Sunken Costs

At every company I have been at, there is always at least one project that has come off the tracks, spinning completely out of control. There are lots of reasons for this. Poorly defined requirements up front. Constantly changing requirements. Key personnel changes in mid course. Huge market disruptions. Whatever the reason, the project marches on. The team fights to keep it alive. Senior management is loathe to end such a program.

What you are experiencing is the phenomenon of “Sunk Costs” and the irrationality it invokes in otherwise intelligent people.  A sunk cost is money spent that can’t be recovered. An example: If during the alpha builds of a product, you find a fatal flaw that forces a complete redesign, the costs of development up to that point, and the costs of the flawed alpha products are “sunk costs”. Seems pretty obvious, but there is a subtle implication in the concept of sunk costs.

Sunk costs (by the way, they often aren’t called that internally) on programs that are over budget and significantly delayed are repeatedly cited in discussions and decisions about the future of a project or program. If you ever hear the phrase: “Well, it looks like we are delayed again, but we have to keep pressing on”, or “project y seems to be struggling, let’s add resources”, or similar comments are typical indications of a program with a sunk costs problem, and leadership who is in denial.

One of the most difficult responsibilities of a product manager is to advocate for the termination of a product or program if it no longer fits the business.  This can be when you replace an existing product with a new development, or when you have completely missed the market opportunity (i.e. if you were developing the highest resolution film camera today, it would be wise to cancel that program with all due haste), or when you have completely saturated the market (photomask inspection tools, for instance).  But terminating a product or program is difficult. We get personally attached to our products and programs. We often can’t see the bigger picture. We strive for success, even in the face of diminishing odds and potential returns. Most importantly, termination feels like failure, and acknowledging a past misstep, or mis-judgement of the business is anathema.

Even when product management does the right thing, and recommends the termination of a product program, they meet strong resistance along the way. Senior management hates to think that they wasted money, so they will continue to pour resources into doomed projects long past their “sell by” date.  An extreme example of this is the current situation of the F35 Joint Strike Force Fighter program. Hugely over budget, riddled with waste, and so far off schedule that they are now thinking that all the flight testing won’t be completed until 2017. The program has ballooned in cost to almost $400 BILLION dollars by the time that the 2000 plus planes are produced. However, the threat of shutting it down, and costing 35,000 jobs nationwide (in virtually all 535 congressional territories) is enough to prod congress into supporting pouring ever more resources into the program. But like many long, complex projects, the requirements have changed, key personnel has shifted, and ultimately, the capabilities being delivered don’t match the needs of today’s armed forces.

How to prevent such a fiasco?

First, before the commencement of the project, a formal requirements gathering process is essential.  I don’t care how small or large your project will be. You must determine the initial state of requirements, and the needs of the potential customers. This takes time, talent, and most importantly, an investment by the company to execute. Be wary of executives who “know what is needed” and that dictate the requirements. Be certain to validate all input. This is especially important in Agile methodologies. Think of it as a master “definition of done” that you write at the beginning. Don’t forget to revisit it, and update it as the project is underway.

Second, a well defined, and rigorously enforced Product Life Cycle (PLC) is an excellent tool to prevent such diversions of cost and schedule. A professional (and certified) project manager is crucial for any medium to large project (and more than one for enormous programs).  At each checkpoint, the product manager needs to revisit the initial and the current working copy of the requirements, adjusting, and documenting any changes in assumptions.  Keeping  abreast of trends in the market place, and how customer needs evolve will refocus and allow small course corrections in the requirements. But:

Third, if a major shift in the market happens.  A disruptive event (like the iphone caught RIM flat footed) can justify a raison d’etre event in the life of a project. If it no longer has a market, you can change (often called pivot) course, or cancel the project if no viable path forward exists. Here is where the “sunk costs” fallacy will be weighing on senior leader’s minds.

Fourth, As part of the PLC process, and the project manager’s duties, constant vigilance over the engineering team. Very often they will (internally) sneer at the requirements, appear to be working on them, but instead developing something that is their preference with the belief that they will look like heroes when they drop it in management’s laps.  This is most common in groups where the group GM or VP has an engineering background. One can understand why they reward and encourage such behavior. But nine times out of ten, these stealth projects flop, badly.

Summary

Every product manager at some point in their career will need to face up to the untimely euthanizing of a project. In retrospect it was always obvious that the program was off the tracks, but in the thick of the daily grind, it can be hard to recognize the symptoms.  We need to take the reins, and fight for what is right.

Essential take-aways:

• Because you have a lot of {time|money|effort} invested in a project doesn’t mean all steam ahead. Be objective in your goals, and pivot or terminate if called for.

• Even in a completely agile product, start with a defined end goal, and a timeline that matches the market opportunity. Adjust and tweak during, but keep the market opportunity window in mind

• Politics will be the toughest for the product manager to navigate this path. But this is where real leadership stands up.

  ---