What is rolling wave planning and when should I use it?

Rolling wave planning is a form of progressive elaboration planning in which the work to be accomplished in the near term is planned in detail while future work is planned at a higher level of the work breakdown structure (WBS). This approach allows different parts of a project to exist at varying levels of detail depending on where they sit in the project life cycle. Project managers use rolling wave planning when it is not feasible or sensible to plan all work in detail from the start. Instead, details are elaborated as the project progresses and more information becomes available. This makes the method especially useful for projects with uncertainty, long timelines, or evolving requirements. The phrase rolling wave planning captures the image of a wave moving forward: the crest of detailed planning advances while the rest remains less defined.

At first glance, rolling wave planning might seem like a compromise between planning everything upfront and planning nothing at all. But it is actually a deliberate, structured approach to managing knowledge gaps. A project manager does not simply postpone planning out of laziness or indecision. Instead, they recognize that early assumptions about distant work are often unreliable, and they choose to invest planning effort where it creates the most immediate value. That subtle distinction matters because rolling wave planning still requires a full high-level roadmap from the beginning. What changes over time is the level of granularity applied to each portion of the work.

Rolling Wave Planning: Key Topics at a Glance

Understanding Rolling Wave Planning as Progressive Elaboration

The underlying mechanism of rolling wave planning is progressive elaboration, which means developing plans through iterative cycles of refinement as more details become known. This is why rolling wave planning as progressive elaboration is best understood as a movement from broad estimates to precise activity definitions. When a project is first authorized, the team usually has enough information to describe major deliverables and phases. Those deliverables form the upper levels of the WBS. For work that is months away, that high-level view is often sufficient. But as the project moves forward, the team learns more about requirements, constraints, risks, and dependencies. At that point, the upcoming work packages can be broken down further into activities, tasks, and assignments.

This refinement does not happen all at once. It happens in waves. The scheduling horizon, meaning the period of time for which detailed plans are developed, rolls forward as the project progresses. For example, a team might maintain a detailed schedule for the next four weeks and a high-level schedule for the following three months. When the first week of detailed work finishes, the team then elaborates the next week or the next phase that was previously only outlined. The wave of detail moves along the timeline, always staying just ahead of execution.

What this really means in practice is that a project plan is not a single static document but a living artifact with different resolutions. Think of it like a map on a phone. When you are zoomed out, you can see a whole city and major roads. When you zoom into the street where you are driving, you see lane-level detail, traffic signals, and buildings. Rolling wave planning lets the project manager zoom in on the portions of the project that are about to be executed while keeping the rest of the project at a broader view. The zoom level changes as the team moves forward, and that change is both expected and controlled.

How the Work Breakdown Structure Supports Multiple Levels of Detail

The work breakdown structure is central to rolling wave planning because it naturally supports hierarchical decomposition. High-level WBS elements represent major deliverables or phases. Those elements can remain less detailed for future work. Near-term work packages, however, are decomposed into smaller components, often down to the activity level. A work package for a software module might initially appear as a single element in the WBS. When that module becomes part of the upcoming planning wave, the team breaks it into activities such as requirements review, interface design, coding, unit testing, and integration.

This decomposition aligns with the PMBOK concept of creating a WBS and then defining activities. In traditional planning, many teams attempt to decompose the entire WBS into activities before execution begins. Rolling wave planning deliberately delays that decomposition for portions of the WBS that are not yet well understood or are too far in the future. The WBS remains a complete hierarchy from the start, but the lower levels are elaborated selectively. That means the WBS itself can exist at multiple levels of detail at the same time, which is exactly what the method intends.

Decomposition Timing and the Project Life Cycle

The timing of decomposition depends heavily on where the work sits in the project life cycle. Early in the project, information is scarce, and many requirements are still emerging. Detailed planning for late-stage deliverables would likely be based on guesswork. As the project moves through execution, more information becomes available from completed work, stakeholder feedback, testing results, and actual performance data. That information improves the quality of planning for subsequent work. Rolling wave planning therefore treats planning as a continuous activity rather than a one-time event at project initiation.

This also means that the level of detail in the project schedule is not uniform. A phase starting next month may have detailed activities, resource estimates, and dependencies. A phase starting six months later may only have summary tasks or milestone-level dates. That is not a sign of an incomplete plan. It is a sign that the team is applying planning effort where it is most reliable and most needed. The expectation is that the later phase will be elaborated when it enters the detailed planning window.

