At my place of employment, we've had some serious growing pains. We went from a development team of 3 to 10, and the company itself has grow 30% in the past year. By most measurements, we're doing well. Unfortunately, the quality of our software has suffered.

In a meeting today with my division's manager, I proposed a project team meeting a day or two after the product has launched. We could discuss budget concerns, scope, what went wrong, and what went right. Ideally, learning from our mistakes. We build sites/apps for other people, so our time is either billable on non-billable. A meeting like this would fall under the latter.

My manager shot it down almost immediately: "That time isn't billable. It'll make us get behind on another project because we waste time at the end of that one talking about it." I was so caught off guard by this logic that I didn't even bother fighting him on it.

So my question: I see the value is post-project meetings, but he doesn't. Is there documented proof of post-project meetings helping save time and money in the long (or short) run? Intuitively I think it will/would, but he clearly is more worried about a small amount of un-billable time from the 5 people that would need to be there.

  • Is there a reason for not talking to the 5 people over lunch or on breaks to get something to demonstrate the value of seeing what people thought about the project? In a way this is just doing it off the company time to be able to demonstrate that there is something there. Just an idea for you to try.
    – JB King
    Commented Aug 22, 2011 at 23:25
  • 10
    Make the hours billable by including them in the budget before hand... And to counter the argument that you are going to price yourself out of a market: 10 manhours or so isn't going to make a difference to a single project (if it does, the project is too small to merit a post mortem anyway). And when your quality goes up as a result of these postmortems, people aren't even going to argue about 10 hours more or less. Plus: don't specify them on any quote, but include them in "general overhead". Commented Aug 23, 2011 at 8:30
  • agree with Marjan. Sometimes Project Manager does not really know what is good for their project. If you are a team lead / tech lead, just do a quick meeting, and do not bother to update the PM. Put the mandays as general overhead. Or you could just do a coffee/lunch session with the developer and do the meeting during that time.
    – Rudy
    Commented Aug 23, 2011 at 10:11
  • 1
    day or two after may be too early, see Conducting a Project Postmortem by Steve Pavlina: "The best time to conduct a postmortem is about two weeks after a product is released (or for certain products, after the project is cancelled). This allows you to regain your objectivity without forgetting the details. Your memories will still be fresh, and you'll have a good perspective to see the project as a whole rather than focusing too strongly on the most recent work..."
    – gnat
    Commented Jul 7, 2015 at 10:28

8 Answers 8


Looking Back, Looking Ahead would be close to documented proof on the idea. The Project Post-Mortem: A Valuable Tool for Continuous Improvement would be a blog post about it.

The Art Of The Post-Mortem has this point about the idea:

The origins of the Post-Mortem are with the military, who routinely use this kind of process to debrief people on the front lines. But its management application is essential to any high performing, learning organization.


Your manager doesn't understand the concept of Technical Debt.

Post-project meetings are an investment, not a cost. That's how you have to sell them. The purpose of any meeting is to exchange ideas about how to save money and fulfill the company's objectives over the long term.

Your manager is a manager because he deals with these long term objectives. So in my view there are two possible truths: your manager wants all the control to himself, or your manager isn't doing his job. If the company has a history and philosophy of doing things "the right way," and investing in its own success, consider taking the issue above your manager.

  • 1
    Unless you give a practical example or two, this kind of arguments is unlikely to convince anyone that it isnt a cost.
    – Rook
    Commented Aug 22, 2011 at 22:46
  • 3
    @Rook: I don't think any argument is going to change someone's management style. Commented Aug 22, 2011 at 22:48
  • Managers like figures (as in monetary figures) ... show them hard figures, and he'll turn the company upside down to get them ... but he's not gonna do it on the basis of "trust" or something immaterial.
    – Rook
    Commented Aug 22, 2011 at 22:51
  • @Rook: Yeah, but how do you do that? You don't know what benefits you're going to derive until you have the actual meeting, so it's a chicken and egg problem. Looking at dollar figures only is a short-term-thinking problem by a person looking for low-risk proof. The manager doesn't need proof; he needs a check-up from the neck up. Commented Aug 22, 2011 at 22:54
  • Well, take someone elses experience and figures then. Or estimate. In any case, use something "concrete", not just "stories". Don't know how to put this better, but I'm sure you get my drift.
    – Rook
    Commented Aug 22, 2011 at 22:56

