Author: Aaron Whittenberger

Being a Personal Business Analysis Center of Excellence

Written by Aaron Whittenberger on April 14, 2014. Posted in Articles. 1 Comment on Being a Personal Business Analysis Center of Excellence

I am often asked how to best go about a particular business analysis scenario; how to do a particular technique. Usually the person is asking more than just best practices, but looking for a short-cut or one-size-fits-all process to go about doing business analysis. I hate to break it to you…there is no such thing.

What I often find in the question is that the person is getting hung up on the process or technique and has lost sight of the ultimate goal…which should always be to add business value. So in attempt to answer the question for all business analysis scenarios and professionals, I will give you my personal operating goals when conducting business.

Remember business analysis is not just the IT Business Analyst or Business Systems Analyst that works on IT projects to deliver software solutions to the business. Whether you are an IT Business Analyst, Enterprise Architect, Process Improvement Analyst, Data Analyst or one of the other business analysis roles, you have to interact with and build relationships with stakeholders and your ultimate goal should be to deliver business value to those stakeholders. So these operating goals relate to you.

There is no one-size-fits-all way of doing business analysis

There are many areas of business analysis that cover many strategic, tactical and operational roles within the organization. There are 34 techniques defined in the Guide to the Business Analysis Body of Knowledge® (BABOK®) version 2.0, and will be more defined in version 3.0 when it is released later this year. With that kind of breadth of coverage it would be impossible to have one simple way to do things. Even in a requirements elicitation activity, what worked last time, with that set of stakeholders, may not work this time with this set of stakeholders. Experience is the best teacher. Go into each activity prepared, ready to do your best and flexible enough to handle the different alternatives that can be thrown your way.

Be proactive not reactive

The best way to be proactive is to plan ahead. There is a whole chapter in the BABOK® concerning business analysis planning activities. It actually speaks about planning the business analysis activities for a software project, but as a practitioner you must plan for each activity you engage on during your work, whether software project or more strategic or operational activity. If you are working with a new line of business or business process that you are unfamiliar with, learn as much about it as possible before you engage in your business analysis activities. There are many techniques that the Business Analyst can use to learn about a business process on his/her own.

Guide, do not direct the conversation

Never go into an elicitation activity cold, be prepared to facilitate the discussion; but realize that the Business Analyst’s job is not to direct the conversation to a preconceived end, but guide the conversation to ensure that it is productive. You may walk into the activity with a preconceived idea of the way the conversation may go, but don’t mistakenly think that is the only way the conversation can go. When the conversation takes an unexpected turn away from your preconceived idea don’t attempt to stop it, allow it to develop and see where it may lead and what can be learned from it. Guiding the conversation means making sure side conversations are kept to a minimum and that everyone’s voice gets heard. You should never walk into a facilitation activity with the goal of forcing all stakeholders to agree on a particular point. It is alright to walk in with the goal of trying to get buy-in or consensus on a point, but if you do not get that consensus that is not necessarily failure.

No one is perfect

Your requirements, process model or design does not have to be perfectly written before you share it with the stakeholders with which you are working. Building these things in collaboration with the stakeholders usually produces better results. Remember that the business stakeholders and project team members that you are working with are not perfect either. They may not articulate everything just perfect or give you perfect feedback on your requirements or models. Seasoned professionals will work through these difficulties.

Work collaboratively with others

As I just mentioned working collaboratively with your stakeholders usually produce better results. The days of the Business Analyst conducting elicitation activities, running off to write the requirements by themselves and then presenting them back to the stakeholders is quickly coming to an end. When possible, write the requirements, or build the process model, during the elicitation activity. Spend the time with the stakeholder and work together to produce the requirements or design. The good by-product of this method is a much easier signoff of the requirements or design.

Learn from past challenges

You are not perfect. The people you work with are not perfect. Don’t think that everything you do will be perfect or end in success. It was Colin Powell that said “There are no secrets to success. It is a result of preparation, hard work and learning from failures.” Failure is not a failure if you learn from it. When something doesn’t go as expected, take a moment to reflect upon the activity and your role in it. What could you have done better.

