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

Project Management Fundamentals

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.