How would you like a toolkit of guidelines and templates at your finger tips and ready to apply in your next business analysis effort?
It would be insanely useful!
But often business analysts find themselves in situations with no predefined set of tools, and none readily available.
So I’m going to show you what you need to do to create a custom set of tools and templates.
But firstly…
What’s in a Business Analysis Toolkit?
The toolkit contains several documents describing the instructions and guidelines to carry out your analysis work. These documents may be templates for deliverables such as a business requirements specification or they may just describe what you need to do.
I’m in favour of well written templates because they can be used for:
- producing the actual deliverables, i.e., in document or spreadsheet formats, or
- as guidelines for work produced in other programs and formats, i.e., if you are using a repository for developing models and requirements.
The tools in your toolkit will largely depend on the type of task you’re carrying out. For example, if you’re defining requirements for a straight forward custom built solution, your toolkit may contain the templates, guidelines or instructions for producing the following outputs:
- Business Analysis Approach Document
- Business Requirements
- Business Case
- Current Business Processes
- “To be” Business Processes
- Stakeholder Requirements
- System Use Cases
- Functional Requirements
- Class Diagrams
- Non-functional Requirements
The contents of your toolkit will vary according to your purpose, the level of detail required, and the methodologies used within your organisation or your client’s organisation.
2 Things You Must Know to Create Your Business Analysis Toolkit
There are two things that you must understand to develop your toolkit.
1. Type of Project (e.g., COTS, custom software, BPI)
Understanding the type of project, the problem you are solving, or the solution you are delivering will inform the types of tools in your toolkit.
For example, you may be:
- documenting business processes to enhance business efficiencies,
- developing requirements for a custom built software, or
- implementing a commercial off the shelf software (COTS).
Your project will require different activities and outputs. For example, a COTS implementation typically does not require detailed functional requirements, but does require configuration requirements. The purpose of a COTS implementation is to minimise new customisations and leverage the functionality that it already has to offer. Therefore, the requirements are based on configuring existing functionality to fit the goals of the business, not defining new features.
2. Methodology (e.g., Agile, Waterfall)
The software development and project management methodologies used within your organisation, or your client’s organisation, informs the level of detail and the timing of project outputs.
To start with, consider whether your organisation has adopted an Agile or Waterfall approach for software development.
An Agile approach advocates working software over comprehensive documentation. Models and documents are created that are just barely good enough and are refined collaboratively during the iterative cycles of the software development process. Your tools will need to be readily accessible throughout the project lifecycle and support a level of detail that is just good enough.
The Waterfall approach is sequential in nature. It requires considerable time spent in the early stages of a project developing detailed requirements and designs. This comprehensive documentation usually requires formal sign off before the next stage of the project can commence. Your tools will need to support high detail in the early stages of the project.
Another consideration is your organisation’s project management practices. Do you need to provide input into the project management process? Or are you also the project manager? What types of documents are required? When do you need to produce them?
When you have established the type of project, and the methodologies used within your organisation, you can go to the next step of putting your toolkit together.
Putting Your Business Analysis Toolkit Together
There are three steps to building your business analysis toolkit.
Step 1. List the activities to be undertaken
In Step 1 identify and list the activities for the type of project or problem being solved. A good place to start is to look at previous project plans and the activities that were described in them. Make sure there is enough detail to identify specific outputs for each activity.
Step 2. Describe the deliverables needed for each activity
In Step 2 list the types of outputs that will be produced for each activity identified in Step 1. There may be none or many outputs for each task. These outputs will determine the types of tools you will need in Step 3.
Step 3. Identify the tools required for each deliverable
Finally, identify the tools and templates that will support the deliverables identified in Step 2. Keep the selection of tools simple. Attempting to use unfamiliar or complex tools because they look like they will achieve great results is not a good to reason to use them. You may find yourself overburdened with unnecessary analysis. To start with, stay with what you know and add new tools to your toolkit gradually.
Here is a very simple example of a toolkit for a business process improvement project.
Step 1:
Activity: Develop project plan or terms of reference
Deliverable(s): Project Terms of Reference
Tool/Template(s): Project TOR
Step 2:
Activity: Organise workshops
Deliverable(s): List of stakeholders, Workshop schedule
Tool/Template(s): Stakeholder Map, Meeting Schedule
Step 3:
Activity: Review existing documentation and processes
Deliverable(s): Business / Problem Domain Statement
Tool/Template(s): Business Domain Model, Problem Statement, Project Objectives, Business Drivers
Step 4:
Activity: Conduct “as is” process workshop
Deliverable(s): As Is Business Process Map
Tool/Template(s): As Is Process Template
Step 5:
Activity: Conduct “to be” process workshop
Deliverable(s): To Be Business Process Map
Tool/Template(s): To Be Process Template
Step 6:
Activity: Develop business requirements
Deliverable(s): Business Requirements Document
Tool/Template(s): Business Requirements Document Template
Step 7:
Activity: Write business case for change
Deliverable(s): Business Case Document
Tool/Template(s): Business Case Template
Business analysts are problem solvers. What we do for our clients we can also do for ourselves. We can use the very same problem-solving capabilities to make our own processes and systems more efficient and streamlined. This includes developing a toolkit of resources that can be applied to various projects. And over time, these resources will evolve and mature with experience, skills and knowledge.