Completing a Project

February 18, 2007 by
Filed under: Process, Project management, Teamwork 

For some, a project is done when the task they have been working on has been completed to their satisfaction. Their work is tossed over the wall to someone else, at least until it is tossed back to them.

For others, completion means that the product has been built and is running well enough to ship. Or at least that date on the calendar has arrived.

Others recognize the surrounding collateral, whether it is sales or training materials, a deployment engagement, packaging, or a variety of other items that need to be put together to support the product itself. Completion isn’t done until the whole product is in the customer’s hands.

Still others are aware of the remainder of the lifecycle past these points, where the customer may find defects, request upgrades, or ask for more of the product.

Truly wise teams know that completion comprises all of these elements, and more. A project is not completed until the team has put it to bed properly, with a retrospective of the project. More than a session to complain about the problems that are finally done (for now), a retrospective is the best opportunity for the team to learn from their experience and prevent all these problems from happening to them again next time around.

Few project teams consistently run effective retrospectives. For most, the term post-mortem may actually be a more accurate assessment of the project outcome, but even in medical post-mortems, there is something that has been learned at the end of the day. An effective retrospective is one where the team follows through with changes to their behavior for the next project cycle.

Usually, though, teams will stop short of this goal. Whether they don’t take the time (as they are already late on their new project from of delays on the project they just completed), or simply don’t recognize or understand the value or approach of an effective review of what just transpired, they are missing a huge opportunity for improvement.

For a retrospective to work well, all participants need to participate with an attitude that they are looking for ways to get better, not to expose anyone for blame on the project. It is all about the group learning from its mistakes and reinforcing its strengths. With that in mind, it is almost essential for a strong moderator to drive the event in all but the most disciplined of teams.

Good project teams will start the proceedings off with a review of the measures of the project. Original expectations of schedule, scope, cost and quality, compared to how the project actually played out. Known drivers for any of the major discrepancies are identified and discussed, and everyone has an equal voice.

It can be quite useful for everyone to know that a retrospective is coming as a project commences, so they can collect information throughout the lifecycle that may be relevant at the end. Perhaps it is a key feature that is taken in late in the game and disrupts the architecture, maybe a team member that goes well beyond the call of duty at one point. Both the good and the bad, collecting them along the way is far easier than trying to recall these events after the battle is over.

Another way of building the group memory is to build a timeline of the project on the wall, where everyone can add different colored post-its to represent different perspectives. Visible cues of high and low points, surprises and other key elements can help the team recognize when things started to sway from the happy path.

A good facilitator can effectively bring out the voice of those that tend to sit back and watch the parade go by. Everyone should have a chance to identify the things that worked well on the project, and the things that didn’t go so well. For particularly challenging projects where people quit during the project or the client is particularly dissatisfied, bringing these parties in for participation can add tremendous value – and regain some of the lost alignment.

Even if all this is done, though, the value still has yet to been gained. With all this information, the analysis now begins. Usually, most of the issues can be distilled to one or two key root causes, which will lead to specific things that should be changed for the next project cycle, along with practices that have been beneficial and need to be reinforced.

More often than not, these changes will be in the areas of planning, scope definition, change management, or team communication. These areas tend to be where challenges hit most projects, and there’s nothing like tying the shortcomings of the early stages of a project to the pains felt towards the end to bring the point home to the group.

Brought to proper closure in this manner, the team gets an opportunity to dispense with all the grief of that past project, and head into a new project with insights that should make the new experience a far better one. There is no downside to a well run project retrospective. – JB


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    Jim is a true professional. His expertise in software development and project management is outstanding, but perhaps more important is his commitment to his clients and his own personal learning. Working with Jim is a pleasure for me – and will be beneficial for you.

    — Kevin Eikenberry, Owner, The Discian Group