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.

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

Read more…

Case Study: 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?

A timeline of events

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.

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.

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 could Revlon 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.

Other project failure case studies

> For an overview of all case studies I have written please click here. 

> To be informed about new case studies just sign up for my newsletter here. 

References

> 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

> Oracle’s Dilemma: Applications Unlimited Versus Oracle Fusion Applications

Read more…

How to improve your organization's project management capabilities

One (relatively) easy and effective way of increasing the number of successful projects in your organization is improving your organization’s project management capabilities.

Business capabilities are a combination of people, process, and technology. Although I very much agree with Tom Peters when he says that “business is people doing things for other people,” when it comes to project management capabilities, process comes first, people second, and technology last. People and technology support the process.

In his book “The Handbook of Program Management: How to Facilitate Project Success with Optimal Program Management” James T. Brown describes a very straightforward approach on how to improve your project management capabilities by creating accountability and maintaining discipline. In other words, he shows how supporting the process can lead to project management success.

Create accountability

A big advantage of processes for project management is that they drive accountability into the system at all levels. Project managers and project sponsors should use leadership and strategy not only to make the project team accountable, but also to make external stakeholders and the leaders in your organization accountable.

Two levels of accountability are critical for improving your project management capabilities. The first level is having someone who is accountable for the establishment, improvement and compliance with the project management processes themselves. These processes should include project management, program management, and portfolio management.

The second level of accountability involves clearly defining all roles and responsibilities for project sponsors, steering committee members, project managers, team members, consultants, and PMO staff.

Developing accountability begins with selling your people on the concept that project management is best accomplished through a structured, repeatable process.

Not too many processes, not overly bureaucratic processes, but strategically thought-out “just enough” processes that are based on the organizational context. These processes are then created and rolled out in an orderly fashion to ensure acceptance and minimize disruption of existing work.

Most people agree that implementing every process that is logical, right, and valuable immediately all at once will overwhelm any organization. Therefore, you must prioritize these processes on the basis of the challenges your organization is facing and then establish a strategy for implementing the processes. 

Strong accountability practice includes establishing an individual who is accountable for managing each process.

Maintain discipline

Do we always follow the logical, well-thought-out, planned process we have established for repeatable success, or do we short-circuit the process every time an imminent deadline, cost pressure, or demanding client or stakeholder surfaces? I am not saying that you should never violate processes, but when you do, you must have a process by which such deviation is approved and publicly acknowledged to all.

When you handle these deviations properly, you signal to the whole project management community in your organization that you and they will act with integrity under pressure.

And although such deviations should be rare, they are very important because they help improve your process.

Closing thought

In the end project management is simply the application and execution of structured, organized common sense.

When you need some guidance on how to define and measure project success, just download the Project Success Model here. 

Read more…

Why you should express your project budget in terms of expected value

Your project budget should always be expressed in terms of expected project value.

Simply put, project success occurs when outcomes add value to the business. This implies that the value of a project is defined by subtracting all of the (in)direct costs from all of the (in)direct benefits the project delivers.

Using this logic, when your expected project value is USD 3M and your company wants a return on investment (ROI) on each invested dollar of 50%, your project budget is USD 2M. In other words, project budget = project value / 1.5.

If the estimated value of your project goes down, your project budget goes down. It is that simple.

Many people confuse real project budget with the authorized project budget. The authorized project budget is the total amount of authorized financial resources allocated for the particular purpose(s) of the sponsored project for a specific period of time. It is usually based on a mixture of project cost estimations, department budgets, free cash flow, and other factors.

But as soon as your costs go over the authorized project budget (which is highly likely for technology projects), or the estimated benefits are not as big as planned (highly likely as well) you should ask yourself what the real budget of your project is and if you are willing to spend it or not.

How do you know whether you’re looking at the right factors when it comes to determining the real budget?

