Deliverables for the Sake of Deliverables

Why does every action need a deliverable?

Alright – there’s documentation. If the goal of a long discussion with somebody is a short list of KPIs, then the ‘deliverable’ ought to be a two page PDF – a cover page, and a short list of KPIs, with footnotes on the exact definitions of what we’re talking about.

Simple.

If I’m talking to 10 stakeholders – do I need to spend 4 hours after each discussion to put together an ‘echo-deliverable’? Or, is it sufficient to parrot back what I heard from the stakeholder what I heard them say? Isn’t that just 40 hours – an entire week of concentrated effort – on a throwaway document?

Moreover, does the echo-deliverable help you get to that two page deliverable – the document that really allows you to go forward with a programme – any sooner? Does it bring you to the wins any sooner?

What do they demonstrate? That people have been heard? Great. But can’t I make them be heard when I’m talking to them?

Installation documentation is important. That’s a vital piece of documentation. But it doesn’t need an accompanying powerpoint deck to explain what it is – right?

Please, before defaulting to creating deliverables for the sake of showing progress – think. Why am I doing this? Why not show progress with progress?

You’ll gain efficiency if you ask the why and focus on the objective.