What does a project manager need to know?

One of my colleagues has just moved into a project manager position for the first time and he has asked me for pointers to help him get started. In the spirit of ‘share, don’t send’ I thought I would post something on our internal blog (as well as posting here) instead of just emailing him.

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:

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 1)Financial Services 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:

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.2)It’s disappeared now but the link takes you to an archived snapshot of the page.

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:

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:

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!

 

Notes   [ + ]

1. Financial Services
2. It’s disappeared now but the link takes you to an archived snapshot of the page.

Of project portfolios and an uncertain future

Earlier this week I was fortunate enough to attend the Gartner Project Portfolio Management (PPM) and IT Governance summit. I approached the event with some trepidation—this is my field and it would clearly be useful to be amongst peers and understand what the latest thinking is, but I expected it to be full of vendors voraciously pushing their wares and lots of attendees who were wrestling with nuances of Microsoft Project and getting ‘resources’ to work with the processes they had rolled out. Although there was indeed some of this, 80% of the content over the two days was extremely valuable. Many of the sessions had big overlaps with topics covered in Lean Enterprise, a fantastic book I read earlier this year which has really honed my thinking about the right way to approach IT and product development work within a large organisation.

The final keynote presentation of the day was extremely thought-provoking. Donna Fitzgerald and Robert Handler gave a talk called ‘Gartner Predicts the Future of PPM’ but it was so much more than just a talk about project portfolio management. The key issue is on how fast the world is changing around us and how quickly we will need to adapt. Early on, they quoted Ray Kurzweil in saying that:

“Our intuition about the future is linear. But the reality of information technology is exponential, and that makes a profound difference.”

The basic messages that I took away from the presentation were as follows:

  • Technological advances are exponential (think Moore’s Law, Metcalfe’s law etc.)
  • Anything that can be automated will be automated.
  • Things that yesterday we generally believed were impossible to automate are being automated (e.g. self-driving trucks, textual analytics etc.—this table from this paper was reproduced in the Gartner slide deck)
  • Only the very highest-level cerebral work will be left, to be done by good people who are seasoned experts.
  • Applying this to PPM, classic project management will be a generic skill, versatility of skills will be a necessity and the role of the PM will be to enable the team to get things done and shift obstacles out of the way.

As I sat there in the audience I couldn’t help but drift away from the PPM world and think back to an article I read in Wired magazine fifteen years ago. The article had such a profound effect on me that I can still remember exactly where I was as I read it—on a Northern Line tube train, heading to work one morning. It’s called Why The Future Doesn’t Need Us and is by Bill Joy, then Chief Scientist at and one of the founders of Sun Microsystems.

My main memory of the article was that humans pursue technological and scientific progress for its own sake, because it is in our nature to explore and discover. Out of this could come unintended consequences such as self-replicating nanotechnology that takes over the world in a horrendous ‘grey goo‘ scenario. Over the past fifteen years, this quest for scientific progress has become synonymous in my mind with the quest for continual ‘economic growth‘.

On my way home from the conference, with thoughts from the keynote still fresh in my mind, I decided to re-read the article. Two things surprised and struck me when I did so: (1) first part of the article focused on Joy’s meeting with Kurzweil so the keynote and the article seemed to have a common thread or root and (2) the article didn’t just focus on technology but also economic growth:

“Now, as then, we are creators of new technologies and stars of the imagined future, driven – this time by great financial rewards and global competition – despite the clear dangers, hardly evaluating what it may be like to try to live in a world that is the realistic outcome of what we are creating and imagining.”

“I believe we must find alternative outlets for our creative forces, beyond the culture of perpetual economic growth; this growth has largely been a blessing for several hundred years, but it has not brought us unalloyed happiness, and we must now choose between the pursuit of unrestricted and undirected growth through science and technology and the clear accompanying dangers.”

I tweeted that the keynote had got me “worried about our drive to automation and the unemployed masses” and a friend responded, stating that I should read about the so-called ‘lump of labour fallacy‘.

I did look into this, and found out that this basically says that the following line of thinking is fallacious:

  • There is a finite amount of work to be done.
  • Where work is automated, the overall pool of work is decreased, so the people unemployed by automation will not be able to find new jobs.

The reason it is ‘widely accepted’ as a fallacy is that historically, through technological, economic and societal change there is new work to be done and over time the labour force shifts to having these new skills. Think about the industrial revolution and the jobs that were lost because of the changes and how the population developed new skills over time for new jobs that had previously never existed.

Of the various excellent articles I have read on this, three things make me think that this historically has been a fallacy but may not be in the future:
  1. The speed of technological change. As per the Kurzweil quote at the top of this post, progress is not linear and it is getting faster. The speed of progress means that people may not have time to re-skill within their own lifetime.
  2. If it is true that “Only the very highest-level cerebral work will be left, to be done by good people who are seasoned experts” then how do you become a seasoned expert if there are no lower-level tasks to be done that allow you can learn the ropes? Will your field still be un-automated by the time you get to be a seasoned expert with a couple of decades of experience behind you?
  3. The work to be done may shift and new jobs may be invented, but who is going to do that work? Will it be automated from the get-go?

I think there are genuine reasons to be concerned. Personally, I do not understand how we blindly accept ‘economic growth’ through capitalism as a singular goal that is commonly agreed on as being an aim for a company, a society, a country or humanity. Expanding populations and finite resources surely mean that there are limits to continual ‘growth’. I know that many people much smarter than me must have examined this question and that people can point me towards countless texts where this is considered. What I do understand is that even through something as gigantic as the recent financial crisis we did not come up with anything better than what we have today—even though many great minds were questioning it and reasoning as to where we should go from here—and that while our current configuration is still in place, it is not an option for an organisation to avoid seeking growth in the form of increased revenues and lower costs through technological innovation, automation etc. If you are participating in capitalism and not striving to be the best that you can be then someone else will take your customers and you will be out of business. The pace at which this is happening is accelerating. 50 years ago, the average life expectancy of a Fortune 500 company was 75 years; as of 2014 it was less than 15 years.

I don’t have any conclusions right now. I know that as an individual with a family to look after, a mortgage to pay etc. I am very much an active participant in this process. But as per Bill Joy’s article that I read all those years ago:

“My continuing professional work is on improving the reliability of software. Software is a tool, and as a toolbuilder I must struggle with the uses to which the tools I make are put. I have always believed that making software more reliable, given its many uses, will make the world a safer and better place; if I were to come to believe the opposite, then I would be morally obligated to stop this work. I can now imagine such a day may come.

This all leaves me not angry but at least a bit melancholic. Henceforth, for me, progress will be somewhat bittersweet.”