Explore

Adaptive project framework (APF) explained

Learn everything you need to know about adaptive project framework — a systematic approach to help managers better respond to constant changes in projects.

Laila Robinson

The life of a project manager can sometimes feel like a constant game of getting things done just in time to avoid catastrophe.

⁠

This link can't be embedded.⁠

What it sometimes feels like to manage projects.

However, this "just in time" approach doesn't have to be stressful. If you ask product management legend

Robert K. Wysocki⁠

, it can be a huge strength.

Wysocki is the mastermind behind the adaptive project framework, which claims two things:

You don't know exactly what the future holds for your project.

You can still prepare for whatever comes your way.

He created the adaptive project framework to prioritize flexibility and iteration, making having no strict plan a planning style in itself. Let's dive into what the adaptive project framework is and why it could change how you think about managing projects forever.

What is the adaptive project framework?

The adaptive project framework (APF), also known as adaptive project management, is an approach to managing projects that face a large number of uncertainties. It arms project teams with the tools to learn from, adapt to, and resolve issues throughout the project lifecycle.

APF is for projects with clear goals but no clear solutions for reaching those goals. As in, you know where you want to go, but you're not 100% sure how to get there. Projects like these benefit from a "learn by doing" approach, where the project team finds solutions by taking action and learning from those actions.

A short history of the adaptive project framework.

Robert K. Wysocki first explored the idea of APF in a

seven-part series of articles⁠

for the Project Management Institute in 2003. He kept writing and thinking about the concept for the next seven years. In 2010, he shared his findings in a book titled

Adaptive Project Framework: Managing Complexity in the Face of Uncertainty⁠

In the introduction to his book, Wysocki explains that the idea for APF came from a simple observation: two separate projects he was working on had clear goals but no clear solution (i.e., no clear way to reach those goals). These two factors (goals vs. solutions) led him to create the following matrix.

On the X-axis is the clarity of the project's solutions. On the Y-axis is the clarity of the project's goals. Following this matrix, Wysocki says there are four overall project management categories:

MPx: Emertxe (extreme backwards) project management uses strategic solutions to find a goal during the project lifecycle.

xMP: Extreme project management defines both the goal and solution during the project life cycle.

TPM: Traditional project management, where both the goals and solutions are clear before the project starts.

APM: Adaptive project management, where the project's goals are clear, but the solutions are not.

⁠

Screenshot taken from Google Books preview of

Adaptive Project Framework: Managing Complexity in the Face of Uncertainty⁠

by Robert K. Wysocki

Even back in 2003, Wysocki recognized TPM is on its way out, saying in

his introductory article⁠

that "More and more projects fall into this classification [of needing APF]." Technology, money, teams, businesses, and culture all move too fast to account for all the requirements and issues that may arise.

In response to this uncertainty, Wysocki advocates for an uncompromising focus on the client (i.e., the people the project team is doing work for) and their needs. Let's dig into how exactly APF works.

How does the adaptive project framework work?

APF has five stages, each of which has its own series of sub-stages with specific deliverables: project scoping, cycle planning, cycled build, client checkpoint, and final review. These stages have strict rules you need to follow, but as a whole, the framework lives up to its name as a flexible tool. This flexibility allows the project team to learn from and adapt to obstacles and involve the client at every opportunity.

⁠

Wysocki’s illustration of APF from his

2003 overview article⁠

. In this graphic, the stages have their original names, which he later updated in his 2010 book.

Stage 1: Project scoping.

The first step of APF is to determine the broad strokes of what the project will involve. At the end of this stage, the project team and the client will develop a shared vocabulary for the project's objectives, requirements, resources, activities, and more.

1.1 Agree to a condition of satisfaction (CoS).

Deliverable: A negotiated agreement between the client and the project lead on what's needed and what can be done.

The condition of satisfaction is the condition that, once met, will satisfy the client. Wysocki says the best way to create a CoS is to have a face-to-face, structured conversation between the project lead and the client, whether it's a quick 15-minute sync or a weeklong retreat.

The structure is pretty simple:

The client makes a request and drives the conversation to ensure the project lead understands the request.

The project lead responds to the request with an overview of what the project team can do about it. They drive the conversation until the client understands what the team can provide.

At closure, the client and project lead negotiate any discrepancies.

A CoS is the first step to creating a shared, established vocabulary among all stakeholders. It's not official paperwork (yet). It's just an initial verbal agreement between the two representatives.

⁠

Wysocki says that this agreement⁠

, though, becomes the foundation for all the project's "problem solving, conflict resolution, and decision making."

