IT BA

Chief among the sticking points is calling an IT BA by another name, such as a Systems Analyst. The BABOK^®  is clear in its definitions , anyone who does anything that is remotely considered under the auspices of the work of a BA , is considered to be working in the realm of BA'dom. This includes (but is not limited to ) System Analysts and Process Analysts, as well as Project Managers.

This article however will focus on something that I find to be a very contentious issue, hotly debated amongst my previous and current colleagues. If we are going to make a distinction between a BA , and an IT BA, then which do we need on a technology project , and why should the IT BA do the business requirements at all?

I’ll start by listing what I see as the main differences between a BA and an IT BA.

In general all BA’s should be able to:

·        Analyse and document business processes.

·        Conduct Stakeholder analysis

·        Elicit, identify, analyse and decompose business problems.

·        Produce from this analysis a Business Case.

·        Refine the business problems into a set of Business Requirements

·        Propose and document a solution for the business problems which can consist of any one,  or a combination of the following within the business requirements document / specification:

o   TO-BE Business Process

o   Business context diagrams

o   Business conceptual Domain Models

·        Elicit , identify , analyse and decompose Solution Requirements.

see also Requirements Analysis  for some background and a more information

All of the above does not require the Solution to include any technological aspects.

It is when a technology solution is required that we see the rise of what is more commonly being referred to as the IT BA .

An IT BA should further be able to ( in my opinion):

o   Elicit, identify, analyse and decompose Solution Requirements that consist of

1.      Functional Requirements
2.      Non-Functional Requirements

Further to that - in my opinion, the IT BA  should also be able to hold their ground , and have substantial input into the architecture of any solutions. As the person who understands ( hopefully!) the business problems and needs more so than any other project member, they must be able to discuss and debate the merits of various approaches with the project Architect, and Developers. It does not matter how fabulous they are at documenting anything, because people are uniquely shaded by their own perspectives. An Architect will have a leaning towards their own personal preferences in technology and platforms, developers will present solutions that fit within their preferred languages, and it takes a strong person to ask the questions regarding the 'fit' of the technology design onto the solution requirements and back to business requirements. Which is in itself a constant process of re-evaluation throughout the project. Don't hesitate to ask those questions of yourself and others , even when you think you have everything nailed down.

There is in my view a  distinct separation of a BA role and an IT BA role , and the outputs they should produce in a project cycle. In an organisation where the roles are distinct and occupied by different people , the BA will do the analysis of the project up to the point where the business requirements are documented and signed off, and will hand over  at that point to the IT BA.

This is where, things start to go pear-shaped. And where many good people lose the plot, so to speak.

In theory - at each stage of a development cycle, the previous role player hands over perfectly executed , exquisitely documented  outputs. There is,  in an ideal world, no shades of grey, when the BA hands over the business case or business requirements to the IT BA, they are getting the best possible representation of the business needs , without exception.

The reality is however that projects start late, they are delayed and impacted  by people who are sick, people have sick children/dogs/parents/spouses. They have car accidents and flat tyres. Key stakeholders miss meetings , or are not identified. Strong willed business stakeholders hijack meetings to push their own agenda's.  Any number of things can go wrong , or be missed in the first stage of requirements elicitation. And when the project is high profile, and impacts the business deeply and badly , there is constant pressure to deliver things quickly rather than properly.

Yes - the IT BA will be given the best possible document that the BA can produce, but it will be subject to any number of negative factors. The IT BA must therefore operate under the assumption that the requirements need to be managed , and QA'd. Even updated , added to , or in some cases scrapped entirely and replaced.

This begs the question - why even bother with the split approach anyway? Surely it would be better to just have the IT BA do everything ? That way , they would be able to make sure they do the best they can do , and at the very least , even if they do a bad job documenting the business needs , they'll understand them , and be able to make a brilliant solution anyway?

I think not. I think that both the BA role and the IT BA  role should be involved in all parts of the project from the start to the end. Buddy Buddy works. And it works well when the BA's on the project collaborate effort skills and knowledge.

The roles and responsibilities stay the same , but the collaboration of the two uniquely positioned viewpoints means that the processes , the analysis , the outputs and the resulting requirements definitions are, within the constraints of the project , the best they can be.

This does not mean necessarily that there will be two people working on the project. In organisations with resource constraints, or where there is no distinction between BA's and IT BA's , there will often be only one BA assigned to a project.

It is these projects where the BA's ability to don different hats becomes critical. If this is you , you must be able to do the BA work as a BA, focus on the Business definitions , concepts , problems and terms. Talk about the solution in terms of what the business will want to achieve.  You should then effortlessly be able to step out of that role , and converse technically with the relevant development team as an IT BA regarding the mapping of those business requirements into functional requirements and solution architecture, while maintaining in the back of your mind anything that might impinge on the business needs.

Globally the role of the BA is becoming more recognised as a profession in it's own merit , and as this thinking gains ground, it becomes ever more critical that BA's step up to the challenge of delivering on that expectation. This means we all need to be able to play different roles, BA, IT BA, technical advisor, systems process analyst, process designer. User Champion.

Yes - User Champion. If that role has not been represented correctly on your project ( a senior VP Exec is NOT a user champion. ) then you need to take on that responsibility , at least to the extent of owning the Functional Requirements and relating them back to an actual business need.

Don't know what a User Champion is  ? Check out below for some interesting reading :

http://www.frontend.com/design/the-user-champion.html
http://tc.eserver.org/19312.html

A BA is not someone who takes notes and writes down what the users want. A BA questions , probes , elicits information , and gathers details. All of this for the purpose of creating a unified view of the problem , it's solution and the road map to get there. In order to accomplish this they will need to play various roles, produce several artefact's and acquire and hone many skills, all of which combine to produce a uniquely skilled individual. An individual who is capable of filling those messy inconvenient gaping holes between Project Managers , Users , Architects, Developers , Business Management, Development managers and  Executive Stakeholders.

If you're up to the challenge , it can be one of the most stimulating environments to work in. Nothing can ever be the same , and therefore everything changes , all the time.

A last word of advice : If you don't like your cheese moved, don't become a BA.