Skip to main content

Author: David Morris

We Are All Designers Now

morris Aug20When 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.

TARDIS – Time and Relative Dimensions in Scoping

One of our biggest concerns as business analysis practitioners is scope: how do we define scope, how do we guarantee that we can deliver everything that satisfies the scope, and how do we ensure that we don’t stray outside the scope?

In other words, how do we place our hand upon the BABOK and swear that the analysis we give will be the scope, the whole scope, and nothing but the scope?

How wide is it?

When most people think about scope, they think about the boundaries of an area or domain, constraining the breadth of what we look at so that we focus more sharply on those processes and activities that require change.

This definition is inherently two-dimensional.

Imagine an episode of Doctor Who, where he and his trusty sidekick have to work out how they can get across a puddle. If the Doctor thought about problems in just two dimensions, he might think he can solve the problem of crossing the puddle by looking only at how long and wide it is; because this tells him whether he can step or jump across it.

This perspective is probably sufficient early in a project where we want to define the business scope, but the real world is not just two-dimensional.

How deep is it?

Within and below the business scope is the solution scope. Most problems I have seen with scope are with the solution scope; that is, how simple or complex will the solution be, are we happy with manual processes alone, with some minimal technical support of the main scenario, or do we need full automation of every possible scenario.

This takes the definition into the third dimension, i.e. how deep it is.

So now Doctor Who could use his sonic screwdriver to gauge how deep the puddle is; which tells him at least whether he can easily walk across it, wade through it up to his waist, or that he’ll need a boat.

The deeper it is the more expensive or time-consuming it will be; but we need to know that before we start, right? Too many projects are approved to go before the solution options have been considered, and this is one of the most common reasons for cost and time blow-out.

The only thing constant is change

And of course, one of the biggest issues for our projects is that they assume the scope is fixed at the outset and work to deliver that; only discovering toward the end that the scope has shifted or grown so that they will struggle to get sign off or worse still, the business will sign it off and never use it.

Of course, this is about the state of something over time, and so introduces the fourth dimension: time.

Back to our puddle; if the Doctor looked at it in the morning, then popped off for a few hours, when he came back the puddle may have dried up, run somewhere else, or grown in area or depth if the rain continued. He cannot then hope to get across it the same way, and if it’s gone completely he doesn’t need to bother at all.

We should never assume the scope stays fixed; and how can we deal with that?

Denial: Some organisations seek to constrain this by enforcing strict change control, in effect putting brakes on change. While this means the scope stays the same during the life of the project, it doesn’t mean it will be fit for purpose when it’s ready for delivery – so we get cost and time blow-out as we redress that.

Acceptance: Smarter organisations accept that scope will change; they baseline the business scope, and work in smaller chunks to elaborate the solution scope on an ‘as needed’ basis. They can continuously check that the scope is still sound, and if it has changed, avoid doing work that will be unnecessary. Although this could end up with only delivering 80% of the original solution scope, the project can still end on time and within budget … or they can choose to continue if that final 20% is really needed.

At the end of the episode, as Doctor Who vanishes off on his next adventure, we’re faced with what’s left and have to ask:

  • What has been your experience of problems with scope?
  • How does your organisation seek to cope with changes in scope?
  • Are there any other approaches that you have seen work?
  • And, most importantly, what was so important about the puddle and couldn’t the Doctor just have used the TARDIS to reappear on the other side?

Don’t forget to leave your comments below.

Innovation and Business Analysis

How can I use the concepts of ‘innovation’ and ‘business analysis’ in the same phrase?

While, to some, this might sound oxymoronic (like the term ‘deafening silence’), or at least moronic (and those who know me would expect nothing less); I would argue that innovation contributes to business analysis, and business analysis contributes to innovation.

What does this mean and how do we make it happen?

We don’t need to be innovative, though, do we?
Business analysis practitioners can provide an excellent service as we work through the project process, asking questions, applying techniques, creating documents and presentations, and clarifying how to implement the approved solution. Like any discipline involved in business change, done well, business analysis can make the difference between a successful and a struggling project.

