Let's Get Down to Business Wed 14 Feb 07

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