Why IT projects so often turn out to be more expensive than budgeted

He cites a project at a large reinsurance company two years ago as an example. “They had a fixed price program for software renewal. A price of just under 10 million euros had been agreed, but after the specifications were drawn up, two-thirds of the money had already been spent. And then there was still construction to be done. Then the supplier said that it could cost 30 million after all, when they had actually offered it at a fixed price of 10 million.” After a consultation with IDC Metri, the actual costs turned out to be lower than 30 million, namely around 12 or 13 million euros.

Overoptimistic experts

Stories like this do not stand alone. Many companies and IT professionals know stories of projects that turn out to be (much) more expensive. So what goes wrong? According to Vogelezang and van Heeringen, it has to do with the budget. “In almost every industry there are professional estimators who are certified for this. A project does not start without the person giving their approval. But within IT, and certainly within software projects, we do not have those people. There you ask a project manager, a developer and, for example, a tester, how much time they think they want to spend on something. That, with a 20% quota, is your budget”, explains Van Heeringen, who is also involved in Netherlands Software Metrics Association (Nesma) based on its expertise.

The problem is that all those people are only experts in their own field. So a developer only knows how long he has been developing something, and a designer only knows how long he has been working on his own design. “These sub-budgets don’t have to be so bad in themselves, but they forget that you also need all sorts of coherent activities to ensure that, for example, your stakeholders stay involved. And those activities are often not included. You also see that you are often 20 to 30% too optimistic with the expert budgets,” adds Vogelezang.

And there is more to the cost estimate for a project. “Do you have a product owner who understands what needs to be done, or does he get things rebuilt four sprints in a row?”, says Van Heeringen. “And what you also see a lot is that found defects are not solved in the same sprint, because there is no time. These are then restored to the backlog. The next sprint you immediately have a backlog, because you also have to solve those defects. Then you can create fewer user stories in that sprint. You have to account for all these things in a budget.”

Misleading story points and hourly rates

In addition, so-called user stories and story points – a measurement unit for measuring the required time effort, risk and complexity – can be misleading in an agile working method. “Story points is an effort goal and not a product goal. Anything that takes time gets story points. So you may well achieve the predicted fifty story points in a sprint and then you are very predictable in your work. But maybe only ten of those story points were for new features and the rest were for defects and bugs to be fixed, so you don’t get much closer to the product you want to make, but you think you’re doing really well because you’ve earned the fifty points. «

And just as story points can be misleading, so can hourly rates. And that is quickly taken into account if an organization carries out a project itself, with its own people, or, for example, hires a team or freelancers. “The problem with hourly rates is that it says what it costs, but not what you get. If procurement is going to try to make the most of it, you’re bound to get juniors or people who are disadvantaged. You don’t want that, because the difference in productivity is much bigger than the difference in hourly rate.’

Furthermore, in these cases the supplier has no incentive to be very productive. “They have an incentive to bill a lot of hours.”

How should it be?

Van Heeringen and Vogelezang have been guiding companies on IDC Metri with their budgets for IT projects for years. According to them, a big difference is that they not only look at what needs to be done and what it is expected to cost, but also at the size and the lead time. Van Heeringen compares it to a painter receiving a commission. “Firstly, it counts the number of square meters to be painted. So do we.”

The two then compare the project with previous comparable projects that have been completed. “We have close to 15,000 reference projects. It includes all kinds of characteristics, such as the industry, the technology, the team size, where the team is – distributed together all over the world – and the cubic meters of software to be delivered,” explains Vogelezang. “If you combine those things, you can select similar projects as best as possible, and within a certain bandwidth you get a clear picture of what the project will actually cost.”

Finally, the lead time is also included in the budget, as it has a large influence. Van Heeringen quotes the painter: “If he has to paint a wall of 200 square meters in one hour, he will not succeed. He has too few people for that. So he has to work with a very large team. But they can get in each other’s way, and communication may not go well. It is the same in IT. If you have to do a project that is too big in too little time, the teams get bigger and bigger and so does the complexity. If you create another team, the delivery time will not suddenly be cut in half. It might only be 10% off.”

The rise of software costing

Those who want to make a more accurate estimate of their budget are therefore most dependent on organizations that take such factors into account and can look at reference projects to make a good estimate. But in the future the companies may be able to do this themselves, says Van Heeringen. From NESMA, he is involved in the development of the Software Cost Estimating Body of Knowledge (SCEBoK), which is being established by the International Cost Estimating & Analysis Association (ICEAA). SCEBoK will be a costing certification program, specifically aimed at software projects. In the future, organizations will therefore be able to hire or employ so-called software cost estimators, who are trained to estimate a software project as precisely as possible.

It not only creates a better picture in advance of what something will cost, but it is also easier to make adjustments during the project, says Van Heeringen. “What has often happened so far is that all traffic lights are still green until three days before the deadline, but then it turns out that you don’t come. But if, after six months, you know that half of the functionality must be ready, and you look at how much is actually finished, you can clearly see whether you are following the schedule or whether things are going wrong. Then you can update your estimate or see if action is needed. But that is only possible if you know at all times how big it is, what you have to do and how much has been completed.”

As far as Vogelezang and Van Heeringen are concerned, companies in the future will have their own cost calculator – who is also, for example, a product owner or scrum master – who constantly keeps their finger on the pulse. But before then, the certification must first appear officially at ICEAA. When that will happen is not yet entirely clear. “It is now a matter of formalizing the exam. I expect it to happen within a month. Then we can really get started.”

Leave a Comment