← Management ConsultingCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Management Consulting
Snapshot Sep 30, 2026 · 23:14 UTC · version 2.2.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Design and operate consulting engagement governance: decision rights, steering committees, RACI, risk and issue registers, status reports, escalation, and stage gates. Use for oversight of delivery; use implementation-planning when available for the execution plan itself.",
"included_files": [
{
"relative_path": "references/risk-and-reporting.md",
"size_in_bytes": 3007
}
],
"name": "project-governance",
"skill_md_contents": "---\nname: project-governance\ndescription: \"Design and operate consulting engagement governance: decision rights, steering committees, RACI, risk and issue registers, status reports, escalation, and stage gates. Use for oversight of delivery; use implementation-planning when available for the execution plan itself.\"\nlicense: MIT\nmetadata:\n category: engagement-delivery\n version: \"2.2.0\"\n author: Anot\n---\n\n# Project Governance\n\nGive the client timely decisions and visibility into delivery. Use the lightest governance that meets the engagement's risk, complexity, and mandatory controls. Start from the client's existing PMO templates, contract, decision rights, and reporting rhythm.\n\nUse available scope, budget, team, milestones, and reporting evidence. Mark missing facts and proposed roles instead of inventing names or approvals. Complete useful draft governance without waiting for charter sign-off; distinguish a proposal from authority to spend, deploy, or change the engagement.\n\n## Establish authority and cadence\n\nA small advisory engagement may need a sponsor, engagement lead, decision log, and short check-in. A transformation may need workstream forums, a program review, and a steering committee. Add a forum only when it makes a decision, resolves a dependency, or satisfies an identified requirement.\n\nFor consequential decisions, record the decider, required input or approval, deadline, escalation path, and evidence needed. Distinguish the consultant's internal recommendation review from the client's decision to invest or implement. If the user supplies joint approvals or regulated authorities, preserve them explicitly.\n\nUse RACI when it clarifies delivery responsibility. Normally assign one accountable role per deliverable and at least one responsible role; the same person may be both. Record assignments as proposed until confirmed. Keep roles current when ownership changes.\n\n## Report the state of delivery\n\nLead with the overall assessment, the decision or intervention needed, and when it becomes time-critical. Separate baseline, current forecast, and approved changes. Report outcomes completed, remaining work, milestones, cost, resource constraints, and material dependencies at the requested depth.\n\nShow RAG status with definitions and trend. Use Unknown where evidence is missing; do not convert missing information into Green. Base progress on delivered scope or a defensible measure of remaining effort. Compare spending to planned and earned progress with the cost curve in view; early front-loaded expenditure alone does not prove overrun.\n\nUse [risk, issues, and reporting](references/risk-and-reporting.md) for registers, severity, forecasting, and escalation. Numerical probabilities and risk scores require a stated basis. Preserve material uncertainty and source conflicts.\n\n## Use gates as decisions\n\nFor each gate define the relevant evidence, authority, decision deadline, and options: proceed, proceed with explicit conditions, revise, or stop. Readiness criteria depend on the transition. A go-live gate tests operational readiness before launch; closure acceptance is a separate decision.\n\nTrack accepted conditions and open items to a named role and date. Do not treat a passed gate as proof that all future risks are resolved. Avoid duplicating agile and phase-based reporting; use one coherent rhythm with necessary approval points.\n\n## Deliver and maintain\n\nProduce the charter, decision-rights map, status report, register, or governance design requested. Include actionable escalations rather than a mandatory collection of every governance artifact. Check that decisions sit with authorized roles, status follows evidence, dates are feasible, and material risks have owners and responses.\n\nPreparing a status report or meeting pack does not authorize sending it, scheduling meetings, or recording approvals. At closeout, document the handback of decision and reporting responsibilities; use project-closeout when available for detailed handover and benefits ownership.\n"
}SHA-256 of public snapshot: ce0855d1f592917e52d6b19c37a0f2a89308e79abebbf131d2544331d616fc93