At first I immediately took the opposing view. Of course deliverables matter! There is no delivery without deliverables. Deliverables are the purpose of the project. Focusing on delivery rather than deliverables seemed to me to be like advising someone to do something for the sake of doing it. On the surface, he seemed to be saying: let’s just do some projects, who cares about what they produce. What nonsense!
I have reflected on this a little longer and realise that the truth lies between the two of us. Well let’s say in a pedantic way I was right, but in the spirit and context of the conversation I was listening to, he was right. My initial response was based onto me deep down clinging onto an older paradigm of project management. His was based on a newer one.
I now realise, I’d missed his point – and it’s an important one.
The shifting face of projects
I have been involved in projects for a long time. I developed as a project manager in the era of massive projects with huge books of requirements. Contrary to popular modern myth, this waterfall era was not a time in which every project failed and nothing got delivered. Lots got delivered. Lots of products, services, operational improvements and so on. However, it did have its challenges, and speed of delivery in the face of changing needs were two of the main ones.
Success was measured in terms of completely fulfilling all those requirements and making sure you delivered 100% of them - or very close to it. Delivery and production of 100% of the deliverables were seen as synonymous concepts. The only tool to change requirements in flight was change control – a very robust, but usually glacially slow and disruptive process.
The view that delivery and complete deliverables were the same, was based on a model that you would not want to change the deliverables once implemented, at least not until the next mega-project completed in a year or two. Value was created through complete sets of feature rich deliverables.
The advent of Agile, and related rapid delivery approaches, has changed this model. Now we know we can improve an existing deliverable in small increments. We start by implementing the minimum viable product, quickly and then incrementally add to it over time. We may end up with a feature rich complex deliverable, but we grab value as we go by actively utilising those incremental deliverables.
Of course, deliverables still matter, but not in the traditional way of being everything. What matters more is the continual flow of delivery, with each delivery contributing something new. This only works, if built into the delivery approach is a mechanism that ensures that each increment of delivery does contribute value. When modern delivery approaches are correctly applied, this should be taken for granted.
So the speaker who triggered my original thought was right. In a way delivery does matter more than deliverables. Or to paraphrase my grandfather – “look after delivery, and the deliverables will look after themselves”.