Have you ever fallen off of 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 do a quick review of what went wrong, then tried 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. If you are still using 4D as your database, Quark as your design application, and Microsoft Access for everything else – then I stand corrected.
When you are considering a change in your organization, it’s incredibly helpful 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. If you are already doing post-mortems – then 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 things 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 you’ve listed the projects over the last five years – set up a post-mortem for each.
Conduct Post Mortem meetings
- Invite all key influencers and end-users to the meeting – people involved in implementing and receiving the change for each project
- 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 easily could be a person or team or specific product, but be aware that that is the default scapegoat to project issues. More often than not, cultural trends were responsible, 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.
After all Post-Mortems are done – you’ll want to consolidate all of the data and here’s an idea of how.
Build the Mega Post Mortem rubric
- In three columns, write with name, the intent of each project, and the start of the project.
- In the next three columns, list the team that implemented, the impacted user group, and the lessons learned (Brevity is your friend here).
- For every project you’ve completed in the last 5 years, fill out a new row
- Look for trends – and highlight them. Do you see any common problems among groups?
If you are implementing software that’s going to qualify as a significant change – start with that rubric. 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.