Hi! Let’s Capture Your Process

A new project. A new analyst. Meet the stakeholders. A round of introductions.

Then, the tricky part – it’s time to start the analysis.

The project manager looks at the business analyst and nods. Take the stage. Go for it. Get those requirements down.

This must the most apprehensive moment for an inexperienced business analyst. You’ve taken the courses, you know, in theory, what to do. You’ve practiced writing user stories or requirement statements. But how do you actually start on a new project?

This is where an easy escape comes to mind: “So, let’s capture your process.” Oh, that’s better. Let’s write down the process steps. Boxes and arrows make a sequence. Just tell me what you do, step by step.

Yes, this definitely feels like progress. It makes sense. At the end of the day, we have a rough process flow and lots of follow-up questions. We can report the progress.

And stakeholders, of course, love talking about their process and complaining about all its pain points. Someone is listening to their woes and writing it all down. All in all, a process flow becomes the icebreaker of a new project.

Then it becomes the greatest resource sinkhole. Everyone is working on a humongous swim lane that wraps around two walls. Experts are called in to clarify obscure exceptional flows. The progress is measured in percent and more time is spent agreeing on the exact percentage. The time allocated to business analysis slips by. The analysis continues without a plan.

---

Once, I joined a project that has already created swim lane diagrams with thousands of objects on them. Every day, a new version needed to be printed in a shop around the corner and protected from the wind while carried back to the office. People crowded around a large table to peer at the boxes. It felt like a lot of progress.

Yet, the project team has never discussed the key question that later became a major gap. Who are the customers? How do we define and keep track of them?

When this structural gap was eventually acknowledged and addressed, the painstakingly detailed process flows were invalidated and required a full revision.

---

Dear Business Analyst:

Process flows are important. At some point during the requirements analysis, you need to understand what processes exist and how they perform so that you can understand what needs to change.

Process flows are also comfortable. Most analysts learnt about them at some point during their training, used them before, or had to create one for their hiring test.

But starting analysis with a process flow rarely works. It’s like starting to build a house by laying the pipes and the cables on the ground, roughly in the place where the foundation is supposed to be dug out.

Without the foundation in place, you are just guessing with the piping. Without the blueprint of the house, you may be using the wrong cables. Without the walls, you may be connecting the pipes in the wrong places.

You need to start business analysis with a plan.

And to have a plan, you need to start with Why. And then ask a few more questions:

Why this project?

Why is a change required?

What is the problem?

What do you need to achieve?

What is the objective?

Who and what is involved?

What organizations?

What parts of the organization?

Who is the customer?

Who are all the players?

What’s the product or service?

What are we selling?

What are we counting?

Remember that a process flow is a behavioural model. It captures how a business system or a collection of business actors behaves to achieve a desired outcome – the goal of a process. First, there must be a reason why the system behaves this way.

When you analyze a new business problem, you need to start by understanding the structure: main business entities, personas, capabilities, products, and services. You need to understand how this particular process fits into the bigger picture, and why is this process needed in the first place.

BABOK Guide, as of this time, includes about fifty business analysis techniques. Process modelling is one of them, but there is more to business analysis than swimlane diagrams.

So if you find yourself in the situation described above, consider starting with these approaches:

• Create a context model: capture the main entities involved.
• Ask what the main use cases are – you may need to create a process flow for each one.
• Discover the terminology – a quick mind map of the main business terms will help direct your discovery process. Even better, create a quick conceptual data model to capture the relationships between main entities. This would have helped to discover the customer entity gap in my story.
• Capture who are the customers of each product and service in scope – you will always have to go back to what benefits the customers.
• Understand what parts of the organization are concerned with the change, what is their role and how they participate in the customer journey.
• Do not leave the main question unanswered: what do you want to achieve with this change?

Once you’ve done this, you will be in a much better position to understand the essential business processes involved. Name them, understand their triggers and outcomes, and how their success is measured.

Equipped with this understanding, you can then investigate, model and analyze each process to the extent that each process is relevant to the business challenge at hand.

For more, check out the Business Analysis Pitfalls series, and learn about other business analysis tools and techniques in the BA Fundamentals webinar videos.  

Contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function.