Monday, September 16, 2019

The Project Recovery Model – Recognition

The Project Recovery Model – Recognition
This is the second article in a series on the Project Recovery Model™, a proven approach for bringing troubled projects back to success. This article will be a deep dive into the Recognition of troubled projects.

Most of my work as a project recovery consultant is with what you can call "troubled projects." But what does this actually mean?

Many organizations I have worked with seem to be stuck in the Project Management Institute (PMI) view of things. The Project Management Body of Knowledge (PMBOK®) Guide defines the successful project as a project that meets its objectives in terms of quality, schedule, budget, and scope (and sometimes customer satisfaction), and considers a project a temporary endeavor undertaken to create a unique product, service, or result.

The guide does not define a troubled project but by taking the opposite of the above you can formulate a starting definition for troubled projects: “A troubled project is a project with overrun in quality, schedule, budget, and scope that exceeds the acceptable tolerance limit.”

The real meaning of trouble

In my opinion, the above definitions of successful and troubled projects are not useful because they only capture a very small part of what successful or troubled projects are. Project success should be defined across three levels:

1) Project delivery success is about defining the criteria by which the process of delivering the project is successful.

Essentially this addresses the classic triangle of scope, time, and budget. It is limited to the duration of the project and success can be measured as soon as the project is officially completed (with intermediary measures being taken, of course, as part of project control processes).

2) Product or service success is about defining the criteria by which the product or service delivered is deemed successful.

For example, the system is used by all users in scope, uptime is 99.99 percent, customer satisfaction has increased by 25 percent, operational costs have decreased by 15 percent, and so on.

These criteria need to be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured immediately at the end of the project itself.

3) Business success is about defining the criteria by which the product or service delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business.

For example, this could be financial value contribution (increased turnover, profit, etc.) or competitive advantage (market share won, technology advantage).

The PMI view only looks at the first level: project delivery success. Personally, I think this level matters very little if levels 2 and 3 are not met.

Another issue with focusing on level 1 is that you measure success against estimations. I can have the best team, doing the absolute best work for seven months, delivering great results for the client and company and still "fail" because some project manager without a clue about software development, without a team in place, and without a deep understanding of the client requirements decided that the scope could be delivered in four months.

A troubled project should be defined by the same three levels and key performance indicators (KPIs) as a successful project. Hence a troubled project can be defined as a project where the difference between what it is defined to be (your objectives and key results), and what it can be expected to be (your measurements and projections) exceeds the acceptable tolerance limits (your minimum and maximum values), pushing it into a course that will inevitably lead to failure.

A troubled project is a project where the difference between what it is defined to be, and what can be expected to be, exceeds the acceptable tolerance limits, pushing it into a course that will inevitably lead to failure.

Recognizing trouble

So now we have a definition for troubled projects, but how does this help me in recognizing, or even better, preventing one?

The PMI view on troubled projects is easy to implement and measure. As shown above, all project delivery success criteria can be measured during and directly at the end of a project, but product/service success and business success cannot. So we have to work with leading indicators and assumption validations in order to make meaningful measurements for those criteria during the project.

In project management, we often talk about “lagging” and “leading” indicators. Lagging indicators are typically output-oriented, easy to measure but hard to improve or influence. Leading indicators, on the other hand, are typically input-oriented, harder to measure but easier to influence.

Let me illustrate this with a simple example. Let's imagine you are responsible for managing a customer support team, and your goal is to resolve any high-priority incidents within 48 hours. Currently, you only succeed in 70 percent of such incidents.

The output is easy to measure: You either solve these incidents in 48 hours or not. But how do you influence the outcome? What are the activities you must undertake to achieve the desired outcome?

For instance: Make sure your team starts working on such incidents immediately when they occur. Make sure that incidents are assigned to the right people with the right skillset and that this person isn’t already overloaded with other work.

This could be translated into the following leading indicators:

> % of incidents not worked on for 2 hours

> % of open incidents older than 1 day

> % of incidents dispatched more than 3 times

> Average backlog of incidents per agent

When you start measuring these indicators on a daily basis and focus on improving these, I would think it is extremely likely to see an improvement in reaching your goal.

All the project success criteria on the three different levels discussed above are so-called lagging indicators. A lagging indicator is a measurable fact that records the actual performance of a project. They all represent facts about the project, the resulting product/service, and the benefits of it to the organization.

But things start to go wrong in a project well before the performance measure turns the traffic light on the scorecard red.

Using only metrics that measure past events is like driving while looking through the rear window. It’s easy to miss an opportunity or threat on the road ahead until you hit it.

Leading indicators for trouble

A leading indicator is a measurable factor that changes before the project starts to follow a particular pattern or trend. Leading indicators are used to predict changes in the project, but they are not always accurate.

Examples of leading indicators for a project’s success:

1) Poorly defined (or undefined) done: Project failure starts when we can’t tell what “done” looks like in any meaningful way. Without some agreement on our vision of “done,” we’ll never recognize it when it arrives, except when we’ve run out of time or money or both.

2) Poorly defined (or undefined) success: A project can only be successful if the success criteria are defined, ideally upfront. Therefore, the lack of these definitions on the three levels as described above is a great leading indicator for project trouble.

3) Stability, quality, and availability of project team: A lot of change in the project team is a good leading indicator for trouble. The same for missing skills and experience. Also, team atmosphere is a great leading indicator.

4) Engineering practices: The practices that are implemented are a good leading indicator of engineering quality.

5) Risk management: The presence or lack of risk management is a great leading indicator of the impact of negative surprises.

6) Availability of up-to-date RAID lists: The quality of these lists is a great indicator for awareness of trouble.

7) Engagement of stakeholders and steering committee: When the stakeholders do not care about your project, then why should you?

8) Runway: The burn rate of a project is a lagging indicator as it describes how money is spent (or lost) for any period of time. The runway is a leading indicator as it predicts how long the budget would last with a specific burn rate.

9) Milestones: Missing or achieving the deadline on a milestone is a lagging indicator. But it is also a leading indicator for the following milestones.

