Let’s get this straight - I'm not the sort of person who comes to work to crack a whip and tick some boxes.
I'm the first to admit that, despite its usefulness, there really isn’t anything particularly glamorous about a lot of what constitutes project management. What it can aid in people producing is interesting, but the processes themselves left me wanting something more. I think it was sometime in 2007 or 2008 that a few things happened which crystalized my dissatisfaction with aspects of the application of project management and delivery processes.
It's an oversimiplification, but it seemed like the common way project management was done in the design/interactive media was to ask each person in your team to provide an estimate of time/effort and to then hold them to it come hell or highwater.
Then, as now, we were working a range of very changeable projects using some interesting and new technologies. I was worried; if I effectively heaped the responsibility for the risk on the heads of the designers and developers, how on earth could I expect to deliver a project in a way that fostered creative/innovative design and development? Wasn't that what clients came to us for?
Looking for ways to manage projects that made more sense, I googled for something along the lines of ‘project management for design’ with no useful results. If there were useful resources out there for young PMs in creative industries, I couldn’t find them. I kept going like this when somehow I hit on Scott Berkun’s excellent book Making Things Happen. It wasn’t from the perspective of a small creative agency, but it wasn’t far into this book that the seemingly obvious dawned on me: of course my job wasn’t about checking boxes - it was about people, more specifically it was about helping people do what they need to do.
Was a this a thing? What was this called? Agile sounds interesting, what is it?
Agile (rightly or wrongly) seems to be a lot of different things to a lot of different people. Some people may disagree, but I think the wonderful thing about agile processes is that they’re not really anything special; they just a set of tools that work really well together to help deliver projects (it doesn't have to be software). But there is one line in the Agile Manifesto that I come back every now which talks about 'valuing of Individuals and interactions over processes and tools. Again, it’s about people.
Fast forward a few years: I was working somewhere a little larger and I’d been fortunate to use the Scrum1 flavour of Agile across a number of projects, training as a certified Scrum Master, Product Owner and a number of other things. I was managing backlogs, facilitating daily stand-ups, removing any blockers stopping the team progressing. Where things broke down and we decided our processes weren’t right, we talked about them and adapted them to better suit ours needs. I was working with effective and creative teams who had a strong idea of what they were doing, and working with happy clients.
That said, the use of agile/Scrum is by no means a silver bullet, nor does it mean there is no project management - contracts are still drawn up and budgets and milestones tracked – but as far as checking boxes goes, it’s the team that agree the which boxes they’ll check, and who check them off with the clients.
----
1 I’m not sure how different they truly are, but flavours of Scrum came from Scrum.org and ScrumAlliance.org (and quite possibly others) at the time.