When Should You Use Rolling Wave Planning?

The most direct answer is that you should use rolling wave planning when you cannot plan all work in detail from the start. That condition arises more often than many project managers admit. Projects with long timelines, changing market conditions, complex technology, evolving regulatory requirements, or unclear stakeholder needs often defeat the attempt to build a fully detailed schedule on day one. In such environments, a detailed upfront plan can create a false sense of certainty. Rolling wave planning offers a more honest and practical alternative by matching planning detail to knowledge availability.

This approach is especially valuable when the project has defined phases or iterative delivery cycles. If a construction project has a clear design phase followed by procurement and construction phases, the design work can be planned in detail immediately while the construction work remains high-level until the design produces key specifications. Similarly, a product development effort can plan the first few sprints in detail while keeping the later backlog items at a feature or epic level. The rolling wave then corresponds to the natural cadence of the project.

Projects with High Uncertainty or Emerging Requirements

High uncertainty is one of the strongest triggers for rolling wave planning. In software development, research projects, or innovative product launches, requirements often emerge through feedback loops and discovery. Trying to decompose the entire project into tasks before any real learning occurs leads to rework, wasted effort, and demoralized teams. Rolling wave planning allows the team to act on what it knows now while preserving flexibility for what it will learn later. The near-term work gets the attention it needs, and the future work remains structured but not prematurely constrained.

A common scenario is a project where the technical approach for the first few deliverables is clear, but the approach for later deliverables depends on the results of early prototypes or customer feedback. Rolling wave planning lets the project manager schedule the prototype development and testing in detail. The later deliverables stay at a higher level in the WBS. Once the prototype results come in, the team then elaborates the next wave with much better information. That sequence reduces the risk of planning work that will be thrown away.

Long-Duration or Phased Projects

Long-duration projects also benefit from rolling wave planning because the distant future is inherently less predictable. A multi-year infrastructure program or a phased product rollout spanning eighteen months cannot realistically be scheduled activity-by-activity for the entire duration. Resource availability, market conditions, and even organizational priorities will shift. Rolling wave planning accepts that reality and builds the schedule in increments. The near-term phase receives detailed task planning, while later phases are represented by major milestones and high-level work packages. As each phase approaches, the schedule is expanded with the detail needed for execution.

This phased approach also improves stakeholder communication. Senior executives often do not need to see every task for a phase that is nine months away. They need confidence that the project has a coherent roadmap and that the near-term work is under control. Rolling wave planning gives them both. It avoids overwhelming sponsors with spurious detail while still demonstrating that the project team has a clear path forward. Meanwhile, the team members who are executing the current phase see exactly what they need to do.

Situations Where Detailed Upfront Planning Is Wasteful

Sometimes the reason to use rolling wave planning is simpler: detailed upfront planning would be a waste of effort. If the project environment changes frequently, much of the early detail will be obsolete before it is used. Every hour spent decomposing work packages that later get revised, cancelled, or significantly changed is an hour not spent on value-adding work. Rolling wave planning prevents that waste by deferring detailed planning until the information is stable enough to be actionable. It is a form of lean thinking applied to project schedules.

This does not mean the project starts without any planning discipline. The high-level plan still defines scope, key deliverables, major dependencies, and overall timelines. Those elements are necessary for governance, funding, and stakeholder alignment. What is deferred is the micro-level task planning that is likely to change. That distinction helps practitioners avoid the common misunderstanding that rolling wave planning is a license to skip planning. It is not about planning less overall; it is about planning the right things at the right time.

Rolling Wave Planning vs. Traditional Detailed Planning

Traditional detailed planning assumes that the project can be fully decomposed and scheduled before execution begins. That assumption works well for projects with stable requirements, repeatable processes, and low uncertainty. A warehouse relocation, a standard regulatory audit, or a well-understood construction project might justify a complete upfront schedule. But many projects do not fit that profile. Rolling wave planning versus traditional detailed planning is less about choosing one method for entire project and more about matching the planning approach to the nature of the work and the knowledge available at each stage.

