Work Breakdown, Deliverables, Estimates and Risks

"How long will it take?"

Every client asks it, and every honest developer finds it hard to answer. The trick is not to guess the whole project at once. You break the work into small pieces, estimate each piece (with a range, not a single number), add them up carefully, and then ask what could go wrong.

This lesson finishes the planning deliverables named in B1.1: the tasks, the deliverables and the information you need for the schedule (which the next lesson draws as Gantt and PERT charts).

The work breakdown structure

A work breakdown structure (WBS) is a tree. The root is the whole product. The next level is the big deliverables or phases. Each of those is split again until every leaf is a work package: a piece of work that one person can own and finish in a few hours to a couple of days.

Two rules make a WBS useful:

• The 100% rule. The leaves together cover all the work, including the unglamorous parts: planning, testing, documentation, installation, training, the final review. If it is not in the WBS, it is not in the schedule, and it will be done at midnight.
• Small enough to estimate. For a student project, a work package should be roughly 1 to 8 hours of effort. A leaf like "write the program" is far too big to estimate honestly.

Numbering (1, 1.1, 1.2, ...) lets you refer to work packages in the schedule, status reports and the Git commit messages you will write later.

Tasks, deliverables and milestones

These three words are easy to mix up:

• A task (work package) is work: "3.2 write the loans module". It takes time and has an owner.
• A deliverable is a thing handed over: the loans module itself, the test report, the user guide. Some deliverables go to the client (the program, the guide); some are internal (the design document).
• A milestone is a moment: "code complete", "scope signed". It has zero duration and marks the end of a group of tasks.

A good plan lists all three, and every deliverable has a task that produces it and a milestone by which it is due.

Estimating with three points

In ICS3U you used PERT to combine three estimates into an expected time:

E = (O + 4M + P) ÷ 6

PERT also gives a measure of uncertainty, the standard deviation:

σ = (P − O) ÷ 6

A wide gap between the optimistic and pessimistic estimates means a big σ: you are not sure. When independent tasks are done one after another, you add their expected times and add their variances (σ²), then take the square root to get the total σ. You add variances, not standard deviations, for the same reason as in MDM4U's probability units: independent ups and downs partly cancel out.

Estimates should be made by the person who will do the work, after looking at similar past work. Two well-known traps: people are usually too optimistic about their own tasks, and they forget work that is not coding (meetings, reviews, fixing tests).

The same calculation as a program. The f-string {name:<20} pads the name to 20 characters on the left, and {e:6.2f} prints the number in 6 spaces with 2 decimals, so the columns line up.

From effort to calendar time

An estimate in person-hours (effort) is not a date. To schedule, convert to duration using how much time people really have.

The LendIt team has about 5 class hours a week on the project, plus about 2 hours each of homework, but some class time goes to meetings and other subjects interrupt. Priya counts 5 productive hours per person per week, so the team has about 4 × 5 = 20 person-hours a week.

The four coding packages total about 27 to 33 hours. Split between two developers working in parallel, that is roughly 14 to 17 hours each, or about 3 weeks at 5 hours a week. One person alone would need about 6 weeks. That is why the work must be split, and why the split must be planned (the next lesson's critical path shows which tasks can run in parallel).

Risks and the risk register

A risk is something that might happen and would hurt the project. (Something that has already happened is an issue.) For each risk, estimate:

• Probability: 1 (unlikely), 2 (possible), 3 (likely).
• Impact: 1 (minor delay), 2 (serious delay or a feature lost), 3 (project fails or data is lost).
• Score = probability × impact, so the biggest risks get attention first.

Then choose a response:

• Avoid: change the plan so the risk cannot happen (check the laptop's Python version in week 1).
• Reduce (mitigate): make it less likely or less harmful (two people know every module; back up data).
• Transfer: make someone else responsible (the centre's IT volunteer handles the laptop).
• Accept: live with it, but watch for its trigger (warning sign).

Every risk gets an owner who watches it.

Sorting a risk register by score is a one-line job in Python. The key=score argument tells sorted to compare risks by their scores. Python's sort is stable: risks with equal scores stay in their original order.