Every technical career involves projects: a software release, a site build, a lab study, a training rollout. This beginner course teaches the core tools project managers use, in plain language and with one running example. You will learn the project lifecycle, write a scope statement with clear exclusions and map stakeholders; break work into a work breakdown structure, find the critical path of a schedule and make three-point estimates and a simple budget; and run the project with a risk register, RAG status reports and a lessons-learned review at closure. Each lesson has a short reading, curated videos and a practical task you can do on paper or in a free spreadsheet. It is a first step towards agile delivery and certifications such as PMI's CAPM.

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.

What Projects Are

Write the project name at the top (level 1).

Turn each deliverable from your scope statement into a level 2 item. Add Project management and Training/handover if they apply.

Break every level 2 item into level 3 work packages, using nouns for deliverables.

Number every item (1.1, 1.1.1 and so on).

Check the 8/80 rule: give each package a rough hour estimate and split or merge any outside 8 to 80 hours.

Apply the 100% rule: tick each scope deliverable and acceptance criterion against the WBS, and remove anything from the exclusions list.

Write a WBS dictionary entry (description, owner, acceptance, estimate) for your two riskiest packages.

## Why it matters

"Build the website" is impossible to estimate, schedule or assign. "Design the sign-up form", "Write the confirmation email" and "Test the form on three phones" are not. A **work breakdown structure (WBS)** is how you get from the first to the second. It is the backbone of planning: the schedule, the budget, the risk list and the status report all hang off it. If work is not in the WBS, nobody has planned to do it.

## The core idea

A WBS is a **hierarchy of deliverables**. The top level is the whole project. Each level below splits its parent into smaller pieces, until you reach **work packages**: chunks of work small enough to estimate with reasonable confidence and assign to one owner.

Three rules make a WBS useful:

1. **Deliverable-oriented.** Organise by the things you produce (nouns), not by departments or phases. "Sign-up form" rather than "development". Activities (verbs) come later, inside work packages.
2. **The 100% rule.** Each level must contain 100% of the work of its parent, no more and no less. If testing, training or project management itself is missing, the WBS is incomplete, and those hours will appear as overruns.
3. **Mutually exclusive.** No piece of work appears twice. If "test the form" sits under both "Sign-up form" and "Testing", it will be counted twice in the budget.

How small is small enough? A common rule of thumb is the **8/80 rule**: a work package should take between about 8 and 80 hours of effort. Another is that it fits within one reporting period, so you can say "done" or "not done" at each status check.

## A worked example

The food bank sign-up website, broken down to three levels:

```text
1 Volunteer sign-up website
  1.1 Project management
      1.1.1 Planning documents (scope, schedule, risks)
      1.1.2 Weekly status reports
      1.1.3 Closure and lessons learned
  1.2 Requirements and design
      1.2.1 Requirements notes (coordinator, 5 volunteers)
      1.2.2 Wireframes for 4 pages
      1.2.3 Visual design and style guide
  1.3 Public site
      1.3.1 Home and contact pages
      1.3.2 Shift calendar
      1.3.3 Sign-up form with validation
      1.3.4 Confirmation email
  1.4 Coordinator admin
      1.4.1 Add and edit shifts
      1.4.2 CSV export of sign-ups
  1.5 Testing and launch
      1.5.1 Test plan and test runs on 3 phones
      1.5.2 Accessibility check
      1.5.3 Go-live on the existing host
  1.6 Training and handover
      1.6.1 Coordinator guide (2 pages)
      1.6.2 60-minute training session
      1.6.3 Handover notes for the IT volunteer
```

Notice that project management, testing, training and handover each have their own branch. These are exactly the items beginners leave out.

The numbering (1.3.3) gives every package a unique ID you can use in the schedule, budget and status reports.

## The WBS dictionary

For each work package, a short **WBS dictionary** entry removes ambiguity:

```text
1.3.3 Sign-up form with validation
  Description: form for name, email, phone, shift; shows errors inline.
  Owner:       Priya
  Acceptance:  passes the test plan cases 4-11; works on 3 phones.
  Estimate:    24 hours
  Depends on:  1.2.2 wireframes, 1.3.2 shift calendar
```

## How to build one

