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. 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 an evil 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 way 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 sunk costs problems, and leadership who has their head in the sand.
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 replacement, 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 hard to do. 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.
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. The lead contractor, Lockheed-Martin is masterful at playing the congressional district game. There are operations for this program in virtually every congressional district. The threat of shutting it down, and costing 35,000 jobs nationwide is enough to cower the congress critters 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. I also don't care if you are "Agile" although many people argue that means you don't need any requirements up front.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. That is a sure sign of impending doom.
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 manager1 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. 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 monds.
Fourth, As part of the PLC process, and the project manager’s duties, constant vigilence 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 heros when they drop it in management’s laps. This is most common in groups where the group GM or VP has an engineering background. For some reason, they reward such behavior. But nine times out of ten, these stealth projects flop badly.
Every product manager at some point in their career will need to face up to the untimely euthanizing of a project. In retrospect it is always obvious that it is inevitable, but in the thick of the daily grind, it can be hard to recognize the symptoms. We need to take the reigns, and fight for what is right.
1 - Note, this is a project manager, and they will work in coordination with the product manager - you - to shepherd the program. Don't confuse these roles, and you will have a good time...