How Your Organisation Limits or Enables Agile Delivery

Most advice on choosing a delivery approach starts with the work: how stable the requirements are, how much is genuinely unknown, whether the solution can be built and released in useful pieces. That analysis matters, and it is where most project managers sensibly begin. It is also where a good many delivery approaches quietly come apart, because the work is only half the question. The other half is whether the organisation around the project can operate the approach you have selected.

The organisation does not merely influence the choice. It sets the range of approaches that can be run at all. A team can assess the work accurately, conclude that iterative delivery fits, and then discover that funding is released once a year against a fixed scope, that the person carrying the product owner title has to take every priority decision to a committee that meets monthly, and that the supplier building the core has signed a fixed-price contract with a locked specification. Nothing about that work has changed. What has changed is the realistic set of options.

Where the organisational limits actually sit

Six conditions do most of the work, and none of them appears in a requirements workshop.

Funding cadence comes first. If money is committed annually against a defined scope, incremental reprioritisation is possible inside the project but invisible to the organisation, which will keep asking whether you are delivering what was funded. Rolling or staged funding makes genuine reprioritisation cheap. Annual capital funding makes it a governance event every time.

Decision authority determines whether any of that reprioritisation can happen at speed. Adaptive delivery depends on someone being able to change priority quickly and make it stick. What matters is what that person can decide alone, what they must consult on, and how long consultation takes. A product owner with no delegated authority is a routing point, not a decision maker.

Governance and reporting expectations do more damage than they look capable of. A steering group that expects variance against a baseline every month will keep asking for a baseline, because that is the information format the organisation understands. Either the reporting changes or the delivery approach has to produce something the reporting can use.

Contracts and supplier arrangements often draw a harder boundary than anything internal. Where a substantial part of the work sits with a third party, a fixed-price scope-locked arrangement turns every change into a commercial negotiation rather than a delivery decision.

Release and adoption capacity sets the pace at which value reaches anyone. Building incrementally is worth little if the organisation can only absorb change on a fixed rhythm. Release windows, operational cutover slots, training cycles and regulatory approvals all govern that rhythm, and it usually belongs to operations.

People and structure close the list. Cross-functional teams with stable membership behave very differently from four specialists shared across six projects at twenty per cent each. Matrix resourcing does not forbid adaptive delivery, but it removes the continuity most of its practices assume.

This is the ground covered by Section 4.3.3 of The Standard for Project Management, which treats the organisation itself as one of the factors bearing on development approach selection alongside the characteristics of the product and the project. The practical reading is straightforward. Two projects with identical technical profiles, sitting in different organisations, can reasonably arrive at different approaches.

Telling a real constraint from an assumed one

The trap on the other side is treating every organisational condition as immovable. Plenty of what looks like policy is habit that nobody has questioned, and plenty of latitude goes unused because nobody claimed it. Three questions separate them.

The first question is who owns the constraint and whether they can vary it. A named owner with that authority means you are looking at a negotiation. If nobody can name the owner, you are usually looking at convention that has hardened into an assumption. "The change board has to approve everything" is often shorthand for a threshold that was set years ago and never revisited.

The second is whether the condition can change inside this project's decision horizon. An annual funding cycle is real, but a reforecast point in six months is a genuine opportunity. A supplier contract already signed is fixed. A supplier contract still in procurement is a design choice you are currently making, and one of the more consequential ones available to you.

The third is what actually happens if you work differently. Regulatory evidence requirements, safety approvals and contractual obligations have consequences that are easy to state. A reporting template has consequences that are mostly social. Both are worth respecting, but only one of them should be allowed to determine the delivery approach.

Run the same three questions in the other direction and they surface enablers, which are easier to miss. Many organisations already hold delegated spending thresholds, a standing change authority, a service team accustomed to frequent small releases, or stakeholders willing to give weekly feedback if somebody asks them properly. Where those exist, more adaptive working is available immediately without anyone approving a transformation.

