---
{
  "title": "Project lifecycles",
  "summary": "Move a defined improvement from purpose through delivery and review.",
  "topic": "delivery",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    1
  ],
  "aliases": [],
  "sources": [
    {
      "title": "UK Government: Project Delivery Functional Standard",
      "url": "https://www.gov.uk/government/publications/project-delivery-functional-standard"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

A project is a temporary effort intended to deliver a defined outcome. A lifecycle provides stages such as initiation, planning, execution, monitoring, and closure, though methods organize them differently. Security projects need business ownership, measurable outcomes, resources, and acceptance criteria. Operations continue after the project ends, so delivery must include the handover of responsibilities and ongoing controls.

## In practice

A project introduces stronger authentication, then hands enrollment, recovery, monitoring, and support to operational owners.

## A common misunderstanding

Installing a tool is not necessarily the project outcome. The intended reduction in risk or improvement in service should be demonstrated.

## Check your understanding

What distinguishes a project from operations?

**Think it through:** A project has a defined temporary change objective; operations sustain the resulting service or process.


## Stages answer different questions

Early lifecycle work asks whether the proposed change is worth doing and who can authorize it. Planning asks what must be delivered and how the team will handle constraints. Delivery produces and validates the result. Closure confirms acceptance and transfers responsibility. These activities may overlap or repeat; a lifecycle is a way to organize decisions, not evidence that every project should follow the same rigid sequence.

Security introduces recurring questions across those stages. Which service or information is being protected? Who owns its risk? What operational burden will the change create? How will the team know it worked? Asking these only at the end makes fundamental problems expensive to fix. A well-placed review can stop an unsuitable approach before more resources are committed.

## Follow a fictional identity improvement

An academy begins with a problem: departing staff retain access too long. Initiation establishes the affected systems and sponsor. Planning maps the departure notification, account changes, verification, and exception route. A pilot tests the workflow with fictional accounts before implementation expands to real operational use.

At closure, the team does not merely archive its task board. Human resources and IT agree who initiates and completes each departure action, what evidence is retained, and how missed notifications are escalated. A later review checks whether the expected improvement is sustained. This connects the temporary project to the continuing service.

## Locate the decision

For a fictional security awareness rollout, write one decision needed before funding, one before broad release, and one before handover. Identify the evidence required for each. Then explain what would justify returning to an earlier design assumption. The exercise demonstrates that structured stages can support learning rather than require the team to ignore new information.

## Keep exploring

- [[project-charter]]
- [[project-governance]]
- [[project-closure]]