Stop Slinging MUD: The Hidden Cost of Shipping a Date

Shipping a Made Up Date, or MUD, is expensive because it hides real uncertainty behind false confidence, letting unverified estimates travel from meeting notes into budgets and board forecasts. Teams then spend enormous energy defending fabricated deadlines instead of managing actual risk, causing missed launches, eroded trust, wasted resources, and costly decisions built entirely on guesses treated as facts.

1. MUD: The Most Expensive Habit in Technology

Over the course of my career I have watched intelligent, experienced people confidently announce delivery dates for projects that nobody in the room could possibly predict with any real accuracy. Sometimes those dates came from programme managers. Sometimes they came from architects. Sometimes they came from executives. Occasionally they came from me. The pattern was always the same. A senior leader wanted certainty, the room wanted the discussion to move forward, and eventually somebody volunteered a date. It sounded plausible enough to survive the meeting, so it found its way into the programme plan, the steering committee pack, the executive dashboard, and eventually the financial forecast. By the time it reached the board, nobody remembered that it had started life as an educated guess.

I have started calling these MUDs, Made Up Dates. The name is deliberately provocative because it captures what actually happens inside organisations. We throw dates around with far greater confidence than the available evidence deserves, and once they land they stick to everything. Revenue forecasts begin depending on them. Marketing campaigns are planned around them. Operational readiness activities are aligned to them. Other technology teams schedule their own work around them. One speculative estimate quietly becomes an organisational commitment.

The uncomfortable part is that this is almost never done with bad intentions. Nobody wakes up in the morning hoping to mislead their colleagues. In most cases people are trying to be helpful. They are trying to answer the question they have been asked. The problem is that organisations often ask questions that simply do not have precise answers yet. Instead of accepting uncertainty, we manufacture certainty because uncertainty feels uncomfortable. We mistake precision for competence, even when the precision itself is fictional.

Looking back, I have realised that the biggest problem was never the date itself. The biggest problem was pretending that knowledge existed before we had earned it.

2. Why Intelligent People Keep Getting This Wrong

Psychologists have been studying this behaviour for decades. Daniel Kahneman and Amos Tversky introduced the underlying idea in the late 1970s, distinguishing between the inside view, where we focus on the specific plan in front of us, and the outside view, where we look at how comparable efforts actually turned out. Roger Buehler, Dale Griffin, and Michael Ross later ran the experiments that gave the planning fallacy its name, showing that people focus on their intended plan and quietly discount the outcomes of similar past tasks, even when they know those past outcomes perfectly well. We imagine the project unfolding according to the ideal path rather than the path that similar projects actually followed. Experience helps, but surprisingly little. Experts suffer from exactly the same bias because they are just as vulnerable to optimism and incomplete information.

The practical fix has a name too. Bent Flyvbjerg calls it reference class forecasting, and the idea is simple even though the discipline behind it is not. Instead of asking only how long we think this project will take, we should also ask how long the last ten comparable projects actually took. That second question does more to correct optimism than any amount of internal debate, because it replaces a guess about the future with evidence from the past. It also gives finance a far better answer than simply widening every estimate by an arbitrary margin.

Technology adds another layer to this problem because most large engineering programmes are not simply exercises in execution. They are exercises in discovery. We begin projects believing we understand the system, only to discover hidden dependencies, undocumented business rules, legacy architectural decisions, and operational constraints that nobody fully appreciated at the outset. Every sprint generates information that literally did not exist when the estimate was produced.

The irony is that organisations treat the first estimate as though it is the most reliable one. In reality it is almost always the least reliable estimate anyone will ever produce, because it is based on the least amount of evidence. Every week of execution increases knowledge, and every increase in knowledge should improve the forecast. Yet culturally we often behave as though changing an estimate is evidence of poor planning rather than evidence of successful learning.

There is another psychological force at work here as well. Once a number has been spoken aloud, it becomes an anchor. Every subsequent discussion starts from that original estimate, even after everyone privately suspects it is wrong. Revising the forecast begins to feel like admitting failure instead of reporting new information. Before long, the organisation is no longer managing the project. It is managing people’s emotional attachment to the first date they heard.

3. Discovery Is Not Manufacturing

One of the biggest mistakes organisations make is treating all technology work as though it belongs in the same category. It does not. There is an enormous difference between improving an existing product and creating a new one.

Suppose you already have a lending platform processing millions of transactions every month. You know your approval rates, your default rates, your fraud losses, your customer behaviour, and your operational costs. If somebody proposes a small improvement to the credit decisioning model, there is uncertainty, but it is bounded by years of historical evidence. You can estimate effort reasonably well because you understand the system. You can model financial outcomes because similar changes have been made before.

