Business analysis (BA)

Every digital product has to start with business analysis. If it doesn't, you're solving the wrong problem.

What do you actually need?

Before I can do anything, I need to understand what your product needs to do, and what you hope to achieve with it. This means I need to really get my head around your business's goals, pain-points, customers, teams, roles, workflows, products, services and existing systems. Plus I need to understand your constraints; things like budget, migration, security, compliance, performance, scalability and integration.

In practice, we’ll cover a lot of this, at a very high level, before you even engage me — during the scoping phase. A good conversation is all I usually need to provide some quick answers to the three all-important questions:

  1. Can it be done?
  2. Should you buy an off-the-shelf product and integrate it or develop something completely bespoke?
  3. How much will it cost?

So by the time we get to the business analysis phase proper, those decisions have already been made. Business analysis is really about putting meat on the bones of the scope.

Step 1: Your 'as is'

First step is to understand your 'as is' — what things look like now. To do this, I'll ask you a bunch of questions about your operation. I'll probably ask your key subject matter experts a bunch of questions too. Then I'll go away and distil your answers.

Depending on complexity and budget, I may capture the relevant business processes in a workflow diagram, complete with swimlanes, like this:

Excerpt of a business process workflow diagram for a commercial cleaning company

Or I might just summarise things with some notes and whiteboard diagrams like this:

Whiteboard notes from a business analysis session with a commercial cleaning company Whiteboard notes from a business analysis session with a commercial cleaning company

Step 2: Your 'to be'

After that, I'll repeat the process, but this time to capture your 'to be' — an optimised workflow that meets your goals, and those of your users, and will also be achievable with your chosen technology. Put simply: the way you want things to work.

I say "the way you want things to work", but don't worry; you don't have to have a crystal-clear vision. Nor do you have to conceive your future functionality all by yourself. I'll work with you and your key personnel to find out what's most important to everyone, then I'll weave all of those threads into a cohesive future-state plan. This is called 'business process improvement' or BPI.

It's also an iterative process, by its very nature. So no-one has to feel pressured to have all the answers at the outset.

Working alone means way less documentation

If you had a team building your product, rather than a multi-skilled individual, you'd need a lot of up-front documentation, because the people who truly understand your needs aren't the people who end up trying to meet them.

You'd have a dedicated business analyst doing the understanding, perhaps assisted by a product owner or product manager. Then they'd hand off to a team of front-end and back-end developers, UX designers, UI designers and UX writers, who then hand off to a team of testers. It's not always this complicated, but it always involves multiple people.

They may do each step fast and iteratively, thanks to 'Agile', but they'd still require a lot of internal communication and quality checkpoints. They'd have to spend a long time diagramming and documenting every last detail of even the most trivial of your workflows, preparing painstakingly granular 'personas', and writing reams of 'user stories' and acceptance criteria. That's just the cost of working in a big team.

But because I do everything myself, most of this is unnecessary. I don't need to document every understanding to pass on to the build team because I am the build team! So my process is much faster and more organic, and way more cost effective.

This means you can invest most where it's really going to count: in the product itself.

I still cover all bases, though

During our discussions, I'll obviously ask you lots of questions about your users, how they'll use the product, and how you'll judge whether I've delivered what you asked for.

There's just no need for me to go to town documenting it all. I'll take whatever notes I need and maybe record a few conversations, so I'm not relying on memory alone and I can avoid scope-creep, but then I just crack on with it.

So by the time a team would be asking you to review their cartoon personas, I'd already be onto the user experience (UX)!

I've been doing business analysis since 2017

I've been analysing business needs since 2002 but, strictly speaking, I didn't get into 'proper' business analysis until 2017, when I became Customer Experience Director for a software company. Since then, it's been a regular part of every role, including my time as Director of Business Systems and in all my consulting work in digital products and customer experience.

Business analysis 2017 – present

  • Present
    Digital Product ConsultantGlennMurray.com.au
  • 2023 – 2026
    Director of Business SystemsMatthews Cleaning Co
  • 2017 – 2023
    Customer Experience DirectorEaseware Technology

Need help with a digital product?

If you want someone with all the skills necessary to help everywhere you need it, please contact me.

Get in touch