review project with team, best practices
August 8, 2007 3:35 PM Subscribe
Reviewing a project with team, now that it's over -- best practices?
my colleagues have recently completed a long term (6 month) project. Some of it went ok, some of it was really unreasonably difficult. The project is a success, but the process took a toll.
We're to review how it all went down, in a few days. Does anyone have any ideas about how to do this that won't end up in a constellation of finger-pointing and complaining?
The goal is to make it constructive and help figure out how to do it better next time. At the same time, we have to acknowledge some serious errors made by various folks on the team.
Any suggestions or experience with this?
my colleagues have recently completed a long term (6 month) project. Some of it went ok, some of it was really unreasonably difficult. The project is a success, but the process took a toll.
We're to review how it all went down, in a few days. Does anyone have any ideas about how to do this that won't end up in a constellation of finger-pointing and complaining?
The goal is to make it constructive and help figure out how to do it better next time. At the same time, we have to acknowledge some serious errors made by various folks on the team.
Any suggestions or experience with this?
Oh, I meant to add... the personal 'serious errors made by members of the team' are probably best covered in one-on-one meetings. This saves face for everyone concerned, lessens the probability of a pile-on, and allows you to get to the heart of the matter with as few interpersonal conflicts as possible.
Also, speaking as someone who has made a couple of serious errors, I can practically guarantee that those people know it, and it is eating them up inside. Having that laid bare in front of the entire team is probably not necessary, and might indeed be ultimately self-defeating.
posted by dirtynumbangelboy at 3:49 PM on August 8, 2007
Also, speaking as someone who has made a couple of serious errors, I can practically guarantee that those people know it, and it is eating them up inside. Having that laid bare in front of the entire team is probably not necessary, and might indeed be ultimately self-defeating.
posted by dirtynumbangelboy at 3:49 PM on August 8, 2007
yeah, keep everything passive voice when in the group. congratulations for having the resources to do a post-mortem, though!
posted by rhizome at 4:08 PM on August 8, 2007
posted by rhizome at 4:08 PM on August 8, 2007
I've gone through this exercise at work before, and have found that our folks are most receptive to the process when it's phrased as "Did Wells/Next Times" - what did we do this time that worked really well, and what can we do next time that will improve the process. It seems like a little thing, but all the training/corporate bonding/etc types swear by the phrasing.
posted by ersatzkat at 4:09 PM on August 8, 2007
posted by ersatzkat at 4:09 PM on August 8, 2007
I used to work for an end-user software company and we would do a postmortem after we delivered a release. The postmortem was run by the project manager, and notes were kept and included in the project archive.
The ground rules were very clear: The postmortem was limited to one member per team only, and all teams needed to send one member. Teams reported their comments in turn, to the manager, and there was a little give and take with other teams after they made their "statements". The most important rule was to BE CONSTRUCTIVE! Limit negative comments to the one or two most pressing concerns, things that are likely to reappear on future projects if they are not corrected. Focus on systemic and dynamic problems, not personal interactions. If there were obstacles during the project (and of course there were), frame the discussion in terms of how to solve the problems for future projects.
Our project were also large (typical production cycle of 12+ months), and the postmortems would typically take two hours or so. We did have some very good project managers, and they kept the meetings moving; this is an exercise that depends on the quality of the manager leading it and the goodwill of the participants. It also helped that they served refreshments. The project manager also set reasonable expectations at the beginning of the postmortem: let's record what we did right and where we most need to improve the process.
When the whole thing was finished, the notes were written up, comments were grouped by department, and the whole report was circulated to each team on the project, which had to sign off that they had reviewed them with their extended teams.
It was a good process. It did NOT result in radical changes or solve all problems for all time, but the most annoying things usually got some attention before the next project started.
Good luck!
posted by mosk at 4:11 PM on August 8, 2007
The ground rules were very clear: The postmortem was limited to one member per team only, and all teams needed to send one member. Teams reported their comments in turn, to the manager, and there was a little give and take with other teams after they made their "statements". The most important rule was to BE CONSTRUCTIVE! Limit negative comments to the one or two most pressing concerns, things that are likely to reappear on future projects if they are not corrected. Focus on systemic and dynamic problems, not personal interactions. If there were obstacles during the project (and of course there were), frame the discussion in terms of how to solve the problems for future projects.
Our project were also large (typical production cycle of 12+ months), and the postmortems would typically take two hours or so. We did have some very good project managers, and they kept the meetings moving; this is an exercise that depends on the quality of the manager leading it and the goodwill of the participants. It also helped that they served refreshments. The project manager also set reasonable expectations at the beginning of the postmortem: let's record what we did right and where we most need to improve the process.
When the whole thing was finished, the notes were written up, comments were grouped by department, and the whole report was circulated to each team on the project, which had to sign off that they had reviewed them with their extended teams.
It was a good process. It did NOT result in radical changes or solve all problems for all time, but the most annoying things usually got some attention before the next project started.
Good luck!
posted by mosk at 4:11 PM on August 8, 2007
I'm with ersatzkat there, though the nomenclature I'm familiar with is Wins/Lessons.
(Because--seriously--every lesson is actually a win, if you think about it.)
posted by dirtynumbangelboy at 4:12 PM on August 8, 2007
(Because--seriously--every lesson is actually a win, if you think about it.)
posted by dirtynumbangelboy at 4:12 PM on August 8, 2007
Does anyone have any ideas about how to do this that won't end up in a constellation of finger-pointing and complaining? The goal is to make it constructive and help figure out how to do it better next time.
I think that for it to truly be constructive, that everyone needs to be able to be brutally honest. Yes, this will involve finger pointing, but hopefully over the course of a 6 month project, everyone involved has done at least one thing worthy of being pointed at, either individually or collectively.
Can you anonymously collect data from people (say, everyone throws an envelope into a hat -- inside the envelope is a list of what they think the biggest five Eff-ups of the project were (and why), and perhaps what they wish had happened instead.
Tell them that this is the time not to pull any punches.
Collect these, compile them by paraphrasing and perhaps depersonalizing ("Joe kept breaking the build" becomes "developers broke the build too frequently"), and distribute them. Make no indication on whether any particular answer was popular -- even if poor Joe got 15 complaints, it shouldn't be weighted any more heavily than something that only got mentioned once... yet.
Use this list as a starting point for your middle of the day debrief meeting. Perhaps you want to collectively sort them, deciding which of them are big deals, and which are not big deals, and then come up with good preventative measures to keep the biggest deals from coming up again. Perhaps you want everyone to claim one ("yep, I was guilty of that at least once").
Try to finish the meeting by 3 or 4 in the afternoon, and then give everyone the rest of the day off. If yours is a culture that appreciates happy hour, consider picking up up a couple hours of bar tab immediately after the meeting -- without the boss there. A team who's just spent a few hours picking each other apart will be well served by having a few pints together.
And then (most importantly), once you get back to the office, actually take the steps to prevent these problems in the future projects -- and show the team that you're doing it. If you have this meeting after every project, and the problems aren't changing, then something is broken.
The message here is that every six month long project has its problems and its minor disasters, and if we want to be constructive and avoid repeating them in the future, we need to be able to have a time and place to be up front and honest about our mistakes and shortcomings -- because at the end of the day, we're all in this together.
posted by toxic at 4:23 PM on August 8, 2007
I think that for it to truly be constructive, that everyone needs to be able to be brutally honest. Yes, this will involve finger pointing, but hopefully over the course of a 6 month project, everyone involved has done at least one thing worthy of being pointed at, either individually or collectively.
Can you anonymously collect data from people (say, everyone throws an envelope into a hat -- inside the envelope is a list of what they think the biggest five Eff-ups of the project were (and why), and perhaps what they wish had happened instead.
Tell them that this is the time not to pull any punches.
Collect these, compile them by paraphrasing and perhaps depersonalizing ("Joe kept breaking the build" becomes "developers broke the build too frequently"), and distribute them. Make no indication on whether any particular answer was popular -- even if poor Joe got 15 complaints, it shouldn't be weighted any more heavily than something that only got mentioned once... yet.
Use this list as a starting point for your middle of the day debrief meeting. Perhaps you want to collectively sort them, deciding which of them are big deals, and which are not big deals, and then come up with good preventative measures to keep the biggest deals from coming up again. Perhaps you want everyone to claim one ("yep, I was guilty of that at least once").
Try to finish the meeting by 3 or 4 in the afternoon, and then give everyone the rest of the day off. If yours is a culture that appreciates happy hour, consider picking up up a couple hours of bar tab immediately after the meeting -- without the boss there. A team who's just spent a few hours picking each other apart will be well served by having a few pints together.
And then (most importantly), once you get back to the office, actually take the steps to prevent these problems in the future projects -- and show the team that you're doing it. If you have this meeting after every project, and the problems aren't changing, then something is broken.
The message here is that every six month long project has its problems and its minor disasters, and if we want to be constructive and avoid repeating them in the future, we need to be able to have a time and place to be up front and honest about our mistakes and shortcomings -- because at the end of the day, we're all in this together.
posted by toxic at 4:23 PM on August 8, 2007
Oh, an effective technique I've also seen:
Have each member of the team (as well as praising one other member) honestly talk about one of their own screwups on the project (this will allow them to choose somewhat, to save face) and what they will do next time to ensure it doesn't happen. Again, this needs to be factual, not personal--no "Well next time I won't listen to Joe's stupid ideas."
posted by dirtynumbangelboy at 4:39 PM on August 8, 2007
Have each member of the team (as well as praising one other member) honestly talk about one of their own screwups on the project (this will allow them to choose somewhat, to save face) and what they will do next time to ensure it doesn't happen. Again, this needs to be factual, not personal--no "Well next time I won't listen to Joe's stupid ideas."
posted by dirtynumbangelboy at 4:39 PM on August 8, 2007
Wow, dirtynumbangelboy, you and I must have attended some of the same team-building, construct-a-tower-out-of-office-supplies-with-your-coworkers management seminar thingies. I've actually used the "talk frankly about a screwup in a neutral setting" thing more than once - I've had many people say that, once you do it "out loud" and don't actually, you know, get EATEN or anything, it makes it easier to confront screw-ups earlier in the process, rather than try to hide/frantically cover up/drink yourself into a stupor.
posted by ersatzkat at 5:36 PM on August 8, 2007
posted by ersatzkat at 5:36 PM on August 8, 2007
I dunno, ersatzkat, it just seems like common sense to me. If people are empowered to openly discuss mistakes they have made, they are--as you rightly said--less likely to try and hide them. In fact, they're more likely to be proactive about fixing them.
posted by dirtynumbangelboy at 5:43 PM on August 8, 2007
posted by dirtynumbangelboy at 5:43 PM on August 8, 2007
I just did one of these yesterday. The process:
Have one person as the moderator and another take notes. Go around the room and each person says what they thought went well and what could be improved next time. If time allows, go around the room again.
Here's where post-mortems usually fall apart: you need to make plans on addressing the issues during the post-mortem meeting. It's not enough to just distribute the notes. Assign people to schedule meetings about the problems and make concrete plans to do things differently in the next project because, otherwise, there's no point to having the post-mortem in the first place.
As for it descending into finger-pointing and yelling: if you have a structure to the meeting (going around the room), it won't happen (unless you're in an incredibly dysfunctional environment). Just don't let it be a free-for-all from the get-go ("Does anyone have any feedback on Project X?"), and it'll go fine.
posted by sfkiddo at 7:02 PM on August 8, 2007
Have one person as the moderator and another take notes. Go around the room and each person says what they thought went well and what could be improved next time. If time allows, go around the room again.
Here's where post-mortems usually fall apart: you need to make plans on addressing the issues during the post-mortem meeting. It's not enough to just distribute the notes. Assign people to schedule meetings about the problems and make concrete plans to do things differently in the next project because, otherwise, there's no point to having the post-mortem in the first place.
As for it descending into finger-pointing and yelling: if you have a structure to the meeting (going around the room), it won't happen (unless you're in an incredibly dysfunctional environment). Just don't let it be a free-for-all from the get-go ("Does anyone have any feedback on Project X?"), and it'll go fine.
posted by sfkiddo at 7:02 PM on August 8, 2007
Oh, and I almost forgot: don't just do post-mortems for projects that went badly, do them for all projects.
posted by sfkiddo at 7:08 PM on August 8, 2007
posted by sfkiddo at 7:08 PM on August 8, 2007
This thread is closed to new comments.
So. Have everyone pull together the following:
1) What didn't work. In this format: "Key milestones were not met. Example blah blah." Do not include names--just a factual "This did not happen at this time."
2) How to overcome that in the future. Concrete, constructive suggestions. Again, no names.
3) What did work. Again, no names.
4) Constructive suggestions on how to ensure that continues to happen in the future.
5) What one person did to help the speaker's own portion of the project. "Man, when $name got those TPS reports to me three days early, that really made my life easier because..." (this helps to ensure that everyone gets praise... as the project lead, be ready with something positive that every single person did, to ensure that everyone gets praise. Sure, it's a little touchy-feely--but surely everyone did at least one thing that really helped, yeah?)
Always finish on a high note. And make your expectations clear before the day of the meeting: this is about finding the facts of what didn't work, and how to overcome them in the future. This isn't about individual egos (phrased suitably delicately for your staff, of course).
And then it might well be a good idea to take everyone out for a nice dinner, on the company.
posted by dirtynumbangelboy at 3:47 PM on August 8, 2007