Project Management Plan

Lighthouse Financial Services Company — Beacon Index Advantage product development program. This plan defines how the program is managed across all knowledge areas. It is the management baseline — the companion to, and deliberately distinct from, the resource-loaded Work Breakdown Structure, which defines what the program builds.

1. Introduction & Purpose

This Project Management Plan defines how the Beacon Index Advantage product development program at Lighthouse Financial Services Company is managed. It is the authoritative statement of management intent across every knowledge area — scope, schedule, cost, quality, resources, communications, risk, procurement, stakeholders, change, and configuration — and it names, for each, the process the program follows and the person accountable for it.

This plan is deliberately distinct from the Work Breakdown Structure. The WBS is the what: the decomposed deliverables, work packages, task-level schedule and resource loading. This plan is the how: the rules under which that work is authorized, controlled, and judged. The two are frequently confused; they are not interchangeable, and this program maintains both.

2. Program Overview

Lighthouse Financial Services Company is a life and annuity carrier manufacturing product in-house. The program develops and launches the Beacon Index Advantage, a single-premium deferred fixed indexed annuity with an optional guaranteed-lifetime-withdrawal-benefit rider, a seven-year declining surrender-charge schedule, and three crediting strategies at launch. The product is filed at the state level; it is deliberately not a registered product, which keeps it out of the SEC/FINRA lane and in the state-filing regime.

The launch date is a fixed market commitment. When the Gate 1 recycle consumed calendar, the launch did not move; instead Stage 2 was compressed from 46 to 40 weeks. That asymmetry — fixed end date, absorbing schedule risk inside the stages — is a defining constraint of how this program is managed and recurs throughout this plan.

3. Project Management Approach

The program is run as a stage-gate new-product-development program. Work proceeds in four funded stages separated by formal gates. Each gate is a go/no-go decision point at which the Gate Review Board authorizes — or declines to authorize — the next stage and its funding tranche. The permissible gate outcomes are a closed set: GO, GO WITH CONDITIONS, RECYCLE, HOLD, and CANCEL.

This approach is chosen over a single linear plan for one reason: the program commits capital progressively against reduced uncertainty. No stage is funded until the gate before it confirms the business case still holds. Management effort therefore concentrates at the gates — assembling evidence, testing assumptions, and defending the decision — rather than being spread evenly across a Gantt chart.

4. Scope Management Plan

Scope definition. Program scope is fixed at each gate and cannot be expanded mid-stage. The launch scope was narrowed deliberately at Gate 1: crediting strategies were reduced from five to three (condition GC-01), and New York was removed from the launch-state set (condition GC-02) with a deferral memorandum issued. Both were scope decisions taken to protect feasibility, not de-scoping under pressure.

Scope control. Any change to product features, launch states, or committed deliverables is a scope change and follows the change process in §14. In-scope and out-of-scope boundaries are recorded in the charter and the requirements document; the illustration engine's supported strategy count is the single most scope-sensitive dependency and is tracked as such.

Scope verification. Scope completion is verified at gates against the gate's entry criteria, which are locked at the preceding gate. Scope is never declared complete by the delivery teams; it is accepted by the Board.

5. Requirements Management Plan

Requirements are captured in the product requirements document and traced through the Requirements Traceability Matrix. Every requirement carries a unique identifier and is traced forward to the design element, the test that validates it, and the gate at which it is accepted. Filing requirements — contract forms, actuarial memoranda, illustration rules — are first-class requirements, not downstream artifacts, because the state filing is the true launch gate.

Requirements are baselined at Gate 1 and change only through §14. A conflict between a modeled requirement and a filed requirement is resolved in favor of the filing: what is filed with the state is what the product legally is, and the model is corrected to match, never the reverse.

6. Schedule Management Plan

Schedule basis. The master schedule is gate-anchored, not a single continuous critical path. Each stage has a start, a fixed end at its gate, and an internal task schedule maintained in the resource-loaded WBS. The gate dates are the schedule's control points.

Schedule control. Because the launch date is fixed, schedule variance cannot be absorbed by moving the end date; it is absorbed inside the stage. The Stage 2 compression from 46 to 40 weeks after the Gate 1 recycle is the governing example. Schedule performance is reported against the next gate, not against a percent-complete, in the weekly status report. The program publishes no full-program earned-value baseline because Stages 3 and 4 are not yet funded; a program-level schedule index would be computed against a baseline that does not exist.

