Avoid 'he said, she said' post-project reviews

Post-project reviews can easily degenerate into blame sessions if you don't set the right tone. Formalizing the gripe process and acting on feedback will keep your teams on an even keel.

Try not to think of a post-project review as a postmortem, even though you might sometimes feel like putting past efforts six feet under. It’s important to avoid destructive conflict and keep post-implementations constructive, especially when the “he said, she said” accusations start to fly. How do you prevent these heated discussions from poisoning the relationship between the development and business teams? Two of the best strategies are to formalize the project retrospective process and to act quickly on feedback.

Formalize the retrospective
One of the main challenges to formalizing the project review process is to prevent the meeting from degenerating into a free-for-all. One way to do this is to set the tone of the meeting by leading off with a series of questions, such as:
  • Was the business stakeholder’s intended vision made clear to you? If not, was it due to a lack of understanding on your part or that of the stakeholder?
  • Did the requested new features allow for a design that didn’t conflict with previous versions of the product?
  • Did you have time to prove your design via prototyping before the coding began?
  • How often did the requirements change after you began coding?
  • What would you change about the process of requirement definition if you could?
  • Was the project leader available when you needed help?
  • Did the project leader assign work in manageable and organized increments?
  • Was your work conducted in an atmosphere of anticipated success or pressure to meet deadlines at all costs?

Encourage open and honest answers, and be ready to take some punches. Take copious notes, and document any issues that are raised. If meeting together isn’t possible, ask your team and representatives from the business side to respond via e-mail.

More on griping employees
If you want to pick up some more advice on how to channel gripes constructively, then read "Griping employees? Teach them to do it right."

Keep the responses in context
After organizing the responses to these questions, review them in the context of software creation in the real world. This will help you weed out team members who were just griping for the sake of griping, like a developer who complains that the coding requirement changes. Well, that’s a fact of life in software development. Coding requirements change because business drivers don’t know what they want until they see the first version in operation, or because business needs shift rapidly. Development must take these changes in stride. Some other examples to consider in context are:
  • Version 2 often breaks the design of Version 1 unless you start with an architecture that is constructed for change.
  • Programmers always think they can figure out the requirements better than the business analyst because they consider themselves experts at what looks right on the screen.
  • Project leaders will often take a negative motivational approach toward the team because it’s an easy way to manage—if not the most effective way.

Act on the feedback
Winston Churchill said that the further we look back, the better we can see ahead. This is the motivating force behind conducting a project retrospective. You’ll notice that the questions suggested for a review meeting anticipate the typical problems we face each day in bringing successful software to market within budget and on time. Our industry is infamous for using the standard equilateral triangle approach toward the business units. It typically goes like this: You can have the product (1) fast, (2) cheap, or (3) correct—pick only two of these three.

The goal of a retrospective is to break this triangulated approach to development. It’s possible to build correct code fast when you’ve learned from your mistakes and apply the lessons to future projects.

Learn and move on
The goal of learning from the post-implementation retrospective is to avoid the common communication problem typical of such project reviews. If you don’t want to be doomed to repeat unprofitable project experiences, let history be your guide to tomorrow. Looking back is sometimes the best way to see the future.

Editor's Picks

Free Newsletters, In your Inbox