Infeasible software projects are launched all the time and teams are continually caught up in them, but what is the real source of the problem?
There are 2 year actual projects for which the executives set a 6 month deadline. The project is guaranteed to fail but isthis due to executive ignorance or IT impotence?
There is no schedule risk in an infeasible project because the deadline will be missed. Schedule risk only exists in the presence of uncertainty (see Schedule Risk is a Red Herring!!!)
As you might expect, all executives and IT manager share responsibility for infeasible projects that turn into death marches. Learn about the nasty side effects Death March Calculus.
The primary causes for infeasible projects are:
- Rejection of formal estimates
- No estimation or improper estimation methods are used
Rejecting Formal Estimates
This situation occurs frequently; an example would be the Denver Baggage Handling System (see Case Study).
The project was automatically estimated (correctly) to take 2 years; however, executives declared that IT would only have 1 year to deliver.
Of course, they failed1.
The deadline was rejected by executives because it did not fit their desires. They could not have enjoyed the subsequent software disaster and bad press.
When executives ignore formal estimates they get what they deserve. Formal estimates are ignored because executives believe through sheer force of will that they can set deadlines.
If IT managed to get the organization to pay for formal tools for estimating then it is not their problem that the executives refuse to go along with it.
Improper Estimation Methods
The next situation that occurs frequently is using estimation processes that have low validity. Estimation has been extensively studied and documented by Tom DeMarco, Capers Jones, Ed Yourdon, and others.
Improper estimation methods will underestimate a software project every time. Fast estimates will be based on what you can think of, unfortunately, software is not tangible and so what you are aware of is like the tip of an iceberg.
None of this prevents executives demanding fast estimates from development. Even worse, development managers will cave in to ridiculous demands and actually give fast estimates.
Poor estimates are guaranteed to lead to infeasible projects (see Who needs Formal Measurement?)
Poor estimates are delivered by IT managers that:
- Can’t convince executives to use formal tools
- Give in to extreme pressure for fast estimates
Infeasible projects that result from poor estimates are a matter of IT impotence.
Both executive ignorance and IT impotence lead to infeasible projects on a regular basis because of poor estimates and rejecting estimates; so there is no surprise here.
However, infeasible projects are a failure of executives and IT equally because we are all on the same team. It is not possible for part of the organization to succeed if the other one fails.
Possibly a greater share of problem is with IT management. After all, whose responsibility is a bad decision — the guys that know what the issues are or the ones that don’t.
If a child wants ice cream before they eat dinner then whose fault is it if you cave in and give them the ice cream?
Unfortunately, even after 60 years of developing software projects, IT managers are either as ignorant as the executives or simply have no intestinal fortitude.
Even when IT managers convince executives of the importance of estimating tools, the estimates are routinely discarded because they do not meet executive expectations.
Rejection of automated estimates: productivity -16%, quality -22%
Until we can get a generation of IT managers that are prepared to educate executives on the necessity of proper estimation and be stubborn about holding to those estimates, we are likely to continue to have an estimated $3 trillion in failures of software projects every year.
1For inquiring minds, good automated estimation systems have been shown to be within 5% of time and cost on a regular basis. Contact me for additional information.
- Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.
- Jones, Capers. The Economics of Software Quality. 2011
- Kahneman, Daniel. Thinking, Fast and Slow. 2011