What is it?
Document Analysis is one of the core techniques of business analysis and involves the Business Analyst reviewing existing documentation in order to gather/elicit information they need in order to more effectively do their job.
Why do it?
According to the BABOK Guide (v2),
Document analysis is used if the objective is to gather details of existing solutions, including business rules, entities, and attributes.... Other references to documents analysis tend to imply that it is only useful for eliciting requirements. However, I feel that limiting the use of document analysis to
existing solutions or eliciting requirements is selling the technique short. Document analysis can be useful in each of the following scenarios:
Learning the Business
First, document analysis can help the BA learn about a new business unit they are engaging with or a new aspect of a business unit they have already worked with. This is especially valuable if there are no business resources available to the BA (due to time constraints or having left the company) or as a preliminary education effort by the BA before engaging with the business resources. This can involve reviewing:
- Policy and Procedure documents and manuals
- Organization Charts
- Training material for the business unit in question (including employee and system guides)
- Goals and Objectives statements
- Annual reports, regulatory documents, and similar enterprise-level documents (especially if engaging with an entire business rather than just unit)
- Departmental intranets and internal / company web sites
- Annual Reports, websites, news releases of competitors
- Business Plans
- Market Studies
- Project documents for past projects undertaken by this business unit (to get insight into past business priorities, decision makers and influencers, and techniques and processes the business is familiar with)
Learning the Project
A second use for document analysis occurs when a business analyst is first engaging with a project that is already underway or a new project that is an evolution of a past effort. This may involve reviewing the following:
- Vision document
- Business Case
- Project Charter
- RFP’s or RFI’s used for this or related projects
- Cost-Benefit Analysis
- Requirements documents
- Meeting minutes of project team meetings
- Any emails or other communications on the project that are available
- Current Business Process documentation
- Training documentation and assets for the business unit and systems impacted by the project
- Customer complaints or suggestion logs related to the project
- Relevant technical standards
Learning the System
A third use for document analysis occurs when the business analyst needs to learn about an existing system. This most often occurs when the BA is beginning a project to enhance or replace an existing system. In this scenario, the BA may review the following documents:
- Requirements documentation for the current system
- User and system manuals
- System training materials
- System defect reports (even if replacing a system, knowing defects of the current system can help avoid those in the new system)
- User complaint or suggestion logs related to the system
- Competing or Commercial product literature of related systems
- Relevant technical standards
- Forms that provide data that is input to the system (helps identify specific data elements and business rules)
- Forms or other output from the system (combined with the above, helps identify specific data elements and business rules)
How do I do it?
The Document Analysis technique is normally undertaken in three stages. These are:
- Preparation -- This involves:
- Determining what documentation is available
- Determining which of the available documentation is relevant
- Out of the relevant documents, which are the most appropriate for study given the objectives you are trying to achieve (this is especially true if there is a large amount of documentation available).
- Review -- This involves studying the documentation you have chosen as the most relevant in order to:
- Extract information that meets your needs or may be valuable later
- Taking note of questions that the documentation raises so that you can follow-up with SME’s later.
- Look for references to other documentation that you may not have come across in your initial search that may be relevant to your effort.
- Wrap-Up-- This involves:
- Organizing and analyzing the information you extracted from the documents. This may include restating the information in the form of preliminary requirements for later review.
- Following-up on any appropriate document references you came across to continue the document analysis process.
- Review any questions you captured with the appropriate subject-matter experts in order to elicit answers and identify further questions.
There are several risks to using the Document Analysis technique.
The first is that there is an implied assumption that any documentation is up to date. Especially in the case of systems, process, or policy documentation this may not be true. The BA must take care that they determine how up to date any documents they reference are and treat the information obtained with some level of skepticism until it has been confirmed.
The second risk is that document analysis can be extremely time consuming. Just reading the material can take significant time; but extracting, analyzing, structuring, and confirming the information can take even more. There may always be the desire to
just include this one more relevant document into the analysis. If there is sufficient time, this may work. But the lack of time on most projects makes triaging the documentation found in order to assess only the most up to date and relevant a critical step. If there is insufficient time allotted however, do ensure to call that out as a project risk.
Linked Notes and
Dock to Desktop functions of Microsoft OneNote make this a great tool to use when conducting Document Analysis.
- The Guide to the Business Analyst Body of Knowledge (BABOK) v2; Section 9.9 -- Document Analysis; Page169