1. Start from the scope statement's deliverables; they become level 2.
2. Break each down by asking "what has to exist for this to be done?"
3. Stop when a piece meets the 8/80 rule or can be estimated and owned.
4. Check the 100% rule: read the scope statement again and confirm every deliverable and acceptance criterion is covered, and nothing extra (from the exclusions) has crept in.
5. Review it with the people who will do the work. They know the hidden tasks.

Sticky notes on a wall work very well for a first draft; a spreadsheet, outline document or free mind-mapping tool works for the final version.

## WBS and agile

Agile teams use a similar structure: **epics** break down into **user stories**, which break down into tasks. The difference is that the lower levels are refined just in time rather than all at the start.

## Common mistakes

- **Organising by department** ("design team", "dev team") instead of deliverables.
- **Missing project management, testing, training or handover.**
- **Going too deep**: packages of 30 minutes create a tracking burden.
- **Listing work that is out of scope.**

## Quick recap

- A WBS breaks the project into deliverables, then into work packages you can estimate and assign.
- Follow the 100% rule and keep pieces mutually exclusive.
- Size work packages at roughly 8 to 80 hours; give each an ID, owner and dictionary entry.

## Try it

Open the **Do** tab and build a three-level WBS for your project on sticky notes or in a spreadsheet.


Decompose a project into deliverables and work packages small enough to estimate, assign and track.

Work breakdown structure

Work Breakdown Structure [WBS EXPLAINED]

Work Breakdown Structure demonstration

## Why it matters

A list of tasks is not a schedule. Some tasks must wait for others; some can happen at the same time. Until you know the order, you cannot say when the project will finish or which delays actually matter. The **critical path method (CPM)** answers both questions, and it is used on everything from software releases to building projects.

## Dependencies

A **dependency** links two tasks. The most common type is **finish-to-start**: task B cannot start until task A finishes. You cannot build the sign-up pages until the screens are designed.

Other types exist (start-to-start, finish-to-finish), but finish-to-start covers most beginner plans. Dependencies come from:

- **Logic**: you must design before you build.
- **Resources**: the same person cannot do two things at once.
- **External events**: the food bank must supply photos first.

## The network and the forward pass

Here is the food bank plan in working days:

| ID | Task | Days | After |
|---|---|---|---|
| A | Agree requirements | 3 | (none) |
| B | Design screens | 5 | A |
| C | Set up database | 2 | A |
| D | Build sign-up pages | 6 | B, C |
| E | Write volunteer guide | 2 | B |
| F | Test and launch | 3 | D, E |

The **forward pass** works out the earliest each task can finish. A task can start only when **all** of its predecessors are done, so its earliest start is the **largest** earliest finish among them:

```text
A: start 0,             finish 0 + 3 = 3
B: start A = 3,         finish 3 + 5 = 8
C: start A = 3,         finish 3 + 2 = 5
D: start max(B, C) = 8, finish 8 + 6 = 14
E: start B = 8,         finish 8 + 2 = 10
F: start max(D, E) = 14, finish 14 + 3 = 17
```

The project takes **17 working days**.

## The critical path and float

The **critical path** is the longest chain of dependent tasks through the network. Here it is **A -> B -> D -> F** (3 + 5 + 6 + 3 = 17). Every task on it has **zero float**: if any of them slips by a day, the whole project slips by a day.

Tasks off the critical path have **float** (also called slack): time they can slip without delaying the end.

- **C** finishes on day 5 but D cannot start until day 8 anyway, so C has 3 days of float.
- **E** finishes on day 10 but F starts on day 14, so E has 4 days of float.

A **backward pass** (working from the end date back, subtracting durations to find latest start and finish) calculates float formally. Float = latest start minus earliest start.

Why this matters: if the database setup (C) takes 2 days longer than planned, nothing changes. If design (B) takes 2 days longer, launch moves 2 days. So you watch critical tasks closely and put your strongest people and earliest risk work there.

## Gantt charts

A **Gantt chart** draws the schedule as horizontal bars on a calendar: one row per task, bar length equal to duration, with arrows for dependencies. It is the most common way to share a schedule because anyone can read it. Critical tasks are often coloured differently.

```text
Day        1   3   5   7   9   11  13  15  17
A  Reqs    ===
B  Design     =====
C  DB         ==
D  Build           ======
E  Guide           ==
F  Test                  ===
```