7. Cost Management Plan

Cost basis. Total authorized cost is $27,904,000: a base of $25,600,000 ($17,980,000 labor + $7,620,000 non-labor) plus a 9% gate contingency of $2,304,000. Funding is not released as a single baseline; it is released in four stage tranches, each authorized only at the gate that precedes its stage.

Contingency control. The contingency is drawn only by Board authorization against a named cause. Two draws are on record, totaling $412,000: the Gate 1 recycle loop ($232,000) and the external actuarial peer review ($180,000). $1,892,000 remains. Cost is distributed, never recomputed — team and stage costs trace to the authorized model, and no cost figure in any artifact is independently re-derived.

8. Quality Management Plan

Quality approach. Quality in a product-development program is conformance to the filed product and to the actuarial and compliance standards that govern it, verified independently of the teams that produce the work. Two independent-verification mechanisms are built into the plan: illustration validation (the illustrated values must match the filed rules) and external actuarial peer review of the rider pricing (condition GC-03), funded from contingency precisely so that the reviewer is independent of the pricing team.

Quality control at gates. Each gate applies a two-tier test: a set of must-meet knockout criteria evaluated first, then a weighted 1–5 score across weighted criteria. A knockout failure stops the gate regardless of the weighted score. Gate criteria are locked one gate in advance so that the bar cannot be lowered to fit the result.

The model is calibrated, not validated. The financial model states how each assumption could be wrong and what would reveal it; the downside IRR of 10.1% — which fails the 11.0% hurdle — is retained in the record rather than suppressed, because a quality plan that hides its own failure case is not a quality plan.

9. Resource Management Plan

Resourcing. The program is staffed by 90 people across 15 teams, totaling 146,440 hours. Team hours and costs are derived from seniority-banded rate assumptions and recorded in the resource plan and the resource-loaded WBS; they are not arithmetic-satisfying allocations but defensible estimates traceable to team composition.

Roles and the governance asymmetry. Delivery-team leads own their work packages but hold no vote at the gate. The people who build the product do not decide whether it passes — that authority rests solely with the Gate Review Board. This asymmetry is deliberate and is enforced in the RACI: no delivery-tier role is ever assigned decision accountability for a gate.

10. Communications Management Plan

Communications are governed by the program's Communications Management Plan, which this plan incorporates by reference. In summary: the Gate Review Board receives a structured pre-read before every gate; the program issues a weekly status report read against the next gate; assumption breaches trigger mandatory notification to the affected Board owner; and external communications to regulators and to independent marketing organizations follow defined channels with named owners. The Gate 1 recycle is retained in the communications record as the program's worked crisis-communications case: it was self-disclosed, quantified, and corrected across every downstream artifact.

11. Risk Management Plan

Risk approach. Risks, assumptions, issues, dependencies, and decisions are managed in a single integrated RAIDD register with unique two-digit identifiers per class. Risks are assessed for probability and impact and assigned a named owner; the register is reviewed on the program cadence and tabled at every gate.

Gate conditions are the live risk instrument. The five Gate 1 conditions (GC-01 through GC-05) are the current top-priority risk controls. As of the status date, 3 are closed, 1 is open and on track (the external peer review, due 26 Feb 2027), and 1 is flagged at risk: the hedging-readiness condition (GC-05), because ISDA execution with the second counterparty has not begun. Because launch is fixed, this schedule risk cannot be absorbed by moving launch and is escalated to the Chief Risk Officer.

12. Procurement Management Plan

Procurement approach. External work is contracted under statements of work with defined deliverables, acceptance criteria, and termination provisions. The principal engagement is the Cordelane statement of work; contract terms such as "terminated for convenience" are preserved exactly as written because they are legal vendor-contract language, not program status.

Procurement control. Vendor deliverables are accepted against their SOW acceptance criteria by the accountable program role, and vendor risk is carried in the RAIDD register alongside internal risk. The external actuarial peer reviewer is procured specifically for independence and is funded from contingency rather than from a team budget so that no delivery team holds the reviewer's purse.

13. Stakeholder Engagement Plan

