Making It Easier for Doug and Tony
by Lidor Wyssocky

Tunnel_smallWhen I was a child, one of my favorite TV shows was The Time Tunnel. The concept of being able to go back in time and try to fix the things that went wrong fascinated me. Wouldn’t it be wonderful if someone from the future could come back and fix whatever it is we did wrong?

Maybe you are one of those lucky people who have a project-postmortem meeting at the end of his projects. If you don’t have them, you really should, but that’s not the topic of this post. The thing is that a project postmortem cannot change the past. The best you can hope for is to learn for the future.

I once attended a project’s postmortem meeting in which the developers claimed that the system’s architect had given them an inconsistent and incomplete interface definition for the component they were supposed to write. Now, since a postmortem meeting (which is sometimes referred to as a lessons learned meeting) should result in some lessons, it was decided that in future projects the architect should pay closer attention to details, and the interface definition should be reviewed. Wow! What a lesson. Too bad we didn’t know that before delivery was delayed.

Had someone delivered the same input during the project, there’s a good chance the problem could have been addressed in real time. There’s no sense waiting with such an observation until the project is already over.

Tunnel2Now, if you are one of those lucky people who have project-postmortem meetings, you might also be lucky enough to have project-status meetings on regular basis. The problem with the term “status meeting” is that it often sets the mindset of the participants: it’s all about understanding the status of the project, isn’t it? But as long as you have frequent status meetings with all the project stakeholders and contributors, you might as well use them for more than just reporting status.

A project status meeting is a great opportunity not only to report the status but also to analyze it, to understand its source, and to learn from it for the rest of the project. There are so many issues that can be addressed during the project and thus prevent unnecessary stress or even failure. Addressing these issues in real time is certainly better than waiting for Doug and Tony to fix them later.

So, in your next status meeting try doing the following:

1. Don’t settle for a dry status report. Encourage everyone to identify the things that shaped the current reality. The discussion should not be limited only to problems. If there are no particular problems, you should certainly try to figure out what caused everyone to do well. The project log can help you analyze the path that led you to where you are.

2.  Communicate your findings openly. It’s not about blaming anyone — it’s about learning. There’s just no sense in postponing the learning process to the end of the project. For a professional development team, learning is an ongoing process that never stops.

3. Record and publish your findings. It will take you exactly five minutes to record your findings and make them available for your colleagues to learn from. You can use a simple Wiki to record such real-time lessons.

4. Do it frequently. If you don’t have frequent status meetings, it’s about time you had. If you’re status meetings are done on the daily basis (for example, in the form of standup meetings), going through this analysis process in each and every meeting is probably too much. The best thing is to do this “mini on the fly lessons learned” activity on a weekly or bi-weekly basis. And it shouldn’t be too long either. If your team is in the right mindset, if all the participants are communicating openly and honestly, and with the help of a project log, you can come up with extremely useful conclusions in no time.

And finally, when you do have a project’s postmortem meeting, remind everyone the single most important universal lesson: next time, don’t wait until the end of the project to learn and improve.

Share this post:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • BlinkList
  • Reddit
  • digg
  • NewsVine
  • blogmarks
  • Furl
  • Netvouz
  • Spurl
  • YahooMyWeb

Optimize Your Software Development

See how I can help you develop software more effectively

3 Responses to “Making It Easier for Doug and Tony”

  1. Mitchell Silverman Says:

    Gee - that’s not how I do it.

    I wait until the projet post-mortem - carefully write up what we should have done, then get in my time machine and and drop the project assement on my desk at project inception. This leads to very clean designs and very accurate design docs. We avoid a lot of bugs this way too.

  2. lb Says:

    Top work!! Love it!

    One team i was on used to do a ’swot’ analysis along the way, to identify “strengths weaknesses opportunities threats” — this was a nice way to achieve a similar result.

    i’ve always found it hard to convince people to do a ‘post mortem’ maybe because the name has such grisly connotations. the benefit isn’t implied by the name — death is implied. ’swot’ is an easier concept to sell to people.

    love your graphics on this article.
    cheers
    lb

  3. Lidor Wyssocky Says:

    Thanks for the feedback lb.

    I agree, postmortem does sound somewhat gloomy. Maybe this term is so common in the software industry because many projects in fact require a postmortem ;)

    Lidor

Leave a Reply