This Month’s Pattern *

83 Lessons Unlearned

The team recognizes its mistakes but repeats them anyway.

Which activities are important in your project?

Writing code? Definitely! Getting the requirements right and testing your product against them? Oh yes.

Doing design? Oh, well. Holding Lessons Learned sessions after the project to improve your work methods? Holding what? Lessons Learned? Why should we waste our time on that? We can’t change anything about our last project—it’s done. (Finally!) Besides, we don’t have time for navel contemplation; the next project is already funded, and we’d better get going.

If such reactions are common in your company, you’re not alone.

One excuse for not examining the project’s successes and failures after the fact is a presumed lack of time. Another excuse is more cynical: “What good is it to pore over our past errors? Our company is not going to allow us to change anything anyway. Besides, we have just made it up to CMMI Level 3; we’ve got to stick to our current approach or we may get sent back to Level 2.”

Both excuses are surefire recipes for repeating whatever errors were made the last time around. Failures that everyone recognizes as failures find no way to turn around and influence what happens next. So, the same failures happen again.

Just having Lessons Learned sessions at project end is a step in the right direction, but it’s not always enough. It’s possible to go through the exercise and still not reap the benefit. Consider this exchange:

    “We do these sessions on most projects here. Give the team two hours to reflect on the good and the bad things about the project. They’ll feel better after they’ve vented.”
    “And then?”
    “Um, then everybody moves on to the next project.”
    “Doing exactly the same things they did before?”
    “Well, more or less.”

How could this happen? How could the review end up being primarily a pressure release mechanism rather than a catalyst for change? The sessions, after all, are justified explicitly as a “mechanism for change.” That sounds right, but there’s a word missing from that justification: They’re actually intended as a “mechanism for internal change.” And there is the rub.

Projects that conduct after-project reviews often find themselves highlighting problems that are not strictly internal to the project. These problems have root causes in the constraints imposed on the project from the outside: organizational interfaces, inadequate access across political lines, artificial intermediaries, imposed understaffing, early overstaffing, imposed standards that get in the way, crazy schedules, lack of clerical support, and so on. Since the problems are outside the domain of the team, their solutions may be declared off-limits.

While we’re at it, changes that lie entirely inside the domain of the team are likely to be dauntingly difficult to implement. So, there’s the double bind: External change is difficult and scary for political reasons, and internal change is difficult and scary for operational reasons. No wonder the review sometimes turns into a mere gripe session with no serious inclination to change anything.

When a Lessons Learned process ends up being mostly for venting, you’ll notice that the published results are observations, not action items. Reversing this phenomenon is mechanically simple, though it may be nontrivial to pull off. The key is to insist on setting action items for identified problems both inside and outside the team’s power base: Tie each identification of something thatdidn’t help or got in the way to an action item to be applied to the next iteration or release, or on the very next project. This puts the Lessons Learned team in a constructive design mode. Some of the action items will be organizational, but they can’t be off the wall. They have to pass the same tests of implementability that their designs of internal project procedures have to pass.

A mechanical trick that is often used to open the sessions is to ask each person to come in armed with at least one good thing and one bad thing to report about the project. (This makes it permissible for participants to raise a subject that otherwise might be thought off-limits.) A similar trick can help close the exercise in a way that will successfully usher in change: Insist that there be at least one action item that lies entirely inside the team’s domain and at least one that lies partially or wholly outside.

Each action item should indicate how some method or task or human interface or imposed constraint will be modified the next time around to avoid the problem. The action items have to be explicit, and they have to be directed toward one specific effort—a kind of pilot for the change—where they will be applied. Because the action item limits the requested change to a pilot area, it has more chance of being accepted by outside powers.

Lessons Learned sessions are most often performed at the end of a project, * but there are good reasons to conduct interim mini-reviews as well, say, at the end of each iteration or each release.

Companies that benefit from the Lessons Learned exercise are courageous: They allow their approaches and processes and organizational structures to be critically examined—even skewered—and they are truly willing to consider change. Working for this kind of organization can be a joy. The opportunity to catalyze change is something participants find particularly valuable about their company culture.

    * Lessons Learned sessions are also called project retrospectives, postmortems, or post-project reviews. For valuable how-to advice about conducting your own Lessons Learned sessions, see Norman L. Kerth, Project Retrospectives: A Handbook for Team Reviews (New York: Dorset House Publishing, 2001).

* Each month we plan to publish here one of the patterns from our Jolt Award book, Adrenaline Junkies and Template Zombies — Understanding Patterns of Project Behavior. (Watch this space for a mere 86 months and you'll have read the whole thing.) The book is published by Dorset House Publishing, in the US and Hanser Verlag in Germany. It is available at Amazon and also as a Kindle book.


Oslo, Mastering the Requirements Process
12-Sep-2017 to 14-Sep-2017

Mastering the Requirements Process with Suzanne Robertson. Contact Den Norske Dataforeignen for details. 

Brussels, Mastering Business Analysis
13-Sep-2017 to 14-Sep-2017

James Archer teaches Mastering Business Analysis. Contact IT Works for details of this course.  

Stockholm, Mastering the Requirements Process
26-Sep-2017 to 28-Sep-2017

Brussels, Mastering the Requirements Process
10-Oct-2017 to 12-Oct-2017

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works for details.  

Brussels, MRP part 2
11-Oct-2017 to 12-Oct-2017

Rome, Mastering the Requirements Process
16-Oct-2017 to 18-Oct-2017

Rome, Mastering Business Analysis
19-Oct-2017 to 20-Oct-2017

James Robertson teaches Mastering Business Analysis. Contact Technology Transfer for details of this course.  

Oslo, Mastering the Requirements Process
6-Nov-2017 to 8-Nov-2017

Mastering the Requirements Process with Suzanne Robertson. Contact Den Norske Dataforeignen for details. 

Hilversum, Mastering the Requirements Process
7-Nov-2017 to 9-Nov-2017

James Archer teaches Mastering the Requirements Process. For details please contact Adept Events. Dutch description, or in English.

Oslo, Mastering the Requirements Process part 2
9-Nov-2017 to 10-Nov-2017

Suzanne Robertson teaches Mastering the Requirements Process part 2. Details for this advanced class at Den Norske Dataforeningen.

London, Mastering the Requirements Process
14-Nov-2017 to 16-Nov-2017

James Archer teaches Mastering the Requirements Process. For details and registration, please contact IRM UK.

in depth

Business analysis is often seen as a technical skill. But the business analyst has another set of responsibilities -- to dig into what the stakeholder's mind and uncover what is really needed, and not just what they say they want. 

A Ruby Beam of Light, Book I of Tom DeMarco's Andronescu's Paradox saga is now available in English in paperback and ebook, from Double Dragon Publishing.

"This war isn't going to blow anything up, only turn everything off."

Suzanne and James Robertson's "Requirements: The Masterclass LiveLessons-Traditional, Agile, Outsourcing". 15+ Hours of Video Instruction. 

Als auf der Welt das Licht Ausging, the German edition of Tom DeMarco's science fiction epic, Andronescu's Paradox, has now been published by Hanser Verlag in Munich.  Translation by Andreas Brandhorst.

James Robertson’s webinar for Software Education explains how agile stories are best used to ensure the right solution. Writing the Right Agile Stories on YouTube. Download the webinar slides.