Project Management and PMP Frameworks

1. Predictive Project-Management Process Groups

flowchart LR
    A[Initiating] --> B[Planning]
    B --> C[Executing]
    D[Monitoring and Controlling] -.informs.-> B
    D -.informs.-> C
    B -.evidence.-> D
    C -.evidence.-> D
    C --> E[Closing]
    D --> E
    E -.next phase or approved change.-> A

    style A fill:#3b82f6,color:#fff
    style B fill:#f59e0b,color:#fff
    style C fill:#10b981,color:#fff
    style D fill:#ef4444,color:#fff
    style E fill:#6b7280,color:#fff

Schedule Variance (SV) = Earned Value (EV) - Planned Value (PV)
Schedule Performance Index (SPI) = EV / PV

Example:
PV = $100K (planned to complete)
EV = $80K (actually completed)
SV = -$20K (behind schedule)
SPI = 0.80 (doing 80% of planned work)

Cost Variance (CV) = Earned Value (EV) - Actual Cost (AC)
Cost Performance Index (CPI) = EV / AC

Example:
EV = $80K (work completed)
AC = $90K (actual spend)
CV = -$10K (over budget)
CPI = 0.89 (getting $0.89 of value per $1 spent)

2. Work Breakdown Structure (WBS)

3. Critical Path Method (CPM) & Gantt Charts

flowchart LR
  A["A Requirements (2)"] --> B["B Design (3)"]
  B --> C["C Development (5)"]
  C --> D["D Testing (2)"]
  A --> E["E Training prep (1)"]
  D --> F["F Training delivery (1)"]
  E --> F
  D --> G["G Deployment (1)"]
  F --> G

4. Earned Value Management (EVM)

Schedule Variance (SV) = EV - PV
- Positive = Ahead of schedule
- Negative = Behind schedule

Cost Variance (CV) = EV - AC
- Positive = Under budget
- Negative = Over budget

Schedule Performance Index (SPI) = EV / PV
- >1.0 = Ahead of schedule
- <1.0 = Behind schedule

Cost Performance Index (CPI) = EV / AC
- >1.0 = Under budget
- <1.0 = Over budget

Illustrative Estimate at Completion (EAC) = BAC / CPI
Where BAC = Budget at Completion

Estimate to Complete (ETC) = EAC - AC

Variance at Completion (VAC) = BAC - EAC

To-Complete Performance Index (TCPI) = (BAC - EV) / (BAC - AC)
- How efficiently must we perform on remaining work to meet budget?

SV = $480K - $600K = -$120K (behind schedule)
CV = $480K - $540K = -$60K (over budget)

SPI = $480K / $600K = 0.80
CPI = $480K / $540K = 0.89

EAC = $1,200K / ($480K / $540K) = $1,350K
(This formula assumes current cost performance persists; choose and document a different forecast when that assumption is not defensible.)

ETC = $1,350K - $540K = $810K more needed

VAC = $1,200K - $1,350K = -$150K (projected overrun)

TCPI = ($1,200K - $480K) / ($1,200K - $540K) = $720K / $660K = 1.09
(The remaining work would need CPI of approximately 1.09 to meet BAC; assess feasibility from the work and risks, not the adjective “challenging.”)

5. Risk Management Framework

flowchart LR
    P[Plan risk approach and authority] --> A[Identify risks and opportunities]
    A --> B[Analyze qualitatively]
    B --> Q{Quantitative analysis useful?}
    Q -->|Yes| C[Model ranges, dependencies, and uncertainty]
    Q -->|No| D[Plan responses]
    C --> D[Plan responses]
    D --> E[Implement<br/>Responses]
    E --> F[Monitor triggers, residual risk, and responses]
    F -.new evidence.-> A

    style A fill:#3b82f6,color:#fff
    style D fill:#f59e0b,color:#fff
    style F fill:#ef4444,color:#fff

6. Stakeholder Management (PMBOK context; constructed categories)

7. Agile/Scrum Framework

Week 1:
Mon: Sprint Planning (4 hrs)
Tue-Fri: Daily Standups (15 min) + Development

Week 2:
Mon-Thu: Daily Standups + Development
Fri: Sprint Review (2 hrs), Retrospective (2 hrs), Sprint Planning for next sprint (4 hrs)

As a [role],
I want [feature],
So that [benefit].

Acceptance Criteria:
- Given [context]
- When [action]
- Then [outcome]

Example:
As a Sales Manager,
I want to see a dashboard of team pipeline,
So that I can forecast revenue accurately.

Acceptance Criteria:
- Given I log into the CRM
- When I navigate to the Dashboard tab
- Then I see total pipeline value by stage
- And I see pipeline by rep
- And data refreshes in real-time

8. Flow Board and WIP Policy (Constructed)

9. Change Control Process

flowchart TD
    A[Record request and authority] --> B[Analyze impacts, alternatives, and evidence]
    B --> C{Authorized decision route}
    C -->|Approved| D[Update baselines, contracts, owners, and communications]
    C -->|Rejected| E[Record rationale and notify affected parties]
    C -->|Deferred| F[Record trigger and revisit date]
    D --> G[Implement through delivery controls]
    G --> H[Verify Change]
    H --> I[Monitor outcome and close or reopen]

    style A fill:#3b82f6,color:#fff
    style C fill:#f59e0b,color:#fff
    style G fill:#10b981,color:#fff

10. Project Charter Template

How To Get Started: Choosing Your Project Methodology

Delivery approach is one design decision among governance, architecture, contracting, funding, team topology, evidence, and operating transition. Tailor those dimensions separately; do not choose a branded method by adding up binary signals. ^{[1] [2]}

Rapid tailoring workshop

Timebox the workshop to the decision, not a universal 90-minute rule. Record:

Output: A one-page delivery-design decision that states which predictive, adaptive, flow, and assurance practices will be used, why each fits, and what evidence would trigger a change. Regulation, fixed dates, documentation, or stakeholder visibility do not mechanically select one method.

Detailed Version: Full Project Initiation (6-8 weeks)

Constructed-methodology boundary: The detailed initiation, execution, and measurement examples below are fictional teaching scenarios. Hours, page counts, team sizes, cadences, thresholds, dates, and task counts are not defaults; replace each with a named owner, rationale, evidence source, authority, applicability condition, tolerance, and review rule.

For larger projects requiring comprehensive planning:

Phase 1: Requirements & Charter (Weeks 1-3)

Week 1: Kickoff & Scope Definition

Workshops:

• Monday: Project scope workshop (2 hours)

  • Problem statement: "What are we solving?"
  • Success criteria: "How will we know it worked?"
  • In/Out of scope: "What's NOT included?"
  • Constraints: "What limits us?" (budget, timeline, regulatory)

• Tuesday-Wednesday: Stakeholder interviews (1 hour each, 10 stakeholders)

  • Document their needs, concerns, expectations
  • Identify potential resistance points
  • Get preliminary estimate of "flexibility"

• Thursday: Draft requirements (high-level)

  • 30-50 bullet points on what solution must do
  • NOT detailed specs, just key capabilities

• Friday: Team alignment

  • Present draft scope to team/sponsor
  • Get verbal approval to proceed

Outputs:

• Scope statement (1 page)
• Stakeholder analysis (power/interest grid)
• Preliminary requirements list (50 bullets)
• Constraints document (budget, timeline, risks)

Week 2 template: Requirements, evidence, and near-term work design

• Select requirements, backlog, model-based, prototype, experiment, or other representations appropriate to the decision and assurance needs.
• Define traceability only to the level required for scope, design, testing, acceptance, safety, regulation, contract, and change authority.
• Obtain approvals from the actual authorized roles; not every stakeholder signs every requirement.
• Choose document depth from complexity, risk, volatility, supplier interfaces, and evidence obligations. Page count is not a quality target.
• Expect controlled learning and change. “Zero requirement changes” is not a valid universal objective.
• User stories and story points are optional local techniques, not Agile or Scrum requirements. Prioritize enough near-term work to support delivery and learning without fixed story counts or known/unknown percentages.

Week 3: Planning & Charter

Waterfall Path:

1. Project Charter: Use Framework #10 template

   • Business case, objectives, stakeholders, budget, timeline
   • Get sponsor sign-off (formal authority)

2. Work Breakdown Structure (WBS):

   • Decompose all scope into 3-4 levels
   • Include Project Management as main deliverable
   • Size work packages to support estimation, ownership, control, and progress visibility; no universal 8–80-hour rule applies
   • Total estimated effort: baseline for schedule

3. Schedule Development:

   • Create task list from WBS (150+ tasks)
   • Estimate duration (days) for each task
   • Identify dependencies (which must finish before others start)
   • Run CPM analysis (identify critical path)
   • Add a contingency buffer on critical path tasks based on risk exposure
   • Create Gantt chart with milestones

4. Budget:

   • Resource-loaded costs (staff, contractors, tools)
   • Vendor costs (licenses, hardware, services)
   • Contingency based on risk exposure
   • Get CFO approval

Agile Path:

1. Product Vision Document (1 page)

   • "What are we building and why?" (elevator pitch)
   • Success metrics (adoption, revenue, customer satisfaction)
   • Timeline: How long until feature-complete? Release 1.0?

