23

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.

Jack Slingerland
  • 333
  • 1
  • 5
  • 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 Aug 22 '11 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". – Marjan Venema Aug 23 '11 at 08: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 Aug 23 '11 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 Jul 07 '15 at 10:28

8 Answers8

25

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.

JB King
  • 16,795
15

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.

gnat
  • 21,213
  • 29
  • 113
  • 291
Robert Harvey
  • 199,517
  • 1
    Unless you give a practical example or two, this kind of arguments is unlikely to convince anyone that it isnt a cost. – Rook Aug 22 '11 at 22:46
  • 3
    @Rook: I don't think any argument is going to change someone's management style. – Robert Harvey Aug 22 '11 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 Aug 22 '11 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. – Robert Harvey Aug 22 '11 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 Aug 22 '11 at 22:56
  • Here's an example: when I break something, I tend to put in a test to make sure it's not broken in the future. That test is good to inform others about. Sometimes I put in a test anticipating that things may break, this is also a good thing to inform others about. Both of these are investments (more precisely: risk prevention or risk control) for the future. – Iterator Aug 22 '11 at 23:32
  • @Rook hard figures yeah how about figures for version control or for issue tracker? or, for having a project manager for that matter? You know I can invent how to collect figures for maybe everything (been there done that). But every time doing such data collecting exercise I can't help but wonder if my manager has learned just one bit of software projects mgmt knowledge gained in last 5 or 10 years – gnat Aug 23 '11 at 08:57
  • In any case, selling this as an investment ( a cheap one at that! ) should be helpful. Thanks! – Jack Slingerland Aug 23 '11 at 11:29
5

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.)

Iterator
  • 191
  • 1
  • 6
3

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?

DeadMG
  • 36,902
3

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.

bethlakshmi
  • 7,625
1

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.

Caleb
  • 39,147
  • 8
  • 95
  • 152
0

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.

Jeff Grigg
  • 1,127
  • I also agree because nobody wants to blame anybody during those meetings so it's generally not fruitful. – Christopher Mahan Aug 23 '11 at 00: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 Aug 23 '11 at 01:53
  • I believe retrospectives is another name of post mortem meeting. – Rudy Aug 23 '11 at 10:14
0

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.

mattnz
  • 21,362