Plan and run small projects: scope, stakeholders, work breakdown, schedules, estimates, risks, status reports and closure.

Project Management Fundamentals

## Why it matters

You do not need the job title "project manager" to manage projects. A developer shipping a feature, a civil engineer delivering a culvert replacement, a designer running a website redesign and a trainer rolling out a new course are all running projects. Knowing how projects are structured helps you plan realistically, spot trouble early and talk with the people who fund and approve the work.

Throughout this course we follow one small project: **a team of four building a volunteer sign-up website for a local food bank in eight weeks**.

## What makes work a project

A **project** is a temporary effort to create a unique result. Two words matter:

- **Temporary**: it has a start and an end. The food bank site is done when it launches and is handed over.
- **Unique**: the result has not been made in exactly this way before.

That is different from **operations**, the ongoing, repeated work of running something. Answering volunteer emails every week after launch is operations. Building the site is a project.

Every project balances three main constraints, often drawn as a triangle: **scope** (what you deliver), **time** and **cost**, with **quality** in the middle. Change one and the others feel it. If the food bank asks for a donation page as well, either the deadline moves, more people join, or something else is cut.

## The five phases

The Project Management Institute (PMI) describes work in five process groups. Many organisations use them as phases:

1. **Initiating.** Decide whether the project should happen and authorise it. Typical outputs: a **business case** (why it is worth doing) and a **project charter**, a short document naming the goal, the sponsor, the project manager, high-level scope, budget and deadline. For the food bank: "Replace paper sign-up sheets with a website by 1 March, budget USD 4,000, sponsor: the volunteer coordinator."
2. **Planning.** Work out how. Scope statement, work breakdown, schedule, budget, risk register, communication plan. Most of this course lives here.
3. **Executing.** Do the work: design, build, test, train. This is usually where most of the time and money go.
4. **Monitoring and controlling.** Runs alongside executing. Compare progress with the plan, manage changes, track risks and report status. It is not a separate later phase: you monitor from day one.
5. **Closing.** Get formal acceptance, hand over, release people, close contracts, record lessons learned and archive the files.

A diagram often shows effort rising through executing and falling at closing, while the cost of making changes rises steadily: changing the plan in week one is cheap; changing it the day before launch is expensive.

## Predictive, adaptive and hybrid

Not every project runs the phases once, in a straight line.

- **Predictive** (often called waterfall): plan most of the work up front, then execute. It suits work where requirements are stable and changes are expensive, such as constructing a bridge, where you cannot pour concrete twice.
- **Adaptive** (agile approaches such as Scrum and Kanban): plan a little, build a small working piece, get feedback, repeat. It suits software and design work where requirements change as people see results.
- **Hybrid**: predictive for some parts (a fixed launch date, hardware orders), adaptive for others (the website features). Many real projects are hybrid.

Even agile projects still initiate, plan (in smaller slices), execute, monitor and close. The phases repeat on a smaller scale. The `agile-delivery` course covers this in depth.

## Phase gates

Many organisations add **phase gates** (or stage gates): a review at the end of a phase where a sponsor decides go, no-go or change course. Gates stop a project from drifting into expensive execution without a clear plan.

## Certifications and careers

PMI's **CAPM** (Certified Associate in Project Management) is a common entry-level certification, and the **PMP** (Project Management Professional) requires several years of experience leading projects. Agile certifications such as Professional Scrum Master are also common. Requirements and exam content change, so read them on the official sites (pmi.org, scrum.org). Checked on 2026-10-23.

## Common mistakes

- **Skipping initiation.** Starting work without a sponsor or a written goal leads to arguments about what "done" means.
- **Treating monitoring as the end.** Problems found only at the end are expensive.
- **Never closing.** Projects that fade out instead of closing leave loose ends, unpaid invoices and no lessons learned.

## Quick recap

- A project is temporary and unique; operations are ongoing and repeated.
- Scope, time and cost (with quality) constrain each other.
- Phases: initiating, planning, executing, monitoring and controlling (throughout), closing.
- Predictive, adaptive and hybrid approaches run these phases differently.

## Try it

This lesson is quiz only. Open the **Do** tab to check you can name the phases and what happens in each.


Tell projects from everyday operations and name the phases from initiation to closure.

The project lifecycle

PM 101 Course: The 5 Phases of the Project Lifecycle

Phases of a Project [PROJECT MANAGEMENT LIFE CYCLE EXPLAINED]

Write a one-sentence objective that says what the project achieves and why.

List three to six concrete deliverables someone could hand over.

Give each deliverable at least one testable acceptance criterion (a number, a time or a yes/no test).

List at least four exclusions: things a sponsor might assume are included but are not.

