How to manage Cost Overruns in IT Projects
Cost Overruns in IT Projects
When the cost exceeds the original planned budget at project completion it is called the cost overruns. Historically it is proven that infrastructure projects are borne to high cost overruns. The reason is that these projects do contain high uncertainties on the variables used. Another main reason is that most projects are multi-year and do not have the inflations correctly projected.
Does it happen in IT projects? Yes, it does. There are couple of aspect to that, one being how to control it and bring it back to baseline and another one would be how to prevent it all together. Before we deep dive let’s see what could effectively cause an IT project for cost overrun.
1. Unexpected delays.
2. Scope creeps.
3. Ambiguity in scope.
4. Incompetent resourcing.
A required process for every organization:
When a project ends with cost overrun then it has to be analyzed in detail with the performed team to identify the reasons for its failure. This is aka post-mortem and it is a very effective required step in reaching organizations goal. This should be done as part of closing process and it is the responsibility of the PM to document the results. This will certainly help preventing any cost overruns in the future projects.
How to control the cost overrun
In case of controlling the cost overrun and bring back the budget in par with baseline; the cost overrun has to be identified in its early stage. It is the duty of the PM to keep track of the budget expenses and gets alerted when the deviation occurs in the budget. Once the deviation is identified and it is steep then control measures should be taken by identifying the reasons for the cost overruns. It could be one of the above as explained and has to be attacked properly to bring it back to baseline.
It should be identified as one of the project risk and should be addressed well with the risk response plan on how to overcome the situation.
Compare the scope baseline with the work performed and identify the additional scope been added to the project without scope change request. There is nothing you could do with the features that has been already added and there is no point in getting them removed. But the ones that are currently been added should be focused on and make sure these things do not happen. To recover the time spent schedule compression can be performed but for the cost it is very difficult to say.
Ambiguity in Scope:
When you identify that scope is either not clear nor it has lot of ambiguity then it is time to stop the project or rewrite the scope. These projects should be performed under a T&M time and material rather than a fixed budget project. It usually occurs in R&D type of projects where scope is not clear.
The selection of resources with desired skill set is very important for any given project’s success. Review the project team’s skill set to make sure there is no lag due to resources skill level. This can be overcome using techniques like training.
How to prevent the cost overrun
Prevention is better than cure; universally accepted phrase. First thing is to focus on the scope; a clear scope definition without any ambiguity is required for any given fixed cost project to be successful. Then make sure scope remains constant as much as possible by not allowing any scope creeps to occur. This will make sure all your cost, schedule and scope baselines are intact encapsulating the project. It doesn’t mean that scope changes are not allowed; scope modifications have to be done through integrated change control system by properly accounting the schedule and cost adjustments for the project.
The second thing to focus would be risks; identify the risks at the beginning of the project and account the risks accordingly. This can be done by preparing workarounds or preparing risk response plans with adding some cost reserves to the budget.
Third thing would be to select the proper resources for the project. Know your project well before and hunt for the resources with the desired skill set.
Blackburn Inc finished an internal Project ‘Inventory system’ with a project cost overrun of about 70% and schedule overrun of about 50%. The VP of Project Management wanted to investigate this and calls for an internal discussion with performed team.
VP: Congratulations on completing the ‘Inventory system’ project. We are here to discuss the reasons for the cost overrun on this project to create the required policy or procedures that can be used to avoid future cost overruns and not to pin point each other for the failure. So please tell me “what went wrong?”
PM: The original estimation was done last year before we bought the new inventory counting hardware. The sponsor was forcing us to meet the same project completion date after the inventory change that made us to do overtime.
Team Member: The purchase of new hardware made us to change our design entirely. So we had to re-work.
VP: Did we account this into our project?
PM: No, It is entirely my mistake and I have not re-estimated as the project completion date remained same.
VP: Well, Now we all know what went wrong. Let’s focus on making some procedures here so that this will not happen again in the future.
What went wrong?
When the new hardware is purchased the scope has changed and it is not accounted for. The things that did not happen:
1. PM should cancel the project and started a fresh one.
2. PM should not have agreed on the same project completion date.
3. PM should have re-estimated using the new hardware and put in the change requests accordingly.
4. Team members should have alerted the PM when the design change was required.