10) Project size: The bigger the project, the higher the probability it will fail.

All leading indicators can be used for identifying troubled projects before it is too late to do something about it. Just be aware that just because a leading indicator is positive, it does not mean the final outcome will be positive. Nor does a negative leading indicator automatically mean a negative outcome.

Trouble is not the same as a crisis

A troubled project is typically something that happens over time and because of some wrong decisions in the beginning and/or bad project management in the broadest sense. This is different from a sudden unexpected (or low-probability) event occurring and spiraling the project into a crisis. Why is this different? Because when the project was solid before the crisis, it will be solid again after the crisis is solved. In such a case there is no need for a project recovery manager, project review, etc.   

Here are some examples of project crises I have personally experienced:

> The sudden departure of the only person that could explain how that ancient legacy system works.

> The main supplier going suddenly bust because of a lost litigation case.

> The main supplier being bought by our biggest competitor.

> Discovering that your supplier oversold big time; the key system functionality that drives your business case does not exist, and will never exist.

> The whole external consultant team being poached by another competitor.

> Performance problems shortly after going live, so bad that complete teams were walking out of the building because they could not access their documents anymore.

The manner in which a project team, an organization, its executive team, and its board responds to and handles a project crisis will often determine the overall impact the crisis has.

In a nutshell: In project management, using only metrics that measure past events is like driving while looking through the rear window. It’s easy to miss an opportunity or threat on the road ahead until you hit it. And only when you have identified a project as in trouble can you start thinking about project recovery. It takes a great deal of political savvy and courage to recognize and admit that a key project is in serious trouble.

This is the second article in a series on the Project Recovery Model™, a proven approach for bringing troubled projects back to success. We'll be publishing more deep dives into the individual concepts of this model and their relationships. The next article will discuss Mandate.

Other articles in this series

Links will be added as soon as the corresponding article is published.

> The Project Recovery Model – An Introduction
> The Project Recovery Model – Recognition
> The Project Recovery Model – Mandate
> The Project Recovery Model – React
> The Project Recovery Model – Review
> The Project Recovery Model – Tradeoff & Negotiation
> The Project Recovery Model – Intervention
> The Project Recovery Model – Transition
> The Project Recovery Model – Conclusion

Read more…

Wednesday, September 11, 2019

Taking and giving responsibility as a project sponsor

Taking and giving responsibility as a project sponsor
Project governance is the serious business of taking responsibility for leadership.

The mindset of many executive sponsors toward projects is simple:

1) When you can, get it over with.

2) If at all possible, evade responsibility.

Which means that when things go wrong, project sponsors often offer a response that begins and ends with the words “It’s out of my control.”

However, there’s an alternative.

Taking responsibility

As a project sponsor, instead of defining the minimal requirements (accountability), outline the maximum possible action you can take (responsibility).

Successful projects and their benefits will not be achieved by organizations with executive sponsors that do the minimal requirements. The race is won by those that figure out what they can do, and do it.

Accountability is done to you. It’s done by the system, by those that want to create blame.

Responsibility is done by you. It’s voluntary. You can take as much of it as you want.

Giving responsibility

“Use your best judgment.”

Organizations have a very hard time saying this to their employees.

They create an endless series of scripts and rules, procedures that force people to not care. They promote the response “I’m just doing my job,” which is the precise opposite of “I see the problem and I’m going to fix it.”

As an organization hits a sufficient size, it will increase rules in order to decrease responsibility.

They’ve gotten big enough that they no longer trust the people who work for them.

In a way it's understandable, as there are only two choices available to any large organization:

1) Hire people who make no original decisions but be damn sure that if they are going to run by the book, the book better be perfect. And build in reviews to make sure that everyone is indeed playing by the book, with significant monitoring and consequences in place for when they don't.

2) Hire people who care and give them the freedom and responsibility to act. Hold people responsible for the decisions they make, and trust their judgment.

However, the only way to really deliver large and complex projects is to hire human beings who care … and to give them the authority and resources to demonstrate that.

Once you’ve got that, it’s pretty easy to get things done.

Promoting responsible project governance

Executive project sponsors are responsible for project governance and when their mentality is to avoid responsibility, the chances of project success decrease substantially. Similarly, when organizations don't show trust in those on their team and allow them the freedom to act, it fosters an environment of apathy.

The alternative is much more promising. Project sponsors can (and should) be truly invested in their work, caring deeply about the project and taking action when the need arises. Confident that they're backed by their organization and trusted to do what's best for the project, they do whatever it takes to keep it on track. This alternative lays a foundation that is conducive to project success.

In a nutshell: Large and complex projects need people that take responsibility … and organizations that give them the ability to do so.  

Read more…

Tuesday, September 10, 2019

Case Study: The $2.5 billion cross-border expansion mistake by Target

Case Study: The 2.5 billion dollar cross-border expansion mistake by Target
Less than two years after entering Canada, Target shocked the retail world by pulling out. After accumulating $2.5 billion in losses, the Minneapolis-based company shut down all of its 133 Canadian locations and laid off 17,600 employees.

In a blog post, Brian Cornell, Target’s chairman and CEO, said the decision to exit Canada was the best option available to the company. “After extensive internal due diligence and research, paired with counsel from outside experts, we fulfilled our obligation to do what was right for our company and our shareholders, and made the decision to exit Canada,” he wrote.

Target is one of America's largest and most successful retailers. The 114-year-old company that evolved out of the old Dayton-Hudson Corporation now has more than 1,800 retail locations.

What most Americans with three Target stores right in their neighborhood don’t realize is that Target isn't a worldwide thing. Walmart, by contrast, operates over 11,000 stores in 28 countries. Walmart is a $465 billion company. Target is a $72 billion company, certainly not small potatoes. But Target, it seems, wanted to be more like Walmart.

Target was a careful, analytical and efficient organization with a highly admired corporate culture. The corporation’s entry into Canada was uncharacteristically bold—not just for Target, but for any retailer. Under Gregg Steinhafel (Target’s CEO at the time), the company paid $1.8 billion for the leases to the entire Zellers department store chain in 2011 and formulated a plan to open 124 locations by the end of 2013. Not only that, but the chain expected to be profitable within its first year of operations.