Whether or not your company can spend this money is a financing and risk question, not a budget question. You could even secure a loan to do certain projects. This increases risk and reduces ROI (because of paid interest) but can be a valid option.

Whether or not this budget is enough to realize the project is a cost estimation and risk question, not a budget question. You should never confuse your cost estimations with your budget. Budget is what you can spend, while cost estimation is what you think you will spend. Ideally, the latter is less than the former.

And whether or not your organization is willing to spend their money on this project is a prioritization question, not a budget question.

Always express your project budget in terms of expected value delivered and you’ll have a better idea of the real budget of any project.

When you need some guidance on how to define and measure project success, just download the Project Success Model here. 

Read more…

Product or service success does not automatically mean business success

I have written many times about project success, and why I think it must be defined on three separate levels. These levels are:

1) Project delivery success: Will the project delivery be successful? Essentially, this assesses the classic triangle of scope, time, and budget.

2) Product or service success: This refers to when the product or service is deemed successful (e.g., the system is used by all users in scope, up-time is 99.99%, customer satisfaction has increased by 25%, and operational costs have decreased by 15%).

3) Business success: This has to do with whether the product or service brings value to the overall organization, and how it contributes financially and/or strategically to the business’s success.

In a LinkedIn discussion around project success, some people challenged the notion that numbers 2 and 3 are separate levels. They are.

Here are some examples that will to help explain why product success doesn’t necessarily equal business success.

Imagine a new investment product for a bank that has a high margin but also carries a significant risk for the bank, not just the customer. The product was wildly successful and many clients bought it. Many more than expected, which made the risk profile for the bank too high.

Now imagine that this one product is still very successful and is creating revenue and happy customers but it goes against everything that is defined in the new strategy of the company, and this is blocking the company from moving in a different direction.

Or that this very successful product with many happy clients, instead of helping the company to get additional clients, is actually cannibalizing their existing clients.

Or that this very successful new service in the direct business of the company is competing with services offered through partners of the business, and these partners are so pissed that they jump ship and it results in a huge net loss.

All the above are true stories that illustrate how product success can be completely different from business success.

For smaller companies with only one product, or a very small product/service portfolio, you might argue they are similar and very tightly correlated.

But for larger companies with bigger portfolios, I’m of the opinion that product success and business success are fundamentally different. This is reflected in the three separate levels I recommend to define project success.

When you need some guidance on how to define and measure project success, just download the Project Success Model here. 

Read more…

Case Study: Workday did not work for Sacramento Public Schools

California’s Sacramento City Unified School District (SCUSD) thought they were getting a good deal when they hired software as a service (SaaS) provider Workday and their service partner Sierra-Cedar for a program intended to improve the management of the district’s finances, payroll, and human resources (HR).

Unfortunately, SCUSD’s high hopes of cutting costs and increasing efficiency in these areas were more than dashed. They were completely destroyed. The school district alleges that after two years of major financial investment in the project, they were left with zero results. Not only that, but in a complaint filed in August of 2018, the district claims that each company infringed their contracts, falsely presented themselves, and defied California’s business and professions code. In addition, SCUSD alleges that Sierra-Cedar committed fraud.

Sierra-Cedar boasts a workforce of approximately 900 employees and has been in business since 1995. They purport to provide consulting services that pertain to upgrading, strategizing and implementing technologies specific to certain industries.

Sierra-Cedar claims to hold “over two decades of enterprise applications experience across a variety of industries including Higher Education and [the] Public Sector.” According to SCUSD, Sierra-Cedar stated that they would provide staff with specific expertise and experience in their area of the public sector, namely K–12 education. Yet the district alleges that no such staff was provided. Rather, they state that they were given consultants with no knowledge or work history in the subject.

Workday is 10 years younger than its codefendant, beginning as a start-up in 2005 with the goal of selling HR and finance technology. The company specifically targets many different industries, including education, specifically calling out to K–12 schools and school districts. Workday claims that their software can be used for teacher recruitment, to gain useful HR information, and to reduce overhead, among other services. It is designed to manage payroll and expenses, track absences, and organize job candidates.

