Successful Projects Need Executive Champions

Here is a simple truth about projects: All projects result in change. Some projects bring about small modifications to the status quo, and others introduce a large-scale transformation.

No matter the size or scale of the project, people resist change. Overcoming this resistance to change is a top challenge faced by project sponsors today.

Good news: You have what it takes to overcome this obstacle. Engage yourself!

Hiatt & Creasey researched over 300 companies when they wrote the book "Change Management: The People Side of Change." They found the number-one success factor cited for implementing change is visible and active executive sponsorship. When the project team sees that an executive is excited about this project, the team buys in, too.

“Employee resistance increases as authority and sponsorship decreases.” — Hiatt & Creasey

Speak at the kickoff and at periodic meetings over the life of the project. Your team and other stakeholders will embrace the change knowing that it comes from the top.

At first glance people tend to see:

> All of the problems associated with a project/idea.

> All of the other demands on their time.

> All of the other things they’d rather give priority to.

As the project’s champion you need to see that the internal sales process is as important as the project goal/idea itself. The status quo does not need to be defended; rather, the project does.

As a champion, to minimize resistance to change you need to convince stakeholders on an ongoing basis that your project is:

> Worth doing – this can be achieved through the defined desired business outcomes and benefits.

> Doable and will deliver the promised outcomes and benefits.

> And doable by you, your governance and project teams (team credibility).

Some recommended tactics for convincing stakeholders to get behind your project:

> Scale the project to what is worthwhile and can be delivered successfully (i.e., is within your and the organization’s ability to deliver).

> Paint a common picture of the future (through the vision and desired business outcomes) that people at all layers of the organization can relate to and sign on to.

> Encourage key stakeholders to critique the desired outcome statements and review the implementation/change delivery plans.

> Sell to individuals, not the organization (i.e., make the benefits personal to stakeholders).

> Ensure they understand both the problems with the status quo and the ramifications of these problems on the business and their future success.

> As early as possible show the new state working or how the end states will be achieved.

> Enroll them and make them part of the business outcomes and benefits realization process,

> Use a new vocabulary to describe what you are trying to achieve – start creating the new world from the outset.

> Visibly take responsibility for making it happen – make the difficult decisions, chair the difficult meetings, get the difficult commitments up-front and personally manage the difficult stakeholders.

In a nutshell: Engage yourself! Fight for what the project needs. It is relying on you for its success.

Read more…

Project Success Criteria (OKRs) vs. Operations (KPIs)

Project success criteria in the form of OKRs (Objectives and Key Results) should be the driving force behind your project and product direction. They boldly state where you’re going and they give you metrics to judge when you’ve arrived.

Project success criteria should be fail-by-default. To succeed in an OKR you shouldn’t be able to sit on your ass and play defense.

Objectives like “don’t release any new bugs” make terrible OKRs. A guaranteed way to achieve that objective is to stop releasing software. But despite “no new bugs” making an awful OKR, it’s still an important measure of business health. It’s worth keeping an eye on.

There are plenty of metrics like bugs released (a proxy for code quality) which are important to watch but don’t fit well in OKRs. Rather than trying to wedge them into a container where they don’t belong, consider adding a second tool to your toolkit — KPIs (key performance indicators).

If OKRs give your teams direction, KPIs make sure nothing is going off of the rails. Practically any metric — site uptime, conversion rates, user retention — can be used as a KPI. KPIs are a metric that’s important to watch, but not something you’re trying to change right now.

Keeping track of relevant KPIs will help you uncover problems as they emerge. If you decide a KPI is out of line enough to justify investing in a fix, then it simply becomes part of an OKR. The passive KPI “Conversion rate — 5%” becomes the active objective “Double conversion rate by September”.

In a nutshell: Use KPIs to keep an eye on things. Use OKRs when you want to make a change.

Read more…

The Modern Project Charter

It’s not clear to me why project charters (or project initiation documents) are the way they are, but they’re often misused to obfuscate, bore and show an ability to comply with expectations.

