I have been working as a project/programme/portfolio manager for almost all of my career and it has been some time since I was asked for project management reference material. The question got me thinking about what a project manager’s role really is right now and I don’t have a single simple answer.

Traditional answer

The basics

Most people would say that a project manager is someone who looks after the plan, risk and issues log, runs status meetings and updates the status report. All of these are true but what is the best way to approach them?

There are three main recognised bodies that are responsible for traditional project management methods. Each has its own reference work which will give you lots of information about what a project manager does:

• The PRINCE 2 guidelines, originally developed by the UK government but now privately owned
• The Project Management Institute’s (PMI’s) Project Management Body of Knowledge (PMBOK)
• The APM Body of Knowledge (BoK)

You can find training providers who will take you through the material and offer you exams and certificates. In my experience you do not need any of these qualifications to work as a project manager—I don’t know of project managers in my industry [ref]Financial Services[/ref] being prevented from getting a job because they didn’t have a certificate. Having said that, the background knowledge of basic ‘classic’ project management is very useful. I did my training through an in-house course at a previous firm that didn’t result in a recognised qualification and supplemented my learning by reading a book called ‘How to Run Successful Projects III’ by Fergus O’Connell which gave me enough of the basics to get going.

You need to know about the following no matter what ‘flavour’ of traditional project management you pick:

• The theory behind planning, particularly
  • Work breakdown structures (WBS) (tasks, durations, dependencies, dependency types)
  • What a critical path is
  • Resource assignments and levelling
  • Advanced concepts such as earned value management (EVM) and critical chain (at least know that they exist, even if you don’t use them)
• Managing risks, issues, assumptions and dependencies
• Managing scope
• Managing your finances
• Reporting

In addition, there was a good blog post that I used to recommend to people called ‘How to be a project manager. For free. Starting today.’ which gives a few useful pointers as to how to behave and act like a project manager.[ref]It’s disappeared now but the link takes you to an archived snapshot of the page.[/ref]

At the firm where I work our project managers need to make sure that they are familiar with our programme and project lifecycle and are using the most up-to-date templates for their work. Speak to somebody at your firm to find out what they use.

What experience gives you

You can (and should) read all of the material you want; however, there is no substitute for getting on with managing a project and striving to do the best job that you can. The amount you will learn from just being a project manager and doing the work is immense. You do need the theory, but just like learning to drive you need to try and put it into practice to really build your skills.

Over time I have come to the belief that the best project managers are usually the pessimists in the room. I don’t mean that they always look downbeat, but that they tend to never sit back when things are going well and are always thinking about what could go wrong to derail the project. The developers on the team are usually optimistic (“That shouldn’t take us long at all!”) and it is the project manager’s job to be pessimistic (“What about all of the other work on your plate? What about the fact we need to check the design with the architecture team?” Etc.) On more than one occasion I have had people tell me that “project management is basically risk management” and I think that this is what they mean. I would agree that anticipating things that can go wrong and moving obstacles out of the way so that the team can get on and do the work they have committed to should be the vast majority of a project manager’s day-to-day job.

As you manage more projects you get a deeper understanding of the situations when certain tools are useful. More importantly you get to realise when to put them down. I remember using Microsoft Project for the first time and coming up with an extremely granular plan of some 1,500 tasks which read more like a to-do list (‘Jim is going to be working on this item for two hours exactly 26 days from now’). I spent days and nights with a nagging doubt that I just wasn’t doing it right; I almost constantly needed to change the plan when people inevitably found themselves blocked and just did something else on the list instead. Microsoft Project is extremely useful and you are well-advised to become familiar with it, but over time experience will tell you when to put it down and focus on the delivery as opposed to the plan.

There are such things as bad project plans (tasks that start ‘in mid air’ without predecessors, dependencies being linked to summary tasks, people being assigned to summary tasks, tasks at too granular a level to be useful) and good project plans (every task except for the first one has a dependency on tasks before it, ‘leveling delay’ has been used to move tasks where there is a resource clash etc.) There aren’t too many books out there that go into the detail about what makes a ‘good’ and ‘robust’ project plan but I highly recommend ‘Dynamic Scheduling’ by Eric Uyttewaal—it’s out of print but you should be able to pick up a cheap second hand copy.

As you get called on to manage more projects you will inevitably find yourself walking into situations where your job is to try to structure order out of chaos. Time and again I have found teams where each person feels that they know what they are doing and how they are contributing to the project but in actual fact they are moving in different directions. Your job is to get everybody together and write down what the project is trying to accomplish, what defines it being ‘done’, what assumptions have been made, what is in scope and out of scope, and play it back to the team (including the project executive or sponsor) so that they can debate it and come to a common agreement.

In many ways your job as a project manager is to act as a ‘mirror’ to the team and senior stakeholders about how things are. Staying up all night fretting about an inbound dependency making your project late won’t help anybody, and it won’t make the task get done any sooner. Your job is to try to anticipate the problem, think laterally about how to solve it to reduce its impact on the work and to let people know what is going on.

I always tell project managers to remember that you cannot actually make anybody do anything—other people are always outside of your control, even those who report into you. You only have influence on what they do and therefore on the project eventually being completed.

Business teams have a reputation for adding scope to the work you are doing. Your job is not necessarily to resist this, especially if it means that the project will deliver something more aligned to what the business needs. However, it is absolutely your job to tell the team what the impact of the additional scope will be (‘mirror’ the impact back to them) so that they can make an informed decision on what should be done.

One of my ex-colleagues, Susanne Madsen, has written a couple of useful books (1, 2) on learning to develop your leadership qualities as opposed to your technical skill. I would recommend this as something to focus on once you feel like you have got to grips with the basics in the section above.

