The first 90 percent of the code accounts for 10 percent of the schedule. The remaining 10 percent of the code accounts for the other 90 percent of the schedule. — Tom Cargill, Bell Labs
Why are software project estimates so inaccurate? Estimates are important data points used to make business decisions. However, we are all aware of technology projects that fell off the rails. Software researchers and practitioners have been examining this problem since the early 1960s, so it’s nothing new. One recent example is the revamped Canadian Government Payroll System; the result: 80,000 workers did not receive correct pay for months on end. It will cost Canadian taxpayers $20 million and require months of work to extinguish this particular dumpster fire. Similar headlines pop up on a regular basis.
Presumably, there were a lot of smart people on this project using some type of intelligent project governance methodology. So how could this possible happen?
Having been involved in numerous tech projects I have seen some recurring themes. Here are three of my favourite maxims. Ignore these at your peril:
1. The original spec identifies 50% (max) of the total requirements and the half-life of new requirement identification is 3 months.
Yes software projects share a similar characteristic with some chemical reactions. A half-life of 3 months means that we will identify one half of the remaining requirements every three months. This principle means that about 10% of requirements will still be undiscovered after 12 months.
Let’s assume the budget starts at 100 units. Three months into the project we will have identified another 25% of the total requirements. The project’s Executive Sponsor is informed that due to the new requirements the budget should be increased to 150 units along with a 50% increase in timelines.
Executive Sponsor: “Well to say I’m disappointed is an understatement. There will be no increase in budget or timelines on my watch”
Software Developer: “That is only possible if the project sticks to the original spec and we ignore these new requirements.”
Executive Sponsor: “Well you are the expert here. Although the new requirements are not explicitly covered in the spec it was assumed by everyone that these type of things would be included. I need you to work with me, look at the plan and see how you can make this work for us.
Software Developer: “Umm well I don’t see a solution here and we aren’t done yet. If you add additional requirements the budget and times lines will continue to expand.”
Executive Sponsor: “Well that’s not going to happen – as I said please go back and review how you can get this done.”
Now a thought may occur to you – Why would the original spec have only 50% of the requirements? Great question! That’s a great topic to be explored in a future blog.
2. One Third of all issues are caused by client supplied bad data.
In B2B and ERP projects, the customer supplied data is always problematic.
Customer: “Hey software vendor when exactly is this system going to be usable? –As an example look at this Sales by Country chart – It is nonsensical!”
Software Vendor: “50% of your addresses don’t have any country specified. And here are some country entries for other addresses: Oregen, NY, ONTARIO, mexico cty, StaTE RoAD 25 and 75107. Note how perfectly this data corresponds to the columns on your chart”
Customer: “So when will you be able to fix it?”
Software Vendor: “Actually your staff will have to clean up all your addresses”
Customer: “Every address! That’s ridiculous – do you know how much work that is? We would have never done this project if we knew about this.
3. Actual software defects are rare
Only 10%. of all identified issues will be actual software defects. The Executive sponsor, however, will announce that the project’s problems simply boil down to poor quality software from the vendor.
Estimating software projects is easy. Establishing complete requirements and providing clean data is hard.