Learn from others

No matter how long you have been doing Business Analysis, no matter how “Senior” or “Lead” you think you are, you can learn from others on the teams on which you work. Everybody in the organization may look to you as the subject matter expert (SME) in business analysis, but that doesn’t mean you can’t learn. If you are open to it, you may be able to learn from that Business Analyst that the company just hired last week. Look at the way other team members operate, what they do good and what they do bad. Incorporate the good into the way you operate. Also remember, you can learn from others doing activities outside of the business analysis space.

Always drive from the business need and the “why”

I have seen business analysts get so caught up on the particular activity or technique that they are doing that they forget why they are doing it. They may be trying to be so perfect that they lose sight of the goal. The Business Analyst’s ultimate goal should be to add business value, but they should know the goal of each activity that they undertake. Now that you keep the goal in mind, determine the “why”. When investigating a new area or business process, get to the “why”. Why do the people do it that way. What is the business value of doing it that way. I have heard it said to ask “why” five times (The 5 why’s). It may not need 5 times, but asking “why” multiple times is a good process to get to the underlying root cause.

Become the trusted advisor

The goal of your business analysis activities should be to add business value. The goal for you in the Business Analyst role within the organization should be to become the trusted advisor. You have to build relationships with all the stakeholders in the organization from your technical team members, project managers, business stakeholders, IT management and business management to build the trust so that these stakeholders will give more weight to your recommendations. When your business stakeholders see you accurately representing their points of view, when IT and business management see you working for the best interest of the organization and working to add business value, trust will grow and you will find your work easier to perform built on that trust.

Continuous Improvement

No matter how long you have been doing Business Analysis, no matter how “Senior” or “Lead” you think you are, learn from others and learn from past challenges and successes. Not only work to become the trusted advisor to everyone in the organization and to add business value; but work to hone your own craft. If you think that you’re so good that there is nothing more for you to learn, I would say to you “get over yourself”. The business analysis space is changing dramatically and will continue to over the coming years. There are new and better ways of doing things being discovered all the time. If you are not consistently working on improving the way you do business analysis then you are standing still and the world, and your organization, will grow beyond you. So continually look for ways to improve your own processes.

As you can see there is a lot to business analysis, inside and outside of software development projects. The Business Analyst cannot stand still in their way of doing things. The business analysis profession, the business environment and your organization are continually changing and growing. The only constant in the universe is change. The Business Analyst professional must change also. Grow in your understanding of business processes, your profession, your organization and the environment in which it operates. Stay up on the latest trends and look for ways to incorporate the way you do your business analysis activities.

Don’t forget to leave your comments below.

My Job Title is Not Business Analyst, But Am I One?

Written by Aaron Whittenberger on March 11, 2014. Posted in Articles. 1 Comment on My Job Title is Not Business Analyst, But Am I One?

I recently had a friend who changed jobs, moving from a Business Analyst to Operations Analyst. I asked if she was going to our IIBA chapter meeting, she informed me that she had not planned on it since she wasn’t a Business Analyst anymore. In another conversation a friend was telling me that she knew a friend that was on the Board of Directors of their local IIBA chapter. When he moved to being a Data Analyst he felt that he no longer was a Business Analyst. It never ceases to amaze me how many people don’t feel that they are a Business Analyst because their job title is not Business Analyst, or some derivative thereof.

I am equally amazed when I get into conversations with people about agile; how they start talking about Scrum and it quickly becomes apparent that they believe that Scrum is the only agile methodology. I think Kent McDonald put it best:

“Scrum is to Agile
as
Kleenex is to facial tissue.”

Agile is an approach to software development based on iterative and incremental development to drive quicker delivery time of the solution. There are many methodologies that support the agile approach, Scrum being the most widely accepted, but not the only one. Other methodologies, such as Lean, Crystal, Kanban, Extreme Programming (XP), Agile Unified Process (AUP), Adaptive Software Development (ASD), and others support the agile principles. However, many are only aware of Scrum and believe it is the only agile methodology.

