Risks of a custom software project, how to keep budget and timeline in check

What are the risks of a custom software project?

Cost over budget, late delivery, scope that keeps growing, disputes over what was included, dependence on the supplier, defects, software nobody uses and exposed data. Nearly all of them start before the first line of code: with a requirement nobody wrote down, a change nobody approved, a contract that does not say who pays.

Most of these risks are reduced before signing, with an analysis that turns requests into a written scope. The rest of the guide says how: which pricing model to choose, who pays for a change, what to write into the contract, how to keep the timeline and what happens when something goes wrong.

Why do budget and timeline blow up?

Because a price, or a date, is set on work that nobody has described well enough yet. Every requirement left unwritten becomes a change request halfway through. The UK government guidance on contracting for agile development says so for public procurement: an imperfect specification leads to change requests and to overruns that surface late.

The problem has been measured. McKinsey, with the University of Oxford, studied more than 5,400 IT projects. In large projects, those with an initial price above 15 million dollars, spending exceeds the budget by 45% on average and the timeline by 7%, and the value delivered is 56% less than predicted. Software projects carry the highest risk, and every additional year of duration increases the cost overrun by 15%. These projects are far bigger than a management system for an SME, but the mechanism is the same: the longer and less defined the work, the further it drifts from the estimate.

The average is misleading too. In the study of 1,471 IT projects published by Harvard Business Review the average cost overrun was 27%, but one project in six overran by 200% on average: we cover it in the guide to costs, with our own figures.

Cost overrun in IT projects

% over budget

All projects, on average27One project in six, on average200

The remedy is to decide before signing. With us the analysis that leads to the quote is free for a project of medium complexity. For a complex project or a tight timeline we run a feasibility study: it takes 1 to 2 weeks, costs up to 2,500 € and, if you sign, is deducted from the project.

Fixed price or time and materials: which is better?

A fixed price is better only if the scope is written down; time and materials suits short, exploratory work, because it leaves the whole estimating risk with you. Between the two there are models with a spending limit, and they are not the same.

With time and materials you pay the hours or days worked at an agreed rate. With a fixed price you pay one figure for a scope. With a cap you pay time and materials up to a spending threshold. With a range and a maximum the quote gives a range and the maximum is written into the contract. With capacity you reserve team time in advance.

The difference between a cap and a maximum is the one that matters. A cap, unless the contract says otherwise, limits spending, not delivery: when the cap is reached the work stops, finished or not. The maximum of the range is the price of the agreed scope. If the initial requirements do not change, the price stops at the top of the range and we absorb the excess.

Pure time and materials has a flaw that the UK guidance also points out: it may encourage the supplier to sell time rather than the outcome, and the risk of poor quality stays with the buyer. The same guidance suggests it for the discovery phase, before moving to a more structured model. We work per project if scope and timeline are clear, on capacity if they are not yet.

Who pays for a change requested halfway through?

