This quote stands for itself. If you can’t make your statement / issue / requirement clear to somebody outside your organization (or department); you probably don’t understand the basics or root cause of it.
Check if you can answer one of these questions adequately and precisely:
- why is it needed,
- why it needs to be fixed,
- what is the desired behavior,
- what purpose does it serve.
I’ll again use the traditional versus Scrum approach to make my point. In traditional way-of-working it’s common practice to:
- describe the “project” needs and requirements in one big document,
- intertwine business language and technical language in the analysis documents,
- not give clear reasons why ALL these requirements are needed,
- only very rarely do a prioritization of what is more important and what is less important (even not in “must have”, “should have”; “nice to have” indication).
As a consequence it’s very difficult for the project team or business owner to present the project functionalities in a simple, clear way for an external audience.
Again Scrum (or Agile in broader sense) comes to the rescue. Agile methods actually invite you to chop up your project or issue into pieces. Manageable pieces that you can explain clearly and for which you can tell easily why it’s needed, how you’ll benefit from it, and what the desired behavior should be. Scrum the Product Backlog is an alternative to the requirements document.
Via the Product Backlog:
- The product owner can make a simple list of all his requirements.
- He states What he wants; for What reason; and How he sees that his need can be fulfilled.
- He can indicate the (unique) priority of each story, so that he clearly shows the importance of each story.
- And if he wants he can even enter the business value of each story to indicate the ROI or benefits he expects. (This is already quite advanced, and you’ll need a very senior & apt product owner to make this work).
- The team can then assess these stories to give you an estimation (in ideal mandays / story points / …) in order to derive an initial cost for each story.
And with this information you’ll be able to explain very clearly what your project is about. You just sort your backlog on priority or ROI (benefit – cost) and in order of importance you tell people:
“I want this, because of that; it will be us these benefits, and costs this much. After this one, I want this, because of that …”
And at the end:
“These are all the items we should actually NOT develop because the costs outweigh the expected benefits.”
Thanks to your product backlog you have a proper understanding of your project / problem, and it helps you to explain it very clearly and simple. Next time you find yourself struggling to explain any of these what, why, how dimensions of your requirement, ask yourself the critical question: “If I can't explain it simply, did I understand it well enough.