According to SCUSD’s complaint, Workday has more than 8,000 employees and brings in billions of dollars in revenue each year. Workday had its beginnings with private companies, but soon branched into work with public entities like local governments.

In spite of Sierra-Cedar and Workday’s alleged failures to perform contractually required work for the Sacramento schools, the companies raked in enormous amounts of cash in the project. The school district claims that the contracts were written in such a way that both companies were able to extract enormous fees whether or not they performed up to par.

The district extended the project’s end date twice, presumably hoping to see an improvement in results, but none came. Finally, with a cringe-worthy payroll testing quality of, at best, a mere 70 percent, SCUSD threw in the towel. The project was never implemented and the district lost a serious amount of money. As the district so sharply stated:

“While Workday and Sierra-Cedar got paid… they put the district right back where it started with nothing to show after two years.” – SCUSD

These harsh words showcase the depth of the issue at hand.

As a result of claimed damages and a demand for the recovery of fees paid, SCUSD is suing for $5.2 million and they need that money badly. These days the district is in dire straits, suffering the threat of insolvency. It may soon have no more funds left and risks being taken over by the state.

The district claims that, should they be taken over, it will take 10 years to recover and the process will be highly detrimental to the student body.

Timeline of Events

SCUSD serves more than 43,000 students across 77 campuses and employs more than 4,200 individuals. The district operates with an annual budget of more than $500M in annual spend. In 2013, they determined the district’s HR and ERP systems did not position them to effectively move forward.

The district’s chief business officer (CBO), with the help of a consultant, set out to identify possible replacement options. In early 2013, the district personnel engaged with the Workday sales team and began to discuss their requirements. Over the course of a number of months, through the exchange of phone calls and emails, it was determined that Workday could meet the district’s requirements (even though Workday had no K–12 implementations).

Workday presented CedarCrestone as a qualified implementation partner and the project was initially presented to the board with a budget of $816K for the first year of Workday cloud fees. The maximum estimate for the time and materials contract presented by CedarCrestone was $3,871,000. The project was scheduled to run from August 2014 through October 2015.

In July 2014, Sierra-Cedar was formed by combining the operations of Sierra Systems US and CedarCrestone.

In October 2014, the numbers were adjusted to $1.275M in annual fees to Workday, and Sierra-Cedar’s anticipated fees were reduced to $3.098M. It is not clear if the amount of Sierra-Cedar’s PO represented the full maximum estimate.

In August 2015, the CBO left SCUSD. Around that same time, it was determined that the targeted January 2016 go-live date would not be met. The school district claims that they pressured Workday and Sierra-Cedar to provide a go-live date that would absolutely be met. The parties agreed to a target go-live of July 2016.

As the go-live date approached, the project team could not achieve payroll testing quality of more than 70 percent. With more than $250M in annual payroll at risk, SCUSD made the call that they would not go live.

Additional negotiations took place with Workday and Sierra-Cedar, in an attempt to salvage the program. In November 2016, SCUSD decided to kill it.

In July 2017, SCUSD named a new superintendent. And in August 2018, SCUSD filed a suit in Sacramento Superior Court. The lawsuit alleges that Sierra-Cedar committed fraud and that both Workday and Sierra-Cedar violated the business and professions code, misrepresented themselves, and breached contracts they had with the district, among other things.

What went wrong

According to the complaint filed by the school district, Workday and Sierra-Cedar had agreed to provide a cloud-based software system to suit their needs. SCUSD chose this particular software in hopes that it would improve many of their most important operations. Yet, after spending millions on the system and related services, the district claims they were left empty-handed.

The district argues that Workday and Sierra-Cedar used SCUSD as a test experience with the schools in order to “tout and enrich themselves as experts in elementary and high school, or K-12, education technology ‘solutions.’” Most significantly, the district argues for the return of the fees spent on what should have been functioning technology which, they say, was agreed upon but never delivered.