What I would say today

Today I think you need to know ‘all of the above’ as well as getting yourself familiar with agile and lean tools and methods. In 2008 I was fortunate enough to be invited to a presentation by Dean Leffingwell who was promoting his latest book on scaling agile within large enterprises. It was a complete lightbulb moment for me—agile felt as though it was scratching a vast number of the itches I had with the traditional methods that we had been using. I am completely convinced that for a large amount of what we do—delivering unique software products against a backdrop of changing requirements—agile and lean methods are more appropriate than traditional project management.

I find that Agile has a very poor reputation within both the Technology and business teams. It seems as though a lot of people have had a lot of bad experiences with project groups that have said that they are ‘agile’ and then proceeded to mismanage the work. I try to avoid talking about Agile with a capital ‘A’ and instead focus on the things that both agile and lean methods brings to the table, all of which have value:

• Breaking the work into smaller chunks so that we can:
  • Deliver something of value to the customer/client sooner (a ‘minimum viable product‘ in the first instance)
  • Get early feedback as to whether we are going in the right direction (“I don’t know exactly what I want, but I’ll know it when I see it”)
• Work out where the pain points are with our delivery process and improve them
  • We can’t release every two weeks because testing takes too long? Automate our testing.
  • We spend too much time integrating all of the code changes and ironing out the defects? Use continuous delivery tools.
  • Estimate the work, measure the speed at which we are getting through it and look at how we can improve our estimates and/or our velocity.
• Avoid having projects that are ‘green’ until they go red at the last minute and fail (a phenomenon known as ‘carrying watermelons‘—green on the outside and red in the middle)
  • Don’t rely on guesses/approximations of whether we are on track, look at the evidence of what we have delivered and use this to forecast how long the remaining work will take. Show this using burnup charts and other visual techniques such as demonstrations.
• Avoid getting through 80% of the work quickly and the remaining 20% taking us well beyond the planned end date
  • Tackle the hardest known problems first
  • Use an economic framework such as ‘Cost of Delay divided by duration‘ (CD3) to work out which of our planned items has the highest business value with the quickest payoff and prioritise that

There are a number of agile and lean methodologies that you should become familiar with. Training courses and certifications are available for these as well:

• Agile
  • Scrum
  • DSDM Atern
  • Extreme Programming (XP)
• Lean
• Kanban

When digging into these you will notice that the ‘project manager’ role is typically not present. For example, Scrum has a role of ‘Scrum Master’ but this is not exactly the same thing. This does not mean that the project manager is redundant. I recently went to a Q&A session with Kelly Waters who proposed that a project manager covers multiple teams whereas a Scrum Master works within a specific team; project managers do the higher-level release planning and coordination.

Agile teams are usually 6–10 people focused around a particular system or product. Scaled frameworks have been developed which take elements of all of the above and adjust them to work across different agile teams and even the entire enterprise. Again, you can study the literature and earn qualifications in these:

• Scaled Agile Framework (SAFe)
  • Large Scale Scrum (LeSS)
  • Disciplined Agile Delivery (DAD)

What I will probably say in the future

Agile and the various scaled agile approaches are striking in that they focus around a specific product. This is different to how we currently do it, where we focus around a budget (sometimes known as ‘budget-driven development’). This can cause problems where projects are approved that need to make changes to a variety of different systems, each of which are already undergoing changes for a number of other funded projects. Beyond Budgeting looks to address some of the failings of this approach.

The #noprojects movement is very interesting in that it says that the whole concept of a project is inappropriate a for software/product development. The key reasons are:

• Projects work to proxies that are set at the start—schedule, budget and scope. This assumes that the value of the entirety of the project is knowable at the start and that there is no value in flexibility. If you have worked on any project before you will know that the world changes around you and so do your requirements; a project could be ‘green’ for schedule, budget and scope as they were initially defined but could actually be delivering something sub-optimal.
• Projects should be reimagined as streams of value (which might stop one day); don’t ask when the software will be done but instead ask when the software will next deliver value. Focus on the benefits achieved and how recently and often they have been delivered by the team. Address the underlying problems with delivering value on a regular basis. Break the problem into smaller chunks and flow work across the team instead of having them work on a big monolithic project.
• A projects is by definition a temporary endeavour. Project teams come together and spend time ‘storming’, ‘norming’ and ‘forming’ before they get to the ‘performing’ stage and then at the end of the project they disband, taking knowledge, capability and performance with them. Software delivered by the project lives on and requires continuous changes in response to new business requirements, defect fixes, security patches etc.

I really buy into this way of thinking. However, it is completely disruptive to how things are set up now with annual budget cycles, project business cases and budgets divided up into ‘run the firm’ and ‘change the firm’. Will this be the reality one day?

Further reading

There are a couple of fantastic books that I have picked up recently which are well worth your time. They cover a lot of concepts that relate to the ‘now’ and ‘future’ thinking above:

• Lean Enterprise by Jez Humble, Joanne Molesky and Barry O’Reilly: This book brings together many of the lean and agile concepts mentioned above and presents them as a coherent whole. I have never been as excited by a business book as this one and wish that everyone I work with had read it. The concepts are extremely compelling and make great sense; this is something for everyone in the organisation to get familiar with.
• The Principles of Product Development Flow by Donald Reinertsen: For ‘product’ read ‘software’ or anything else that we produce which is unique and not mass-produced. The text is extremely heavy-going and dense but contains a lot of information, presented as 175 ‘principles’ in the categories of economics, queuing, variability, batch size, work-in-process constraints, flow control, fast feedback and decentralisation. Having read it once I know that it deserves re-reading to further deepen my understanding. If anyone else has read it I’d be glad to hear from you so that we can explore the topics together!