If I want the real truth about a project and where it’s going, I’d rather see something else. This modern project charter should be divided into six sections:


1) Reality
2) Assumptions
3) Success
4) Alternatives
5) People
6) Money

Reality

The reality section describes the world as it is. Tell me about the market you are entering, the needs that already exist, the competitors in your space, technology standards, and the way others have succeeded and failed in the past. The more specific, the better. The more ground knowledge, the better. The more visceral the stories, the better. The point of this section is to be sure that you’re clear about the way you see the world, and that you and I agree on your view. This section isn’t partisan. It takes no positions; it just states how things are.

This section can be as long as you need it to be to tell the story. It can include supplementary materials such as spreadsheets, market share analysis, and anything I need to know about how the world works.

Assumptions

The assumptions section is your chance to describe how you’re going to change things using concrete details We will do X, and then Y will happen. We will build Z with this much money in this much time. We will present Q to the market and the market will respond by taking this action.

This is the heart of the modern project charter. The only reason to launch a project is to change something, and I want to know what you’re going to do and what impact it’s going to have.

Success

The success section describes how you define and measure success of your project on three separate levels. 1) Project delivery success, 2) Product or service success, and 3) Business success. You can download a detailed guide on how to define project success here.

Alternatives

Of course, the assumptions section will be incorrect. You will make assumptions that won’t work out. You’ll miss budgets and deadlines and sales. That's where the alternatives section comes in. It tells me what you’ll do if that happens. How much flexibility does your product or team have? If your assumptions have proven to be false, is it over? Talk about alternatives here for when things don't go exactly as planned.

People

The people section rightly highlights one of the key elements of project success: who is on your team, and who is going to join your team. ‘Who’ doesn’t mean their resume; rather, 'who' means their attitudes and abilities and track record in getting stuff done.

Money

The last section is all about money. How much do you need, and how will you spend it? What does cash flow look like? This section should include P&Ls, balance sheets, margins and exit strategies.

The modern project charter looks a lot different than the traditional format you're used to, but the information contained in its six sections provide instant clarity and transparency. Your local PMO might not like this format, but I’m betting it will help your team think through the hard issues more clearly.

In a nutshell: If you want the real truth about a project and where it’s going, write down your reality, assumptions, success, alternatives, people, and money in a project charter.

Read more…

Misunderstanding the Project Sponsor Role Isn't the Only Problem

In recent years, project sponsorship has been the focus of a lot of writing and discussion. Generally, it's agreed that effective project sponsorship strongly contributes to project success.

In my opinion, the success of any organization is dependent upon effective project sponsorship. If project sponsorship is poorly developed or misunderstood, the organization will have a hard time making any lasting achievements. And unfortunately, it's clear that in many organizations this role is still poorly developed and misunderstood.

So why is the project sponsor role such a challenge for organizations, and what is needed for a successful approach?

When discussing project sponsorship, most people focus on defining the project sponsor's responsibilities and behavior (myself included), implicitly or explicitly assuming that ineffective project sponsorship is caused by project sponsors not understanding or doing their job.

This also implies that if project sponsors could just be trained to do their sponsor job properly, the issue with ineffective project sponsorship would be solved.

And this is not necessarily true.

Project sponsors are often business managers who perform their project sponsor role on behalf of an organization, and the way they perform should be seen in this context. They are part of a whole and have good reason to behave the way they do.

Pointing the finger of blame for project failure at the project sponsor is an ineffective approach, and not just because it isolates one factor instead of addressing the whole. It can also be counterproductive.

Feeling blamed for being the cause of project failure can cause unnecessary resistance among business managers. In the end, the challenge is to close the gap between executive management, line management and projects, and to strengthen project direction from a business perspective.

And this is a challenge for the organization as a whole.