Just as the agile approach contains a few methodologies, Business Analysis contains a few business services to drive better business outcomes. Notice, I did not use the term ’business solutions’ as Business Analysis is more than about business solutions, it contains a few services outside of information technology projects that deliver business solutions. Business Analysis is about defining and delivering outcomes that is best for the organization; strategically, tactically and operationally.

STRATEGIC ANALYSIS

Strategic analysis is about developing a strategy for a business by examining the organization and the environment in which it operates and determining likely responses to events and changes going on around and within the organization. It’s called strategic because it’s high level and about a long-term direction for the organization. It’s called analysis because it is about breaking something that’s big and complex down into more manageable pieces. There are several business analysis roles within the organization that support strategic initiatives of the organization.

Strategic Analysis Areas

Strategic areas that business analysis plays a role include:

Enterprise/Business Architecture – a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach for the successful development and execution of the organizational strategy.
Enterprise Analysis – the analysis to identify a business need, problem or opportunity, define the nature of a solution to that need, and justify the investment necessary to deliver that solution. Again as a holistic approach for the enterprise.
Business Intelligence – the strategic arm of business analytics, or Prescriptive analytics, it is the use of data to prescribe the best course of action to increase chances of realizing the best outcome for the enterprise.
Market Research – is about looking outside the organization at the market in which the organization operates to look for opportunities and threats from the environment and market(s) and make recommendations for strategic direction to take advantage of the opportunities and mitigate the threats.
Management Consulting – is the practice of helping organizations improve performance through analysis of organizational problems and developing plans to mitigate those problems.
Business Value Management – is a newer and lesser known concept of measuring the value of a business that expands beyond economic profit to include other forms of value such as employee value, customer value, suppler value, channel partner value, alliance partner value, managerial value and societal value.
Product Ownership – is the holder of the Product Vision, the future vision of the firm’s product and the roadmap to achieve that future state. These products may be products that the organization sells in the marketplace or systems in use by the organization.

Strategic Analysis Job Titles

People working in strategic analysis for their company often have a job title such as Enterprise Architect, Business Architect, Enterprise Analyst, Enterprise Business Analyst, Project Portfolio Manager, Research Analyst, Market Analyst, Market Research Analyst, BI Analyst, Management Consultant, Business Value Manager and Product Owner.

Strategic Analysis Tasks

Popular tasks performed by Strategic Analysts include, but not limited to, Organizational Modeling, SWOT Analysis, Market Research, Capability Gap Analysis, Feasibility Studies, Decision Analysis, Business Rules Analysis, Surveys, Process Modeling, Prescriptive Data Analysis, Benchmarking, and Organizational Change Readiness Assessment.

TACTICAL ANALYSIS

Tactical Analysis is where the rubber hits the road; often this is the execution of the strategic analysis recommendations for the company. It includes IT project work, whether Waterfall or Agile methodology is used, Business Analytics, and Product and Change Management. There are several roles in the organization that perform tactical analysis.

Tactical Analysis Areas

Tactical areas that business analysis plays a role include:

IT Business Analysis – this the widely accepted BA role working on IT projects to deliver business solutions to meet a specific business need, problem or opportunity.
Agile Analysis – this role works on IT projects to deliver solutions for the business, but in an environment that uses one of the agile methodologies of software development. The analysis role often moves from one agile team member to another during the iteration in an agile environment.
Business Analytics – is the scientific process of transforming data into insight for making better business decisions, this includes Descriptive and Predictive analytics.
Decision Analysis/Business Rules – an approach to decision-making that examines and models the possible consequences of different decisions. Decision analysis assists in making an optimal decision under conditions of uncertainty.
User Experience (UX) – involves a person’s behaviors, attitudes, and emotions about using a particular product, system or service.
Product Management – is the process of managing the development of a product toward the realization of the product vision and roadmap.
Change Management – is the process of analyzing the organization’s readiness for change and implementing that change.

Tactical Analysis Job Titles

