We Are All Designers Now
When the discipline of business analysis first established itself, it was important that it be differentiated from other disciplines. Part of this distinction was that business analysis focuses on the ‘what’ and ‘why’ of a solution, rather than the ‘how’ – the latter being the responsibility of solution architects, developers, and the like.
I have always felt that this was an artificial distinction, that business analysis practitioners by their very nature cannot avoid thinking about how a solution will be delivered, that we unnaturally bend ourselves when we try to write in a way that is completely devoid of any solution context. This will bother many purists within business analysis, as well as within our partner disciplines. So let me explain.
We often talk about the golden thread in a project being the traceability from the original problem/opportunity statement, through the benefits, the scope, business requirements, stakeholder requirements, solution requirements, solution design, built solution, tested/proven solution, implemented solution, and finally (one hopes) the realised benefits.
At a key point (usually between solution requirements and solution design) this is deemed as crossing the threshold into other discipline areas, and woe betides any business analysis practitioner who dares venture there. At some level, we can make sense of this, as shifting from requirements to design is an obvious shift from the what (is wanted) to the how (it will be achieved). However, consider the following heretical thought: as we shift from higher levels of abstraction to lower levels of substance, we make decisions, decisions that implicitly mean we have decided ‘how’.
For example, when the problem statement is translated into a set of objectives or benefits, we are deciding how we can prove when the problem or opportunity has been resolved. When we define the scope, we are deciding how wide and how deep we need to go in order to achieve the benefits. When we develop business requirements, we are deciding how the scope will be achieved. And so it goes on.
“Ah,” you say, “OK, I get where you’re coming from. So, yes, to that extent, I can accept that BAs do get involved in decisions about ‘how’ something gets done. But that’s not design, is it?” And you’d be right, to the extent that, so far, we haven’t established how business analysis touches on design; just that we don’t focus solely on the ‘what’ and the ‘why’.
So, now it gets more interesting, because now we get to see how business analysis practitioners are actually delivering part of the solution. Sure, we don’t actually code any software. However, software is only one part of a solution. Is your spidey sense tingling now? Do you get a feel for where this is going?
Embrace your inner designer
A solution is made up of many parts. Let’s simplify it into the three Ps – people, process, and platform.
When we look at current process, we’re establishing the current state, or ‘as is’. Before we can look at what changes are required, we need to look at the future state. As soon as we start drawing future state process diagrams, guess what we’ve done? Are you ready for it? We’ve designed the future state!
Take a moment to let that sink in.
OK, now you’ve taken a breath and redrawn your mental map of the world as you know it, I want to ask you if you’re ready to continue this journey. Do you want the red pill or the blue pill? Do you want to wake up and go back to your world where you observe strict demarcations between business analysis and other disciplines, or do you want to keep going, to see how deep this rabbit hole goes?
If you’re still here, I presume you want to continue this journey. Don’t worry, your Steve Jobs designer outfit of sneakers, blue jeans, and black sweater haven’t been ordered yet — but know this, the tailor is on the way.
Now, let’s move on from having established a future state process. Next we look at how the future state will be supported by roles. This is often where we get involved in organisation design. Perhaps those roles imply a change in responsibilities, perhaps they don’t currently exist and imply the standing up of a new team, or more extremely, suggest a restructure. Sure as heck, we are designing something.
Also, when we get involved in drawing up user guides and short courses, we are not only designing, we are actually building and delivering too.
Scary stuff, eh?
Now, let’s move on to the more familiar territory of software development. Many of us get involved in white-boarding, wire-framing, and paper prototyping the solution. This helps galvanise our stakeholders. They start to see a little of how the solution might look and behave, and can start to challenge their assumptions and confirm that they have understood their requirements. Yup, you guessed it, this is design as well.
Welcome to the design school. That knock at the door is the tailor. So, get kitted up to and get ready to design. It’s fun and it’s what we’ve been doing anyway, so learn to embrace your inner designer.
The great thing about design-thinking is it inherently generates greater collaboration too. Now I’ve got you interested in design, I’d like to talk to you about the wider field of Business Design. That’s a post for another day.
Don’t forget to leave your comments below.