Now compare that with building an entirely new product, replacing a platform that has been running for two decades, or introducing a fundamentally different architecture. There is no historical evidence, because the thing does not yet exist. There are assumptions, hypotheses, and aspirations, but there is very little objective data. The work itself exists to generate the knowledge that everyone wishes they already possessed.

Several years ago I experienced exactly this problem during what looked like a relatively straightforward front end migration. A senior engineer estimated roughly one month of work. Wanting to be conservative, I tripled it before communicating the estimate upwards, and confidently announced that three months would provide sufficient contingency. I genuinely believed I was being prudent.

The programme eventually consumed close to nine months.

Nothing catastrophic happened. Nobody failed. We simply discovered that what appeared to be a presentation layer contained years of embedded business logic that nobody realised existed. Every screen exposed another dependency. Every dependency revealed another hidden assumption. The project did not expand. Our understanding expanded. Had somebody asked us for a revised estimate every Friday, we would probably have extended the forecast every Friday as well, because reality kept revealing itself one layer at a time.

That experience permanently changed my view of software estimation. Software development does not merely produce software. It produces knowledge. Forecasts should therefore evolve as knowledge evolves.

4. The Hidden Cost of Pretending to Know

The damage caused by Made Up Dates extends far beyond missed deadlines. Once a date enters an organisation it acquires a life of its own. Finance begins recognising future revenue against it. Marketing schedules campaigns. Operations plan training. Customer communications are drafted. Other delivery teams align their dependencies. A speculative forecast quietly becomes the foundation for dozens of independent decisions.

Ironically, organisations often respond to increasing uncertainty by investing even more time in planning. Additional workshops are scheduled. Architects, senior developers, programme managers, and executives spend hours debating delivery dates in the hope that enough discussion will somehow eliminate uncertainty. It rarely does. Instead, the people best positioned to reduce uncertainty are pulled away from the work that would actually generate the missing information.

Planning is not free. Every estimation workshop has an opportunity cost, because it consumes the attention of the same engineers who could otherwise be discovering the unknowns that make future estimates more accurate. At some point the pursuit of certainty defeats itself. The organisation delays learning in order to discuss learning.

This is where I think much of modern programme governance gets itself into trouble. We often measure the maturity of a programme by the sophistication of its plans instead of the speed at which it generates reliable knowledge. Those are not the same thing. A beautiful Gantt chart is not evidence that uncertainty has been reduced. Sometimes it is merely evidence that uncertainty has been documented in exquisite detail.

None of this is an excuse for poor delivery, and I want to be direct about that. Honest uncertainty is not an exemption from accountability. There is a real difference between genuine unknowns that discovery work legitimately uncovers, and negligent investigation, uncontrolled scope growth, poor execution, dependency failures, or an estimate that was presented with far more confidence than the evidence ever supported. Teams should still be held accountable for the quality of their discovery, the speed at which they retire risk, the transparency of their assumptions, and the frequency with which they update the forecast. The objective is not to eliminate accountability. It is to stop measuring accountability against knowledge that never existed in the first place.

5. Financial Certainty Is Not Engineering Certainty

There is a section of this argument that deserves to stand on its own rather than being folded into a passing comment about finance. Finance genuinely needs forecasts. A finance team cannot walk into a board meeting and say that revenue for the next two years is simply unknown. Capital has to be allocated, budgets have to be set, and targets have to be communicated to shareholders. Forecasting is not the villain in this story.

The problem is not that finance asks for numbers. The problem is that the confidence attached to those numbers rarely reflects how much evidence actually exists behind them. A forecast built on a mature, well understood product should carry a very different confidence level to a forecast built on a product that does not yet exist.

Consider the difference between these two situations. In the first, you are forecasting revenue for an established lending product with three years of transaction history, known conversion rates, and known default behaviour. In the second, you are forecasting revenue for a brand new digital offering that has never been tested with real customers. Both forecasts will appear in the same spreadsheet, sometimes on the same slide, often with the same number of decimal places. That equal treatment is the mistake. One number is grounded in evidence. The other is closer to an aspiration wearing the clothing of a forecast.

Mature organisations separate these two categories explicitly. They attach wide ranges and clearly stated confidence levels to greenfield initiatives, and they reserve tight, high confidence numbers for work that is genuinely operational in nature. Doing this does not weaken the forecasting process. It strengthens it, because it tells the board exactly where the risk actually sits instead of hiding that risk behind false precision.

This distinction between operational forecasting and innovation forecasting is, in my view, one of the more useful ideas to take from this entire discussion. It converts an engineering complaint about estimates into a leadership principle about how an organisation should think about risk.

6. Replace Precision with Confidence

None of this is an argument against forecasting. Businesses need forecasts. Boards need investment cases. Finance needs models. Capital has to be allocated before products exist, otherwise nothing ambitious would ever be built.

