We were sitting in a project wash-up meeting discussing how tough the project had been, and how none of us honestly expected it to have the successful outcome that it did. We eventually came to the conclusion that it was all down to the brilliant project manager the agency had put on the project. A couple of beers later – and after all agreeing that we “loved” the PM – we arrived at the realisation that, even though some of the bad digital projects we’ve worked on have had good PMs working on them, none of the great digital projects ever had a bad PM at the helm.

The next day, recalling this conversation, I was thinking about how we could help bad PMs to become great PMs. It had to be more than just Gantt charts and budgets. And it’s definitely more than just saying “yes” to whatever client services, and the client, wants.

This is my conclusion. We teach them what every great PM instinctively knows: how to become masters of understanding consequences.

Sounds simple, doesn’t it? But it’s a sure-fire way of becoming a brilliant PM – especially on digital projects.

Let’s start at the beginning. Anybody who’s watched Grand Designs has heard presenter Kevin McCloud explain how time, quality and money are inextricably linked – that they act as the three main constraints on any project.

This is how Kevin explains it: you’re given the options of fast, good and cheap, and told to pick any two. Here, fast refers to the time required to deliver the product; good is the quality of the final product; and cheap refers to the total cost of designing and building the product. This triangle reflects how the three properties of a project are interrelated, and it’s impossible to optimise all three – one will always suffer. In other words you have three options:

  1. Design something quickly and to a high standard – but it won’t be cheap.
  2. Design something quickly and cheaply – but it won’t be the highest quality.
  3. Design something to a high standard and cheaply – but it’ll take a long time.

This may be good enough for Grand Designs, but it won’t do for a digital software project. Traditionally a software project has the same triangle but with different labels; most PMs would recognise the following as the project management triangle (AKA “triple constraint”).

In this version, scope is one of the constraints replacing quality, which is now part of the project outcome.  The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project’s end result. These three constraints are often competing constraints: increased scope typically means increased time and increased cost; a tight time constraint could mean increased costs and reduced scope; and a tight budget could mean increased time and reduced scope.

To help make brilliant PMs we need to show them that there’s more to a digital project than these three constraints.  And we need a diagram that can show how all the elements that make up a digital project are all interdependent; changes to one will have repercussions on all the others.  In fact, we can borrow from a well-established model like McKinsey’s 7S Framework to show these interdependents. (But without all those esses!)

And this is what it looks like:

The project management triangle is still there, but so are all the other interdependent elements: scope, complexity, integration and the technical stack.

The project manager must understand that to change one element is to change them all. What may seem a small change – not even warranting a formal change request – could have any number of unforeseen consequences. And it’s up to the project manager to be able to articulate this at the point of asking – rather than at some later date when the client thought they had tacit agreement for that change.

It puts me in mind of the proverb “For Want of a Nail”.  The client wants to add a small simple feature (scope); this in turn requires a new JavaScript library (technical stack).  This isn’t a problem, until it turns out the new library doesn’t work in all the required browsers. So, a workaround is required (complexity); this in turn requires more testing (quality).

And all this takes extra time, of which there is not enough, and money, of which there is no more.  What seemed like a simple addition might actually end up putting the entire project at risk.

I’m not saying the PM has to know in every instance how a change request will affect the project, just that it might do so. I do understand that being a digital project manager is one of the hardest jobs in any agency.

And because I understand that having a brilliant PM on a project helps everybody have a more enjoyable time (including creatives, devs, client services and, especially, the client), we’re taking this a stage further. Cohaesus are putting together a short workshop for agency PMs that we hope will help them to help us.

Watch this space.

Author: Quentin Ellis
Main image: sk8geek