1.2 Clarify the project overview Statement (POS).

Deliverable: A documented and approved statement summarizing CoS.

A project overview statement (POS) is a one-page summary of the CoS that all stakeholders can reference. There are five parts to a POS:

Problem/opportunity statement: One sentence summarizing the problem to be solved or opportunity to take advantage of.

Goal statement: One sentence explaining the desired result of the project.

Objective statement: Several one-sentence statements explaining the particulars of the goal statement.

Success criteria: Quantitative, measured outcomes both the project team and client will track throughout the project lifecycle.

Assumptions, risks, and obstacles: Any number of things that can get in the way of successful completion.

Project completion date.

⁠

Wysocki emphasizes⁠

the POS should be no longer than one page, saying that "In 38 years of project management practice, I can honestly say that I have always been able to write a one-page POS regardless of the scope of the project."

1.3 Define cycle parameters.

Deliverable: Agreed to and documented cycle length and number of cycles.

An APF project is split into cycles (kind of like

sprints⁠

) with clear goals. These cycles can be any length, but Wysocki says they're typically between two and six weeks. After each cycle (as we'll get into later), the project team and the client assess, reset, and make changes to the project before continuing.

Before starting the project, all stakeholders need to agree on the number of cycles and their length. Wysocki recommends starting with shorter cycles and extending their length as the project progresses to maintain momentum. But they should always fit the needs of the client first.

