I’m Not a Business Analyst – I’m a Business Analyst Designer

For many years I have been calling myself a Business Analyst. But recently I’ve been feeling somewhat awkward in my own skin. I’ve noticed that I don’t do things in quite the same way as other BAs around me. I seem to think differently. I get especially uncomfortable when people use the word “requirement”.  Over that time, I’ve slowly come to realise that I’m not a Business Analyst. I’m actually a Business Analyst Designer. It’s a job title I’ve invented because I couldn’t find any existing job title that quite fits the bill. In this article I’m going to explain what it means.

Tony Heap, Freelance Business Analyst Designer, its-all-design.com,  tony.heap@its-all-design.com
Previously published on www.its-all-design.com

Tony will be presenting a half day workshop on “Agile By Stealth – A Step By Step Guide” at our annual Business Analysis Conference Europe 2016, 19-21 September, London

Please note this article was first published prior to the publication of BABOK v3.

What is a Business Analyst?

One of the problems that our industry faces is that the job title of Business Analyst means different things to different people, and the role varies from company to company.

There are, however, at least two industry bodies that have published a definition of the role – namely IIBA and BCS.

IIBA’s BABOK Guide is in its third edition (version 2.0, published in 2009), and version 3 is in progress. It contains a description of the tasks, techniques and competencies that business analysts must perform or possess. In summary, the BABOK Guide says:

Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.

Two key concepts within the BABOK Guide are solutions and requirements. A solution is defined as:

A set of changes to the current state of the organization that are made in order to enable that organization to meet a business need, solve a problem, or take advantage of an opportunity.

And a requirement (slightly adapted) is:

A condition or capability [of a solution] needed by a stakeholder to solve a problem or achieve an objective.

In examining the tasks described within the BABOK Guide, it is clear that a business analyst’s life revolves primarily around requirements. Business analysts elicit, analyse, prioritize and document requirements.

With regards to solutions, business analysts assess (proposed) solutions, recommend solutions and validate solutions. What they do not do is design solutions. From my reading, solution design is done by someone else.

The alternative definition of the business analyst role is BCS’s Business Analysis, currently in its second edition (published 2010). It too defines a set of competencies and tasks. Its definition of the business analyst role is:

An internal consultancy role that has the responsibility for investigating business situations, identifying and evaluating options for improving business systems, defining requirements and ensuring the effective use of information systems in meeting the needs of the business.

Again, the role revolves primarily around requirements – eliciting, analyzing, documenting, validating. And again there is a distinction between requirements and solutions.

Business Analysts are Not Designers

If I take the above definitions to their word, then it seems to me that business analysts do not do any design work. They define. They identify. They elicit. They analyze. They decide. But as for the creative process of designing business processes and IT systems, that is apparently down to someone else. It’s either done by the stakeholders, with the BA helping them along (eliciting/analyzing/prioritizing/documenting), or else it’s done by the “solutions team”, with the BA validating/recommending.

Actually, I’m being a little unfair here. Both books do make reference to design activities, but only if you’re reading carefully and actively looking out for them. The BABOK Guide refers to creative thinking, decision making, problem solving and systems thinking as being underlying competencies of a business analyst. It refers to process modelling, scenarios and use cases and data modelling as important techniques in the BA’s arsenal, all of which (to my mind) are elements of design. BCS’s book has similar references.

The BABOK Guide also devotes a chapter to Enterprise Analysis. This describes the work that is done at the start of a project to understand the business objectives (“business need”) and to determine a business change (“solution”) that best achieves the objective. To my mind this is all about design. It talks about understanding desired outcomes, identifying gaps, generating options and selecting a preferred solution. But it does seem to imply that such design work is only done by the BA at the start of a project, and also possibly only by an enterprise business analyst with special enterprise skills.

I am a Designer

I see myself first and foremost as a designer. I engage with stakeholders and listen to their objectives. I make sure I understand the business domain, and the as-is business processes and IT systems. I listen to their proposals and ideas for how to achieve their objectives. Then, I work collaboratively with them to design a business change that meets their objectives. The business change sometimes includes IT system change. It always includes business process change. Usually, I design multiple options – some cheap and simple, some expensive and sophisticated.

The design work starts at a high level (much like enterprise business analysis). But it continues throughout the process. I apply creative thinking to every detail of every feature – constantly generating alternatives and (collaboratively) selecting the one that works best.

The tasks I perform are very similar to those described in the above books. I just do them with a slight twist. I don’t attempt to “elicit requirements”. I recognise that stakeholders might not know what they want, and that it’s my job to come up with designs to meet their objectives. I recognise that stakeholders sometimes think they know what they want, but that it’s my job to work out alternative designs that might better meet their underlying objectives.

Just to save confusion here – when I talk about design, I’m talking about business process design and IT system functional design – the user-visible behaviour of an IT system (for more details read this article). I am not talking about doing IT technical design – I’m not too interested in what programming languages or server hardware are used to deliver the system.

