Have you ever fallen off your bike?

Were you pushing yourself (attempting a jump, in my case) or just learning to ride?

What did you do next?

Did you hobble off in a fit of rage and quit, never to return to the 2-wheeler lifestyle? Or did you quickly review what went wrong and then try it again?

What about your organization’s implementation attempts? Have they all been perfect? Any mistakes?

Most Digital Transformation efforts are a lot like attempting a jump over 15 cars “Evel Knievel-style” – and if this is your and your organization’s first implementation attempt – you may never have ridden a bike before. But chances are, your organization has attempted implementations before. So if you are still using 4D as your database, Quark as your design application, and Microsoft Access for everything else, I stand corrected.

When you consider a change in your organization, it’s beneficial to understand what has happened before you get started on anything new.

Some organizations already conduct regular post-mortem meetings (or “lessons learned” post-project, reflection meetings for those steering clear of death analogies in project management) after every major project. So if you are already doing post-mortems, the mega post-mortem is just one more step.

For everybody else, you’ll want to conduct five years of implementation project reflections very quickly. Your goal is to get a list of what went wrong (and right), so you can avoid or improve upon them in the future. I’m simplifying it here, but the idea is to learn as much as you can as fast as you can and to be as inclusive as you can.

After listing the projects over the last five years – set up a post-mortem for each.

Conduct Post Mortem meetings

1. Invite all key influencers and end-users to the meeting – people involved in implementing and receiving the change for each project
2. Follow post-mortem meeting rules. Here’s a helpful article on post-mortems.

A couple of notes on this:
Gather what data you can about the challenges. Avoid traps like blaming it on a person (or team) or a specific product – but look deeper to see what aspects of your organization may have been contributing to the issues. It could be a person, team, or specific product, but be aware that that is the default scapegoat to project issues. Cultural trends were responsible more often than not, but you’ll have to dig until you get at them.

Offer people the opportunity to discuss feedback personally. Silence doesn’t mean agreement in these meetings.

Be acutely aware of the dynamics in the room. This feedback is as helpful as the spoken words tossed around.

Once the initial Post-Mortems are complete – collect and consolidate the data.

Build the Mega Post Mortem rubric

1. In three columns, write with name, the intent of each project, and the start of the project.
2. In the following three columns, list the team that implemented it, the impacted user group, and the lessons learned (Brevity is your friend here).
3. For every project you’ve completed in the last five years, fill out a new row.
4. Look for trends – and highlight them. Do you see any common problems among groups?

Start with that rubric if you are implementing software that will qualify as a significant change. This is not to say that the issues listed in the rubric won’t happen again, but, like a bike jump, they may prevent you from falling on your ass.

Supporting Music

Thunderstruck by AC/DC

Paper Planes by M.I.A.

Do I Wanna Know? by Arctic Monkeys

Note: Originally posted November 28, 2017