How They Avoid the Five Most Common BA Mistakes
Over the past several years, the job title of Business Analyst (BA) has become more and more prevalent. Currently, the International Institute of Business Analysis (IIBA) defines business analysis as "the set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change."1 Thus, business analysts are often the liaisons between business and solution development (oftentimes IT), canvassing the enterprise to understand business needs, issues and opportunities in order to recommend solutions that address those needs most effectively and efficiently.
In this intermediary role, the business analyst must be able to communicate and relate equally effectively with senior management and users, business and IT communities and various functional areas throughout the organization while recognizing that each group has different priorities and issues. As a result, the business analyst's job is not an easy one. However, those who have been most successful in this role have learned to avoid the following five particularly common and dangerous pitfalls.
Mistake #1 - Not Clarifying the Role of the Business Analyst
Most of us are conditioned to think that we're supposed to "know our job." As a result, when business analysts are given a new project, they often rush to begin working on "it". That sounds logical enough, but it's amazing how often clients are disappointed, BAs are reprimanded or efforts fail because "it" was never clearly defined from the beginning. More specifically, it's absolutely essential that the BA define the scope of their role. Although the general title "Business Analyst" has been used for decades, it has only recently been established as a well-defined and widely recognized discipline, hence, the emergence of the IIBA.
Even so, the role of the BA can still vary dramatically from company to company, manager to manager and project to project. For these reasons, the BA needs to clarify boundaries by distinguishing their responsibilities from that of the project manager, product manager, systems analyst and others who might play a leadership role in the effort.
Indeed, many BAs-having been too tentative or apprehensive to clarify their role prior to task initiation-have ultimately paid the price with dissatisfied clients, frustrated teams and poor results.
Avoiding Mistake #1
As early as possible, BAs must clearly define their role and responsibilities by working with their sponsor and asking the following key questions:
- What is my role in this effort?
- What is my level of responsibility?
- What other resources will be available to me?
- What will be the reporting relationships?
- What is the "end goal in mind"?
- What specific deliverables are expected?
- What other related tasks should I be aware of (other than those I will be managing as BA)?
- What are the timing expectations?
- What project-related risks are known at this point?
Solving these problems as they arise on a case-by-case basis does not move us forward. This is one of the key issues that can be addressed by SOA and Web services in particular.
Mistake #2 - Rushing Through Detailed Requirements Development
A key task for many BAs is documenting business, user and/or system level requirements. Requirements documentation can be a significant undertaking, and oftentimes BAs simply begin by scheduling interviews, negating the importance of documenting a requirements development plan. Many BAs also make the mistake of developing a change management process only after the document is completed.
Avoiding Mistake #2
Particularly for significant requirements documentation efforts, the successful BA takes time to develop a clear plan that works within the context of the overall project plan, and includes the following activities:
Developing templates
Develop specific, well-organized interview guides and templates to capture stakeholder feedback.
Conducting stakeholder analysis
Consider all potential stakeholders before beginning requirements gathering. All stakeholders are not equal, so take some time to analyze/prioritize them based on relevant criteria (e.g., influence level within the organization, amount of impact the solution will have on them, availability for interviews, etc.).
Implementing a change management process
Unfortunately it's quite common that, before the ink is dry on the requirements document, changes will be requested. During requirements planning, the BA should decide: when the document will be baselined2, how changes will be handled, who will authorize the changes, what the decision criteria will be and so forth.
Mistake #3 - Failing to Balance Task and Relationships
Business Analysts are often charged with fixing the ills of the organization and as such need to be very structured, methodical, and task-focused. Many BAs become so focused on the task that they forget about the critical relationship component. As an intermediary among various functional organizations with competing interests and priorities, the business analyst's success is largely contingent on their ability to build and sustain strong, amiable relationships throughout the enterprise. Too often BAs hit the "information ceiling."
In other words, they no longer receive the information they need because they don't have the trust or respect of critical stakeholders who best understand the organization's problems, opportunities and processes.
Avoiding Mistake #3
The most successful business analysts constantly nurture their relationship-building skills. As much business analysis work is done in a team environment, effective business analysts consciously incorporate relationship-building activities into regular interactions. Requirements gathering can be particularly challenging without an environment of trust, camaraderie and respect. Wise BAs know that they can garner more information from a casual lunch with a friendly colleague than facilitating a three-hour interview with colleagues who are fearful, distrustful, or anxious. Recently, an associate of mine recalled an experience where his team had reached an impasse. In response, the BA took them out bowling, which immediately helped "break the ice." This is a great example of a few hours of relaxation away from the task can strengthen relationships, expand thinking, and sooth nerves. Indeed, strong relationships assist in conflict resolution, team productivity and stakeholder management.
Consider these tips when managing a business analysis task:
- Incorporate periodic social activities early in the process for internal core team members. Also, don't forget remote teams - consider using the Intranet as a way of including them.
- Take time to learn something non-work related about critical stakeholders.
- Conduct certain sessions outside the office (when appropriate)
- Provide stakeholders with as much information as possible (avoid being mysterious)
- Be considerate of stakeholders' concerns.
- Be honest with stakeholders - tell the truth!
Mistake #4 - Confusing Users' Stated Needs with Real Needs
Many business analysts spend significant amounts of time gathering users' requirements through interviews, surveys, focus groups, etc. Although users are a great source of information about their needs, the business analyst must recognize that the stated needs aren't always the real needs.
This disconnect usually occurs for the following reasons:
- Users don't really know what they need so they ask for what they think they need.
- Users ask for more than they really need (anticipating potential downstream bargaining).
- Users focus on the solution they want instead of articulating their true needs.
Avoiding Mistake #4
An efficient business analyst is a keen investigator. Just as a doctor must gather information, analyze it, then provide a diagnosis, the business analyst must perform similar analysis (often in tandem with subject matter experts). When talking to users, BAs must clearly distinguish between a requirement3 and a solution.
That can be achieved with targeted questions:
- Focus the user on the need (what they're trying to fix), not necessarily the solution (how it will be fixed)
- Begin with broad questions. Don't narrow too quickly or key elements may be overlooked.
- Ask both open and closed questions (i.e., long-answer and short-answer).
- Consider the "why, what, where, who, how and when."
- Ask the interviewee if there's anything you should have asked but didn't.
Mistake #5 - Not Quantifying Benefits
"Show me the money" is not just a famous line from a movie but also a common refrain in the business community. As business analysts are often in the position of selling their recommendations, it is important to highlight benefits and costs of potential projects. Successful business analysts recognize the importance of quantifying those benefits as much as possible. While it's important to recognize qualitative benefits like increased employee morale, enhanced customer satisfaction and increased brand equity, they're not nearly as important to decision makers as quantitative benefits. This makes it critical for the business analyst to translate benefits into dollars and cents.
Avoiding Mistake #5
Successful business analysts recognize the importance of generating a business case that clearly outlines the anticipated benefits and costs of the recommended course of action. While many of the benefits may appear qualitative, these can also be presented in a way that approximates the quantitative aspect as well. This requires the business analyst to position benefits that relate to time, cost and quality in a manner that provides a concrete perspective on the impact to the business.
For example:
Instead of saying...
Increased customer satisfaction
Quantify the benefit by saying...
Customer complaints reduced by 30%
Instead of saying...
Increased employee morale
Quantify the benefit by saying...
Employee turnover reduced by 25%
Instead of saying...
Increased efficiency
Quantify the benefit by saying...
Average production cycle time reduced by 20%
Conclusion
The business analyst plays a critical role in representing the best interests of the organization and justifying financial investments. As the BA navigates the sometimes complicated business landscape, they should actively avoid each of the five pitfalls discussed. The best practices outlined in this article not only encourage success on a specific project but, more importantly, help the business analyst develop skills that provide a foundation for long-term success.
Don't forget to post your comments below.
Dana Brownlee founded Professionalism Matters, Inc. to provide results-oriented professional development training and consulting services to both the public and private sectors. Ms. Brownlee has consulted for Fortune 500 companies representing various industries, including media/ entertainment, telecommunications, nonprofit, sports, e-business retail and automotive. She currently provides professional development training to businesses, organizations and educational institutions, such as.Learning Tree International, a leading global provider of effective training to management, business and information technology professionals. Since 1974, over 13,000 public and private organizations have trusted Learning Tree to enhance the professional skills of more than 1.8 million employees. For more information, call 1-800-843-8733, or visit our website at www.learningtree.ca.
References
- 1. Guide to the IIBA Body of Knowledge: Draft Material for Review and Feedback. Release 1.6. International Institute of Business Analysis, 2006. p.8 Available at www.theiiba.org
- 2 The requirements document is baselined at the point when it's approved by all relevant approvers and thus considered final. At this point the design phase of work begins and any subsequent requirements changes should go through the change control process.
- 3 IEEE Standard Glossary of Software Engineering Terminology, IEEE Std. 610.12-1990 A "requirement" is de!ned as: "A capability needed by a user to solve a problem or achieve an objective."
Subscribe to this comment's feed
written by rpa, August 04, 2009
RPA
Senior Business Analyst
-
- +0
-
-
written by makarandj, August 04, 2009
Really very useful article. I agree with the points mentioned in the article, especially the point 5, which talks about highlighting business benefits and cost ruduction proposition sales.
Makarand Jadhav
Business Analyst
-
- +0
-
-
written by Nkumar, August 05, 2009
Nirmal Kumar
Sr. Business Analyst
-
- +0
-
-
written by Dave Smith, August 05, 2009
Great Article, I'm sure we've all made at least one of this mistakes over time.
David (Senior Business Analyst)
-
- +0
-
-
written by harish, August 05, 2009
Harish Madaan
Business Solution Specialist
-
- +0
-
-
written by nima, August 05, 2009
Thanks for the great article. The points you've mentioned are all true but they are focused on the internal aspects of the BA job rather than the external aspects (in correlation with other roles). I believe the ability for a BA to put your recommendations in action is mostly dependent on the external factors and those correlations.
While in some organizations BAs are God-like entities, and every project-related effort must be coordinated with them, in some others they are merely technical writers who've been given a short time to write a functional spec dictated by other members.
I believe the ability of a BA to avoid the mistakes mentioned is very much dependent on the existence of other stronger roles such as PMs or Product Managers in the organization.
I think it is very important for BAs to quickly learn about the dynamics of their organization and the common mental models of the organization. Then, they’d need to develop a solution and a plan based on these guidelines to avoid pitfalls and educate their organization about their roles, if necessary.
-- Nima
-
- +0
-
-
written by abhikashyap22, August 05, 2009
A very useful article for the BA community. I liked the way it is drafted. The mistakes and how to avoid these, will surely help all the BAs. I have kept it for my future reference.
Thanks
-
- +0
-
-
written by revikumar, August 06, 2009
Excellent article.I have stored it for future reference.
Thanks
-
- +0
-
-
written by Lori Wickman, August 11, 2009
Lori Wickman
-
- +0
-
-
Great article! I totally agree with all points, especially #3: "Balancing Task and Relationships".
A BA is an intermediary, a liaison, a translator, an interpreter.
It's a must, therefore, for the BA to be on good terms with all involved.
Thanks. Every BA should save this article and use it.
Aaron Gothelf
A Real Business Analyst
http://www.aarongothelf.com