Learning from failures (and successes) requires different IT systems

A few years ago, I worked with a colleague tasked with improving his company’s project management outcomes (I was going to say processes, but on thinking about it they asked him to improve the performance and results).

He’s focusing on lessons learned, as you might expect. The company has done lots of projects; surely there are many lessons within those projects that could help improve things going forward? And there are. But my colleague has found that the inability to effectively capture and share these lessons prevents the organization as a whole from getting much if any value out of their past experiences.

[A Harvard Business Review article, "The Experience Trap," emphasizes why project management, in particular, is prone to repeating the same mistakes over and over again.]

I was thinking about my colleague as I was reading this recent article in “Strategy + Business” entitled, “Are You Killing Enough Ideas?” by Zia Khan and Jon Katzenbach. The article discusses innovation, not project management, but this section in particular resonated with me and spurred my connection with project management lessons:

…When there is an ineffective balance between formal and informal structures, it often shows up as an inability to manage bad ideas effectively. After a formal decision has been made to advance some ideas but not to pursue others, the company expends considerable effort to plan the next steps for the winners. But no one thinks actively of planning next steps for the losing ideas, to put them to rest, free up their supporting resources, and (ideally) identify and share any lessons or insights gleaned from the experience.

One quibble with this otherwise excellent paper: why is identifying and sharing lessons and insights from experience an “ideal” situation? It should be business as usual.

Significant corporate initiatives, whether they are innovation ideas or IT projects, are expensive in capital, resources and opportunity cost. The experience, whether the project is ultimately a success or not, is hard won and valuable. It should be mandatory to capture and share these lessons and insights.

There are several barriers my colleague faces in trying to institutionalize the creation and use of lessons learned. “Let’s move on” is one of the most pernicious ones. After a difficult project, people are inclined to look ahead rather than backward, to forget difficult or painful experiences rather than mine them for lessons. (As mentioned in chapter 6 of the book, lessons sometimes emerge years after an experience.) Organizations, of course, in their eagerness to place blame, facilitate people’s instincts to hide or blur what happened in the case of a failed project.

My colleague’s company has a very open and positive culture; they are more equipped than most companies at overcoming the reluctance to share. Yet they still face a significant obstacle: their information systems are not up to the task of gathering, sharing, sorting and consuming lessons-learned material.

They capture lessons in Word forms and documents, and store them in file folders on a shared drive. And they are not surprised when no one can find anything. Dumping valuable lessons on a shared drive may have a slightly positive use for whoever writes the lessons down; at least that person learns a bit more from the retelling. But certainly it’s of no use to anyone else.

Lessons-learned need enterprise 2.0-type tools that capture narrative data, signifiers and tags; allow users to “like,” pass along, add to, and otherwise annotate original stories; and browse through, search and connect related stories. That’s what my colleague needs, and that’s what every organization that wants to “ideally” learn from both good and bad experiences needs as well.