Grade by Grade
B. Software Development · Software Development: Managing a Team Software Project

Project Review and Reflection: Plan versus Actual

B1.6 B2.3About 75 minutes
Learning goals
  • I can review a project by comparing the plan with what actually happened: schedule, effort, scope and quality.
  • I can identify successes and problems, find root causes, and make specific recommendations.
  • I can write a project review report in an appropriate format.
  • I can run a blameless team retrospective.
  • I can assess my own and my team's progress fairly, using evidence, and write a reflection that leads to action.

Words to know

project review (post-mortem)
A meeting and report at the end of a project that compares the plan with what happened and records lessons for the future.
variance
The difference between planned and actual, such as a milestone 5 working days late or 31 hours over the effort estimate.
root cause
The underlying reason a problem happened, found by asking "why?" repeatedly instead of stopping at the first answer.
retrospective
A regular team meeting (after each sprint and at the end) about how the team worked and what to change.
blameless review
A review that looks for causes in the process and situation rather than blaming individuals, so people can speak honestly.
self-assessment
Judging your own work against agreed criteria, with evidence.
peer assessment
Team members assessing each other's contributions against agreed criteria, with evidence.
reflection
Thinking in writing about an experience: what happened, why it mattered, and what you will do differently.

Projects end; lessons should not

LendIt is delivered and signed off. It would be easy to stop here. But the team has just spent six weeks running an experiment in how to build software, and the results are valuable: which estimates were wrong and why, which practices saved them, which habits cost them. Professional teams capture these lessons in a project review, so the next project goes better.

The curriculum asks you to review the management of the project (e.g., compare plan to actual performance, outline successes, make recommendations for improvement) and prepare a report in an appropriate format (B1.6), and to reflect on, and assess, team and individual progress during the project review (B2.3).

Step 1: Compare the plan with what happened

Use numbers from the documents you kept: the baseline schedule and estimates, the status reports, time logs, burndown charts, test reports and the change log. Compare four things:

  • Schedule: planned and actual date of each milestone (variance in working days).
  • Effort: planned and actual hours, overall and for the biggest tasks.
  • Scope: requirements planned, delivered, deferred, added.
  • Quality: bugs found at each stage, bugs that reached the client, tests written.
from datetime import date, timedelta
def workdays_between(a, b):
"""Count working days from date a to date b (negative if b is earlier)."""
step = 1 if b >= a else -1
d, n = a, 0
while d != b:
d += timedelta(days=step)
if d.weekday() < 5:
n += step
return n
milestones = [("Scope signed", date(2026, 11, 5), date(2026, 11, 5)),
("Design approved", date(2026, 11, 10), date(2026, 11, 10)),
("Code complete", date(2026, 11, 18), date(2026, 11, 25)),
("Accepted", date(2026, 11, 25), date(2026, 12, 3)),
("Review report", date(2026, 11, 26), date(2026, 12, 10))]
for name, planned, actual in milestones:
slip = workdays_between(planned, actual)
print(f"{name:<16}{planned:%b %d} -> {actual:%b %d} slip {slip:+d} days")
planned_hours, actual_hours = 110, 141
change = (actual_hours - planned_hours) / planned_hours
print(f"Effort: {planned_hours} h planned, {actual_hours} h actual ({change:+.0%})")

Output: one line per milestone, from Scope signed Nov 05 -> Nov 05 slip +0 days to Review report Nov 26 -> Dec 10 slip +10 days, then Effort: 110 h planned, 141 h actual (+28%). The format {slip:+d} always shows the sign.

Nov 02Nov 09Nov 16Nov 23Nov 30Dec 07deadline Dec 11Scope signedDesign approvedCode complete+5 daysAccepted+6 daysReview report+10 daysbaseline (planned)actual
LendIt's milestones: baseline (outlined) against actual (highlighted). Planning and design were on time; the slip began during coding and grew to 10 working days, which still fitted inside the buffer before the December 11 deadline.
Worked example

