Adaptive Project Management Is a Design Choice, Not a Methodology Fashion

The question is not whether an organisation is agile or traditional; it is whether the management system fits the uncertainty of the work.

Methodology debates often become tribal.

One group argues for tight scope, baselines and control. Another argues for iteration, experimentation and flexibility. Teams start describing themselves as agile, waterfall or hybrid, as though the label alone says something about whether the project is well designed.

It does not.

Andrew Davies's 2019 APM report separates traditional and adaptive project management around a more useful question: how predictable is the work, and how should the management approach respond to the project's uncertainty, complexity, novelty and pace?

This is an executive design problem rather than a delivery-fashion problem.

Some work should be highly controlled. Some should deliberately preserve flexibility. Large complex projects can contain both conditions at the same time.

The Strategic Context

Traditional project management is built around a powerful assumption: enough can be known early to create a meaningful baseline, and later performance can be managed largely by keeping execution aligned with it.

That assumption is appropriate in many environments.

If a facility repeats a proven design, requirements are stable, supply is well understood and interfaces are familiar, detailed planning and tight change control reduce unnecessary variation.

Problems arise when leaders apply the same logic to work where the environment itself remains uncertain.

Davies's source argues that future conditions cannot always be fully comprehended at the start. Projects can face changing technology, unresolved requirements, complex interdependencies, unfamiliar operating contexts and stakeholder needs that evolve during delivery.

In those circumstances, strict adherence to the original plan can become a source of risk. The baseline may preserve assumptions that evidence has already disproved.

Adaptive project management is therefore not permission for weak planning. It is planning that assumes learning will continue.

What Leaders Commonly Misread

The first misread is treating all uncertainty as poor project management.

Some uncertainty exists because teams have not done enough work. That should be reduced.

Other uncertainty is intrinsic to the problem. New technology may behave differently at scale. Users may not know what they need until they interact with prototypes. Several systems may produce unexpected interface behaviour when integrated. Market or policy conditions may change during a multi-year project.

The management response should distinguish avoidable uncertainty from irreducible uncertainty.

The second misread is interpreting adaptation as loss of control.

Adaptive delivery still requires governance, objectives, financial discipline, quality, risk management and accountability. The control system simply focuses more on evidence and decision thresholds than on defending the original detailed plan.

The third misread is assuming that a project needs one methodology.

Davies discusses a concept of targeted flexibility: different parts of a large complex project can use different commercial and management approaches according to their level of uncertainty. A predictable component can be tightly specified while an immature technical subsystem remains iterative.

The fourth misread is equating agile teams with an adaptive enterprise.

A project can run two-week iterations yet remain trapped by fixed annual funding, rigid architecture, slow procurement, unclear decision rights and a business case that cannot respond to learning.

Adaptation must exist at the level where consequential decisions are made.

Reframing the Issue

Project methodology should be treated as an organisational response to uncertainty.

That reframing creates a portfolio of management choices rather than a binary choice between agile and traditional.

Consider four dimensions emphasised in the adaptive project-management literature discussed by Davies:

• uncertainty: how much is unknown about what will work;
• complexity: how many components and interactions must be integrated;
• novelty: how unfamiliar the solution is to the organisation and users;
• pace: how much time pressure shapes the delivery strategy.

These dimensions can vary within one project.

A hypothetical defence technology program may use a stable civil construction package, an evolving software platform, an immature sensor subsystem and a tightly constrained regulatory certification process. Applying one uniform delivery method to the entire program would ignore the structure of the risk.

The better question is: which parts require predictability, which require learning and how will they be integrated?

Adaptation Requires Stable Boundaries

Paradoxically, adaptive work benefits from clarity about what should not constantly change.

Teams need a stable purpose. They need clarity about the outcome, safety constraints, regulatory limits, architecture principles, financial boundaries and decision rights.

Within those boundaries, requirements and solution detail may evolve as evidence improves.

This matters because "being adaptive" can otherwise become an excuse for uncontrolled scope expansion.

A strong adaptive system distinguishes:

• purpose from solution;
• constraint from preference;
• evidence-driven change from unmanaged churn;
• learning from repeated indecision;
• option preservation from avoiding commitment.

The objective is not maximum flexibility. It is the right amount of flexibility at the right point.