Free tools include spreadsheet templates, GanttProject and many free tiers of online planners. The tool matters much less than correct dependencies.

## Milestones

A **milestone** is a zero-duration marker for a significant event: "Design approved", "Go-live". Sponsors care about milestones more than tasks. Put them on the chart and in status reports.

## Common mistakes

- **Missing dependencies**, so the chart shows tasks overlapping that cannot.
- **Calendar dates typed in by hand** instead of calculated from dependencies, so one change breaks everything.
- **Ignoring resource limits**: two critical tasks assigned to the same person at the same time.
- **Treating the critical path as fixed.** If a non-critical task slips past its float, it becomes critical.

## Quick recap

- Dependencies (mostly finish-to-start) set the order of tasks.
- The forward pass gives each task's earliest finish; a task starts at the latest finish of its predecessors.
- The critical path is the longest chain; its tasks have zero float and set the project length.
- Gantt charts and milestones communicate the schedule.

## Try it

Open the **Do** tab. The code for a forward pass is already written except for one line. Fill it in and the program finds the food bank project's length and critical path. No programming experience needed.


Sequence tasks with dependencies, draw a Gantt chart and find the critical path that sets the project's length.

Schedules and critical path

Use forward and backward pass to determine project duration and critical path

What is a Gantt chart?  ...explained in under 3 minutes

Make a table with columns: WBS ID, work package, owner, O, M, P, PERT estimate, SD.

For each package, write optimistic, most likely and pessimistic effort in hours. If possible, ask the person who would do the work.

Calculate PERT = (O + 4M + P) / 6 and SD = (P - O) / 6 for each row, then total the PERT column.

Compare the PERT total with the total of your M column and note the difference.

Multiply the PERT total by an hourly rate (use a realistic local rate, or USD 20 for practice) to get labour cost.

List non-labour costs: software, hosting, materials, rooms, travel. Use free tools wherever you can and write zero for them.

Add a contingency line and write one sentence explaining which risks it covers and why you chose that amount.

Convert the effort for your longest package into calendar days, assuming 5 productive hours per day.

## Why it matters

Every sponsor asks two questions: "When will it be done?" and "How much will it cost?" Answering with one confident number ("12 days") hides the uncertainty that every estimate has. When reality turns out different, the team looks unreliable. Good estimating is not about predicting perfectly; it is about being honest about the range and planning for it.

## Effort vs duration

- **Effort** is the amount of work, in person-hours or person-days: "the form takes 24 hours of work".
- **Duration** is calendar time: if Priya can spend 4 hours a day on it, 24 hours of effort takes 6 working days.

Mixing these up is a classic mistake. People are rarely 100% available; meetings, other projects and support work take time. Many planners assume 5 to 6 productive hours in an 8-hour day.

## Ways to estimate

- **Expert judgement**: ask the person who will do the work. Usually the best starting point.
- **Analogous**: "the last site like this took 3 weeks." Quick, but only as good as the comparison.
- **Parametric**: use a rate. "Each page takes about 6 hours to build; 4 pages = 24 hours."
- **Bottom-up**: estimate each WBS work package and add them up. Slower, but the most accurate and easiest to defend.

## Three-point estimates

Instead of one number, ask for three:

- **O** (optimistic): if everything goes well.
- **M** (most likely): the realistic case.
- **P** (pessimistic): if things go wrong, but not disastrously.

Then combine them. Two common formulas:

```text
Triangular average:   E = (O + M + P) / 3
PERT (beta) average:  E = (O + 4M + P) / 6
PERT spread:          SD = (P - O) / 6
```

PERT weights the most likely value more heavily. A worked example for the sign-up form:

```text
O = 16 h, M = 24 h, P = 44 h
Triangular:  (16 + 24 + 44) / 3     = 28 h
PERT:        (16 + 4 x 24 + 44) / 6 = 156 / 6 = 26 h
Spread:      (44 - 16) / 6          = about 4.7 h
```

Notice the expected value (26 h) is higher than the most likely value (24 h). That is normal: tasks can overrun by much more than they can come in early, so the average drifts later. A single "most likely" number is too optimistic on average.

## From effort to budget

A simple project budget has:

1. **Labour**: effort per work package times a rate. Even volunteer or internal time has a cost worth tracking.
2. **Non-labour costs**: software, hosting, equipment, materials, travel, training rooms, permits.
3. **Contingency reserve**: money (and time) for **known risks**, the "known unknowns" in the risk register. Often calculated from the risks, or set as a percentage, commonly somewhere around 5 to 15% on small projects depending on uncertainty.
4. **Management reserve**: held by the sponsor for "unknown unknowns". It is usually outside the project manager's control.

A worked example for the food bank site:

```text
Labour   PERT total 150 h x USD 20/h (contractor rate)  = 3,000
Hosting  existing host, domain renewal                  =    20
Testing  2 second-hand phones for testing               =   280
Training room and printing                              =    50
Subtotal                                                = 3,350
Contingency (about 15%, design and photo risks)         =   500
Total project budget                                    = 3,850
```

That fits under the USD 4,000 constraint from the charter, with a small margin. If it had not, the options are the usual trade-offs: cut scope, find cheaper resources, or ask for more money.

## Tracking costs

During the project, compare **planned cost to date** with **actual cost to date** and with how much work is actually done. Spending exactly half the budget means little if only a quarter of the work is finished. More formal techniques such as earned value management build on this idea.

## Common mistakes

- **Estimating for someone else** without asking them.
- **Forgetting overhead**: meetings, reviews, testing, fixes, handover.
- **Padding every task secretly** instead of a visible contingency.
- **Giving a single number** when the range is wide. Say "about 4 weeks, likely between 3.5 and 5."
- **Never re-estimating.** Update estimates as you learn; the early ones are the least accurate.

## Quick recap

- Effort is work hours; duration is calendar time. Account for availability.
- Three-point estimates: optimistic, most likely, pessimistic; PERT uses (O + 4M + P) / 6.
- A budget is labour plus non-labour costs, plus contingency for known risks and a management reserve.

## Try it

Open the **Do** tab and produce three-point estimates and a one-page budget for your WBS.


Make three-point estimates of effort, turn them into a simple budget and add a sensible contingency.

Estimating and budgets

What is Three-Point Estimating? Master This PMP Estimating Technique

How to Create a Project Budget - Project Management Training

Break the work into deliverables and tasks, schedule it and find the critical path, and estimate effort and cost.

Planning

Set up columns: ID, risk statement, likelihood (1-5), impact (1-5), score, owner, response, trigger, status.

Write down, in one line each, what the numbers 1, 3 and 5 mean for impact on your project (in days or money).

Brainstorm at least eight things that could go wrong. Look at your schedule's critical path, your assumptions and your stakeholder map for ideas.

Rewrite each one using the cause, event, effect pattern. Move anything that has already happened to a separate issues list.

Rate likelihood and impact and calculate the score. Sort by score.

For the top five, choose a response strategy and write one concrete action each.

Give every risk a single named owner and an early-warning trigger.

Add at least one opportunity (a positive risk) with its own response.

## Why it matters

Something will go wrong on every project. A key person gets sick, a supplier is late, a test reveals a design flaw. Teams that thought about likely problems in advance handle them calmly with a plan and a budget. Teams that did not lurch from crisis to crisis. A **risk register** is a simple table that makes this thinking visible, shared and owned.

## Risks vs issues

- A **risk** is an uncertain event that **might** happen and would affect the project's objectives. "The food bank might not supply photos on time."
- An **issue** is something that **has** happened and needs action now. "The photos did not arrive."

When a risk happens, it becomes an issue, and you move it to the issue log. Risks can also be positive: an **opportunity** is an uncertain event that would help, such as "a volunteer designer might offer free illustration work".

## Writing a good risk statement

Vague risks ("photos", "technical problems") cannot be managed. Use the **cause, event, effect** pattern:

```text
Because the food bank's photographer is a volunteer with limited time (cause),
the photos may arrive after 15 January (event),
which would delay the visual design and the launch by up to a week (effect).
```

This tells you what to watch (the cause), what to prevent (the event) and why it matters (the effect).

## Likelihood, impact and score

Rate each risk on simple scales, usually 1 to 5:

- **Likelihood**: 1 = rare, 3 = possible, 5 = almost certain.
- **Impact**: 1 = negligible, 3 = noticeable delay or cost, 5 = the project fails to meet its main goal.

Multiply them for a **risk score** (1 to 25). A colour-coded grid of likelihood against impact (a heat map) shows which risks need attention: high scores get active management; low scores are watched. Agree what the numbers mean at the start, in terms of days or money, so different people rate consistently.

