The importance of documents prepared by Business Analysts
To understand what documentation you must produce, you need to understand the type of problem you’re solving.
I’m often asked about business analysis documents and how these deliverables tie in with an approach such as Agile or Waterfall.
As far as documentation is concerned the approach taken influences when, and in how much detail, a document is produced. The document may also have a different name but the goals of the business analyst are the same no matter the methodology used.
The goal of the business analyst is to identify business needs and determine solutions to business problems. The solution may come in many forms but typically involve:
- The implementation of a new system
- Enhancements to an existing system
- Business process improvement
- A new information strategy
- A new policy or strategic plan
- An organisational restructure
- A combination of any of the above
Most commonly, business analysts are involved in the first three.
Understanding the type of project, the problem you’re solving, or the solution you are delivering will inform the types of documentation to be produced.
If you’re procuring an off-the-shelf product, you wouldn’t write detailed descriptions of functions and features of the system. You would, on the other hand, produce business requirements with enough information about how the stakeholders need to interact with the product and for what purpose. These requirements would also include some important qualities of the system (e.g., the system must comply with the organisation’s standard operating environment). A product vendor can then provide a detailed response that aligns with the criteria of the organisation.
Where a custom solution is being implemented, highly specific descriptions of functional and non-functional qualities are necessary. In addition to the initial business requirements, the deliverables could include use cases, a user interface specification and data flow diagrams. These documents must be written with enough detail to hand over to the people who design the system’s technical architecture and write the code.
To understand what documentation you must produce, you need to understand the type of problem you’re solving.
This is your starting point.
Use your documentation to demonstrate real value
The delivery and presentation of your documentation is one opportunity to demonstrate the value of a project, and your value to a project.
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.
Use your documentation to communicate clearly to your audience
Value is the key. How you deliver that value occurs through a variety of mechanisms but it includes your documentation.
Determining what documents to deliver on a project is not done in isolation. If you recall from my 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.
The Business Analyst Template Toolkit
The Business Analyst Template Toolkit, by Laura Brandenberg (CBAP), is not just a bunch of templates containing empty sub-headings!
It is a valuable resource containing 12 fully annotated templates and helpful guidance on how to use them. And for each template, a corresponding work sample shows you what the template will look like when completed.
These business analysis templates will increase your effectiveness as a business analyst by helping you produce better quality and concise deliverables.
The template pack includes:
- Business Process
- Change Request
- Data Feed Specification
- Glossary Template
- Issues List
- Meeting Agenda
- Meeting Notes
- Requirements Development Plan
- Scope Statement
- Use Case Template
- Use Case List
- User Interface Specification
The toolkit comes with instructions on how to apply these business analysis deliverables in each of the three broad phases of a project. These phases are initiation, definition and implementation. And for each phase you – the business analyst – will provide input at varying degrees.
Whether you’re scoping the project requirements in the initiation phase, developing the functional requirements in the definition phase or revising changes during the implementation phase – the Business Analyst Template Toolkit gives you the guidance you need to produce the correct deliverables in each phase.
Even though this template toolkit won’t be the magic bullet that makes your work suddenly exceptional, it will assist you in improving the quality of your work through increased alignment amongst stakeholders.