Whoever asked for it pays, unless the contract says otherwise: you, for the changes you ask for, even with a lump-sum price (article 1661); the supplier, for those it makes on its own initiative (article 1659). This holds for a contract for works (appalto), where under Italian law the supplier works with its own organization of resources and at its own risk (article 1655 of the Civil Code). It is a contract for professional work (contratto d'opera) instead when the supplier works mainly with their own labour, like a freelancer working alone (article 2222); which of the two applies is assessed case by case. For a contract for works the Civil Code distinguishes three cases.

Two practical consequences. First: what counts is who asked for the change, and written evidence decides it, meaning emails, minutes, signed requests. Second: the one-sixth limit concerns your power to impose changes; beyond it, the supplier is not obliged to accept them, and a new agreement is needed.

The contract can regulate changes differently, and article 1659 says so explicitly (“salvo diversa pattuizione”, unless agreed otherwise): that is why the procedure must be written down. With us a change request is opened, we assess the impact together and you decide. If the change stays inside the agreed scope the cost does not change; if it goes beyond it, you know before deciding. Nothing is developed, and nothing is invoiced, without your approval.

An example: a fixed-price management system that asks for 15,000 € more

The case is made up, and it is one of the questions we put to search engines to write this guide. A company signs a fixed-price quote of 40,000 € for a custom management system. Halfway through, the supplier asks for another 15,000 €, because some requests were out of scope, and moves delivery back by two months. Who is right?

Neither, automatically. You go request by request.

Then, in this order:

• Do not sign or pay the extra straight away. Ask for an item-by-item breakdown: the original request, the new one, the cost and the effect on the dates.
• Separate price and delay. The two months can only be justified by the new requests; the others do not move the date.
• Do the one-sixth calculation. One sixth of 40,000 € is about 6,667 €: new requests worth 15,000 € are more than double that, so they are not changes you could impose, but a new agreement. If there is no written agreement, that is the first point to clear up.
• Propose a phase 2. New requests that are not needed straight away move to after the release, with a separate quote.
• Before suspending payments or disputing in writing, have a lawyer read the contract and its annexes.

It could have been avoided with a written scope including exclusions, a procedure that shows the cost of a change before it is developed and a warning about the delay as soon as it becomes likely. With us you know an out-of-scope request with its cost and its date before deciding, not after it has been developed.

What must the contract say?

What is included and what is not, how acceptance testing works and how a change is approved. Then how you pay, who owns the code, what happens if a date slips, what the warranty covers and how you exit. The price is one line; the rest of the contract decides what happens when the project changes, which is nearly always.

Late-delivery penalties appear in nearly every answer that generative engines give to this question, with figures that differ from one another. Two things to know. Under Italian law the supplier is liable for a delay even without a penalty, unless it proves the delay comes from a cause it cannot be held responsible for (article 1218, as Canella Camaiora explains). And a penalty, unless the contract also provides for further damages, limits compensation to the agreed amount (article 1382): a low penalty can protect the supplier more than you. If a date really matters to your company, write down why, and what happens if it slips.

With us you pay by milestone: a deposit on signing from 25% to 35%, payments tied to the phases and the balance after the acceptance session. Each paid milestone transfers to you ownership of the part of the project it covers, as the guide to costs explains in the section How do you pay, and when does the code become yours?

What to have handed over, and what the law says about code written by a supplier, is in the guide How to choose a software house. A recent ruling goes the client's way. On 24 June 2025 the Court of Venice applied by analogy to software commissioned under a contract for works the rule for software written by employees, giving the economic rights to the client. It also ordered interim delivery of the source code, because without it the client could not hand maintenance to anyone else. It remains one court's decision, not a rule: the transfer must still be written down.

How do you keep the timeline?

With dates that come out of the analysis, frequent deliveries and one person in your company who decides. Dates come out of a rigorous analysis of scope, timing and the roles needed, and we would rather lose a deal at estimate stage than miss a deadline invented to win it.

• Deliveries are incremental and you see working software all the way through: a typical project lasts on average about four months, and you do not spend them in the dark.
• The part that hurts most is released first, and the priorities that follow are decided by real use instead of an assumption made at a desk. A short phase is easier to estimate than a long project, which is also what the McKinsey figure on duration says.
• On your side you need someone who knows the process and can answer in days, not weeks: a question left waiting is a delay, even if it is not the supplier's.
• If a delay becomes likely you hear it straight away, with a replanning proposal, not on the delivery date. And if a deadline looks impossible to us, we propose a smaller scope or a different date.

What happens if the software has defects, or you want to stop?

Under Italian law a defect must be reported within 60 days of discovery in a contract for works, within 8 in a contract for professional work, and you can ask the supplier to remove it at its own expense. If you want to stop, you can withdraw at any time by paying expenses, work done and lost profit. These are the time limits for defects.

So acceptance testing is not a formality: a defect you see and do not report when you accept the software is no longer covered. And if you skip the tests or change requests without tracking them, Canella Camaiora notes that a judge may see contributory fault (article 1227), which reduces compensation. With us quality control before the release involves both sides, and in the warranty after release the rule is clear cut: bugs are covered by the warranty, new features are quoted.

You can also stop the project at any time, even once work has started, by compensating the supplier for expenses, work done and lost profit (article 1671). Lost profit can weigh heavily: that is why the contract should say how you exit, with what notice and what you are handed over. With ownership transferred at every milestone, if you change supplier the code you paid for is already yours.

Sources and further reading

• Italian Civil Code, article 1655, definition of the contract for worksbrocardi.it, in Italian, accessed 24 October 2026
• Italian Civil Code, article 1659, agreed changes to the projectbrocardi.it, in Italian, accessed 24 October 2026
• Italian Civil Code, article 1660, necessary changes to the projectbrocardi.it, in Italian, accessed 24 October 2026
• Italian Civil Code, article 1661, changes ordered by the clientbrocardi.it, in Italian, accessed 24 October 2026
• Italian Civil Code, article 1667, nonconformities and defects of the workbrocardi.it, in Italian, accessed 24 October 2026
• Italian Civil Code, article 1668, content of the warranty for defects of the workbrocardi.it, in Italian, accessed 24 October 2026
• Italian Civil Code, article 1671, unilateral withdrawal from the contractbrocardi.it, in Italian, accessed 24 October 2026
• Italian Civil Code, article 2222, contract for professional workbrocardi.it, in Italian, accessed 24 October 2026
• Italian Civil Code, article 2226, nonconformities and defects in the contract for professional workbrocardi.it, in Italian, accessed 24 October 2026
• Italian Civil Code, article 1382, effects of the penalty clausebrocardi.it, in Italian, accessed 24 October 2026
• Italian Civil Code, article 1218, liability of the debtorbrocardi.it, in Italian, accessed 24 October 2026
• Italian Civil Code, article 1227, contributory fault of the creditorbrocardi.it, in Italian, accessed 24 October 2026
• Court of Venice, 24 June 2025, “Software commissionato in appalto: titolarità del committente e consegna cautelare dei codici sorgente” (Software commissioned under a contract for works: the client owns it, and interim delivery of the source code), Giurisprudenza delle impresegiurisprudenzadelleimprese.it, in Italian, accessed 24 October 2026
• Margherita Manca, “La software house è responsabile se il software ‘su misura’ non funziona?” (Is the software house liable if custom software does not work?), Canella Camaiora, 18 June 2025canellacamaiora.it, in Italian, accessed 24 October 2026
• CGF Legal, “Contratto di sviluppo del software: tutele e garanzie” (Software development contract: protections and guarantees), updated 12 February 2026cgflegal.it, in Italian, accessed 24 October 2026
• Michael Bloch, Sven Blumberg and Jürgen Laartz, “Delivering large-scale IT projects on time, on budget, and on value”, McKinsey, October 2012mckinsey.com, accessed 24 October 2026
• Bent Flyvbjerg and Alexander Budzier, “Why Your IT Project May Be Riskier than You Think”, Harvard Business Review, September 2011arxiv.org, accessed 24 October 2026
• UK Cabinet Office, “Contracting for Agile Guidance Note”, updated 20 June 2023gov.uk, accessed 24 October 2026