I’m bringing Project Management back, baby!
In our haste to distance ourselves from all things waterfall, have we lost sight of some key principles?
Humans have been building things for thousands of years. The great pyramid of Geeza, built approximately 4500 years ago is sometimes cited as one of the first examples of a construction project. To take a more modern example, I commute by bus to and from my home city, Auckland New Zealand every morning and evening. Or at least I used to before the whole Covid 19 thing happened! Anyway, a large construction project is happening alongside the bus-way — a separate dedicated bus fly-over is being built.
This kind of project, which will span well over a year, requires a large amount of up-front planning. If a large supporting structure containing many tonnes of concrete is even a few centimeters out of place, this is a problem. In a digital project a missed requirement will mean a re-plan or, worse case, a pivot. In the bus route project we are talking some very large earth moving equipment at the least. It would be an expensive mistake.
Here’s the thing. Heavy-weight planning, a fixed feature set and even heavy duty change control processes make some sense when you’re building a bridge. But they just slow you down when you’re building a website. Because knowledge work is different to physical project work, it follows that our ways of working should be different too. Indeed the Agile movement was sparked largely by a group of technical people who were frustrated at the rigid project management principles being applied to software projects.
That said, the question I want to pose in this blog is:
in our desire to put distance between ourselves as knowledge work professionals, and the ‘old-school’ project management methods, have we lost sight of some key principles traditionally associated with Project Management that are actually really handy when executing any project?
Here are some words, phrases and concepts we may want to think differently about:
Projects
In our enthusiasm to divorce our agile selves from the ‘bad bits’ ’of Project Management we have gone so far that even the word ‘Project’ provokes furrowed brows from ardent agilists. Instead we force the language to about only ‘products’. In this we have rather lost sight of the point. A project, according to the PMI is “a temporary endeavor undertaken to create a unique product, service or result.” We need projects. One of the main reasons we need projects is to create and improve products! I am working with many agile teams working on projects of all different sizes. Yes. Projects.
Project Chartering
Getting key project folks together to make sure everyone is on the same page regarding the outcome we want is a key part of Project Management discipline. Call it a ‘product lift-off’ or ‘big room planning’ if you like — but let’s not lose sight of the need to set a solid foundation for our projects.
Phases
One thing waterfall and agile proponents will agree on is that we need to split the work down into manageable chunks. Project Management has the Work Breakdown Structure and agile has stories. Because we don’t believe in Phases as agile coaches and Scrum masters our instinct is to get a prioritized product backlog built as soon as possible. However this misses the valuable opportunity for us to look at whether there are some things that need to be done before other things. And can these ‘things’ be grouped in some way. I have found that splitting a project into phases is an extremely valuable way to create focus and this approach eliminates a lot of complexity, allowing the team to focus on Phase 1, without the constant noise of Phase 2.
Specifications
By rejecting the concept of heavy specifications up front (which I acknowledge is largely a waste of time in knowledge work) have we gone too far? The act of specifying a piece of work is very valuable. It is a key way in which we learn about the feature we are developing. It is easier and far cheaper to discover a mismatch of understanding when a feature is on paper, than during development. Are there creative, visual ways we can specify the work before we start on it?
Dependencies
In today’s matrixed organizations teams depend on other teams to achieve results. Understanding the web of relationships and how to navigate them is valuable, for any team, on any project.
Design
Because agile frameworks like Scrum don’t specify a ‘design’ meeting, design often becomes seen as a non value-adding activity. But consider the question: which is easier to change, boxes and lines on a design document, or written software? Design is a key and under-appreciated element in today’s knowledge work teams
Risks
Although we don’t want to fixate on the negative, we do want to be conscious of what could derail our project, so we can do our best to foresee and mitigate the unexpected.
Justin Timberlake brought sexy back. Do we need to bring (the good bits) of waterfall Project Management back?