They allege that Workday never suggested that their systems could not be used effectively in K–12 schools. In fact, SCUSD claims that company representatives presented the software as being fully capable of handling the CBO’s specific requirements. In other words, SCUSD placed their trust in these companies to do as they promised.

However, SCUSD now believes that they were duped. Workday’s intentions, rather than to provide a cloud system to suit the needs of Sacramento’s schools, was, according to the district, a means to enter into the K–12 sector with as little financial risk as possible for what they refer to in their complaint as a “practice run.” Furthermore, SCUSD believes that Sierra-Cedar was well aware of Workday’s intentions.

The district claims that Sierra-Cedar was presented as the only option available for project implementation and that they were, thus, qualified to do so. A series of contracts were drawn up which the district assumed to be fair following the many conversations SCUSD’s CBO had shared with Workday regarding the project’s parameters. Workday, they believe, was under obligation to provide staff experienced in the K–12 sector and that were capable of getting the job done. Sierra-Cedar vowed to provide such staff for implementation.

Workday promised many things: regular reviews of Sierra-Cedar’s work, a subscription to Workday’s software as a service (SaaS), training for school staff, and support throughout the project. Various steps were agreed upon which would be applied in the course of project implementation. It was understood that Workday would check up on Sierra-Cedar and ensure they were performing in an agreed-upon manner.

The financial side of the project was problematic. The district believes that the companies wrote the contracts in such a way that all the financial risk fell on the schools. Before the project was made live, Workday required the payment of two fees of over $1.5 million. Training payments were requested to be made before training had begun. In addition, the district was to pay an hourly rate to Sierra-Cedar.

In spite of their promises to provide experienced staff, Sierra-Cedar SCUSD the district with a project manager with no experience in the K–12 sector. This was also allegedly true of the additional staff they provided.

Due to the staff’s alleged lack of understanding and knowledge of the K–12 sector, they had great difficulty in handling the schools’ data and organizing the technology to suit the district’s needs. SCUSD claims their data mapping and conversion was regularly late, incorrect, or only partially completed, which led to extra expenses and delays.

Another important aspect of Workday’s SaaS solution was that it was supposed to handle the schools’ payroll. Yet, between January and June 2016, Sierra-Cedar was unable to get the payroll accuracy to over 70%. Though Sierra-Cedar and Workday assured the district that they could go ahead and implement payroll, the accuracy numbers from the test were too low for the district to agree. Moreover, the district claims that the companies would not assure them that payroll would be correct if they did decide to implement it. Thus, the schools chose not to do so.

By November 2016, SCUSD decided it was not possible to continue the project in spite of investing millions of dollars in it. They claim that in 2016, the proposals that the companies made were entirely insufficient and not possible to put into action. On November 22, SCUSD notified Workday and Sierra-Cedar that they were putting an end to their relationship.

The school district believes that the project was an enormous loss of funds and time for them, while Workday and Sierra-Cedar exited the contract with both K–12 experience they could market to other customers and a gain of millions of dollars. In other words, the district claims that the companies made significant money using SCUSD as their K–12 guinea pig while enriching themselves.

In fact, on their website, Workday describes the company as a program which “streamlines the ‘business’ of education” for K–12 school districts by providing assistance in business planning, financial management, human capital management, and prism analytics. SCUSD believes they were the testing ground for forming this K-12–specific focus.

In the end, the school district sued the two companies for the following:

> Breach of Contract against Sierra-Cedar for not performing their contractual obligations;

> Breach of Contract against Workday for not providing the experienced K–12 sector experts they were promised, not offering sufficient check-up, and not fulfilling their contractual duties;

> Breach of Covenant of Good Faith and Fair Dealing against Sierra-Cedar for failing to truly attempt to make the project go live and instead giving insufficient fluff proposals;

