Starting Out in Project Management

Although I won’t do a full repeat of my talk at BarCampLondon2, today I wanted to talk a little bit about starting out in Project Management. Most folks don’t start their career as a project manager … they come to it later, having been in an operational role or part of a project team first.

One of the difficulties for a first-time project manager is that being a great project resource (i.e. team member) is what gets you the job as project manager, nine times out of ten. Unfortunately, the characteristics of a great project resource are not necessarily the same as those of a great project manager. Standing out in a project team is about getting more done than your fellow team-mates, knuckling down and “getting on with it”. By definition, this focuses you on the executional level of the project — getting tasks done, once they’ve been assigned to you.

In contrast, being a great project manager requires excellence at all the OTHER parts of the project — planning, communication, dealing with stakeholders, managing risk, seeing the “big picture” and so on. There’s also a big part of project management which is more about management than about the project — your team will function best if they are left in peace to do their work and move the project forward, so making sure they don’t NEED to worry about all those factors is paramount.

In traditional project management, there are a number of stages: Initiation, Planning, Execution, Control and Closure. The crux of my talk last weekend was that the real success or failure of a project is determined in the Initiation, Planning and Closure stages, whereas most of the focus is traditionally on the Execution & Control phases. This is not to say that these are the most time-consuming phases — nor that the Execution & Control are not important! — just that they are the structure that allows for success .. or not.

In my experience, some of the most typical mistakes first-time project managers make are in these stages:

  • INITIATION — not making sure everyone is 100% clear and aligned on the purpose of the project. Realising this later on when the software “doesn’t do what we wanted it to do” or when the savings/value promised are not delivered is much more costly.
  • PLANNING — thinking that the plan, once written down (as thousands of lines in MS Project) will be followed to the letter. Plans are not robust. Task planning is especially fragile. If you spend your time worrying about the fact that task #137 is only 70% complete, then you’re not keeping your eye on the rest of the project.
  • CLOSURE — if you think your project is finished and others don’t, then you have big problems. There are a number of reasons this can happen (probably fodder for another blog post), but the most frequent are either that you haven’t met everyone’s real objectives for the project (see above) or that you haven’t provided for the future of the area you’ve been working on. This leads to the “undead stakeholder” phenomenon that seemed to strike a chord with everyone I mention it to.

So, what can you do if you’re managing a project for the first time? Or even if you’ve already managed your first project and weren’t happy with the results? There are a few things you can do:

  1. Educate yourself. Even though Project Management may not seem as real or worthwhile as development or design, it is still a valid skillset and there is a lot of information out there, notably some great books.
  2. Think back. When you were working on projects, who were the best project managers? Who do you remember fondly? Who do you definitely NOT want to emulate? Learn from their mistakes and adopt their best practices.
  3. Ask around. There are probably other young PMs in your organisation. Maybe you could even meet up and swap horror stories.

UPDATE: I’ve since written a book aimed at those just getting started in project management — have a look at The Principles of Project Management.


  • While I agree with almost all of this, I’ve never liked calling people “project resources” (or for that matter calling personnel departments “human resources”). I know it’s only management geek jargon, but it still strikes me as vaguely dehumanising.

  • Rich, to be honest I have to agree. In my defence, I work in an organisation where people are part of an organisational team first and project teams second … so they are “team members” in one arena and “project resources” in another 😉

  • May I used this post in my teaching? I teach computing at Toongabbie Christian School Sydney Australia. I’d like to be able to print off and produce handouts – giving you credit. Thanks

  • @Roger: Sure, feel free 🙂 If you could let me know via email if it turns out useful I’d appreciate it: blog AT meriwilliams DOT com

  • This article was pretty much a standard introduction to Project Management until you started talking about the mistakes first PMs make, where it really got interesting.

    I am interested in republishing this article on PM Hut, in case you’re OK with this, then please use the “Contact Us” on the PM Hut site and we’ll take it from there.

  • Meri,
    I didn’t know where I could ask this question, so I’m putting it here hoping you will give me your input.
    I’m reading your book on Project Management and I’m about 1/3 of the way through it.
    Here’s my question! In the planning section you talk about a rolling wave approach. You say that you can’t give accurate time estimates beyond 8 weeks which I agree with. But if you have a project that has a ball park time frame of 5 months what do you tell upper management when they want to know first how much is this project going to cost, and during the project, are you on budget.
    Especially if beyond the first 8 weeks the estimates are very rough or broad-based as you have said in your book.
    I really believe your focus is correct concerning the people issues and the real world estimates on time to delivery.
    Do you understand my question? How do you communicate cost and budget to those above you who may consider you arriving on budget as the most important issue?