How to Write a Business Analysis Report

So your boss (or client) has asked you to do a full review of a business area before presenting your findings and recommendations?

OR

You’ve completed your investigation and now need to present your findings and recommendations to your stakeholders.

If that sounds like you, then this is the post for you.

Why?

Because today I’m telling you everything you need to know about writing your Business Analysis report.

Including how to CHANGE your presentation or documentation structure depending on your stakeholders.

AND

Giving you ideas on how to present your recommendations so they ALWAYS get accepted.

Start with the end in mind – What are you trying to say in your BA Report?

This is KEY.

A strong Business Analyst will be thinking about their solution recommendations from the very beginning and right throughout any project.

And if your investigation is conducted thoroughly, it won’t be difficult to form an opinion on the best way for the business to move forward effectively.

If you’ve studied business you will know this already, but it’s true for BA’s as well.

So here’s what I would do:

When I get allocated a project, I tend to set up my final presentation meetings at the start of the project.

The benefit:

• I have a clear deadline, which increases my productivity.
• I am able to secure the diaries of extremely busy people – especially managers
• Sometimes I am able to get a whole team into one session because the manager is able to prepare.

By starting with the end in mind, you will have a clear idea of what you want to get out of the presentation.

Sometimes I even go to the extremes of writing down my recommendations FIRST and working backwards from there.

Who are you writing your Business Analysis Report for?

If you’re at the start of the project you need to do your stakeholder analysis.

If you’re presenting and haven’t done one yet – DO IT NOW

Use my article Stakeholder Mapping Tool – How to engage 15 business areas so you can be sure you’ve done it right.

Why should you do one of these?

The main reason is because it will help you identify who are the powerful people that you need to convince

AND

Who are the most project interested people that you need to convince of your findings.

The general rule of thumb:

Powerful people are usually high up and don’t need to hear about the detail of the current issues. No! They want to hear what they need to do to make the company better. So in this situation make sure your focus is mainly on the recommendations and NOT the problems.

However:

Less powerful people that are interested tend to be the team members that your future changes will impact.

SO… in this scenario, they probably want to see if you agree with what they think or know is the problem. Most of the time the problems will have come from those SMEs during the investigation.

So it’s a great opportunity to make them feel listened to by spending a bit more time going through and discussing their problems.

Whether it’s a document or a presentation

You need to bear these people in mind and present your business analysis report in the right way depending who you are presenting to.

HOW will you deliver your business analysis report?

If you’re at the start of the project. Now is a good time to decide how you will present your findings and recommendations to your stakeholders.

Usually one of the below

1. In a document
2. A Presentation
3. Both documentat and presentation

Build up your recommendations throughout the presentations

Have you heard the saying?

• Tell them what you’re going to say
• Tell them
• Then tell them what you said.

That’s the 3 step process to a high impact presentation. And it’s exactly what you should be doing with your findings and recommendations.

How to structure your report

The structure of your report could be the ultimate reason as to why the people you need to convince will take your recommendations.

So here’s the key areas to consider

1.      The intro

Start with a bang.

Explain the background of the project.

For a document report:

You may wish to use BOSCARD (read my BOSCARD article if your response to that is – WHAT?). That’s where you’re terms of reference from the beginning of the project will come in

Make sure you keep it short and sweet. Ask yourself ‘Would I continue reading if I read this intro?”

For a presentation

DON’T use BOSCARD in its entirety.

DO NOT go over more than one page.

Don’t write down in detail on the presentation.

Put bullet points for the project reasons and why you’re standing here today.

2.      Report The approach

You need to get this bit absolutely spot on.

Because there’s a fine line between being BORING and being INFORMATIVE.

Ask yourself – “why am I telling them my approach?”

Well the reason is so that you can get them to understand how you came to your recommendations.

Don’t go to the nth degree of detail – especially if you’re presenting to highly powerful stakeholders just a simple explanation of the steps you took throughout the project.

So what did you do during the project?

Voice of the Employee? To obtain feedback from those that KNOW.

Statistical Analysis? To ensure findings are accurate and logical.

Process Mapping? To gain an understanding.

List the tools AND explain why they are beneficial.

3.      Report the outcome of each technique used

This is where you can begin to slot in your recommendations slowly in order to gauge an early response.

The outcome of each technique you used to gather information will allow you to show in a bit more detail why you are making these recommendations.

DON’T go through your process maps in minute detail.

DO pick out the important aspects of the process map. Remember this isn’t an opportunity to verify that your process knowledge is accurate. You should have already done that. It’s an opportunity to make people aware that you can spot problems within a process.

Use the 7 wastes TIMWOOD rule when reviewing your processes and use these as examples to highlight any issues.

If you undertook feedback workshops with SME’s, it’s always a good idea to explain the outcomes and ‘blue sky ideas’ from those workshops.

DON’T say WHO gave the ideas – you don’t need to.

Why?

Because you don’t know how each of your stakeholders respect each other’s ideas and if one person doesn’t respect another (trust me it happens), you may have lost them before the improvements have even begun.

Instead focus on the ‘why an idea is worth implementing’.

4.      Summarise your findings

There’s 2 opportunities here:

The first is the ability to win round the employees who will be affected by your recommendations.

The second is make business leaders accept the recommendations by the impact of the issues you describe here in your findings.

Keep them short but solid.

And use figures! Nothing tells a better story than the impact of space, time and money. Especially to leaders.

5.      Summarise your recommendations

When writing your summary recommendations, make sure you categorise them.

A good categorisation is by People, Process and System

That way you can clearly explain whether it’s a culture issue or a technology issue.

Remember Culture issues can be very difficult to fix but if done right and fast can be a whole lot cheaper than implementing a system that may not even fix the issue.

You should have already won round your audience by this point.

So all you are trying to do is to tell them what you’ve been telling them for the last hour.

If you’re having difficulty wording your recommendations, download my Business Analyst Report for some inspiration.