This tactical analysis role is the one that most people think of when they speak of business analysis; more specifically those roles that work on IT projects and have titles like Business Analyst, Business Systems Analyst, Systems Analyst, Technical Analyst, Requirements Engineer, Solution Architect or IT Business Analyst. Other job titles in the tactical analysis area include Agile Analyst, Agile Team Member, Data Analyst, Decision Analyst, User Experience (UX) Specialist, Product Manager, Change Manager and Release Manager.

Tactical Analysis Tasks

Common tasks that these Tactical Analysts perform for their organizations include Observation, Interviews, Surveys/Questionnaires, Focus Group Discussion, Requirements Workshops, Document Analysis, Interface Analysis, Process Modeling, Data Modeling, Data Dictionary, Data Flow Diagraming, Brainstorming, Decision Analysis, Business Rules Analysis, Prototyping, Estimation, Risk Analysis, Structured Walkthrough, Vendor Assessment, Solution Scope Definition, Product Backlog Grooming, Use Cases, User Stories, Personas, Stakeholder Map, Organizational Change Readiness Assessment, Metrics and Key Performance Indicators, Acceptance and Evaluation Criteria Definition, and Lessons Learned.

OPERATIONAL ANALYSIS

Operational analysis is used to determine the efficiency of the business operations. This may include an examination of the company’s production methods, material costs, equipment utilization and workplace conditions.

Operational Analysis Areas

Operational areas in which business analysis plays a role include:

Process Analysis – is the process of analyzing a business process or procedure, finding the waste in the process and determining how to improve it.
Production Support – is providing end user support for IT systems/applications in use by the business.

Most people, even Business Analysts, will find it surprising that I list production support here. These analysts often perform root cause analysis and problem tracking until the issue is resolved. If these tasks are a major portion of your job, then consider yourself a business analyst. On the other hand, if you simply log the issue and pass it on to others to resolve, that is not business analysis.

Operational Analysis Job Titles

Common job titles in this area are Operations Analyst, Business Process Analyst, Process Analyst, Continuous Improvement Analyst, Production Support Analyst, Production Support Specialist, and Help Desk Analyst. As I said above, just because you have one of these job titles does not necessarily make you a business analyst. If you do not perform any of the tasks below, or perform them so rarely during your daily job performance, then you would not fall into a business analysis role despite having the word ‘Analyst’ in your job title.

Operational Analysis Tasks

Tasks that these Operational Analysts perform include Observation, Process Modeling, Document Analysis, Root Cause Analysis and Problem Tracking.

So just because your job title is not Business Analyst or Business Systems Analyst doesn’t mean that you are not a Business Analyst. There are many job titles that perform business analysis activities, and this is increased by those companies that get creative with their job titles. There are job titles in and outside of IT project work that performs business analysis activities. Remember, whether you are a business analyst is determined by the tasks you perform for the company, not by your job title. One way to put it is…

”IT Business Analyst is to Business Analysis
as
Scrum is to Agile”

I do have to add a word of caution here, just because you perform one or more of the business analysis tasks mentioned above rarely during the performance of your work doesn’t necessarily make you a business analyst. Many business analysts do perform other tasks outside of business analysis for their company, but a majority of their work is on business analysis tasks. These are considered hybrid business analysis roles and often are combined with tasks in project management, development and/or quality testing.

Perhaps we should define business analysis in Jeff Foxworthy fashion…”You might be a Business Analyst if…”

Don’t forget to leave your comments below.

Where is the Business Analysis Profession Going?

Written by Aaron Whittenberger on February 4, 2014. Posted in Articles. 1 Comment on Where is the Business Analysis Profession Going?

It is customary that at the start of a new year people reflect upon the past and look into the future. I believe you will agree some people are better at both activities than others. In fact, recently Julian Sammy, Head of Research and Innovation at the IIBA® did both. In this recent article he takes a look at predictions that he and other members of the Senior Leadership Team of the IIBA® made in 2011 about what 2013 will look like. He then takes a look at what he thinks 2016 will look like for the business analysis profession.