## Response strategies

For threats:

- **Avoid**: change the plan so the risk cannot happen (use stock photos with a suitable licence instead of waiting for new ones).
- **Mitigate**: reduce likelihood or impact (ask for photos by 1 December, and design with placeholders so the layout does not wait).
- **Transfer**: shift the impact to someone else, usually through a contract or insurance (a fixed-price contract with the web developer).
- **Accept**: do nothing now, but keep contingency and a fallback plan. Suitable for low scores or when responses cost more than the risk.

For opportunities the matching strategies are exploit, enhance, share and accept.

**Escalate** when a risk is outside the project's authority, for example a funding decision for the whole food bank.

## Owners and triggers

Every risk needs **one owner**: the person who watches it and carries out the response. A risk owned by "the team" is owned by nobody. Add a **trigger**, an early warning sign: "no photos received by 8 January".

## A worked example

| ID | Risk (cause, event, effect) | L | I | Score | Owner | Response | Trigger | Status |
|---|---|---|---|---|---|---|---|---|
| R1 | Volunteer photographer has limited time; photos arrive after 15 Jan; design and launch slip up to 1 week | 3 | 3 | 9 | Sam | Mitigate: request by 1 Dec, design with placeholders; fallback to licensed stock photos | None by 8 Jan | Open |
| R2 | Only one developer knows the host; if unavailable during launch week, go-live is delayed | 2 | 4 | 8 | Priya | Mitigate: pair the second developer on the host setup in week 3 | Leave booked in launch week | Open |
| R3 | Volunteers are not used to online sign-up; adoption is low in the first month | 3 | 4 | 12 | Coordinator | Mitigate: paper fallback for one month, launch email with a 1-minute video | Fewer than 20 sign-ups in week 1 | Open |
| R4 | A volunteer designer offers free illustrations; site looks friendlier | 2 | 2 | 4 | Sam | Accept (opportunity): say yes if offered, within the existing schedule | Offer received | Open |

## Keeping it alive

A register written once and filed is useless. Review it in a short slot at every team meeting: new risks, changed scores, triggers hit, responses done, risks closed. Report the top three in each status report.

Everyone should feel safe adding risks. Thank people for raising them; a risk raised early is far cheaper than an issue found late.

## Common mistakes

- **Vague risks** with no cause or effect.
- **No owner**, or the project manager owns everything.
- **Listing issues as risks**: if it has already happened, it is an issue.
- **Responses that are not real actions** ("monitor closely").
- **Never reviewing it.**

## Quick recap

- A risk might happen; an issue has happened. Risks can be threats or opportunities.
- Write risks as cause, event, effect; rate likelihood and impact; score them.
- Respond with avoid, mitigate, transfer or accept (or escalate); give each risk one owner and a trigger.
- Review the register regularly.

## Try it

Open the **Do** tab and build a risk register for your project.


Write clear risk statements and log them with likelihood, impact, an owner and a planned response.

Risk registers

A Project Manager's Guide to Creating a Risk Register

What is a Risk Register & When To Use It - Project Management Training

Write your RAG definitions first: what Green, Amber and Red mean for schedule and cost, with a number for each.

Decide the overall status and write it with a one-line reason at the very top.

Rate schedule, cost, scope and risks separately with a short note for each.

List what was finished since the last report as outcomes, not activities.

List what is planned for the next reporting period.

Show the top two or three risks or issues from your risk register, each with its response.

Write one decision you need from the sponsor, with options and a date.

Ask someone to read it for 60 seconds, then tell you the status and the decision needed. Fix anything they missed.

## Why it matters

Sponsors and stakeholders cannot watch the work every day. A **status report** is how they find out whether the project is on track and whether they need to act. A good one takes two minutes to read and leads to decisions. A bad one is ten pages of activity lists that nobody reads, or a cheerful "all fine" every week until suddenly it is not.

## What a status report is for

A status report answers four questions for its readers:

1. **Are we on track?** (overall status)
2. **What happened since last time, and what is next?**
3. **What could go wrong, or has gone wrong?** (top risks and issues)
4. **What do you need to do?** (decisions or help needed)

Everything else is optional. Busy sponsors read the top, so put the answer first, just like the plain-language rule from the professional communication course.

