The Post-Mortem — Not the “What”, but the “How”

With so many great projects happening in the Public Service Renewal world, we often find ourselves wrapped up in the “what” of the projects. This makes sense — we’re concerns about what it is that we are doing, and where it fits into the larger picture. As projects are launched and reports are written, it is easy to become sit back and look at the project, and then try to decide what project you’ll work on next.


I’ve certainly been guilty of this. While it can be nice to look back on projects, no one wants to look back and bring out the failures that occurred during the process, or look at the content again. It’s important, though, they we look back and do an analysis of the process that we used to get to our (hopefully successful) end.

What I mean is that we’re often so focused on the “what” that we don’t look at the “how”. How did we plan the project? How did we develop our products? How did we consult? How did we advertise the project? How did we work together? The “what” becomes less important for this particular aspect (not saying that it’s not important — it is).

By reflecting, publicly, on the “how”, it allows those of us who are either in the midst of projects, or about to embark on them, to learn from the trials and tribulations of your team. The issue is that we often don’t want to be honest about it. For some reason, there seems to be a perception that if we publicly reflect on the issues we faced in the run of a project cycle, that it somehow lessons the credibility or the perfection of our product. We assume that others will tear apart our project, and doubt its perfection!

Of course, these are myths. The expectation of perfection isn’t there, and even if it was, I can’t imagine any project being perfectly executed, with no sort of internal issues (whether HR, financial, IT, etc). By hiding our strategies for success, we put ourselves into competition with each other, rather than collaborating. If we’re going to spend so much time talking about collaboration, then I don’t want to just see project pages on GCpedia — I also want to see the post-mortems (and honest ones, at that). This is especially true for longer-term projects and ones that involved a large collaborative aspect.

So, hoping beyond hope that some people from Chelsea’s Blog Rally still read this, I ask you: What is the biggest issue you’ve faced in a project? How did you combat it? Would you do it differently now?