Stakeholders. The primary decision stakeholders are the six members of the Gate Review Board. Each owns a domain of the gate decision and, where they are the accountable owner of an open gate condition, abstains from the vote on the gate at which that condition is verified.

The program manager chairs the Board from the PMO without a vote. Broader stakeholders — independent marketing organizations, wholesalers, state regulators — are engaged through the channels defined in the communications plan.

14. Change Management Plan

Change control. A change to any baseline — scope, schedule, cost, or a baselined requirement — is raised as a change request, assessed for its effect on the business case, and dispositioned by the appropriate authority. Changes that affect the gate decision are reserved to the Board; changes within a stage that do not move a baseline are dispositioned by the program manager and logged.

The baseline documents themselves — including this plan — are not edited to reflect change. The change is recorded; the baseline stands as the reference. This is how the program preserves the ability to answer, at closeout, whether it operated the way it said it would.

15. Configuration Management Plan

Configuration management. Every controlled artifact carries a single source of truth. The program's financial figures live in one fact base from which every document is generated, so that a figure cannot say one thing in the charter and another in the status report. Where two artifacts assert the same fact, an automated consistency check enforces their agreement rather than relying on manual reconciliation.

Artifacts are versioned; superseded values (for example the pre-recycle IRR of 14.6%) are retained as superseded rather than deleted, so the record shows what changed and when.

16. Governance & Decision Authority

Decision authority. The Gate Review Board is the sole authority for gate decisions. A CANCEL decision requires only a simple majority; a RECYCLE may be carried by any two members. Every gate decision records a mandatory dissent section, so that a minority view is preserved in the record even under a GO.

Chair without vote. The program manager chairs the Board from the PMO and does not vote. Where a two-domain disagreement cannot be resolved between the accountable owners, it is escalated to the Chair for adjudication of process, not of the technical merits, which remain with the domain owners. Approving authority for this plan is the Chief Product Officer and Executive Sponsor, G. Marchetti.

17. Process Improvement & Lessons Learned

Continuous improvement. Lessons are captured at every gate, not only at closeout. The Gate 1 recycle produced the program's most consequential lesson — that a sequencing failure in the assumption chain can pass every individual check while producing a wrong answer — and that lesson is embedded as a control: assumptions are now cross-checked between the artifacts that depend on them. The post-launch review (Gate 5) is the formal lessons-learned gate and is included in this program's scope as a template even though it is forward-dated.

18. Assumptions, Constraints & Dependencies

Assumptions. The business case rests on stated assumptions including a 9.25% illustrated cap rate (versus a 9.00% peer level and an 8.50% floor fixed at Gate 1), a 62% rider election rate, and a capital strain of 4.2%. Each assumption is documented with the method that would reveal it wrong.

Constraints. The binding constraint is the fixed launch date of 06 Mar 2028. Regulatory constraints (state filing, contract-form approval) and capital constraints (the 11.0% hurdle rate) are the other hard boundaries.

Dependencies. The critical external dependency is ISDA execution with hedging counterparties (DEP-06), which underlies the at-risk hedging-readiness condition. The independent actuarial peer review is a dependency of the Gate 2 decision. Dependencies are carried in the RAIDD register with named owners.

19. Baselines Summary

These baselines are the reference for all variance reporting. They are re-baselined only by a Board decision at a gate, and the prior baseline is retained as superseded.

20. Appendices

This plan is supported by the program's controlled artifacts, each of which owns its knowledge area in full: the Program Charter (authorization and objectives), the Gate Decision Framework and Governance Model (the gate process), the resource-loaded Work Breakdown Structure (the task-level schedule and resource loading), the RAIDD register (risk, assumptions, issues, dependencies, decisions), the Communications Management Plan, the Requirements Traceability Matrix, the Test & Validation Strategy, the financial model and cost-benefit analysis, and the gate packages themselves. Where this plan summarizes an area, the named artifact is authoritative.

21. Approval

This Project Management Plan is issued by the Program Management Office of Lighthouse Financial Services Company and approved by the Executive Sponsor. Approval signifies acceptance of the management approach defined here as the baseline for the Beacon Index Advantage program.

Baseline issued for the Beacon Index Advantage product development program. Status date 16 October 2026. This document is archived intact at closeout as the program's governance-conformance reference.