Analyse, Connect, Do!
Getting stuff done is messy. Having a map can help!
Business analysis is complex. There are many tools, methods, and approaches out there. It isn’t surprising: there is a lot going on.
Ever since stumbling into a business analyst role, I found myself needing something more than a library of tools and vague aspirations like “help businesses to do better business”. Criticisms of the Double Diamond aside, at least it helps people to orient themselves in the complexity and to work out where to head next.
We business analysts aren’t so lucky. There’s no agreed-upon approach.
When I started out I read all the articles and the books (I was terrified of failing). But rather than really helping me, they just left me more and more jaded. Nothing I read reflected what I was actually doing IRL.
I worried that I was doing it all wrong.
The truth is that my business analyst role was far messier, more complex, and more chaotic than any of the business analysis processes I read about. Seven-step-process this, five-element-plan that … 🙄 please! I can’t remember a single instance where my BA plan survived reality.
And it wasn’t just one job that was like that. Position after position taught me that being responsive and adaptive is a critical success factor for BA work. And yes, I acknowledge that my obsession with responsive BA work is partially because my entire career is in the delivery space (I sure do love the spot where the the rubber hits the road and shit gets real), but it left me with a dilemma:
It’s one thing to reactively “get stuff done”, but to improve, continuously and consciously, you need to be able to identify patterns by comparing and contrasting outcomes.
You need to understand your own approach.
So I defined mine.
Introducing Analyse, Connect, Do!
This is how I do business analysis work:
The model is fairly self-explanatory. But let’s cover the key parts:
Work moves from problem to solution
Let’s start by mentioning the most important, foundational feature: Work moves through the model from left to right, from problem to solution. Simple, no?
There are three areas of focus
The three broad areas of focus of this model are:
Analyse: All positive outcomes require understanding. To analyse—to examine carefully and comprehend fully—is the fundamental value-add of all business analysis (many of the Jimmy Methods focus on analysis for this reason).
It’s why we call it business analysis rather than business connect or business do.
Connect: The ability to share understanding and gather feedback is the sign of a great business analyst. Connecting is how we get the entire team on the same page.
Do: Neither shared understanding nor a clear path forward is anyone’s true end goal. Outcomes only happen as a result of action. The best business analysts are those who get stuff done. Getting stuff done requires coordination.
☝️ Everything I do as a BA fits into one of these focus areas.
And you need all three to generate value.
-
Without Do (coordination), we aren’t actually generating value, realising benefits, or seeing progress. We also can’t really understand and monitor impacts.
-
Without Connect, we aren’t building shared understanding, we can’t make informed decisions. We aren’t all pulling in the same direction.
-
Without Analyse we don’t know the facts. We haven’t identified a root cause, and we don’t have a good understanding of the issues and impacts.
But do all three and you’re playing a key role in both identifying the right thing and doing the thing right!
It's an iterative process
The ACD model is iterative. One-and-done is for cake baking, not complex business problems.
This feels sort of obvious for agile projects. As an agile BA you’re continually looping back and forth around all three focus areas: Planning is Connecting, writing acceptance criteria is Analysis, talking to subject-matter-experts is Connection (again), UAT is Doing. And so on
But note that even on the most waterfall project of all time, you will still iterate between Connect and Analyse to build, then validate, your requirements. And no matter how awesomely you do your job on this mythical waterfall project, once delivery kicks in, there will be more feedback from build (Do), thus more decisions to be made (Connect), and perhaps even more issues to unpack (Analyse)!
In short, the delivery approach determines how long you spend in each focus area, but does not change that you’ll use all three iteratively.
The process is not (strictly) sequential
I know I know, the model is very loopy.
But life is loopy!
The reason for this isn’t merely aesthetic. The loopiness (that’s a word right?) acknowledges that making progress isn’t always a happy path of step 1, then step 2, then step 3. The model is responsive.
Just because your Analyse work builds understanding does not mean that you’re ready to make a decision. It is far more likely that the feedback you receive during socialisation (Connect) will push you back into Analyse before being able to support a clear direction for Do.
The model separates action from analysis. This is deliberate. It acknowledges that business analysts themselves don’t generate value: value is generated only when decisions grounded in good analysis are executed.
Knowing where you are in the model helps you to identify where you’re going next …
Each focus area has an exit
No matter which focus area you are in, there is an exit that you are chasing: a condition that must be met before moving on.
For Analyse, that condition is understanding. For Connect, it is a decision (or enough feedback to frame up the next piece of analysis work). And for Do, the exit is getting stuff done (or accumulating real-world-data to share).
So those are the segments of the model explained. All makes sense? Yes?
Good! Then let’s talk about the rules of play.
Rules of the game
All great things have rules (potentially extremely unpopular Hannah opinion right there 👀) and so does this model! Well rules, and some guidelines:
- Agreement is required before any action is taken
- Move things to done as quickly as practicable
- Prioritise moving small pieces of work over completing all work possible in one segment (smaller pieces are better)
- Minimise the time spent in analysis (yes really!) to avoid analysis paralysis.
Agreement is required before any action is taken
You’re not permitted to take action without agreement (or at the very least, endorsement). This rule helps to ensure that the right conversations have taken place before committing to a path.
Move things to done as soon as practicable
The aim of the game is not to keep things moving ‘round and ‘round the model. The aim is to close things out. This means focusing on what can be completed rather than on starting new things.
In other words: understanding is vital, but not at the cost of shipping product.
Prioritise moving small pieces of work
To get things moving and keep them moving, smaller really is better! Prioritise moving small pieces of work over completing all possible work in a focus area.
Decompose big things, prioritise the parts, and get moving.
Minimise time spent in analysis
Minimise your time spent in analysis by sharing work in progress and gathering feedback as soon as possible. This one feels super counterintuitive to say as a business analyst (if some analysis is good, surely more is better?), but it is perhaps the most important guideline of them all.
We aren’t optimising for our work as BAs, we are optimising the system. And for the system to be optimised, we need to be sharing insights and understanding that drive informed decisions. The longer we wait to share, the more comprehensive we make our documentation, then the longer the lag before agreement can be established and implementation begun.
Move forward in easily-digestible steps or you’ll never reach that consensus.
This one takes time to hone as knowing when to stop work in a focus area is more art than science.
How visualising my process has helped it
Okay, so now that I’ve explained the model … I guess the question is this:
So what?
For you? Possibly nothing. But for me? It has been revolutionary!
Defining my process is more than an exercise in documentation. By defining it, I reify it, making it palpable and unambiguous. Now, I can see it clearly to optimise it.
Since creating my model, I’ve become far more focused on the two transition points (achieving understanding and making a decision) and much more deliberate about driving towards each.
I’ve found that the more agile, big, and complex you get, the harder it is to strike that balance between surfing the chaos and diving into solid analysis work that brings people together in consensus … all while avoiding the dreaded “BA slow-down”. Being clear about what I’m doing and when has helped tremendously. I’m better at moving things forward, despite the noise.
I’ve also learned that the leaner and meaner you can run the loops, the more rapidly you will get stuff done. Kind of like a big racetrack.
I realise that these are some seriously bold claims for loops and arrows, but I stand by ‘em!
👏 So that’s it: my BAwesome™️ approach to business analysis. You can now email me to tell me how I’m doing it all wrong!
Or mostly right?
Or if you’re interested in knowing a bit more about each focus area, see my approach page. Or if you want to know how I built the model, then see the appendix below 👇 for all the details.
Hey, tell me what you think!
Please do hit me up on Linkedin or by email if you have any feedback! I’m always up for difficult questions, and I’d love to know what you think of this article!
Appendix: the background to the model
How successful our work is correlates directly to the amount of influence that we can bring to bear in our environment. We can have the best tools and modern techniques, and be the smartest person in the room, but without shared understanding and an eye on how to make the thinking real, our work is worthless and will end up unused in a cloud filing cabinet.
Harsh. But true. 😔
This is why “approach” is one of the things that I’m mildly (read: totally) obsessed with. I’m constantly reflecting on the environment that I’m in, how it is different from or or similar to previous environments, and what common patterns I can find. The more that I understand how things work around me, the better I will be at my job. That’s the theory, anyway.
It is safe to say I’ve spent a lot of time thinking about approaches.
And, I’ve spent years studying my own.
The process
To be clear, I didn’t set out to create my own model. I thought for ages that I could adopt/extend/adapt existing models, but it just didn’t work out.
I got furtherest with the Double Diamond. Except, the Double Diamond is just too rigid and linear, which made adapting it to a business analysis approach extremely difficult. The Double Diamond also assumes that the implementer can dictate the overall approach to the project, but that is, in my experience, a very uncommon power for any BA to have.
I realised that any approach or model would have to work within a wide variety of contexts.
So instead of trying to fit into an existing model, I went back to basics.
I analysed all the activities that I perform as a business analyst (this was crowd-sourced with input from other senior BAs – Connect, right?). Activities were themed, categorised, and synthesised, with special focus on the activities that added the most value.
It quickly boiled down to three levels of abstraction – team, project, and organisation – and three areas of focus – analysis, connection, and coordination (doing). Although I’m cheating a little with this retelling: I didn’t actually name them until later.
But I now had groups. Great start, but not the end. I wanted a model that would help me to orient myself – a model that that would help me to answer both “where am I” and “what’s the next step?”
So I did what I do best: I applied business analysis to business analysis.
I took the model to work with me. I starting monitoring what activities I was undertaking and when, how my activities interacted over working days and weeks, and how my work flowed. I found that the level of abstraction was determined by the environment and the current project (it varied between gigs), but, interestingly, that the areas of focus remained stable.
Thus, I discovered the backbone of my model. More, I realised how important each of these focus areas was to success. Whenever I went “above and beyond” (according to a client), it was because I had applied all three focus areas to a situation.
But, most interestingly, I realised how important Connect is. It is the key: the heart of a collaborative approach to business analysis.