Related article: A Program Lifecycle Is a Strategic Learning System, Not a Bigger Project Plan

Planning Becomes a Learning Architecture

Traditional planning often treats replanning as a response to deviation.

Adaptive planning treats replanning as an expected response to information.

That does not eliminate baselines. It changes their role.

Near-term work can be planned with high detail because knowledge is stronger. Longer-term work can be represented through assumptions, milestones, options and ranges until uncertainty reduces.

This creates a rolling commitment model.

For example, the organisation might approve detailed development for a proven subsystem while funding experiments for an uncertain technology before committing to full deployment. The plan becomes a sequence of decisions that progressively convert uncertainty into commitment.

Governance should then ask:

• What did we expect to learn?
• What did the evidence show?
• Which assumption changed?
• What decision follows?
• Does the business case still hold?

This is stronger control than pretending uncertainty does not exist.

Contracts Must Support the Required Behaviour

The management model and commercial model cannot be separated.

Davies's report notes that fixed-price approaches can work when conditions are understood and design can be stabilised. It also discusses more flexible approaches where uncertainty is higher, including combinations that target different risk conditions across sub-projects.

The executive principle is that contract incentives should support the behaviour the project needs.

If the project needs joint problem-solving but the contract rewards each party for proving that uncertainty belongs to someone else, collaboration will be fragile.

If the work is mature and suppliers can genuinely control delivery risk, a more fixed arrangement may strengthen accountability.

Commercial structure should therefore be selected after uncertainty is understood, not before.

Decision Framework

Leaders can tailor a project through a simple uncertainty-to-control matrix.

Before choosing a method, ask what kind of mistake is most dangerous.

In predictable work, uncontrolled variation may be the main threat.

In uncertain work, false certainty may be more dangerous.

From Strategy to Execution

Immediate action should start by mapping uncertainty across the project rather than applying one label to the whole initiative.

For each major component, assess:

• requirement stability;
• technology maturity;
• interface complexity;
• supplier familiarity;
• regulatory certainty;
• operational novelty;
• urgency;
• reversibility of decisions.

Then decide how much definition is needed before commitment.

In the medium term, align governance and commercial arrangements with that map. Give teams authority to adapt inside clearly defined tolerances. Establish decision points where new evidence can legitimately change scope, sequencing or solution direction.

Reporting should distinguish poor execution from changed knowledge. A project that discovers early that an assumption is wrong may be healthier than one that preserves a green dashboard by delaying recognition.

Longer term, organisations should build multiple delivery capabilities. Strategic resilience depends on being able to manage stable engineering work, experimental development, complex integration and operational transition without forcing them into one governance template.

Related article: Governance Can Reduce Complexity or Become Another Layer of It

Signals to Monitor

A project may be poorly matched to its environment when:

• detailed plans are repeatedly rebuilt because core assumptions keep changing;
• teams are penalised for surfacing new evidence that challenges the baseline;
• uncertain technical packages are placed under commercial structures that discourage learning;
• stable and predictable work is being managed with unnecessary experimentation;
• "agile" is used to justify unclear outcomes or uncontrolled scope;
• governance cannot make timely decisions when evidence changes;
• integration problems appear late because sub-projects optimise independently;
• project controls report deviation without explaining whether the underlying plan remains valid.

Questions for the Leadership Team

1. Which parts of this project are genuinely predictable, and which are not?
2. Where are we treating an assumption as though it were a requirement?
3. Which decisions should remain reversible until more evidence is available?
4. Do our contracts reward the collaboration and learning the project actually needs?
5. Are decision rights fast enough for the rate at which conditions can change?
6. Where would tighter control improve performance, and where would it suppress necessary adaptation?
7. What evidence would justify moving a work package from exploratory to committed delivery?

Closing Perspective

Adaptive project management is not a rejection of discipline. It is a rejection of the idea that the same discipline should be applied in the same way regardless of context.

Executives should demand rigor in both predictable and uncertain work. The difference is what rigor means.

In stable work, rigor may mean specification, baseline control and efficiency. In uncertain work, rigor may mean explicit assumptions, experiments, staged commitment, rapid learning and deliberate replanning.

The method should follow the problem. When methodology becomes identity, organisations stop adapting before the project has even begun.

About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.

Copy link Print