Determining what documents to deliver on a project is not done in isolation. If you recall from my free eBook, The First Bite, the very first questions I ask when I commence a project include:
- What is required of me?
- Do you have an outcome already in mind?
- What are the expected deliverables?
- In what format do you expect the deliverables to be produced?
The answer to these questions not only provide you with a broad overview of the business activities to be undertaken, but also the type and format of the documents to be produced. As more is understood about the project, the more refined your understanding of those deliverables will be.
Therefore, the questions above are the starting point for understanding the objectives of project. The project objectives inform the documents and deliverables required, and the deliverables inform the type of information you need to gather.
In understanding the objectives of the project, and the things that you need to produce, it’s important to understand these three things.
- The intended “end game” may change as the project progresses. As new information comes to light, the objectives may change and so may the required deliverables.
- The project is not about producing good documents, but adding value to the organisation. The documents just help you deliver that value.
- Documents are not true deliverables. Nor are systems or processes. The true deliverable is the value you bring to the organisation.
Value is the key. How you deliver that value occurs through a variety of mechanisms but it includes your documentation. And your documents must communicate clearly and accurately to your intended audience.
For instance, I’ve read many business cases that lacked a suitable description of how the recommended change would provide value to the organisation. As is frequently the case, the so-called value is written from the perspective of the solution.
For example, the recommended XYZ system will:
- Store data in a central repository
- Provide a single source of truth
- Eliminate duplicate records
- Improve accessibility
These are good benefits, but what is the real value to the organisation? The decision makers need to know but it is not communicated clearly.
The same scenario applies if you were delivering a detailed functional specification. You need to provide the information in a way that the technical team (your audience) can design and implement code with as little re-work as possible. Therefore, they need a suitable description of what the solution will look like and how it will work.
So a document must accurately communicate to the intended audience. And it’s my opinion that there is no right or wrong way of doing this, as long as it communicates its value.