1 Project Governance and Decision Rights

Governance and oversight

Project governance establishes how a project is directed and overseen. It clarifies who may decide what, how decisions are reviewed, and when issues must be referred to a higher authority. It complements day-to-day project management rather than replacing it.

A sound framework is clear and proportionate to the project’s scale and complexity. It should use only the roles and forums needed for effective oversight, and those arrangements should be reviewed as the project changes.

Allocating decision authority

Assign decision rights before delivery begins, usually in the project charter, governance plan, or board terms of reference. The framework should make the approval authority explicit rather than relying on assumptions.

• Match authority to accountability: A person answerable for an outcome should have the authority, or a defined route to obtain authority, to make the decisions needed for it.

• Delegate to the lowest capable level: The project manager and team should make routine decisions within agreed limits. Reserve decisions with strategic, cross-project, or significant organizational effects for the sponsor or governing board.

• Name one accountable decision owner: Others may advise, provide evidence, or be consulted, but the framework should identify who approves the decision.

• Set limits in advance: Define decision boundaries and approval thresholds.

• Keep arrangements proportionate: Use only the roles and forums needed for oversight, and review them as the project changes.

A typical arrangement has the project team resolving day-to-day delivery questions, the project manager directing work and approving matters within delegated tolerances, and the sponsor or project board deciding matters outside those tolerances. Examples of matters for the sponsor or board include major changes to objectives, funding, or risk exposure. Role titles vary by organization, so authority should be stated explicitly.

Setting decision boundaries

A decision boundary states when a role may decide independently and when approval is required. Boundaries commonly cover:

• scope and expected outcomes;

• budget and forecast cost;

• schedule and milestone dates;

• quality or technical requirements;

• risks, safety, legal, and regulatory obligations; and

• changes to benefits, resources, or stakeholder commitments.

For example, a project manager might approve a small schedule adjustment if it stays within an agreed tolerance and does not affect a contractual milestone. A change that exceeds the tolerance, reduces a required outcome, or creates a material new risk should go to the designated sponsor or board. Limits should be specific enough to guide action: a vague instruction to escalate “significant changes” can leave room for disagreement.

Routing issues for escalation

Escalation is the planned route for a decision or issue that exceeds someone’s authority, cannot be resolved at the current level, or needs wider oversight. The governance plan should specify what triggers escalation, who receives it, what information is required, and how quickly a response is needed.

A practical sequence is:

1. The responsible team member raises and assesses the issue with the project manager.

2. The project manager considers options, impacts, urgency, and whether the issue is within delegated limits.

3. If the issue is outside those limits, the project manager refers it to the sponsor, change-control authority, or project board designated for that decision type.

4. The decision owner decides, requests further analysis, or refers the matter to a higher organizational authority when necessary.

5. The decision and resulting actions are communicated to affected people and tracked to completion.

Escalation should bring a matter to the right authority in time for action, not merely report that a problem exists. The project team should provide a concise problem statement, relevant evidence, consequences of delay, and feasible options.

Recording and tracking decisions

Maintain a decision log as the authoritative record of important project decisions. Each entry should include:

• a unique reference and date;

• the question or decision required;

• the decision owner and people consulted;

• the options and key evidence considered;

• the decision, rationale, and any conditions;

• impacts on scope, cost, schedule, quality, risk, or benefits; and

• actions, owners, due dates, and any review or approval reference.

Record decisions promptly, share them with affected stakeholders, and link them to relevant change requests, plans, or meeting records. A decision log supports traceability by showing what was decided, who had authority, and why the decision was made. It also helps prevent old assumptions from being mistaken for current approvals.