Executing in an Adaptive Project
Project managers who move from predictive delivery into iterative work often describe the same disorientation. In a predictive project, execution had edges. The plan said what happened this month, the team did it, and the reporting line ran from the work back to the baseline. In iterative work everything appears to be happening at once, the plan changes while the work is under way, and there is nothing obvious to dispatch. A common response is to add meetings, which is an understandable instinct and the wrong one.
Execution in adaptive delivery has a good deal of shape. It sits inside the cycle, and the project manager's contribution moves from allocating work towards protecting the conditions in which a team can finish something small and find out quickly whether it was worth building.
The same job in a shorter rhythm
Everything a project does to convert agreed intent into delivered results sits in the Executing Focus Area at Section 4.5.3 of The Standard for Project Management: coordinating the work, leading the team, keeping people informed, managing quality, holding stakeholder relationships and building the outputs themselves. None of that belongs to a particular development approach. What changes in adaptive delivery is that the whole set runs repeatedly inside short cycles instead of once across a long stage.
Compression has consequences. A coordination problem that would have surfaced in a monthly report surfaces in two days. A misunderstood requirement becomes visible as a working process the wrong person cannot use, eleven months before a traceability matrix would have surfaced it. Information arrives faster, which is the benefit, and it arrives at a rate that demands somebody be available to act on it, which is the cost.
This is also why iterative execution punishes part-time attention. A predictive project can survive a project manager who is across it on Tuesdays. An iterative one generates decisions daily, and decisions that wait a week are decisions made by default.
Where the project manager's effort actually goes
Flow takes the largest share. Work that has started and cannot finish, because a dependency is unresolved, an environment is unavailable, an approval is sitting with somebody on leave or a decision has not been made, is the most expensive thing in an iterative team's week. Progress is measured in items finished, so a half-done item is worse than an unstarted one, and clearing the obstruction is usually worth more than anything the project manager could contribute to the work itself.
The goal of the increment takes the next largest. Each cycle is supposed to produce something coherent enough to be inspected and to answer a question. That coherence erodes quietly. An extra item gets pulled in, a piece of the original intent gets deferred, and by the review there is a collection of finished items that does not add up to anything anyone can respond to. Holding the goal steady through the middle of a cycle is real work, and it is often the least popular thing the project manager does that fortnight.
The definition of finished takes the rest. Teams under pressure move it without announcing it: testing is deferred, documentation is deferred, the accessibility check is deferred, and the increment is declared complete. None of that appears on a burn-down. It shows up two cycles later as a slowdown nobody can account for, and it is a common reason an adaptive project loses its ability to forecast.
When the work turns out to be wrong halfway through
The judgement that recurs most often in iterative execution arrives mid-cycle, when the team learns something that makes the current work look misdirected. Predictive delivery has a formal route for this: assess the change against the baseline and take it through the agreed process. Adaptive delivery has a faster route, and the speed is what makes the judgement necessary, because a team that re-opens its commitment every time it learns something never finishes anything.
What happens next turns on whether the increment can still be inspected and responded to with the discovery left where it is. Where it can, the discovery is written down with the evidence attached to it and taken to the next planning conversation, which is the right answer far more often than teams expect, because most discoveries are not urgent and the backlog exists for this. Where it cannot, because carrying on would mean knowingly building the wrong thing, the cycle stops, and that should be uncommon enough that everyone notices when it happens. Absorbing the discovery into the current cycle sits between the two and is safe only while it is small enough to leave the increment's goal untouched.
A professional-services firm was six weeks into replacing the way its consultants recorded client time. The team had released a first working version to one practice group, and in the second cycle it was extending the approval route. Four days in, a senior associate in the pilot group showed that she was recording her time correctly and the report her practice head received still had a gap in it, because time booked to a client through a secondment sat outside the structure the team had built. Nobody had described that category of work at the outset, so the report had nowhere to draw the figure from.
Fixing it on the spot was tempting, because the team could see how. The project manager asked two questions instead: whether the increment could still be inspected and responded to with the gap in place, and how many people were affected before the next planning conversation, eight days away. The answers were yes and eleven, and eleven people could be told. The secondment case went into the backlog with the associate's example attached to it, the cycle finished on its original goal, and the following week's planning treated it as a piece of scope nobody had known about, weighed against everything else waiting there.
The other course was available and would have felt more responsive. It would also have produced a cycle ending in a partially rebuilt time structure with nothing coherent to show the practice head, and a team that had learned the way to get work done was to raise it loudly in the middle of an iteration. Making that call in a few minutes, repeatedly, under pressure from somebody who has a good point, is a skill rather than a rule, and a structured PMP exam preparation course gives you somewhere to rehearse it before a live cycle asks for it.
Discipline that does not go away when the cadence changes
Iterative execution is sometimes described as though governance, finance and risk belong to the predictive world and get left behind at the door. Money is still being spent while a team iterates, and somebody still answers for the rate at which it goes. Risks still need owners and responses. Quality is still designed into the way the work is done. What changes is the form. The risk conversation happens inside the team's regular rhythm. The forecast is built from measured delivery rates. Assurance samples the working output itself instead of documents describing it.
Hybrid delivery makes this concrete, because both forms usually run side by side. A regulated programme may have a data migration executing against a fixed baseline under formal change control while the service layer iterates fortnightly, with the two funded and reported together. Execution in that environment means keeping two rhythms honest at once and resisting the urge to impose one on the other for the convenience of the reporting pack.
For a PMP® candidate, the discipline to practise is reading a scenario for what the situation requires and not for the approach label attached to it. A question set in an iterative context can still turn on escalation, procurement or a compliance obligation, and the presence of a backlog does not change who is accountable for a decision.
Judge the cycle by what came out of it, and the test is simpler than any of this. At the end of a cycle, can somebody outside the team look at what was produced, understand it, and say something useful about it? Where the answer is yes, execution is working, whatever the ceremony around it looks like. Where it is no, another meeting will not repair it, and the place to look is flow, the goal of the increment, or a definition of finished that has been quietly relaxed.
Interested in going further?
Deciding whether a mid-cycle discovery can wait for the next planning conversation, and when it should stop the cycle outright, is a judgement that improves considerably on other people's examples
The PMBOK® Guide Eighth Edition sets out the Executing Focus Area alongside the performance domains that carry on running while a team iterates.
Ad · Amazon affiliate link.
References
A063: Adaptive Does Not Mean Unplanned
A075: Closing a Project Properly Still Matters
A072: Planning in Predictive and Agile Projects
A007: The Standard for Project Management vs the PMBOK Guide
A071: Initiating Is Not Just Something You Do Once
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