That should have been easy, right? After all, Americans and Canadians speak the same language (ignoring the French-speaking Québécois) and most Americans somehow seem to think of Canada as their 51st, more polite, colder state to the north.

But it's not that simple. Take these two factors as an example. Canada has a different currency. Sure, it uses dollars, but at the time of this writing a Canadian dollar is worth only 72 percent of an American dollar. That conversion rate is constantly fluctuating. Also, Canada uses the metric system. To the people in the U.S., a 2-foot deep shelf is a 2-foot deep shelf. In Canada, that shelf is 60.96 centimeters.

You can already begin to see the IT challenges, can't you?

An inventory system that was set up to handle U.S. dollars would need to be updated to handle Canadian dollars. If the system didn't already have a currency field, that would need to be added throughout. Conversion methods would need to be added. And, for an inventory management system that has to fill shelves, knowing the size of product packaging would be important. Software that calculates area for placement would have to be modified to handle multiple measurements and measurement systems.

Add to that issues of sourcing of products and pricing. The products don't all just come from the U.S. A box of small widgets in the U.S. might be 12 inches tall. But that same product packaged for the Canadian market might only be 11 1/2 inches tall, or whatever that might translate to in centimeters.

You get the idea. Internationalizing an IT system is a lot of work. For an IT system tracking the amount of data that an enterprise the size of Target needs, you're talking about a lot of development and customization.

But let’s start from the beginning.

To download all my Project Failure Case Studies in a single eBook just click on the image.

Timeline of events


Everything started with Richard Baker, the executive chairman of Hudson’s Bay Co. (HBC). Although Baker is a retail executive, he is, at heart, a real estate man. His maternal grandfather started buying and selling real estate in New York City in 1932 and helped pioneer the concept of shopping malls. Baker’s greatest business insight was to recognize the value of the property developed by both his grandfather and his father. In the 1990s, he started selling some of it off to various companies, including Walmart.

That relationship proved fortuitous in late 2010, when Walmart approached him and offered to buy the Zellers chain from HBC. Baker realized there was more value to Zellers’ real estate than to the operation itself, since Walmart had soundly beaten the brand. An astute dealmaker, Baker and his team reached out to Target to stoke the company’s interest.

It was an open secret that Target was interested in the Canadian market. But the company had previously decided it wanted to grow as quickly as possible if it were to enter Canada, rather than pursue a slow, piecemeal expansion. The challenge was in acquiring enough real estate to make that possible. The Zellers sale provided just such an opportunity. After Baker’s team let Target know Zellers was on the block—and Walmart was interested—the American company acted quickly to finalize its own offer.


Walmart would eventually back out, but Target put down $1.8 billion. Steinhafel bought everything, essentially committing the company to opening stores as quickly as possible to avoid paying rent on stores that weren’t operational and leaving landlords without anchor tenants. The price Steinhafel paid raised eyebrows. “When the numbers got up as high as they did, we found that pretty surprising,” says Mark Foote, the CEO of Zellers at the time.

Almost immediately after signing the deal, employees in Minneapolis were seconded to work on the Canadian launch. It was considered a privilege to be recruited. “The company was pouring in resources left, right and sideways, so it was palpably exciting in Minneapolis,” says a former employee.

Early 2012

By early 2012, with the planned opening still a year away, the nerve center for the Canadian launch had moved from Minneapolis to Mississauga, Ontario, and waves of American expats settled up north. Hiring was a top priority.

Fall 2012

Strange things started happening in 2012, once ordering began for the pending launch. Items with long lead times coming from overseas were stalled—products weren’t fitting into shipping containers as expected, or tariff codes were missing or incomplete. Merchandise that made it to a distribution center couldn’t be processed for shipping to a store. Other items didn't fit properly onto store shelves. What initially appeared to be isolated fires quickly became a raging inferno threatening to destroy the company’s supply chain. It didn’t take long for Target to figure out the underlying cause of the breakdown: The data contained within the company’s supply chain software, which governs the movement of inventory, was riddled with flaws.

Thus, “data week” was held in the fall of 2012. Merchandisers essentially had to confirm every data point for every product with their vendors. A buyer might have 1,500 products and 50 to 80 fields to check for each one. The more experienced employees had the foresight to keep records of verified information (dubbed “sources of truth”), which made the task a little easier. Others weren’t so lucky.

Complicating matters was the dummy information entered into the system when SAP was set up. That dummy data was still there, confusing the system, and it had to be expunged. “We actually sat there and went through every line of data manually,” says a former employee. “It was terrible.” Target anticipated how awful it would be and designed the week to help keep employees sane. To kick it off and rally spirits, a few employees performed a hip-hop song-and-dance routine on the first day. Ice cream and pizza flooded in to keep employees fueled up; some stayed at work well past midnight that week, squinting at screens through bleary eyes.

February 2013

The grand opening of Target Canada was set to begin in one month, and they needed to know whether the company was actually ready. In February 2013, about a dozen senior-level employees gathered at the company’s Mississauga headquarters to offer updates on the state of their departments. Tony Fisher, Target Canada’s president, was holding these meetings every day as the launch date crept closer. The news was rarely good.

The news at this particular meeting was no different. The company was having trouble moving products from its cavernous distribution centers and onto store shelves, which would leave Target outlets poorly stocked. The checkout system was glitchy and didn’t process transactions properly. Worse, the technology governing inventory and sales was new to the organization; no one seemed to fully understand how it all worked.

The 750 employees at the Mississauga head office had worked furiously for a year to get up and running, and nerves were beginning to fray. Three test stores were slated to open at the beginning of March, followed shortly by another 21. A decision had to be made, and they made it. They opted to go ahead.

March 2013

On March 4, 2013, Tony Fisher led a gaggle of reporters through a new Target location in Guelph, Ontario. The store officially opened the next day, along with two others in the province.

The company had been teasing consumers for a year at this point, starting with a pop-up shop in Toronto featuring designer Jason Wu. There had also been a high-profile ad during the Academy Awards to hype the Canadian launch, and actors Sarah Jessica Parker and Blake Lively were lined up to appear at the grand opening.

