≡ Menu
Pawel Brodzinski on Software Project Management

Successful Projects

According to often mentioned CHAOS reports prepared by Standish Group most of software projects meets deadline with software which can’t be called “ready”. In the first report from 1994 brought information that:

• 16,2% of IT projects were successful (on time and in planned budget).
• On average time overruns were 222% and budget overruns 189%.

These statistics are known by almost everyone. I bet it is the most often cited report about IT projects, so here you are – once more.
I’d one more thing from CHAOS report:

• 100% features were delivered in merely 7,3% projects.

In reports from later years all statistics significantly improves when comapred to 1994. Successful projects are about one third of all. Budget and time overruns are less than 100%. Situation is still far from ideal though. IT projects still fail to deliver planned content before planned deadline. One more statistic from CHAOS reports shows that feature completeness is between 50% and 70%.

Statistically, everyone had the problem with incoming deadline impossible to meet with completed project. Basically you should be prepared to manage this situation from the very beginning of the project. I know no one is. No one assumes on the beginning that she will fail to finish work on time.

It’s easier when you have a product you sell to many customers – then it’s you who (almost) fully controls requirements list. Basing on you experience in development and knowledge about you customers you choose features that will and will not be developed. You can choose a range of features that will be created depending on time and prioritize them. If there’s a time, they’ll be done. If not, well, at least you are prepared – you won’t promise this particular feature to your customer because you’re not sure if it will be there in the new version.

Things are different (what a surprise) when you develop custom project for single customer. The main reason is that you don’t fully control both: the list of requirements and the deadline. Unfortunately, the old rule of thumb says: “First take it, and then think how to do it”. It makes sense from business perspective, especially when you are on very competitive market fighting with bigger companies. From development perspective you end up with schedule impossible to meet and pressure from sales team to do it right. Sometimes you can try some more resources (what a nice name for developer), engage another team or subcontractor. Sometimes. Most often you go through schedule counting how many features are late.

Depending on your customer’s internal situation you can end up in two ways – either implementing project that isn’t feature-complete, but is on time or overrunning your deadline. Ah, yes, there is the third way – you do both.

Funny thing is that’s not as great problem as it looks. The biggest the project is the smaller are chances that it will be canceled on this stage. I estimate that for carrier grade solution on average overrunning the deadline for a year is not a great problem. For enterprise solutions more than half a year becomes serious issue. In the mid-market one or two months is usually all you can have trying to finish your project after the deadline before lawyers would start their work.

One thing remains almost constant in CHAOS reports – percentage of projects completed but not being “successful” (about 50%). That means there was either time or budged overrun (in vast majority of cases both). Now, in 2006, we all are more conscious in area of project management but I don’t believe that improvements shown in new Standish Group report will be fast and significant. It’s the long way to go.

in: project management, software business

1 comment… add one

Leave a Comment