Lesson 5 of 5
Running the gate
9 min
Listen to this lesson
With questions defined, views assembled and data cleaned, the gate meeting should be short and decisive. Its job is not to discover the status; that work is done. Its job is for the accountable owners to look at the evidence, judge the residual risk and decide. This lesson covers how to facilitate that and how to record it in Cloud ALM so the decision is traceable.
Before the meeting
- Freeze the evidence: take snapshots of each view with filter, date and author, and attach or reference them in the gate's checklist items.
- Pre-assess each checklist item: met, met with conditions, or not met, with a one-line reason.
- Circulate the pack 24 to 48 hours ahead so owners can ask questions before, not during, the meeting.
- Confirm the decision makers will attend. A gate without the accountable owners is a status meeting.
In the meeting
- Purpose and criteriaChair (Grace) restates the gate and its agreed criteria
- Evidence by itemItem owners present met / conditions / not met, briefly
- Risks and exceptionsPriya presents open defects as risk statements and any coverage gaps
- DiscussionOwners question the evidence and the proposed conditions
- DecisionPass, pass with conditions, or fail with a re-gate date
- RecordOutcome, conditions, owners and dates recorded in Cloud ALM the same day
Three possible outcomes
| Outcome | When | What to record |
|---|---|---|
| Pass | All criteria met | Decision, decision makers, date, evidence references |
| Pass with conditions | Criteria met except items with an agreed mitigation | Each condition as a follow-up task with owner and due date; how it will be verified |
| Fail | Critical criteria not met | What must change, a re-gate date and the impact on the plan |
Gate outcomes. Conditions are where gates most often lose their teeth, so make them concrete.
Recording the outcome in Cloud ALM
Record the decision on the Quality Gate task itself: update each checklist item's result, add the decision and decision makers, and reference the evidence snapshots. Capture every condition or action item as a follow-up task linked to the gate, with an owner and a due date, so it shows up in the project's task lists and does not live only in meeting minutes. The gate's status on the project overview then reflects reality for everyone, including people who were not in the room.
- Are all critical criteria met?Yes → next question · No → fail; set re-gate date
- Are the remaining gaps covered by concrete mitigations?Yes → pass with conditions · No → fail or extend
- Does every condition have an owner, due date and verification?Yes → record and proceed · No → define them before closing the meeting
After the gate
Communicate the outcome the same day: what was decided, the conditions, and what changes for each team. Teams waiting to start UAT or a cutover rehearsal need to know whether they go on Monday. Then review the gate itself briefly. Which checklist items were hard to evidence? Which views needed manual work? Which hygiene problems surfaced late? Feed those answers into the checklist template for the next gate. Over a program, gates should get faster and less contentious; if they do not, the evidence or the data discipline needs work, not the meeting format. Keep the record of each gate in the same Cloud ALM project so that, at go-live, anyone can follow the chain of decisions from the first gate to the last.
What would you do?
At Contoso's end-of-Realize gate, Dan agrees to pass with a condition: "Finance will look at the revenue account defect." Nothing else is recorded. What should Priya do before the meeting closes?
- Do the status work before the meeting; the gate is for judgment and decision.
- Outcomes are pass, pass with conditions or fail; make every condition concrete.
- Record results, decision makers and evidence references on the Quality Gate task in Cloud ALM.
- Capture conditions as linked follow-up tasks and verify them at the next gate.
Check your understanding · not graded
Lesson check
1. Who should own the gate decision?
2. Where should gate conditions be tracked in Cloud ALM?
3. What makes a gate meeting a status meeting instead of a decision?
4. When should the closure of gate conditions be verified?