Run a Project Governance Cycle

{"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.\n\nV2 practical protocol:\nMilestone control method: for each milestone list baseline due date, current forecast, accepted deliverable, independent completion evidence, status as of time and responsible role. Calculate date variance = forecast finish − baseline finish, in days; annotate whether this is a model forecast or an approved rebaseline. Report earned value/SPI only if consistent work-package budgets and earned-value definitions exist; do not invent percentages for unmeasured progress. Note blocked acceptance separately from task completion. A concise exception table should show only changes since last review and items threatening the outcome.","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.\n\nV2 practical protocol:\nSchedule forecast: trace dependencies and identify the longest/critical remaining chain rather than summing parallel durations. For each late critical task, estimate remaining work, resource availability, prerequisite timing and confidence; derive best/likely/worst scenario where data support it. Distinguish active Issue (happened) from Risk (may happen), and include trigger, impact to customer milestone, probability confidence, owner and response. Severity must reflect consequence, not a decorative traffic-light score. When data are sparse, use explicit schedule uncertainty rather than an unfounded exact date.","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.\n\nV2 practical protocol:\nCorrective action method: test 2–3 feasible options against impact on accepted scope, time, capacity, cost and customer obligations. For example, resequence independent work, remove a dependency with an approved workaround, add focused capacity or formally rescope. For every option show the resulting forecast, decision authority, cost of delay, operational downside and proof required to judge the intervention. Do not alter approved scope, contract or budget on the agent's authority. If a decision is blocked, produce one explicit ask with owner and latest useful decision date rather than an open-ended escalation.","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.\n\nV2 practical protocol:\nReport structure: headline project outcome and confidence; what changed since last period; milestone forecast; top three risks/issues with consequence; decisions requested, with option trade-offs; and verified customer-side dependencies. Make executive versus delivery reporting adaptive: executives need effects and decisions, the delivery team needs action specifics. Audit red flags for unsupported \"on track\" status when critical path, customer acceptance or dependencies disagree. Meeting occurred only when there is genuine evidence of discussion, not because the agent wrote a draft.","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.\n\nV2 practical protocol:\nBaseline update checklist: new forecast and approved baseline must remain separate. Update only authorized task and project records; verify the returned state, owner, date, dependency and status. Preserve previous decisions and reasons for any approved replan. For material corrective actions define a specific verification signal and date; minor tasks need no extra formality. A cycle is done when exceptions and decisions are accurately reflected in an actionable plan, not when a status report is exported.","resourceHints":[],"title":"Update the operating baseline"}],"title":"Run a Project Governance Cycle"}