System life cycle and project management plan

System life cycle and project management plan

PL-01 — Business or mission need

The sponsor records the problem or opportunity the system is intended to address, the desired outcomes and the reasons for undertaking the work. The record identifies the people and organisations expected to benefit, affected stakeholders, constraints, assumptions and the basis for judging whether investment remains justified. Options include changes to existing systems, acquisition, new development and changes to working practices. The decision to proceed identifies the selected approach and the authority committing resources.

The system owner maintains this justification as circumstances change. Benefits and protection needs are carried into requirements and acceptance arrangements. A successful technical demonstration is not by itself evidence that the business need has been met. At [review events], the sponsor considers current costs, expected benefits, risks and alternatives, and records whether to continue, redirect, suspend or close the work.

PL-02 — Life-cycle model

The delivery coordinator records the life-cycle model used for [system]. The plan identifies the stages through which the system will pass, their intended outputs, decision points and continuing activities. Requirements, risk management, stakeholder engagement, configuration management and assurance operate throughout the stages. Iteration is planned explicitly: feedback from testing, operation or stakeholder review can reopen earlier decisions through the change procedure.

The planning basis is a systems life cycle aligned in subject matter with ISO/IEC/IEEE 15288:2015 and the systems security engineering approach in NIST SP 800-160 Vol. 1 Rev. 1. Processes are organised around the work needed; they are not treated as a requirement to run a separate meeting or create a separate department for every process. Where an existing organisational procedure performs the work, the plan identifies it and its records.

PL-03 — Work and resources

The coordinator identifies the work products required by adopted commitments and decomposes the work sufficiently to assign ownership, estimate resources and manage dependencies. Each planned activity identifies its input, output, responsible role and completion evidence. The plan includes security engineering, privacy assessment, supply-chain work, testing, operator preparation, documentation and assurance, as well as implementation.

Estimates record their basis and significant uncertainty. Resource planning includes people, facilities, tools, supplier services and access to representative test conditions. Where an activity depends on specialist competence or an external service, the coordinator confirms availability before relying on the planned date. Changes in capacity are reflected in delivery and risk decisions rather than left as unexplained overdue tasks.

PL-04 — Agreements and interfaces

The coordinator identifies agreements between the acquirer and supplier, including internal delivery teams where responsibilities cross organisational boundaries. Agreements define expected outputs, acceptance arrangements, information exchange, change handling and the responsibilities retained by each party. Interface responsibilities identify who maintains each side of an interface, how compatible versions are identified and how interface changes are coordinated.

The plan records dependencies on shared infrastructure, external services, operational teams and supplier roadmaps. Dependencies include identity, monitoring, recovery, data quality and support, not only software packages. Where a dependency cannot be controlled directly, the owner records the assumptions, monitoring arrangement and contingency. Unconfirmed supplier dates are marked as assumptions rather than committed milestones.

PL-05 — Decision points and reviews

For each planned decision, the coordinator records the decision authority, information required, participating stakeholders and the possible outcomes. Review criteria connect to the applicable requirements and policy promises. Review evidence may include a requirements baseline, architecture analysis, threat assessment, test results, supplier evidence, operational readiness and an updated assurance argument.

Decisions may authorise continued work with stated conditions where the authority has that discretion. Conditions identify their owners, deadlines and effect on subsequent decisions. A review that has not occurred remains outstanding. Attendance at a meeting does not substitute for recording the decision. Repeated or automated delivery can use standing decisions whose scope, conditions and verification are explicitly documented.

PL-06 — Assessment and control of progress

At [schedule], the coordinator compares actual progress with planned work, resources, quality and risk. Reporting distinguishes completed work products from activities merely started. Changes to requirements, defects, stakeholder issues and supplier events are considered when forecasting completion. The owner records the evidence supporting the forecast and identifies unresolved decisions that affect it.

Corrective actions address the cause of a deviation and identify a responsible person and review date. Replanning records the previous baseline, changed assumptions and approving authority. Scope reduction identifies which stakeholder needs and policy commitments are affected. A revised plan does not erase the fact that a previous promise or milestone was missed.

PL-07 — Knowledge, quality and closure

The engineering lead maintains the technical knowledge required to sustain the system, including architecture decisions, interface definitions, operating instructions and known limitations. The programme owner identifies reusable organisational knowledge and updates shared procedures when lessons apply beyond one project. Quality reviews assess whether both the work products and the methods used meet the adopted expectations.

Project closure confirms deliverables accepted, outstanding work transferred, resources released and records placed with their continuing custodians. System operation may continue after a development project closes; the operations owner explicitly accepts the continuing responsibilities. The closure decision identifies unresolved risks and obligations, with named owners and schedules, so they do not disappear when the project team disbands.