So I will jump on the band wagon (because it is a popular thing to do and because I have something to say) and give you a look at what I think the business world will look like for business analysis professionals for the next couple years. Trends take time to develop and take hold so I will take a multi-year look into the future, and why I believe Julian looked three years into the future. You will see my analysis has a heavy tendency toward the tactical IT Business Analyst role because, well let’s face it, that is what I know best; and it is still the largest business analysis role in existence today. Maybe one of my trends should be a prediction of how that will change soon. Ok, I got my crystal ball out, are you ready?

Trend 1 – Agile is here to stay

There are those that still believe that agile is a fad, soon to pass. Sorry, anything that has been here for 10+ years is not a fad. Many fashions (remember bell bottom jeans) are a fad; agile is here to stay. Although acceptance of agile methodologies may stagnate a bit, many of the tools and techniques of agile will find their way into IT project work in many companies; further developing the hybrid project approach.

Resistance of agile acceptance will come from companies that “tried” agile and failed. Some will “try” again or for the first time, some will abstain; yet some will realize you don’t “try” agile, you decide to give it your “all” (all the organizational support it needs) or don’t bother. Further resistance will come from the idea of a 100% dedicated team to one project seems an unwise use of resources in today’s business environment; and agile professionals will struggle to answer that concern to the satisfaction of business management. Also, lack of truly effective Agile Coaches will hinder the willingness of companies to give it a go. This will become a valuable consulting role; if you’re looking to drive your career into a role of the future, consider this one.

Trend 2 – Business agility will demand greater collaboration on IT project teams

Greater demand for quicker IT project delivery times will continue to crunch project schedules and resources. The trend of doing more with less will continue. This will demand greater collaboration among the project team. The BA Team, QA Team and PM will give way to the IT project team; with the BA as the liaison to the business stakeholder. They will all merge into the “core” project team with the responsibility to deliver full functionality, on-time and on-budget. The “we vs. them” mentality will slightly diminish between business and IT, but it will drastically diminish among the IT team itself; gaining greater synergies for a more effective working environment.

Trend 3 – Resurgence of Strategic Enterprise Analysis

Continued dissatisfaction with dismal project success rates will bring about a resurgence of the strategic business analysis role. This role demands a whole different skill set than the traditional IT business analyst. Skills to do market research, capability gap analysis, SWOT analysis, benchmarking and feasibility studies will become in greater demand. The skill to create a bullet-proof business case describing the business value of IT projects will become paramount. This role will work with project approval committees to define for them the business value and risks of projects under review, thereby giving necessary support to project portfolio management.

Trend 4 – The Value of Product Vision gives rise to the Product Owner and Product Manager roles

Product Vision will gain wider acceptance as many will come to the realization that this means more than maintaining future enhancement and feature lists, and product roadmaps. System users will become greater source of future direction of product vision of systems development. Yes, these roles exist today, but primarily in large enterprises. We will see this role gain acceptance in Small to Medium Sized (SMB) companies. Even in large enterprises these roles will gain greater recognition with clear career paths. As these roles gain higher profile recognition, people in the role realize that their value comes in communicating that product vision to all business and IT stakeholders so that all have a shared vision of the future product. For business and IT professionals looking to drive their career, this is another good direction for the future.

Trend 5 – Requirements collaboration tools integrates social media and the desktop

With greater emphasis being put on business agility and greater collaboration on the IT project team, requirements management tools providers will jump on the opportunity, as these tools make the transition to requirements collaboration tools. Transparency of requirements during their development will become enhanced as other members of the project team, including business stakeholders will have that visibility. The requirements tool itself will become the accepted communication tool among the team, allowing them to interactively communicate about the requirements being developed. Yes, some tool providers have already integrated this capability, but organizations will integrate this capability into its business and IT processes, again due to gaining business agility.

The great enhancement in coming years in this area is that these tools will integrate to peoples’ desktop. Imagine being in conversation with a group and needing to schedule a meeting to continue the conversation. Imagine being able to scan everybody’s calendar and having a few suggested dates and times that everyone can make it to the meeting. Upon agreement of a good date and time, imagine everyone in the conversation receiving a calendar meeting invitation moments later; and all this happens right there in one tool. Now imagine that the conversation included vendor personnel who use Lotus Notes calendar while you use Microsoft Outlook; and some participants use Google calendar. Each recipient receives the proper invitation for their calendar.

