While you’re waiting for the kick-off meeting to be scheduled, you don’t have to sit idle. This is the time to start your desktop analysis, one of the most underutilised tools in a business analyst’s early project toolkit.
This is the third article in a six-part series on how to start a business analysis project. The previous articles covered what to do on day one and how to schedule and run your kick-off meeting. This article is about how to make the most of the time in between.
What Is a Desktop Analysis?
A desktop analysis is a structured review of existing documentation and systems relevant to the project. The goal is to build as much understanding of the problem domain as you can before your formal stakeholder engagement begins.
It’s research. And done well, it transforms the quality of every conversation that follows.
When you walk into a workshop or interview having already reviewed the organisation’s existing process documentation, business case, and policy framework, your questions are sharper. You’re not asking stakeholders to explain things that are already documented. You’re using the existing material as a foundation and asking them to validate, expand, and correct it. That’s a much more productive use of everyone’s time.
What to Ask For
As soon as you have a point of contact on the project, ask the project manager for access to all relevant existing documentation. The list will vary by project, but typically includes:
- Project plans and charters, which give you the formal scope, timeline, and governance structure for the initiative.
- Business cases, which often contain a wealth of information about the drivers, options considered, and the rationale for the chosen direction.
- Business process documentation, which describes how the organisation currently operates in the areas affected by the project.
- Existing business and system requirements documents from previous initiatives, which can surface requirements that are still relevant and gaps that were never resolved.
- Organisation charts, which help you understand the structure of the teams involved and who reports to whom.
- Policies and legislation, which define the constraints and obligations the project must operate within.
- Strategy documents, business plans, and mission statements, which connect the project to the organisation’s broader purpose and priorities.
If the project involves existing systems, request access to those systems as well. Being able to see how the current technology works, what it does well, and where its limitations are gives you context that documentation alone rarely provides.
How to Work Through It
The volume of documentation you receive can feel overwhelming at first. Don’t try to read everything in equal depth. Scan first to get a sense of what’s there and how relevant each document is, then focus your detailed reading on the material most directly connected to the project scope.
As you work through the documents, look for:
- Business drivers, organisational values, and the criteria by which success will be measured.
- Issues and risks that are currently affecting the organisation in the areas under review.
- Business requirements, including any reporting or information needs that are documented.
- Functional and non-functional system requirements from previous projects that may still be relevant.
- The organisational structure and the key roles involved in the business functions being examined.
- Business processes and the systems that currently support them.
- You don’t need to rewrite every piece of information you find. What you’re building is a working picture of the problem domain, enough to inform your questions and give your stakeholder sessions a solid starting point. For instance, I’ll read existing system requirements documents carefully to understand the work that was done previously, but I won’t reproduce them verbatim. I’m looking for context and gaps, not creating a duplicate record.
Record What You Find
As you work through the documentation, record the relevant information in a format that you can use and refer back to. Modern tools like Confluence, Notion, or Microsoft OneNote work well for this. A well-organised Word document or spreadsheet is equally fine if that’s what your environment supports. Modelling tools like Lucidchart or draw.io are useful if you want to start sketching process flows or organisational structures from what you find.
The goal is to build a working document that captures the key information from each of the areas listed above. This document becomes the starting point for your written requirements and models, and a prompt for discussion in your workshops and interviews.
When you present your initial analysis to stakeholders, they’ll validate and refine what you’ve captured. That dynamic, presenting your understanding and inviting them to correct it, is one of the most effective elicitation techniques available to a BA. It’s much easier for people to respond to something concrete than to answer an open question from scratch.
One Important Caveat
Documentation goes out of date. Processes change, systems are modified, and strategies evolve. Treat everything you find in your desktop analysis as a starting point to be verified, not as ground truth. Note what needs validation and build that into your stakeholder engagement plan.
How Ash Supports Your Desktop Analysis
Once your desktop analysis is underway and you’re building a picture of the project, Ash Virtual BA is a useful thinking partner for organising what you’ve found. You can bring your notes, your brief, or your initial findings into Ash and work through the key categories of information systematically. Ash will help you identify what you have, what’s still missing, and what questions to prioritise in your upcoming stakeholder sessions.
For BAs who encounter unfamiliar terms or concepts in existing documentation, the Ash Glossary provides plain-language definitions with practical examples, free to use at any stage of your work.
Frequently Asked Questions
What if there’s very little existing documentation to review?
It happens, particularly in smaller organisations or for new initiatives that haven’t been formally documented before. In that case, your desktop analysis might be limited to publicly available information about the organisation, its industry, and any relevant regulatory context. The absence of documentation is itself useful information: it tells you that your stakeholder sessions will need to do more of the foundational work, and you should plan accordingly.
How do I handle confidential or sensitive documents?
Treat everything you receive with discretion and handle it according to the organisation’s data governance requirements. If you’re unsure about the sensitivity of a document, ask before sharing it with others. As an analyst you’re often trusted with information that isn’t widely accessible, and protecting that trust matters.
Should I share my desktop analysis findings before the kick-off meeting?
Generally not in full. The kick-off meeting is the right forum to present your initial understanding and invite stakeholders to validate it. Sharing detailed findings too early can anchor the conversation prematurely or create confusion if your reading of the material turns out to be incomplete. Keep your desktop analysis working notes internal until you’re in a position to present them in context.
How long should a desktop analysis take?
It depends on the volume of material and the complexity of the project. For a straightforward engagement, a day or two of focused review may be sufficient. For a complex initiative with extensive existing documentation, it could take a week or more. The practical answer is: do as much as you can in the time available before your first stakeholder sessions, and continue refining your understanding as the project progresses.
What if I find conflicting information in different documents?
Note the conflict and flag it as something to verify with stakeholders. Conflicting documentation is common, particularly in organisations where processes have evolved over time without a corresponding update to the written record. Surfacing these conflicts early is valuable: it identifies areas of ambiguity that need to be resolved before requirements can be finalised.