Some days I like to be gentle with people. Some days I sit and listen while people explain to me how important the work of a project manager is, how we have changed the business world, and how the present glory barely presages the coming glory of our reign. Perfect portfolios of properly prepared projects proceed purposefully into a paradise. Or something like that.

The reality of a project manager’s life involves a lot more process and a lot less project. Managing risks and performing earned value analysis certainly has its place, but most of our work centers on the simple workaday activities involved with keeping people on track. We build schedules, call meetings, talk with everyone who might be remotely interested in the project’s outcome (and their uncle, just to be safe), then stay up all night with the team while things fall apart. We file reports, oh the reports, and intervene only when the process’ steady hum stutters.

Wait a second. The process? Yes, the process. When we look only at the output, each IT “project” we engage in looks, in fact, suspiciously like a project. We have a unique product created to meet a particular need in a specific context and time. However, having a bunch of product midwives around is not what attracts corporations to the idea of project management. People were producing products long before our profession got off the ground and will be doing so long after PMI, PRINCE, and all the rest vanish into the dust of history. What attracts them is the idea that we can manage a repeatable, measurable ,auditable process by which things mostly happen.

In other words, it’s our ability to manage the process rather than managing the end state which drags otherwise sober leaders into fits of unbridled optimism when they think about project management. It also means that, for the most part, the poor TPM is in for a world of hurt.

Think about it. Technical project managers tend to come from technical backgrounds. We either devolve out of programmers who made the mistake of admitting to having social skills or infrastructure folks who stuck their heads out of their cubes long enough to be seen by management. As technical people, our primary focus was always on the end state – did the product work or not. The use of chewing gum, bailing wire, and duct tape is just considered part of the package. The less time we have, the more of the above three can be found under the surface of any working solution.

Changing from end-state focus to process focus takes a mental leap that only a few technical project managers actually make.  Those that do tend to backslide easily, especially when presented with challenges within their areas of expertise.

Now, if you will excuse me, I have a bunch of poin…er, process documentation that I have to get pulled together.  Right after I fix this little problem with an AD server…