Tailoring Schedule Management for Adaptive Delivery
Asked for a schedule, an adaptive team produces something that looks to a governance group like an absence of one: a list of themes, a cycle of two weeks, and a forecast expressed as a range. The instinct is to ask for a proper plan, and the useful response is to explain what has replaced it, because something has.
Section 2.3.3 of the PMBOK® Guide Eighth Edition covers the tailoring considerations for schedule work, and adaptive delivery mostly changes the resolution of planning at different distances, keeping all three in view.
Three horizons instead of one plan
The outcome level. Where the work is going over the next several months, expressed as outcomes with rough sizes and any fixed external dates marked. This carries no activity detail and it is what a governance group needs in order to fund and direct the work.
The cycle level. What the team has taken on now, at full detail, with the dependencies for this cycle cleared before it started. This is the only level where the plan is meant to be firm, and it is firm precisely because it is short.
The day level. What is in progress, what is blocked, who is working on what, maintained continuously by the team. It exists for coordination, not for reporting, and it changes several times a day without any of those changes being a variance.
Forecasting without an activity network
Use observed throughput and give a range. How much the team has completed per cycle over its recent history, applied to what remains, produces a window with an opening and a closing date. That is an honest instrument and it improves as history accumulates, which is the opposite of how a detailed long-range plan behaves.
Explain it once, properly, to whoever reads it. A governance group is usually content with a range and its assumptions, provided somebody has said why that form was chosen and what would narrow it. The resistance nearly always comes from having been handed a range with no explanation attached, which reads as evasion.
A tooling team and an outage window
A telecoms operator's platform team built and maintained the tooling used in its network operations centre. It worked adaptively, in fortnightly cycles, and kept its planning on a strip of brown paper taped along the wall: the near section crowded with cards for the current cycle, the middle section holding a handful spaced well apart for the next couple of months, and the far section almost bare.
That arrangement worked for everything the team controlled. It failed on the one thing it did not. Deploying a change to the correlation engine required a network outage window, which the operator granted quarterly, was requested eight weeks in advance, and was allocated by a team on the other side of the business.
Twice, work was completed and sat undeployed for the best part of a quarter, because the window had not been requested while the work was still in the far section of the paper. Nobody had been looking that far out, because the team's planning deliberately did not.
The fix was one addition to the wall. The far section gained a small set of fixed external dates written on different coloured cards: outage windows, the regulatory reporting freeze, and the annual platform upgrade. Those dates were planned backwards from, in the predictive way, while everything else stayed adaptive.
Nothing changed about how the team worked inside its cycles. What changed was that somebody was now looking at the eight-week horizon for the things that needed eight weeks of notice.
What still needs a date
External commitments. Anything somebody outside the team is planning around: a customer go-live, a regulatory submission, an event, a contractual milestone. These are dates, they are committed, and the team's flexibility is exercised inside them rather than against them.
Dependencies you do not control. Outage windows, third-party releases, approval queues, shared environments and specialist availability all run on other people's calendars. Every adaptive project needs somebody maintaining a view of those far enough ahead to act, and this is the single most common gap in otherwise well-run adaptive delivery.
For a PMP® candidate, the reading that helps is that tailoring changes the resolution of planning rather than removing it, so a scenario about completed adaptive work that cannot be deployed is describing an external dependency planned at the wrong horizon. A response that adjusts the team's cycle discipline addresses the part that was working. A structured PMP exam preparation course gives real room to situations where the team is delivering and the organisation around it runs on quarterly dates.
On an adaptive project, write down every fixed date in the next six months that somebody else owns, and how much notice each one needs. Put those on the same wall as the team's own work. It is about an hour of effort and it removes the most common way that good adaptive delivery fails to reach anybody.
Interested in going further?
Adaptive teams plan their own work well and are regularly caught by calendars belonging to other people. Omega's PMP® Exam Preparation works through scheduling across mixed horizons.
Tailoring considerations for schedule management are set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A151: Tailoring Resource Management for Agile and Hybrid Teams
A121: When a Schedule Baseline Needs to Change
A110: The PMBOK 8 Schedule Performance Domain: What It Really Covers
A077: Tailoring in Project Management: What It Actually Means
A141: Tailoring Stakeholder Engagement for Different Contexts
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