The key difference lies in the distribution of planning effort. Traditional planning front-loads the effort, attempting to define all activities, dependencies, and resources at the beginning. Rolling wave planning distributes that effort across the project life cycle. The total planning effort may be similar or even higher, but it is timed to coincide with the availability of information. This reduces rework and increases the relevance of each planning session. It also means that the schedule baseline may need to be maintained differently, with more frequent updates to reflect newly elaborated detail.

Comparing Planning Horizons and Granularity

In a traditional plan, the entire project schedule is usually at the same level of granularity. Every work package is decomposed into activities, and every activity has assigned resources and durations. In rolling wave planning, the schedule is intentionally uneven. The planning horizon for detailed work may be two to four weeks, while the rest of the schedule remains at a summary level. This unevenness can be uncomfortable for stakeholders who expect to see a fully detailed Gantt chart from start to finish. But that discomfort is often a sign that the stakeholder values the appearance of certainty over the reality of reliable information.

Project managers need to set expectations about this granularity. They should explain why near-term tasks are detailed and later tasks are not. They should also define the process for rolling the wave forward, including when and how the next set of activities will be elaborated. Without that explanation, team members may worry that the plan is incomplete and sponsors may lose confidence. Communication around the planning horizon is therefore as important as the planning itself.

How Rolling Wave Planning Manages Change and Risk

Rolling wave planning is inherently more tolerant of change than a fully detailed upfront plan. When a requirement changes, only the elaborated portion of the schedule typically needs significant revision. The high-level future work is less affected because it was never decomposed into fragile task dependencies. That reduces the administrative burden of change management and allows the team to respond more quickly. It also means that risk management can be more dynamic. Risks associated with near-term work are assessed in detail, while risks in later phases are reviewed at a higher level and elaborated as those phases approach.

That alignment between planning detail and risk assessment is powerful. A detailed risk register for a phase that is eight months away is often speculative. Rolling wave planning lets the team focus risk identification and response planning on the work that is about to happen. As the wave moves forward, the risk process moves with it. This keeps risk discussions concrete and actionable rather than theoretical. It also reduces the chance that significant risks are buried under a mountain of low-value risk entries for distant work.

How Rolling Wave Planning Works in Practice

Implementing rolling wave planning requires more than just deciding to defer detail. It requires a defined schedule for when the wave will roll forward and who is responsible for elaborating the upcoming work. Without that discipline, the method can drift into reactive planning or last-minute scrambling. The rolling wave planning process begins with establishing the high-level WBS, milestones, and major deliverables. From there, the team identifies the detailed planning horizon and agrees on the intervals at which new waves will be decomposed.

A practical approach is to hold a rolling wave planning session at regular intervals, such as every two weeks or at the end of each sprint. In that session, the team reviews the upcoming work packages that now fall within the detailed horizon. They decompose those work packages into activities, identify dependencies, estimate durations, assign resources, and update the schedule baseline. The output is a more detailed plan for the next wave. The previous detailed plan is either completed or updated based on actual progress.

Setting the Planning Horizon and Wave Intervals

The planning horizon should be long enough to give the team confidence about near-term execution, but short enough to avoid excessive speculation. For many projects, a horizon of four to six weeks works well. That gives the team enough visibility to sequence work, coordinate resources, and manage dependencies without overcomplicating the schedule with far-future details. Some agile teams use a much shorter horizon, perhaps only the current iteration plus the next one. The right horizon depends on project complexity, lead times for resources, and the pace of change.

The wave interval, meaning how often the wave rolls forward, is equally important. If the interval is too long, the schedule can become stale. If it is too short, the team spends too much time in planning meetings. A monthly rolling wave update works for many projects, while agile teams often roll the wave at the start of each sprint. The key is to keep the interval consistent enough that the team and stakeholders know when to expect new detail. That predictability itself helps reduce anxiety about the incomplete portions of the schedule.

Decomposing Work Packages into Activities

When a work package enters the detailed planning window, the team performs the same decomposition that would happen in traditional planning, but only for that package. The work package is broken into activities with clear definitions, predecessor and successor relationships, durations, and resource assignments. This is where the schedule moves from summary tasks to actionable assignments. The team may use estimation techniques such as analogous estimating, parametric estimating, or three-point estimating, depending on the nature of the work. The resulting activities are then integrated into the project schedule and used for tracking.

This step requires the same rigor as any detailed planning effort. The fact that the work was planned later does not excuse sloppy decomposition or vague activity definitions. Each activity should be measurable and specific enough that a team member can understand what is expected. If the team cannot decompose a work package into meaningful activities, that is often a signal that the work package itself needs further clarification. Rolling wave planning therefore acts as an early warning system for poorly understood scope.

