Let's Get Down to Business

In my post on Monday I talked about forming a Business Analysis group within IT to act as a bridge between IT and the business units.  The reason for this is to make the business strategy more effective through a proper use of technology.  By taking the steps necessary to add value beyond just delivery of services IT can become a strategic service.

The typical first approach to this is to simply say that we'll take some of our applications people and make them business analysts.  Although I won't say that application developer can not make good business analysts I will say that it is not a common occurrence.  The reason for this is that these two functions call for different skillsets and training.  Applications folks are trained in the intricacies of programming language and processes with little or no business training.  Most of their business exposure comes from what they learn on the job.  Conversely, business analysts are primarily trained in business process with an overview of application development.

Let's take a closer look at the requirements for a business analyst.

Sometime ago a recruiter friend of mine asked me if I could suggest some names to fill a Business Analyst position and sent me a position description outlining the requirements.  I kept the position description because I thought it was excellent.

• Elicit requirements using interviews, document analysis, requirements workshops, surveys, site visits, business process descriptions, use cases, scenarios, business analysis, task and workflow analysis.
• Critically evaluate information gathered from multiple sources, reconcile conflicts, decompose high-level information into details, abstract up from low-level information to a general understanding, and distinguish user requests from the underlying true needs.
• Proactively communicate and collaborate with external and internal customers to analyze information needs and functional requirements and deliver the following artifacts as needed: (Functional requirements (Business Requirements Document), iii. Use Cases, GUI, Screen and Interface designs)
• Utilize your experience in using enterprise-wide requirements definition and management systems and methodologies required.
• Successfully engage in multiple initiatives simultaneously
• Work independently with users to define concepts and under direction of project managers
• Drive and challenge business units on their assumptions of how they will successfully execute their plans
• Strong analytical and product management skills required, including a thorough understanding of how to interpret customer business needs and translate them into application and operational requirements.
• Excellent verbal and written communication skills and the ability to interact professionally with a diverse group, executives, managers, and subject matter experts.
• Serves as the conduit between the customer community (internal and external customers) and the software development team through which requirements flow.
• Develop requirements specifications according to standard templates, using natural language.
• Collaborate with developers and subject matter experts to establish the technical vision and analyze tradeoffs between usability and performance needs.
• Be the liaison between the business units, technology teams and support teams.

I've highlighted a few of the sections above as they especially convey the essence of what distinguishes a good business analyst from a good applications person.  It is basically a blending of business and technical skills and not necessarily an in-depth expertise in either.   Typically this would be someone with a business degree with an emphasis in information systems.

Another critical skill that this person needs is to be able to work effectively in a matrix organization.  The reason for this is that I suggest that the business analyst report on a "solid line" basis to IT and also report on a "dotted line" basis to the business unit.  I also suggest taking it a step further and embedding or co-locating the analyst in the business unit analogous to embedded journalists with the military.  I had earlier talked about doing the same with the PC techs.  The basis for this is, to use the business phrase, "to get close to the customer".  To be truly effective, the analyst has to understand his customer's business, know their pain points, their needs, their strategic plans.  A full understanding in necessary to be able to adequately convey this to the applications folks.  This obviously also places an additional burden on IT management as employee supervision is more difficult under this arrangement.  However, remembering that the goal isn't to make life easier for IT but rather to make for the business we support I think you'll agree it is worth the extra effort.

Have you tried this?  I'd love to hear from anyone who has implemented a Business Analysis group within their IT department.  Please share your experiences.

Upcoming post:  An unexpected obstacle to implementing this concept.

If  this topic was of interest, you might also like these:

• Let's Get Strategic!
• How We Can Become More Like "Shadow IT"
• IT Needs To Become More Like "Shadow IT"
• Or the posts in the Business Analysts / Analysis category

Comments

[James]

Mike,

Thank you for a description of what a BA role is.

Personally I can see point three taken too literally:

"Proactively communicate and collaborate with external and internal customers to analyze information needs and functional requirements and deliver the following artifacts as needed: (Functional requirements (Business Requirements Document), iii. Use Cases, GUI, Screen and Interface designs)"

with BA's thinking it is their responsibility to create the GUI and interface designs.

What I think is lacking in the definition is the distinction between finding out what is required and designing how that is implemented and which part of that is in the role/responsibilities of the BA and which is not.

Do you think the role of the BA is to design "HOW" a system will do what it does?

I find the "HOW" creeps in whenever the requirements take the form "The System shall..." rather than "It is required that ...".

What do you think ?

Rgs,James.

[Mike]

James,

Thanks for commenting.

Like so many things in life it is not black or white but a shade of gray. In general I do agree with you though. To grossly oversimplify the BA should be concerned with outcomes rather than methods.

In terms of "designing" GUI I can see the BA being involved from outlining what the customer needs and how it should work. The behind the scenes workings are clearly that of the developer not the BA.

Likewise a BA could say I need a report that shows X which is (A/B)*C. In this case they are both defining the outcome and the method of doing it which is necessary to clearly show what they need. The BA and developer should be able to work together so that if the developer says B/A is already setup as D and therefore it is more efficient to program it as X=D*C the BA shouldn't have an issue since it provided the needed outcome with the developer determining the best method.

The key is to remember the BA is not the developer but may have to provide some input on "how" to clearly indicate the outcome.

[James]

Mike,

To me your comments highlight the need for conversation between all people involved and more importantly how requirements are the begining of that conversation, not the end.

Also highlighted is the need for BA's to respect that while they may be accountable for getting certain artefacts together, they are not necessarily responsible for doing them. Especially if they don't have the skills.

Rgs, James

[Mike]

James,

You're correct. As in all relationship communications and respect are critical to the relationship's success.

Mike