Whether you’re recommending a case for change to decision makers or delivering a functional specification to a technical team, your documents must contain value for your audience.
Value may come in the form of:
- Clearly describing a problem and recommending a solution that is aligned with the organisation’s needs,
- Assisting decision makers with the best approach moving forward by helping them understand costs and benefits,
- Succinctly describing the characteristics of a solution (whether it be a new system, a process change or something else), or
- Assisting an organisation with managing change or continuous improvement.
It’s my opinion that there’s no right or wrong way of communicating value as long as you know what you need to communicate and why.
Your documentation may be written according to a best practice framework and your diagrams may follow the UML specification to the letter. However, if your stakeholders cannot interpret and visualise the solution you’re describing, your documentation is ineffective. And will contain significantly less value than the document that doesn’t follow best practice but effectively expresses the intended message.
The delivery and presentation of your documentation is one opportunity to demonstrate the value of a project, and your value to a project. Your value is frequently demonstrated in how well you have understood a problem and aligned it with a solution.
Throughout the lifecycle of a project, you have the opportunity to deliver value at every step of the way. Just ask yourself “What’s of value here? What’s really important? Why is it important?” And at every point, try to express these important things as clearly as possible. Do this through all channels of communication including your documentation to make clear and powerful statements about how a problem can be solved.