Adaptive Project Framework (APF) Explained

What is the Adaptive Project Framework?

The Adaptive Project Framework is a project management approach in which budget and duration are fixed at the outset, while the scope of each delivery cycle is decided jointly by the client and the team as the solution becomes clearer. Work proceeds in short, equal-length cycles; anything not finished inside a cycle returns to a prioritised pool rather than extending the schedule.

Wysocki’s framing is useful: traditional project management asks the team to follow a recipe, while APF asks them to develop one. His summary line — “TPM is for cooks, APF is for chefs” — captures the cultural difference. The framework expects requirements to be incomplete at the start and treats that incompleteness as the central problem to manage, not a planning defect to apologise for.

It emerged from two consulting engagements, a supermarket kiosk design project and a software process redesign, both with a clear goal and no clear route. Wysocki has reported APF in use across professional services, film production, pharmaceutical R&D, retail logistics, and operations planning.

What problem does APF solve?

It solves the mismatch between a fixed commercial envelope and an unknown solution. Most failures in discovery-heavy work come from pretending the solution is known so the budget can be planned in detail.

Wysocki’s model sorts projects on two axes: how clear the goal is, and how clear the solution is.

The middle row is where APF lives. Everyone agrees what success looks like — halve processing time — but nobody can specify the architecture, the vendor, or the data model in advance. Planning in detail would be fiction; planning nothing would be negligence. APF’s answer is to plan the next three weeks properly and the rest at a high level.

> Important note: APF is not “no planning”. It is just-in-time planning. The version scope phase still produces a work breakdown structure and a requirements breakdown structure — they are simply mid-level, not exhaustive.

What are the five phases of APF?

The framework has five phases. The middle three repeat until the budget or time runs out.

Three artefacts carry the method.

Conditions of satisfaction. A short, plain-language statement of what the client will accept as success, agreed before work starts. It functions as the contract for “done” where the specification cannot be written.

The project overview statement. One page, always: problem, goal, objectives, success criteria, risks. If it needs two pages, the goal is not clear enough.

The scope bank. A living, prioritised list of every requirement, idea, and change request not in the current cycle. Nothing is lost and nothing is silently added.

What are the rules that make APF work?

The flexibility is real but bounded. Four rules do the bounding, and dropping any of them turns APF into an unfunded wish list.

A cycle’s duration never changes. If the cycle is three weeks, it ends after three weeks whether or not the planned features are finished. Unfinished work returns to the scope bank. This rule protects the fixed budget and date.

Scope changes only at checkpoints. Mid-cycle requests go into the scope bank, not into the build. The team gets an uninterrupted window; the client gets a scheduled moment to change direction.

The client decides priority, the team decides approach. The client is the authority on business value, the team on feasibility. Confusing the roles produces either a client dictating architecture or a team quietly choosing what not to build.

The team plans only what it can deliver. Wysocki’s warning to technical teams — optimism has no place in the cycle plan, especially in a first cycle — is the practical version of this rule.

How does a cycle actually run?

Here is a worked example. A five-person team has a $300,000 budget over six months, run as eight cycles of three weeks each. That gives a cycle budget of $37,500.

Capacity check. Five people × 15 working days = 75 person-days per cycle. The team reserves 15% for coordination, reviews, and unplanned support, leaving 64 person-days of delivery capacity. In cycle 1 they plan 60 person-days of work — a deliberate buffer for a team that has not worked together before.

Cycle 1 build. Planned 11 items, finished 9, with 2 rolling back. Actual effort: 71 person-days against 75 gross capacity — over the 64-day delivery budget, but inside the gross. The two unfinished items go to the scope bank, not into an extension.

Client checkpoint. The client reviews the 9 delivered items, rates quality, and re-prioritises. One carry-over is now less valuable because a vendor demo changed the approach; it is dropped. A new item — audit logging, prompted by a compliance question — enters at position two.

Notice what did not happen: no re-baselining, no change approval cycle, no deadline negotiation. The fixed envelope held because scope absorbed the variance.

What happens when a cycle overruns?

It ends anyway. Suppose cycle 3 is on track to need an extra week. The arithmetic explains why the rule exists: five people × 5 days × $600 per person-day = $15,000 for one added week. Eight cycles extended by a week each would cost $120,000 — 40% of the entire budget — and push the six-month delivery to eight months.

The middle option is usually correct, and it is only available because the scope bank exists as a real, ranked list rather than a document nobody maintains.

How do you measure progress without a fixed scope?

Two measures are enough, and neither needs an earned value system.

Cycle completion rate. Items accepted divided by items committed. A team committing 11 and delivering 9 has an 82% rate; two consecutive cycles below 70% means the cycle plan is too ambitious.

Business value delivered. Record the value the client assigns to each accepted item. By cycle 6 of 8, the example project had delivered $248,000 of a $300,000 value pool — 83% — with two cycles left. That is a more honest signal than percent-complete against a plan that keeps changing.

How is APF different from Scrum and waterfall?

APF and Scrum share DNA — short iterations, client involvement, prioritised backlogs — but they operate at different levels and assume different things.