Updating the Schedule as New Information Emerges

After each wave, the project manager updates the schedule to reflect the newly elaborated activities. This may involve adding tasks, adjusting dependencies, refining estimates, and revising milestone dates. The high-level portion of the schedule also shifts as completed work reveals new information about future phases. Those updates should follow the project's change control process when they affect the baseline. However, the elaboration of previously high-level work packages into activities is typically not considered a scope change; it is the normal realization of the plan at a deeper level.

This distinction is important because a rigid change control process can discourage teams from elaborating the schedule properly. If every decomposition triggers a formal change request, the rolling wave process will become bureaucratic and slow. Project managers should define upfront that rolling wave elaboration is an expected and approved planning activity. Material changes to scope, schedule, or cost still go through normal change control. The act of adding detail within an already approved work package, however, is part of the planning process itself.

Rolling Wave Planning in Agile and Hybrid Environments

Agile methodologies use rolling wave planning almost by default, although they may not call it that. The product backlog represents the high-level future work, while the sprint backlog represents the near-term detailed plan. Each sprint planning session is essentially a rolling wave event in which upcoming backlog items are decomposed into tasks and estimated in detail. Rolling wave planning in agile manifests through iterative refinement, with the product owner and team continuously elaborating the backlog as more is learned from each increment.

In hybrid environments, where some phases are predictive and others are adaptive, rolling wave planning bridges the two. A project might have a detailed plan for the current predictive phase, while the later adaptive phase is represented by high-level milestones and a roadmap. As the project approaches the adaptive phase, the team shifts to backlog-based planning. The overall project schedule remains coherent because the major deliverables and dependencies are still tracked at a high level. This hybrid use of rolling wave planning is becoming more common as organizations blend traditional governance with agile delivery.

Connections to Iterative Development and Backlogs

Iterative development naturally produces the conditions for rolling wave planning. Each iteration delivers working results that generate new information. That information then informs the plan for the next iteration. The team does not need to predict the details of iteration six before iteration one has even started. Instead, the backlog serves as the high-level WBS, with epics and features representing future work. During backlog refinement, those epics and features are progressively decomposed into smaller user stories and acceptance criteria as they approach implementation.

This is not fundamentally different from predictive rolling wave planning. The difference is the cadence and the artifact. In a predictive project, the wave may roll monthly based on the project schedule. In an agile project, the wave rolls at each sprint boundary based on the accumulated learning from the previous sprint and stakeholder feedback. The principle remains the same: detailed planning for near-term work, high-level planning for future work, and continuous elaboration as information becomes available.

Scaled Agile and Rolling Wave Scheduling

At scale, rolling wave planning becomes even more important. Large agile initiatives with multiple teams and dependencies cannot realistically maintain a detailed task-level schedule for every team for a year in advance. Instead, many scaled agile frameworks use a rolling wave approach at the program and portfolio levels. Near-term program increments are planned in detail, while later increments are outlined at a feature or capability level. Each program increment planning event then elaborates the next wave of work across all teams.

That approach helps manage cross-team dependencies without forcing premature detail. Teams can coordinate on the near-term work where dependencies are concrete. Future dependencies are flagged at a high level and revisited as the wave approaches. This is far more effective than trying to resolve every dependency for the entire program upfront, which often leads to assumptions that later prove false. Rolling wave scheduling at scale aligns with the reality that complex systems reveal their true dependencies only as work progresses.

Key Takeaways on Rolling Wave Planning in Agile and Hybrid Models

Sprint planning as rolling wave

Each sprint planning session functions as a rolling wave activity, converting the highest-priority backlog items into detailed tasks and effort estimates immediately before execution so that team commitments are grounded in current information.

Backlog as high-level WBS

The product backlog serves as a dynamic, high-level work breakdown structure in which epics and features represent future scope that is progressively decomposed into user stories and acceptance criteria during refinement, allowing the team to defer detail until it is truly needed.

Bridging predictive and adaptive phases

In hybrid environments, rolling wave planning links the detailed, near-term schedules of predictive phases to the higher-level milestones and roadmaps of later adaptive phases, preserving schedule coherence across the entire project lifecycle.

