Change Control Log

Every scope, cost, schedule or vendor change raised on the Beacon Index Advantage program since Gate 0, with the decision taken and the reasoning behind it. Status date 16 October 2026. Each entry links to its full change request form in the Change Request Detail.

1. About this log

A stage-gate program has two distinct control mechanisms and they are easy to confuse. The Gate Conditions Register records obligations the board attaches to a gate decision: things that must be true before the program may continue. This log records changes to the baseline between gates — scope, cost, schedule, vendor terms — whether or not a gate is anywhere near.

The two interact. Three of the requests below exist because a gate condition obliged the program to act: a condition creates the obligation, but it is a change request that amends the baseline. Recording only the condition would leave the scope baseline silently out of date.

2. Change requests at a glance

3. Decision profile

4. Financial effect

Two requests drew on contingency, and they are the only two draws the program has made: $232,000 for the Gate 1 recycle loop (CR-004) and $180,000 for the external actuarial peer review (CR-003). Together $412,000 of the $2,304,000 reserve, or 18%.

⚠ The savings from CR-001 and CR-002 were deliberately not re-baselined into a lower authorized ceiling. On a stage-gate program the tranche is an authorization to spend up to a limit, not a forecast; reducing the ceiling every time scope narrows would leave no absorption capacity for the change requests that follow, and would make each subsequent request a board matter.

5. Where change requests come from

Half the register exists because of a decision the board itself took — three conditions and one recycle. That is characteristic of stage-gate governance and not a sign of instability: a board that attaches conditions is a board that generates change requests, and a program that recorded the conditions but not their effect on the baseline would look more stable than it is.

6. How a change is raised and decided

Change authority on this program is deliberately split, because routing every request to a seven-member board that meets at gates would either stall the program between gates or push people to make changes without recording them. The thresholds below are set in the Stage-Gate Governance Model §9.

A request is raised on the standard form, which is the structure reproduced for every record in the detail. The form is not optional and it is not shortened for small changes: the impact assessment across scope, schedule, cost, quality and risk is what distinguishes an assessed change from an accepted one, and the alternatives section is what stops the first workable idea from becoming the decision.

7. What an approved change amends — and what a declined one does next

An approved change request is not itself the baseline. It is an instruction to amend specific documents, and a register that does not name them produces a program whose baseline documents quietly disagree with its change log. Each approval below carries its amendment set.

⚠ Note what is not on that list. No approval here amended the authorized ceiling of $27,904,000, and none amended a gate date. On a stage-gate program those two figures are the board’s, not the program manager’s, and a change request that would move either is not a change request — it is a gate matter, which is precisely the reasoning that deferred CR-006.

Declined does not mean closed

A declined request leaves a problem behind, and the failure mode of most change registers is that the problem disappears with the request. Both declines here are explicitly kept open:

• CR-005 was declined on pricing discipline, but the uncommitted premium it was offered to solve remains referred to I-06 and R-07. The board directed that the two-year point-to-point alternative be assessed by pricing and brought to Gate 2 — so the underlying question is scheduled, not dismissed.
• CR-007 was declined because external counsel would not move a date controlled by another institution’s credit committee. GC-05 therefore stays at risk into Gate 2, and a fallback third counterparty is to be assessed before then. The decline made the risk more visible, not less.

A request may be re-raised once the fact pattern behind it changes — not simply because the requestor still wants it. Both declines above name the specific evidence that would justify a re-raise, which is what stops a register from turning into a record of who asked most persistently. ⚠ This is also why the deferral of CR-006 is recorded as a deferral rather than a decline: the board found nothing wrong with it, and mislabeling that would misrepresent both the request and the board.

8. How to use this log

1. Read the decision column first. The two declines and the deferral carry more information about how this board operates than the five approvals do.
2. Open the full form for anything that matters. Each entry in the detail records what happens if the request is approved and what happens if it is not — which is the do-nothing option made concrete rather than left implied.
3. Check the alternatives. A request with no alternatives considered is a request that was never really assessed. Every entry here lists at least three.
4. Follow the cross-references. Requests tie to gate conditions, RAIDD entries and the budget. A change register that does not reconcile to the risk log and the money is a document rather than a control.

9. Document control

Maintained by C. Tyrrell, NPD Program Manager and Chair of the Gate Review Board. Related: Change Request Detail · Gate Conditions Register · Stage-Gate Governance Model · RAIDD Log · Program Budget.