Blogroll

Lessons Learned, Stupid Organizations, and the Other Things

Many organizations are stupid. This always surprises me as stupid organizations almost always have very smart people working within them and are often quite successful. Stupid organizations are stupid however, because they’re missing actionable models for success.

Last Saturday was the fourth annual TEDxHouston, a great day of slam poetry, obscure conceptual mix-ups, and lessons on how stand up comedy and gender-neutral pronouns can save the world. All of this was held around the proverbial corner at Rice University.

The basic concept of TEDx, for those of you who’ve never attended, is to pick a topic or concept, and then to invite an eclectic mix of local thinkers in the fields of Technology, Entertainment, and Design to interpret that concept through the lens of their particular passion. The audience is then invited to translate those concepts through their own perception bias and into the realm of their own professions. Saturday’s concept was “The Other Things,” a reference to the John F. Kennedy moonshot speech delivered at the Rice University stadium 50 years ago:

We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.

Last Saturday, a couple dozen speakers took 12 minutes each to identify what they felt those “other things” were. One such session was presented by a physician from MD Anderson, a local hospital specializing in cancer care. That’s what got me thinking about lessons learned and the concept of stupid organizations.

The concept is surprisingly simple. Most people in the world do not have access to the world class cancer treatment available in treatment hubs such as the Houston Medical Center. MD Anderson is thus teaming up with IBM to develop a rich database of data related to treatments and success models. If a patient is diagnosed with cancer, the doctor may tap into this wealth of information to prescribe a tested, valid treatment plan. (Link to discussion here)

This is a perfect model for what the lessons learned exercise should be. In a perfect world, lessons learned should focus on what success looks like, and how the project achieved success. Specifically, a lessons learned exercise should be designed to refine success and convert it into an actionable model. This actionable model may be used in at least three distinct ways:

To structure the next project to take advantage of this model thereby enhancing the chance of success.

To structure the next project to identify when the project is diverging from the approved model, and thereby increasing risk by branching onto a heretofore unknown development path.

To structure the organizational processes to ensure that the chance of project success is enhanced (See point #1)

Not only does a smart organization continuously refine the model that brings success, but the smart organization continuously looks at that model as a scientific hypothesis, i.e. a theory that explains how things happen, but that can be jettisoned the moment we come up with a better model. Models are like any theory: they’re valid until they’re not.

Instead of lackadaisically conducting a couple of interviews after your next project and calling it lessons learned, think about how to convert your current project into a repeatable model for future projects. In retrospect, what were some of the key indicators and patterns that led to the place you’re currently in? Break those down into at least two categories:

Things that directly impacted the course of the endeavor.

Things that enhanced the chance of the endeavor succeeding.

Take those concepts and feed it back into your lessons learned exercises, project structuring, and HR onboarding process. Don’t start a lessons learned process by focusing on the solution and asking what generic information you need. Rather, focus on the fundamental organizational problem by really defining success, asking what models lead to that success, and how you can structure your projects to map them to those models – or to detect when the project no longer aligns with a proven model.

Continue to test your models. Don’t accept a success model as the gospel, instead continue to test it against success patterns to see if you’ve really distilled the essence of what makes your organization successful.