Research20 September 2026

The cost of finding out late

Someone already knew. The project found out in month eleven.

Noah McDonough4 minute read
The short version
  • Large IT projects run 45 percent over budget, and every extra year on the schedule adds 15 percent to the overrun.
  • The most common cause is a requirement that shows up late. It was almost always known early, by someone who did not say it.
  • Surveys cannot hear it and interviews cannot reach it. Candidly AI hears from everyone in days, so month eleven becomes week one.
The pattern McKinsey documented at a bank transformation. The concern existed from the start. The project heard it ten months later.

A bank was a few months from go-live when its finance department finally got pulled in. They brought an accounting change the new performance-management system had created, and nobody had built for it. The modules had to be reworked. McKinsey, which documented the case, puts the result plainly: the launch slipped more than three months, at a cost of more than $8 million.

Nobody in finance learned about that change in month eleven. They knew in month one. The project was not set up to hear them.

That is the pattern behind most late requirements. It is worth understanding because it is the most fixable expensive thing on a project.

What late costs

McKinsey and the University of Oxford looked at more than 5,400 IT projects above $15 million. On average they ran 45 percent over budget and delivered 56 percent less value than planned. Every additional year on the schedule added 15 percent to the overrun.

15 percent

Added to the cost overrun for every additional year a project is scheduled to last.

McKinsey and University of Oxford, 5,400+ IT projects

The Standish Group sees the same thing across more than 25,000 projects. Sixty-one percent of small projects succeed. Six percent of the largest do. Standish has said since 1994 that size, which in practice means time, is the single most important factor in how a project ends.

Small61%
Moderate24%
Medium12%
Large11%
Grand6%
Share of projects delivered on time, on budget, with a satisfactory result. Standish Group CHAOS 2015, more than 25,000 projects.

So the schedule is the cost. Anything that puts weeks back on the calendar is money. Anything that pulls a surprise forward from month eleven to week one is more.

Why the surprise is always a person

Ask what causes the slippage and the answer is requirements. The Project Management Institute found 47 percent of unsuccessful projects fail because of inaccurate requirements management. But a requirement is not a document. It is something a person knows.

And people do not say what they know. In an interview study of 40 employees, Milliken, Morrison and Hewlin found 85 percent had held back an issue from a supervisor that they believed was important. Of those, 74 percent said colleagues who knew the same thing stayed quiet too. The reasons were fear of being labelled a problem, and the belief that saying it would change nothing.

85 percent

had held back an issue from a supervisor that they believed was important. Of those, 74 percent said colleagues who knew stayed quiet too.

Milliken, Morrison and Hewlin, Journal of Management Studies, 2003. Interview study, 40 employees.

Gallup found only 8 percent of employees strongly agree their organisation acts on surveys. Boston Consulting Group found three in four executives believed they had good engagement on their transformation, while only one in three had it from middle management.

Leaders think the project is aligned. The people who know it is not have decided not to say so. That is where the month-eleven requirement lives.

Why your current tools cannot find it

You have two ways to ask. A survey reaches everyone, but it cannot ask a follow-up, and only 8 percent of the people filling it in strongly believe anything will come of it. An interview gets the follow-up, but a consultant can schedule and synthesise ten or fifteen of them, it takes months, and the person asking works for the boss.

One tool cannot hear. The other cannot reach. The requirement that matters falls between them.

What changes when everyone is heard

Candidly AI runs one on one voice conversations at scale. Participants call a dedicated number whenever it suits them. The conversation adapts, asks the follow-up, and can be fully anonymous. Hundreds of people in days, not fifteen in four months. Every conversation is read by a person, and the Ground Truth Report gives you the themes with the verbatim quotes behind them, every participant quoted at least once.

Two things happen. The listening window collapses from months to days, and that time comes straight off the front of the critical path. And the person in finance who knew in month one gets asked, in a setting where saying it costs them nothing.

The research supports the mechanism. It does not put a number on how much risk that removes, and we are not going to invent one. What it does price, clearly, is the schedule.

You buy back the schedule, and you buy back the surprise.

Hear from a hundred people this month, or find out in month eleven what the other ninety thought.

Common questions

How much do large IT projects typically go over budget?

McKinsey and the University of Oxford analysed more than 5,400 IT projects with budgets above $15 million. On average those projects ran 45 percent over budget and 7 percent over time while delivering 56 percent less value than predicted. Seventeen percent overran by more than 200 percent, badly enough to threaten the company running them.

Does a longer project schedule increase cost overruns?

Yes. In the McKinsey and Oxford dataset, every additional year a project is scheduled to last increases cost overruns by an average of 15 percent. The Standish Group's CHAOS 2015 analysis of more than 25,000 projects found 61 percent of small projects succeeded against 6 percent of the largest, with 43 percent of the largest failing outright.

What is the most common cause of project failure?

Requirements. The Project Management Institute found 47 percent of unsuccessful projects fail to meet their goals because of inaccurate requirements management, and 39 percent of organisations name inadequate requirements gathering as the primary cause of failure. McKinsey found that failure to manage strategy and stakeholders, together with mastering technology and content, typically causes about half of all cost overruns.

Why do stakeholders raise concerns late instead of early?

