“The overall purpose of Business Analysis is to build a bridge between business and IT”. This is a good enough definition for a position as hard to define as Business Analysis.
The construction metaphor is familiar to people who have had experience with enterprise IT initiatives. Technical specialists (a.k.a. “IT”) are experts in their field – they can create or configure an IT system - as long as they get detailed technical requirements. People outside IT (a.k.a. “The Business”) are also specialists in their respective fields, e.g. accounting or sales – they are not trained to express what they need as detailed requirements.
Since communication problems are bound to occur we need someone in the middle translating for each side and facilitating communication. That is what the bridge metaphor is trying to convey. But it’s not as simple as it sounds. Bridge builders know you can’t build a bridge just anywhere. To have a bridge you need solid ground on both shores. It’s as true for IT projects as it is for crossing water.
Yet on the Business side we have a collection of many different people and departments representing their respective interests. They are engaged in company politics balancing between their personal agendas and the good of the company. Reaching a decision that enables IT to act is a challenge by itself.
IT is also hardly “solid ground”. It’s composed of various professionals each waiting for personal instructions on what they have to do. After requirements arrive they need further processing and allocating so that the team knows their individual tasks. This makes it perfectly possible for a requirement to arrive in IT only to “sink” in the internal procedures there and be forgotten.
To achieve results we need to do something to make both these sides more solid. And then we need to build the bridge itself. These are three fundamentally different roles a BA must take.
The Business Process Designer helps the business figure out what they need. If “business does not know what they want” then this is the process designer who is missing. Business Process Designer receives some vague initial instruction from management (“We’ll start offering a new product” or “We’ll offer a new customer service feature”). After that he/she sits together with business stakeholders and together with them figures out:
- What is the new process blueprint for departments directly involved
- What are the structured requirements for IT and other departments
A common misconception is that this position is just about process models - current situation (“As is”) and future proposal (“To be”). Models are important but just to make sure you’re doing the right thing. To actually push the change forward you have three main tools:
- Stakeholder management –important stakeholders can help convince everyone else to adopt the new process
- Transition requirements – if you break down the transition into steps, plan trainings/new work instructions and foresee possible problems the change will be much easier for everyone involved
- IT requirements - employees rely on IT systems to support their work process – so by changing the system you force them to change the process.
By designing the work process we determine the requirements – one cannot exist without the other. But requirements derived by process design are rarely detailed enough to start development.
That’s where the Business Systems Analyst comes in - translating business talk to IT talk. Software designers and developers are bound to have a lot of questions and someone need to answer those. To successfully fill the Business Systems Analyst role one needs to be able to understand both what Business is requesting and what the technical specialists need. The question “Who do I actually talk to in IT” indicates a lack of a Business Systems Analyst in the project.
The BSA performs requirements specification and analysis, asks key questions to business and ultimately translates business language into IT language. IT specialists tend to perceive this as the “true” Business Analyst while business does not see a difference between this role and a high-level technical expert. The combination of high technical competence and the ability to understand what Business requested is very rare and makes these professionals very sought after.
All this analysis work is necessary to figure out what has to be done - but to actually get it done a lot of coordination is necessary. The Requirements Manager is managing traffic on the proverbial Business-IT Bridge. He/she assumes responsibility for a requirements package and makes sure everyone is doing what’s necessary to get this package delivered smoothly. (or as PMs would say it – on time, on scope and on budget). A lack of a requirements manager is indicated by the phrase “So where are the requirements?”
The Requirements Manager’s job description includes identifying all the individuals doing analysis work. Then they need to communicate requirements with them. There is a different process for communicating requirements assumed to be true, requirements confirmed to be true, requirements that were changed recently, etc. The Requirements Manager knows these processes even if no one else does and makes sure they are followed in a way that produces results.
People performing this role need to be very flexible in both knowledge and attitude - filling in for BSAs, process designers or PMs on demand. Project managers tend to have a high appreciation for this BA role as its main function is to make their life easier.
Process designer, systems analyst, requirements manager… A single person cannot fill all three roles but we try nevertheless. So companies chose a priority role for their Business Analysts – the role in which they should focus most of their energy in.
Most commonly the Business Systems Analysts role is chosen. In this case Requirements Management is handled by the Project Manager or whoever has frequent customer contact (account managers are common choice for this reason). In the same time Subject Matter Experts handle process design in their departments.
Another common practice is to focus on Requirements Management. In this case one or more senior technical specialists stand up to take the role of System Business Analyst. In many cases IT architects or development leads are in fact the BSA of the project.
Whatever solution companies find it’s rarely a conscious decision. Business Analysts are supposed to do the “whole” job but are permitted to let some problems slip. It’s a reasonable attitude for now but as the Business Analysis field evolves the sub-professions will become clearer and better defined. We’ll see technically inclined Business Analyst specializing in systems analysis, SMEs and client-facing analysts transformed into process designers and BA/PM hybrid roles developing into professional Requirements Managers. And that way when we look at our job descriptions we won’t have to ask “Can anyone do this job?”.
Author: Peter Lefterov is a freelance Business Analysis consultant and trainer with experience in many different industries and Business Analysis roles. His experience includes process design initiatives with the ARIS framework, managing requirements for customer care and billing systems in Telecommunications, analysis of requirements for key systems in government and commercial institutions. He is founding VP of the Sofia chapter of the International Institute of Business Analysis and one of the first BAs in Europe to pursue and achieve the CBAP designation. For more information visit:
http://www.linkedin.com/in/plefterov
http://www.baconsulting.eu/