Workers were still stocking shelves at the time, and signs throughout the store read, “We’re open (mostly).” The three Ontario stores were part of Target’s soft launch, and the company explained in a press release that the goal was to use them to iron out kinks and “determine operational readiness” before opening 21 more locations as part of its official launch that month.

Fall 2013

In the fall of 2013, hundreds of Target Canada head office staff piled into the auditorium at the Mississauga Living Arts Centre for a state-of-the-union address from their leaders. The employees were weary and frustrated by this point. The bulk of the 124 stores had opened, and it was clear the launch had gone seriously awry.

Consumers were frustrated when confronted with empty shelves, and the media and financial analysts were hammering the company for it. On stage, Fisher stated his conviction that Target Canada was making progress and that 2014 would be a greatly improved year.

A Q&A session followed; one employee bravely asked Fisher what he would do differently if he could do the launch over again. A man in the front row stood up and offered to field the question. Taking the microphone, Steinhafel, Target’s CEO, didn’t hesitate with his answer: He would renegotiate the real estate deal that facilitated the company coming to Canada in the first place.

February 2014

In February 2014 Target headquarters released its annual results, revealing a US$941-million loss in Canada. The company attributed the shortfall to growing pains, expansion costs and—because of all that excess inventory sitting in warehouses—significant markdowns. “As we enter 2014 with a much cleaner inventory position, the team’s number one operation focus is on in-stocks—ensuring we have the right quantity of each item in the right place at the right time,” Steinhafel said on the earnings call.

It was his last as Target CEO. A month prior, Target had disclosed a massive security breach in which hackers stole the personal information of 70 million customers in the U.S. Combined with the bleeding operations in Target Canada, Steinhafel’s position was untenable, and he stepped down in May. (He walked away with US$61 million in compensation.) Fisher, who was hand-picked by Steinhafel, left the company two weeks later. Mark Schindele was his replacement.

June 2014

Target Canada released an apology on YouTube; the video featured employees and executives reflecting on the challenges of the first year and confessing to their sins. “Maybe we didn’t put our best foot forward when we entered into Canada,” said Damien Liddle, the company’s senior corporate counsel. “Certainly we know we’ve disappointed our Canadian guests.” The video was remarkably candid as far as corporate mea culpas go but maintained an optimistic note. “We’re headed in the right direction now,” said another employee in the video. “For sure.”

December 2014

Target employees were beginning to feel like there was a light at the end of the tunnel. The company had a much better handle on its technology, its data and the supply chain, and every day no longer felt like a crisis. Target Canada was at last transitioning into a functional—almost normal—retailer. There were even big plans for 2015, such as implementing online shopping at

January 2015

The news on January 15, 2015 was much different: Target Canada was filing for bankruptcy protection. It had spent $7 billion on the expansion so far, and it didn’t project turning a profit until at least 2021. Early that morning, Schindele’s direct reports broke the news to their teams, who then informed their own departments. A press release went out at 8 a.m. By then, the entire company knew.

All 133 Canadian stores closed by April.

What went wrong 

Data quality

It didn’t take long for Target to figure out the underlying cause of the supply chain breakdown in 2012: The data contained within the company’s supply chain software, which governs the movement of inventory, was riddled with flaws. At the very start, an untold number of mistakes were made, and the company spent months trying to recover from them.

In order to stock products, the company had to enter information about each item into SAP. There could be dozens of fields for a single product. For a single product, such as a blender, there might be fields for the manufacturer, the model, the UPC, the dimensions, the weight, how many can fit into a case for shipping and so on. Typically, this information is retrieved from vendors before Target employees put it into SAP. The system requires correct data to function properly and ensure products move as anticipated.

A team assigned to investigate the problem discovered an astounding number of errors. Product dimensions would be in inches, not centimeters or entered in the wrong order: width by height by length, instead of, say, length by width by height. Sometimes the wrong currency was used. Item descriptions were vague. Important information was missing. There were myriad typos. “You name it, it was wrong,” says a former employee. “It was a disaster.”

It was also something the company should have seen coming. The rush to launch meant merchandisers were under pressure to enter information for roughly 75,000 different products into SAP according to a rigid implementation schedule. Getting the details from suppliers largely fell on the young merchandising assistants. In the industry, information from vendors is notoriously unreliable, but merchandising assistants were often not experienced enough to challenge vendors on the accuracy of the product information they provided. (The staff were also working against the countdown to opening.)

“There was never any talk about accuracy,” says a former employee. “You had these people we hired, straight out of school, pressured to do this insane amount of data entry, and nobody told them it had to be right.” Worse, the company hadn’t built a safety net into SAP at this point; the system couldn’t notify users about data entry errors. The investigative team estimated information in the system was accurate about 30 percent of the time. In the U.S., it’s between 98 and 99 percent. (Accenture, which Target hired as a consultant on SAP, said in a statement: “Accenture completed a successful SAP implementation for Target in Canada. The project was reviewed independently and such review concluded that there is no Accenture connection with the issues you refer to.”)

Data loading

There was an entirely different process to ensure the correct data actually made it into SAP. The employees in Mississauga couldn’t add it directly. Instead, the information was sent to a Target office in India, where staff would load it into SAP. Extra contractors had to be hired in India, too. “Sometimes even when we had the data correct, it got mixed up by the contractors in Target India,” says a former employee. (Another former employee disputes this: “Sometimes the quality of their work wasn’t so great, but for the most part they did a good job.”) In any event, uploading took longer than expected, and data week stretched into two. Periodic data blitzes in individual departments became common into the following year.

Empty shelves

The foot traffic in the early days was higher than expected, which was encouraging, but it didn’t take long for consumers to start complaining on social media about empty shelves. “Target in Guelph, please stock up and fill the shelves,” wrote one aggrieved shopper on Facebook. “How can I or anyone purchase if there is nothing left for me to buy?” Target told the media that it was overwhelmed by demand and made assurances that it was improving the accuracy of product deliveries.