Because they choose not to speak. In an exploratory interview study of 40 employees, Milliken, Morrison and Hewlin found that 85 percent had been in a situation where they felt unable to raise an important issue with a supervisor, and 74 percent of those said colleagues who knew about the same issue also stayed quiet. The two leading reasons were fear of being labelled negatively and a belief that speaking would change nothing.

What is Candidly AI?

Candidly AI is a Calgary-based Canadian platform that holds hundreds of one on one voice conversations with the people whose perspective a decision depends on. Participants call a dedicated number on their own schedule, the conversation adapts with follow-up questions, and the organisation receives the Ground Truth Report: themed findings backed by verbatim quotes, with every participant quoted at least once. Candidly AI is ISO 27001 Certified and SOC 2 Audited, runs on fully Canadian infrastructure with self-hosted models, and makes no third-party model API calls.

Design, Listen, Findings. Fully Canadian infrastructure, self-hosted models, no third-party model API calls. SOC 2 Audited. ISO 27001 Certified.

See how it works

Sources

We tier our sources so you can see which claims are load-bearing and which are supporting. The rule beside each tier matches the rules beside the statistics above. Where research is contested in the peer-reviewed literature, we say so and scope our use of it.

Load-bearing

Bloch, M., Blumberg, S., and Laartz, J. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey & Company. More than 5,400 IT projects above $15 million, with the BT Centre for Major Programme Management, University of Oxford.
Read the studyUsed for: 45 percent budget overrun, 7 percent time overrun, 56 percent value shortfall; $66 billion aggregate; 15 percent per additional year; 17 percent black-swan rate; the finding that the first two dimensions cause about half of cost overruns; the bank case; the diagnostic on infrequent stakeholder communication.

The Standish Group International (2015). CHAOS Report 2015. More than 25,000 projects, FY2011–2015, Modern Resolution definition.
CHAOS Report 2015 (PDF)Used for: success rates by project size; 43 percent outright failure for grand projects against 7 percent for small; size as the single most important factor; faster to production means faster payback.

Flyvbjerg, B. and Budzier, A. (2011). "Why Your IT Project May Be Riskier Than You Think." Harvard Business Review, 89(9). 1,471 projects.
hbr.orgUsed for: 27 percent average cost overrun; one in six a black swan at 200 percent cost and almost 70 percent schedule overrun.

Supporting

Milliken, F. J., Morrison, E. W., and Hewlin, P. F. (2003). "An Exploratory Study of Employee Silence: Issues that Employees Don't Communicate Upward and Why." Journal of Management Studies, 40(6), 1453–1476. Exploratory qualitative study. Interviews with 40 full-time employees across diverse industries. Placed in this tier because of sample size, not because of the quality of the work.
doi.org/10.1111/1467-6486.00387Used for: 85 percent having felt unable to raise an important issue; 74 percent reporting colleagues stayed silent too; fear of negative labelling and futility as the leading reasons.

Forth, P., Reichert, T., de Laubier, R., and Chakraborty, S. (2020). Flipping the Odds of Digital Transformation Success. BCG. 70 client transformations and 825 senior executives. Executive self-report.
bcg.comUsed for: the 30 / 44 / 26 outcome split; three in four executives believing they had good leadership engagement against one in three with committed middle-management engagement.

Project Management Institute (2014). Requirements Management: A Core Competency for Project and Program Success.
pmi.orgUsed for: 47 percent of unsuccessful projects failing due to inaccurate requirements management.

Project Management Institute. Pulse at Work: Practitioner's Guide (2017).
Practitioner's guide (PDF)Used for: 39 percent naming inadequate requirements gathering as the primary cause of failure.

Gallup (2023). "So You Administered an Employee Engagement Survey. Now What?"
gallup.comUsed for: only 8 percent of employees strongly agree their organisation takes action on surveys.

Correctives we apply to our own sources

Jørgensen, M. and Moløkken-Østvold, K. (2006). "How large are software cost overruns? A review of the 1994 CHAOS report." Information and Software Technology, 48(4). We use CHAOS for the size and duration effect and for the ranking of success factors. We do not use it for how much projects overrun: this review found the widely quoted 189 percent average cost overrun far above comparable estimation surveys, with sampling that appears biased toward failure projects.
Open-access PDFThe reason we do not use Standish overrun magnitudes.

Eveleens, J. L. and Verhoef, C. (2010). "The Rise and Fall of the Chaos Report Figures." IEEE Software, 27(1).
doi.org/10.1109/MS.2009.154Independent methodological concerns about CHAOS overrun figures.

Scope of the BCG and PMI figures used above. Both are executive self-report and carry the biases that come with asking people to grade their own programmes. No study in this set isolates the counterfactual: nobody has shown that hearing a given stakeholder seven weeks earlier saves a specific sum. What the evidence supports is narrower and still strong. Duration predicts both cost overrun and failure, late requirements are the most frequently named cause of duration growth, and the people carrying those requirements are demonstrably reluctant to volunteer them.The reason this piece prices the schedule and not the risk.

What would you ask your stakeholders?

Tell us the questions your programme is trying to answer and we will build a demo conversation around those, not a generic one.