Effective business analysts should explore a variety of skills and habits to maintain and improve their skills and capabilities.
Being a successful Business Analyst (BA) requires a variety of different skills and be adaptable to a changing environment. Every BA will bring their unique blend of skills and experience to the role, some foundational and others that are essential to improve effectiveness.
Color Inside the Lines
Many projects suffer from scope creep, growing ever larger, sometimes out of control. But many of those projects never clearly defined their intended scope, the boundary between what’s in and what’s out. It’s hard to even know if the issue is scope creep if stakeholders never agreed upon— and documented—the scope in the first place.
Begin all requirements exploration with the project’s business requirements. Why is the organization undertaking this project? What benefits do they hope it will provide to them and their customers? Can the managers state a concise vision of what the overall product will be and do? Without understanding the business objectives, the critical question whenever someone proposes a feature: “Is this in scope?” will not be answered. A structured vision and scope document can store this guiding project information. Templates for various requirements deliverables are available at https://www.processimpact.com/goodies.html
Most teams follow an iterative process for software development, so define the scope of the first release or iteration as a subset of the final product. Describe a growth path from this initial release toward the ultimate product vision through a series of iterations. Document any known limitations, such as functionality that was NOT intended, but which some stakeholder might expect. Such expectation management can help prevent unpleasant surprises at the project’s end.
Ask Revealing Questions
The worst question one can ask during a requirements elicitation discussion is “What do you want?” The second-worst question is “What are your requirements?” Nobody knows how to answer questions like that. The BA needs to actively facilitate discussions with users to pull out the pertinent knowledge.
Users naturally focus on the system’s normal, expected behaviors for common tasks. An effective BA should ask questions to explore possible alternative ways a user might want to perform some task and related tasks. Questions that begin “Would anyone ever need to…” can reveal requirements nobody thought to mention yet.
If a user says “The default should be …” he’s probably describing the normal flow or most common scenario for a use case. A phrase like “The user should also have the option to …” suggests an alternative flow or scenario. These alternatives might have lower priority, so target them for later implementation. Beginning prioritization very early helps the team focus on delivering the minimum necessary solution as soon as possible.
In addition, ask questions about possible error conditions that could arise and how the system should respond. If a user says the system should be “robust,” he means it needs to handle erroneous input and unexpected situations sensibly. If the BA does not explore exceptions as part of requirements discovery, the only hope is the developers will think of them and make a reasonable guess as to how the system should handle them.
Business analysts are not simply scribes; they must be creative and suggest ideas and alternatives to users during elicitation. Analysts can often think out of the box that limits the creativity of people who are too close to the problem. Watch out for gold-plating, though. This is the temptation to add extra functionality that just seems cool or somehow necessary. If the team does not know how the functionality will be used or why it’s there, that functionality is not needed.
An effective analyst can think at multiple levels of abstraction, generalizing a specific user’s request into a set of related requirements that will satisfy a broader range of needs. Judge when to drill down into specifics from a vaguely stated need. The more guidance a BA can provide the developers about what to build, the less guessing they’ll have to do, and the less time they’ll need to spend chasing down answers from users and the BA.
Prioritize Early and Often
All stakeholders think their requirements should have the top priority, but no one can build everything at once. Analysts must work with customers to define feature priorities, so the team can implement the most critical functionality first. One BA responsibility is to facilitate negotiation among stakeholders to make sensible priority decisions. The elicitation group should early on how to assign requirements to priority categories to make sure things get built in the right order.
Early in requirements development, identify the various user classes— and other, non-user stakeholders—that might contribute requirements. Determine which user classes are “favored.” Meeting their needs is most closely aligned with achieving the project’s business objectives. The favored user classes take precedence if you encounter conflicts in the requirements or the priorities coming from different groups.
One effective strategy is to begin by working with any/all product champions to identify their major use cases, or user stories. Perform a first-cut prioritization on those user requirements to determine which ones to explore in detail first. The top priority requirements are those that are both the most important (capabilities the users really need) and the most urgent (capabilities the users need right away).
One truism of software development is that requirements will change during development. View the backlog of requirements as dynamic, ebbing and flowing as reality happens. Re-prioritize requirements as changes come in to make sure the team delivers the maximum customer value as quickly as possible.
Continually Develop Skills
A competent BA must combine communication, facilitation, and interpersonal skills with some technical and business domain knowledge. These capabilities are particularly important:
- Listening skills, to understand what people say and to sense what they might not be saying
- Interviewing techniques, to talk with individuals and groups about their needs
- Facilitation techniques, to lead elicitation workshops
- Writing skills, to communicate information effectively to users, managers, and technical staff
- Modeling skills, to represent knowledge in visual forms that augment natural language text
- Organizational skills, to structure and manage the vast array of information collected during requirements discussions
- Interpersonal skills, to negotiate priorities and resolve conflicts among stakeholders
- Domain knowledge, to have credibility with user representatives and converse effectively with them
Do a self-evaluation of current skills and choose one or two areas to strengthen. The list on pages 65–67 of Software Requirements, 3rd Edition, is a great place to start. Then, commit to learning more in each of those areas and actively trying to practice those new skills on the next project or iteration.
A more structured way to enhance BA skills is to pursue a professional certification in business analysis. There are many to choose from, including the following.
- The International Institute of Business Analysis (IIBA) has several levels of certification, including Entry Certificate in Business Analysis (ECBA), Certification of Capability in Business Analysis (CCBA), and Certified Business Analysis Professional (CBAP).
- The Project Management Institute (PMI) has the Professional in Business Analysis (PMI-PBA) certification.
- The International Requirements Engineering Board (IREB) offers the Certified Professional for Requirements Engineering (CPRE) credential.
- A series of business analysis certifications are available from the British Computer Society (BCS) at the beginner, practitioner, professional, consultant, and expert levels.
Holding one or more certifications demonstrates a serious level of commitment to accumulating the knowledge and experience of a true business analysis professional.
Conclusion
Few project roles are more challenging than that of business analyst. Few are more critical Requirements aren’t just lying around waiting for someone to collect them. At best, requirements exist as fragments in the minds of users, visionaries, and developers. The BA’s job is to gently extract them, massage them into a usable form, and communicate them to the project stakeholders for action.