The practical distinction is the level of control. Scrum governs how a team works; APF governs how a project is funded and steered. A software team can run Scrum inside an APF envelope: the cycles set the commercial rhythm, the sprints set the team rhythm. What APF adds is an explicit answer to the question Scrum tends to leave implicit — what happens to the contract when the scope keeps changing.

When does APF fit, and when should you avoid it?

It fits when three conditions hold at once.

1. The goal is clear and the solution is not. If you cannot write a defensible conditions-of-satisfaction statement, you have a research question, not a project.
2. The client can attend checkpoints. Every three weeks, for 60–90 minutes, with authority to decide. Without that, cycles drift and the scope bank becomes a complaint file.
3. The commercial envelope is genuinely fixed. Fixed price, fixed date, or both. APF converts uncertainty into scope variation, which is only useful if scope is the variable the contract permits.

Avoid it when the work is well understood — a data centre migration, a regulatory filing, a repeatable deployment. There, the overhead of cycles and checkpoints buys nothing. Avoid it too when the client cannot be reached or when the deliverable must be specified for procurement.

> Common mistake: Running APF with a client who attends the kickoff and then delegates to a coordinator with no decision authority. The framework’s entire steering mechanism depends on a real decision at each checkpoint.

What does a client checkpoint look like?

The checkpoint is the most important hour in the cycle, with a fixed agenda:

• What did we agree to build, and what was delivered? Review the cycle’s commitments against accepted items, including quality.
• What did we learn that changes the plan? Surface technical findings and anything that shifts the value of future work.
• What should the next cycle contain, and what should we stop doing? Re-prioritise the scope bank together: the team states feasibility, the client states value.

End with a written record: what was accepted, what moved, what was dropped, and the next cycle’s goal. Ten lines is enough, and it becomes the audit trail a fixed-scope contract would have provided through change orders.

What are the trade-offs and criticisms?

APF is not a free lunch, and its weaknesses are worth naming.

• It depends on client availability. The most common failure is a client who approves the framework and then cannot attend. Cycles proceed without decisions, and the scope bank fills with unresolved items.
• It can look like scope creep to finance. A fixed budget with changing scope is normal inside APF and alarming outside it. You need a governance narrative that explains why the envelope holds while the content moves.
• Procurement and fixed-scope contracts fight it. If the contract specifies deliverables, APF’s core mechanism is legally awkward. Hybrid contracts with a defined envelope and a change-tolerant scope clause work better.
• Distributed teams struggle with the interaction density. Research on virtual project teams has noted that APF’s intensive client interaction and preference for lightweight tools fit poorly with environments that depend on documentation and asynchronous coordination.
• Small projects carry disproportionate overhead. A two-month project with four cycles spends a meaningful share of its time in checkpoints.

The honest summary: APF trades planning certainty for delivery relevance. That is a good trade in discovery work and a bad one in repeatable work.

What are the common mistakes?

• Letting the first cycle be ambitious. A new team, a new client, and an unfamiliar problem is the worst possible moment to over-commit. Plan 80% of capacity.
• Treating the scope bank as a graveyard. If items enter and never get re-ranked, the bank becomes a place where good ideas go to be forgotten.
• Extending “just this once”. The first extension teaches everyone that the rule is negotiable, and the fixed envelope quietly disappears.
• Skipping the post-version review. It is the only phase that improves the next project rather than this one, which is exactly why it gets cancelled.
• Measuring percent-complete against a plan that changes. Use cycle completion rate and business value delivered instead.

How do you run APF without a project controls team?

You need four things: a ranked scope bank, a cycle board with owners and dates, a checkpoint record, and a simple value tracker. A spreadsheet and a task board can carry a project of this size; the failure mode is tooling fragmentation, not capability.

When the scope bank lives in a document, the cycle plan in a spreadsheet, and the issues in a chat thread, the checkpoint needs an hour of reconstruction before it can start, and the review that was supposed to take 60 minutes takes 90. That erosion is what kills the cadence.

Doitify is built for this shape of work: a backlog you can re-rank, cycles with fixed end dates, tasks with owners, milestone and risk tracking, and progress reports showing what was accepted versus what was planned — in the workspace where the team already works. We make the product, so weigh that accordingly; a disciplined spreadsheet plus a task board will run APF perfectly well for a small team.

Conclusion

APF is the answer to a specific problem: a client who knows what success looks like, a budget that will not move, and a solution that has to be discovered. Its contribution is not the iteration — plenty of methods iterate — but the discipline around the fixed envelope: cycles that end on time, scope that changes only at checkpoints, and a client who decides rather than observes.

Adopt it when the goal is clear and the route is not, and only if you can get a decision-maker into a room every three weeks. Then protect two rules: never extend a cycle, and never let the scope bank go unranked. Those two habits separate a framework that manages uncertainty from a project drifting with a fashionable label attached.

If this post on adaptive project framework was helpful, you might also enjoy Project Scheduling: The Complete Guide and Project Management Life Cycle: The 5 Phases Explained.