It also means that today, I said something that five years ago, I would not have ever imagined would come from my lips: "I need to get this technical work done and out of the way so that I can concentrate on project management."
You see, five years ago, I was in the midst of a career crisis. I had somehow turned into a project manager and I wasn't all that happy about it. I didn't view it as "real" work. It seemed like I spent my days gently (and not so gently) encouraging other people to do their work, and I wondered whether it might not be better if I just rolled up my sleeves and did the work for them.
I have completely changed my tune. My "a ha!" moment was when I joined a project that was in trouble. It was behind schedule, but no one was sure by how much. It was over budget, but no one knew how the spend was trending. And management was threatening to just cancel it. I came on board and had a new schedule in place, with a known budget trend within a month. Roughly 8 months later, management decided to renew the project for another year. The team was happy, and so were the customers for the software the team produced. One of the customers sent me a really nice email (as I went out on maternity leave), complimenting me for turning the project around- and I realized that, yes, I had done that. Project management was indeed "real work".
So now, I am still a bit on the fence about whether or not project management is what I want to do with the rest of my life- a topic for a future blog post or ten, I'm sure- but I am not at all on the fence about whether or not project management is "real work". It is. I fully understand why someone has to set aside some time to keep his or her eye on schedules, dependencies, and communication (intra-team, inter-team, and up to management). In fact, if you are going to tackle multiple projects at once, or even just a single long and complicated project, someone probably has to forgo work doing the hands-on technical and/or scientific work altogether and focus on project management full time. Otherwise, your projects will probably finish late and/or over budget, if they finish at all.
I know that most techies and scientists roll their eyes at project management. I think that is because people try to apply the wrong techniques to their projects. If you are running an agile or agile-like software development project, you don't need the project management techniques that were developed by government contractors to deal with their multi-year projects, which were required by the government to be fully specified before they began. In fact, if you try to graft those techniques onto an agile-ish software development project, you will probably make it fail- or at least make your best programmers quit in search of less annoying pastures. (I actually spent an entire year of my life insulating project teams from overly waterfall-y project management requirements. I learned a lot, but I can't say that I have any desire to repeat the experience.)
Similarly, if you are in the development part of drug research and development, you use a different process than if you are in the early research part of the cycle. This is not to say that I think early research should run with no project management whatsoever- but it should have a much more lightweight process. When I work with a research project (yes, we have these in scientific informatics!), I favor the use of flowcharts and checkpoints over fully specified project timelines- and I don't expect the management of that project to consume anywhere near the amount of time that managing a project that is developing enterprise-level software will consume. When I worked with teams that were heading into the development portion of R&D (and yes, I've done that, too- and that had nothing to do with software!) I expected to be able to write fairly good timelines, because the processes the team would be using were already known, even if the outcomes were not.
All of this makes it hard for me to explain what a project manager does when I get asked about it at the various "alternative career" events I've attended. I guess I can boil the core responsibilities down to these:
- Know the deadline(s) for the project, and what the impact of slipping that deadline will be
- Know which of these three things management would prefer you compromise, and which you think you should compromise, if pushed: schedule, budget, or quality. And yes, sometimes compromising quality really is the correct answer!
- Know the tasks that need to be completed in order to get the project done, and know their interdependencies (i.e., if task A runs late, will that impact tasks B and C?) Know which tasks are done and which are in process.
- Manage team communications. Make sure the team is communicating however is most effective for it- be that with meetings, emails, or IMs. Know that different teams communicate in different ways, and allow- no, facilitate!- that.
- Be the source of project information for senior management, so that they don't go bugging your team. Try to protect your team's time.
- Know and track your budget, to whatever level of detail your organization requires.
- Keep your eye on the hidden administrative tasks that can derail a schedule- like keeping contractor work orders up to date.
- Keep an eye on your team's state of mind and availability. Are they burning out? Are the bored? Who's going on vacation soon? How will that impact the project? Try to fix the problems you see.
I know I have some other project managers amongst my readers. What do you think? Is my list complete? Since I just wrote it off the top of my head in five minutes, I doubt it. Add your items in the comments! Also, for those who are curious about project management- feel free to leave questions. I'll either answer them in the comments or write another post about the topic.
Update: I've written a post with a short list of some project management reading suggestions.