Finally, the business analyst doesn’t rely on Microsoft Office as their primary requirements tool. Yes, some large, and SMBs, have been past this stage for a few years. However, this trend will become much more wide spread as more and more companies invest in these requirements tools; and those that have had them for a while will invest in the next generation of these tools to gain the benefits of the increased collaboration for their project teams.

Trend 6 – The Business Analyst as Proxy for the Business Stakeholder

In organizations where the Business Analyst reports to IT management and work on IT projects, the company will recognize the value of putting a Business Analyst on the business side to work as a proxy for key business stakeholder(s); this will be an additional BA role within the organization. This will free up the business stakeholder(s) to run the business while their proxy takes on the responsibility of working on IT projects to bring about the change that the key business stakeholder desires. This, of course, means that the business analyst has to not only share the product vision of the business stakeholder, but must understand the ‘what’ and the ‘why’ of all the business change requests with great clarity.

Trend 7 – Businesses increases its Investment in Training

Changes in the business analysis environment will increase at even greater velocity. That along with the increase need of collaboration with a lot of different roles within the business organization will cause business analysts to develop new skill sets. Businesses will continue to see the value in investing in the development of its people, but will look for greater bang for their buck when investing in training for business analysts and other project professionals. Training that take the people away from work for shorter time, allow more people to attend the training for lower cost will see increased utilization over the traditional classroom training class.

Education providers in the space will scramble to beef up their virtual classroom offerings with excellent content, while continuing to offer the traditional classroom training for those organizations that value the in-person interaction with the instructor and other students, and are willing to pay for it.

Local IIBA® chapter professional development days (PDD) will help fill this need as well. PDDs like WI BADD (Wisconsin), I-BADD (Iowa) and SO BARC (Cincinnati, OH) will continue to gain attendance over the next few years. Chapter’s that don’t yet offer this service will see the value and begin to provide this service to their business community. Likewise, local business education providers that have any capability in this space will beef up their business analysis offerings to leverage the opportunity of this trend.

Trend 8 – Business Analysis jobs will continue to be in abundance

With organizations putting focus on business analysis roles, additional roles will prop in those organizations. With the diverse skill set necessary to be effective, business analysis jobs will be in abundance. We will see an influx of people flowing into the business analysis profession from other professions including project management, quality assurance, business and operations. Now the flow will be both ways as people move from business analysis to project management and the other professions, but the flow into business analysis will be greater. Even with that inward flow it will not keep up with the demand for good business analysts, creating even greater demand for training.

Trend 9 – We will see a resurgence of Business Analysis Centers of Excellence

With all these changes in the business analysis space, organizations will also look inward for training for their business analysts and give them opportunities to learn from each other. Business Analysis Communities of Practice (BACoP) and Centers of Excellence (BACoE) showed rapid growth in 2011 and 2012, and stagnated a little in 2013. Organizations will see their value in training and incorporating best practices across lines of business. They will help ensure the same level of service across lines of business. We will see a slight uptake in BACoPs and

Trend 10 – Business Analyst and Project Manager roles will continue to Overlay

As the Project Management Institute (PMI®) continues to expand its teachings into areas like stakeholder management and collecting requirements they will lose focus on their core purpose and core audience. Businesses will realize that requirements, and stakeholders, need more than just management or documentation. They will realize the different skill set and focus (business focus, not project focus) needed to effectively develop requirements from the business and project management will give way to a project leadership mentality. Businesses will see that dual project leadership roles, one focused on the project and one focused on the solution, has greater probability to lead to increased project success rates.
The practitioners that perform these roles, through their professionalism, will find ways to work together for the benefit of the organization no matter the teachings of the PMI® or IIBA®. As for the IIBA® and PMI®; just like David and Goliath, David will

So that’s how I see the next couple of years for business analysis, and related, professionals. Now let’s see how I stack up to the ESI International’s predictions for the

So which do you agree with? What would you add or subtract from the list?