The reality was that Target was still struggling with data quality problems that were hampering the supply chain, and it didn’t have time to address the root causes before opening another wave of stores. Problems multiplied, and the public mood continued to turn against Target. Consumers soured on the brand when confronted with empty shelves—the exact scenario some senior employees warned of earlier in the year.

Stock overflow

Ironically, even as consumers encountered barely stocked stores, Target’s distribution centers were bursting with products. Target Canada had ordered way more stock than it could actually sell. The company had purchased a sophisticated forecasting and replenishment system made by a firm called JDA Software, but it wasn’t particularly useful at the outset, requiring years of historical data to actually provide meaningful sales forecasts. When the buying team was preparing for store openings, it instead relied on wildly optimistic projections developed at U.S. headquarters.

According to someone with knowledge of the forecasting process in Minneapolis, the company treated Canadian locations the same way they did operational stores in the U.S. and not as newcomers that would have to draw consumers away from rival retailers. Even if the stores were in out-of-the-way spots—and some of the locations in the Zellers portfolio certainly were—the company assumed the strength of the Target brand would lure customers. There was another element at play, too. “Once you signed up to do 124 Zellers locations, it felt like there was a point where it’s like we have to assume sales will be good,” says the former employee. “It’s very backwards.”

Distribution problems

The distribution depots were hampered by other factors caused by lingering data problems and the learning curve associated with the new systems. Manhattan, the company’s warehouse software, and SAP weren’t communicating properly. Sometimes, the issues concerned dimensions and quantities. An employee at headquarters might have ordered 1,000 toothbrushes and mistakenly entered into SAP that the shipment would arrive in a case pack containing 10 boxes of 100 toothbrushes each. But the shipment might actually be configured differently—four larger boxes of 250 toothbrushes, for example.

As a result, that shipment wouldn’t exist within the distribution center’s software and couldn’t be processed. It would get set aside in what was designated as the “problem area.” These sorts of hang-ups happen at any warehouse, but at Target Canada, they happened with alarming frequency. Warehouse workers got so desperate to move shipments they would sometimes slice open a crate that was supposed to contain, say, a dozen boxes of paper towels but only had 10, stuff in two more boxes, tape it shut and send it to a store that way.

Malfunctioning point-of-sale system

To add even more headaches, the point-of-sale system was malfunctioning. The self-checkouts gave incorrect change. The cash terminals took unusually long to boot up and sometimes froze. Items wouldn’t scan, or the POS returned the incorrect price. Sometimes a transaction would appear to complete, and the customer would leave the store—but the payment never actually went through. The POS package was purchased from an Israeli company called Retalix, which worked closely with Target Canada to address the issues.

Progress was maddeningly slow. In 2014, a Retalix team flew to Toronto to see first-hand what Target was dealing with. After touring a store, one of the Retalix executives remarked, “I don’t understand how you’re using this,” apparently baffled the retailer managed to keep going with so many bugs. But Target didn’t have time to find a new vendor and deploy another technology. “We were bound to this one bad decision,” says a former employee. (Retalix was purchased in 2012 by NCR Corp., the American global payment transaction firm.)

“When entering a new country, it is normal for retail software systems to require updates to tailor the solution to market needs and processes,” NCR said in a statement in response to questions about Target’s experience. “NCR was making progress to customize the solution for the market and Target’s new operations until their decision to exit the country.”

Gaming the system

A small group of employees also made an alarming discovery that helped explain why certain items appeared to be in stock at headquarters but were actually missing from stores. Within the chain’s replenishment system was a feature that notified the distribution centers to ship more product when a store runs out. Some of the business analysts responsible for this function, however, were turning it off—on purpose. Target's business analysts (who were young and fresh out of school, remember) were judged based on the percentage of their products that were in stock at any given time, and a low percentage would result in a phone call from a vice-president demanding an explanation.

But by flipping the auto-replenishment switch off, the system wouldn’t report an item as out of stock, so the analyst’s numbers would look good on paper. “They figured out how to game the system,” says a former employee. “They didn’t want to get in trouble and they didn’t really understand the implications.” Two people involved in the discovery allow that human error may have been a component, too. Like SAP, the replenishment software was brand new to Target, and the company didn’t fully understand how to use it.

When Schindele was told of the problem, he ordered the function to be fully activated, which revealed for the first time the company’s pitifully low in-stock percentages. From there, a team built a tool that reported when the system was turned on or off, and determined whether there was a legitimate reason for it to be turned off, such as if the item was seasonal. Access to the controls was taken away from the analysts, depending on the product.

How Target could have done things differently

The obvious recurring theme through all problems and wrong decisions with Target's entry into Canada is the immense time pressure. From the very beginning, a clock was ticking … and that clock was absurd. The company did everything it could to remove barriers that might slow progress and to ensure decisions could be made quickly. Timelines were hugely compressed. Building a new distribution center from scratch, for example, might take a few years. Target was going to do it in less than two years—and it planned to construct three of them. Introducing a new SAP system within two years? Hiring and training 15,000 employees? They never had a chance.

But aside from the obvious there are some additional lessons learned in this story.


One of the most important decisions Target made concerned technology—the systems that allow the company to order products from vendors, process goods through warehouses and get them onto store shelves promptly. In the U.S., Target used custom technology that had been fine-tuned over the years to meet its exacting needs, and the corporation had developed a deep well of knowledge around how these systems functioned. Target faced a choice: Was it better to extend that existing technology to Canada or buy a completely new, off-the-shelf system?

Finding an answer was tricky. By using Target’s existing technology, employees in Canada could draw on the large amount of expertise in the U.S. That plan had shortcomings as well. The technology was not set up to deal with a foreign country, and it would have to be customized to take into account the Canadian dollar and even French-language characters. Those changes would take time—which Target did not have. A ready-made solution could be implemented faster, even if the company had little expertise in actually using it.