The real question is not whether we should forecast. The question is how honestly those forecasts represent the evidence available at the time they are produced.

Mature organisations distinguish between evidence and assumptions. They understand that improving an existing product deserves narrower confidence intervals than inventing a completely new one. They model uncertainty explicitly rather than hiding it behind precise dates and revenue projections. They recognise that confidence should increase as knowledge increases, and they encourage forecasts to evolve as new information becomes available.

This thinking aligns closely with ideas such as Woody Zuill’s NoEstimates movement, although I would frame the conversation slightly differently. The objective is not to eliminate estimates. The objective is to stop treating low confidence forecasts as high confidence commitments simply because somebody senior asked for a date.

Every forecast should become more accurate as delivery proceeds. If a delivery date never changes from the day it was first spoken aloud, one of two things is true. Either the team learned nothing during delivery, or the team learned a great deal and chose to ignore it rather than report it. Neither is a sign of a healthy programme.

Perhaps the simplest principle is this. The first estimate is almost always the estimate based on the least information you will ever possess. Treating that estimate as a contractual promise does not reduce uncertainty. It merely disguises it.

7. Four Words Leaders Confuse

Part of the reason MUD spreads so easily is that organisations use four different words as though they were interchangeable, when they describe four genuinely different things.

A target is what the business would like to happen. A forecast is what the current evidence actually suggests. A commitment is what the organisation is prepared to organise itself around, with budgets, dependencies, and communications attached. A deadline is a genuinely immovable external constraint, such as a regulatory date or a contractual obligation.

Most of the pain I have described in this article comes from a target quietly being reported as though it were a commitment, or a forecast being treated as though it were a deadline. Separating these four words, and insisting that every date in a board pack is labelled with the right one, removes a surprising amount of organisational confusion on its own.

Alongside that separation, it helps to require a small amount of structure behind every date leaders are given. At minimum, a date should arrive with a range rather than a single point, an explicit confidence level, the evidence or comparable delivery history it is based on, the assumptions that must hold true, the material unknowns still being investigated, and the point at which the forecast will next be revisited. That is not bureaucracy. It is the difference between a number and an argument.

8. The MUD Test

Before accepting a date in a steering committee, a board pack, or a hallway conversation, it is worth asking six short questions.

1. What evidence produced this date?
2. What range surrounds it?
3. What assumptions have to hold true for it to be correct?
4. What comparable work supports it?
5. When will it next be recalculated?
6. Is this a target, a forecast, a commitment, or a deadline?

None of these questions are hostile. They simply ask an organisation to be honest about how much it actually knows at the moment it commits to knowing it. Maybe it is time we stopped throwing MUD around our organisations. Not because estimates are unnecessary, but because pretending certainty exists before knowledge does has quietly become one of the most expensive habits in technology.

9. References

1. Kahneman, D. and Tversky, A. (1979). Intuitive Prediction: Biases and Corrective Procedures. TIMS Studies in Management Science, 12, 313 to 327. Introduced the distinction between the inside view and the outside view that underpins the planning fallacy.
2. Buehler, R., Griffin, D., and Ross, M. (1994). Exploring the Planning Fallacy: Why People Underestimate Their Task Completion Times. Journal of Personality and Social Psychology, 67(3), 366 to 381. The primary empirical study that gave the planning fallacy its name. https://doi.org/10.1037/0022-3514.67.3.366
3. Kahneman, D. Thinking, Fast and Slow. 2011. Particularly the chapters covering the planning fallacy, optimism bias, and the inside versus outside view.
4. Flyvbjerg, B. (2006). From Nobel Prize to Project Management: Getting Risks Right. Project Management Institute Research Conference. A practical, practitioner facing introduction to reference class forecasting and the outside view. https://www.pmi.org/learning/library/nobel-project-management-reference-class-forecasting-8068
5. Boehm, B. W. Software Engineering Economics. 1981. The source of what later became popularised as the Cone of Uncertainty, showing how estimate accuracy tends to narrow as a project progresses.
6. McConnell, S. Software Estimation: Demystifying the Black Art. 2006. One of the definitive books on software estimation, uncertainty, and estimation ranges.
7. Zuill, W. NoEstimates. Challenges whether detailed upfront estimation improves software delivery and advocates empirical, evidence based approaches. https://medium.com/no-estimates
8. Reinertsen, D. The Principles of Product Development Flow. Explains why reducing batch size and accelerating feedback produces better outcomes than excessive upfront planning.
9. Reinertsen, D. Managing the Design Factory. Explains why product development behaves fundamentally differently from manufacturing, and why traditional scheduling techniques often fail in knowledge work.
10. Cagan, M. Inspired. A useful discussion on product discovery versus product delivery. https://www.svpg.com/books/