83. Lessons Unlearned

Pencil Drawing by Brian Duey

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 over-staffing, 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 that didn’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.

¹ 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).

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.