in Workplace

why does project management suck so badly?

Today I’m going to write about why project managers are almost universally loathed by technical staff. Let me begin with a Dilbert cartoon which illustrates the sentiment:

Sadly, my experience in the technology sector has only reinforced my negative perception of project management. In this essay, I’m going to describe those negative experiences, explain what I think are the pre-requisites for project management to not suck, and then conclude on a bit of a downer by explaining why I don’t think those pre-requisites are likely to be fulfilled any time soon.

As I said, my experience with project managers has generally been very poor. I have had to work with project managers who:

  • had little-to-no experience in software development or IT;
  • were unclear about who the real clients were;
  • failed to act as a representative of the project team, rather than as an agent of the client;
  • failed to place enough importance upon the business analysis, and/or failed to separate the PM role from the business analyst role;
  • showed disdain or open contempt for the technical staff, particularly when the schedule slipped;
  • unilaterally imposed project schedules upon developers in order to “meet the budget” or some other artificial factor having little to do with technical success or code quality

To be frank, poor project management contributed greatly to my decision to get out of software development, particularly in a technical leadership role. Who wants to come to work every day to be hammered by a project manager because the project is over budget, or line items 15-18 are a day late, or the client is asking for a bunch of new features that the PM readily agreed to without consulting anyone?

Keeping all this in mind, I think there are a number of pre-requisites that need to be fulfilled for project management not to suck, and they are as follows:

  1. Functional management needs to clearly define metrics for project success that are coincident with the technical staff’s success metrics. It is no good to have the primary success metric of a project be “was it delivered under budget?” because the technical staff could care less about the budget; the staff want to deliver a working product that is architected well, easy to maintain, has high quality, etc. This requires functional managers to show a certain level of understanding and respect for the technical staff.
  2. Project managers need to be informed that their primary responsibility is to the project team, and that the success of the project is directly related to how satisfied the project team is. The project manager’s job is to advocate on behalf of the team and the organization, not the client.
  3. Risk management must be conducted early and often, and the project manager must genuinely and diligently take ownership of risk mitigation. The entire team should be involved in at least one session of risk gathering, but the team must not be the target of finger-pointing if a risk does come to fruition.
  4. The scope of the project must be clearly and neutrally defined as soon as possible. By “neutrally” I mean that the project manager should not also do the business analysis. The business analysis and requirements document should ideally be produced by a separate business analyst, or failing that, the technical lead.
  5. Any deviation from the agreed-upon scope must result in a change request; no exceptions. The project manager must not agree to accept a change request without obtaining team buy-in.
  6. While the project manager should own the project schedule, the line items on the schedule must be created in close consultation with the technical lead. However, the project manager must have enough knowledge about the domain that he/she understands the meaning of each line.
  7. When something on the project is not going well, the project manager must resist the temptation to hammer the technical staff about the problem. The best thing the project manager can do during a crisis is to stay out of the way and let those people who are fixing the problem do their jobs. At this time the project manager should also keep the client as far away from the technical staff as possible!

Unfortunately, I have to admit that I don’t think any of this will be forthcoming any time soon. The reasons are as follows:

  1. Functional management does not see the need to hire technically-qualified staff to be project managers.
  2. PMP certification is frequently seen as a substitution for real-world project successes, whereas in fact PMP candidates are supposed to have real-world PM experience prior to taking the exam.
  3. Technical staff still rank low on the food chain behind functional managers and the PMs. PMs are seen by functional managers to be “more like them than like the developers”, whereas it’s the developers who do most of the grunt work, solving difficult technical problems to meet client needs.

Sadly, I think that massive software projects will continue to fail as a result of poor project management, and I am certain that the high turnover of software developers and elevated burnout rates of talented developers within the IT sector is also a direct result of poor project management. I welcome your comments.

