Governance Structures That Prevent SaaS Project Failure

The two most common governance failures in SaaS implementation projects are opposites. The first is under-governance: no steering committee, no formal escalation path, project decisions made informally by whoever is loudest in the room, and a project manager who is technically accountable for delivery but has no real authority to enforce decisions. The second is over-governance: approval processes so layered that a configuration change requires sign-off from four stakeholders who each need a week to review it, and a programme board that meets monthly to be briefed on a project moving in weekly sprints.

Both failure modes share the same underlying problem: governance structures that don’t match the pace and decision-making needs of the actual project. The result in both cases is the same. Problems that should have been resolved in days compound over weeks, because either nobody has the authority to resolve them or the process for doing so is slower than the project.

Effective implementation governance is a deliberately calibrated structure: enough formality to ensure the right decisions reach the right people at the right time, light enough to avoid becoming the reason nothing gets decided. Here is what that looks like in practice.

 

Steering Committee: Who, How Often, and What They Decide

The steering committee is the senior governance body for the implementation. Its function is not to manage the project, as that’s the project manager’s role, but to make the decisions that are above the project manager’s authority: budget authorisation beyond a defined threshold, significant scope changes, risk acceptance for issues escalated from the project team, and go/no-go decisions at defined implementation gates.

 

Membership

Membership should be small and decision-capable. The right composition is: the project sponsor (a business executive who owns the outcome), the vendor’s implementation director or equivalent, the business owner for each major impacted department (typically two to three people), and the project manager as the meeting lead and information presenter. Eight people maximum. More than that and the meeting becomes a briefing session rather than a decision forum.

 

Meeting Cadence

Cadence for a mid-complexity implementation should be fortnightly during active delivery, moving to weekly in the final four weeks before go-live. Monthly is not frequent enough. A SaaS implementation can produce three or four decision-requiring issues in a week. If the steering committee meets monthly, those decisions are either made informally (undermining the governance structure) or deferred for a month (compounding the problem).

 

Structuring the Agenda Around Decisions

The agenda should be structured around decisions, not updates. Status updates belong in a written report circulated before the meeting. The meeting time is for escalated risks requiring a decision, scope change requests above the project manager’s authority threshold, and blocked items where the steering committee’s intervention is needed to unblock progress. Steering committees that spend forty minutes on status updates and ten minutes on decisions have the agenda backwards.

 

Change Control: Protecting Scope Without Killing Velocity

Change control is the mechanism that prevents scope from expanding informally during delivery. Done well, it provides full visibility into what the project is actually building, ensures changes are costed and approved before work begins, and gives the steering committee an accurate picture of scope evolution over time. Done poorly, it becomes an obstacle that project teams route around, making informal agreements to “just add this” and back-filling the paperwork after the fact.

 

Proportional Approval Thresholds

The key design principle is proportionality. Not all scope changes carry the same risk. A change requiring four hours of configuration work should not require the same approval process as a change requiring four weeks of integration development. A practical threshold structure: changes up to a defined effort level (say, one day of work) are approved by the project manager and logged in the change register. Changes above that threshold require the project sponsor’s written approval before work begins. Changes above a higher threshold (say, five days of work) require a steering committee decision.

 

The Change Register

The change register is as important as the approval process. Every approved change should be logged with: a brief description of what was requested and why, the assessed impact in effort, cost, and timeline, who approved it and when, and whether the project baseline was updated to reflect it. The change register should be a standing agenda item at steering committee meetings, not to review each change in detail, but to maintain visibility of cumulative scope evolution. A project that has approved thirty changes over twelve weeks needs its baseline updated and its go-live date reassessed, even if each individual change looked small in isolation.

 

RACI Matrix: Removing Decision Ambiguity

A RACI matrix (Responsible, Accountable, Consulted, Informed) for implementation decisions eliminates the ambiguity that generates the most common governance failure: decisions that aren’t made because everyone assumed someone else was making them.

 

Decisions That Most Frequently Stall

The decisions that most frequently stall without a clear RACI are: business process design choices (when the new system can’t exactly replicate the legacy process, who decides the new approach?); data cleansing acceptance (who is accountable for confirming that migrated data meets the quality standard?); defect severity classification (who has the authority to accept a defect as “acceptable for go-live” versus requiring resolution?); and go/no-go (who makes the final call, and what do they need to see to make it?).

 

One Accountable Person Per Decision

A RACI that assigns Accountable to more than one person is not a RACI. Joint accountability means diffused accountability, which in practice means no accountability. For each major decision category, there should be exactly one Accountable person. Consulted parties provide input. Informed parties receive the outcome. Only one person is accountable for the decision itself.

 

Risk Escalation: Traffic Light Reporting That Means Something

Most implementation projects use red/amber/green (RAG) status reporting. Most RAG reporting is unreliable as a governance tool because the rating reflects how the project team wants the situation to be perceived, not what the situation actually is. Projects stay amber for six weeks before turning red two weeks before go-live, because nobody wants to be the person who called red and was wrong.

 

