The three parts of the bridge

15883 Views
4 Comments
10 Likes

“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 three parts of the bridgeThe 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?”.

Peter LefterovAuthor: 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/

 

Like this article:
  10 members liked this article
15883 Views
4 Comments
10 Likes

COMMENTS

sparkerb posted on Monday, January 17, 2011 7:37 AM
The problem with the bridge analogy is that a bridge is an inanimate thing that does nothing but provide a connection between two points. Many times that connection is simply the quickest way between those two points, not necessarily the only way.
Business analysts do more than simply connect business to IT. That is not their primary purpose.
If you need a bridge analogy, then the business analyst is the bridge between the business problem and the technical solution, although I would suggest that the business analyst bridges to a solution whether it is technical or not.
I think the primary purpose of the business analyst is to increase the value of the organization through solving business problems. For example producing business analysts may be called upon to analyze the sales process and results to assist management make a decision about redistricting the sales force. While a good and typical use of business analyst skills, a bridge analogy is quite tenuous at best, and there is no connection at all with IT.
I think it's time business analysts realize they are more than the go-between for business and IT.
plefterov posted on Tuesday, January 18, 2011 11:22 AM
Thank you for your comment!

Indeed I too struggled with my distaste for the bridge analogy while creating this article. In the end I was satisfied to put it in quotes, make it "build the bridge" instead of "be the bridge" and to call it just "a good enough" definition.

Indeed we need to make sure we're communicating the right thing to the right people and not just pass messages back-and-forth. But even this "smart bridging" function is still only 1/3 of the work - that of the Requirements Manager.

To really make sure things get done a good BA should be able to be involved in the actual definition of the problem and the preparation of the solution - and that are the two sources of our "analytical" work. The problem is usually a process and the solution is usually a software system but of course that's not necessarily the case - it's simply an example people can easily relate to.
sparkerb posted on Thursday, January 20, 2011 8:09 AM
Don't forget the all important job of assisting the business in transitioning to the new system, feature, process. This is usually not part of the project charter, nor is it on the radar of the project manager or solution team. Someone has to make sure the business is ready to accept the solution when the solution is implemented.
That adds a fourth part to your bridging, and of course four legs are more stable than three.
LauraBrandau posted on Monday, January 24, 2011 2:50 PM
I think if we use the bridge analogy we should look beyond the business-IT bridge. BAs also build bridges between various parts of "the business" which is not a single entity but a group of diverse people, often with competing interests.
Only registered users may post comments.






Latest Articles

Rethinking the Triple Constraint: Five Project Dimensions
Feb 17, 2020
0 Comments
Perhaps you’ve seen a sign at an auto repair shop that asked, “What do you want: good, fast, or cheap? Pick two.” While humorous, th...





Copyright 2006-2020 by Modern Analyst Media LLC