17 March 2004

by Michael Mah, Senior Consultant, Cutter Consortium

Recently, one of my clients and I were discussing a project that his team had deployed some time ago. It was a real success story in risk management. The team had skillfully managed the deadline and the scope, using project simulations of where things were heading, and delivered within two weeks of their 90% probability date.

In contrast, he also described another project that ultimately led to his leaving the company in disgust. Management and marketing had committed to an insane date. Quarterly revenue was the motivation — if they made the perceived time-to-market, it could open a money pipeline for that product and ultimately help the company meet Wall Street expectations for that quarter.

What happened? They ran their simulations — and based on the “in-flight radar,” it became apparent that they’d either have to slip the date or cut function. But the exec in charge would not hear one word of that. So he directed the team to work 70- and 80- hour weeks. Many cancelled summer family vacations. Mom or dad had to work, so the kids were out of luck. This reminds me of a past quote from a senior VP of another major company, who is now its CEO. He said, “We either have to make our deadlines or kill our kids.” (No joke — this quote appeared in a national magazine. I can’t tell you who it is.)

In the end, as another client once said to me, “Reality will prevail.” And it did. After all those vacations were cancelled, the company killed the project anyway when the deadline arrived, and exited that business niche. It shouldn’t have. Another competitor entered the same market later on with a competing product and now owns a virtual monopoly, raking in the bucks.

So, when should you cancel a project and when should you let the team finish?

Certainly not based on just a deadline — and one that may be arbitrary at that. Tom DeMarco, in his keynote speech on risk management at last year’s Cutter Summit conference, said that time-to-market is often a myth. It’s hogwash to think that the first to the prize always wins. Was Google the first search engine? Was Excel the first spreadsheet? Was Access the first PC database? What products were the first? (Bonus points to those who can answer the above, including the companies that made them. The answer to the database quiz question, plus a trivia tidbit, is at the end of this article.)

My advice is that it has to be about more than the deadline.

There are two high-order dimensions that have to be considered when deciding whether to cancel a project. One is output: that is to say, is the project on a “trajectory to completion” by a given date? To answer this, you’ll need to track progress in a more effective way than just using a tool or method such as MS-Project, which only tracks things like milestones and effort expended. That’s like deciding whether an aircraft is on course by looking at just a watch and a fuel gauge.

To assess whether a project is truly on course, you have to track the cumulative progress of the components as they’re being built (i.e., modules, objects, classes) and their quality. These product measures will give you early transition indicators if the project starts going astray — things like a green, yellow, or red light if they don’t stay on the path of what is usually an S-shaped progress curve.

The other thing you’ll have to keep in mind is outcome. Suppose a project indeed looks like it’s going to miss its sometimes arbitrary and “aggressive” deadline. And suppose the budget overrun is going to be about a million dollars. Well, if the value of the thing looks like it’ll be modest at best, then by all means, kill it. However, if this is a product like an iTunes and it turns out to be a killer app that helps sell another hardware killer app like an iPod, then who cares if it’s a little late and over budget! Chances are, it was your budget and deadline that was wrong wrong wrong in the first place. The value generated by the application will vastly outweigh the project overrun and slippage.

Oftentimes, I’m reminded that impatience is not a virtue. Managers need to be thoughtful about output and outcome when considering whether to kill a project. We need also to redefine what the term “project failure” means. A decision-making failure might occur if a project is poorly planned, managed without any size or defect metrics, and cancelled prematurely, while having high value if it were only deployed. Another decision-making failure might be an application that makes a deadline and stays within budget, but does nothing for the company.

That’s why it’s vitally important to have a frame of reference that puts things in perspective. I’m reminded of a story about an art student and teacher. The first sketch by the student was that of a hand. It was quite two-dimensional, with very little detail. After some instruction by the teacher, the next sketch was beautiful. It looked three-dimensional, and had texture. The teacher was asked, “What techniques did you impart that led to such a dramatic difference?” The teacher’s answer: “None — I simply taught the student to see things differently.”

Sometimes, deciding whether to kill a project requires a new way of seeing things. If you expand your vision to include tracking product output metrics like size and defects, while being thoughtful about project outcomes and value creation, it may make all the difference in the world to your decision-making skill.

— Michael Mah, Senior Consultant, Cutter Consortium

[The first PC database was dBase. It was built by a company called Ashton-Tate. George Tate was one of the company founders. Ashton was the name of his dog. Sadly, Tate died at age 40 in 1983. Ashton-Tate was acquired by Borland Software after shipping its flagship product, dBase IV, by an aggressive deadline. Because it was shipped too soon, it still had thousands of bugs, and the company lost the entire market. MS-Access would later become dominant.]

© 2004 Cutter Consortium. All rights reserved.