Any business manager in a project sponsor role has to divide his or her attention between operational responsibilities (these result in short-term impact on vital matters such as service delivery, customer satisfaction, or commercial result) and their project sponsor role (this results in long-term impact on business success). It is only natural that, under pressure, the short-term operational interests tend to prevail.

Unfortunately, in many organizations, most of the criteria used to measure management performance focus on the direct results of the line organization, thus reinforcing this natural focus on the short-term interests of one’s own department/area.

As a result, the company’s performance management system—which has a direct impact on a manager’s income and career prospects—simply tells them that their operational duties are far more important than their contribution to project success. From a wider perspective, one could say that performance management in many organizations has not yet been adapted to the needs of an environment where the capability to change has become a major success factor.

All this makes for a very reserved attitude from business managers toward projects.

If we then consider that the failure rate of projects is significantly higher than that of operational processes, why would any sensible business manager put their career at risk by being associated with projects?

In the interest of their own future, there can be only one conclusion: Stay away from projects. Leave them to the project managers as much as you can!

Building strong engagement from business management in projects is more than providing tips or training courses on how to be an effective project sponsor.

In a nutshell: You have to establish a culture and a performance management system that rewards active project sponsorship and does not punish project failure. It should punish inactive sponsorship instead.

Read more…

Why Your Organization Doesn't Learn From Its Lessons Learned

Lessons Learned or Lessons Learnt are experiences distilled from a project that should be actively taken into account in future projects.

There are several definitions of the concept. The one used by the NASA is as follows: “A lesson learned is knowledge or understanding gained by experience. The experience may be positive, as in a successful test or mission, or negative, as in a mishap or failure. A lesson must be significant in that it has a real or assumed impact on operations; valid in that is factually and technically correct; and applicable in that it identifies a specific design, process, or decision that reduces or eliminates the potential for failures and mishaps, or reinforces a positive result.”

Personally I like the following definition: “Generalizations based on evaluation experiences with projects, programs, or policies that abstract from the specific circumstances to broader situations. Frequently, lessons highlight strengths or weaknesses in preparation, design, and implementation that affect performance, outcome, and impact.”

I think most organizations feel that project sponsors, managers, and teams can reduce project costs and duration by learning from past projects, by implementing past successes, and by avoiding past failures.

But at the same time, many organizations have no standards for collecting, analyzing, storing, disseminating, and reusing Lessons Learned. Consequently, they are losing valuable knowledge gained during projects and between projects.

They seem to be able to learn the little lessons, like improving small aspects of projects, but the big lessons seem to be relearned time and time again. Here is why:

> Projects are not making sufficient time for a Lessons Learned session.

> Key people (like the sponsor or main stakeholders) are not available for a Lessons Learned session.

> Organizations have an ineffective lessons capture process. Lesson learning crucially needs a standard lessons reporting format and structure, an effective approach to root cause analysis, a focus on lesson quality, openness and honesty, and a validation process.

> Project teams do not see the benefit of a Lessons Learned session. Lessons Learned captured on a project seldom benefit that project. They benefit future projects. Often, the project sponsor and manager see capturing Lessons Learned as simply another chore that provides his or her project with little value, especially if the Lessons Learned procedure is complex, takes a fair amount of resources and time to implement, and management has not provided adequate resources to perform the work. The solution here is to have a simple procedure, ensure projects have the resources and time to implement the procedure, and hold project managers accountable for following the procedure.

> An ineffective lessons dissemination process. The value of even well-crafted reports is often undermined because they are not distributed effectively. Most dissemination is informal, and as a result development and adoption of new practices is haphazard. Generally, project teams must actively seek reports in order to obtain them. There is no trusted, accessible repository that provides Lessons Learned information to project teams company-wide, although some departments do have lessons repositories.

> Lack of motivation to fix the issues. There is a reluctance to make big fixes if it's not what you are being rewarded for, a reluctance to learn from other parts of the organization, and difficulties in deciding which actions are valid.