Example 1: Reading the variances

Use the variance output and the project documents to describe LendIt's performance against plan, and decide where the slip came from.

  1. Schedule: the first two milestones were on time, so planning and design estimates were good. The slip appears at code complete (+5 days) and stays roughly the same afterwards (+6 at acceptance), so the delay came from the development stage, not from testing or delivery.
  2. The review report was +10 days, but that milestone was deliberately moved to after sign-off; it is not a further slip in the work.
  3. Effort: +28% overall. The time logs show most of the overrun in the loans module (planned about 9 hours, actual about 14.5) and in bug fixing after integration began.
  4. Scope: all Musts and Shoulds delivered; two Coulds deferred by agreement. Scope was managed, not lost.
  5. Buffer: 11 working days planned, 10 used. The plan worked because it had a buffer, but there was almost none left.

Good planning and design estimates; development underestimated by about a quarter; the buffer and scope management absorbed it. The key lesson concerns estimating coding work, not testing or delivery.

Step 2: Successes, problems and root causes

List what went well (so you keep doing it) and what went badly (so you fix it). For each problem, find the root cause by asking "why?" several times. Stopping at the first answer usually blames a person; going deeper finds a process you can change.

Problem: code complete was 5 days late.

  1. Why? The loans module took much longer than estimated (about 14.5 hours against an expected 9).
  2. Why? The date and fine calculations were harder than anyone expected, and nobody had written them before.
  3. Why? The difficulty was discovered only in week 2, when coding started.
  4. Why? The risk register listed "loans module underestimated", but the plan had no early action to test that risk; the wide three-point range (6 to 16 hours) was noted and then ignored.

Root cause: a known, high-uncertainty task was planned like a routine one. Recommendation: for any task with a wide estimate range, run a short experiment (called a spike) in week 1 and re-estimate from what you learn.

Recommendations must be specific and actionable: "run integration tests from sprint 1" can be done; "communicate better" cannot.

Step 3: The team retrospective

Before writing the report, the team meets for a retrospective. Its golden rule is to be blameless: assume everyone did the best they could with what they knew at the time, and look for causes in the process. People only describe their mistakes honestly if they will not be punished for it.

A simple format is Start, Stop, Continue: each person writes sticky notes for practices the team should start, stop and continue. The team groups similar notes, discusses the biggest ones, and agrees on two or three changes.

Startmerge branches within 2 daysintegration tests in sprint 1a spike for risky tasksStopsilent rule changes (LOAN_DAYS!)branches open for a week"80% done" in stand-upsContinuetest-first for rulesFriday demos to Denisechange log for every requestEach item is about how the team works, not about who is to blame.
LendIt's final retrospective board. Every note names a practice, and the team can check next time whether it changed.

Step 4: Write the review report

The review report is written for the client and the teacher (or, in industry, management and future teams). An appropriate format is short, structured and backed by evidence:

  1. Summary: the outcome in three or four sentences.
  2. Plan versus actual: schedule, effort, scope and quality, with a table or chart.
  3. Successes.
  4. Problems and root causes.
  5. Recommendations for future projects.
  6. Appendices: the evidence (variance tables, burndown charts, test summary, change log, reflections).

Model: LendIt's project review report

LendIt Project Review Report · Prepared by the LendIt team for Denise Tremblay and the teacher · Thursday, December 10, 2026

1. Summary. LendIt 1.0.0 was delivered and accepted on December 3, one day before sign-off on December 4 and within the December 11 deadline. All Must and Should requirements were met. The project used 141 hours against 110 planned (+28%), and 10 of the 11 days of schedule buffer.

2. Plan versus actual. Milestones: see the variance table (planning and design on time; code complete 5 working days late; acceptance 6 days late). Scope: 8/8 Must, 3/3 Should delivered; 2 Coulds deferred by agreement; 1 change request (skate sizes) deferred to version 1.1. Quality: 24 bugs found (14 by unit tests, 3 by integration tests, 4 in system testing, 1 in acceptance, 2 minor ones reported after release); 0 serious bugs open, and the 2 minor ones are scheduled for version 1.0.1.