The team responsible for the decision went with SAP. Considered the gold standard in retail, SAP is used by many companies around the world, from Indigo in Canada to Denmark’s Dansk supermarket chain. It essentially serves as a retailer’s brain, storing huge amounts of data related to every single product in stores. That data would be fed by SAP into Target’s other crucial systems: software to forecast demand for products and replenish stocks, and a separate program for managing the distribution centers. After implementing SAP in Canada, Target wanted to eventually switch the U.S. operations over as well, aligning the two countries and ensuring the entire company benefited from the latest technology.

While SAP might be considered best-in-class, it’s an ornery, unforgiving beast. Sobeys introduced a version of SAP in 1996 and abandoned the effort by 2000. (It wasn’t until 2004 that the grocery chain tried again.) Similarly, Loblaws started moving to SAP in 2007 and projected three to five years to get it done. The implementation took two years longer than expected because of unreliable data in the system. Target was again seeking to do the impossible: It was going to set up and run SAP in roughly two years.

The company wasn’t doing it alone, however, and hired Accenture (which also worked on Loblaws’ integration) as the lead consultant on the project. Target believed the problems other retailers faced were due to errors in data conversion. Those companies were essentially taking information from their existing systems and translating it for SAP, a messy process in which it’s easy to make mistakes. Target, on the other hand, was starting fresh. There was no data to convert, only new information to input.


Target has a unique, well-established corporate culture in the U.S., which the company views as one of the reasons for its success, and leaders sought to replicate that environment in Canada. Target describes itself as “fast, fun and friendly” to work for and it’s a place where attitude and soft skills are of equal—if not more—importance to experience. “Target’s motto was they could train you for the job, but they couldn’t train culture,” says a former employee.

In the U.S., the company prides itself on its development programs for even junior positions like business analysts, who help coordinate the flow of product, and merchandising assistants, who work with buyers to choose which products to stock and negotiate costs with vendors. Target typically recruits candidates for these positions straight out of school and prepares them for a career in retail. That’s how Tony Fisher got his start—he joined the company as an analyst in 1999, after he was drafted by the Texas Rangers baseball organization and played for two years in the minor leagues. Young employees receive months of instruction and are paired with a mentor. Hiring for culture over experience works, essentially, because Target in the U.S. provides ample training.

In Canada, the company succeeded in hiring people with the right personalities, but young staff received only a few weeks of training, according to former employees who worked at Target in both countries. The Canadian team lacked the institutional knowledge and time to properly mentor the new hires. “Everyone was stretched thin. We didn’t have the manpower to get everything done in the time frame that was laid out,” says a former employee. Another was surprised to see how green his colleagues were. “I was one of the older people there, and I was in my mid-30s,” he says.

Target Canada would eventually learn what happens when inexperienced employees working under a tight timeline are expected to launch a retailer using technology that nobody—not even at the U.S. headquarters—really understood.

Delay market entry

Fisher, 38 years old at the time, was regarded as a wunderkind who had quickly risen through the ranks at Target’s American command post in Minneapolis, from a lowly business analyst to leader of a team of 400 people across multiple divisions. Launching the Target brand in a new country was his biggest task to date. The news he received from his group that afternoon in February 2013 should have been worrying, but if he was unnerved, Fisher didn’t let on. He listened patiently as two people in the room strongly expressed reticence about opening stores on the existing timetable.

Their concern was that with severe supply chain problems and stores facing the prospect of patchy or empty shelves, Target would blow its first date with Canadian consumers. Still, neither one outright advocated that the company push back its plans. “Nobody wanted to be the one to say, ‘This is a disaster,’” says a former employee. But by highlighting the risks of opening now, the senior employees’ hope was that Fisher would tell his boss back in Minneapolis, Target CEO Gregg Steinhafel, that they needed more time.

The magnitude of what was at stake began weighing on some of those senior officials. “I remember wanting to vomit,” recalls one participant. Nobody disagreed with the negative assessment—everyone was well aware of Target’s operational problems—but there was still a strong sense of optimism among the leaders, many of whom were U.S. expats. The mentality, according to one former employee, was, “If there’s any team in retail that can turn this thing around, it’s us.”

The group was riding a wave of momentum, in fact. They had overcome seemingly endless hurdles and worked grueling hours to get to this point, and they knew there were costs to delaying. The former employee says the meeting ultimately concerned much more than when to open the first few stores; it was about the entirety of Target’s Canadian launch. Postponement would mean pushing back even more store openings. Everyone else in attendance expressed confidence in sticking to the schedule, and by the time the meeting concluded, it was clear the doors would open as promised. “That was the biggest mistake we could have made,” says the former employee.

Closing thoughts 

To say that Target had unrealistic and highly optimistic growth plans for its entry into Canada would be an understatement—in 2011 the company had plans to open 124 locations by the end of 2013 with the expectation that the Canadian company would be profitable within its first year of operations. Not to mention that they also intended to build three new distribution centers in less than two years—a feat that typically takes a couple of years per center. The end result was that Target Canada filed for bankruptcy, wasted billions of dollars, tarnished its reputation and left approximately 17,600 people without jobs. In most cases, this would have completely destroyed a company’s chances of surviving and Target has been lucky to continue to see success among its U.S. stores.

In a nutshell: Unmanageable deadlines and disastrous IT wrecked this top U.S. retailer's attempt at international expansion. Just another proof that nowadays technology can make or break an enterprise.

Other project failure case studies

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

> To download all my Project Failure Case Studies in a single eBook just click on the image.


> Dahlhoff, D. (2015). Why Target’s Canadian Expansion Failed. [online] Harvard Business Review. Available at:

> Wahba, P. (2015). Why Target failed in Canada. [online] Fortune. Available at:

> Joe Castaldo (2015). The last days of Target. [online] Canadian Business. Available at:

Read more…

Monday, September 09, 2019

The Project Recovery Model - An Introduction

The Project Recovery Model
Recovery of troubled projects is a combination of art, science, and craft.

Many have tried to translate project recovery in a “fits all” framework, methodology or process. After more than a decade of doing project recoveries, I’m of the opinion that this is a futile exercise. The reality is just different.

What has really helped me over all these years is something a little different: a conceptual model of a project recovery and the steps it typically goes through.

