The persistent complaint about IT projects is not that they fail outright, though some do. It is that they fail to be predictable. A programme that finishes six months late and forty percent over budget is damaging, but a portfolio in which any given project might finish on time or might slip a year, with no reliable way to tell which in advance, is corrosive in a different way. It makes planning at the business level impossible. It teaches executives to pad every estimate and discount every commitment, which in turn teaches delivery teams that estimates are theatre. The whole system drifts into a low-trust equilibrium where nobody believes the plan and everybody protects themselves.

This matters more now than it did a decade ago for a specific reason. IT change is no longer a discrete event that a business absorbs occasionally. It is continuous, and it is entangled with revenue, regulation and customer experience in ways that leave little slack. When a core banking migration slips, or an ERP consolidation stalls, the consequences are not confined to an IT budget line. They cascade into commercial commitments, compliance deadlines and the credibility of the leadership that sponsored the work. The cost of unpredictability has risen even where the cost of individual failure has not.

The uncomfortable truth is that a great deal of unpredictability is manufactured at the outset, before a line of code is written or a server provisioned. It is manufactured by treating estimation as negotiation, by committing to scope that was never genuinely understood, and by adopting a delivery approach chosen for cultural comfort rather than for the actual character of the work. Predictability is largely determined by decisions made when the project is still cheap to shape. That is where the discipline has to start.

The foundational decision in any IT project is not which framework to adopt. It is a diagnosis of where the uncertainty lives. Broadly, uncertainty in delivery comes in two forms, and they call for opposite responses. The first is uncertainty of execution: we know precisely what we need to build, but building it is large, complex or risky. The second is uncertainty of requirement: we could build it competently if only we knew what it was, but the right answer will only become clear through feedback from real use. Confusing these two is the origin of most method-related failure.

Where the dominant uncertainty is one of execution and the requirement is genuinely stable, plan-driven delivery is not a relic to apologise for. It is the correct tool. A data centre migration, a regulatory reporting change with a fixed legal specification, or the rollout of a well understood package to new sites all have knowable scope and benefit enormously from detailed upfront sequencing, dependency mapping and critical-path management. Pretending such work is a voyage of discovery wastes the one advantage it offers, which is the ability to plan it properly.

Where the dominant uncertainty is one of requirement, the plan-driven approach becomes actively harmful, because it forces premature commitment to decisions that should remain open. Here adaptive delivery earns its place: short cycles, working increments and frequent contact with real users convert unknowns into knowns at the fastest sustainable rate. The point of iteration is not speed for its own sake. It is the systematic retirement of requirement risk. A team that iterates but never confronts its increments with genuine user feedback has adopted the ceremony without the mechanism, and gains nothing.

The honest position, and the one this article argues for, is that most substantial programmes contain both kinds of uncertainty in different proportions across their components. The mature judgement is not to declare the whole thing agile or waterfall, but to decompose it, apply plan-driven rigour where scope is stable and adaptive discovery where it is not, and manage the seam between them deliberately. That seam is where the real skill lives.

Several developments have reshaped IT project management in recent years, and it is worth separating the substantive from the fashionable. The most substantive is the shift from project thinking to product thinking in the parts of the IT landscape that are long-lived. A payments platform or a customer portal is not a project that finishes; it is a product that persists, funded continuously and owned by a stable team. For that class of work, the project construct with its fixed end date and its dispersal of the team on completion has become an active liability, because it optimises for handover rather than for the sustained ownership that keeps software healthy.

At the same time, and somewhat in tension with the product movement, the discipline of managing dependencies at scale has been formalised. As organisations run dozens of teams against a shared architecture, the binding constraint on delivery is rarely the productivity of any single team. It is the coordination cost between them: the shared services, the sequencing of integrations, the platform capabilities that multiple streams depend on. Scaled delivery frameworks are, at their useful core, an attempt to make these cross-team dependencies visible and to schedule them before they become the reason everyone is blocked.

A third change is the maturing of continuous delivery and the automation of the path to production. When deploying a change is a rare, manual, high-risk event, the economics push towards large batches and long release cycles, which in turn push towards heavy upfront planning. When deployment is automated, tested and routine, small increments become cheap to release, and the whole rhythm of delivery can shift towards the frequent feedback that adaptive work depends on. Much of what is attributed to methodology is in fact downstream of this engineering capability. A team cannot iterate meaningfully towards value if it can only release twice a year, regardless of which framework is written on the wall.

Predictable delivery is as much a property of how the work is structured as of how it is managed. The single most powerful lever is decomposition into increments that each deliver something demonstrable and, ideally, something usable. This is not a project-administration nicety. An increment that produces working software forces the integration and testing questions to be answered early and repeatedly, rather than deferred to a final phase where they detonate all at once. The classic failure of the big-bang integration, where months of separately built components are combined at the end and discovered not to fit, is a failure of increment design before it is a failure of management.

Dependency architecture is the second principle. Every dependency between teams, systems or vendors is a scheduling constraint and a risk. Good delivery design works to minimise and sequence these deliberately: identifying which components are on the critical path, which shared capabilities must exist before dependent work can start, and which external commitments, such as a vendor deliverable or a regulatory sign-off, sit outside the team's control and therefore need the earliest attention and the most conservative buffering. Dependencies that are discovered late are the most expensive kind, because by the time they surface the options for resolving them have narrowed.

