Business analysis in 7 steps

Hello, beginners in business analysis and all who care about the value of work. Learn how to ensure that your initiatives with software or improvements in a company make sense. In 7 steps.

1. What’s the problem? Problem statement

What’s the problem? You would be surprised how many times we tend to solve things not matching the problem we have. Describe the problem very briefly and as concrete as you can. Consult with people having something to do with it. Do they see the problem the same way? Reformulate if needed. Only by knowing the exact problem, you can build a solution and check afterwards, if it helps.

2. What are you going to achieve? Business goal

A business goal should present a value to the organization. And it should be SMART –  especially measurable and time-bounded (those two we tend to forget).

Good examples:

1) Increase income from product X by 20% by the end of 2020.

2) Introduce consistent on-line selling process in all business units by 1-Sep-2020.

3) Reduce expenses of department X by 30% by the end of Q3 2020.

Wrong examples:

1) Develop a system. 

Too vague. Too technical. What is the value for the organization? What if we create a system, but the problem will remain unsolved?

2) Introduce new technology.

What for? What is the value for the organization? What if we introduce a new technology, but the problem will remain unsolved or some new problem will appear?

3) Reduce costs.

Which value will be satisfactory and realistic? 1%? 80%? 1 $? 3 000 000 $?

3. What’s the best way to achieve it? Business case

We tend to jump into the solution which came to our heads first. However, it doesn’t necessarily mean that it was the best one. What’s more – it can be a really poor choice in comparison to other options. We will never know if it remains unchecked.

To create a business case means to think about options. How can we achieve the goal in different way? Maybe we can create the solution by ourselves? But that’s not the only possibility. Maybe we can outsource? Can we minimize the scope first or do we really need the full solution from the beginning? Maybe someone did it already and is selling this as a ready product? Would it be cheaper? Or maybe, after some calculations, it appears that it’s better not to do anything? Which option is the best? 

After taking all of these into consideration there is a higher chance that you will do the right thing.

4. How not to forget about anyone? Stakeholders

Do you remember the frustration when someone forgot to tell you about a change which impacted you or your work? Irritating, huh? So no wonder, that other people get frustrated too, when you forget about them. Let’s minimize the risk, that we will forget people or relevant points of view, by doing a stakeholder analysis.

Who will have an impact on the solution? Who should have something to say in this regard? Whom the solution will impact directly and indirectly? Users, people, who will experience the change, because their way of working alters, or other departments, which will be impacted, e.g. accounting, HR? What about sponsors, regulators, customers? Shouldn’t they have something to say?

There are many techniques to perform stakeholder analysis. Let’s make a use of it.

5. How does it work in reality? Business processes

Before you start to interfere with users way of working or living, you should understand what are you actually changing first.

How activities are performed step by step when looking at people behaviors? Forget about all supporting systems for a moment. Just understand the flow of actions, communication, and responsibilities. When and who performs certain actions? What triggers the process? What is being produced as an outcome of those actions? How people exchange information? What’s next after each step? Can it be simplified somehow?

6. Which conditions the solution has to meet? Functional & Non-Functional requirements

And now is the time for requirements. What do we expect from the solution? Which conditions should be met?

Answer the questions: “what should the system do?”, “which features should it deliver?”, “what behaviors of users should it allow?”. You’ll end with functional requirements. You can capture them as user stories, use cases or in other forms.

Not only features, but also quality plays a major role in solutions. Gather non-functional requirements by answering questions like the following; How the solution should work? On which operating systems, browsers, or devices? How much data should be processed? What’s the expected response time? How long can it be unavailable not to harm people or important business activities?

Again – there are some concrete techniques and knowledge underlying to requirements gathering. Start with simple forms, gather experiences and learn in the mean time how to do it better.

7. How can we deliver value? Priorities, road map, release plan

Are you happy with the long list of requirements? Don’t be. Problems will arise as soon as you drown in too many wishes. The art is to now select the most important things and decide what should be delivered first.

Which requirements must be delivered to recipients that they get real value fast? Which of those can wait? Which are just nice-to-haves? What should be included in the first, second, and following releases? 

Assign priorities. Based on the value, dependencies, risk, etc. Create a road map. Build a shared understanding of the expected delivery of value and timing. Remember to break it into smaller pieces. Deliver often. Gather feedback. Change your plans if it’s more valuable.

Remember about those 7-steps. Let your project or a product make more sense.