Objective Criteria for RAG Status

Effective risk escalation requires two things: objective criteria for each RAG status, and a clear escalation path that makes it safe to escalate rather than penalising it.

Objective criteria means that RAG status is determined by measurable indicators, not subjective assessment. Green means: sprint velocity is within 10% of plan, defect closure rate exceeds discovery rate, all integration milestones are on schedule, no unresolved risks rated high or critical. Amber means: one or more of those conditions is not met, a remediation plan exists, and the project manager has authority to execute it. Red means: one or more amber conditions has persisted for two sprints, or a new risk has emerged that requires steering committee decision to resolve.

 

Making Escalation Safe

Making escalation safe means that a project manager who calls red and escalates a problem is recognised for surfacing it, not managed as if they caused it. Implementation governance cultures where the implicit rule is “don’t call red unless you want a difficult conversation with the steering committee” produce exactly the late-stage crises they’re designed to prevent. The escalation path exists to accelerate decision-making. It only works if it’s used.

 

Vendor Governance: SLAs, Issues, and Release Management

SaaS vendor governance is an area that many implementation project teams under-invest in, on the assumption that vendor management is the procurement team’s responsibility. In practice, vendor performance during implementation, covering configuration support responsiveness, sandbox environment stability, defect resolution timelines, and release management during active delivery, directly affects project delivery, and managing it is the implementation team’s responsibility.

 

The Three Governance Mechanisms That Matter

The three governance mechanisms that matter most are: a documented issue log (not the general project risk log, but a specific log of vendor performance issues with dates raised, response times, and resolution status); a defined escalation path within the vendor organisation (the implementation project manager’s contact, their manager, and the vendor’s client success director); and a release change notification process (formal agreement that the vendor will provide advance notice of platform releases during the implementation period, with the project team’s right to defer releases that conflict with active testing phases).

 

Managing Vendor Releases During Testing

Vendor releases during active testing are a specific governance risk that many implementations don’t anticipate. A platform update deployed by the vendor mid-testing phase can invalidate test cases already executed, introduce regressions in areas the team has already signed off, and create a re-testing burden that wasn’t in the project plan. The governance control is a formal freeze agreement, meaning no vendor releases to the implementation environment during defined testing windows, that is negotiated as part of the project setup, not discovered as a gap when the first disruptive release arrives.

 

QA Governance: Defect Classification and Go/No-Go Criteria

Quality assurance governance defines the standards by which the implementation is judged ready to go live. Without it, go/no-go decisions are made under deadline pressure, with inconsistent criteria applied to individual defects, and a tendency to accept risk that will materialise as production incidents within thirty days of go-live.

 

Defect Severity Classification

Defect severity classification should be agreed and documented before testing begins, not during it. A workable four-level classification:

Critical: System cannot be used for its primary purpose, no workaround exists, go-live is blocked.

High: Significant functionality is impaired, workaround exists but is not acceptable for extended production use, must be resolved before go-live.

Medium: Functionality is impaired, acceptable workaround exists, may be resolved in a post-go-live patch within thirty days.

Low: Cosmetic or minor issue, does not affect functionality, resolved in a future release.

Any defect that is accepted as “go-live risk” at Critical or High severity should require explicit written acceptance from the project sponsor, not from the project manager.

 

Go/No-Go Criteria

Go/no-go criteria should be defined at project initiation and reconfirmed at the final steering committee before the go-live date. The criteria should be objective and binary: zero Critical defects, High defects below a defined threshold, all integration smoke tests passed, data migration validation signed off by business owners, rollback procedure tested and documented, and hypercare support arrangements confirmed. If the criteria are met, go-live proceeds. If they are not, the go/no-go decision requires a steering committee decision, not a project manager judgement call under pressure.

 

The Governance Theatre Problem

Governance theatre is the pattern where all the formal structures exist, including the steering committee, change control, risk register, and RAG reporting, but none of them are functioning as intended. The steering committee meets weekly but focuses on status rather than decisions. The risk register is updated before each meeting and never looked at between them. Change control is applied retrospectively. RAG status stays green until it’s suddenly red.

 

How to Spot It

The tell for governance theatre is simple: look at the last three steering committee meetings and count the decisions made. If the answer is zero, the governance structure is reporting on the project rather than governing it. The fix is not adding more governance process. It is redesigning the existing forums around the decisions they need to make, and holding the project team to the discipline of escalating problems through the structure rather than managing them informally.

 

Why Governance Design Matters

SaaS implementation governance works when it is designed for the pace of the project, calibrated to the size of the decisions, and used consistently from day one. That combination is less common than it should be, and the difference between implementations that succeed and those that don’t often comes down to whether the governance structure was set up to make decisions or merely to document that decisions weren’t made.