10 thoughts on “The Post-Mortem — Not the “What”, but the “How”

  1. Doing frequent retrospectives to look back on how a team is working together, what is working and what isn’t, is critically important if you’re serious about getting better at how you do what you do.

    Agile approaches to getting stuff done, which are based on short cycles of iterative and incremental delivery of whatever business value the project delivers, ask teams to hold a retrospective at the end of each delivery cycle to inspect how they worked together as a team (there’s a separate meeting to inspect the work product itself) so that the team’s learnings and insights can go into the planning of the next delivery period or project. As a coach, I recommend to the teams that I work with that they make most of their retrospective findings available to other teams so that the wider org can benefit from what they learned and what worked well from them. (I say ‘most’ findings because sometimes the issues are very particular to the people on that team, in which case it may not be appropriate to share the discussion/learnings with a wider audience). I’m struggling with getting people to use the org wiki (this is in a non-PS context) to do this — there’s a lot of fear related to airing dirty laundry to overcome in favour of the mindset that we should share what we’ve learned far and wide in order to benefit the org as a whole.

    I also ask teams to take an Appreciative Inquiry approach to looking back on how work unfolded in order focus on what *worked* rather than what didn’t (which is where people often like to focus during these kinds of discussions). Paying attention to what didn’t work is important, but future success is more likely to be based from noticing what went well and committing to do more of that in the future.

    So, to answer your questions about tough issues in projects (again, from outside a PS context): it’s usually about the people, and how they talk to each other and reach agreement on getting something done. Sometimes the biggest hurdles are org impediments where the project team wants to implement something and are prevented from doing so by stakeholders or gatekeepers, but more frequently it has to do with the team not working well together or not being honest with itself and the stakeholders about the actual current state of getting stuff done. These are harder issues to solve because they require transparency and honesty to address properly, and if the problem is trust, it’s hard to be transparent and honest.

    • Thanks for the comment, Ellen!

      I think you’re right re: many issues surround the people. The gov’t context can offer some unique issues (certain policies people might not have been aware of, seeing what other departments are doing, etc) that it would be nice to better understand.

      I’m not entirely convinced about not reflecting on the negative aspects — what I mean by that, is we do want to replicate success, but also want to NOT replicate mistakes. In order to do that, we need to understand what the mistakes are, and why the methods used to combat it may not have worked. The totality of understanding is what I think we’re going after.


  2. Thanks Colin, I really appreciated this post. I have found myself coming up against the whole notion of the “how” lately. While the “what” is super important and is what drives people to projects/initiatives in the first place (it is the sexy piece); the “how” seems to be relegated to distant second in the hearts and minds of participants. And while your post focuses on the work of reflecting on projects i think the same sort attitude exists at the outset and even during projects. We only want to talk about the “what”, we don’t really want to hear about the “how”; our eyes roll, we squirm in our seats and we doodle on our notepads. Of course the “how” is supposed to be what gets you there but no one wants to talk about it,and then no one wants to be reminded of it along the way. We like to hear ideas and we especially like to share our ideas (the “what”) but we are not that terribly interested in being told to focus our ideas/actions within a timeframe, scope or process. We love action, getting stuff done but we are not terribly interested in acting within a scope, process, or even timeframe. There is a lot of talk lately about collaboration (it has a lot of sex appeal!), and the great thing is that collaboration is not the “what”, it is the “how”…and it is super interesting and an incredible opportunity for us to look closely at it, at how we’ve done it is the past and how we do it now, in order to learn to do it better.

    Woah, that is a whole lot of use of those words in one paragraph…sorry if it’s coming off a little repetitive! I hope i was able to express my thoughts clearly enough. Cheers!

    • I agree about the sexiness of collaboration, hopefully we’ll give it the scrutiny it deserves! My worry is that we says things will be completed collaboratively, without understanding fully the implications of the term. What does that mean? How will the various tools be used?

      The following step, as part of the how, is how does accountability work in a collaborative atmosphere? I think that’s another thing we don’t often want to talk about.


  3. I think that sometimes the failures and the stories behind them are more valuable to an organization than the successes. I always make an effort to document what didn’t work in a project so that we can learn from our mistakes. Successful projects don’t always get as much attention from me but failures get dissected to ensure causes are identified and if possible avoided in the future.

    I will try to share my closeout reports wider next time even if most of my projects are small potatoes in the grander scheme of things.

  4. I think a big part of the fear is that what didn’t work can often be a whom didn’t work. The people who did want to get on to the next thing and the people who didn’t don’t want to get called out – definitely not publicly, but preferably not at all. In the Public Service, where punishment for poor (or even unacceptable) performance is not only rare but really quite difficult even if a manager or a team wanted to do it. But, maybe this is one way to make that into positive learning. How do you work around situations? Maybe case studies that are less precise about the human, procedural, or functional name of the problem but more precise about the tools used to solve the problems would be more helpful and could be part of the “collaboration” process. That makes it all success stories, instead of some of the more failure or problem-focused stories you were kind of getting at. But I think you are also talking about things that actually give you something to use – an unknown process or rule or method. So, I think this perspective on it could work. What did we learn that we could share with ourselves, with others or with our successors. I think massive value in this would be true project handover notes with precedents learned written for someone who wasn’t there but will likely use that knowledge in the future. I haven’t only seen that in one division ever, and even there not all the time.

    This could be an MBTI thing too though, where the T in me would rather get it done and talk about how it can be done better next time – but fix it first – than sit around with people who would like to sing kumbaya and talk about how we could all share more when we are getting things done (I guess the latter is my nightmare scenario when someone wants to have a post-mortem on “how” we did that has no outcome or metric focus around it). I’d rather talk about how what we learned could be applying to the system as a whole than talk about a project that we finished – unless we are doing it all over again, then sure, let’s talk about what worked and didn’t last time. I guess the other reason that I’m hesitant is that best practices cases take time and if you don’t know that you are going to use it again or anyone else is, is it really value that you are creating? Jot down a few notes, sure… but to go in depth, I’d rather people worked on the system and the longer term stuff in the absence of a next real project to talk about. Extrapolating in the abstract doesn’t seem as worthy (unless it’s over a beer, for kicks, with people you like anyway – in which case, it’s standard post-work drinks, no?)

    • I’ll buy the first part of the argument — case studies that look at the tools, an how they were used to overcome various issues that arose throughout the project. Of course, I’m also interested in hearing how some tools didn’t work, and why they didn’t work, as it is a lesson that others can learn from.

      I half buy the MBTI thing. Being a ‘T’ myself means I’m also looking for efficiencies and knowing how to not make the same mistake twice. That doesn’t necessrily have anything to do with feelings, but rather looking for efficiencies. Analyzing the “how” of a project makes it so that inefficiencies in this project aren’t repeated in another project. If made available to the department through a broader medium, then it may contribute to the reduction of inefficiencise across the system. That’s how we begin to feed into the larger system-based solutions.

      Thanks for the comment, Teale!


      • Sure. But, then, do you agree that the focus should be on how the case applies to the system, rather than beating a dead project horse?

        Agreed on noting the tools that didn’t work – the first, second or third tries before the better one was found – or why it didn’t fit that scenario.

        I think the MBTI feelers out there want to talk about how the process could have loved and included them and others more sometimes and that’s maybe why people are scared of sharing circles/outlets. Maybe guided reflection and revision on the tools and the process would be a good compromise to avoid wasting time on what interpersonal dynamics or leadership issues (which maybe could have another venue – like a 360 assessment) came up?

      • It depends on the group’s understandnig the system. Given that the system is made up of its components, data can be collected at the unit-level. If efficiencies can be created at the unit-level, then that still benefits the overall system.

        Putting it into a system-level context is certainly important, and if the information collected can be couched in such terms is is helpful. But I wouldn’t underestimate the power of collecting that information at the unit-level.

        Sometimes talking about what worked/did not work in terms of dynamics can be helpful, although I’m thinking a bit broader than just within the group. Maybe there was a key group that wasn’t consulted (and that lack of consultation caused some issues). Those types of ‘feeling’ perspective can be helpful in making a team better able to achieve its goals.

        MBTI, while a helpful indicator of how we all work, is by no means (in my opinion) meant to be taken to extremes. The ‘F’ is just as important as the ‘T’ in establishing a high-performing unit, assuming that people aren’t just robots programmed to complete certain tasks. I agree that many aspects of the ‘F’, in a post-mortem setting, would be better suited to another venue, it still has its place in conducting a unit post-mortem.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s