Don’t forget to leave your comments below.

The Top 8 Mistakes in Requirements Elicitation

Written by Aaron Whittenberger on January 21, 2014. Posted in Articles. 1 Comment on The Top 8 Mistakes in Requirements Elicitation

Whether you are an Enterprise Business Analyst, Enterprise/Business Architect, Business Intelligence Analyst, Data Analyst, Process Improvement Analyst, Agile BA Team Member or IT Business Analyst, you work to bring about change within the organization. Sometimes these are small incremental changes, and sometimes these are big changes that require an organizational shift or cultural change. Whether small or large, most of those business analysis roles deal with gathering requirements. One of the key activities of a Business Analyst is to draw out and document business change requirements from stakeholders throughout the organization. As the International Institute of Business Analysis (IIBA®) celebrates their 10th anniversary this year, we are reminded that business analysis as a profession is still maturing, as is the practice of business analysis in many organizations around the world.

As organizations struggle with maturing their business analysis approaches, let’s take a look at some common mistakes that practitioners commit when eliciting requirements from stakeholders.

1. Improper Stakeholder Analysis

Often times resource managers or the Project Management Office (PMO) assigns resources to projects almost as early as the Project Manager (PM) and Business Analyst (BA) are assigned. With these resources the project marches on and the Business Analyst never does a proper and complete Stakeholder Analysis. Stakeholders can be missed because that early in the project all the lines of business within the organization that are affected may not be known. Perhaps as the project moves on, it takes a turn into a new business line; and if the Business Analyst doesn’t recommend that a representative of that business unit be assigned to the project team, then they are not doing their job. If you have stakeholders from one line of business answering for another line of business, you may not have all the business or functional stakeholders engaged in the project that should be.

One of the first activities that the Business Analyst should complete upon being assigned to a project is a Stakeholder Analysis. This helps ensure that the proper stakeholders are engaged in the project. However, a Stakeholder Analysis is not a one-and-you’re-done thing. It is an activity that should be considered throughout the project’s timeframe, especially when elicitation discussions take a turn into a new business area and there isn’t a representative from that business unit on the project team. This is the time for the Business Analyst to raise the red flag, complete a new Stakeholder Analysis, and recommend new resource(s) be engaged on the project.

2. Improper language in the requirements

Business Analysts that work in very large organizations or with very structured teams, especially Quality Assurance teams, have heard that your requirements have to be well structured and testable. Many Business Analysts have been told that requirements have to be SMART: Specific, Measureable, Attainable, Realizable and Time-bound. I worked in one place that advocated that requirements had to be SMART-CC, adding Complete and Concise to the SMART acronym.

Quality Assurance Teams advocate the SMART test for requirements as they want requirements that they can test. Even though, most of the time, QA teams test the solution against the solution (functional and non-functional) requirements, most Business Analysts will attempt to make their business and stakeholder requirements SMART. A lot of times the BA will fall into the trap of expressing the requirement from the technical viewpoint and in technical terms. So they have taken a requirement for/from the business and applied technical terms or changed the viewpoint of the requirement, which adds ambiguity and confusion for the business stakeholders.

Remember the business requirements and stakeholder requirements are primarily from and for the business stakeholders. Even though the technical team will use those requirements, the business is the main consumer of those requirements. Therefore, they should be expressed in business terms and from the business standpoint. Likewise, the solution requirements have to be SMART for testing purposes. The technical teams are the main consumer of those requirements, so they should be expressed in technical terms.

3. Jumping to design before getting the requirements

I have been in many stakeholder requirements elicitation activities where the stakeholders start talking about design and in which system this solution will be implemented. If the BA doesn’t squash those discussions immediately when they start too early, then they tend to multiply and consume the actual elicitation of requirements. Soon you have a design for a solution before you truly understand the business problem you are trying to solve—before you understand the business need.

This tends to put blinders on the entire project team, and everyone marches down the same path toward a solution because that is the only thing the team can see. Once the solution discussions begin, and are not halted by the BA, it tends to give everybody hearing the discussions a single focus, even though they don’t fully understand the business need. Quite often this leads to alternatives to the“initial solution never getting considered. This also leads into my next two mistakes BAs make during elicitation activities.

