« Okay, Okay, I Get It. | Main | An Unexpected Obstacle to Forming a Business Analysis Group »

Let's Get Down to Business Wed 14 Feb 07

Strategic2In 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.

Teamwork 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:

            Tell A Friend Tell a Friend    View blog reactions   Bookmark    rss RSS Feed

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c5de753ef00d83573e14669e2

Listed below are links to weblogs that reference Let's Get Down to Business:

» Hiring the Right / Wrong IT People to Achieve Alignment from Beyond Blinking Lights and Acronyms
Dr. George E. Strouse had a great article recently on CIO.com entitled Are You Hiring the Wrong IT Staff to Achieve Your Alignment Goals? Strouse contends that the major cause of business and IT mis-alignment is that IT is not [Read More]

» Interviewed On Dice.com About Business Analysts Raising Their Profile from Beyond Blinking Lights and Acronyms
Back in April, Sonia Lelii from Dice.com, a recruiting and career development website for technology and engineering professionals, interviewed me as part of her story, Business Analysts Raise Their Profilein their Technology Today section. Lelii also ... [Read More]

» Business Analyst Job Description from Beyond Blinking Lights and Acronyms
Far and away my most popular post is Let's Get Down to Business. Even though it was written about a year and a half ago, 20 % of my recent site visits are to this article coming in either through Google [Read More]

» What's In A Title / Job Description - Programmer, Developer, System Analyst, Business Analyst from Beyond Blinking Lights and Acronyms
A reader from Singapore (fantastic place by the way) wrote me with a question a few weeks ago -- Just wonder how a BA [business analyst] is different from a SA[system analyst]. My understanding of a good SA has attributes [Read More]

Comments

michael_schaffner


tell_a_friend Tell a Friend About Mike's Blog







Creative Commons License 
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 License.

My photos on
www.flickr.com
Mike Schaffner's items Go to Mike Schaffner's photostream

Free Subscriptions
  Free RSS Subscription

Free RSS Subscription


For An Email Of New Articles
Enter your email address:


Read On Your Mobile Device

mofuse


Join the Conversation
Subscribe to Comments
  Free RSS Subscription

For New Comments Email
Enter your email address:






This is the personal blog of Michael W. Schaffner. The opinions expressed in this blog are soley mine and those of commenters. You should not infer that these opinions are the opinion of or have been endorsed by any current or former employer.

Please review the Privacy Policy.   I do love comments and trackbacks but I do reserve the right to remove any that don't comply with the Comments and Trackback Policy.  Rather than clutter up the front page with badges and statistics that are of little interest to anyone other than me I thought it would be best to establish a separate page for statistics and rankings.


Copyright © 2006, 2007, 2008, 2009 Michael W. Schaffner       You may copy or quote sections of this blog if you provide an attribution consisting of a reference to the Michael Schaffner and ''Beyond Blinking Lights and Acronyms" along with a hyperlink (if a web reference) to the blog posting.     

Creative Commons License 
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 License.