3. Successes. Automated tests caught the off-by-one in the 3-item limit and the member-number type bug before the client saw them. Friday demos kept Denise informed; no surprises at acceptance. The change log stopped scope creep.

4. Problems and causes. The loans module took about 60% longer than its expected estimate: the risk was on the register, but the team planned with the expected value and found the hard part (date calculations) only in week 2. Integration started late (week 3), so the seam bug appeared late. Two days lost to illness (risk K1) were absorbed only because work was in the shared repository.

5. Recommendations. Run a one-day spike early on any task with a wide estimate range; run integration tests from the first sprint; merge branches within two days; keep the change log and Friday demos; book client time in week 1.

Appendices: variance table, burndown charts, test summary, change log, team reflections.

Step 5: Assess team and individual progress

B2.3 asks you to reflect on, and assess, both the team's progress and your own. Fair assessment uses criteria agreed at the start (from the team charter: contribution, reliability, communication, quality, teamwork) and evidence:

  • the task board and Git history (what each person finished and reviewed; git shortlog -sn counts commits per author, but commit counts alone are a poor measure: one careful commit can be worth ten tiny ones);
  • time logs and status reports (who met their deadlines, who warned early);
  • code reviews (quality of work given and received).

Self-assessment and peer assessment work best together. Where your view of yourself differs a lot from your teammates' view, that is the most useful thing to talk about, calmly and with evidence.

criteria = ["Contribution", "Reliability", "Communication", "Quality", "Teamwork"]
self_scores = [4, 4, 4, 4, 4] # Jordan rates himself (1 to 4)
peer_scores = [[4, 2, 3, 4, 4], # Priya
[3, 2, 4, 4, 3], # Amara
[4, 3, 3, 4, 4]] # Luc
for i, c in enumerate(criteria):
peers = sum(p[i] for p in peer_scores) / len(peer_scores)
gap = self_scores[i] - peers
note = " <- discuss with evidence" if abs(gap) >= 1 else ""
print(f"{c:<14} self {self_scores[i]} peers {peers:.1f}{note}")

Output: one line per criterion. Only Reliability is flagged: Jordan rated himself 4, but his teammates averaged 2.3, a gap of more than 1.

Worked example

Example 2: Turning a gap into a reflection

Jordan sees the Reliability gap and feels it is unfair: he worked harder than anyone. Using evidence and the What? So what? Now what? model, write his reflection.

  1. Look at the evidence, not the feeling. His time log shows the most hours on the team (about 46). The board shows the loans module finished 5 days after its planned date, and the status reports show he told Priya about the delay on the day it was due, not when he first suspected it.
  2. What? "I worked the most hours, but my main task finished 5 days late, and I reported the delay late."
  3. So what? "My teammates rated reliability on whether they could plan around me, not on effort. Because I warned late, Luc and Amara had to rearrange their work at the last minute. My estimation ratio was about 1.4, and I didn't use it in my estimates."
  4. Now what? "Next project I will (1) try out any unfamiliar part of my task in week 1 and re-estimate, (2) tell the PM as soon as a task looks more than a day late, and (3) check my ratio every Friday."
  5. He also notes, fairly, his strengths: the loans module had the most tests and no bugs after release.

A reflection that accepts the evidence, explains the gap, keeps the strengths, and ends with three specific actions. Effort and reliability are different things, and both matter to a team.

What?what happened(evidence)So what?why it mattered,what I learnedNow what?what I will dodifferentlynext project, next sprint
The What? So what? Now what? reflection model. A reflection that stops at "What?" is only a diary; the "Now what?" turns it into improvement.
Just for fun

