Lessons Learned · Business Analysis Notes

What it is#

The BABOK Guide presents lessons learned as a way for the project team and key stakeholders to reflect on and record both successes and opportunities for improvement, so that future work benefits. It does not prescribe a format: stakeholder preferences usually decide how a session runs. It also notes that combining the session with a celebration can encourage people to take part and reinforce the positive results.

According to the Watermark study tables, a session can cover:

business analysis activities and deliverables;
the final product, solution, or service;
recommendations about behavior and ways of working;
expected versus actual performance, and variances from the plan;
root causes that affected performance;
consequences for the organization;
new technology or automation introduced, or old technology retired.

The study tables list the benefits: the session surfaces areas for improvement, can lift team morale after a difficult project or phase, reinforces what made the work succeed, lowers risk for future projects, can produce metrics for improvement, and shows the strengths and weaknesses of the project’s structure, methods, processes, and tools.

When to use it#

At the end of an iteration, release, phase, or project. In agile teams this is a routine retrospective every iteration; in plan-driven projects, hold one at least at each phase end, not only at closure.
After a significant event: a troubled launch, a large change request, a near miss.
At the start of new work. The BABOK Guide connects the technique to tasks such as 3.1 Plan Business Analysis Approach and 3.5 Identify Business Analysis Performance Improvements, so read relevant past lessons before you plan.

When to use something else. If you need to diagnose one specific failure in depth, use Root Cause Analysis. If trust is low and people fear blame, an open group session may produce silence or finger-pointing; start with anonymous input or one-to-one interviews, and bring in a neutral facilitator.

How to do it#

Set scope and timing. Name the period and deliverables under review. Hold the session soon after the event, while memories are fresh.
Invite the right people. Team members plus key stakeholders who lived through the work. Keep the group small enough for everyone to speak; split large groups.
Gather facts beforehand. A timeline of key events, planned versus actual dates and effort, the item log, defect counts, stakeholder feedback. Facts keep the discussion away from opinions about people.
State ground rules. Discuss processes and decisions, not individuals. Assume people did their best with what they knew at the time.
Collect observations. Use a simple frame such as Went well / Did not go well / Try next time or Start / Stop / Continue. Have people write silently first, then share, so quieter voices count.
Group and choose themes. Cluster similar notes and let participants vote on the themes that matter most.
Look for causes. For the top two or three themes, ask “why?” until you reach something you can change.
Agree actions. Each action is specific and has an owner and a date. Two or three real actions beat twenty vague ones.
Record and share. Write a one-page summary and store it where the next team will look for it.
Follow up. Check action status at the next session or in the next planning meeting. A lesson nobody acts on has only been documented, not learned.

Example#

The Workshop, a fictional chain of 12 bike-repair workshops, ran a six-week pilot of online booking in three workshops. The analyst facilitates a session with the owner, two workshop managers, front-desk staff, a mechanic, and the lead of the outside development team. The owner brings pastries; it is also a small celebration of the pilot.

Went well: customers liked picking their own time slot; front-desk staff spent noticeably less time on the phone.

Did not go well: mechanics only saw the day’s bookings when they arrived in the morning; the disagreement about slot length surfaced late; parts for booked repairs were often missing.

Root cause for missing parts: the booking form did not ask for the bike model or the repair type, so nobody could order parts in advance.

Actions:

#	Action	Owner	Due
1	Add bike model and repair type to the booking form	Analyst	Before rollout
2	Send each workshop its next-day schedule every evening	Development team lead	Before rollout
3	Agree standard slot lengths with all 12 managers in the first rollout week	Owner	Rollout week 1

Common mistakes#

Only at the very end → run short retrospectives at phase or iteration ends so the lessons still help the current project.
A complaint session → the study tables warn that participants may shift blame onto others; set ground rules and use firm facilitation that steers toward solutions.
Blaming individuals → talk about decisions, conditions, and the information available at the time.
Only problems → record successes too; they transfer to future work just as well.
Reluctance to talk → the study tables note people may be unwilling to discuss problems or successes; collect anonymous input before the session and use silent writing.
A report with no actions → end with a few owned, dated actions.
Nobody reads past lessons → make reviewing them a standard step when planning new work.

Template#

Template

# Lessons learned: <project or phase>, <date>
**Scope:** <period and deliverables covered>
**Participants:** <roles>
**Facts reviewed:** <timeline, plan vs. actual, item log, feedback>

## What went well
- ...
## What did not go well
- ...
## Top themes and causes
- <theme> → <cause>
## Actions
| # | Action | Owner | Due | Status |
|---|--------|-------|-----|--------|
| 1 |        |       |     |        |
## Recommendations for future projects
- ...

Checklist#

Scope, timing, and participants agreed
Facts gathered before the session
Ground rules stated at the start
Both successes and problems captured
Causes explored for the top themes
Every action has an owner and a date
Summary stored where future teams will find it
Actions reviewed at the next checkpoint

Sources and further reading#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Technique 10.27 “Lessons Learned”.
Watermark Learning. BABOK v3 Study Tables. 2016. (study aid for the BABOK Guide). Section 10.27.