Common Misconceptions and Pitfalls

One of the most common misconceptions is that rolling wave planning means the project has no detailed plan at all. Stakeholders sometimes hear "we plan in waves" and assume the team is making it up as they go. In reality, rolling wave planning requires a complete high-level plan plus a disciplined process for elaboration. Common misconceptions about rolling wave planning often stem from confusing the absence of premature detail with the absence of planning. The goal is not less planning; it is planning at the right resolution.

Another misconception is that rolling wave planning is only for agile projects. While agile teams use it naturally, the method originated in predictive project management as a way to handle uncertainty and long timelines. Construction, aerospace, pharmaceutical development, and infrastructure projects all use rolling wave planning in various forms. It is a general planning technique, not a software development practice. Recognizing that broad applicability helps project managers in traditional industries adopt the method without feeling they are abandoning sound project control.

Rolling Wave Planning Is Not an Excuse for Poor Planning

There is a real risk that rolling wave planning becomes a convenient excuse for avoiding hard conversations about scope and feasibility. A project manager might defer all difficult planning decisions to "later waves" and never actually do the detailed planning until it is too late. That is not rolling wave planning; it is procrastination. The method only works if the team is committed to elaborating the upcoming work at defined intervals. Without that commitment, the project drifts into reactive execution with no realistic ability to forecast cost, schedule, or resource needs.

To avoid this pitfall, the rolling wave plan should include clear criteria for what constitutes a completed wave. Those criteria might include the decomposition of all work packages within the planning horizon, the identification of major dependencies, the completion of resource estimates, and the update of the schedule baseline. If those criteria are not met at the interval boundary, the project has a planning problem that needs immediate attention. Holding the team accountable to these criteria separates effective rolling wave planning from wishful thinking.

Avoiding Excessive Deferral and Last-Minute Crunches

Another pitfall is setting the planning horizon too short. If the team only plans one week ahead, every week becomes a planning fire drill. Resources may be unavailable, dependencies may be missed, and the team may be forced to make decisions with insufficient lead time. The planning horizon should reflect the realistic lead times for acquiring resources, coordinating with other teams, and managing dependencies. A horizon that is too short creates the very chaos the method is supposed to prevent.

Conversely, a horizon that is too long reintroduces the problems of traditional upfront planning. The team invests effort in decomposing work that is far enough away that the assumptions are likely to change. That effort is wasted when the work inevitably shifts. Finding the right balance requires understanding the project's rate of change, the stability of the environment, and the cost of rework. It is a judgment call, and it may need adjustment as the project progresses. The planning horizon is not a fixed number set at the start; it can evolve based on observed performance and the rate of new information.

Integrating Rolling Wave Planning with Other Project Processes

Rolling wave planning does not operate in isolation. It intersects with cost estimation, resource management, risk management, procurement, and stakeholder communication. Integrating rolling wave planning with cost and risk management is essential because the schedule drives many other project artifacts. When the schedule is elaborated in waves, the associated cost estimates and risk assessments should follow the same cadence. That way, the project maintains a coherent picture of performance at every level of detail.

In PMBOK terms, the schedule management plan should define how rolling wave planning will be used. It should specify the planning horizon, the wave interval, the criteria for elaborating work packages, and the process for updating the schedule baseline. The WBS dictionary also plays a role by documenting the level of detail expected for work packages at different stages. This formal integration helps ensure that rolling wave planning is not treated as an ad hoc practice but as a structured part of the project management methodology.

Cost Estimation, Resource Planning, and Procurement

Cost estimates for near-term work can be more accurate because the activities are defined and resources are assigned. For future work, cost estimates are necessarily less precise, often based on analogous or parametric methods at the work package level. Rolling wave planning accepts this natural variation in estimate accuracy. As the wave approaches, estimates are refined from rough order of magnitude to definitive. The cost baseline then reflects this progressive refinement. This is consistent with the PMBOK concept of progressive elaboration of estimates.

Resource planning follows a similar pattern. Detailed resource assignments are made for the current wave, while future waves may only identify resource categories or high-level skill requirements. Procurement activities also benefit from rolling wave planning because long-lead items can be identified early at a high level, while detailed procurement specifications are developed as the relevant work package enters the planning horizon. This sequencing ensures that procurement decisions are based on current information rather than stale assumptions.

Risk Management and Contingency Planning

