---
{
  "title": "Project planning",
  "summary": "Connect the intended outcome to work, resources, dependencies, and evidence.",
  "topic": "delivery",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    3
  ],
  "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

Project planning defines what must be delivered, who will do it, how work relates, and how success will be accepted. Include scope, schedule, resources, cost, risks, communication, and handover. Estimates should state assumptions and uncertainty. Plans change as evidence develops, but changes need to be visible and owned. Security requirements belong in the plan rather than being added only before release.

## In practice

An authentication upgrade plans enrollment, testing, support training, fallback handling, staged deployment, and acceptance by service owners.

## A common misunderstanding

A schedule containing only installation tasks may miss the work needed to make an improvement usable and sustainable.

## Check your understanding

What should an estimate reveal?

**Think it through:** Its assumptions, dependencies, level of confidence, and what information could change it.


## Connect the pieces before choosing dates

Planning starts with the result people need, then identifies the deliverables that make that result possible. A security monitoring project might require selected log sources, access approval, retention settings, detection rules, an escalation process, and staff training. A schedule containing only tool installation conceals most of the effort. Map relationships among these deliverables before assigning deadlines.

Estimates should state what they assume. Integrating an existing supported connector differs from developing a custom one, and obtaining a test account may take longer than writing a configuration. Include availability of people with scarce expertise. Allocating the same engineer to three simultaneous tasks does not create three engineers. Planning also needs a route for revising assumptions as learning occurs.

## A fictional monitoring rollout

An academy wants to monitor administrator sign-ins before its next enrollment period. The initial plan says to enable a dashboard in one week. During planning, the team discovers that access approval, identity log retention, and an out-of-hours contact are unresolved. It creates a small pilot with one identity system and defines which alerts someone will actually investigate.

This narrower first step gives the team usable feedback while keeping the intended outcome visible. A later expansion can build on the working handoff instead of reproducing an untested configuration across every service. Document why the sequencing changed so stakeholders can distinguish sensible adaptation from unexplained delay.

## Test the plan on paper

Select a fictional password-manager rollout and list five deliverables. For each, identify an owner, an input it needs, and an observable completion condition. Then remove the person responsible for procurement for one week. Explain which work can continue and which decision must move. A useful plan helps answer that question without pretending uncertainty has disappeared.

## Keep exploring

- [[work-breakdown-structure]]
- [[project-dependencies]]
- [[project-budgeting]]