Why the project model is difficult to operate when delivering value in software development.
At Friday we’ve recently renamed our project managers ‘delivery managers’. The change is not solely nominative: it reflects our underlying thinking about the nature of projects and the very essence of what we do for our clients.
Friday’s raison d’etre is to help companies survive and thrive through digital transformation. Sometimes that is pure consultancy, but more often than not it means building new digital platforms — i.e. making software.
The projects we undertake are sizeable: the roll-out of 52 new multi-language websites for a global bank; and a new consumer-facing healthcare website unifying hospitals, gyms, physio, and health assessments, to name two. They often have big budgets, big teams and run for more than a year.
But like many other organisations, we’ve found that the big project approach and the optimum environment for building software are in conflict.
No project
The NoProject movement, spearheaded by Allan Kelly and Steve Smith, has written widely about this conflict, so we know we’re not alone in thinking this way.
In traditional projects, a successful project manager brings projects in on time, on budget and with all the features listed in the statement of work (SoW). He sticks to the plan. He manages away uncertainty.
If things slip, he barks milestone deadlines at the team in the guise of ‘governance’. If the client’s requirements vary, he renegotiates the SoW and creates project plan v1.1, and so on.
However, as Kelly writes, budget, time and features are merely proxies for the value the client wants. They are often arbitrary constructs created by the SoW. Until such time as clients can define a perfect set of requirements for what they want at the outset, change will occur during the project.
Conventional project management was designed to deliver infrastructure — literally concrete assets like bridges and roads. It assumes manufacturing-style economies of scale apply: the larger the batch, the cheaper each feature will be.
But building software works in reverse — it has diseconomies of scale — small batches are more efficient because they reduce the risk. Each small batch can be evaluated for its contribution to the overall goal of delivering the value the client wants.
No end in sight
And that highlights another disjunct between conventional project management and the continuous nature of software product delivery: projects assume an end-date. The bridge is built, a local dignitary cuts a red tape with a giant pair of scissors to light applause, and heavy traffic starts to flow.
Does that sound like software? Of course not. Unlike a bridge, software has the capability to evolve at the pace of user need, to adapt to changing requirements for value. Rather than attempting to manage away uncertainty, software exploits it.
Software that isn’t changing isn’t being used. Software that changes continuously delivers value.
That doesn’t mean we don’t have deadlines. We review value delivered to date and ask when the team will next deliver value that contributes to the overall goal. But we don’t cram for an end-date. We don’t cut quality to achieve an arbitrary deadline. Features can be traded off against time and budget, but quality — delivering value — cannot. Cutting quality builds technical debt that has to be paid off in the future.
What now?
Whether the project model is broken for software development isn’t in question: greater minds than mine have already declared it so and their reasoning is sound. Rather, the question is: what do we do instead?
The C-suite will be comfortable with an approach based on value-delivery, at the level of outcomes, not outputs. But how does this approach fit with the business infrastructure that has grown around conventional project management, such as procurement, detailed SoWs and contractual terms and conditions, signed off by a legal department?
We’ve made the shift from project manager to delivery manager to reflect the changed nature of the work. But the business infrastructure of most clients is still in project mentality, and our focus now is on gently taking our clients with us.
Nevertheless, our thinking is still evolving. Anyone who says they’ve nailed it forever is not being truthful and certainly missing the point. We still refer to big client projects as ‘projects’ because that’s the language our clients are familiar with.
But what we mean when we say ‘project’ has changed fundamentally to mean product delivery, or — to put it into business language — value delivery.
Is this an issue on your radar? We’d love to hear what you think or how you’re dealing with it.