This is essentially an after action review, which is particularly useful in a lot of different contexts, not just the military.

My own development cycle involves analyzing both what should be done in the next iteration or project and what could be done better in the previous project. Even if a project is shelved for awhile, having a list of things to work on helps when it comes off the shelf (or backburner...) and is again an active project. The next time I touch it, I don't have to spend as much time reviewing what I need to do.

In addition, by reviewing a project and finding the neat tricks that I or others have implemented, these are disseminated and the next project or next iteration is that much better. (It might come as no surprise that I frequently think in terms of iterations.)


The value of this is simple logic and inherently obvious. How can you improve on future projects if you never learn from your mistakes on your previous projects?


While not specifically documentation, review of process (during or after completion) is a major component of just about every standards-based quality control system I know of, CMMI and Lean 6 Sigma especially.

Maybe you could propose it as not an obligation, something that is done voluntarily over a lunch meeting or something? Chances are good that quite a few of your development team will be eager to come and try new things... so if you can swing at least the first one, the results will speak for themselves.


It may be that your manager is under budget pressure. That has to be a big concern when expanding from 3 to 10 developers in a short time. If that's the case, then it's probably a good idea to just skip the post-mortem meetings for now and suggest them again in a few months, when hopefully the immediate budget issues won't be so pressing.

One reason that quality may be suffering is that communication between 10 people is a much bigger problem than communication between 3 people: 3! << 10!. While you can probably muddle along as you are for a little while, you're going to eventually have to make some changes to foster better communication among the developers, and to make sure that the principles that the original 3 developers established get disseminated to the newer folks and updated to work well in your new larger group. Project post-mortem meetings are one way to do that; periodic code reviews are another. It wouldn't hurt to point out that post-mortem meetings are a critical part of quality improvement in industries from medicine to manufacturing.

It's hard to imagine that your manager believes that he can expand his development team simply by hiring additional people. There absolutely has to be some investments in training and team building; without that, your organization will collapse under its own weight. If you wait a little while, your organization may start to experience some concrete problems that are directly attributable to poor communication. At that point, your manager will probably say: "We've got to get everybody on the same page! Schedule a meeting with all the developers!" And if it seems to help, he'll probably say: "We should be doing this after every project!" ;-)

So, be patient, but be persistent.


I'll buck the trend: I agree with the manager.

I've found post-project reviews largely pointless because it's too late to do much of anything to correct the problems revealed.

What I would most highly recommend is periodic retrospectives done during the project. Once or twice a month have the team talk about what went well, what didn't; what to do more, what to do less. Do this during the project so that you can immediately apply the suggestions and see how well they work.

  • I also agree because nobody wants to blame anybody during those meetings so it's generally not fruitful. Commented Aug 23, 2011 at 0:50
  • 7
    The goal of a post-mortem isn't to fix the project. The goal is to fix your process so that you don't repeat the problems that you encountered.
    – Caleb
    Commented Aug 23, 2011 at 1:53
  • I believe retrospectives is another name of post mortem meeting.
    – Rudy
    Commented Aug 23, 2011 at 10:14

Look at fomalising the meeting. Many post-project meetings are talk-fiests and your manager is absolutely correct not to support them.

Invite you manage to the meeting (ask him to chair/moderate), circulate an agenda and have specific outcomes. As a manager, he can then see the value in the meeting.

We use, and I recommend de Bono's "6 Thinking Hats" review process (refer Wikipidia). The outcome is a few (2 or 3) action points that the meeting identifies as being the most important leason learnt. The first few times we has trouble getting out os the starting blocks, but once we got used to it, won't go back.

Not performing a post-project review dooms you to make the same mistakes you made in the previous project.

Not the answer you're looking for? Browse other questions tagged or ask your own question.