Fictional case study · Document 16 · Week 9
Schedule Change Request and Decision
The PM requests a one-week change after ISS-01, and the sponsor records the decision and follow-up actions.
Illustrative project record. AegisShield, BookEasy, the people, decisions and outcomes are fictional.
Change request
Requested by: Project Manager. Date requested: February 27, 2026 (simulated). Reason: ISS-01 blocks the BookEasy pilot because a timeout retry can create duplicate events. Proposed change: move the plan from 12 to 13 calendar weeks while keeping scope and acceptance criteria unchanged. The PM recommends delaying the pilot rather than reducing tests. The request uses targeted part-time effort from Engineering, QA, PM and Customer Success; no additional budget is requested at this point. BookEasy and the delivery team confirm availability for the revised dates.
Pre-decision analysis
| Area | Impact |
|---|---|
| Dates | Pilot moves from week 10 to week 11; production from week 11 to week 12; stabilization, handover and closure move to week 13. |
| Resources | Targeted recovery work is added; a full extra week is not assumed for every role. |
| Costs | No additional budget is approved; any material impact is escalated. |
| Risks | Keeping the original date would risk duplicate events and weak acceptance evidence; reducing tests would increase release risk. |
Decision record
| Field | Record |
|---|---|
| Reference | DEC-01; related to ISS-01 and risk R03 |
| Requested by | Project manager, based on Engineering and QA's recovery estimate |
| Date requested | February 27, 2026 (simulated) |
| Decision maker | CTO / project sponsor |
| Date approved | March 2, 2026 (simulated) |
| Decision | Approve a one-week schedule extension; keep the agreed scope and release criteria. |
| PM recommendation | Delay the pilot rather than reduce testing, because the defect affects event integrity and customer acceptance. |
| Alternatives considered | Reduce test scope (rejected); keep week 10 without a fix (rejected); add capacity (reviewed but not required). |
| Decision limit | This schedule decision does not authorize production; a separate go/no-go is still required. |
Revised baseline
| Milestone | Original baseline | Revised baseline |
|---|---|---|
| BookEasy pilot | Week 10 | Week 11, subject to passing retest |
| Controlled production release | Week 11 | Week 12, subject to pilot acceptance and go/no-go |
| Handover and project closure | Week 12 | Week 13 after stabilization |
Resource and cost impact
The extra calendar week uses targeted part-time Engineering, QA, PM and Customer Success effort for the fix, retest and customer coordination. It does not mean a full extra week for every role. No additional budget is approved in this decision; any material capacity or cost impact must be escalated separately. Engineering, QA and BookEasy confirmed availability for the revised dates.
Schedule version and terms
The approved schedule becomes Revised Baseline v1.1. Forecast means the date the team expects to finish; revised baseline means the sponsor-approved dates used to measure progress. Schedule extension means adding time to the plan. Go/no-go remains the separate decision to proceed with or postpone production.
Post-decision actions
The PM updates the schedule to Revised Baseline v1.1, confirms capacity with Engineering and QA, confirms the revised pilot date with BookEasy through Customer Success, updates the GitHub board snapshot, and communicates the new dates. Engineering and QA report retest results. The revised baseline is not permission to release: the separate production go/no-go remains required.