Software Estimation Best Practices

Seven Steps to Software Project Failure

In spite of 30 years of structured programming, CASE tools, OO development, 4th GL languages, CMMI, and PMI, the failure rate for larger projects has failed to respond to all of this love and attention. We normally think of failure as a negative thing; but it can have its upside. Saddling a competitor or enemy with a doomed project could stain their career or at the very least inflict a high level of pain on them. A CEO about to retire, or whose focus is on near term stock options, may be able to boost quarterly profits by continuing to add staff to a doomed effort:  one for which the customer pays for the added staff, of course.

Since failure is a constant, here is a management guide on how to assure failure. While any one step in the process can be overcome, taken together they create the perfect software project storm.

Step 1: Start work as soon as you can

Come on. You don’t really need to spend all that time in requirements meetings and documenting assumptions. Real projects take the ball and run.  Be sure to begin coding as quickly as possible. Call it prototyping if you will; but do get started. You can always circle back to tweak things if needed.

Step 2: Estimation is overhead

Nothing is more frustrating and time wasting as having to go to some external group who know nothing about your project and have them tell you how long your project should take, how many people should be on it, and what the trade-offs are. What can their mathematical models possibly know about your project? A good end run around this situation is to create a project plan and call it your estimate. Make sure that it is very detailed and contains decimal points, since these will make it more difficult to challenge.

Step 3: Assume that you understand the requirements

This ties in closely with Step 1. You will create confidence if you exude it. Show a sense of urgency to get started with the work. Analyzing everything to the nth degree accomplishes little, frustrates mightily, and contributes little to getting the work done.

Step 4: Change can always be fit in

There are always changes in a project; but one thing your customer doesn’t want to deal with is a negative attitude on your part. A can-do attitude is a must. Say “Yes” and solidify the impression in our customer’s mind that you are responsive to their interests. And don’t try to nickel and dime them for more time and money. You can always fit it in. Say yes and they will be far more apt to give you the space you need to run your project the way you know it should be done.

Step 5: Make your best developer the project lead

All of this process improvement stuff just stifles innovation. Your best developers know how to really get things done. Put them in charge so that they can guide others. Let them lead by example.

Step 6: Hide bad news

Nothing poisons your relationship with your customer and lowers team morale more than bad news. Keep it to yourself and work things out. Most bad news is overblown, anyhow. No point getting everybody all riled up over nothing. Most things can be resolved without causing a commotion.

Step 7: When problems arise, add staff

Bring in the troops. A few more good people will bring a fresh perspective and add renewed enthusiasm to the project. Your team will appreciate it and your customer will see that you are really taking the situation seriously.

While this seven step program does not exhaust the possibilities, it has been put to the test and has inevitably been proven to work.

My thanks to those masters of satire, Jonathan Swift and C.S. Lewis (who taught by proposing the opposite of what they recommended).

Blog Post Categories 
Risk Management Program Management