Primary Project Manager vs. Contracted Project Manager

Did you know there was a difference in how you should operate if you are contracted as a Project Manager to a client vs. being the Project Manager employed by the same client? A while ago I missed that little dynamic, ran straight into a brick wall, and today I'll share two of the lessons learned.

I've been a Project Manager for nearly 14 years, in the Army, Oil and Gas and IT cultures. At one point I was working with a company as the Project Manager for the software implementation at a very important client. I was new to the company and was hired because the original PM wanted to be a functional lead, and honestly, there was too much work for one person to be both the PM and functional lead. 

I entered the position trying to learn as much as I could about the culture of my employer and the client. As I worked with both, I realized that there was a lot of work necessary to bring things into alignment and resolve some outstanding issues, one of the largest being extended decision points impacting configurations. I was working closely with our team, the client's team, and the client's Project Management Team, but acting largely as I did in the past (although I would believe that several of my previous teams would indicate I had mellowed). 

One particular morning, we had our morning stand-up meeting, and the client's Project Manager (Let's call her Beth, not her real name) wasn't present. Not an issue, the client's Assistant PM and I started the meeting (as we had done before). As the meeting progressed, I identified 2 issues that I thought should be addressed:

1. There was a decision point regarding Fixed Assets and Taxes which impacted configuration of the software and was extending into the foreseeable future. There was no endpoint in sight. 

2. There was a series of notification emails my team had formatted and were awaiting responses from the client's end users to address final tweaks. 

When the first point arrived, I asked the question: "This seems to be extending out. Can we define when we will have a decision made?" 

Apparently, a member of the client team (let's call her Emily, not her real name) took that as an accusation and started to try to defend herself. When I tried to indicate that I understood the complications but wanted to define the timeline and not the decision itself, another member of the client team (Ann, again not the real name) jumped in, providing cover for Emily. 

At this point I decided I needed to change tactics with the team, asking: "I understand the question is difficult. Can we at least define what the next steps are?" to which I received a response from Emily and Ann that was appropriate and I thought the situation resolved for the time being. 

Later in the meeting, the second issue came up, this time Ann was the person coordinating the effort. I asked her "Would it be possible to consolidate the input from the end users so that we can address them all in one cycle, rather than constantly adjusting the notifications?"

Ann's response was a rather terse: "I'll see what I can do."

My response was a simple "Thank you." I let the rest of the meeting pass without incident because I could feel the tension in the room at the time. 

Later that day, Beth came to me about the "difficult" meeting, asking for my side of the story. I was honestly surprised it was worth discussing but shared with her my thoughts, and commented that meetings can be difficult if things need to be decided. I thought I explained myself well, and it was a done issue.

That is until the next week when I was removed from the client project for creating confrontations. This was the first and only time I've ever been removed from a project, and honestly took me a while to figure out what I had done wrong. 

Let me break down the issues:

1. Contracted PM vs. Client PM - I was acting like the Client's PM, pushing for decisions and trying to maintain the project schedule and budget. Sometimes this means being direct to get work to move forward. This created a potential issue of "who's in charge" as well as potential difficulty interacting with the client's team and upper management. 

Don't confuse this. A Project Manager is hired to get a project done on schedule, on budget, and in scope. This means that you aren't always going to be popular and / or liked. But, there is a difference between how a contracted PM working on a client site should work vs. how a PM hired by the client should work. 

This is a bigger issue when there is a Client Project Team with a Project Manager alongside your team, rather than just a set of end users supporting your team's implementation. If there was no client side PM team, but only a client project sponsor, then my actions probably would have been appropriate (depending on the political environment, as defined in item 2), provided I kept the sponsor in the loop. 

2. Loud vs. Quite People - When I first arrived on the project there was a difficult character who no one seemed to get along with. He was the head programmer on the client side and everyone agreed if there was going to be a problem with integration of the teams, it would be him. Can you guess where I focused? 

Unfortunately, he wasn't really a problem. He was just confrontational and interested in getting things right. He lacked people skills but wasn't really a difficulty once you realized you could push back (intelligently) and he would actually appreciate it because it meant that things were being considered / discussed.

The person I should have been watching out for was Ann. She was a quiet woman who felt she needed to be the smartest person on the team and didn't take well to people questioning her decisions / actions. She also was personally placed on the team by the CFO and had direct access to him with or without the client PM's (Beth's) knowledge of the interactions. 

When I work with a team, I typically circle around with everyone to ask how things are going, what they are working on, and if they need anything. If I am confused (which can happen in a highly technical deployment) I ask questions for clarification. What I hadn't realized is that by performing these actions, I was making Ann uncomfortable. She thought I was questioning her abilities and her decision-making process. 

The meeting above must have been the final straw, as I later learned that she had gone to the CFO and said I was creating confrontation within the team. In reality, I was making her uncomfortable and she didn't like it. 

Lessons Learned from this experience:

1. When you are not the primary PM, then you need to behave more like an Assistant PM. Identify issues and provide solutions through the client PM, rather than addressing them directly. Although the Client PM and I had a strong relationship, and I always worked toward her goals, it could easily be seen as a power struggle from within the team or by the end-users, and that is something to be avoided. 

2. Don't just look for the obvious problem. I was concentrating on the loud, outspoken team member but didn't see the political issue lurking in the background. If I had done what I typically do: try to have initial one on one conversations with each member of the team (client and contractor side) outside the work environment to foster stronger relationships and establish expectations, then maybe Ann wouldn't have felt as threatened.

Overall, I feel both of these lessons are the reason I was removed from the project by the client. I hope that you can learn from my missteps, and not fall into the same trap.

Now the question is, should this be a Morey's Law? Or two? And what should I name them?