v1 Published snapshot
Run a Project Governance Cycle
Use when the delivery owner needs a repeatable weekly or milestone-based assessment of progress, decisions, dependencies, and risks for an active customer engagement. A cycle ends with a trustworthy view of delivery and targeted course corrections; it does not replace incident response or a full project restart.
Starting inputs
- project *
Project or engagement identifier.
string
- audience
Primary audience, e.g. delivery team, sponsor, or steering committee.
string
- planSources
Milestone plan, issue tracker, meeting notes, resource plan and status sources.
array
- reviewPeriod *
Reporting window or checkpoint date.
string
Steps
- 1
Reconcile the baseline with verified work
Read the latest approved milestone baseline and active work items. For each milestone, establish planned versus evidenced completion, accepted deliverables, elapsed time, spend or capacity if available, and the date of the observation. Use source links and distinguish shipped, reviewed and customer-accepted. Ask owners for material missing evidence; never equate a status tag with acceptance. Gate: a skeptical stakeholder can tell what was completed, what merely moved, and what remains unverifiable.
- 2
Diagnose exceptions and forecast consequences
Review late tasks, blocked dependencies, unresolved decisions, scope changes, resource constraints and customer-side obligations. Classify risks by probability, impact, early-warning signal and mitigation owner without fake precision. Forecast likely impacts to milestone dates and acceptance using ranges or explicit scenarios where exact estimates are unavailable. Separate active issues from future risks. Gate: the top problems are prioritized by their effect on outcomes, not by volume of tickets.
- 3
Design corrective actions and decision requests
For each material exception, propose options such as resequencing, reducing scope via formal approval, allocating scarce capacity, gaining customer access or revising acceptance approach. State the trade-off, decision owner, deadline and the smallest verifiable action. Do not independently amend contractual scope, dates or budget. Escalate only those decisions the owner cannot make. Gate: each red/amber issue has a credible option and a named authority for the necessary choice.
- 4
Run the status or steering review
Create an audience-appropriate one-page status with outcomes, confidence, exceptions, options and precise asks; put detail in an appendix rather than burying the headline. Use confirmed numbers, cite source dates and record disagreement. After the review, distinguish decisions made from proposals and undecided items; do not infer consent from attendance. Gate: the reader can see what matters, what changed, and which decision is required without reconstructing the tracker.
- 5
Update the operating baseline
Update the project plan, RAID items and decision history to reflect only the authorized decisions; otherwise prepare exact proposed changes. Check that owners, dates and dependencies remain internally consistent and that no action appears simultaneously done and open. Track the next verification checkpoint for critical corrective actions, not a generic handoff. Gate: the current baseline is unambiguous and the next review will measure real progress against it.
Content digest
sha256:sha256:21a3fab3a4e40dc408af4caea4523639b57e036f3f85162da17e2c07633bca38{"category":"operations","description":"Use when the delivery owner needs a repeatable weekly or milestone-based assessment of progress, decisions, dependencies, and risks for an active customer engagement. A cycle ends with a trustworthy view of delivery and targeted course corrections; it does not replace incident response or a full project restart.","inputSchema":{"additionalProperties":false,"properties":{"audience":{"description":"Primary audience, e.g. delivery team, sponsor, or steering committee.","type":"string"},"planSources":{"description":"Milestone plan, issue tracker, meeting notes, resource plan and status sources.","items":{"type":"string"},"type":"array"},"project":{"description":"Project or engagement identifier.","minLength":1,"type":"string"},"reviewPeriod":{"description":"Reporting window or checkpoint date.","minLength":1,"type":"string"}},"required":["project","reviewPeriod"],"type":"object"},"schemaVersion":1,"steps":[{"expectedOutputs":[{"description":"Milestone-by-milestone variance, dated evidence and limitations.","kind":"status-baseline"}],"id":"R2PS","instructions":"Read the latest approved milestone baseline and active work items. For each milestone, establish planned versus evidenced completion, accepted deliverables, elapsed time, spend or capacity if available, and the date of the observation. Use source links and distinguish shipped, reviewed and customer-accepted. Ask owners for material missing evidence; never equate a status tag with acceptance. Gate: a skeptical stakeholder can tell what was completed, what merely moved, and what remains unverifiable.","resourceHints":[],"title":"Reconcile the baseline with verified work"},{"expectedOutputs":[{"description":"Prioritized RAID view and scenario-based schedule impact.","kind":"risk-and-issue-register"}],"id":"OYNA","instructions":"Review late tasks, blocked dependencies, unresolved decisions, scope changes, resource constraints and customer-side obligations. Classify risks by probability, impact, early-warning signal and mitigation owner without fake precision. Forecast likely impacts to milestone dates and acceptance using ranges or explicit scenarios where exact estimates are unavailable. Separate active issues from future risks. Gate: the top problems are prioritized by their effect on outcomes, not by volume of tickets.","resourceHints":[],"title":"Diagnose exceptions and forecast consequences"},{"expectedOutputs":[{"description":"Actionable countermeasures and decision-ready escalations.","kind":"correction-plan"}],"id":"Z6FH","instructions":"For each material exception, propose options such as resequencing, reducing scope via formal approval, allocating scarce capacity, gaining customer access or revising acceptance approach. State the trade-off, decision owner, deadline and the smallest verifiable action. Do not independently amend contractual scope, dates or budget. Escalate only those decisions the owner cannot make. Gate: each red/amber issue has a credible option and a named authority for the necessary choice.","resourceHints":[],"title":"Design corrective actions and decision requests"},{"expectedOutputs":[{"description":"Sponsor-ready status narrative, decision log and review outcomes.","kind":"governance-review"}],"id":"588N","instructions":"Create an audience-appropriate one-page status with outcomes, confidence, exceptions, options and precise asks; put detail in an appendix rather than burying the headline. Use confirmed numbers, cite source dates and record disagreement. After the review, distinguish decisions made from proposals and undecided items; do not infer consent from attendance. Gate: the reader can see what matters, what changed, and which decision is required without reconstructing the tracker.","resourceHints":[],"title":"Run the status or steering review"},{"expectedOutputs":[{"description":"Current project status, RAID and milestone baseline with verified updates.","kind":"updated-control-set"}],"id":"2OAE","instructions":"Update the project plan, RAID items and decision history to reflect only the authorized decisions; otherwise prepare exact proposed changes. Check that owners, dates and dependencies remain internally consistent and that no action appears simultaneously done and open. Track the next verification checkpoint for critical corrective actions, not a generic handoff. Gate: the current baseline is unambiguous and the next review will measure real progress against it.","resourceHints":[],"title":"Update the operating baseline"}],"title":"Run a Project Governance Cycle"}