Before tweaking procedures, look for vulnerable areas

Have you ever sat through a project washup and wondered what the point was? Or if anything will change next time? You’re not alone.

Most organizations claim they transfer knowledge from one project to the next, through exercises such as lessons learned, post-mortems, and after-action reviews. The laudable aim is continuous improvement, otherwise known as ‘doing better next time’. But often the outcome proves illusory.

Sometimes, you can identify a generic process that’s worth tightening up wherever it occurs (‘If X, do Y’). But try to define a procedure for everything and you risk creating a culture where people need instruction on how to tie their shoelaces. You have to trust your people to apply a general policy to their own context. Some safety procedures may require explicit steps. But even then, mindlessly following a checklist can lead to incidents.

In fact, it’s surprisingly rare for a non-standardized process to cause the kinds of things that actually go wrong on complex projects. Why? Start with why they are complex.

Every large feat of engineering has some factor that’s different this time, such as a new location, a different supplier, or a change in season. Just one new element interacting with myriad others nudges the project from the complicated realm into the complex. And complexity adds to riskiness.

When organizations seek out general principles to apply across every project, they diminish the value of the learning process. By definition, general principles can’t apply in all cases. You must adapt the lessons from previous projects to the unique context of the next one.

Aim instead to view recent incidents as indicative of areas of vulnerability. Did a weakness materialize during the initial approach or design phase of the project? Or was it a problem of not being ready when the work was in full swing? Perhaps it was a sensing issue? Or an unnecessary delay in resolving the problem?

Uniqueness adds to complexity, and complexity adds to riskiness.

Considering these broad areas helps you better identify categories of risks during planning, and then spot potential issues early before they materialize.

Don’t let your team fall into the trap of paying lip service to ‘lessons learned’ while not actually learning what will save your neck the next time. Question whether your current knowledge transfer practices are really helping you. If you don’t seek out the deeper reasons for failure, you’ll pay the price.

Remember: uniqueness adds to complexity, and complexity adds to riskiness. So, what’s different on this project? Start there.