4. Not guiding the conversation during elicitation with a group of stakeholders

Even with a small group of stakeholders, even in a one-on-one stakeholder interview, discussions can go off course onto tangents that are not relevant to business needs. Sometimes the conversation can be so far off course that it is not even relevant to the present project. These conversations tend to distract from the task at hand and waste time during requirements discussions. It can cause stakeholders to become frustrated with the process and become disengaged with the project, as they find better use of their time than to continually hear a couple of people dominate the conversation with what they did over the weekend or other irrelevant topics. Another distraction is when there are two or three conversations going on in the room. Of course, all these issues compound as the number of stakeholders in the conversation increases.

Part of the task of the facilitator is to keep the discussion on topic. When the conversation goes off on a tangent, it can be difficult to find the proper time to rope it back in. The sooner the facilitator brings the conversation back on topic, the less likely further discussions will stray off, the less time is lost, and the more engaged your stakeholders stay in the project.

5. Getting approval for the requirements without a shared understanding of them

With today’s tight project schedules, often times the requirements approval process is rushed so much that ensuring that all stakeholders, business and technical, understand the requirements in the same way is difficult. With stakeholders coming from different viewpoints, ensuring that they all understand the requirements is a task in itself. A structured requirements walk-through will go a long way in accomplishing this task. As everyone in the walk-through hears comments from other stakeholders, a common understanding begins to take form. The stakeholders learn how others view the requirements.

6. Feeling requirements must be 100% complete and accurate before sharing with the stakeholders

Novice Business Analysts can fall into the trap of feeling that the requirements that they are documenting must be 100% correct before they share them with anyone. They feel that any corrections or changes to the requirements mean that they did not do their job correctly. So in an effort to make sure they are correct, they go talk to more stakeholders. They make sure to elicit from everybody in the organization. Then before you know it, the project is in analysis paralysis.

BA Managers have to ensure that there are no performance measures on the BA’s evaluation that measure changes to requirements. It is not a good measure of how well the BA did the job of elicitation. The BA themselves have to remember that they are one person and they cannot know everything. Changes to requirements are not any indication of how well the task of elicitation was done. Using a more collaborative approach to requirements elicitation, where the requirements are more visible throughout the process, is a better approach to ensuring the requirements represent what the business actually needs.

7. Not building trust with stakeholders

Often times BAs move from one project to the next, have four projects going on at once, and don’t take the time to get to know new stakeholders that they had not previously worked with. Getting to know the new people who you are working helps you understand their viewpoint and agenda. This will certainly help if conflict arises during elicitation. Understanding each person’s viewpoint will help the BA resolve the conflict by helping each person to understand the other viewpoints in the conversation. The BA cannot accomplish this if they do not understand the viewpoints in question. Taking the time to get to know someone shows them that you value their input and participation in the project.

8. Blindly using a template

I was recently handed a Business Requirements Document (BRD) template that had several categories of requirements including documentation, reliability, scalability and training, among others. All of these categories are non-functional, or solution, requirements—and as I said this was in the BRD template. Recognize the fact that these are solution requirements and do not have any place in the BRD. If you receive a BRD like this, remove these categories or mark “N/A” or “Will be defined during design and included in the Functional Requirements” in each category. If you do the latter, check the Functional Requirements document template to ensure that the category is in that template as well. If not, add it. Don’t blindly use a template just because that is what the organization uses. Don’t try to define solution requirements during business requirements. How do you know what your training needs are if you don’t know what the solution is? BAs are agents of change. Challenge the template and help the decision makers in the organization see the value of a correct template.

Conclusion

To do an effective job at requirements elicitation, avoid these traps that can get your activities off track. Be sure you have everyone in the conversation that should be, define the business need before designing the solution, ensure that there is a shared vision of the requirements, and document the requirements in a collaborative approach with the project team. This will help ensure that you do an effective job at eliciting the requirements for your organization.
So there is my list, what is yours?

Don’t forget to leave your comments below.