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

Project Management Fundamentals

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.