PMP and IT

PMP/PMI has has turned into one of those things that HR people put on the job description just because they assume it is a de facto standard. It is not. In fact, of all the PMs I have worked with, none of the top 5 are PMPs. Quite a few of the bottom 5, however, are. It is one thing to memorize the PMBOK. It is another thing to understand it. And it is yet another thing to manage a software project within an organization that uses an iterative, agile, spiral, V-model, or really any sort of SDLC that is still viable these days. I know some people claim they use waterfall, but I have yet to even hear of one project involving new development that went along the waterfall route cleanly.

Of course, I am assuming here that the IT organization is not hiring a PM to sit behind a desk with a .mpp file and move colored blocks around on their screen. I am assuming that the PM is also a BA, technically-aware, and at times client-facing. In software – especially custom software – your PM has to be these things. Software is a unique animal. Custom software is yet another.

A PMP is, in my opinion, less useful on a software project than a plain old PM who has also played Scrum Master for a couple weeks, or is familiar with MSF, AUP, RUP, or anything else software-related. I would rather see a PM draw an interative lifecycle for me than list the entirety of the inputs for the Monitoring and Controlling phase. At work, we do work.
I didn’t post this because I do not have my PMP or because I am looking for a job. It just irks me, a bit, because people could see such greater results if they only took the time to understand their situation and the tools available to them. PMP/PMI is great, but it is not software-specific. It has tremendous overhead. It is, in many cases, a paper certification.

If there are software-specific approaches out there (that are proven and are battle-tested), why not consider their influence foremost?

Best,

Josh