> A lack of dedicated resources. Commitment to learning is wasted if resources are not available to support the process. Unfortunately, funds available to sustain corrective action, training, and exercise programs are even leaner than those available for staff and equipment. Lesson-learning and lesson management need to be resourced. Roles are needed to support the process, such as those seen in the US Army and the RCAF, or in Shell. Under-resourcing lesson-learning is a major reason why the process so often fails.

> A lack of leadership involvement in and commitment to the learning process. This is the most critical barrier. An effective Lessons Learned process means having a disciplined procedure that people are held accountable to follow. It means encouraging openness about making mistakes or errors in judgment. It often means cultural or organizational change, which does not come easily in most organizations. It means leading by example. If management is unwilling to learn from their mistakes, it is unlikely that the rest of the organization will be willing to admit to mistakes either. In fact, management must reward people for being open and admitting to making mistakes, bad decisions, judgment errors, etc. This, of course, flies in the face of many corporate cultures.

> Process change versus accountability. When something goes wrong on a project, there is someone accountable. One of the biggest problems in implementing an effective Lessons Learned process is to separate the “accountability” issue from the “process” issue. Accountability is important, but is something to be dealt with by management. Lessons Learned must deal with the process deficiency that caused the problem (e.g., inadequate procedure, too much of a rush, inadequate training, poor communications, etc.). Once a Lessons Learned process focuses on blame or finger-pointing, the process will soon fade into oblivion.

> Not using Lessons Learned in the initiation and planning phases of new projects. You should ensure that projects in these stages incorporate Lessons Learned from prior projects by making a Lessons Learned session mandatory.

Closing Thoughts

Instead of leaning the little lessons, like improving small aspects of projects, I think it would be very valuable to learn the big lessons, instead of relearning them time and time again by making the same mistakes on similar projects.

There are many reasons why lesson learning is not working for most organizations. Perhaps the underlying causes include organizations treating lesson learning as a system, rather than as a product (i.e., a report with documented lessons), and a failure to treat lesson learning with the urgency and importance that it deserves.

In a nutshell: If learning lessons is important (and it usually is), then the process needs proper attention, not lip service.

Read more…

Case Study 6: How Revlon Got Sued by Its Own Shareholders Because of a Failed Sap Implementation

Cosmetics company Revlon’s roots stretch back to its 1932 nail polish launch by Charles Lachman and brothers Charles and Joseph Revson. Since its early days, much has changed.

The company’s products have found their way into the everyday lives of individual customers and onto the shelves (digital or physical) of major retailers across the world. Though best known for their makeup, Revlon sells a startling range of cosmetics including hair coloring kits, deodorants, and fragrances to both men and women globally.

Last year on a call following the announcement of the company’s first-quarter results for fiscal 2018, Revlon announced that its SAP ERP implementation was a disaster. This came on the heels of delayed financial reporting because of said SAP implementation failure.

The company’s stock fell 6.9 percent within 24 hours of reporting the news, which led to investor lawsuits against the company. Not good, especially for a publicly traded and well-known consumer product company.

Some four law firms have filed class action suits to date, based on the U.S. beauty behemoth’s quarterly results where it confessed it was unable to fulfil orders to the tune of US$64 million because of its inability to record and account for inventory.

“In early February [2018], we rolled out SAP for a large part of our North American business to integrate planning, sourcing, manufacturing, distribution and finance… However, we experienced issues during the SAP changeover that caused the plant to ramp up capacity slower than anticipated,” Christopher Peterson, COO, told investors on this call.

"As a result of the poor preparation and planning of the implementation of the ERP system, Revlon was unable to fulfill product shipments of approximately $64 million of net sales," claims a lawsuit filed in the U.S. District Court in New York by Rosen Law Firm on behalf of an investor. The lawsuit was announced late last week and seeks class action status.

Revlon is the latest in a string of recent SAP enterprise resource planning (ERP) failures. Lidl, National Grid, and Haribo are just a few other companies that have experienced such massive challenges.

