Why Complex Projects Veer Off Course
Most UX projects don't end the way they were planned. Timelines slip, budgets stretch, and the original scope quietly morphs into something else. The pattern is consistent: projects that involve multiple stakeholders, specialized domains, or internal software are far more likely to run over schedule and over budget. Shipping on time is rarely the rule — it's the exception.
The root cause is human nature. We are wired to be optimistic, which leads to unrealistic forecasts and a failure to identify potential problems early. Hofstadter's Law captures this well: a project always takes longer than expected, even when you account for that law. In practice, only 0.5% of large projects hit their original budget and schedule targets.
Complex projects rarely follow a normal distribution of outcomes. They are "fat-tailed," meaning extreme overruns of 60–500% are common. Adding a 15–20% buffer doesn't help because the risk isn't in the average case — it's in the tail.
Grounding Estimates in Reality
The instinct to improve estimates by collecting more detailed costs and requirements is understandable, but flawed. Complex projects are full of unknown unknowns — risks and dependencies you simply cannot anticipate, no matter how thorough your analysis is. A more reliable approach is reference-class forecasting.
Reference-class forecasting is straightforward:
- Find past projects that closely resemble the one you're planning.
- If outcomes follow a Bell curve, use the mean plus a 10–15% contingency.
- If outcomes are fat-tailed, invest in robust risk management rather than relying on buffers.
- Adjust the mean only when there are strong, defensible reasons.
- Maintain a database of past project costs, timelines, and outcomes.
The goal is to anchor estimates in empirical evidence from similar work, not in hopes and projections.
Mapping the Journey Before You Build
A practical technique for reducing uncertainty is Event Storming, an approach for capturing user experience moments through the lens of business needs. The focus is on the desired business outcome, then working backward to project the events users will experience as they work toward that outcome.
The exercise maps different lanes for different points of interest: user events, risks, bottlenecks, stakeholders, and UX metrics. Teams can then identify common themes and establish a shared understanding of constraints and the people who need to be involved. User events are divided into two categories:
- Success moments — the experiences you want to amplify.
- Pain points — the frustrations you want to reduce.
Small groups of 3–4 people then prioritize these events, plotting them on Effort vs. Value curves to assess impact.
This is followed by identifying key stakeholders, evaluating risks (such as legacy systems or third-party dependencies), and determining resources and tooling. Dedicated time is set aside to pinpoint blockers that could endanger the outcome. Where possible, UX metrics are defined to track whether the work actually improves the current state.
This level of planning may seem excessive for a UX project, but it consistently reduces failure rates and delays while maximizing business impact. Thorough discovery and scoping are among the most effective risk mitigation strategies available — especially for high-visibility initiatives like legacy system replacements or new product launches.
Reducing Exposure to Black Swans
Nearly every project eventually encounters a Black Swan: a low-probability, high-consequence event that becomes more likely as project duration stretches. Restructuring, shifting priorities, and cancellations all qualify. Small problems compound into disastrous ones, which is why the early mitigation of minor issues matters so much.
The most effective countermeasures are making projects smaller and shorter, and involving stakeholders early. Less surface area means fewer opportunities for Black Swans to emerge. Every project should start with a simple question: "Why are we actually doing this?" The answers reveal motivations, but also dependencies and challenges that aren't visible in the brief.
Adopting "right-to-left thinking" also helps: start with the desired end state and work backward to the present. This keeps decisions and milestones anchored to the final goal, highlighting what's missing or blocking progress.
Compensating for Inexperience
Complex projects begin with a significant deficit of experience. To counter that, the process should be as repetitive as possible, using small work modules repeated by stable teams. Innovation is best left to other contexts:
- Unchecked optimism leads to unrealistic forecasts.
- "Cutting-edge" technology that hasn't been tested will spiral risk.
- "Unique" projects carry a high probability of exploding costs.
- "Brand new" approaches should be replaced with tested and reliable ones.
- "The biggest" initiatives should be decomposed into small pieces that are composed later.
Stable teams with a proven track record, well-tested tools, and familiar processes are essential. Complex projects are not the right setting to experiment with new processes or cheaper vendors — those are often extreme costs in disguise.
Prioritize Planning Over Production
Rushing into delivery mode before the scope is defined is a common failure point. It can work for experiments and small changes, but it's a red flag for larger work. The better approach is spending more time in planning before designing anything.
Planning should be hands-on, involving experiments, simulations, and refinements. It must explicitly address how risks will be reduced and how to respond when unexpected but predictable problems arise.
Design as Risk Management
When presenting design and research to senior leadership, frame it as risk management. Concept testing, user feedback, iteration, and refinement are inexpensive compared to delivery. Rushing into production based on untested assumptions is when a project becomes fragile and difficult to reroute. Delivery is extremely cost-intensive; poor planning makes it far worse.
The insights here draw from the book How Big Things Get Done by Bent Flyvbjerg and Dan Gardner, which analyzes why large projects fail and what separates successful ones. While not a design book, it provides valuable lessons for designers who need to plan and estimate more accurately.
Successful projects share a common trait: they spend most of their time on planning and managing risks, rather than on execution alone. They test continuously instead of pursuing big-bang reveals. You can't prevent all unknown unknowns from emerging, but you can design a process that detects and responds to them early. That's the best possible foundation for success.