Write the constraints (deadline, budget, tools) and at least two assumptions.

Ask someone to read it and say what they thought would be included. Add any surprise to the deliverables or the exclusions.

Invent one change request and write a three-line impact note (scope, time, cost) as if you were sending it to the sponsor.

## Why it matters

Most project arguments are really arguments about scope. The sponsor thought "website" included a donor portal; the team thought it meant three pages. Writing scope down, including what is **not** included, is the cheapest risk control a project has. It also gives you something to point to when new requests arrive halfway through.

## Requirements vs scope

- **Requirements** describe what the result must do or be, from the point of view of the people who will use it: "Volunteers can sign up for a shift on a phone in under two minutes."
- **Scope** describes the work and deliverables the project will produce to meet those requirements, and the boundaries: what is in, what is out.

Good requirements are specific and testable. "The site should be fast" is not testable. "Pages load in under three seconds on a typical phone connection" is.

To gather requirements, talk to the people affected (interviews, short workshops), watch how the current process works (the paper sign-up sheets), and look at existing documents. Write them down in the users' words, then confirm them back.

## The scope statement

A **scope statement** is a one- or two-page document, agreed with the sponsor during planning. A practical structure:

1. **Objective**: one sentence on what the project achieves and why.
2. **Deliverables**: the concrete things handed over.
3. **Acceptance criteria**: how the sponsor will decide each deliverable is done.
4. **Exclusions** (out of scope): things people might assume are included, but are not.
5. **Constraints**: fixed limits such as deadline, budget, technology or regulations.
6. **Assumptions**: things believed true but not confirmed. If one turns out false, scope may need to change.

## A worked example

```text
Objective
  Replace paper volunteer sign-up sheets with a mobile-friendly website
  by 1 March, so the coordinator spends less time on phone calls.

Deliverables
  1. Public site: home, shift calendar, sign-up form, contact page.
  2. Coordinator admin screen to add shifts and export sign-ups to CSV.
  3. Email confirmation to volunteers after sign-up.
  4. A 2-page coordinator guide and one 60-minute training session.

Acceptance criteria
  - A volunteer can sign up for a shift on a phone in under 2 minutes
    (tested with 5 volunteers).
  - The coordinator can add a week of shifts in under 10 minutes.
  - Pages meet WCAG 2.2 AA colour contrast.

Exclusions
  - Online donations or payments.
  - A mobile app (the site works in phone browsers).
  - Migrating old paper records.
  - Support after 31 March (handled by the food bank's IT volunteer).

Constraints
  Budget USD 4,000; launch by 1 March; must use the existing web host.

Assumptions
  The food bank provides logo, photos and shift times by 15 January.
```

The exclusions list is the most valuable part. "Online donations" is there because someone will ask for it.

## Scope creep and change control

**Scope creep** is uncontrolled growth in scope: small additions, each reasonable, that together break the schedule or budget. "Could it also send SMS reminders?" "Can volunteers pick a T-shirt size?" Creep often comes from good intentions, including the team's own "gold plating" (adding unrequested extras).

The answer is not to refuse every change. Projects learn things, and some changes are worth it. The answer is **change control**:

1. Write the request down (a short change request).
2. Assess the impact on scope, time, cost, quality and risk.
3. The sponsor (or a change board, on larger projects) decides: approve, reject or defer to a later phase.
4. If approved, update the scope statement, schedule and budget, and tell everyone.

For example, SMS reminders might add three days and a monthly messaging fee. The sponsor can then make an informed choice instead of the team silently absorbing it.

In agile projects, the same idea shows up as a prioritised backlog: new ideas go into the backlog, and the product owner decides what is worth doing next, within the fixed time and budget.

## Common mistakes

- **No exclusions**, so every assumption becomes an argument.
- **Untestable acceptance criteria** such as "user-friendly".
- **Saying yes in the hallway**: agreeing to changes informally without assessing impact.
- **Scope written by the team alone**, without the sponsor's sign-off.

## Quick recap

- Requirements say what the result must do; scope says what the project will deliver and where the boundaries are.
- A scope statement has an objective, deliverables, acceptance criteria, exclusions, constraints and assumptions.
- Scope creep is uncontrolled change; change control makes every change a visible decision.

## Try it

Open the **Do** tab and write a scope statement, with at least four exclusions, for a small project of your own.


Write a scope statement with deliverables, acceptance criteria and explicit exclusions, and control scope creep.

Scope and requirements

Project Scope Statement [IN 4 EASY STEPS]

How to Prevent Scope Creep

Brainstorm every person or group who can affect or is affected by the project. Aim for at least eight. Include people who will maintain or support the result afterwards.

Draw a 2 by 2 grid with power on the vertical axis and interest on the horizontal axis.