## RAG status

**RAG** stands for **Red, Amber, Green**, a traffic-light rating used for the overall project and often for each dimension (schedule, cost, scope, risk). Definitions must be agreed in advance, or everyone means something different. A common set:

- **Green**: on track. Any problems can be handled within the team's plan and contingency.
- **Amber**: at risk. There is a problem the team is working on that threatens a milestone, the budget or scope, but there is a credible recovery plan. The sponsor should be aware.
- **Red**: off track. A milestone, budget or scope target will be missed without a decision or help from outside the team.

Many organisations add numeric thresholds, for example: Amber if the forecast end date slips up to 5 working days or cost forecast exceeds budget by up to 5%; Red beyond that. Use your organisation's definitions if it has them.

Some teams add **Blue** for complete.

## Honesty and watermelons

A **watermelon project** is green on the outside and red on the inside: the report says green while the team knows it is in trouble. It happens because people fear bad news or hope to recover quietly. It is the most damaging status-reporting habit, because by the time the truth appears, the cheap options are gone.

Turning amber early is a sign of good management, not failure. It gives the sponsor time to help. Report the **forecast**, not just the past: "We have done 60% of the work" is history; "At the current rate we will launch on 6 March, not 1 March" is what the sponsor needs.

## A worked example

```text
Food bank volunteer sign-up site: status, week 5 of 8 (7 February)

Overall: AMBER  (was Green)
Forecast launch 6 March vs plan 1 March. Recovery plan below.

            Status  Note
Schedule    Amber   Design approval 4 days late (photos arrived 19 Jan)
Cost        Green   USD 2,100 spent of 3,850; forecast 3,700
Scope       Green   No changes since week 2
Risks       Amber   R3 adoption risk unchanged; R1 photo risk closed as issue

Done since last report
- Shift calendar and sign-up form built and tested on 2 of 3 phones
- Coordinator reviewed the CSV export: approved

Next two weeks
- Admin screen, accessibility check, coordinator guide draft

Top risks and issues
- Issue: design approval late (R1 happened). Recovery: second developer
  starts the admin screen in parallel; saves 3 of the 4 days.
- R3 (score 12): low volunteer adoption. Paper fallback agreed for March.

Decision needed (by 10 February)
- Accept a 6 March launch, OR approve USD 300 of extra contractor
  hours to hold 1 March.
```

Everything a sponsor needs is in the first three lines, and the decision has options and a deadline.

## Format and rhythm

- **Short**: one page or one screen. Link to the details (schedule, risk register) rather than pasting them.
- **Regular**: weekly or every two weeks, on the same day. Predictability builds trust.
- **Consistent**: same headings each time, so readers can compare.
- **Tailored**: the board might get the overall RAG and decision only; the team gets more detail.
- **Delivered with a conversation** when the status is amber or red. Never let a sponsor discover red in an email.

## Common mistakes

- **Activity lists instead of outcomes** ("attended 6 meetings").
- **Undefined colours**, so green means different things to different people.
- **Watermelon reporting.**
- **No forecast**, only what happened.
- **Asking for a decision without options or a date.**

## Quick recap

- Status reports answer: on track? progress and next steps? risks and issues? decisions needed?
- RAG ratings need agreed definitions; amber early is good management.
- Report the forecast, keep it to one page, and send it on a regular rhythm.

## Try it

Open the **Do** tab and write a one-page RAG status report for your project.


Write a short, honest RAG status report that shows progress, risks and the decisions you need.

Status reporting

How to Use RAG Status in Project Status Reports

Write a short timeline of the project: start, key milestones, problems and the finish.

State the blameless rule out loud or at the top of your page: we are improving how we work, not blaming people.

Write at least three notes each for Went well, Did not go well and Puzzles.

Group the notes into themes and pick the top three (vote if you are in a group).

For the most important problem theme, ask "why?" until you reach a root cause you could change, usually 3 to 5 times.

Turn each top theme into an action with an owner and a date. Include at least one action that keeps something that went well.

Write a closure checklist for the project and tick off what was done: acceptance, handover, finances, release, archive, celebration.

Write a half-page summary and save it where you will see it before your next similar project.

## Why it matters