Delivering inside the range you have

Consider a regional media group replacing the content system behind its publishing and broadcast output. The requirements are genuinely uncertain, the editorial teams will only know what they need once they use it, and the solution can be built in pieces. Everything about the work says adaptive. The organisation says something more complicated: capital is approved annually, the core platform is coming from a supplier on a fixed-price contract, and anything touching transmission can only go live in a Tuesday morning window that operations controls and will not move.

The honest answer here is hybrid, and not as a compromise. Build and discovery run iteratively with editorial staff involved every fortnight. Releases batch into the transmission window, so the team plans on a two-week build rhythm and a four-week adoption rhythm and stops pretending these are the same number. The supplier scope stays fixed for the core and moves to time-and-materials for integration work, where change is expected. Funding is handled with a delegated tolerance inside the annual envelope and a formal reforecast at the mid-year point.

What matters is that each adaptive practice retained is one that still pays without the enabling condition it usually assumes. Fortnightly feedback from real editorial users is worth having even when the release is monthly, because the learning arrives regardless. A prioritised backlog is worth maintaining even when the funding envelope is fixed, because it governs sequence within the envelope. Daily coordination events for a team that cannot decide anything, or two-week iterations stacking up behind a quarterly release with no feedback taken between them, produce the appearance of adaptive delivery and none of the benefit. Where the enabling condition is missing, the practice is either dropped or the condition is negotiated. Carrying it as decoration is the worst of the three.

Sometimes the right move is to change one organisational condition rather than design around it. Getting a single priority decision delegated, or persuading operations to open a second release slot during transition, can widen the range more than any amount of clever tailoring. That is a legitimate use of a project manager's influence and, where the decision sits above the project, a legitimate reason to escalate.

Making the organisational read part of the decision

The practical habit is to run the organisational assessment at the same time as the technical one, before recommending anything. Map the funding cadence, the real decision rights, the reporting expectations, the contractual position, the release capacity and the resourcing model. Mark each as fixed, negotiable or assumed. Then choose the approach that fits both the work and the space you have, and say plainly in the recommendation which organisational conditions it depends on. A sponsor who has agreed to an approach without understanding what it requires from the organisation will withdraw support the first time it collides with a governance cycle.

For a PMP candidate, this is a habit of reading rather than a rule to recall. Scenario questions that describe the organisation at all tend to describe it for a reason: the annual budget cycle, the shared team, the fixed contract or the regulator in the background is usually load-bearing rather than scene setting. The current PMP Examination Content Outline places recommending a development approach inside the Process domain, alongside assessing what the project needs and how complex it is. Omega's PMP® Exam Preparation works through approach selection as a reading of context, because the exam and the job both reward the same reading.

On a live project the payoff is earlier and more mundane. Choosing an approach the organisation can support means fewer surprises at the first steering group, fewer teams running ceremonies that cannot influence anything, and a much shorter conversation when something needs to change. Predictive, adaptive and hybrid are all legitimate answers. Which one is available to you is partly someone else's decision, made long before your project started, and the sooner you know which it was the better your own decision will be.

Andre Malowney

Interested in going further?

Approach selection is one of the areas where candidates most often learn the three labels without learning how to choose between them under real organisational conditions. Structured preparation gives you the reasoning behind the choice, which is what both scenario questions and sponsors actually test.

The PMBOK® Guide Eighth Edition sets out development approach selection and the organisational factors that shape it in more detail than a single article allows.

Ad · Amazon affiliate link.

References

A066: How Project Characteristics Shape the Delivery Approach
A064: Choosing Predictive, Agile or Hybrid for a Real Project
A085: Tailor for the Organisation Before Tailoring for the Project
A057: How to Recognise Predictive, Agile and Hybrid PMP Scenarios
A056: Predictive vs Agile vs Hybrid Project Management: How to Choose

PMP and PMBOK are registered marks of the Project Management Institute, Inc.