Place each stakeholder on the grid. Write one sentence for each explaining your placement.

For each stakeholder in the high-power quadrants, write what they need from the project and their current attitude (supportive, neutral or resistant).

Pick a communication method and frequency for every stakeholder based on their quadrant.

Mark two stakeholders whose position is likely to change during the project and note when.

Show the map to someone else involved, or a friend, and ask who is missing. Add them.

## Why it matters

Projects rarely fail because of technology alone. They fail because the person who could block the launch was never consulted, the users were not asked what they needed, or a key approver heard about the project for the first time a week before go-live. **Stakeholder management** is the habit of finding everyone who matters and keeping each of them involved in the right way.

## Who is a stakeholder?

A **stakeholder** is any person or group who can affect the project, is affected by it, or believes they are. That last part matters: someone who feels affected will act like a stakeholder whether you listed them or not.

Common stakeholders:

- **Sponsor**: funds and champions the project, makes the big decisions.
- **Project team**: the people doing the work.
- **Users and customers**: the people who will use the result.
- **Managers of the people involved**: they control team members' time.
- **Approvers and specialists**: security, legal, finance, accessibility, building inspectors, IT.
- **Suppliers and contractors**.
- **People affected indirectly**: neighbours of a construction site, a support team that will get new questions.

For the food bank sign-up site: the volunteer coordinator (sponsor), the board (approves the budget), volunteers (users), the warehouse lead (needs the shift lists), the food bank's IT volunteer (will maintain the site afterwards), the web host, and the four-person project team.

## The power/interest grid

A simple, widely used tool is a 2 by 2 grid. Rate each stakeholder's **power** (ability to influence the project: budget, approvals, the ability to block) and **interest** (how much they care or are affected). Each quadrant suggests a strategy:

```text
                 low interest          high interest
high power   KEEP SATISFIED         MANAGE CLOSELY
             (brief, regular,       (involve in decisions,
              no surprises)          frequent contact)
low power    MONITOR                KEEP INFORMED
             (light touch,          (regular updates,
              watch for change)      ask for input)
```

Placing the food bank stakeholders:

| Stakeholder | Power | Interest | Quadrant | Plan |
|---|---|---|---|---|
| Volunteer coordinator | High | High | Manage closely | Weekly check-in, approves scope |
| Board | High | Low | Keep satisfied | Monthly two-line update, sign-off at launch |
| Volunteers | Low | High | Keep informed | Survey, usability test, launch email |
| Warehouse lead | Low | High | Keep informed | Review the export format |
| IT volunteer | Medium | Medium | Keep satisfied/informed | Review hosting plan early |
| Web host | Low | Low | Monitor | Check terms before launch |

Positions change. The IT volunteer has low interest at first, but becomes high interest near handover, when they inherit the site. Review the map at each phase.

## Beyond the grid

For each important stakeholder, also note:

- **What they need from the project** (the coordinator: fewer phone calls; volunteers: quick sign-up on a phone).
- **Their current attitude**: supportive, neutral or resistant, and what would move them.
- **How they prefer to communicate**: email, a quick call, a dashboard, a printed one-pager.

Teams often combine these into a **stakeholder register**, a simple table with name, role, power, interest, needs, attitude, owner on the team and communication plan.

## Engaging stakeholders

- **Involve early.** People support what they helped shape. Ask volunteers to test a paper prototype before anything is built.
- **No surprises for high-power stakeholders.** Bad news delivered early is a conversation; bad news delivered late is a crisis.
- **Tailor the message.** The board wants cost and risk in two lines; the warehouse lead wants to see the actual export file.
- **Listen to resistance.** A resistant stakeholder often knows about a real problem. The warehouse lead may point out that shifts must be split by loading dock.

Be careful with stakeholder information: maps can contain frank notes about people, so store them in team-only spaces and write them professionally.

## Common mistakes

- **Forgetting the people who maintain or support the result** after the project ends.
- **Treating users as low priority** because they have little formal power.
- **Mapping once and never updating.**
- **Communicating the same way with everyone.**

## Quick recap

- A stakeholder can affect, is affected by, or believes they are affected by the project.
- The power/interest grid gives four strategies: manage closely, keep satisfied, keep informed, monitor.
- Record needs, attitudes and preferred communication, and review the map every phase.

## Try it

Open the **Do** tab and build a stakeholder map and engagement plan for your project.


Identify everyone affected by a project and map them by power and interest to plan how to engage each one.

Stakeholders

Stakeholder Mapping | 60 Second Business

Stakeholder Analysis: How to Use the Power/Interest Grid

What makes work a project, the phases every project passes through, and how to pin down scope and the people involved.