The Project Recovery Model ™ is such a conceptual model. Where a mental model captures ideas in a problem domain, a conceptual model represents 'concepts' and relationships between them.

A conceptual model in the field of computer science is also known as a domain model. The aim of a conceptual model is to express the meaning of terms and concepts used by domain experts to discuss the problem and to find the correct relationships between different concepts.

A conceptual model acts as a key artifact of business understanding and clarity. The concepts of the conceptual model can be mapped into actual implementations that will be different for each organization and project.

The Project Recovery Model ™ contains eight concepts (or steps). Each one has a relationship with the others.

1) Outcome
2) Recognition
3) Mandate
4) React
5) Review
6) Tradeoff & Negotiation
7) Intervention
8) Transition

The diagram below offers a visual representation of the model.

You cannot put “gates” into this series of steps. Their relationships are fluent. One step will most likely not be completed before you will have to start the next one.

Now that we've looked at the Project Recovery Model ™ in a broad sense, let’s take a closer look at each concept.


A project recovery can have only three possible outcomes:

1) Delivery of the project without significant changes in scope, time and/or costs. This is very rare and only possible when trouble is identified early and action is taken immediately.

2) Delivery of the project with significant changes in scope, time and/or costs. There will be an impact on the business case.

3) Termination of the project because costs and benefits or value are no longer aligned. Note that termination does not necessarily mean that everything done up to this point should be written off as sunk costs. Some parts might be salvageable.


As soon as a project is identified as in trouble you can start thinking about project recovery. Identifying a problem project as such is a very important precondition for any successful project recovery. It takes a great deal of political savvy and courage to recognize and admit that a key project is in serious trouble.


The purpose of a mandate is simple. Obtaining executive support for a project recovery attempt by appointing a project recovery manager and releasing budget for such an attempt.

The mandate of the project recovery manager should be defined clearly, and he/she needs strong executive support, especially when the recovery manager is working with the current (or new) project manager instead of replacing him/her.

The project recovery manager can be an internal role, but there are a number of good reasons to hire an external project recovery manager.


You cannot ignore that the project is ongoing while you start the recovery. It takes time to get to a solution, but it is also necessary to limit spending on a failing project. You have two options.

1) Halt the project
2) Curb the bleeding


The review is a critical assessment of the project's existing status. You will look at what went wrong and what can be corrected rather than looking for someone to blame. A project review is all about the probability of project success. A review will give you a good understanding of the current status of the project and how it is on track to deliver against your definition of project success on three levels:

1) Project delivery success
2) Product or service success
3) Business success

Tradeoff & Negotiation

As soon as you have the necessary information for decision making as well as the team's support for the recovery you can start negotiating. It will be highly unlikely that the original requirements can still be met without some serious tradeoffs. You must now work with the team and determine the tradeoff options that you will present to your project sponsor and other stakeholders. The goal is to redefine (and agree on) your project success criteria on the aforementioned three levels.


Assuming the sponsor and stakeholders have agreed to new success criteria, and approved a recovery plan on how to achieve them, you are now ready to start intervention of the project. This means, among other things:

> Briefing the team on the outcome of the negotiations

> Making sure the team learns from past mistakes

> Introducing the team to the agreed-upon recovery plan including the agreed-upon milestones

> Introducing any changes to the way the project will be managed

> Fully engaging the project sponsor as well as the key stakeholders for their support

> Identifying any changes to the roles and responsibilities of the team members

> Restoring team confidence


As soon as the project is in a normal state again the project recovery manager (when he/she does not have the project manager role) can transfer the responsibility for the recovered project and close the recovery. When the project recovery manager also has the role of project manager he/she can decide to close the recovery and manage the project as if it was a freshly started project or keep the project in recovery mode until the project is delivered.

Closing thoughts

This is the first article in a series on the Project Recovery Model ™, a proven approach for bringing troubled projects back to success. Future articles will be deep-dives into the individual concepts of this model and their relationships. The next article will discuss Recognition.

Other articles in this series

Links will be added as soon as the corresponding article is published.

> The Project Recovery Model – An Introduction
> The Project Recovery Model – Recognition
> The Project Recovery Model – Mandate
> The Project Recovery Model – React
> The Project Recovery Model – Review
> The Project Recovery Model – Tradeoff & Negotiation
> The Project Recovery Model – Intervention
> The Project Recovery Model – Transition
> The Project Recovery Model – Conclusion

Read more…

Sunday, September 08, 2019

Escalation of commitment (or why you should ignore sunk costs)

Escalation of commitment (or why you should ignore sunk costs)
Escalation of commitment is a human behavior pattern in which an individual or group facing increasingly negative outcomes from a decision, action, or investment nevertheless continues the behavior instead of altering course. People maintain behaviors that are irrational, but align with previous decisions and actions.

Economists and behavioral scientists use a related term, sunk-cost fallacy, to describe the justification of increased investment of money or effort in a decision, based on the cumulative prior investment ("sunk cost") despite new evidence suggesting that the future cost of continuing the behavior outweighs the expected benefit.

This is probably the most important decision-making rule you learn in business school, yet it is still largely misunderstood in the real world.

When making a choice between two options, it's imperative that you only consider what’s going to happen in the future, not which investments you’ve made in the past. The past investments are over, lost, gone forever. They are irrelevant to the future.

For example, say you have two office buildings. One you've bought for $1 million, and one for $10 million. You want to move all your people into one of these buildings. Which one should you pick?

I know. The one that’s right next to the railway station and has enough parking space, not the one in the city center that is so hard to reach. Does it matter how much the office cost to buy? No. Not at all.

Now imagine you and your team have worked for months on a deal to buy another company. They were really hard to work with. You spent countless hours analyzing, reviewing, and negotiating contracts.

On your way to the lawyer's office to sign the deal, another company calls you and offers you double the amount to buy the other company from you. Should you sell?

The answer is yes. The amount of time you spent getting the deal is irrelevant. If you wouldn’t be willing to PAY double for this company (and you weren’t, or you would have) then you should be willing to SELL it immediately. Spend some money on a party for the team and go find a new and better deal for your company.

