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.
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.
One thought on “Deliverables for the Sake of Deliverables”
Who knows where to download XRumer 5.0 Palladium?
Help, please. All recommend this program to effectively advertise on the Internet, this is the best program!
Comments are closed.