When the product launches, most teams want to move on. But projects that just fade out leave problems behind: deliverables nobody formally accepted, support staff who do not know how the system works, contractor invoices still open, and the same mistakes repeated on the next project. **Closing** turns a launch into a finished project, and a **lessons-learned review** turns experience into improvement.

## The closing checklist

A practical closure list for the food bank site:

1. **Formal acceptance.** The sponsor confirms each deliverable meets its acceptance criteria from the scope statement, in writing (an email is fine for small projects). "A volunteer can sign up on a phone in under 2 minutes: tested with 5 volunteers, average 1 minute 20 seconds."
2. **Handover to operations.** The people who will run and support the result get what they need: access, documentation, a walkthrough, and a named contact. Here, the IT volunteer receives the hosting login (through a password manager, never by email), the handover notes and a one-hour session.
3. **Close contracts and finances.** Pay final invoices, cancel trial accounts and tools you no longer need, return equipment, and record the final cost against the budget.
4. **Release the team.** Tell people and their managers when their time on the project ends. Thank them, and give feedback for their reviews.
5. **Archive.** Store the final scope, schedule, risk register, decisions and lessons learned where future teams can find them.
6. **Celebrate.** Mark the finish. It matters for morale and for the next project.

If a project is cancelled early, close it too. Documenting why it stopped is often the most valuable lesson of all.

## Lessons learned

A **lessons-learned review** (also called a retrospective or post-project review) asks what went well, what did not, and what to do differently. It works only if it leads to changes, and only if people feel safe being honest.

### Make it blameless

The aim is to improve the **system** (processes, tools, communication), not to find someone to blame. Assume everyone did the best they could with what they knew at the time. If people fear blame, they hide the very problems you need to learn from. Agree this explicitly at the start.

### A simple 60-minute format

1. **Set the stage (5 min).** Purpose, the blameless rule, the timeline of the project on a wall or screen.
2. **Gather data (15 min).** Everyone writes sticky notes silently in three columns: **Went well**, **Did not go well**, **Puzzles** (surprises or open questions). Include stakeholders such as the sponsor or support team, or gather their input beforehand with a short survey.
3. **Group and vote (10 min).** Cluster similar notes into themes; each person gets three votes for the themes that matter most.
4. **Dig into the top themes (20 min).** For each, ask why it happened. A short "five whys" chain helps reach a root cause:

```text
Design was 4 days late.
  Why? Photos arrived late.
  Why? The request went out in mid-January.
  Why? Nobody owned asking for content.
  Why? Content was not in the WBS.
Lesson: put "content collection" in the WBS with an owner and a deadline.
```

5. **Actions (10 min).** Turn each top theme into a specific action with an owner and a date: "Add a Content work package to our WBS template (Sam, by 15 April)." A lesson without an action is just a complaint.

### Keep what went well

Successes are lessons too. "Usability testing on paper prototypes caught three problems before build" should become a standard step on the next project.

### Share them

Write a one-page summary: what happened, top lessons, actions. Store it with other projects' lessons, and read the lessons from similar projects when you start a new one. That is the step most organisations skip.

Agile teams run small retrospectives every sprint rather than only at the end, which is why they improve quickly. You can do the same on any project: a 15-minute review at each phase gate or milestone.

## Common mistakes

- **Skipping formal acceptance**, so "finished" is disputed later.
- **Handover by email only**, with no walkthrough.
- **Forgetting to cancel paid tools and trials**, which keep charging.
- **Blame-focused reviews**, so people stay silent.
- **Lessons with no owner or action**, filed and forgotten.

## Quick recap

- Close with formal acceptance, handover, contract and finance closure, team release, archiving and a celebration.
- Run a blameless lessons-learned review: gather, group, find root causes, agree actions with owners.
- Capture what went well too, share the summary, and read past lessons before starting new projects.

## Try it

Open the **Do** tab and run a lessons-learned review on a project you have finished, at school, work or home.


Close a project properly with acceptance and handover, and run a blameless lessons-learned review.

Closing and lessons learned

Lessons Learned Meeting: How to Make it Excellent

Closing the Project [5 STEPS TO PROJECT CLOSURE]

Keep the project on track with a risk register and honest status reports, then close it and capture lessons learned.

Project Management Fundamentals

About this course

Course content

What Projects Are

Planning

Running the Project

Where this course leads

Next course on the path

Careers that use it