Risk management benefits from rolling wave planning because risks are assessed at the level of detail where they can actually be managed. Near-term risks are identified and quantified with specific response plans. Future risks are captured in a risk register at a higher level, often as watch items or preliminary risks. As the wave moves forward, those high-level risks are revisited and elaborated. A risk that seemed minor at a distance may become significant as the work approaches. Conversely, a risk that loomed large in the early plan may disappear once more information is available.

Contingency reserves can also be managed more dynamically. The project manager may allocate contingency at the high-level phase or work package level for future work, while near-term activities have specific contingency tied to identified risks. This allows the project to maintain an appropriate level of reserve without overcommitting resources to distant uncertainties. The result is a more transparent and defensible risk posture, which senior stakeholders tend to appreciate.

Core Insights on Rolling Wave Integration

Schedule Drives Cost and Risk

Since the schedule influences cost, risk, and related project baselines, rolling wave planning must be integrated with cost and risk management from the outset.

Matching Cadence Across Artifacts

As schedule detail emerges in waves, cost estimates and risk assessments should advance at the same cadence to maintain a consistent performance picture across all levels of detail.

Schedule Plan Formalizes the Approach

The schedule management plan should specify the planning horizon, wave interval, work package elaboration criteria, and the formal process for updating the schedule baseline.

WBS Dictionary Defines Detail Levels

By documenting the expected level of detail for work packages at each stage, the WBS dictionary turns rolling wave planning into a structured methodology rather than an ad hoc exercise.

Cost Precision and Procurement Timing

Near-term cost estimates become more accurate once activities and resources are defined, while long-lead procurement items can be identified early at a high level and refined as their work packages enter the planning horizon.

BVOPM Perspective on Rolling Wave Planning

Business Value-Oriented Project Management recognizes that work breakdown structures often contain inherent inaccuracy because they are created before sufficient information is available. In that context, rolling wave planning aligns well with the BVOPM emphasis on avoiding waste and treating scope change as feedback rather than failure. The BVOPM perspective on rolling wave planning suggests that detailed elaboration should be directly tied to the value expected from the upcoming work. Future work remains at a higher level not just because information is lacking, but also because over-planning distant work can consume effort that does not yet contribute to business value.

BVOPM also introduces a five-level scope scale ranging from definite to unlikely, which supports the idea that not all planned work has the same level of certainty. Rolling wave planning can use a similar logic by keeping uncertain scope at a higher WBS level until it becomes definite enough to decompose. This prevents the team from treating every planned feature or deliverable with the same rigor regardless of its likelihood of being needed. The result is a plan that reflects the actual confidence level of each part of the project.

Practical Guidance for Adopting Rolling Wave Planning

Adopting rolling wave planning effectively requires more than a change in scheduling technique. It requires a shift in mindset among the project team and stakeholders. Everyone involved needs to understand why the detailed plan does not extend to the end of the project. That understanding is built through clear communication, visual representations of the rolling wave horizon, and consistent delivery on the promise to elaborate upcoming work on time. When stakeholders see the wave roll forward reliably, their confidence in the method grows.

The first step is to establish the high-level plan. Define the major deliverables, phases, milestones, and the overall timeline. Make sure the WBS is complete at the summary level before any detailed planning begins. Then define the planning horizon and wave interval based on the project's rate of change, lead times, and stakeholder needs. Document these parameters in the schedule management plan. Finally, schedule the first rolling wave planning session and hold it. From that point forward, the discipline of the wave becomes the heartbeat of the schedule.

Project managers should also expect resistance from stakeholders who are accustomed to seeing fully detailed Gantt charts. Some executives will ask why the schedule does not show every task for the next year. The answer is not that detailed planning is impossible, but that it would be unreliable and potentially misleading. A schedule that looks detailed but is based on weak assumptions gives false confidence. Rolling wave planning replaces that false confidence with honest, current detail where it matters and a clear process for extending that detail as the project progresses.

Ultimately, rolling wave planning is a practical expression of the fact that project knowledge is acquired over time. Every project manager has experienced the frustration of a detailed plan falling apart because reality did not match early assumptions. Rolling wave planning accepts that reality and turns it into a managed process. It does not eliminate uncertainty, but it reduces the cost of responding to it. And it keeps the team focused on the work that is actually in front of them while maintaining a clear line of sight to the future.