Why IT project estimates fail and what to do about it

Simultaneously, there is a lot of advice as to what IT project managers should present to management. For example, one suggestion is that the project manager should first make an estimate, and then double it, because it will be wrong anyway. Another suggestion is to provide an analogy that other departments in the organization will understand. Take commuting, for example. Depending on the traffic situation, you might be many hours late, or it may take double or triple the time to get home due to unforeseen events. Or, simply not providing a project estimate at all is another course of action. Or, give an estimate as late as possible during the project development because you are then less likely to be completely off-target. 

Project estimates not only fail, but they also fail massively

In 2011, an article in Harvard Business Review, Why Your IT Project May Be Riskier Than You Think[1], pointed out that although IT projects are not prone to cost overruns on average, a disproportionate number of IT projects incur massive overages. As the authors put it, IT projects are a new risk for companies; they routinely cost the jobs of top managers and are known to have sunk entire corporations. Furthermore, the authors of the article advise leaders to conduct a stress test to determine whether the company has the capacity to absorb huge failures in project estimates. For example, this could involve a large IT project going over-budget by 400% or more, with only 25% to 50% of the project benefits being realized.

Today, almost a decade later, IT project estimates still fail; and fail massively, and management will seldom be happy with a traffic-jam analogy but will ask for a fairly detailed and reliable project estimate. This is exactly what they ask from all other departments – sales, marketing, production, logistics, and so on. Considering that the IT department is full of intelligent and brilliant people, one starts to think that there must be a better way to measure IT performance.

Function points measure the size, not the capability of your IT department

A well-known method for measuring software development is function points. As the name suggests, function point analysis measures the size of a system based on its functionality, by measuring the number of inputs, outputs, queries, and internal and external files in a system. As the same type of elements can vary in complexity, each function type is also adjusted according to whether it is simple, average, or complex.

Knowing the size of a system will, however, not reveal whether your company has the capability to develop it and integrate it with existing systems. To estimate time and budget, function point analysis is, therefore, often combined with historical data on the time and cost for a project of equal size in terms of function points. However, due to today’s rapid technological development, historical data is often not a very accurate tool. Furthermore, especially where complex systems development is concerned, relying on historical data might, in the worst case, take you completely off course.

People make the difference

The missing factor in function point analysis, and in many of the methods and templates available on the Internet, is people. Software development is highly dependent on the skill and experience of your IT developers. For example; imagine an extremely complex, high-risk surgery, such as a heart transplant. This kind of surgery will only be performed by extremely skilled and experienced heart surgeons. Adding one or several General Practitioners, GPs to the team, will not help the patient or move the surgery forward. It will probably only mess things up for the heart specialist, who will have to deal with a lot of inexperienced doctors during the surgery.

The same variation can be found among IT developers. Just allocating a lot of heads to a project will not move the project forward unless the developers in question have the necessary skills and experience. You cannot simply grade, or rate, a GP with a 1, for example, and a heart specialist with a 5, or use categories that say that a GP can do “simple” tasks and a specialist “complex” tasks, similar to the function point adjustment. Those kinds of approximate scales do not take into account the vast difference between the GP, who has no experience of heart surgery at all, and the specialist who has perhaps decades of experience and who has performed hundreds of surgeries.

Start measuring performance drivers

Just like doctors, IT developers are not interchangeable plugs. However, many models and templates for project estimates do not take the people factor into account, or otherwise employ very rough, close to meaningless, scales. Also, software developers do not work in a vacuum. There are legacy systems, IT architecture, company culture, and many other aspects, or drivers, that will have an impact on IT performance.

Once you start to measure your IT performance drivers, of which ‘people’ is the most important, you will also gain a more accurate estimate of the potential of your IT department. Consequently, you will also be much better equipped to make accurate project estimates and be able to predict project time and cost accurately.