> Breach of Covenant of Good Faith and Fair Dealing against Workday, for not offering true and real support to successfully release the project on the go-live date;

> Fraud against Sierra-Cedar for agreeing to provide staff with K–12 experience and expertise in the contract, then proceeding to do no such thing. In fact, SCUSD claims that Sierra-Cedar knowingly used whatever staff they had available for the project and took advantage of the opportunity by using the school district as a K¬¬–12 training ground while gaining a substantial hourly rate. If true, Sierra-Cedar would have knowingly misrepresented themselves. The school district claims that this misrepresentation caused a breach of their rights;

> Negligent misrepresentation against Sierra-Cedar for stating that they would offer experienced employees and then not doing so;

> Violation of the Business and Professions Code against Sierra-Cedar for unfair competition through their alleged misrepresentation and for allegedly using SCUSD as a K–12 experiment;

> Negligent misrepresentation against Workday for presenting Sierra-Cedar as being capable of carrying through on the project; and

> Violation of the Business and Professions Code against Workday for unfair competition through their claim that Sierra-Cedar employees were experienced and could complete the work well.

In the end, Sacramento City Unified School District claims to have paid $3,240,955.45 in fees to Sierra-Cedar, a substantial sum for any school district. Moreover, they never received the benefits which were promised by Workday representatives way back in the early conversations with the school’s Chief Business Officer Forrest.

For the school district, the project with Sierra-Cedar and Workday was a disaster.

How could SCUSD have done things differently?

If SCUSD’s allegations are true, both Workday and Sierra-Cedar were deeply in the wrong. But SCUSD also has to think hard about their own role in this project failure.

If you sign up a trusted advisor, make sure they are qualified.

The lawsuit claims that SCUSD used an experienced K–12 consultant to assist with the ERP selection process. This program looks like a disaster from top to bottom. It is not clear what experience the initial consultant had. Perhaps SCUSD is suing the wrong party. Or maybe the advice was sound, and SCUSD just ignored it.

Get IT on board.

The lawsuit makes no mention of IT. The published board documentation makes no reference to IT. Any well-qualified CIO would have likely stopped the idea of planning to use software that had not had a thorough industry shakedown, particularly in the public sector where budgets are tight and regulatory compliance requirements are high.

Get a decent lawyer on board.

The suit claims that simple boilerplate contracts were used that offered very little protection to SCUSD. They were largely relying on the “good word” of their suppliers. Given this was a $5M spend that involved a system that controlled the payment of more than $400M in salaries and benefits, you would have thought that somebody from Legal would have been a little more forceful in protecting SCUSD.

Never be first … unless you are willing to have the project blow up in your face.

SCUSD could have and should have known that there were no Workday K–12 customers. A simple reference check would have told them that. Any company that signs up to be the beta test for any software should do so with some form of significant financial gain possible.

If you do want to be the first, make sure the vendor is paying their share.

If Workday and Sierra-Cedar wanted to penetrate the K–12 market so badly, Sacramento could have likely gained major contract concessions to offset the risk they were willing to take. Having an experienced negotiator on their side could have saved SCUSD millions of dollars up front and likely increased the probability of success with the vendors having more skin in the game.

Do quality checks.

As a part of the Workday implementation practice, quality checks are performed, and the results are reported to the client. The lawsuit, while mentioning the quality checks were to be performed, makes no mention of what was reported and what the issues were that the team might be dealing with. It is entirely possible that Workday identified issue(s) described in this article. And even if they didn’t, as the paying client, you are always responsible for doing quality checks yourself as well. Never trust a third party to sign off on quality.

Be ready for the project and engage yourself.

Given the apparent lack of participation of IT and Legal, and the apparent lack of quality and detailed requirements documentation, it is highly probable that there was insufficient participation throughout the program. If quantifiable participation was called out as a part of the boilerplate contract, then this is going to be a heavy lift for SCUSD’s legal counsel.

Closing thoughts

