1: A PM's job is not to manage the project

Sure, a PM wants you to think that is their job, to manage the project. That is their title after all. And that is what they study, especially to get their PMP certification.

A lot of developers don't like PM's, and it is a shame. Probably because they have had bad experiences in the past. PM's are like any technology. They can be used for good or evil.

I am hear to say that while they do manage the budget, and timeline, and lots of other things, that is not their job. Any sound person can use MS Project (or other tools) to do this, and for most projects, do alright. (Don't think I am dismissing these activities, because they are critical as well.)

No, the most important job of a PM is to manage the client. What? Yes, manage the client. The client is the one resource on a project that requires the most care, and is the absolute most critical to the success of the project.

And part of this client management is to manage the expectations of the client. Both of the project process itself and of the project's final deliverables (completed system, or whatever).

It is easy to forget about why a client has hired you to do a project. Sometimes you don't really know what the true drivers for a project are (and you should really find out if you don't know.) You get lost in the details, and technical challenges, and you forget there is this person (or group of people) that have their own expectations for the project. The project team then becomes disconnected from the actual drivers and the client. And I have never seen a success once that has happened; seen plenty of train wrecks, never a success.

These expectations need to be managed. The best way is through communication, which is where a GOOD PM excels. The PM should constantly be finding out what the client's expectations are, and make sure that the project, is in line with them. Sometimes, (maybe more often than I want to admit), the expectations can be a little off kilter. This is where the fine art of expectation therapy comes in. There are only three PM's I know that have done this well, but many do ok at it.

When you find out that there is an issue with the client expectations (unrealistic for example, or they changed because, well, things change), the PM should instantly start working through that. Resetting them correctly, or working with the project team to re-plan the project to stay on track (the new track that is). This is were agile comes in handy. With waterfall, it is harder to get back on track (the old track usually, and then results in more track issues. But that is for another post).

The PM must excel at communication, and truly build a relationship of understanding with the client. There are whole books on how to do that, one blog post, especially from me, isn't going to cover it.

So, the PM tracks budgets, writes conference reports, and processes change control, but that is just paperwork. They are work products to support the business of a project.

The PM has a lot more to offer the client, and the project team. They can end up being a force for good, actually completely bypassing issues a 'run of the mill' PM might run into, and really make the client's experience with the project a great story.

There was one project I was on where a client disconnect happened over and over again. Part of this was due to the PM (who is a fabulous PM in my book) wasn't fully available for the project, part due to the day to day client having their own misunderstandings of what the real drivers were on the part of the executive sponsor, partly due to some global company politics, etc.

The first problem was when we had beautifully executed a visual and technical design for a self service EDI application. We finished on time, had a great result, and felt really good about doing a good job under a great deal of pressure. Now this project, which we were a small small part of had plenty of problems. It was a huge integration project, with a lot of newbies running the show. There were missed timelines (by months), immature use of off shore teams, exasperated executives, and all manner of other problems.

On the last day of the project, we deliver our final deliverables, and are in a great mood. The executive sponsor blows his stack. 'Why did we waste his time with this? When were we going to build it for him?'

It turns out that this giant team, with four chefs who didn't communicate with each other, suddenly told the executive sponsor that the timeline was ok, because not only were we going to design, but also build the front end. This would allow their super team of back end people to really hit the timeline this time. Here was the problem, no one told us, but the sponsor had that as the expectation.

So, our PM rolled up his sleeves, and got to work. Calming people down. Unwinding the ball of yarn that covered the truth. He was able to do this with just the sponsor in the room. He eventually came to realize what was going on. He then signed a contract with us to bust out the front end. Wiring it to the backend was to still be left to the first team, the backend guys.

Because we weren't actually in charge of the project (just brought in to do one aspect), we weren't in a position to avoid this. We were sucker punched by the actual project team.

Because of this, our PM recognized that we had skin in the game, wether we were supposed to or not, so he got completely engaged. When more slings and arrows came our way, he was able to step in and wave it away with the sponsor, and the client.

Years later, this client still calls me on occasion for advice, from a project with my former employer.

While I may have done a good job with the tech on that project, the real superman was the PM; keeping the client and project on the same track, freeing me to build cool stuff that allowed the users to kick ass.

 

Rule 1: A good PM doesn't just manage the project, but manages the client and the cilent's expectations.