2. Release Plan:

   • Define MVP scope (what's in Release 1.0?)
   • High-level roadmap (quarters or releases)
   • Target launch date
   3. Team Setup:
   • Product Owner assigned for product-value decisions
   • Scrum Master identified for Scrum and team effectiveness
   • Developers and other delivery specialists assembled as the product and assurance context requires

3. Infrastructure:

   • Set up Jira/Azure DevOps board
   • Create epics + user stories
   • Configure WIP limits
   • Schedule sprint meetings

Phase 2: Project Setup & Kick-off (Weeks 4-6)

Week 4: Risk & Communications Planning

Risk Management Setup:

1. Conduct risk identification workshop (2 hours)

   • Brainstorm top 15-20 risks (threats + opportunities)
   • Categorize: Technical, Resource, Schedule, Budget, External
   • Document on risk register

2. Risk Analysis:

   • If useful, define local ordinal probability and impact scales with owners, evidence, triggers, and review dates; the scale is not a measured probability or exposure model
   • A sample P × I score can support triage only when its interpretation and escalation rule are approved; it does not quantify risk by itself
   • Prioritize risks through the defined method, considering correlation, dependencies, severity, opportunity, and decision value

3. Risk Response Planning:

   • For high-score risks: develop mitigation strategy
   • Assign risk owner (who monitors it?)
   • Define contingency (if risk occurs, what's our backup plan?)

Communication Planning:

For Waterfall projects:

• Sponsor: Weekly email + monthly 1-on-1
• Steering Committee: Monthly meetings (30 min)
• Project team: Weekly 60-min status meeting
• Stakeholders: Monthly updates (email or town hall)

For Agile projects:

• Product Owner: Daily (quick syncs as needed)
• Stakeholders: Sprint reviews every 2 weeks (demo of completed work)
• Team: Daily standup (15 min)
• Leadership: Decision-relevant outcome, forecast, flow, quality, risk, and capacity evidence; do not use team velocity as an executive productivity score

Week 5: Procurement & Vendor Setup

• Identify make-vs-buy decisions (build in-house vs. buy/outsource)
• If buying: RFP, vendor evaluation, contracting
• If outsourcing: Statement of Work (SOW), KPIs, governance
• Set up vendor kick-off meetings

Week 6: Final Approvals & Kick-off

• Final review of charter/plan with steering committee
• Get formal approvals (Sponsor, CFO, CTO)
• Announce project to all stakeholders
• Kick-off meeting (1-2 hours)
  • Explain project goals, timeline, how to participate
  • Introduce team leads and key stakeholders
  • Set expectations for communication/engagement

Phase 3: Execution (Months 2-6+)

Waterfall Projects:

Weekly Activities:

• Standup: 30-min team sync (what did we complete? what's next? blockers?)
• Status Update: Document schedule/cost variance using EVM metrics
• Risk Review: Check risk register, look for new risks
• Scope Management: Triage change requests through CCB

Monthly Activities:

• Sponsor 1-on-1: Review status, discuss issues, get decisions
• Steering Committee: Present metrics, escalate risks >10

Control Activities:

• Track actual effort vs. planned (budget variance)
• Track schedule progress (milestone completion)
• If SPI or CPI differs materially from the approved tolerance: verify data and EVM assumptions, diagnose drivers, update forecasts, and choose a response through the authorized owner. A 0.95 threshold does not automatically require recovery or cost reduction.

Agile Projects:

Daily Activities:

• Standup: 15 min (completed yesterday, doing today, blockers)
• Dev work: Build user stories from sprint backlog

Sprint Cycle (2 weeks):

Monday (Sprint Planning):

• 2-4 hours depending on sprint length
• Select user stories from product backlog
• Team estimates effort (story points)
• Commit to sprint goal (e.g., "Deploy user registration features")

Tuesday-Thursday:

• Daily standup (15 min)
• Dev work
• Code reviews
• Testing

Friday (Sprint Review + Retrospective):

• Sprint Review (60 min): Demo completed work to stakeholders + product feedback
• Retrospective (60 min): Team discusses "What went well?" "What to improve?"
  • Capture 2-3 action items for next sprint
• Next Monday: Sprint Planning begins again

Velocity Tracking:

• If the team uses story points, observe them only within that team and estimation system.
• Do not require stabilization after a fixed number of sprints or convert points directly into calendar duration without scope, uncertainty, capacity, dependencies, and historical forecast error.

Common Pitfalls & How to Avoid Them

Waterfall Pitfalls

Pitfall 1: Frozen Requirements That Are Wrong

• Problem: Spent 2 months documenting requirements, market changed, requirements are obsolete
• Response: Route proposed changes by decision authority, materiality, evidence, dependency, and assurance need. A requirements freeze is one possible control, not a default; preserve traceability while allowing governed learning.
• Risk if unresolved: Rework, delay, or obsolete output can result, but magnitude and timing depend on the project and evidence.

Pitfall 2: No Executive Sponsor Engagement

• Problem: PM manages project, sponsor ignores it, then says "This isn't what we wanted" at end
• Response: Agree the sponsor's decisions, access, evidence, escalation route, and approval cadence from governance, consequence, and uncertainty rather than imposing weekly or monthly meetings.
• Risk if unresolved: Unclear authority or delayed decisions can cause rework, pause, or cancellation; no fixed three-to-six-month loss is assumed.

Pitfall 3: Schedule Overruns from Critical Path

• Problem: Over-estimated task durations, didn't identify true critical path, project slips
• Response: CPM identifies modeled critical and near-critical dependency paths under current duration and sequencing assumptions. Test uncertainty, resource constraints, merge points, calendars, and path changes before intervening.
• Resource caveat: Adding people, equipment, overlap, or buffers can help, do nothing, or increase coordination and risk. Compare crashing, fast-tracking, resequencing, scope, capacity, and acceptance effects rather than adding resources only to one path.

Pitfall 4: Vendors Not Held Accountable

• Problem: Vendor misses deadlines, PM has no leverage
• Fix: Clear SOW, measurable KPIs, contractual penalties/rewards, weekly governance
• Cost of skipping: Material scope left undelivered on time

Agile Pitfalls

Pitfall 1: No Clear Product Vision

• Problem: Team starts building, then discovers they're building wrong thing
• Fix: Spend 1 week defining product vision, MVP scope, and success metrics upfront
• Cost of skipping: 8-12 weeks of wasted development

Pitfall 2: Absent Product Owner

• Problem: PO doesn't prioritize stories, team doesn't know what's next
• Fix: Require the PO to be materially available, not a nominal part-time role
• Risk of skipping: Poorly understood work, weak Sprint Goals, churn, or missed decision priorities

Pitfall 3: Forecast and Sprint Goal failures

• Problem: The team repeatedly selects work that does not support a credible Sprint Goal or current capacity
• Response: Developers forecast from current capacity, work, dependencies, risk, and relevant history; velocity is optional and not a commitment target
• Risk: Persistent forecast error or weak goals can reduce confidence and delay decisions

Pitfall 4: Testing Debt Piles Up

• Problem: Team prioritizes features, defers testing, accumulates bugs
• Fix: Definition of Done: Features not done until tested, QA integrated in sprint
• Cost of skipping: 2-3 months to fix technical debt before release

Measurement: How to Know You're On Track

Waterfall Projects:

Every Week:

• Schedule Variance (SV) >-5% → On track
• Cost Variance (CV) >-5% → On budget
• Risk register updated, no new surprises

Every Month:

• Milestones hit on schedule (0-5% slip acceptable)
• Sponsor reports "no surprises"
• Steering committee has <2 escalations (shows healthy governance)

Before Launch:

• Authorized scope, acceptance, safety, security, quality, and operational-readiness evidence satisfy the decision-specific release criteria
• Defects are within severity- and exposure-based tolerance; a percentage of “critical” defects is not a valid release rule
• UAT sign-off obtained
• Cutover plan finalized

Agile Projects:

Every Sprint:

• If used, velocity is a local observation with no required stabilization point
• Sprint Goal evidence reviewed without converting story completion into a universal percentage target
• Retrospective action items addressed next sprint
• Technical debt not accumulating (code quality stable)

Every Month (Multiple Sprints):

• Flow, forecast error, outcome, quality, and risk trends interpreted from stable local definitions; no fixed velocity band
• Product Owner satisfied with prioritization
• User feedback incorporated in next sprint
• Release plan on track to MVP launch

Before Release:

• The authorized product/release scope and explicit exclusions are reconciled; a Sprint 0 backlog is not a fixed baseline
• Acceptance evidence meets decision-specific coverage and severity criteria rather than a universal pass percentage
• Performance/load testing passed
• Release notes prepared, training complete

Red Flags: When Methodology is Wrong

Predictive-design Red Flags:

• ✗ Requirements constantly changing → Reassess discovery, feedback, baseline, and change authority; consider adaptive or hybrid practices if they improve evidence without violating obligations
• ✗ 10%+ rework late in project → Requirements were incomplete
• ✗ Vendor missing deadlines regularly → Governance/accountability weak
• ✗ Steering committee escalations >1/month → Execution struggling
• ✗ Team says "we're done, just waiting for testing" → Testing not integrated

Agile Red Flags:

• ✗ Material flow or forecast deterioration → Verify definitions and investigate capacity, interruptions, dependencies, quality, work mix, morale, and scope as competing hypotheses
• ✗ Product Owner absent → Decisions bottlenecked, team losing direction
• ✗ Technical debt accumulating → Definition of Done too loose
• ✗ Same bugs showing up each sprint → Not addressing root causes
• ✗ Stakeholders surprised at sprint review → PO not communicating feedback

Hybrid Red Flags:

• ✗ Waterfall people complaining about lack of planning → Need to strengthen Phase 1
• ✗ Agile people frustrated by bureaucracy → Over-applying Waterfall controls
• ✗ Scope is growing unchecked → Need change control even in Agile phases

Why This Matters: Mental Models & Project Wisdom

The contrasts below are teaching simplifications, not universal properties of “Waterfall” or “Agile.” Real delivery systems combine planning, feedback, assurance, flow, and governance in different ways. All cases and quantities in this section are constructed; they do not establish that a methodology caused an outcome.

Mental Models: Why Project Methodologies Work

1. Why Waterfall Works: Predictable, Sequential Dependencies

A predictive sequence can be useful when dependencies and evidence justify committing detail early; it is not automatically optimal for an entire project.

Predictability Through Planning: Predictive approaches frontload selected planning and baselines. That can improve coordination, but a plan does not create certainty about scope, duration, cost, regulation, or operating conditions.

Sequential Dependencies: Some work has real sequencing constraints: a component may need to exist before it can be integrated or tested, and a manufactured item may need to exist before deployment. A predictive sequence is one way to coordinate that work; staged prototypes, reviews, simulations, and incremental testing can still reduce uncertainty.

Example: Building a bridge may require predictive engineering, procurement, and assurance controls, while still benefiting from staged design reviews, prototypes, incremental testing, and governed learning:

• Requirements: Load capacity, environmental conditions, regulatory approvals
• Design: Engineering blueprints, stress analysis, materials selection
• Construction: Foundation → Supports → Deck (must be sequential)
• Testing: Load testing, safety inspections
• Deployment: Open to traffic

Physical construction constrains what can be changed cheaply after commitment, so design assurance, prototypes, staged approvals, and controlled field learning matter; that does not require pretending every design decision is final before evidence arrives.

Why It Works: For projects where the cost of rework is high (construction, hardware, safety-critical systems), proportionate upfront planning and assurance can reduce avoidable changes; they do not remove the need for feedback or authorized adaptation.

Why It Fails: When a predictive design delays credible feedback on uncertain requirements. If customer needs or solution mechanisms are not knowable upfront, late validation can produce rework; staged discovery and incremental evidence may reduce that risk.

2. Why Agile Works: Learning and Adaptation Under Uncertainty

Adaptive approaches use short feedback loops when needs or solutions are expected to evolve. Agile does not require two-week Sprints, and Scrum permits Sprints of one month or less. ^{[6] [2]}

Rapid Feedback Loops: An adaptive team can deliver and inspect usable increments on a chosen cadence. Whether customers can safely use an increment and whether feedback identifies causal value depend on the product, evidence, and release controls.

Embrace Change: Adaptive practice treats new evidence as a reason to inspect assumptions and revise authorized decisions. Predictive practice can also learn and change through controlled baselines, reviews, and change authority; neither label owns learning.

Example: A startup building a mobile app uses Agile:

• Sprint 1: Build login + basic dashboard (hypothesis: users need dashboards)
• Sprint 2: User feedback: "Dashboard is confusing, but we love the notifications"
• Sprint 3: Pivot: Simplify dashboard, enhance notifications
• Sprint 4: User retention improves 40%

In this constructed comparison, a long feedback cycle would have risked spending six months on the full app before discovering that users preferred simple notifications.

Why It Works: For projects where customer needs are uncertain (new products, consumer apps, innovation), rapid feedback may reduce the risk of building the wrong thing; it does not guarantee product-market fit or causal learning.

Why It Fails: Hard constraints do not disqualify adaptive practices. The team must make scope, quality, evidence, funding, deadline, and change authority explicit so adaptation does not conceal an infeasible commitment.

3. Why Hybrid Works (and Why It's Hard): Combining Disciplines

Hybrid project management combines predictive and adaptive practices when their interfaces, authorities, evidence, and commitments are deliberately designed. It can be useful, but it is not automatically superior and requires balancing competing constraints.

Structured Flexibility: One hybrid design might use predictive planning, procurement, architecture, or assurance controls alongside iterative delivery and feedback. The interface must state which scope, budget, quality, evidence, and authority commitments are fixed, negotiable, or revisable.

Example: An enterprise CRM implementation uses Hybrid:

• Waterfall Phase 1: Requirements gathering (3 months, comprehensive)
• Waterfall Phase 2: Architecture design (2 months, validated with vendors)
• Agile Phase 3: Development (6 months, 2-week sprints for each module)
• Agile Phase 4: Testing & iteration (3 months, continuous UAT feedback)
• Waterfall Phase 5: Deployment (1 month, big bang go-live)

Architecture decisions may be controlled through explicit review and change authority while feature details remain open to user-testing evidence; neither label alone determines the decision rights.

Why It's Hard: Predictive and adaptive approaches differ in commitment timing and feedback design; neither is accurately summarized as “plan everything” or “planning is waste.” ^{[1] [2]}

Hybrid requires the team to make interfaces explicit: which decisions are controlled, which can change, who decides, what evidence is needed, and how work crosses boundaries. Ambiguity—not the coexistence of practices itself—creates confusion.

Why It Works: For complex projects where assurance or contractual controls coexist with uncertain user needs, a hybrid design may balance compliance, learning, and delivery if the evidence and authorities are explicit.

Why It Fails: When teams combine incompatible commitments without decision rights: for example, demanding a fixed scope and date while accepting unbounded change without feasibility checks. The remedy is to make tradeoffs, baselines, and escalation explicit.

4. Why Critical Path Matters: Resource-Constrained Execution

Critical Path Method (CPM) identifies the longest sequence of dependent tasks—the bottleneck determining project duration. Understanding this matters because resources are finite.

Bottleneck Logic: A project with 100 tasks doesn't mean all 100 matter equally. If 95 tasks have slack (can be delayed without impacting the project), only 5 tasks on the critical path actually determine when you finish.

Resource Allocation: CPM reveals where to focus: "Add resources to critical path tasks (shortens timeline). Adding resources to non-critical tasks wastes money (doesn't shorten timeline)."

Example: A product launch has these paths:

• Path A (Product development): 6 months (critical path)
• Path B (Marketing campaign): 3 months (3 months slack)
• Path C (Sales training): 2 months (4 months slack)

Adding resources to Sales training (Path C) doesn't accelerate the launch (launch depends on Product development finishing). Adding resources to Product development shortens the critical path by 1 month, enabling a 5-month launch.

Why It Works: CPM prevents waste. Without it, managers add resources everywhere ("we need to go faster!"), diluting impact. CPM focuses resources on the bottleneck.

Why It Fails: When priorities, dependencies, or evidence shift dynamically. In iterative work, the modeled dependency network can change frequently, so CPM assumptions and forecasts need regular review rather than being discarded by method label.

Composite Failure Examples: When Project Methodologies Failed

The following scenarios are composite teaching examples, not named empirical case studies.

Case 1: Healthcare IT Project Failure - Methodology Mismatch

Situation: A hospital system contracted a $50M electronic health record (EHR) implementation. The vendor used Waterfall: 6-month requirements phase, 12-month development phase, 3-month testing, 1-month deployment. Total timeline: 22 months.

What Went Wrong: Month 6: Requirements completed and frozen (Waterfall phase gate). Month 18: Development completed, testing begins. Month 18 discovery: Clinical workflows had changed significantly due to new regulatory requirements (meaningful use standards). The EHR, built to old requirements, was obsolete before deployment.

Hospital requested changes. Vendor response: "That's a change order. Scope was frozen at Month 6. Changes require $15M and 12-month delay."

Hospital faced a choice: Deploy an obsolete system or pay $65M total and delay 12 months. They deployed the obsolete system. Physician adoption: 40% (instead of target 90%). ROI: Negative. Project deemed a failure.

What Methodology Failed: This constructed design treated requirements as stable despite a changing healthcare context. A 22-month timeline meant the requirements were 16 months stale by deployment.

What Would Have Worked: Agile with phased rollout:

• Month 1-3: Build core EHR (patient records, basic workflows)
• Month 4: Deploy to 1 department (Cardiology), gather feedback
• Month 5-6: Iterate based on feedback and regulatory changes
• Month 7: Expand to 3 more departments
• Month 12: Enterprise-wide deployment

Agile's frequent iterations (every 2 weeks) would have incorporated regulatory changes as they emerged, preventing obsolescence.

Lesson: In changing environments, shorten evidence and decision cycles while preserving required assurance and traceability. The appropriate mix is a design decision, not a categorical ban on predictive practice.

Case 2: Software Project Death March - Waterfall Applied to Uncertain Work

Situation: A software company committed to a fixed-price, fixed-scope contract to build a custom platform for a client. Contract terms: $5M, 12-month delivery, 200 features specified in a 300-page requirements document.

The company used Waterfall:

• Months 1-3: Requirements review and design
• Months 4-10: Development
• Months 11-12: Testing and deployment

What Went Wrong: Month 4: Development started. Developers discovered 30% of requirements were technically infeasible (client asked for features that conflicted with each other or violated technical constraints).

Company faced a choice:

1. Tell client "your requirements are infeasible" → Client lawsuit for breach of contract
2. Build what's feasible and hope client accepts → Risk client rejection at delivery

They chose option 2.

Month 10: Integration testing revealed the 200 features didn't work together (modularity assumed in requirements didn't exist in implementation).

Month 12: Delivery deadline. System was 60% complete. Company asked for extension. Client refused (contract specified 12 months). Company faced penalties: $1M/month for late delivery.

Outcome: Company worked weekends and nights (death march) to deliver something. Month 15: Deployed a broken system (technical debt, poor quality). Client sued for non-performance. Settlement: $8M (original contract + $3M damages). Company lost money and reputation.

What Methodology Failed: The design's requirements freeze and feasibility gaps created an impossible contract. The client specified what it wanted without understanding feasibility, and the vendor committed without validating it. Both parties treated requirements as correct without adequate evidence.

What Would Have Worked: Agile with Time & Materials contract:

• Month 1: Build 20 most critical features (MVP)
• Month 2: Client tests MVP, refines priorities
• Months 3-12: Iterative development of next-priority features
• Every 2 weeks: Client sees working software, provides feedback
• Month 12: Deliver 150 features that actually work (vs. 200 that don't)

Earlier technical and user evidence could have surfaced infeasible requirements sooner, but the constructed case does not prove that a branded method would have done so.

Lesson: For complex uncertain work, align contract structure, discovery, acceptance, incentives, change, audit, and termination rights with the uncertainty. Fixed-price and time-and-materials contracts each allocate risk and incentives differently; qualified procurement and counsel should design the arrangement.

Case 3: Agile Chaos - Applied Without Discipline to Complex Delivery

Situation: A financial services firm adopted Agile for a regulatory compliance project (implementing new anti-money-laundering rules). The project had hard constraints:

• Scope: Fixed (regulators specified requirements)
• Deadline: Fixed (regulatory deadline 18 months away)
• Budget: Fixed ($20M approved by board)

The project team ran 2-week sprints. After 12 months and $15M spent:

• Delivered: 40% of required features
• Remaining: 60% of features, $5M budget, 6 months deadline
• Math: Impossible (current pace: 40% in 12 months = 100% in 30 months, not 18)

What Went Wrong: Agile's flexibility enabled scope creep:

• Sprint 5: Product owner added 10 new user stories (not in original scope)
• Sprint 10: Team refactored code for better architecture (didn't deliver new features)
• Sprint 15: Product owner reprioritized backlog, deprioritizing 20% of regulatory features (still required by law, but pushed to "later")

No one tracked: "Are we on pace to finish all required features by the deadline?" Agile's sprint-by-sprint focus obscured long-term progress.

Month 12: Steering committee asked: "Will we make the deadline?" PM answered: "We're doing Agile, so we're flexible." Steering committee: "The regulatory deadline isn't flexible."

Outcome: Company hired external consultants (additional $10M), worked weekends, delivered minimum viable compliance by deadline. Total cost: $30M (vs. $20M budget). Quality: Poor (technical debt accumulated from rushing). Post-launch: 18 months of bug fixes.

What Methodology Failed: Adaptive delivery does not assume that legal scope is flexible. The constructed team failed to map obligations, evidence, capacity, deadline, and change authority into its delivery design.

What Would Have Worked: Hybrid approach:

• Waterfall Phase 1 (Months 1-2): Requirements analysis (map all regulatory requirements to features)
• Waterfall Phase 2 (Month 3): Baseline plan (how much can we deliver per sprint to finish in 18 months?)
• Agile Phase 3 (Months 4-16): 2-week sprints, but EVERY sprint must deliver X features (pace discipline)
• Waterfall Phase 4 (Months 17-18): Integration testing and deployment (no new features)

This constructed hybrid keeps iterative delivery while adding explicit feasibility, baseline, and assurance controls; it still needs rolling forecasts and authorized tradeoffs.

Lesson: When scope, deadline, and budget are all constrained, test feasibility and explicitly govern tradeoffs. Baselines, rolling forecasts, incremental delivery, and adaptive planning can coexist; none guarantees predictability.

Competing Schools: Different Approaches to Project Management

1. Predictive vs. Adaptive Project Management

Predictive approaches: Use greater upfront and rolling planning where dependencies, procurement, assurance, or commitments justify it. Baselines support comparison, but forecasts and plans change through authority and materiality-appropriate control.

Philosophy: Planning can reduce some uncertainty and coordinate commitments; it does not make the future knowable.

Strengths:

• Predictability: Stakeholders know what to expect
• Accountability: Baseline plan enables variance tracking (on-time, on-budget?)
• Risk management: Comprehensive risk analysis upfront

Weaknesses:

• Rigid: Hard to adapt when reality diverges from plan
• Late validation: Deliver at the end, discover issues late
• Assumes stable requirements: Fails when requirements change

Potential fit signals, not automatic selections:

• Construction, infrastructure, manufacturing, or other work with material physical dependencies may benefit from predictive planning and assurance; incremental validation can still be useful.
• Regulatory work may require traceability, evidence, approval, and release controls; those controls do not by themselves prescribe a predictive-only delivery system.
• Fixed-price contracts allocate commercial risk and change rights; procurement and governance design should determine how planning, discovery, acceptance, and change interact.

Adaptive (Agile, Scrum): Plan iteratively. Define vision and high-level goals, while details emerge through feedback and evidence. Scope, time, budget, quality, and authority constraints can be governed in different combinations; adaptation does not mean unbounded scope.

Philosophy: "The future is unknowable. Adaptation reduces risk."

Strengths:

• Flexibility: Respond to changing requirements
• Early validation: When Scrum applies, inspect a usable Increment on the chosen Sprint cadence; other adaptive teams may use different increments and release controls
• Customer collaboration: Continuous feedback loops

Weaknesses:

• Unpredictability: Hard to forecast final scope or cost
• Scope creep risk: Without discipline, teams iterate endlessly
• Requires decision access: Product Owner availability must fit the product decisions and cadence; Scrum does not prescribe weekly availability

Potential fit signals, not automatic selections:

• Software or service work where requirements or solution mechanisms are expected to evolve may benefit from short feedback cycles.
• Innovation work may benefit from experiments and staged commitments when learning value justifies the cost.
• Startups may use adaptive practices, but funding, safety, contractual, technical, and operating constraints still require explicit governance.

Hybrid (one possible design): Combine predictive and adaptive practices only where the interfaces, authority, evidence, and tradeoffs are explicit:

• Some scope, timeline, budget, architecture, procurement, assurance, or release commitments may be baselined.
• Other details may be discovered and delivered iteratively within stated constraints.

Example:

• Predictive: "We will implement a CRM system in 12 months for $2M"
• Adaptive: "We'll deliver via 24 sprints. Each sprint, we'll refine features based on user feedback"

2. Command-and-Control vs. Self-Organizing Teams

Command-and-Control (a centralized decision pattern): An authorized manager or governance body assigns or approves work, tracks progress, and makes selected decisions; the degree of team discretion depends on capability, consequence, and decision rights.

Philosophy: "Centralized control ensures coordination."

Strengths:

• Clear accountability (PM is accountable)
• Efficiency (no time wasted on consensus)
• Works with junior teams (don't require self-direction)

Weaknesses:

• Bottleneck (all decisions go through PM)
• Low engagement (team feels "managed," not empowered)
• Limited innovation (team doesn't challenge assumptions)

Potential fit signals, not automatic selections:

• Time-critical incidents or decisions where a clear incident commander or authority is required.
• Work with limited capability or unclear decision rights where temporary structure, coaching, and escalation may reduce risk.
• High-consequence work where explicit approvals and independent assurance are needed; centralized control is not a substitute for expertise or evidence.

Self-managing teams (a team-discretion pattern): The team decides how to accomplish an agreed goal within its authority and constraints. In Scrum, the Scrum Master supports Scrum and team effectiveness; the role is not automatically a project manager and does not remove product, technical, safety, or governance accountability.

Philosophy: "Teams closest to the work make better decisions."

Strengths:

• Speed (no bottleneck; decisions made locally)
• Engagement (team owns outcomes)
• Innovation (team challenges assumptions)

Weaknesses:

• Requires maturity (doesn't work with junior teams)
• Coordination challenges (multiple teams may work at cross-purposes)
• Accountability diffusion ("team" accountability = no one accountable)

Potential fit signals, not automatic selections:

• Teams with the capability, access, psychological safety, and authority to make the relevant decisions.
• Work where local expertise and feedback improve solution quality or learning.
• Stable or changing teams alike, provided coordination, escalation, accountability, and onboarding are deliberately designed.

Hybrid (Servant Leadership): PM sets vision and removes blockers (servant leadership), but team makes execution decisions (self-organizing).

Example:

• PM: "Our sprint goal is to enable user login. What blockers do you need removed?"
• Team: "We need API access to authentication service."
• PM: "I'll handle that. You decide how to implement the login flow."

3. Phases vs. Sprints (When to Use Each)

Phases (a predictive delivery pattern): Sequential or partially overlapping stages with formal gates. Use a gate when the evidence and authority justify it; phases need not eliminate iteration or staged validation.

Phases: Requirements → Design → Build → Test → Deploy

Strengths:

• Clear milestones (know when each phase is "done")
• Quality gates (don't proceed until phase is validated)
• Works for sequential work (can't test before building)

Weaknesses:

• Long cycle times (months between validation points)
• Late feedback (discover issues in Testing phase, too late to fix cheaply)
• Assumes linear progress (doesn't accommodate iteration)

Potential fit signals, not automatic selections:

• Hardware, infrastructure, or other work with physical dependencies may need staged engineering, procurement, testing, and release controls.
• Compliance work may need formal evidence and approval gates, which can coexist with iterative design or implementation.
• Large-scale delivery may use phases for coordination while running incremental validation inside them.

Sprints (an adaptive delivery pattern): Fixed-duration iterations; two weeks is a constructed example, while Scrum permits a Sprint of one month or less. A Sprint aims to produce a usable Increment when Scrum is being used.

Sprint Cycle: Plan → Build → Review → Retrospective → Repeat

Strengths:

• Rapid feedback (validate every 2 weeks)
• Flexibility (can pivot based on sprint learnings)
• Momentum (frequent "wins" keep morale high)

Weaknesses:

• Fragmentation risk (focus on sprint goals, lose sight of big picture)
• Overhead (sprint planning, reviews, retros take meaningful team time)
• Hard to estimate total duration (how many sprints to "done"?)

Potential fit signals, not automatic selections:

• Software or customer-facing work where frequent feedback can change priorities or solution detail.
• Continuous-delivery environments where release, quality, security, and operational controls support small increments.
• Any context in which the cadence improves evidence and decision quality; the cadence must still fit the work and its obligations.

Hybrid (Phased Rollout with Agile Execution): One possible design uses phases for high-level milestones and iterative delivery within phases; the interfaces and release authority must be explicit.

Example:

• Phase 1: Requirements (3 months, Agile sprints to iterate on requirements)
• Phase 2: Build (6 months, Agile sprints to deliver features incrementally)
• Phase 3: Deploy (2 months, Agile sprints for rollout by region)

Context-Dependent Delivery Design

Organization labels such as “startup,” “scale-up,” and “enterprise” do not prescribe Agile, Waterfall, sprint length, documentation volume, governance cadence, or delivery duration. Tailor the delivery system to the work and its obligations.

A small uncertain product team might use short experiments and lightweight artifacts; a similarly sized medical-device team may require substantial traceability and assurance. A large organization might use adaptive product discovery in one workstream and predictive procurement or migration controls in another. These are constructed contrasts, not maturity stages or duration benchmarks.

Select and revise practices from observed forecast error, flow, defect and incident evidence, learning value, control effectiveness, stakeholder impact, and delivery outcomes. Tool choice, meeting frequency, page count, and organization stage are not proxies for rigor.

Tailoring dimensions:

Operating Manual: Your Project Execution Playbook

Constructed-policy boundary: All hours, durations, team sizes, thresholds, budgets, meeting cadences, status labels, and escalation values in this operating manual are fictional teaching assumptions. Replace them with approved project-specific evidence, contract, safety, regulatory, accessibility, workforce, procurement, and governance constraints before use.

This operating manual contains constructed sample cadences, roles, thresholds, hours, durations, budgets, statuses, and escalation triggers. None is a benchmark or default. Replace every sample with a named owner, rationale, applicable governance, evidence source, tolerance, and review rule. The two-track presentation is a teaching convenience; a real delivery design may combine or omit practices.

Delivery-System Tailoring

Do not select a method from a rigid Waterfall/Agile taxonomy. Tailor planning horizon, feedback, sequencing, flow, documentation, assurance, procurement, funding, release, and change authority independently. Predictive and adaptive practices can coexist, and regulation or fixed-price contracting does not prescribe one method.

WATERFALL TRACK: Your Phased Project Playbook

Phase 1: Initiation (Weeks 1-2, 40-60 hours)

Objective: Define project scope, secure sponsorship, and obtain formal approval to proceed.

Activities:

Week 1: Project Charter Development (20-30 hours)

• Business Case (8 hours):

  • Problem statement: What issue are we solving?
  • Proposed solution: High-level approach
  • Benefits quantification: Revenue impact, cost savings, efficiency gains
  • Investment required: Budget estimate with stated confidence range
  • Alternatives considered: Why is this the best option?
  • Output: Business case document (3-5 pages)

• Stakeholder Identification (4 hours):

  • List all affected parties (typically 15-30 stakeholders)
  • Classify by the constructed power/interest aid in Framework 6; do not treat the categories as a universal stakeholder standard
  • Identify sponsor (executive accountable for success)
  • Identify steering committee (3-7 senior stakeholders for oversight)
  • Output: Stakeholder register with roles

• High-Level Scope Definition (4 hours):

  • What IS included (in-scope): 5-10 major deliverables
  • What is NOT included (out-of-scope): 5-10 exclusions
  • Assumptions: What we're assuming to be true
  • Constraints: Budget limits, timeline deadlines, resource caps
  • Output: Scope statement (1-2 pages)

• Success Criteria (4 hours):

  • Define "done": What does success look like?
  • Measurable outcomes: KPIs, metrics, milestones
  • Acceptance criteria: How will sponsor approve?
  • Example: "CRM system deployed to 500 users with <5% critical bugs and <2 hour average response time"
  • Output: Success criteria checklist

Week 2: Charter Approval & Kickoff (20-30 hours)

• Project Charter Finalization (8 hours):

  • Consolidate: Business case + scope + success criteria + stakeholders
  • Add: High-level timeline (phases with dates), budget confidence range, major risks
  • Format: 5-10 page document
  • Review with sponsor and key stakeholders
  • Iterate based on feedback

• Approval & Sign-Off (4 hours):

  • Present charter to sponsor/steering committee
  • Secure formal approval (signature or email confirmation)
  • Allocate initial budget for the planning phase
  • Assign project manager (if not already assigned)

• Project Kickoff Meeting (2-3 hours):

  • Attendees: Sponsor, PM, core team (5-15 people)
  • Agenda:
    • Present charter (10 min)
    • Introduce team and roles (10 min)
    • Review timeline and next steps (10 min)
    • Q&A (15 min)
    • Team building activity (optional, 30 min)
  • Output: Meeting minutes, action items

Outputs (Phase 1):

• Approved project charter
• Stakeholder register
• Sponsor commitment and budget allocation
• Core team assembled

Decision Gate: Proceed to Planning?

• GREEN: Charter approved, sponsor committed, budget secured → Proceed to Phase 2
• YELLOW: Minor scope adjustments needed → Refine and re-approve within 1 week
• RED: Business case weak or sponsor unavailable → STOP or revisit in 3-6 months

Red Flags:

• Sponsor not engaged (skips meetings, delays approval) → Escalate or pause
• Scope undefined ("improve customer experience") → Too vague; define measurables
• Budget unavailable → Cannot proceed without funding commitment
• Stakeholders misaligned on goals → Facilitate alignment session (Chapter 9)

Resource Requirements:

• Project Manager: 40-60 hours (full-time for 1-2 weeks)
• Sponsor: 4-6 hours (charter review, approval meeting)
• Stakeholders: 10-15 hours total (distributed)

Phase 2: Planning (Weeks 3-8, 200-300 hours)

Objective: Develop detailed project plan with scope, schedule, budget, risks, and quality standards.

Week 3-4: Requirements & Scope Planning (60-80 hours)

• Requirements Gathering (30-40 hours):

  • Stakeholder interviews (10-15 people, 1-2 hours each): "What do you need from this project?"
  • Workshops (2-3 sessions, 2-4 hours each): Facilitate group requirements definition
  • Document review: Existing processes, systems, contracts
  • Requirements documentation:
    • Functional requirements: What system/solution must DO (50-200 items typical)
    • Non-functional requirements: Performance, security, usability standards (10-30 items)
    • Format: Requirements traceability matrix (Excel or requirements tool)
  • Prioritization: Must-have (MVP), Should-have (Phase 1), Could-have (Phase 2), Won't-have
  • Output: Requirements specification document (20-100 pages depending on complexity)

• Work Breakdown Structure (WBS) (20-30 hours):

  • Decompose project into hierarchical structure:
    • Level 1: Major phases (Initiation, Planning, Execution, etc.)
    • Level 2: Deliverables per phase (Requirements doc, Design spec, Build, Test, Deploy)
    • Level 3: Work packages sized to support ownership, estimation, control, and progress visibility
  • Rules: cover the defined project scope under the WBS 100% rule; do not require mutually exclusive work or a universal 8–80-hour package size. ^[3]
  • Tool: Microsoft Project, Excel, or Lucidchart
  • Output: WBS diagram (visual) + WBS dictionary (descriptions of each element)

• Scope Baseline (10 hours):

  • Formal documentation of approved scope
  • Includes: Requirements spec + WBS + Scope statement from Phase 1
  • Becomes basis for scope change control
  • Route changes by delegated authority, materiality, contract, safety, regulation, baseline impact, and evidence; not every change requires formal review
  • Output: Scope baseline document (approved by sponsor)

Week 5-6: Schedule & Budget Planning (80-120 hours)

• Activity Sequencing & Duration Estimation (40-60 hours):

  • List all tasks from WBS (typically 50-500 tasks depending on project size)
  • Sequence: Which tasks depend on others? (predecessors/successors)
  • Estimate duration: Use historical data, expert judgment, or three-point estimates (optimistic/most likely/pessimistic)
  • Identify critical path: Longest sequence of dependent tasks (determines minimum project duration)
  • Tool: Microsoft Project, Smartsheet, or Gantt chart tool
  • Add buffer based on uncertainty and risk exposure
  • Output: Project schedule (Gantt chart with dependencies)

• Resource Planning (20-30 hours):

  • Identify roles needed: PM, business analyst, developers, testers, etc.
  • Estimate effort per role per task
  • Level resources: Smooth workload to avoid over-allocation (e.g., developer not assigned 80 hours/week)
  • Identify resource constraints: "Only 2 developers available; others on different projects"
  • Output: Resource allocation matrix (who does what, when)

• Budget Development (20-30 hours):

  • Calculate costs:
    • Labor: Hours × hourly rate (or FTE allocation)
    • Materials/equipment: Hardware, software licenses, facilities
    • External vendors: Contractors, consultants, outsourced work
    • Contingency based on uncertainty and risk exposure
  • Create budget by phase and by category (labor, materials, vendors)
  • Example waterfall project budget: 10% initiation, 20% planning, 50% execution, 15% testing/QA, 5% closure
  • Secure budget approval from sponsor/finance
  • Output: Project budget (detailed breakdown with approval)

Week 7-8: Risk, Quality & Communication Planning (60-100 hours)

• Risk Management Plan (20-30 hours):

  • Risk identification workshop (2-3 hours with team + stakeholders): Brainstorm 20-50 risks
  • Risk assessment:
    • Probability and impact: Use a defined local ordinal scale; this operating example may use the same 1–5 scale as Framework 5, but the labels and anchors must be approved for the project
    • Score: Probability × Impact only as a local ordinal triage aid, not a quantitative exposure measure
  • Prioritize: Record the scale, owner, trigger, evidence, and review rule; do not present a numerical cutoff as a universal threshold
  • Mitigation strategies for top 10 risks:
    • Avoid: Eliminate risk (e.g., use proven technology vs. experimental)
    • Mitigate: Reduce probability or impact (e.g., add testing to reduce defect risk)
    • Transfer: Shift to vendor/insurance (e.g., vendor guarantees uptime)
    • Accept: Risk acceptable; document decision
  • Output: Risk register (living document, updated weekly)

• Quality Management Plan (15-20 hours):

  • Define quality standards: What level of quality is acceptable?
    • Example: "Software must pass 95% of test cases with zero P0 bugs before go-live"
  • Quality assurance activities: Reviews, inspections, audits
  • Quality control measures: Testing, validation, acceptance criteria
  • Tools: Defect tracking (Jira), code reviews, automated testing
  • Output: Quality plan (how quality will be ensured and measured)

• Communication Plan (15-20 hours):

  • Stakeholder communication matrix:

    Stakeholder Group	Frequency	Medium	Content	Owner
    Sponsor	Weekly	Email	Status summary (1 page)	PM
    Steering Committee	Monthly	Meeting	Detailed review + decisions	PM
    Project Team	Daily	Standup	Progress, blockers	PM/Team Leads
    End Users	Bi-weekly	Email	Updates on progress, upcoming changes	PM

  • Escalation protocol: When to escalate, to whom
  • Reporting templates: Status reports, dashboards, presentations
  • Output: Communication plan document

• Procurement Plan (if applicable) (10-15 hours):

  • Identify what needs to be procured (software, hardware, consulting services)
  • Vendor selection criteria and process
  • Contract types (fixed-price, time-and-materials, etc.)
  • Output: Procurement plan (if vendors involved)

Outputs (Phase 2):

• Requirements specification (approved)
• WBS and scope baseline
• Project schedule (Gantt chart with critical path)
• Resource plan and budget (approved)
• Risk register (top 10 risks with mitigations)
• Quality plan
• Communication plan

Decision Gate: Proceed to Execution?

• GREEN: Plan approved, resources committed, risks acceptable → Proceed to Phase 3
• YELLOW: Plan needs refinement (schedule/budget adjustments) → Revise and re-approve within 1-2 weeks
• RED: Plan not viable (timeline too aggressive, budget insufficient, risks too high) → STOP or re-scope

Red Flags:

• Schedule shows critical path >2× sponsor expectation → Reset expectations or add resources
• Budget >30% higher than charter estimate → Re-validate business case
• Top risks unmitigatable → May not be feasible; consider alternative approach
• Team not aligned on plan → Facilitate planning workshop to build consensus

Resource Requirements:

• Project Manager: 200-300 hours (full-time for 6 weeks)
• Business Analyst: 60-100 hours (requirements gathering, documentation)
• Team Leads: 40-60 hours each (3-5 leads for different workstreams)
• Stakeholders: 30-50 hours total (interviews, reviews, approvals)

Contingency Triggers:

• If planning extends beyond 8 weeks → Move to execution with rolling wave planning (detail only next phase)
• If requirements unclear → Run additional discovery; may extend planning 2-4 weeks
• If budget cuts forced → Reduce scope (descope should-haves and could-haves) or extend timeline

Phase 3: Execution (Variable, 3-12 months depending on project)

Objective: Execute the work defined in the plan; deliver project deliverables per schedule.

Execution Cadence (Ongoing)

Daily Activities (15-30 min/day):

• Daily standup (if team co-located or on video):
  • 3 questions per person:
    • What did you complete yesterday?
    • What will you complete today?
    • Any blockers or help needed?
  • PM notes blockers and resolves outside meeting
  • Keep to 15 min max (5-10 people)

Weekly Activities (4-6 hours/week):

• Team sync (1-2 hours):

  • Review progress vs. schedule
  • Identify slippage: Any tasks behind?
  • Adjust plan if needed (re-sequence, add resources)
  • Review upcoming milestones
  • Output: Updated schedule, action items

• Status reporting (2-3 hours):

  • Collect status from team leads
  • Update project dashboards:
    • Schedule health: On track / At risk / Behind
    • Budget health: Within budget / At risk / Over budget
    • Scope health: No changes / Minor changes / Major changes
    • Risk status: Top 3 active risks
  • Distribute weekly status email to stakeholders
  • Format: 1-page summary with RAG (Red/Amber/Green) status

• Risk review (1 hour):

  • Review risk register
  • Update probabilities and impacts based on new information
  • Identify new risks
  • Escalate risks that meet the project's defined priority, trigger, severity, authority, or evidence rule; a score ≥6 is only an illustrative local cutoff if explicitly approved
  • Output: Updated risk register

Monthly Activities (8-12 hours/month):

• Steering Committee Meeting (2-3 hours):

  • Attendees: Sponsor, steering committee (3-7 executives), PM, key team leads
  • Agenda:
    • Progress update (10 min): Milestones achieved, upcoming milestones
    • Budget review (10 min): Spend vs. plan, forecast to complete
    • Decisions needed (20-30 min): Scope changes, resource requests, issue escalations
    • Risk review (10 min): Top 3-5 risks and mitigations
    • Q&A (10-15 min)
  • Output: Meeting minutes, decisions documented, action items

• Change Control Board (as needed, 1-2 hours per request):

  • When change requests arise (scope additions, deletions, modifications):
    • Evaluate impact: Schedule (days delayed), budget ($cost increase), quality (risks introduced)
    • Present to sponsor/steering committee
    • Decision: Approve, reject, or defer
  • If approved: Update scope baseline, schedule, budget
  • Document all changes (change log)

• Quality Reviews (variable):

  • Code reviews (for software): Ongoing, peer reviews
  • Design reviews: Architecture/design sign-offs before build
  • Testing/QA: Unit testing, integration testing, user acceptance testing (UAT)
  • Inspections: Review deliverables against acceptance criteria
  • Defect tracking: Log bugs, prioritize (P0 = critical, P1 = major, P2 = minor), fix
  • Target: Zero P0 defects before go-live; <5% P1 defects

Execution by Workstream (Parallel):

Design Phase (Month 1-2):

• Detailed design documents (technical specs, process flows, wireframes)
• Architecture decisions (technology stack, integrations, data model)
• Prototype/mockup (if applicable, for stakeholder validation)
• Design review and approval
• Output: Detailed design specification

Build Phase (Month 2-6):

• Development/configuration (build the solution)
• For software: Code in sprints (2-4 week sprints even within waterfall)
• For process/operations: Document new processes, create training materials
• For infrastructure: Procure, install, configure systems
• Progress tracking: % complete per module/component
• Output: Built solution (not yet fully tested)

Testing Phase (Month 5-7):

• Unit testing: Individual components work
• Integration testing: Components work together
• System testing: End-to-end workflows function
• User Acceptance Testing (UAT): End users validate solution meets needs
• Performance testing: System handles expected load
• Security testing: Vulnerabilities identified and fixed
• Defect management: Fix critical/major bugs; defer minor bugs to post-launch
• Output: Tested solution with sign-off from QA and end users

Deployment Phase (Month 7-8):

• Go-live readiness review: Checklist of criteria (all tests passed, training complete, support ready)
• Deployment plan: Step-by-step cutover (often phased rollout: pilot → broader launch)
• Data migration (if applicable): Migrate from old system to new
• Training: End user training (classroom, videos, documentation)
• Go-live: Launch to production
• Hypercare period (2-4 weeks post-launch): Intensive support, rapid bug fixes
• Output: Solution live in production, users trained, support available

Outputs (Phase 3):

• All deliverables per scope baseline
• Tested and validated solution
• End user training completed
• Go-live successful (solution in production)
• Weekly status reports and monthly steering committee updates

Decision Gates (throughout Execution):

• Design Approval (end of Month 2): Design meets requirements?
  • GREEN: Design approved → Proceed to build
  • YELLOW: Minor adjustments needed → Refine and re-approve
  • RED: Design doesn't meet needs → Revisit requirements or pivot
• Build Completion (end of Month 6): Solution built per design?
  • GREEN: Build complete → Proceed to testing
  • YELLOW: Some components delayed → Adjust schedule or descope
  • RED: Major delays or technical blockers → Escalate for resolution
• UAT Sign-Off (end of Month 7): End users accept solution?
  • GREEN: UAT passed → Proceed to deployment
  • YELLOW: Minor issues to fix → Address and re-test
  • RED: Major defects or functionality gaps → Delay go-live, fix critical issues
• Go-Live Readiness (end of Month 8): Ready to launch?
  • GREEN: All criteria met → Go live
  • YELLOW: Minor gaps → Mitigate and proceed with risk acceptance
  • RED: Not ready → Delay go-live until critical gaps addressed

Red Flags:

• Schedule slippage >10% → Escalate; crash schedule (add resources, work overtime), reduce scope, or extend deadline
• Budget overrun >10% → Investigate root cause; may need scope reduction or additional funding
• Quality evidence breaches the authorized severity/exposure tolerance → investigate mechanisms and compare process, design, testing, scope, and release responses
• Team turnover >20% → Knowledge loss risk; cross-train and document
• Scope creep >15% → Enforce change control; push back on unapproved changes
• Stakeholder disengagement (missing meetings, not responding) → Escalate to sponsor

Resource Requirements (example for 6-month execution):

• Project Manager: 960 hours (full-time)
• Business Analyst: 400-600 hours
• Developers/Builders: 2,000-5,000 hours (varies by team size: 3-10 people)
• Testers: 400-800 hours
• Training/Change Management: 200-400 hours
• Sponsor/Steering Committee: 30-50 hours (distributed)

Contingency Triggers:

• If project 20%+ over budget → Formal review with sponsor; options: add funds, reduce scope, or cancel
• If critical team member leaves → Immediate backfill; knowledge transfer sessions
• If technology choice fails → Pivot to alternative technology; may extend timeline 2-4 months
• If business priorities shift → Re-validate project relevance; may pause or cancel

Phase 4: Monitoring & Controlling (Ongoing, parallel to Execution)

Objective: Track progress, manage changes, ensure quality, and keep project on track.

Weekly Monitoring (3-5 hours/week):

• Earned Value Management (EVM) (1-2 hours):

  • Track 3 key metrics:
    • Planned Value (PV): How much work should be done by now (per schedule)
    • Earned Value (EV): How much work is actually done
    • Actual Cost (AC): How much has been spent
  • Calculate variances:
    • Schedule Variance (SV) = EV - PV (negative = behind schedule)
    • Cost Variance (CV) = EV - AC (negative = over budget)
  • Calculate indices:
    • Schedule Performance Index (SPI) = EV / PV (< 1.0 = behind)
    • Cost Performance Index (CPI) = EV / AC (< 1.0 = over budget)
  • Forecast:
    • Estimate at Completion (EAC) = BAC / CPI (forecasted total cost when current cost efficiency is assumed to persist)
    • Estimate to Complete (ETC) = EAC - AC (how much more will be spent)
  • Tool: Microsoft Project or Excel with EVM formulas
  • Output: EVM dashboard (weekly update)

• Schedule Tracking (1-2 hours):

  • Update task completion % in project tool
  • Identify tasks behind schedule
  • Analyze critical path: Is critical path delayed?
  • Adjust plan:
    • Crash: Add resources to critical path tasks
    • Fast-track: Overlap sequential tasks (increases risk)
  • Output: Updated Gantt chart, critical path analysis

• Issue Management (1 hour):

  • Log issues as they arise (issue register)
  • Categorize: Technical, resource, scope, external
  • Assign owner and due date for resolution
  • Escalate unresolved issues to steering committee
  • Output: Issue log (living document)

Monthly Monitoring (4-6 hours/month):

• Performance Reporting (2-3 hours):

  • Compile monthly status update:
    • Accomplishments this month
    • Planned for next month
    • Budget status (spend vs. plan, forecast to complete)
    • Schedule status (milestones hit vs. missed, critical path health)
    • Top 5 risks
    • Top 5 issues
    • Change requests (submitted, approved, rejected)
  • Format: 3-5 page package or dashboard
  • Distribute to sponsor, steering committee, stakeholders
  • Present at monthly steering committee meeting

• Variance Analysis (1-2 hours):

  • For any variance >10%:
    • Root cause analysis: Why did variance occur?
    • Corrective action: What will be done to get back on track?
    • Impact assessment: Does this affect downstream tasks?
  • Document in variance memo
  • Present to steering committee for major variances

• Stakeholder Engagement Review (1 hour):

  • Assess stakeholder satisfaction:
    • Are stakeholders engaged? (attending meetings, responding to requests)
    • Are there conflicts or concerns? (proactively address)
  • Adjust communication plan if needed (increase frequency, change format)

Outputs (Phase 4):

• Weekly EVM dashboards
• Weekly status reports (1 page)
• Monthly performance reports (3-5 pages)
• Updated schedule, budget, risk register, issue log
• Change requests evaluated and approved/rejected

Red Flags (constructed examples, not universal thresholds):

• If the project's approved SPI or CPI alert rule is breached for the defined review period, validate the data and assumptions, investigate drivers, and route a response through the authorized owner; <0.9 for >2 consecutive weeks is only a local teaching example.
• Critical path delayed >2 weeks → Risk of missing deadline; crash or fast-track needed
• Burn rate >20% over plan → Budget will be exhausted early; need cost controls or additional funding
• Issue backlog growing (not resolving issues) → Team capacity problem or escalation needed
• Stakeholder satisfaction declining → Communication breakdown; schedule alignment sessions

Phase 5: Closing (Weeks 1-2 after go-live, 20-40 hours)

Objective: Formally close project, transfer to operations, and capture lessons learned.

Week 1 Post-Go-Live: Transition & Handoff (10-20 hours)

• Operational Handoff (4-6 hours):

  • Transfer solution to operations/support team:
    • Documentation: System architecture, user guides, support runbooks
    • Training: Train support team on troubleshooting, escalation procedures
    • Support transition: Define support SLAs (response time, resolution time)
  • Warranty period: Typically 30-90 days where project team provides bug fixes
  • Output: Operational handoff document (signed by operations team)

• Final Deliverable Review (2-3 hours):

  • Review all deliverables against acceptance criteria (from scope baseline)
  • Confirm: All requirements met, all deliverables delivered
  • Obtain formal acceptance from sponsor (sign-off)
  • Output: Deliverable acceptance form

• Financial Closeout (2-4 hours):

  • Final budget reconciliation: Actual spend vs. budget
  • Close purchase orders, finalize vendor payments
  • Release unused contingency funds
  • Output: Final budget summary

• Resource Release (2-3 hours):

  • Release team members back to functional managers or other projects
  • Performance reviews/feedback (for team members)
  • Celebrate success (team celebration, recognition)
  • Output: Resource release notifications

Week 2: Lessons Learned & Documentation (10-20 hours)

• Lessons Learned Workshop (2-3 hours):

  • Attendees: Project team (5-15 people)
  • Facilitated discussion:
    • What went well? (strengths to replicate)
    • What didn't go well? (areas to improve)
    • What would we do differently next time?
  • Categorize lessons: Planning, execution, communication, risk management, technology, stakeholder management
  • Document specific, actionable lessons (not vague like "communicate better")
  • Output: Lessons learned summary

• Project Closeout Summary (6-10 hours):

  • Executive summary (1 page):
    • Project objectives: What we set out to do
    • Final outcomes: What was delivered
    • Success metrics: Did we hit success criteria from charter?
    • Budget performance: Final cost vs. budget (% variance)
    • Schedule performance: Final duration vs. plan (% variance)
    • Key accomplishments and challenges
  • Detailed sections:
    • Scope delivered (summary of all deliverables)
    • Budget summary (spend by phase and category)
    • Schedule summary (timeline with milestones)
    • Quality metrics (defect rates, test pass rates, user satisfaction)
    • Risk management summary (risks that materialized, mitigation effectiveness)
    • Change management summary (# of change requests, impact)
    • Lessons learned (summary of workshop findings)
  • Recommendations for future projects
  • Output: Project closeout summary

• Archive Project Documentation (2-4 hours):

  • Organize all project artifacts:
    • Charter, plans, schedules, budgets
    • Requirements, design docs, test results
    • Status updates, meeting minutes, decision logs
    • Lessons learned, closeout summary
  • Store in centralized repository (SharePoint, project folder, document management system)
  • Ensure accessibility for future reference
  • Output: Archived project documentation

Outputs (Phase 5):

• Formal project acceptance (sponsor sign-off)
• Operational handoff complete (support team trained)
• Final budget reconciliation
• Lessons learned summary
• Project closeout summary
• Archived documentation

Decision Gate: Project Closed?

• GREEN: All deliverables accepted, documentation complete, team released → Project officially closed
• YELLOW: Minor cleanup tasks remain (documentation gaps, final invoices) → Complete within 1-2 weeks
• RED: Major issues unresolved (defects, incomplete deliverables) → Extend project or plan Phase 2

Red Flags:

• Sponsor refuses to sign off → Unmet expectations; investigate and address
• Support team not ready to take over → Extend transition period; provide additional training
• Significant budget variance unexplained → Investigate; may indicate cost control issues
• Team members reassigned before closeout → Knowledge loss; ensure documentation complete

Resource Requirements:

• Project Manager: 20-40 hours (closing activities)
• Team members: 10-20 hours (lessons learned, documentation)
• Sponsor: 2-4 hours (final acceptance review)

AGILE/SCRUM TRACK: Your Iterative Project Playbook

Setup Phase (Weeks 1-2, 40-60 hours)

Objective: Define product vision, assemble team, and prepare for iterative execution.

Activities:

Product Vision Definition (8-12 hours):

• Product vision statement: What are we building and why?
  • Format: "For [target user], who [need/opportunity], our product is [product category] that [key benefit]. Unlike [alternatives], our product [unique differentiation]."
  • Example: "For marketing teams who need to automate campaigns, our product is a marketing automation platform that requires zero coding. Unlike Marketo, our product has a visual workflow builder."
• High-level roadmap: Major features/themes for next 6-12 months (not detailed yet)
• Success metrics: How will we measure success?
  • Example: "50 paying customers by Month 6, NPS >40, <10% churn"
• Output: Product vision document (2-3 pages)

Team Assembly (12-16 hours):

• Scrum roles:
  • Product Owner (PO): Accountable for maximizing product value and effective Product Backlog management
  • Scrum Master (SM): Accountable for establishing Scrum and improving Scrum Team effectiveness; this is not defined as a generic blocker-removal or project-manager role
  • Developers: Accountable for creating a usable Increment each Sprint; required skills can span engineering, design, testing, analysis, or other work. ^[6]
• Team co-location (if possible): Ideally same room or same floor; if remote, daily video standups
• Team working agreement:
  • Working hours: Core hours when everyone is available (e.g., 10 AM - 4 PM)
  • Communication norms: Slack for quick questions, meetings for complex discussions
  • Definition of "Done": What does it mean for a story to be complete? (coded, tested, reviewed, deployed?)
  • Sprint cadence: Choose a fixed cadence that fits the product and the team's ability to inspect and adapt. ^[6]
• Output: Team charter (1 page)

Product Backlog Creation (12-16 hours):

• Gather user stories: Stakeholder interviews, user research, competitive analysis
• User story format: "As a [user type], I want [goal] so that [benefit]"
  • Example: "As a marketer, I want to create email campaigns so that I can engage customers"
• Write 20-50 initial user stories (high-level epics)
• Prioritize using MoSCoW or value vs. effort matrix:
  • Must-have (MVP): Minimum viable product features
  • Should-have: Important but not critical for MVP
  • Could-have: Nice-to-have enhancements
  • Won't-have: Out of scope for now
• Acceptance criteria for each story: How will we know the story is done?
  • Example: "Email campaign can be created, previewed, scheduled, and sent. Metrics track open rate and click rate."
• Output: Prioritized product backlog (living document, will evolve)

Sprint Planning Preparation (8-12 hours):

• Define sprint goal template: Each sprint will have a goal (theme/objective for that sprint)
• Estimate stories using story points or t-shirt sizes (XS, S, M, L, XL):
  • Story points: Relative complexity (1 point = simplest story, 8 points = most complex in sprint)
  • Capacity and forecast: use availability, work type, dependencies, risk, and the team's own historical evidence; story points are optional and have no universal team-size range
• Set sprint schedule:
  • Sprint length: 2 weeks (adjust if needed: 1 week for fast iteration, 4 weeks for longer cycles)
  • Sprint ceremonies:
    • Sprint Planning (Monday, start of sprint): 2-4 hours
    • Daily Standup (every morning): 15 min
    • Sprint Review (Friday, end of sprint): 1-2 hours
    • Sprint Retrospective (Friday, end of sprint): 1 hour
• Output: Sprint calendar, estimation baseline

Outputs (Setup Phase):

• Product vision and roadmap
• Team assembled and trained on Scrum
• Product backlog (prioritized, estimated)
• Sprint schedule and ceremonies defined

Decision Gate: Ready to Start Sprints?

• GREEN: Vision clear, team ready, backlog has 2-3 sprints worth of stories → Start Sprint 1
• YELLOW: Backlog thin or team not fully assembled → Extend setup 1 week
• RED: Vision unclear or team unavailable → Pause until resolved

Red Flags:

• Product Owner not available (has other full-time job) → Will bottleneck; need dedicated PO or part-time commitment
• Team composition or size impedes cohesion or required skills → inspect coordination, capability, dependencies, and product boundaries; no universal numeric cutoff applies
• No user research or customer input → Building in a vacuum; risk building wrong thing
• Backlog has no acceptance criteria → Stories not testable; will lead to scope confusion

Sprint Execution (Ongoing, 2-week sprints example)

Sprint Planning (Monday, Week 1 of sprint, 2-4 hours)

Activities:

• Review sprint goal (30 min):
  • PO presents sprint goal: What will we accomplish this sprint?
  • Example: "Complete user authentication feature (login, signup, password reset)"
• Select user stories from backlog (1-2 hours):
  • PO presents top-priority stories
  • Team discusses: Is story clear? Do we understand acceptance criteria?
  • Team estimates effort (if not already estimated)
  • Developers forecast the work that supports the Sprint Goal using current capacity, dependencies, risk, and relevant history; velocity does not determine a commitment
• Break stories into tasks (1-2 hours):
  • For each story, team identifies tasks:
    • Example story: "User can log in"
    • Tasks: Design login UI, implement login API, write tests, integrate with existing system, deploy
  • Estimate tasks in hours (2-16 hours per task typical)
  • Assign tasks to team members (self-assignment, not top-down)
• Output: Sprint Backlog: Sprint Goal, selected Product Backlog items, and a plan for delivering the Increment; selected items remain a forecast, not a universal promise.

Daily Scrum (each working day of the Sprint; 15-minute timebox under the Scrum Guide)

Format:

• Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog. The format is theirs; standing and the historical three questions are not required.
• Detailed problem-solving can follow or occur elsewhere when useful; the Scrum Master need not attend or personally resolve every blocker.

Sprint Work (Daily, 6-8 hours/person)

Activities:

• Developers code features, designers create UI, testers write/run tests
• Pair programming (if applicable): Two developers work together on complex tasks
• Code reviews: Peer review before merging code
• Testing: Unit tests, integration tests, manual testing
• Update task board: Move tasks from "To Do" → "In Progress" → "Done"
• Scrum Master supports the team's effectiveness and helps impediments reach the appropriate decision-maker; the role does not require personally resolving every blocker or owning all technical decisions.

Tools:

• Task board: Physical board (sticky notes) or digital (Jira, Trello, Azure DevOps)
• Columns: To Do, In Progress, Code Review, Testing, Done
• Definition of Done checklist: Code written, tests passed, peer reviewed, deployed to test environment

Mid-Sprint Check-In (Optional, Wednesday of Week 1, 30 min)

Activities:

• Review sprint progress: Are we on track to complete committed stories?
• Burndown chart review: Chart showing remaining work vs. time
  • Ideal: Steady decrease from start to end of sprint
  • Reality: Often choppy; use to identify if sprint is at risk
• Adjust if needed: If behind, descope low-priority stories; if ahead, add stretch goals

Sprint Review (Friday, Week 2 of sprint, 1-2 hours)

Objective: Demonstrate completed work to stakeholders; get feedback.

Activities:

• Demo (45-60 min):
  • Attendees: Team, PO, stakeholders (sponsor, end users, anyone interested)
  • Team demonstrates each completed story:
    • Show working product (not slides or mockups; actual functionality)
    • Explain: What was built, why it's valuable
  • Stakeholders provide feedback:
    • Does it meet their needs?
    • Any adjustments needed?
  • Celebrate successes: Recognize team for what was delivered
• Optional follow-on refinement (outside the event):
  • Based on feedback, the Product Owner may update and reorder the Product Backlog as an ongoing activity.
  • The team may provide input on feasibility, dependencies, and evidence; refinement is not a required Sprint Review activity.
• Output: Sprint outcome inspected, stakeholder feedback captured, and any authorized backlog adaptations recorded.

Sprint Retrospective (Friday, Week 2 of sprint, 1 hour)

Objective: Reflect on process; identify improvements for next sprint.

Activities:

• What went well? (20 min):
  • Team shares what worked: Good collaboration? Helpful tools? Smooth deployment?
  • Scrum Master captures on whiteboard/doc
• What didn't go well? (20 min):
  • Team shares challenges: Blockers? Unclear requirements? Technical debt? Slow tests?
  • No blaming; focus on process not people
• What will we change next sprint? (20 min):
  • Identify 1-3 concrete improvements:
    • Example: "We'll add automated testing to reduce bugs" or "PO will clarify stories 1 day before sprint planning"
  • Assign owners for improvement actions
• Output: Retrospective notes, action items for next sprint

Sprint Outputs:

• Potentially shippable product increment (working features added to product)
• Updated backlog
• Optional local measures such as a burndown chart or velocity, interpreted as diagnostic planning observations rather than productivity targets
• Retrospective actions

Sprint Health Metrics:

• Prefer measures tied to the product decision: Sprint Goal evidence, outcome, flow, quality, reliability, customer impact, risk, and forecast error.
• If velocity or completion is used, keep definitions stable within one team and treat trends as diagnostic observations, not productivity targets or cross-team comparisons.
• Set defect and release tolerances from severity, exposure, safety, regulation, service level, detectability, and rollback—not universal percentages.

Red Flags:

• Material change in flow, goal evidence, quality, or forecast error → verify definitions and investigate multiple explanations; do not diagnose capacity from a fixed velocity decline
• Repeated inability to meet Sprint Goals → inspect goal quality, scope, dependencies, interruptions, capability, and product decisions without a universal percentage
• Retrospective actions not implemented → Team not learning; Scrum Master needs to follow up
• Stakeholders skip sprint reviews → Disengagement; risk building wrong thing
• Technical debt or quality risk accumulating → compare refactoring, redesign, testing, scope, and sequencing from risk and product value; no fixed Sprint allocation applies

Contingency Triggers:

• If team consistently over-commits → Reduce capacity estimate (commit to fewer points)
• If PO unavailable → Escalate; Scrum doesn't work without engaged PO
• If blockers persist >2 days → Scrum Master escalates to leadership
• If stakeholder feedback contradicts PO direction → Facilitate alignment session

Release Planning (Parallel to Sprints, Every 3-6 Sprints)

Objective: Plan major releases (collections of features) for go-live.

Activities (4-8 hours every 3-6 sprints):

• Release Goal Definition:
  • What features will be in next release?
  • When will release go live? (target date)
  • Who is target audience? (beta users, all users, specific segment)
• Release Backlog:
  • Group stories into release: "Release 1.0 includes login, profile, search features"
  • Estimate completion from a range using scope, dependencies, risk, capacity, flow, and relevant team history; velocity alone is insufficient
• Release Criteria:
  • Defects within the authorized severity- and exposure-based release tolerance; some critical contexts require zero unresolved critical defects, while counts alone are insufficient
  • Performance acceptable (load testing passed)
  • Security reviewed (pen testing if applicable)
  • Training/documentation complete
• Go/No-Go Decision:
  • Review release criteria
  • Decide: Launch, delay, or descope?
• Output: Release plan (features, timeline, go-live date)

Release Cadence:

• Fast iteration: Release every sprint (continuous delivery; common for SaaS)
• Moderate: Release every 3-6 sprints (2-3 months; common for mobile apps)
• Slow: Release 2-4 times/year (common for enterprise software with long sales cycles)

Agile Retrospectives & Learning (Ongoing)

Objective: Continuously improve process, tools, and team dynamics.

Metrics to Track:

• If used, velocity trends interpreted as local planning observations—not “increasing is good” productivity scores
• Defect severity, exposure, detection, recurrence, and escape rather than count direction alone
• Sprint Goal evidence without a universal achievement percentage
• Voluntary, confidential team-experience measures under approved instruments; a generic happiness rating is not NPS
• Stakeholder satisfaction (are stakeholders happy with product progress?)

Adjustments Over Time:

• Inspect whether the delivery system produces better customer, product, flow, quality, risk, and forecasting evidence.
• Teams may continue learning and redesigning at any Sprint; no fixed calibration, optimization, or maturity ranges apply, and high velocity is not maturity.

Common Agile Pitfalls & Fixes:

• Pitfall: PO acts as project manager (controlling tasks) instead of defining product
  • Fix: Empower team to self-organize; PO focuses on what, team decides how
• Pitfall: Daily standups become status reports to manager
  • Fix: Reframe as team sync (not reporting up); manager doesn't attend or listens only
• Pitfall: Sprint planning takes >4 hours (too much detail)
  • Fix: Refine backlog items before Sprint Planning when useful; do not treat “grooming” as a Scrum requirement
• Pitfall: No retrospective improvements implemented
  • Fix: Scrum Master tracks actions, follows up, ensures changes happen
• Pitfall: Stakeholders want detailed long-term plan (conflicts with agility)
  • Fix: Provide roadmap (themes/epics for next 3-6 months), but emphasize that details will emerge

Summary: Delivery Tailoring Matrix

The matrix is a qualitative tailoring aid; evaluate the project's actual constraints rather than applying the examples as fixed thresholds. ^{[1] [6] [2]}

When to Use This Operating Manual

Use the sample predictive track for artifacts that benefit from an explicit baseline and the sample adaptive track for work that benefits from frequent inspection and revision. A project may use both, neither, or different practices by workstream. Document the rationale, authority, interfaces, and triggers rather than calling the result “hybrid” as a substitute for design.

Chapter Summary

This chapter provided formal project management frameworks:

1. Predictive process groups - Five recurring groups, not five lifecycle phases
2. WBS - Hierarchical decomposition of scope
3. CPM & Gantt - Schedule management and critical path analysis
4. EVM - Integrated cost and schedule performance measurement
5. Risk Management - Identify, analyze, respond, monitor
6. Stakeholder Management - Engagement strategies by power/interest
7. Agile/Scrum - Iterative development with sprints
8. Constructed flow board - Visual workflow and locally justified WIP policies; not a full Kanban treatment
9. Change authority - Impact analysis and a tailored authorized decision route
10. Project charter - Purpose, boundaries, governance, and assigned authority

Table 11.10 — Predictive and adaptive practices. Constructed comparison; select practices independently from the project's evidence and constraints.

When these PMP-oriented frameworks may help: Use them as tailoring prompts, not numerical thresholds. Their value depends on the decision, evidence, authority, and consequences—not on project size or an industry label. ^[1]

• Projects with material scope, dependency, cost, risk, stakeholder, assurance, or change decisions
• Work involving multiple teams, suppliers, jurisdictions, or decision authorities
• Regulated, contractual, safety-critical, or otherwise high-consequence contexts where traceability and specialist review are required
• Any project where an explicit baseline, feedback loop, forecast, or decision record would improve the next decision

Next Chapter: Client Management - Stakeholder engagement, presentations, difficult conversations

Cross-references: See Chapter 7 for teams and leadership, Chapter 9 for issue trees and MECE, Chapter 10 for integrated initiatives, and Chapter 12 for client and stakeholder governance.