ERP problems, including implementation failures, are common. But an ERP problem that results in an investor lawsuit is rare. The more common disputes are between ERP customers and the system implementers.

So what happened at Revlon?

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Timeline of Events

2016

In June 2016, U.S. cosmetics company Revlon announced its intention to buy Elizabeth Arden Inc. for US$870M. The acquisition was completed in September of the same year.

Revlon then kicked off 2017 with a major restructure, cutting jobs and streamlining operations as part of the acquisition and integration. This activity alone was projected to cost between $65 million and $75 million over the coming four years. Revlon also acquired the Cutex brands in the same year.

Elizabeth Arden was an early adopter of Oracle Fusion Applications according to a Forrester report of 2013. In the 2008 annual report for Elizabeth Arden, the chairman, president and CEO E. Scott Beattie was quoted as saying, “Our global efficiency re-engineering project remains on track and we currently anticipate savings of approximately $10 million to $12 million by the end of fiscal 2009 and additional savings of approximately $13 million to $15 million by the end of fiscal 2010. A significant component of our global efficiency re-engineering project is the implementation of an Oracle financial accounting and order processing system. During fiscal 2007, we successfully implemented the same Oracle solution in our Greater China business.”

Revlon had previously chosen Microsoft Dynamics AX which was an equal success story. Revlon ran 50 different business entities with a plan to collapse 21 separate ERP systems into one. Dynamics AX was to be implemented at Revlon to act as one unified organization under the leadership of David Giambruno, senior VP and CIO of Revlon back in 2013.

Giambruno was quoted as being in favor of a “no customization rule” within Revlon. The base implementation and the first company took a year to go live. The second country went live in 14 days and the third country in less than a day! Giambruno left Revlon in November 2013. Juan Figuereo, a new Revlon CFO, joined the company in April 2016 only to retire just over a year later in mid 2017.

Fast forward to today, and it comes as no surprise that off the back of the acquisition, Revlon considered migrating to something different. Colomer, the Barcelona-based hair and beauty products firm that was acquired by Revlon in 2013, ran on SAP. The subsidiary Red Door Spas, part of the Arden business, also ran on SAP. Colomer/Revlon implemented HANA in April 2014. In the middle of the project, Colomer was acquired by Revlon; this affected the project, in that the landscape had to be moved from Spain to the USA.

When exactly the decision to switch to SAP was made, or why, I can’t say; however, this decision was already on the cards per the fiscal year ending December 31, 2016 filing. Ahead of the implementation the filing even stated that

This system implementation subjects the Company to substantial costs, the majority of which are capital expenditures, and inherent risks associated with migrating from the Company's legacy systems. These costs and risks could include, but are not limited to:

> inability to fill customer orders accurately or on a timely basis, or at all;

> inability to process payments to vendors accurately or in a timely manner;

> disruption of the Company's internal control structure;

> inability to fulfill the Company's SEC or other governmental reporting requirements in a
timely or accurate manner;

> inability to fulfill federal, state and local tax filing requirements in a timely or accurate manner;

> increased demands on management and staff time to the detriment of other corporate initiatives; and

> significant capital and operating expenditures.

If the Company is unable to successfully plan, design or implement this new SAP ERP system, in whole or in part, or experience unanticipated difficulties or delays in doing so, it could have a material adverse effect on the Company's business, prospects, results of operations, financial condition and/or cash flows.

While statements like this are not entirely unusual, it is a red flag to investors, or should be, indicating that the business anticipates problems and chooses to protect itself accordingly with such caveats.

2018

Revlon said on its earnings conference call in March 2018 that while it remained on track with the Elizabeth Arden integration activities, it was seeing lower sales volumes, but that they expected the total estimated synergies to be impacted over the multiyear period.

At the time the specifics of the implementation of the new SAP ERP system, which went live at the beginning of February, was said to be overall on schedule in terms of the implementation steps. "Production capabilities and inventory recovery has been slower than expected, affecting our current order fulfilment levels."