One popular retrospective format draws the project as a sailboat: the wind is whatever pushed the team forward, anchors are whatever held it back, and rocks are the risks ahead. A team whose drawing has more anchors than wind already knows what its first retrospective item is.

Hands-on activity

Project step 14: Review your project and reflect

You need: all your project documents (baseline, status reports, time logs, burndown charts, test reports, change log), sticky notes, your teammates (if any) and your client.

  1. Variance table: list your milestones with planned and actual dates; run the variance program with your dates. Add planned and actual total hours.
  2. Scope and quality: count requirements delivered, deferred and added; count bugs found at each stage.
  3. Retrospective: hold a 30-minute Start, Stop, Continue session (alone: write the notes yourself, one hat at a time). Agree on three changes.
  4. Root causes: pick your two biggest problems and ask "why?" until you reach a process you can change.
  5. Report: write the project review report with the six sections from this lesson (one to three pages plus appendices). Give it to your client and teacher.
  6. Assessment: rate yourself (and, if you have teammates, each other) on the charter's criteria, with one piece of evidence for each score. Discuss any gap of 1 or more.
  7. Reflection: write a What? So what? Now what? reflection of about 300 words on your own contribution, ending with three specific actions.

What to look for: numbers, not impressions; causes in processes, not people; recommendations someone could actually follow; a reflection that is honest about both strengths and weaknesses.

Your turn

1

Name four things a project review compares between plan and actual.

2

A milestone was planned for Monday, November 16, 2026 and reached on Thursday, November 19, 2026. What is the slip in working days?

3

Planned effort 80 h, actual 92 h. What is the percentage change?

4

Rewrite as an actionable recommendation: "We should test more."

5

What makes a retrospective blameless, and why does it matter?

6

Why is the number of commits per person a weak measure of contribution?

7

What are the three questions of the reflection model?

More practice: warm-up

1

What is another name for a project review?

2

What is a variance?

3

Name the three columns of a Start, Stop, Continue board.

4

Who is the review report written for?

5

What does {slip:+d} do in an f-string?

More practice: on your own

1

Ask "why?" to find a root cause for: "Two features were finished the night before the demo."

2

Using the variance program, what would it print for a milestone planned for Friday, December 4, 2026 and reached on Monday, December 7, 2026?

3

Write the "Successes" section (two sentences) for a project where the client never missed a demo and no bugs were found after release.

4

Why should peer assessment use criteria agreed at the start (in the charter)?

5

In the peer-assessment program, what would change if the flag rule were abs(gap) >= 0.5?

Challenge

1

The effort was +28% but the delivery was within the deadline. Explain how both can be true, using LendIt's documents.

2

Design a better measure of individual contribution than commit counts, combining at least three sources of evidence.

3

Write the "Now what?" part of a reflection for a team member whose peer ratings were high for quality but low for communication, with three specific actions.

Check your understanding

Quiz

1.

Which is the best evidence for a project review's schedule section?

2.

Planned effort 120 h, actual 150 h. What is the effort variance?

3.

Which recommendation is actionable?

4.

What is the main idea of a blameless retrospective?

5.

Jordan rates his reliability 4; peers average 2.3. What is the most useful next step?

6.

Which reflection shows the "Now what?" step?

For parents and teachers

Big idea: B1.6 asks students to review the management of the project (compare plan with actual performance, outline successes, recommend improvements) and prepare a report; B2.3 asks them to reflect on and assess team and individual progress. This lesson covers variance analysis, root causes, blameless retrospectives, the review report, fair self- and peer assessment with evidence, and written reflection.

How to help: Read the review report as the client. Ask what they would do differently next time and whether that is specific enough for someone else to check. If peer feedback stings, help your teen look at the evidence first and the feelings second; the What? So what? Now what? model helps.

Common difficulties:

  • Reviews based on impressions rather than the numbers in their own documents.
  • Blaming people ("Luc was slow") instead of finding process causes.
  • Vague recommendations.
  • Self-assessments that equate hours worked with contribution, or that are overly harsh.