CXO

How to prevent a negative end-of-project meeting

End-of-project meetings can be politically charged and leave a consultant out in the cold. Arm yourself upfront by agreeing with your client counterpart about the goals of the meeting.


Little inspires as much dread in project managers and consultants as the end-of-project meeting. Even though we know these meetings play a vital role in our success, many of us avoid them. Their very importance makes them highly charged events, capable of ruining an otherwise successful engagement. This is another lesson I learned the hard way at the end of a highly successful network deployment project.

My team and I spent several months designing and deploying a new infrastructure expansion for a rapidly growing client. We worked with the client's newly hired IT team throughout the project, and a few client team members were hired in the middle of the deployment. We ran into the usual line-up of problems: messed-up flights, a bad server install, a deployment delayed by a facilities issue that took two weeks to straighten out. We knew the risks going in and planned accordingly, so we ended up two days over time and $1,000 over budget on a six-month/$2M project. Everyone seemed pleased, although a bit hung over from the end-of-project party.

A week later, I walked into the project review meeting expecting a few dings. My team had made a handful of mistakes that I was perfectly willing to point out, including a royally botched job on a router configuration that cost us four hours before it was straightened out. When the first thing out of my client counterpart's mouth was, "XYZ company cost us $500,000 and here is why," I almost fell out of my chair. What followed was three hours of the most instructive and negative project meeting I had ever encountered. Apparently my company, and I in particular, were a group of incompetent ogres, solely responsible for every risk that appeared in the project. My counterpart's team could have executed the project for well under what we charged, with a much higher customer satisfaction rating.

This approach so blindsided me that I didn't even fight back during the meeting itself. Some of my team members, a bit more agile in their thinking, fought back with bitter venom, pointing out that the client IT team didn't even know what a service was, or how to schedule jobs. By the end of the meeting, our two companies decided to "wash their hands of each other."

As we walked out for the final time, I asked my client counterpart what went wrong. He looked at me, shrugged, and said, "It was just business, Shannon. Nothing personal."

A structure built from failure?
After I calmed down a bit, I decided to try to figure out where we went wrong. Obviously, something went awry early in the process—something we failed to account for.

My suspicion immediately focused on our preparations for the meeting itself. Before that event, our teams worked together very well. After it, we would never work together again. It seemed to be such a disjunction that it cried out for an explanation.

If I assumed that my counterpart got what he wanted by crucifying me, what did he achieve? He convinced his executive sponsors, through rhetorical device, that he and his team were the super-competent experts on the project. This affixed the weight of the successful project to his team, ensuring that they would gain further projects. It strengthened his position in the company. He also created a number of expectations about his own performance in the future. Those expectations might come back to haunt him at a later date.

In contrast, my goals for the meeting focused on discussing the project's successes and failures to establish lessons learned. This abstract knowledge-based goal did not hold up well against the personal/political goal of my counterpart. Furthermore, it worked in direct hindrance of his mission, since it implied neither blame nor praise.

Looking more deeply at my counterpart's situation, the origins of his goal became absurdly clear. He and his team were newcomers to the organization, hired to replace a departing IT staff. He had little political credit and less influence. This project touched the lives of over 60 percent of the company in a positive way. He needed that accomplishment if he wanted to get anywhere.

Building for success
So, what happened was just business, but not quite how my counterpart meant it. I assumed that the meeting had a single purpose without considering the other issues inherent in the situation.

Assuming that all end-of-project meetings involve either attempting to gather prestige for success or avoiding the loss of prestige for failure, how can we, as consultants, prepare? Unless we have long-standing positive relationships, we cannot count on our client counterparts not to throw us to the wolves. In fact, it's in their personal, and sometimes professional, best interest to do so.

We can attempt to mitigate this situation by taking several steps:
  1. During the project, agree on the allocation of political gains. Agree beforehand how to allocate success and failure in the project, and slant the status reports to reflect this agreement. If you talk about it openly, most people will agree to a reasonably equal distribution.
  2. During the final phase of the project, agree on what the end-of-project meeting will look like. Establish who will take the political credit for which portions of the project. Also, talk frankly about whether your client needs to sacrifice your consultancy to move forward.
  3. During iterative or phased projects, make sure that credit allocation occurs during the end-of-iteration/phase reviews. This defuses the end-of-project review, allowing the final review to take a more abstract, knowledge-management-oriented tone.

Fast forward
At the start of my next project, I had a closed-door meeting with my client counterpart. We talked frankly about his political situation, what he needed from this project, and how we were going to go about securing it for him. We also addressed my organization's needs. Four months later, the end-of-project meeting ended with him getting a commendation and my company getting an additional follow-up project.

In the first case, I didn't prepare for the political reality of the end-of-project meeting. In the second, I applied the basic rules of social engineering to the situation to ensure a positive result for all involved.

Editor's Picks

Free Newsletters, In your Inbox