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.