Truthful statistics of cost overruns
There is no secret that the cost overruns go closely with each software development project in the world. The average overrun amounts 40 – 50%. And 70 – 80 % of projects in the industry finish with overrun against the initial estimation.
The IT market is not only that is full of overruns. Big complex projects such as military and construction ones often get their budget over.
Why the software development budget goes over
The reasons of overruns are bound with all the areas of the project development. The reasons may be linked with bad practices of project management and their cumulative impacts. There is a complex mechanics under the hood of a project. So, what are the reasons of overruns?
The bigger the project the more probable the risk of over budget is. The scope may be changed by the project customer or the product manager for reaction to the market needs or investors plans.
Some projects have not very distinct business aim and mission. It’s dangerous because it usually leads to many changes in solutions and the features planned. Changes and additions on the fly lead the situation when some part of work has to be thrown away. Because the new requirements may contradict the initial ones. It’s extra money.
The target should be fixed as much as possible because the pointing to a moving target is much harder and more expensive.
The other vital thing is priorities within the scope. Customers usually say that all the works within the scope are very important and they are right. However not each customer shows the priorities based on the project mission or business goals. As a result the tasks are developed by random along with the budget.
The important way to get a more accurate scope is the analytics phase before the development.
Time is the third category defines the Project management triangle of balancing between Scope, Budget and Time. The meaning of this diagram is simple. If one of the three is important, other two have to be abated. Or if two of the three are important, the remaining one should be sacrificed. Actually there is no ability to improve positions of all the parts of the triangle at once.
The tight schedule produces an over budget because of overtime work, that is not so productive, lack of time for planning and control, too many parallel flows to conduct etc.
The estimation is the very thing a customer takes into account when he decides to start a new project. The estimations in the IT development market are usually not reliable. Why?
- The estimation is based mostly on the skills of the particular expert(s) participated into estimation. Each expert has his/her set of examples in his/her own practice to give an estimate.
- The estimate has a risky nature: the more is the necessary reliability of the estimation the more the estimate is.
- Moreover, there are a lot of developers and even IT companies showing optimistic estimations to get the projects. As a result, you know what the statistics of the projects with the cost overruns is.
The right approach for the estimation is pointing the estimate values along with a description of:
- assumptions that make the estimation valid;
- pessimistic estimations with the risks described.
The important way to get a more accurate estimation is the analytics phase before the development.
Each project lives and breathes and needs to be controlled in terms of the initially planned budget and the forecasted one. In case of the hourly based contract, it can lead to the moving of the featured with less priority to the future versions of the product to keep the budget.
Software quality is being used as a fourth part balancing with Scope, Time and Budget. However, quality can be considered as a part of Scope.
A frequent example is the load for a new web-application. The loadability can be not sufficient if it was not arranged with the performer initially.
There are a lot of methods that should be used for the quality assurance. These methods require works of the relevant experts and should be planned initially.
The main resources within the software development is human resources: developers, QA engineers, analysts etc. Their conditions define the result.
FreeImages.com/B S K
The work made by low level specialists with low rates is often far more expensive than the work by high level specialists with high skills, since a low level specialist needs more detailed code review and bigger bugfixing. This difference is obvious in case of complex tasks.
The people may get demotivated due to some reasons on the project. It leads to lower productivity. As a result, the same scope may cost more.
A customer can have a really big profit from small investments in team-building.
From the other side, good companies conduct rich stuff policy to provide their employees with the systems of motivations.
Work with people is connected with psychology and sociology and this topic can’t be described in the bounds of this post.
The loads of communication cost much because this time is billed. The lack of communications costs even more, because each team mate of the project should be on the same page with others.
That’s why the important instruments is a set of communicative rules and sufficient documentation, that eliminates the extra communications.
During each phase of a software project development, harmful incidents may occur. It can be unexpected problems with 3rd party systems or changing of a budget by stakeholders. If a project member can point the risk early, it can be much more safely for the project budget.
The risks should be found as soon as possible, they should be roughly estimated in terms of probability and costs. Important risks should be mitigated. The risks list should be periodically updated.
Some projects need additional acquire products, services needed from outside.
It should be planned and controlled as well.
There are projects without a described picture of the organizations and persons, who participate the project. Opinion and decisions of each stakeholder can lead to the budget change.
The work with the stakeholders should be based on the principles of engagement in project decisions and execution.
An inappropriate methodology of the project management may completely ruin any IT project. Work progress of several people may become chaotic without the organizing power from outside.There are a lot of negative consequences of this, e.g. conflicts, duplication of work, delays in the production of any artifact, reworking and over budget, indeed.
The reliable workflow describes the flow of the distribution of responsibility. In this case each colleague knows who should do, what should be done, when it should be done.
There are a number of methodologies of the project development from the ‘Waterfall’ to the Extreme Programming. One of the most important characteristics of the up-to-date methodologies is iterativity. It allows to have a working products after the end of each iteration. The end of each iteration can be used as a checkpoint for controlling of the budget and planning of it for the future.
How to get the project done in the bounds of the budget?
I would like to suggest that you use the following checklist to mitigate the risk of cost overruns.
As a project customer, I need to check, whether
- I have the mission and the business goals written and shared with the performer;
- I know the priorities between the scope, the schedule, the quality and the budget of the project.
- The performer shows me estimates with assumptions and risks.
- The costs are controlled regularly with the objective instruments.
- The parameters of quality are set up.
- The schedule is realistic and prudent.
- The company-performer cherishes the people who are working within it. The team mates are motivated and committed to the project. The distribution of tasks relates with the skills of each teammate.
- Amount of communications are optimal. The documentation answers a majority of questions, keeping time of the project team.
- There are the up-to-date risks list and the mechanisms to actualize it periodically. The most important risks are mitigated.
- There is a plan of purchases for the project.
- All the stakeholders are known and included into a process of making decisions. Opinion of each stakeholder has been taken into account.
- Workflow is iterative, resultative, transparent. It provides the new working version of the product after each iteration.
Be sure now, that your project is in budget ;).