Where we can add real value, is in providing creative analysis – enabling stakeholders to think outside the box, encouraging them to behave like their project was their own business so that they care about the outcomes, and providing thought leadership from the project space to the organisation.

How innovation contributes to effective business analysis
An essential purpose of business analysis is to “recommend solutions that enable the organisation to achieve its goals” (p3, BABOK v2, 2009). Sometimes this will involve helping organisations to ‘invent’ something new, although more often it will be to ‘innovate’ – to improve something already in use.

However, with business analysis typically practiced within the confines of a project, under the direction of a project manager, we risk adopting convergent thinking approaches. By following the ‘correct’ process to document requirements for sign-off, we can be seen to add little value in the process – that is, we become a requirements clerk gathering requirements.

Of course, we are more effective where we plan and manage our own business analysis activities, identifying the stakeholders and negotiating the scope, so that we can elicit, analyse, document, and communicate what is needed.

We add even more value where we apply divergent thinking too; this is where innovation is key to business analysis.

What does this mean? We need to push our stakeholders outside their comfort zones, to think laterally, to challenge them beyond an assumed solution and find out why they want something – so that we can be clear about what they really need and guide them to selecting the optimum solution, not just the one they first thought of; that is, let’s not make a bad process faster, let’s design the right process and work out how that needs to be supported.

How do we do this? At its simplest, this requires two things: to develop our underlying competencies (in areas like creative thinking, problem solving, and facilitation), and to have the courage to push back (suggesting that there could be alternative solutions, challenging to ensure that the underlying causes or needs are identified).

How business analysis contributes to effective innovation
Business analysis also has much to offer to how an organisation approaches its innovation processes, that is, well before there is a project.

Innovation in the pre-project stage
Most organisations will go through some form of scoping and business case stage before a project is initiated. While this is often undertaken by a project manager; mature organisations and PMOs recognise that it is a better fit for the BA to build the case for a project, or at least support the business owner in doing that. (Indeed, some would argue that you cannot assign a project manager until you have a project to manage, however there is always business to analyse).

Now, you might contend that building a business case is not showing innovation, it is simply taking the information that is available then researching and analysing it enough to understand the likely costs, revenue, duration, return on investment, risks, etc.

However, to develop a strong business case, we are required to explore alternatives, and can often uncover unexpected options or combinations that were not in the mind of the customer or requestor. More examples of divergent thinking.

How do we do this? If BAs in your organisation do not currently work at this level, find a small project that cannot yet proceed because it needs a business case, then volunteer to ‘have a go’. Even if it still doesn’t get the go ahead, you can learn from the experience and interact with stakeholders in a slightly different role.

Innovation in ideation
Further upstream (in the new product development process), before an idea has even been approved to be scoped and have a business case developed, business owners are busy working with sales performance data, customer satisfaction feedback, market research, and blue-sky thinking – divining answers that will result in a new or improved product, give a jolt to sales, or eventually withdraw a product from the market.

Equipped with our divergent, lateral-thinking, and facilitation skills, we can really enable an organisation to make the most of smaller investments to determine if an idea makes sense, before anyone even thinks of writing a business case. Working at this fuzzy front-end is also very rewarding; as well as being very focused on good business outcomes, you definitely get a sense of play, and interact with senior management.

How do we do this? Opportunities for these sorts of roles are rare, and are often promoted internally rather than advertised. The best way to attract these is to be seen to perform well in the pre-project space, and if there are ever any moves to revise the solution delivery lifecycle, governance, and/or new product development process, volunteer to be involved – from there you can agitate for a role like this and position yourself as the ideal candidate.

I’ve shown that irrespective of where we work in an organisation, and the development process stage, business analysis has much to offer in terms of helping foster innovation in our organisations. Do you agree?

I’ve said it’s rare for us to work outside the project space. Is this your experience?

What steps can we take to convince our organisations to allow us to play in this more creative space?

Don’t forget to leave your comments below.