The loss of millions of dollars down the drain for Sacramento’s public school district doubtlessly affects teachers, students, staff, and parents. SCUSD had high hopes of implementing a tech program that would save them time and money. In the end, dollars and hours were simply wasted.

Yet the school district is not a wholly innocent victim here, even if the allegations prove true.

Staff and school officials did not do their due diligence in checking up on the company’s background in K–12 or looking into the project managers they had on staff. Rather than simply accepting Workday’s word that they had experienced professionals at Sierra-Cedar, SCUSD ought to have looked deeply into the matter.

The schools would have done well to request specific evidence of Workday’s SaaS solution working successfully in other school districts. With a bill in the millions and hours of invested time, it seems like the least they could have done.

The district should have more carefully checked the language in the contracts to ensure that the companies could not have exited the project with the cash without delivering a functional product.

Regardless of the Sacramento Superior Court’s final decision, it’s clear that both the plaintiff and the defendants could have done better.

Other project failure case studies

> For an overview of all case studies I have written please click here. 

> To be informed about new case studies just sign up for my newsletter here. 

References

> Sacramento City Unified School District vs. Workday Inc a Delaware Corporation. No. 2018-00238302. Sacramento Superior Court. 1 August 2018

> Meeting Minutes Sacramento City Unified School District Board of Education, 19 June 2014

Read more…

Principles of Project Success (Part II)

Project management principles are the foundation on which the profession of project management is built. Conformance to these principles is a prerequisite for successful project management.

I have written about the five principles of project success from Glen Alleman before. And they are still the best I have come across so far.

But last weekend I stumbled on an older blogpost from Bill Duncan that also gives a very clear and interesting perspective on the principles of project success.

Bill Duncan was the primary author of the original version of “A Guide to the Project Management Body of Knowledge”.

He wrote the post titled “Principles of Project Management?” in response to a question on LinkedIn, but originally wrote the text more than 20 years ago building on some work done by Max Wideman, Bob Youker, and others.

Bill starts his post with the following definitions.

Principle: A basic truth, law, or assumption; a rule or standard, especially of good behavior; a basic or essential quality or element determining intrinsic nature or characteristic behavior. (American Heritage Dictionary)

Project: A unique, temporary endeavor undertaken to create a product or service.

Project management: The application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project. (PMBoK Guide, first edition)

Stakeholders: Individuals or organizations who may help or harm the project.

Next, Bill dives in to his five principles of project management.

Project Management Principles

1) There must be a project.

Project management is best applied to the management of a project, and all projects should be managed with project management. The usefulness of some project management tools and techniques outside the project context does not mean that project management is a substitute for general management. Likewise, the fact that project management borrows heavily from general management does not mean that general management skills and knowledge will be adequate for successful management of a project.

2) Projects must be properly authorized. 

Each project should be formally authorized by a level of management commensurate with the resource needs of the project: the greater the needs, the higher the organizational level which should authorize the project. Unauthorized projects are likely to be unsuccessful no matter how well-managed.

3) The project sponsor(s) must provide adequate resources

Resources include tangibles such as financing, people, and material as well as intangibles such as time and support. The need for the sponsor to provide adequate resources does not absolve the project management team of the responsibility (a) to communicate the impact of receiving inadequate resources or (b) to identify alternative courses of action that may be possible with fewer resources.

4) There must be an integrated project plan

Your plan must be documented and distributed to appropriate stakeholders and must include:

> Scope, schedule, cost, and responsibilities defined at an appropriate level of detail for the size, complexity, and phase of the project.
> A defined process for dealing with uncertainty in scope and work definition.
> Success criteria defining how the project will be judged and measured.
> A defined process for dealing with changes to the plan.

5) There must be periodic assessments of performance against the plan 

Periodic assessments are necessary to ensure that the project will achieve its purpose. Projects which no longer support the purpose for which they were undertaken should be cancelled or significantly redirected.

Principles of Project Success

