Continual improvement through post mortem’s August 22, 2008Posted by Darth Sidious in Project Management.
A lot of organizations move at a frantic pace (especially the Galactic Empire), but never really improve. When it comes to projects and managing projects it’s common to move right onto the next one as soon as one is done.
Because of that, are you ever truly improving? It’s worth it to add as part of the project plan to factor in a post completion post mortem. In the post mortem you’re looking to identify the following…
What did we do well?
Being fully aware of your strengths is important, as that’s what you want to continue leveraging as an advantage going forward. Are you particularly good at completing certain types of projects, actualizing certain types of ROI, or taking on certain kinds of hurdles?
When it comes to prioritizing future projects, it would be a smart move to notate somewhere for all future projects how well your strengths (from the perspective of project execution) map against the project as part of the evaluation process.
For example the Empire is particularly good at building Star Destroyers, we can pump those suckers out like it’s nobodies business. Since resources (people, capital, and time) are always in short supply and we have a need for a Star Destroyer, vs. something else – each of which are equal in priority… the tipping balance would go in favor of the Star Destroyer since we know we can kick ass in that area.
What didn’t we do so well at?
This is where the improvement comes into play. If you’re not identifying what you didn’t do so well at, you’re going keep repeating the same mistakes over and over again. For example there’s a mistake that the Empire keeps doing and it drives me crazy – we keep using the same round interface port design that allows R2D2 to keep overriding our security systems (you have no idea how annoying that is).
As part of the post mortem list out all the things that didn’t go well with the project. Things you didn’t anticipate, what caused certain delays, why budgets were overrun, why the amount of scope creep was out of control, things you found the organization isn’t good at, etc… For example I’ve found that the Empire is not good at building commodity low cost attack robots; Jedi’s are able to walk through armies of those as if they’re nothing more of a nuisance than flies. We just can’t get the artificial intelligence level high enough with the low cost CPUs, part of that is our coders lack the skill to write efficient enough code (I’ve electrocuted them as a result btw).
So going forward now that we’ve identified that weakness at least we’re not going to keep making the same mistake. Though in those analogies they’re slanted towards the quality of the product, but just to clarify, your focus is on the project and not necessarily the product. A bad product is just the result of not identifying our weaknesses up front as part of the project planning (e.g. I like the idea of cheap robots, so if we try to do it again perhaps we bring in a company that specializes in such things).