6 Integrated Practice Cases

Choosing an approach

Project-management approaches should fit the work rather than be selected by habit. Predictive planning is useful when requirements and dependencies are relatively stable. Adaptive delivery suits work with significant uncertainty and frequent learning, while a hybrid approach combines elements of both.

Different parts of one project may have different needs. Plan consequential constraints explicitly, and use feedback and iteration where learning can change decisions. More than one approach may be defensible when it addresses the constraints and explains its trade-offs.

Hospital medication dashboard

The dashboard’s interface and alert logic are not well understood, and clinicians can review prototypes every two weeks. At the same time, deployment depends on formal security and clinical-safety reviews, and a pilot is expected in six months.

Use a hybrid approach. Develop and test the interface and alert logic in short feedback cycles with clinicians so the team can learn which information is useful before committing to a final design. Plan and track security, clinical-safety evidence, approval gates, and pilot readiness explicitly; these consequential constraints should not become informal end-of-project checks.

Make safety part of each increment’s acceptance and verification work. Keep a visible record of risks, decisions, and evidence needed for approval. A review gate should confirm readiness, not be the first time safety is examined. This balances learning with controlled release.

Consider how the decision would change if every requirement were treated as fixed from the beginning, or if approval and safety obligations were treated as flexible. If clinician feedback calls for a major redesign late in the pilot schedule, the team must respond to that feedback while making its schedule and release implications visible.

Online subscription service

The target market is uncertain, but the company can release a limited product to a small group and deploy updates regularly. The cross-functional team has twelve weeks to provide investors with evidence of customer traction, but investors have not prescribed a detailed feature list.

Use an adaptive approach with a clear near-term goal and frequent inspection of results. Start with the smallest useful release that can test important assumptions, such as whether users understand the offer and will complete a paid subscription. Order work by expected value and learning, then revise priorities when evidence changes.

Use customer behavior and feedback alongside delivery measures. Sign-ups, conversion, retention, and user-reported problems may indicate whether the offer is working; counting completed features alone does not. The twelve-week decision point matters, but it does not require fixing every feature in advance. The team can manage toward the date while adapting scope to evidence.

Decide what evidence would justify stopping, changing, or expanding the experiment. Consider how to avoid treating favorable feedback from a small group as reliable market demand. If investors request a feature that conflicts with observed customer needs, assess the conflict using the available evidence.

Municipal bridge replacement

The bridge location, structural standards, and funding ceiling are established, and construction permits are required. Subsurface conditions remain uncertain, and the design team needs to explore traffic-management options with residents and emergency services.

Use a hybrid approach. Treat the funding ceiling, applicable standards, permits, major construction sequence, and contractual controls as explicit planning and governance concerns. Investigate subsurface conditions early because they can change estimates, design, schedule, and risk exposure. Use workshops, alternatives analysis, or traffic-plan prototypes to compare options with residents and emergency services before choosing a solution.

Adaptive planning does not mean postponing necessary investigation. Use iteration where alternatives can be compared and feedback can change the decision. Once key design choices and site conditions are sufficiently understood, baseline the construction work while continuing to manage risks and approved changes.

Consider which discovery activities are most likely to prevent expensive rework, how to respond to a utility conflict discovered after construction starts, and how to invite public input while making clear which constraints cannot change.

Payroll system rollout

The organization is replacing its payroll system across four regions. Payroll calculations and cutover dates must be correct, while regional data quality and local procedures differ. A vendor team configures the software, and internal teams prepare data, training, and operations. Executives want regular progress reports and a coordinated launch.

Use a hybrid approach with coordinated governance and iterative regional preparation. Maintain an overall plan for dependencies, executive decisions, integrated testing, and launch sequence. Within that plan, let regional teams inspect and improve data, configuration, procedures, and training in manageable cycles. A pilot region can reveal issues before the remaining regions cut over.

Define readiness criteria before rollout, such as reconciled test results, approved local procedures, trained staff, and a viable support plan. Track regional risks and dependencies together so a problem in one region is not hidden by aggregate progress. If a region fails a critical readiness check, deliberately decide whether to remediate or adjust the sequence rather than relying on optimism.

Determine which decisions should be central and which should remain local. Use information from the pilot to decide whether to approve the next rollout, and communicate a delay in one region in a way that makes its effect on the overall plan clear.

Mid-project change in direction

A product team is halfway through building a customer portal. A competitor’s new service has changed customer expectations. Some contracted integrations are stable and underway, but the main navigation and highest-value features are uncertain. The sponsor asks the team to keep the original deadline and add everything customers are requesting.

Do not promise the original date and all added scope without examining the consequences. Clarify the outcome the sponsor needs, the basis for the deadline, contractual or technical constraints, and the value and urgency of the requested changes. Revisit priorities with the product decision-maker and delivery team. Continue stable integration work where it remains valuable, while using short discovery and delivery cycles to test changed customer needs.

Present feasible options, such as keeping the date with a narrower first release, moving the date to include more scope, or staging delivery. Explain the associated risks and dependencies so a scope increase is not hidden inside the team’s commitment. Scrum emphasizes a shared product goal, an ordered backlog, and inspection and adaptation; its framework does not make unlimited scope compatible with a fixed deadline.

Before agreeing to the request, consider what evidence would show whether the competitor’s feature is a genuine priority, how to protect quality if scope changes but the deadline does not, and who has authority to decide among scope, time, and risk trade-offs.

A practical decision check

Use these questions when choosing or adjusting an approach:

1. How certain is the work? Stable requirements support more upfront planning; uncertain needs call for more learning and feedback.

2. What constraints are consequential? Identify safety, regulatory, contractual, funding, integration, and deadline constraints that need explicit management.

3. Where can learning change a decision? Use increments or experiments where feedback can meaningfully shape the result.

4. How will progress and quality be visible? Track useful outcomes, risks, dependencies, and evidence of completion, not activity alone.

5. What will trigger a decision or change of course? Agree on review points and decision authority before pressure builds.

The Scrum Guide describes Scrum as a framework for addressing complex work through iterative, incremental delivery and regular inspection and adaptation. That does not mean every project should use Scrum; choose and tailor the approach to the project’s conditions.

Across project decisions, balance uncertainty, constraints, feedback, and coordination. Make assumptions visible, identify decision authority, define evidence of progress and quality, and revisit the approach when circumstances change.