PM Hell

Thursday, December 13, 2007

Every once in a while, I run up against a project manager on a client project who seems to be there just to make my life hell. Usually I just let this roll off me since it’s only a temporary condition — that’s part of why I work as an independent, after all — but sometimes I just have to rant.

To begin with, I usually work on the design side of things, from functional requirements through technical design, and I leave the project management to the trained professionals: not only do I not like doing project management, I’m not very good at it. I think that many companies do a great disservice by "promoting" technical people to project managers by allowing that to be the only pathway for their advancement, rather than creating senior technical positions with the same prestige and pay. What happens in the current model, since so many developers have moved into project management roles, is that the term "project manager" has come to mean someone who also does some amount of the business requirements or design work on a project as well as managing it.

This is just plain wrong.

First of all, if someone is tasked with managing the project, let them manage the project without burdening them with other roles that might be in conflict with their primary role. Second, if someone has been in project management for a while, their technical skills are probably a bit rusty, and you could end up with poor results. Furthermore, many people in project management don’t even have a technical background, but are expected to take on technical project work because of the assumption that they used to be a developer; this is almost always not going to work out well.

The worst case that I experienced was when an ex-COBOL programmer was assigned by his large management consulting employer as a project manager on an implementation project, but he was obviously frustrated by that position and wanting to do technical design. I was the lead architect on the job, but he argued with pretty much every point in the design, even though he had no understanding of the technical development environment, and little understanding of the specific products that we were using (products on which I was very experienced). We spent a lot of time arguing over things, only to end up back where I started in the first place. Since I was a subcontractor to his company, he lobbied to have my contract terminated (which was within their rights, with the appropriate amount of notice) and I breathed a sigh of relief over not having to deal with him any more, as well as not having to go to a very cold part of the country in February. The end result: the architecture and design were redone by the project manager with some input from a couple of the developers who weren’t familiar with the BPMS; the system was installed more than a year late, went way over budget, and didn’t meet the customer requirements. After turfing out the big consulting firm, the customer called me back to see if I could help fix the mess. I laughed all the way to a different customer in a warmer climate.

A more recent PM from hell wanted to completely control my access to the customer. As an independent contractor rather than permanent staff, she may have felt threatened by my existence, and obviously felt she could do my job just as well as I could — without any apparent skills or experience at it. Since I often work offsite and she worked onsite, she was able to convince the customer to funnel every piece of email and documentation that I needed through her, rather than just having the customer copy her on communications to me. There were obviously a lot of conversations (via email) going on that I was not privy to, and which would have made my job easier, but the PM decided to filter the information that went to me. At one point, she even said that she was doing this in order to "watch my back" for me (presumably so that she knew exactly where to stick the knife). At one point I needed a detailed database schema, and the PM replied that what she had was too detailed for me; I suggested that I could make that decision, and to just send it on, but instead, she had someone in the internal IT group run a not-detailed-enough report for me. When I asked for more information, the PM said "This is what we decided was best to send to you." Every interaction that I had with this PM was the same frustrating, teeth-pulling exercise. Although I did a good job for the customer, it could have been better if I’d had wider access to people and information.

I have a huge amount of respect for skilled project managers, but let’s get a few things straight:

  1. I don’t want your job, so don’t feel threatened. I like my job just fine, or I wouldn’t be on the project in the first place.
  2. I don’t care if you want my job, the customer hired me to do it, not you. Do your own damned job.
  3. Don’t create barriers between me and the sources of information that I need in order to do my job, or you will negatively impact the end product and the customer satisfaction.

2 Comments

  1. Frank Hamm says:

    You’r describing situations that very often take place within companies, too. And it’s not only in regard of project managers bot also in regard of line managers. Very often employees get promoted as line managers only because they did a very good job but not also because they are management enabled.

    Seems to me that management often thinks doing a good job on an operational level qualifies for leadership. So maybe the boss knows better programming than his people. But then his people suffer of not beeing leaded but controlled.

    P.S. Hope I could map out my thoughts in my humble English

  2. sandy says:

    Frank, I completely agree — in English, we call that the “Peter Principle”, where someone who is good at something is promoted to a level where they are incompetent. 🙂

    Leadership and management skills are specific skills on their own, and it can’t be assumed that someone has them because they’re good at doing the job that’s being managed.

Leave a Reply