The third principle is designing for reversibility where the requirement is uncertain and for robustness where it is settled. Decisions that are cheap to reverse can be made quickly and revised in light of feedback; decisions that are expensive to reverse, such as a data model at the heart of the system or the choice of a platform that everything else will depend on, deserve disproportionate scrutiny before they are locked. A well run project spends its careful analysis where reversal is costly and moves fast where it is not, rather than applying uniform ceremony to every choice. Confusing the two, agonising over the trivial while rushing the irreversible, is a common and quiet cause of trouble.

Scope creep dressed as flexibility. Adaptive delivery is frequently misused as a licence to never fix scope at all. Genuine iteration refines the solution towards a stable goal; undisciplined change substitutes one goal for another every few weeks and calls it responsiveness. The distinction is whether the changes are converging. A project where each cycle brings the outcome closer to a coherent objective is learning. A project where each cycle adds a new objective is not managing scope, it is abandoning it, and it will not finish.

The watermelon status report. Green on the outside, red on the inside. This is the natural product of judging projects on milestones passed rather than on working software and realised value. When the metric is percentage of tasks complete, a team can report ninety percent for months while the hard, integrating, value-bearing ten percent remains untouched. The remedy is not better reporting discipline. It is changing what is measured, so that progress means demonstrable, tested, usable increments rather than activity against a plan.

Dependency denial. Teams plan their own work with care and treat everything outside their boundary as someone else's problem that will resolve itself on schedule. It rarely does. The dependencies a project does not own are precisely the ones most likely to slip, and the ones a team is least able to expedite when they do. Making external dependencies explicit, assigning them owners and buffering them realistically is unglamorous work that separates programmes that hold their dates from those that do not.

Stakeholder ambiguity. Many projects run for months without a clear answer to who actually decides. When the sponsor, the users and the funders want subtly different things and no single accountable owner reconciles them, the project absorbs the conflict as churn, relitigating settled decisions and pleasing no one. Clarity about who owns the outcome, who must be consulted and who merely informed is not bureaucracy. It is the mechanism by which a project can actually make decisions and keep them made.

Estimation as commitment. An estimate is a probabilistic statement about an uncertain future. The moment it is treated as a promise, it stops being honest, because the safest estimate to promise is the padded one, and padding destroys the information the estimate was meant to carry. Healthy delivery keeps estimation and commitment separate: estimates inform planning candidly, and commitments are made deliberately, with the uncertainty acknowledged rather than negotiated away.

Nashua's approach to IT project management begins with the diagnosis rather than the method. Before recommending any delivery model, we work to establish where the uncertainty in a given programme actually resides, component by component, because that reading determines everything downstream. This is deliberately unfashionable work. It resists the impulse to declare a single methodology for the whole landscape and instead accepts that a programme may need plan-driven rigour for its stable, dependency-heavy core and adaptive discovery for the parts where requirements are still being learned. We manage the seam between those modes as a first-class concern rather than an afterthought.

In execution, we hold to a small number of non-negotiable disciplines. Increments are designed to produce working, tested software early and often, so that integration risk is confronted continuously rather than deferred. Dependencies, especially those outside the team's control, are made explicit, owned and buffered from the start. Scope is managed against a coherent objective, with change welcomed where it converges on that objective and challenged where it merely enlarges it. And we keep estimation honest by separating it from commitment, so that plans carry real information rather than defensive padding. Above all, we judge progress by demonstrable working software and evidence of realised value, not by the count of milestones passed, because the second is easy to fake and the first is not.

We also take seriously the human architecture of a project: establishing who owns the outcome, who decides, and how those decisions are kept made. Much of what looks like delivery failure is in fact unresolved stakeholder ambiguity expressed as churn, and we treat the clarification of accountability as delivery work of the first order rather than as governance overhead to be minimised.

The difference Nashua brings is not a proprietary method that promises to make uncertainty disappear. No such method exists, and the firms that claim otherwise are selling comfort rather than delivery. The difference is judgement applied consistently: the willingness to diagnose honestly, to choose plan-driven and adaptive delivery on their merits rather than by fashion, to make dependencies and accountability visible before they become excuses, and to insist throughout that a project is worth what it puts into users' hands and realises in value, not what it reports against a plan. That judgement is the product of having delivered enough programmes to know where they actually go wrong.

There is also a practical corollary that changes what the work is permitted to assume. When an engagement calls for a capability that does not yet exist, it need not wait on a procurement cycle or a vendor's roadmap. The Nashua 360 Enterprise Platform is built to accommodate almost any feature at pace, through extreme vibe coding: what is needed is described in plain language and generated quickly, but always within firm architecture principles and under stringent quality assurance, so that speed never comes at the cost of coherence, security or control. The effect is strategic rather than merely convenient. It moves the make-or-buy line, keeps optionality cheap, and lets the architecture follow the strategy rather than the strategy bending to whatever happened to be on a shelf.

What ties this together is a refusal to let delivery become theatre. It is straightforward to run a project that looks well managed, generates confident reporting and satisfies every governance checkpoint while quietly failing to produce anything of value. It is much harder, and much rarer, to run one that stays honest about its uncertainty, confronts its risks early, keeps its scope converging and measures itself against working outcomes. That harder path is the one Nashua commits to, because it is the only one that makes IT change genuinely predictable rather than merely well documented. The organisations we work with come to rely not on the promise that nothing will go wrong, but on the confidence that when something does, it will be seen early, named plainly and dealt with while it is still cheap to fix.