Revlon said it had taken "immediate actions to address the situation, have implemented a robust service recovery plan and have communicated with our key customers." This suggests many temporary hands in warehouses to pick, pack and ship as well optimize and cut backorders.

As Revlon COO Christopher Peterson stated in 2018, Revlon had implemented SAP for a huge portion of the North American company for improved supply chain integration to increase efficiency and improve working capital management, but the SAP changeover resulted in an initial slowing of plant operations, disrupting the manufacture of finished goods and fulfilling orders to large retailers.

Revlon attributed to the changeover a reduction of $20M in net earnings in one quarter alone, accompanied by $10M in unplanned expenses including non-recurring labor to improve customer support. At the time (2018), Revlon had implemented SAP in 22 countries on the Revlon heritage side of the company. Apparently, the Arden switch-out of JD Edwards had not even begun at that stage.

2019

A year later, in March 2019, CFO Victoria Dolan said Revlon had spent $32M in 2018 on operating activities in comparison to 2017, taking the costs of the migration to $54M; understandably, profits and stock prices dipped. Revlon reported increased losses. The fiscal year 2018 (ended on December 31) closed with $294.2 million dollars in the red, compared to $183.2 million-dollar losses registered in 2017.

Ironically the results were due to a drop in sales of all its business categories, except Elizabeth Arden, partly caused by the breaks in service levels directly attributed to the SAP implementation. Revlon also qualified the losses by saying that the rise in losses was also related to the re-acquisition of some rights connected to the brand Elizabeth Arden.

In March 2019, the United States Securities and Exchange Commission (SEC) made public Revlon’s first-quarter 10-K filing, thus illustrating to the wider world the dire SAP ERP issues in the Oxford plant and their wide-reaching effects on the business. Around the time of the SEC’s release, the company’s chief financial officer made clear to the public that the SAP ERP issues had been resolved and that the Oxford plant was up and running as normal.

After the March 2019 financial statement stock prices improved.

Yet, in May of 2019, Revlon faced a stream of painful class action lawsuits from firms Bragar, Eagel, & Squire; Rosen Law Firm; Wolf, Haldenstein, Adler, Freeman, & Herz; and Zhang Investor Law. Ouch.

In the class action suit, specific reference was made to the Oxford center in North Carolina where the business was supposedly unable to fulfil product imports of about $64M worth of revenue.

What Went Wrong

As if the above weren’t enough Revlon also reported that:

> The company was unable to recover lost sales from the SAP failure

> Customer service levels were disrupted

> There were increased demands on its management team and staff, which cannibalized focus on other corporate priorities

> It incurred significant capital and operating expenditures

> It experienced difficulty processing payments to vendors

> It was unable to fulfill federal, state and local reporting and filing requirements in a timely or accurate manner

> It had greater than expected expedited shipping fees, resulting from the customer firefighting stemming from the SAP failure

> It suffered from an “inability to fill customer orders accurately or on a timely basis, or at all”

How Revlon Could Have Done Things Differently

Incremental Software Implementation Strategy

Perhaps Revlon should have considered starting small. The disaster that was their SAP ERP implementation in the Oxford plant might have been avoided if the company had used a narrow roll-out strategy for the software.

When a company utilizes an incremental roll-out strategy the former system is slowly replaced as the new SAP ERP is rolled in. The benefits of such a strategy are obvious: if the new software is implemented piece by piece, potential problems can be sussed out, understood, and handled on a small-scale without causing serious damage to the company’s reputation, efficiency, or bottom line. Even if large-scale issues occur in the future, the company will have experience getting such matters under control and will be more likely able to snuff out the problem quickly.

Furthermore, employee training may be more gradual and thorough should the company choose a roll-out rather than big-bang strategy. Opting for a big bang means that they have selected to implement the new SAP ERP across the board simultaneously.

