So you’re the hardworking techie who’s just been promoted to project manager. Congratulations and all that, of course, but I’m sure you realise that your new job has very little to do with your old one. Chalk and cheese or caramel and chilli are comparisons that come to mind.
“What’s that you say? You didn’t know?”
You shake your head. “They didn’t tell me,” you reply.
“Well, of course they didn’t,” I respond, and rush back home to continue this piece…
The transition from a techie to a project manager can be a difficult one. The biggest and hardest adjustment is this: project managers are responsible for a whole lot of stuff that they don’t do themselves. The best way to explain what I mean is through my own experience.
As a project manager I’m responsible for the success of a project although I’m not directly involved in the nuts-and-bolts of its implementation. I depend on the team for the latter. In effect, as far as technical work is concerned, I’m Dr. Do-little – I do very little (if any) coding or design.
So what do I do? The facetious answer is: I manage projects. To most people who don’t know what project managers do, this sounds like a Very Important Job. One in which I get to order people around, tell them what needs to be done and by when. The reality, as all experienced PMs know, couldn’t be more different. The following paragraphs should serve to illustrate just how so.
A lot of my time and effort is spent in ensuring that others can do their work unimpeded by obstacles of any kind – political, physical, communication-related or whatever. (Ah, I see that look of disbelief on your face now – but believe you me, it’s true.) Some examples of this include: following up with vendors; making sure that a developer has the stuff he needs to proceed with cutting code; resolving misunderstandings between developers or between developers and users, and so on.
Another aspect of a PM’s job is negotiation. Sometimes it seems that I spend entire days negotiating – with team members (cajoling… no pleading… with them to get the module finished by Friday, as they’d promised) or with vendors (to try and get them to ship the hardware that was to have arrived yesterday) etc.
Finally, because I’ll be the first one out of the door if the project fails, it is in my interest to ensure things are on track. Here too, things aren’t black and white (or even red, amber and green as those wonderful traffic light status reports show) – they’re in several hundred fine shades of gray. A task can be late but still be under control. Even more paradoxically, it could be early but getting out of control. There’s way more to keeping projects on track than is detailed in status reports. You have to have an eye out for potential trouble, or project banana skins as I’ve called them in an earlier piece. For example, a task could have finished early because the developer wanted to finish it up before resigning – things are about to spin out of control and you’re not yet aware of it.
I may be Dr. Do-little in that I don’t cut code or do design. And although I don’t to a Very Important Job, I do a reasonably important one. Without my efforts, the project may well fail. So, to the novice project manager I say: welcome to the infuriating and frustrating world of project management. Remember, in the end – when your projects are successful – it can also be very rewarding.