Write a Comment


  1. Gotta admit that the generalization of PM's pretty much is dead on.

    On the other hand being between a rock (management) and a hard place (client) is never fun.

    PMP's have this evil tendency to fall back on PMP documented processes and forget about the human factor. The basics like "ask the team for input" are human factor that are almost never taught in classes for PMP (or technical management for that matter). It comes down to experience.

    Unlike most people who interview to hire PM's I get nervous when I hear the words process and documentation. Repeated too many times it becomes a mantra and that should be a warning. I like to hear words like culture and consultation and review and checkpoint.

  2. Well the basic problem with project mgmt is that you're forced to play the middle with no real power, i.e. lazy programmer who is the only one that can do x task is MIA and causes massive scope creep. Recourse? … Yeah, you can't fire him or even threaten to fire him, you can't elevate this to upper management because they hired you to make problems like this go away, even though they gave you no real power.

    No instead you relegated to working around the bad apples, and worse, covering up for mistakes. Perhaps the best weapon to move a problem child along his path to the exit door is to find a stellar replacement, and then point out to his teammates via "questions" how much work he's throwing on their shoulders. Playing one developer against another with subtle cross dependencies can work wonders to get the inside scope on what's really happening, and if you're lucky, it will be something resembling plain English. "I wonder why Larry didn't … strange, well hopefully you can bang this out or we're really screwed."

    Then there's the certification cults. Agile development – it even makes coffee! Yeah right, it's like we'll work on everything piecemeal, talk about it like we're in a 12 step program, and torture ourselves with talking everything to death. The piecemeal approach means that the project becomes even more abstract for a PM to follow, and he's basically forced to ride along and try to turn the peas in a pod accomplishments into understandable progress reports for his superiors and their clients. Questioning Agile is like questioning someone's religion, don't go there, but you can hold them to the initial requirements and a schedule. Let them spout about decentralized workflows and iterations all they want – hopefully they bought the cassette tapes and videos too. This PM certification racket is a joke too, it literally reminds of Verisign in the old days – how much will a company pay for gif that say "Trust Me!" … ?

    The other huge reason being a PM sucks is that it's basically job limbo. Where do you go? Nobody sees you, the only things you can do to promote your self-worth is to give numbing Gantt chart presentations (that don't really make sense with Agile). Best bet look for a door, any opportunity and run for it. The developers won't miss you because they think you're a water boy anyway, and the upper managers can be handed a nice status report and task list that they'll just hand off to some other sucker.

    • What can I say but that it's pointless to hire project managers and not give them any authority. I don't mean hire-fire authority; I mean enough credibility and clout to convince functional managers to deal with their poorly performing staff.

  3. That is the main problem, everywhere I have worked, PM assume that everyone works for them. They manage projects not people! and until that is drilled in to their heads, their head will continue to expand!

  4. I’ve been a PMP for 10+ years. I’m no longer a fan because companies don’t understand why they’re hiring a PMP certified person (when most of the time they don’t need to), they set up ridiculous infrastructure requirements, mandate useless documentation, and put processes over people. See my full blog.

  5. Just went to the Global Scrum Gathering conference, and the disdain for project managers was not only palpable, it was open. Most popular solution: get rid of them. If you are agile, and you break down work into small enough pieces in short enough iterations, people can project manage their own stuff.

  6. Couldn’t agree more.

    I’m a developer currently working on a very complex site. I’m not a junior but I’m not the most senior in the company either and this is by far the most technically challenging project we’ve ever done. I don’t really know why I’ve been put in charge of it to be honest. Anyway, my PM literally does nothing but forward emails to me from the client. I’ve taken to just cutting him out and talking to client directly because things keep getting lost in translation. He’s incapable of talking to the client without saying “I’ll have to ask the developer.” and when he doesn’t ask me, it’s usually something that is technically unfeasible that i have to end up doing. The project is quite frankly doomed. I’m quitting soon but have been put in charge of other developers who are now asking me all the questions instead of the PM. The worst part is he gets paid far more than me.

    It’s been the case with all the PM’s I’ve worked with except one, who is an ex developer. I can’t wait for the day I leave and I will only ever work in software again if it doesn’t involve working for other people with no technical experience. Otherwise I’m becoming a fisherman or a farmer or something

  7. As a PM that grew up in development, I agree with your assessment. I’ve been a pm for almost 20 years (yeah, I’m old).

    I got PMP certified 6 years ago. Why? Because some shops won’t look at you without it.

    I also don’t think things will change, unfortunately.