Most importantly, I hold myself accountable for my designs. They are my designs. If they don’t meet the stated objectives, that’s my fault. I don’t blame the stakeholder for giving me bad requirements.

Actually that’s not quite true. I’ve discovered that the best model for success is joint ownership of the design – between me and the stakeholders. We agree together that the design meets the objectives, and we take the flak together if it doesn’t. There’s no them and us.

I’m Also a Business Analyst

Being able to design business processes and IT systems is an important part of my role, but it’s not enough. I’m not the sort of designer who relies on someone else to go and “elicit the requirements” from the stakeholders. I engage directly with the stakeholders myself. It’s the only way I can understand their objectives and design them a business change that satisfies those objectives.

So, I need business knowledge. I need to be able to communicate effectively with business stakeholders. I need to act ethically and foster trust. I need to manage scope. I need to prioritize. I need to manage change.

In short, I need the competencies of a business analyst, and I also need to execute many of the tasks of a business analyst. Some of them I execute with a “design” twist.

I am both a business analyst and a designer. I am a Business Analyst Designer.

A New Job Title

Surely there’s no need for yet another job title in the IT industry. There are enough job titles and enough confusion out there already, something that two separate industry bodies (IIBA and BCS) are working hard to resolve. Why make it worse?

Here’s my problem. Currently, the industry seems to recognise two separate roles – that of the business analyst, and that of the (IT) solution architect/designer. The definitions of the business analyst role provided by the IIBA and the BCS seem to support this separation. But the way I work cuts across both roles – I am both a business analyst and a designer.

I would love to refer to myself as a business analyst. But the way I work is (I think) sufficiently different from the way in which the IIBA and BCS describe the role that it just doesn’t fit for me.

And the solution architect/designer job title doesn’t fit either. Typically, the solution architect/designer expects to receive some “requirements” against which to design. But that doesn’t work for me because in my view there’s no such thing as a requirement. I engage directly with business stakeholders to understand their objectives, their desired outcomes.

So, I chose the job title Business Analyst Designer to convey the sense that I am both a business analyst and a designer.

There are other job titles that fit the role I do. A fellow blogger tells me he uses the term Business Design Analyst, and also considered Business Designer. Another prefers Architect to Designer. A colleague of mine refers to himself as a Business Architect, but only in the UK – apparently Europeans don’t recognise it. The title does matter, and is clearly a subject for debate. But it’s the role that’s really important.

A Real World Example

The business analyst/solution designer conundrum was summed up for me in a job interview a couple of years back. The hiring manager had placed two separate job adverts – one for a BA and one for a Solution Architect. I asked him what he was really after. He replied something like “well, I don’t want just a business analyst – I want someone who is going to design solutions for me. But I don’t want just an architect, I want someone who understands business and can engage with the stakeholders.”

He ended up hiring me for the role. Hopefully he got what he wanted – a Business Analyst Designer.

Parallels with Building Design

Comparisons are often made between the construction of software and buildings. Such analogies don’t always hold water, because buildings and software are very different things, and there’s no reason why the construction process of one should apply to the other.

That said, it is interesting to note that a building architect works much in the same way as I do – engaging directly with stakeholders to understand objectives, but also being responsible for the design of the building to satisfy those objectives. Not designed to the finest level of detail, but in enough detail that the stakeholder knows what they are going to get.

In the building industry there is no concept of a building analyst who “elicits the requirements” and a separate building designer who receives the “requirements” and designs a “solution”. It’s a single role.

An Opinion

In this article I have talked about the way I work. I am not saying everyone should work this way. I am not saying this is necessarily the best way to work. I’ve just noticed that it works well for me, and on the particular projects I’ve worked on. It’s my opinion, nothing more.

In particular, I am in no way wanting to discredit or diminish all the good work done by the IIBA and BCS in advancing the industry by working to define the business analyst role. I don’t agree with everything in their definitions, but I still find them of immense value.

Are You a Business Analyst Designer?

I think there are other Business Analyst Designers out there. Steve Blais is keen for us to Stop Gathering Requirements. Thomas Frisendel recently talked of The Changing Shape of Business Analysis. David Morris believes that We are All Designers Now. In response to David, Julian Sammy gives a more balanced view and declares himself to be Requirementortionist!

So, are you a Business Analyst Designer? Or perhaps a Business Analyst Designer by another name? Whether you are or not, I’d love to hear your opinion, so please feel free to comment below

Tony Heap is a freelance Agile Business Analyst / Agile coach / trainer based in the UK. He has worked for a variety of clients including ASDA, Morrisons, NHS, RWE nPower, Arcadia, BT, Barclaycard and Egg. In his spare time he likes to share his experiences and ideas on his blog www.its-all-design.com. He is particularly interested in Agile approaches and how they apply to Business Analysis. He is a requirements denier. Follow Tony on Twitter @tonyheapuk.

Copyright: Tony Heap, its-all-design.com