The Five Immutable Principles from Glen are stated in the form of five questions. When you have answered these questions, you will gain insight into the activities required for the project to succeed in ways not found using the traditional process group’s checklist, knowledge areas, or canned project templates.

I) What does “done” look like? 

You need to know where we are going by defining “done” at some point in the future. This may be far in the future—months or years—or closer—days or weeks from now.

II) How can you get to “done” on time and on budget and achieve acceptable outcomes? 

You need a plan to get to where you are going, to reach done. This plan can be simple or complex. The fidelity of the plan depends on your tolerance for risk. The complexity of the plan has to match the complexity of the project.

III) Do you have enough of the right resources to successfully complete the project? 

You have to understand what resources are needed to execute the plan. You need to know how much time and money are required to reach the destination. This can be fixed or it can be variable. If money is limited, the project may be possible if more time is available and vice versa. What technologies are needed? What information must be discovered that you don’t know now?

IV) What impediments will you encounter along the way and what work is needed to remove them? 

You need a means of removing, avoiding, handling or ignoring these impediments. Most important, you need to ask and answer the question, “How long are you willing to wait before you find out you are late?”

V) How can you measure your progress to plan? 

You need to measure planned progress, not just progress. Progress to plan is best measured in units of physical percent complete, which provides tangible evidence, not just opinion. This evidence must be in “usable” outcomes that the buyer recognizes as the things they requested from the project.

Comparison and Closing Thoughts

When you compare Bill’s project management principles with Glen’s Five Immutable Principles, you will see many similarities.

Principle 1 is implicitly stated by Glen, because his principles refer to projects. But yes, they only apply to projects, so there should be a project in place.

Principle 2 is not part of Glen’s principles and I tend to agree with Bill that, when it comes to larger companies, this is a prerequisite for project success.

Principles 3 and III are similar, but I like Glen’s definition better. The project sponsor is not solely responsible for resources. Suppliers can have resource issues no matter how much money you give them.

Principle 4 is the same as principle II.

Principle 5 is the same as principle V.

Principle I is not a separate principle for Bill, but it is mentioned in principle 4.

Principle IV is not a separate principle for Bill, but I think it should be.

The post made by Bill Duncan has not convinced me to change my adoption of Glen Alleman’s principles. However, it did gave me a very interesting new perspective on project success principles, and I will go back and add a sentence to my previous articles stating that Glen’s five principles are only valid for authorized projects. This addition will cover Bill’s first two principles.

I hope this article will make you think about your own project success principles and practices. When projects do not work out, you can usually trace the root cause back to one of the principles and start fixing it. And when you want to give a new project the best chances of success, you should start with these principles in mind.

When you need some guidance on how to define and measure project success, just download the Project Success Model here. 

Read more…

Project success and project failure are NOT absolutes

Project success and project failure are NOT absolutes. It may not be possible to be a little bit pregnant, but you can be a little bit successful.

Every project has multiple success criteria related to business results, product/service results, and project delivery results (cost, schedule, scope, and quality).

Some criteria are absolute, meaning they must be completed on or before the original planned date, and some are relative, meaning they must be completed by a date acceptable to the client.

Project success is determined by how many of your success criteria are satisfied, and how well.

Whether or not a project is successful depends on who you ask. The very happy project manager that implemented the SAP project as scoped on time and below budget (I know, this will NEVER happen), the end users who absolutely hate the complexity and slowness of the new system, and the COO that has seen IT costs double whilst none of the expected savings materialized may all have very different opinions on the success of the project.

Project success also depends on when you ask. Twelve months after go live the users will have a better grasp of the system and initial performance problems will have been solved. And slowly but steadily, the expected savings will often start to materialize as well.

So in order to determine the success or failure of your project, you should define all the criteria relevant to your project, define how you will measure them, and define when you will measure them.

When you need some guidance on how to define and measure project success, just download the Project Success Model here. 

Read more…