Why your replatforming gets priced twice

You received a quote. You signed it. Work begins, and a few months in comes the next figure: a new price for whatever turned out to be harder than expected, or to fall outside scope.

A second price rarely surprises anyone who has costed projects before. The explanation lies in how the first calculation was made.

The price is set before anyone knows what the work involves

A conventional quote puts a price on work that has not yet started. Nobody knows how long the integration with your ERP will take before someone has opened it. Nobody knows which exceptions are hiding in your pricing logic, or how they should be handled as standard.

That is not dishonest. It is what an estimate is. The uncertainty is real, and if every solution is built almost from scratch it can hardly be removed. The question is who carries it.

The uncertainty is also easy to underestimate. A review of 5,392 IT projects found that cost overruns do not distribute evenly around an average. Most projects overrun a little. A smaller number overrun violently.

Roughly one project in five ends up at least fifty percent over budget. And those projects do not stop at fifty percent. On average they finish at a little over five times the sum in the original quote. The worst case in the material was not a major programme, but a small workflow adjustment.

The average, in other words, does not describe the risk you are taking. And that never shows in a quote.

The picture is the same for projects of ordinary size. Between 60 and 80 percent of all software projects overrun on effort or schedule. The typical project lands about a fifth above the estimate, while the average sits twice as high. The difference comes from the few that run away and pull the mean up. It is usually the larger projects that are underestimated.

One clarification about the figures: the numbers most often quoted in the industry are considerably higher than these, but they tend to come from consultancy reports rather than research. We stick to the lower ones.

The integration is the hardest part to judge

Pricing logic, customer-specific discounts, stock balances and order flows all look simple in a requirements specification and behave differently in production. A price that appears fixed is often recalculated on every order, based on contract, volume and customer group. That complexity does not show in the quote. It shows up later in your invoices.

Real usage is what generates the add-ons

Only once the solution is live does it become clear what the specification missed, and every such discovery becomes a new order. After go-live in a traditional project they arrive in quick succession. Each change means a new calculation and a new discussion. For you, that means the budget never quite holds.

Maintenance is not a rounding error

The maintenance phase accounts for around 60 percent of what a piece of software costs over its lifetime. The IEEE Computer Society puts the range at 60 to 80 percent. The build is the smaller part of the bill.

The usual rule of thumb says maintenance costs 15 to 25 percent of the build budget every year. That figure comes from systems with few external connections. A customer portal or reseller portal is connected to the platform, the ERP and several external services, and for those 15 to 25 percent is closer to a floor.

We have done the arithmetic and set out the result in a separate article. Litium and Business Central alone account for more than forty occasions a year when something around the solution changes, without you having asked for a single one of them.

Why we are willing to quote a fixed price

We quote fixed prices. It is fair to ask how we dare.

The answer is that we have usually already built what is being priced. The functions in our library are running at other companies, with integrations to Business Central, Monitor and Jeeves. We know what quality they hold and how well they work alongside the rest of a solution. Pricing something that already exists is a different exercise from pricing something that will be developed iteratively, and at times exploratively.

That is where the difference lies. That way of working is right when nobody yet knows what should be built, and uncertain estimates come with it. You cannot put an exact price on something that has to be discovered, and that is the nature of it. On standardised work you can.

It also means less has to be built from new. The smaller the share of a project that is new, the less there is to underestimate.

We also calculate differently on what is built for several customers. When a function is developed to be used by more than one company, the development cost is shared. You pay for your share of it and for the adaptation to your setup, not for the whole build.

Three levels, one pricing logic

A function is delivered at one of three levels, depending on how unique the need is. Standard works as it is. Adapted is used when your process differs somewhat. Customer-specific is developed when the need exists only at your company, and it is then built separately from the rest, so that it does not affect other parts when the platform is upgraded. All three are delivered at a fixed scope and a fixed price.

That also changes what go-live means. Instead of being the starting point for additional invoices, it becomes the start of a contracted responsibility at a fixed monthly cost. We track the versions of both the platform and the ERP integration and make sure they keep working together. An upgrade is therefore not a new quote. You can start with a product site and later add a customer portal on the same foundation, without starting over.

Macro Design, part of Svedbergs Group, took it in that order. They signed Care at the same time as the implementation of their new website and reseller portal on Litium was agreed. Maintenance had a price before the build began, not after.

What the model asks of you

A fixed price requires a locked scope. We spend more time on preparation and close the scope before the build starts, which means you have to make decisions earlier than in a time-and-materials project. If a new need appears later, we price it separately. The difference is that the basis we calculate from already exists, so the figure arrives quickly and holds.

If you want complete freedom to change direction along the way, time and materials is the more honest choice. If you want to know what it will come to before you start, our model suits you better.

Two questions to ask your next supplier

How much of what you are quoting is already running somewhere else today? And what happens to the price when scope changes after go-live?

The answers tell you most of what you need to know about the figure in front of you.

If you want a point of comparison, we will carry out an assessment of your current solution. You point us to your domain and set aside two hours for a meeting. Within 72 hours of that meeting you get back an inventory of your current functionality and integrations, a functional specification for the solution going forward, a prototype showing how it would look, and a complete cost picture with a timeline. The assessment is free, and the material is yours to use whatever you decide.

Sources

Distribution of cost overruns and the workflow adjustment example: Flyvbjerg, Budzier, Lee, Keil, Lunn and Bester, "The Empirical Reality of IT Project Cost Overruns: Discovering a Power-Law Distribution", Journal of Management Information Systems, vol. 39 no. 3, 2022.

Share of projects overrunning by more than 50 percent, and the average among them: Flyvbjerg and Gardner, How Big Things Get Done, 2023, appendix A.

Share of projects that overrun, the average overrun and the gap between mean and median: Moløkken-Østvold and Jørgensen, "A Review of Surveys on Software Effort Estimation", IEEE International Symposium on Empirical Software Engineering, 2003. The comparison with the higher figures in consultancy reports is in Jørgensen and Moløkken-Østvold, "How large are software cost overruns? A review of the 1994 CHAOS report", Information and Software Technology, 2006.

Maintenance as a share of lifecycle cost: IEEE Computer Society, with comparable figures in the ISBSG project database. The 15 to 25 percent annual rule of thumb is industry practice drawn from systems with few external connections and is not a measured value for integrated portal solutions.

Number of change events per year: Litium's public release notes and Microsoft Learn for Dynamics 365 Business Central. The count is set out in our article on what a TCO calculation needs to contain.