Or say you make a mistake and keep the company instead of selling (the company cost you double now). Down the road, the deal turns out not to bring you the benefits you expected. You don’t like them so much now. But you paid double for the deal! Should you keep the company, or sell?

What do you think?

The business world is fraught with examples of escalated commitment that could have—and should have—been avoided, resulting in unnecessary losses. Just because the team spent a lot on the new ERP system doesn’t mean they shouldn’t spend more to make it actually work. The amount they already spent is irrelevant. What matters is what the benefit of a properly working ERP system will be.

In a nutshell: You should ignore sunk costs.

Read more…

Tuesday, September 03, 2019

Agile is not the answer to all your failed software development projects

Agile is not the answer to all your failed software development projects
Agile means many things to many people. I believe that the simple high-level Agile Manifesto is close to the way most engineers think about software development. Here's a quick rundown:

> Individuals and interactions over processes and tools
> Working software over comprehensive documentation
> Customer collaboration over contract negotiation
> Responding to change over following a plan

However, once you get past these high-level ideas into the details, the agreement starts to fade. Agile has some good ideas but it also has problematic elements which are too centered around short-term thinking to work on large and complex engineering projects done not only at huge companies like Google, Amazon and Microsoft, but also in non-tech industries. For example, this could include building a core banking system, a high-frequency trading platform, a drug discovery system, or ERP software.

Without getting buried in details, let’s look at some of the principles behind the Agile Manifesto.

> Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

> The best architectures, requirements, and designs emerge from self-organizing teams.

> At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

> Continuous attention to technical excellence and good design enhances agility.

> Simplicity — the art of maximizing the amount of work not done — is essential.

These principles are almost common sense for smart engineers, and have been known and applied for years. NASA of the sixties, I am looking at you now.

However, there are other parts of the principles which are not a part of a healthy large and complex project development culture. These are the parts which have led to the short-term-focused Scrum process. They seem suited to particular types of development, most notably consulting or contract programming, where the customer is external to the organizations, runs the show because they are paying for development, and can change their mind at any time:

> Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

> Business people and developers must work together daily throughout the project. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

> Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This style of short-term planning, direct customer contact, and continuous iteration is well suited to software with a simple core and lots of customer-visible features that are incrementally useful.

It is not so well suited to software which has a very simple interface and tons of hidden internal complexity, software which isn’t useful until it’s fairly complete, or leapfrog solutions the customer can’t imagine.

Companies like Google, Microsoft and Amazon write revolutionary software which has never been written before, and which doesn’t work until complex subcomponents are written.

This type of innovation takes significant up-front design time, and requires working on components over longer periods than one-week iterations. Because the projects have such simple external interfaces and so much internal complexity, much of the work is not even visible to “customers,” so there is no way to write customer-visible stories about it. With this type of software it takes 9–24 months to deliver the first working version to the customer.

Projects like this are the anti-Scrum. They represent extremely long-term thinking on the part of the technical leaders. Instead of working on something that would meet a small need this week, they were laying a foundation for a fundamental shift in the way cluster software was developed. That investment has not only reaped incredible rewards at Google, Microsoft and Amazon, but has influenced the entire industry.

Other industries have similar analogs. From tax-accounting software to computer games, some software is not suited to give to end customers when partially finished.

If I was asked to rewrite the above Agile principles to be more in-line with large and complex style software development, they might look something like this:

> Our highest priority is to increase customer (and programmer) productivity and access to information. Work on the biggest, most frequently used problems you can find, and create the largest net impact. Don’t give the customer what they ask for; understand them, and revolutionize their world.

> Developers should create a project charter (a fairly minimal but structured design doc), detailing the project, outlining what goals it hopes to achieve, and explaining why it can’t be done in other ways. This document should be circulated with stakeholders to get early feedback before the project gets underway. The written record is essential, as it assures there is a clear and agreed understanding of when the project is a success and how it aims to get there.

> At all phases of the project, critical design elements for larger components should be concisely explained and captured in a design document.

> Innovate in leapfrogs. It’s more important to finish and deploy a leapfrog than to attempt perfection. There is no perfection. Instead, be flexible and plan to constantly reinvent at every level of the stack.

> Deliver working software as soon as is reasonably possible, and no sooner. “Dogfood” projects internally before they are shipped externally. Make sure products meet high quality standards before shipping. The quality of the product is more important than the time it takes to achieve it.

While the high-level Agile Manifesto is flexible enough to work with these principles, these are very different than the short-iteration, low-documentation Scrum/SAFe/LeSS/Nexus/DAD processes that have become synonymous with the word "Agile."

Starting with an understanding of what you are actually doing, the people you are working with, the things you are working with to get work done, and why you are doing it, should be the first priority, not starting by choosing a framework or process.

The biggest problem I am seeing is that people have made “Agile” the goal, worrying about “doing Agile right” before actually understanding the problem they are trying to solve and/or the opportunity they are trying to explore. They take it as a given that Agile is the right approach for the project, before the project is even defined.

In a nutshell: We should all start with an understanding of where we want to go before we figure out how we want to get there … not the reverse.

Read more…

Tuesday, August 27, 2019

How to champion your project

How to champion your project
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…

Monday, August 26, 2019


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.

OKRs 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.

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

The Project Success Model

Read more…

Monday, August 19, 2019

The modern project charter

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:

> Reality
> Assumptions
> Success
> Alternatives
> People
> Money

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.

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.

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.

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.

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.

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 assumptions, success, alternatives, people, and money in a project charter.

Read more…

Sunday, August 18, 2019

Misunderstanding the project sponsor role isn't the only problem

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…

Monday, August 05, 2019

Why your organization doesn't learn from its Lessons Learned

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…

Sunday, August 04, 2019

Case Study: How Revlon got sued by its own shareholders because of a failed SAP implementation

Case Study: How Revlon got sued by its 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?

To download all my Project Failure Case Studies in a single eBook just click on the image.

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

Other project failure case studies

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

> To download all my Project Failure Case Studies in a single eBook just click on the image.


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

REVLON, INC., Form 10Q




Read more…