Subscribe
The death of a promising project is jarring. It may open the door to opportunity. It may also lead to more problems. Which path is illuminated depends upon what the stakeholders, including team members, choose to do with the pain.
Grieving
The stages of grief – denial, anger, bargaining, depression, and acceptance – are known by many. What isn’t commonly known is individuals have the ability to refuse to go through them and simply stay stuck at one stage. This can be seen at funerals and wakes.
There are those who lack any significant response and their turn in the pit of unfairness of life will come with some other event. Others are shattered and will need time to put the pieces back together in a way that puts the loved one’s death in perspective by incorporating something of the deceased’s spirit in moving forward in a significant, positive way. Still others who experience grief simply want to go “back to sleep,” get through the situation, and return to a monotonous sense of security that can be shortsighted, numb, and insensitive causing a walling off to occur along with stunted growth.
Keep the somber images above in mind when doing lessons-learned on a promising project that somehow failed, and failed dramatically to everyone’s surprise. There is nothing magical about lessons learned. If they are to be beneficial each stakeholder and team member involved must put some piece of themselves into the process and risk being transformed.
Robust Lessons Learned
What can help is changing the way lessons learned are performed. This can be done through resilience engineering (RE), steeped heavily in chaos and complexity theory. Two concepts from RE that help are “robust” and “resilient.” They can be used as lens for placing value on contributions to lessons learned.
Traditionally, a robust approach is used. Here “robust” means the ability for the system, as it is, to respond to change, especially threatening change. The overall structure of the system does not necessarily change. As is, the system changes tactics based on the threat being projected. This sounds pretty good. There is a trap present, though. An example may help.
Imagine a downsized company with resources stretched thinner and thinner having avoided major catastrophes on the last few projects. It is natural for phrases such as “best of breed, lean-and-mean, etc.” to start getting bandied around. With the lessons learned from each project a growing sense of false confidence can develop, one that leads to a “going to sleep” as to how close to the edge the team actually is. Suddenly – BANG! – a high profile project starts falling apart and a chain reaction of failure sets in moving at the speed of sound. What makes matters worse is nothing turns up when doing root cause analysis to determine where a fix is needed. No matter how hard everyone tries, workarounds have no impact or the workarounds make matters worse.
A Paradoxical Approach: Resilient Lessons Learned Ahead of Time
A better approach to lessons learned on the previously successful projects would be through resilience. As used here, resilience asks and answers the questions, “What is the nature of success? How can we sustain it? How close to the edge are we? Can we adapt? If we do, how must we change our structure and the way we do work?” Done properly, this approach to lessons learned helps puncture the false confidence and leads to a more sober, positive approach to building for sustained success. In the example this would lead to addressing human capital well in advance of the catastrophe. The paradox, then, is lesson learned would be performed BEFORE the next high profile project began in an attempt to avoid the catastrophe.
In closing, there is one key difference between the robust and resilient approach. Rather than root cause analysis the resilient approach examines the socio-technical complex present in the organization. It looks to see where everyone is “drinking the Kool-Aid” and a collective march towards the edge is occurring while everyone believes success is just understood to occur.
—