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…