Common causes of overruns in software projects

Over runs are very common in software projects. In a recent experience in executing one such project, I decided to do introspection. Not for finger pointing but for making sure we do not set ourselves for failure in another future project.

A typical project lifer cycle in software industry starts with a "Statement of work" a contract binding the customer with software development company. Commonly known as "SOW", this contract has very high level goal/requirements for implementation of the system based on analysis done by a sales engineer.

However the first thing that can go wrong in a project is that the statement of work though signed by both parties may not have been really reviewed by both parties and customer may have little faith in the SOW considering it implementing parties document rather than considering it a project bible!

Mistake #1 SOW not really reviewed by customer.

What ever relation you may have with your customer, make sure the SOW is understood and reviewed by the customer!

This can lead to lack of confidence in SOW, flawed estimations, missing/misrepresented pieces of work in the SOW which would lead to scope creep. In fixed-price projects once customer makes the payments its next to impossible to convince him for any further change orders in future. It might be easier to snatch meat from a Lion's mouth though!

Anyhow the project when in implementation phase with flawed estimations/assumptions results in requirement gap analysis followed by a change order cycle (remember snatching Lion's food). In the beginning of the project you end up straining relations with the client!

The legacy system if not understood fully by the sales engineer and poses humongous challenges with the implementation team to design the system. Due to this design may get compromised and developed in a haste to met deadlines. Design is a critical path activity and any delay or rework in design has a huge impact on project cost.



Mistake #2 Flawed Design to accommodate deadlines and features committed in SOW.

Any alarm raised by implementation team that threatens feasibility of the project may get drowned in commotion for keeping the project and any prospect projects "ON". Ideally the "SOW" needs to be revisited. May be split in phases, with certain items scoped out at the beginning of the project based on analysis of the implementation team. Even PMI advocates approved amendments to baseline at any stage of the project.


Mistake #3 Hidden features not spelled out in SOW

The SOW may not talk about certain features but they need to be developed in order to achieve a stable system. Such features are neither accounted as scope creep nor as Change Order. They may classify as "Gold plating" but rather unavoidable gold plating. These are minor issues but the technical team hardly ever reports it to the management. Even if they do due to nature of these issues they are ignored, and considered unimportant. However it adds to the overall cost of the project.

Mistake #4 Resource alignment

Resource alignment is usually done (on the basis of the flawed estimation) in the beginning of the project. During the course of the project estimation changes faster than resource alignment. Resources have their warm up time which adds up the the project lapse time. Even if the resources are idle they simply add to cost of the project. Resource planing is very critical to success of project and in agile projects with changing requirements can add to the stress!

Mistake #5 Infrastructure management 

Infrastructure management is hardly accounted in the SOW. But we all know its a laborious unavoidable work. We need to give ourselves more credit for this task be it developer environment management or QA servers, BAT servers etc. Sometimes also involves educating environment management to customer for customer specific environments. If I look back 20% additional time was lost on any project in infrastructure management as opposed to 5% allocated time.