Important note: Once your cycle parameters are set, they're set. You cannot extend the cycle length if the project team doesn't complete all of that cycle's tasks. Instead, anything that's not completed will get reprioritized for future cycles using a scope bank (which we'll describe later).

1.4 Create a mid-level work breakdown structure (WBS) and requirements breakdown structure (RBS).

Deliverable: A partial

work breakdown structure⁠

providing an initial overview of the work that needs to be done as well as a

requirements breakdown structure⁠

listing all known project requirements.

Next, you need to create a mid-level WBS that lists all project activities based on everything you know about the project. It's important to remember that you won't be able to predict all the required activities at this point. Just do what you can with what you know.

Similar to the WBS, you also need a mid-level requirements breakdown structure (RBS) that lists all the resources and approvals required to complete the activities listed in the mid-level WBS. Again, you won't be able to accommodate everything. Just do your best.

1.5 Prioritize activities.

Deliverable: A list of critical first steps towards finding a solution.

At this point, you won't have a solution to reaching the project's goal. That's fine. Each cycle will be an opportunity to learn and inch closer to the solution. Right now, look at your mid-level WBS and RBS to identify which will get the project team started off well.

Stage 2: Cycle planning.

With the initial project scope outlined, the project team can begin the actual cycles. Before each cycle is the cycle planning stage, which is like a mini version of the project scope stage, except the client doesn't factor in as heavily.

2.1 Create the cycle WBS.

Deliverable: A cycle-specific WBS.

Select a series of activities from the overall project WBS to complete during the cycle. Remember: You cannot extend the length of the cycle. Any activities you choose that your team doesn't finish will have to get put into the scope bank for later consideration (again, more on this later). So, be realistic about what your team can achieve in one cycle when creating the cycle WBS.

2.2 Group and assign tasks to sub-teams.

Deliverable: A first past at a staffed schedule.

Now, assign tasks and groups of tasks from the cycle WBS to relevant sub-teams. Wysocki recommends keeping each group of activities as self-contained as possible. Avoid having dependencies across different teams as much as you can.

2.3 Establish task dependencies.

Deliverable: Map out each tasks' dependencies.

Map out each dependency in the upcoming cycle and make sure the team members responsible for important tasks understand the role of those tasks. This step might benefit from a

PERT⁠

Critical Path Method⁠

approaches, where you use dependencies to identify which tasks are most important to the on-time completion of the project.

2.4 Map tasks to a timeline.

Deliverable: Final schedules for each sub-team combined into one overall cycle timeline.

Create a schedule for each sub-team and map out the resources they need to complete their tasks. Make sure your timeline is detailed and thorough. Time planning is super important when in the cycle planning stage because, again, you cannot extend the length of a cycle if it takes longer than predicted to complete all the tasks.

Stage 3: Cycle build.

Now comes the stage where you do the work involved with the project. No more planning, just doing. Back in 2003, Wysocki

recommended whiteboards and sticky notes⁠

for this stage because technology back then required more work than it was worth.

Nowadays, you've got a plethora of tools to lean on, including

Miro⁠

and

Coda⁠

. Wysocki's main point was to actually do the work at this stage, don't waste time too much wrangling

overly complex project management tools⁠

Before entering the cycle build stage, Wysocki says there are two unique characteristics of APF that you need to understand:

You should never extend the length of the cycle. Any work you don't complete in time needs to get reevaluated and folded into future cycles. This is a learning opportunity for what's truly important to completing the project.

You cannot make changes to the cycle while it's running. Note all changes and obstacles the project team runs into for analysis after the cycle completes. If the issues are big enough to derail the entire cycle, return to stage two.

3.1 Micro-level schedule.

Deliverable: Task-level schedule set by the team member responsible for it.

The micro-level schedule is the responsibility of individual team members and is just a simple to-do list. It can be on a post-it note or in a project management software, but the purpose of the micro-level schedule is to be a list the team can reference during team meetings (stage 3.5).

3.2 Work packages.

Deliverable: For critical tasks, the team member responsible should create a short description of how they plan to complete the task should anything happen.

Life happens. And sometimes, it can take a team member out of the project for a couple of days or weeks. If that team member is responsible for a critical task that many other tasks are dependent upon, they should create a short write-up on their plan to tackle that task so they can hand it off to another team member. This write-up will keep momentum going should unforeseen complications arise.

3.3 Scope bank.

Deliverable: A list of potential changes to the project or cycle as well as any tasks that won't get completed by the end of the cycle.

The scope bank is one of the secret weapons of APF. Any changes you realize the team needs to make to the project will go into the scope bank to reassess the client at the end of the cycle. Any incomplete tasks will also go in the scope bank to be scheduled into future cycles if they're still relevant.

3.4 Issues log.

Deliverable: A list of any issues the team runs into during the cycle.

Conflict resolution efforts can quickly derail the progress of a cycle. On your whiteboard or in the software, create a list of issues, including details like the issue itself, who raised it, and who's responsible for resolving it.

3.5 Team meetings.

Deliverable: Short, daily stand-up team meetings with progress updates.

These team meetings will sound familiar if you know the

agile framework⁠

scrum⁠

methodologies. There are no chairs, no handouts, no chit-chat, and everyone attends. The team will go around and, referencing their own micro-level schedules and work packages, provide short updates on what they accomplished yesterday, what they're working on today, and anything they'd like to add to the scope bank or issues log.

Stage 4: Client checkpoint.

After the completion of a cycle comes what Wysocki describes as

the most crucial stage of APF⁠

, the client checkpoint. If anything most differentiates APF from TPM and other methodologies, it's this client checkpoint stage where the project lead and client meet to ass the cycle's results.

There are four questions you should answer:

Do the cumulative deliverables meet expectations?

Should the project continue to the next cycle?

What is the priority order of the remaining functionality?

What should the next cycle include?

The client check-in stage is where change, iteration, and improvement happen in the lifecycle of an APF project. By collaboratively answering these questions after each cycle, both the project team and client will gradually converge on a solution to reach the project's overall goals.

But there will likely be a lot of iteration at this stage. And that's a good thing. As Wysocki puts it, "Change is expected in an APF project. Without it, no meaningful learning and discovery could have taken place."

Stage 5: Final review.

The final review stage is relatively straightforward and is like a more extensive, final version of the client checkpoint.

You should re-address the questions in stage four as well as the following questions:

Did the team find an acceptable solution?

Did the solution meet the expected success criteria laid out in stage one?

How well did APF work for both the client and project team?

With these questions answered, you can start to assess the business value generated by this project and begin to prepare for the next.

What are the benefits of the adaptive project framework?

APF is a great project management approach for projects where you're not exactly sure how you'll reach your goal. The point is to collaboratively iterate after each cycle, keeping a tight focus on what the client needs and how they'd like the project team to meet those needs. Overall, there are three core benefits to using APF.

APF is client-focused and client-driven.

When the only "North Star" on a project is the client's goal, your project needs an intense focus on the client's needs. The entire APF system Wysocki designed revolves around client involvement. You can't even start planning without agreeing to and documenting the client's goals. As the project progresses, two factors drive all iterations:

The project team's learnings in pursuit of the client's goal.

The client's feedback between cycles.

The client's needs are always front-and-center in an APF project.

APF creates a continuous feedback loop.

Because APF prioritizes client involvement in the project, a continuous feedback loop is essential. This loop is why Wysocki built APF around cycles. These cycles have feedback built into their processes, from daily meetings to the issues log to client checkpoints.

APF prioritizes achieving business objectives.

With such an intense focus on both the client's goals and iteration towards those goals, well-run APF projects never lose sight of the underlying business value of the project. The project team is always laser-focused on what matters: the bottom line.

What are the drawbacks of the adaptive project framework?

Wysocki is the first to admit that APF only works well for a specific type of project: one where the goal is clear, but the solution isn't. If your project doesn't meet these criteria, APF might be more work than is necessary.

APF's flexibility can lead to ambiguity.

In the project planning stage, there will be a lot of blank spots. You will not know every detail of how exactly you'll accomplish the project, and that can lead to ambiguity and stress for the project team because they won't know precisely what they're responsible for right away. They'll need to learn to be OK with unanswered questions and with learning by doing.

The rigidity of APF's cycles can cause friction.

Even though APF as a whole is flexible, individual cycles aren't. Change requests to the overall project have to wait until after the cycle finishes and can only come into play during client checkpoints and future cycle planning stages. This waiting period can be frustrating for stakeholders who would like the change they requested to happen faster.

Scope creep can crop up.

Because there's no clear strategy for achieving the client's goal, the scope of the project can balloon. The project team can't answer the question of "What will it actually take to reach the goal of the project?" until they try a few cycles into the project. At that point, the budget might be at risk of running out. This threat of scope creep is why it's vitally important to answer the question, "Should the project continue to the next cycle?" in the client checkpoint stage.

When should you use the adaptive project framework?

Use the adaptive framework when you have a project with a clear goal but no clear solution. It requires a specific business environment where:

The project and client team that's comfortable in a constantly changing environment.

Both teams are comfortable with a process of experimenting to find a better solution as the project progresses.

Failure, iteration, and pivots are welcomed and even encouraged.

⁠

A few example projects (with aliases) Wysocki lists in his book⁠

as good candidates for APF include:

Snacks Fifth Avenue wanted to draw more traffic to their stores. The solution was redesigning their kiosks, which were novel at the time.

Pizza Delivered Quickly needed to compete with other up-and-coming pizza delivery chains. The answer was to implement a "pizza factory" system that provided branches with pre-made pizza dough and toppings they could bake.

Try & Buy Department Stores had siloed IT teams managing different departments, which led to inefficiency and redundant work. The solution was keeping the siloed IT teams independent but standardizing their project management approach.

Seven free templates to help you use the adaptive project framework.

These seven templates can slot right into the stages of APF. Each can help you manage and learn APF efficiently for free.

Project Plan Template

This

project plan template⁠

will work well in the project scoping stage.

Project Requirements Process Template

The

project requirement process template⁠

will help you create the RBS of the project scoping stage.

Work Package Template

This

work package template⁠

can help you create a WBS in the project scoping stage and the cycle planning stage.

Project Execution Plan Template

If you need more firepower in the cycle planning stage, you can use this

project execution plan template⁠

Task Tracking with Dependencies Template

You can combine this

task tracking and dependencies template⁠

with the project execution plan template to assign dependencies as a part of the cycle planning stage.

Basic Project Management Template

The cycle build stage can benefit from a

basic project management template⁠

, especially individual micro-level schedules for each team member. Each stakeholder can get their own, because everyone can have access to each others' you can use them as guides for the daily team meetings.

Cross-Functional Project Tracker Template

If the cycle build stage includes many different sub-teams, consider using this

cross-functional project tracker⁠

to manage dependencies across different teams.

Adaptive project framework FAQs

What are the phases in the adaptive project framework?

There are five phases to the adaptive project framework:

Project scoping

Cycle planning

Cycle build

Client checkpoint

Final review

The project team will repeat phases two through four as many times as needed.

What are the characteristics of adaptive project management?

The characteristics of adaptive project management (APM) include constant iteration, a strong feedback loop, and an uncompromising focus on the client and their needs. In the life of an APM project, the project team works closely with the client to identify the right strategies to achieve the client's goals.

Is the adaptive project framework the same as the agile methodology?

The adaptive project framework and the agile methodology are different approaches to project management, though they share similarities, such as daily stand-up meetings and an emphasis on iteration.

What is the difference between the adaptive project framework and traditional predictive project management?

Traditional predictive project management (TPM) processes assume you know both the project's goal and the correct strategy to achieve those goals. In the adaptive project management framework (APF), the project's goal is clear, but the strategy to achieve that goal isn't clear.

The work involved with a TPM-based project is about keeping the project running smoothly according to plan. The work of an APF-based project is about figuring out the plan along the way, with a "learn by doing" approach.