Revlon could have chosen to implement a roll-out strategy on a less vital company entity first, thus working out the kinks of the software-business partnership, before gradually stepping into major company entities like the Oxford plant.

Risk Management Is Project Management for Adults

Revlon, like many companies implementing SAP S/4HANA and other ERP solutions, didn’t seem to understand the risks associated with their transformations. Worse yet, they must not have quantified or implemented effective strategies to mitigate those risks.

In this case, Revlon experienced shipping delays and lost sales due to production stoppages at its North Carolina plant – the location of the first phase of its SAP go-live.

Had Revlon understood, quantified, and mitigated the inherent ERP implementation risks, it would have taken action to ensure that its go-live didn’t materially affect its operations.

Had Revlon had a sufficient emergency plan in place, they might have amended the Oxford disaster in a far shorter period of time, and thus caused less damage to the company. How many of the issues which arose in 2018 could have been foreseen? Could solutions have been found in advance of implementation?

If Revlon had better planned for such problems, perhaps the problems could have been avoided in the first place or even simply nipped in the bud.

As Tim Lister says, risk management is project management for adults.

Organizational Implementation Readiness

Prior to implementing SAP, Revlon had some significant operational issues related to its acquisition and integration of the Elizabeth Arden brand. As it outlined in its financial filings, it was having trouble integrating the operations, processes, and organizational structure with its newly acquired company. An SAP implementation is likely to fail against this type of backdrop.

Instead of focusing on the futile attempt to roll out new SAP ERP software, the company should have built a stronger business blueprint and foundation for the overall transformation. This would have begun with defining how Elizabeth Arden would fit into its overall operations, as well as defining clear business processes for the implementation.

This SAP S/4HANA implementation readiness phase is a critical but often overlooked ingredient to transformation success.

Closing Thoughts 

While the circumstances surrounding the newest ERP lawsuit are unique, as are the plaintiffs, the events that led to the failure of Revlon’s SAP system are all too familiar.

It may be tempting to blame the SAP software or whoever the system integrator was, but Revlon and others should recognize that they ultimately have to own the results of these sorts of transformations.

For starters, it does not seem as if Revlon understood either the size of the projects nor any of the risks inherent in rolling out a new ERP software system. It doesn’t appear as if the cosmetics giant developed any strategies to offset the possible risks.

Complicating matters, the company was encountering major problems integrating the Elizabeth Arden brand into its business. Rather than focusing on getting the new ERP system up and running, it should have first addressed the operational problems. Any ERP implementation is likely to fail under these circumstances.

Furthermore, the company admitted in the SEC filing that it had “material weaknesses” with its own internal controls caused by the ERP implementation. Having an effective business plan before starting an ERP project can help companies to avoid this.

But without question, the largest problem for Revlon was that as a result of the ERP train wreck the project resulted in a negative ROI stemming from production and operational issues when Revlon brought the SAP system online.

Costly failures such as the one Revlon encountered can be avoided. Doing so requires top management to own the project and develop a plan to smoothly meld the technology into the business process, not the other way around.

Don’t let your project fail like this one!

Discover here how I can help you turn it into a success.

For a list of all my project failure case studies just click here.

Sources

> US SECURITIES AND EXCHANGE COMMISSION, Commission File Number: 1-11178
REVLON, INC., Form 10K

> US SECURITIES AND EXCHANGE COMMISSION, Commission File Number: 1-11178
REVLON, INC., Form 10Q

> CLASS ACTION COMPLAINT FOR VIOLATIONS OF THE FEDERAL SECURITIES LAWS, UNITED STATES DISTRICT COURT EASTERN DISTRICT OF NEW YORK, Case 1:19-cv-02859, Document 1, Filed 05/14/19

> REVLON REPORTS SECOND QUARTER 2018 RESULTS

> REVLON REPORTS THIRD QUARTER 2018 RESULTS AND ANNOUNCES 2018 OPTIMIZATION PROGRAM

Read more…