Knowing When to Quit

Patricia Keefe has a blog entry in Information Week, where she describes two failed projects: the FBI Virtual Case File and the Mecklenburg County court system, both of which you can read about in this blog.

Patricia raises the question of deciding when it’s time to kill a project. From her post:

Far more projects fail than succeed today—in large part because people don’t practice basic project management (pity the poor project manager). So doesn’t it make sense to know what your pain threshold is going to be? Isn’t it better to lose $1 million instead of $6 million? Part of being a leader is knowing when to quit so you can come back and launch another project another day.

The kill /don’t-kill decision is always hard. Here are a few points to think about when staring down the gun barrel:

1. Consider whether you trust the vendor. In Mecklenburg County, the head guy made the vendor “promise” to do a good job. Sure, that’s nice, but a promise isn’t sufficient to align the vendor’s interests with yours. If you don’t trust your vendor, consider finding a replacement.

2. Get non-biased advice. Ask an objective, experienced third party for their advice. Yes, it will cost a little money, but isn’t preventing further disaster worth something to you? (Hint: the answer to that question should have been yes.) By the way, don’t ask your existing vendor to play this role.

3. Don’t be scared. Sometimes you need to pull the plug. If the time has really come, then be brave and do it.