April's article discussed the importance of understanding your organization's overall business goals, and May's piece covered how to create a common vocabulary among your project team. This month, for my third in the five-article series, I'd like to discuss something that can often get overlooked in the business analysis process: properly identifying the sources from which you will eventually extract your requirements.
When we're kids, we're told that labeling people is bad. Well, this is good advice in life, but not necessarily in business analysis. The fact is, properly identifying and affixing your sources to specific categories is essential for planning and successfully extracting requirements. Although there are none that are set in stone, three common categories that I've used to label sources on past projects include: Customers, Users and Additional Materials and Experts. In this example, all of your sources would fit into one or more of these three buckets:
A customer is the person or group, internal or external to your organization, likely to pay for the products and services produced. This category can be further refined to include subcategories such as sponsors and champions, or domestic and international customers. The further you're able to refine your categories, the better.
A user is the person or group who is ultimately responsible for interacting with the products or services produced. Like customers, there's definitely room for further refinement here. For example, direct users may touch and manipulate the system on a daily basis, while indirect users may simply request monthly or quarterly reports. Both groups will yield distinctly different requirements.
Additional Materials and Experts
This category is more than just a fancy name for Other. It could include additional individuals or groups with influence on the project, such as third-party vendors and subject-matter experts. It's also important to note that your sources don't necessarily even have to be humans. And no, I'm not talking about robots-at least not yet. There are many non-human sources that would fit into this category that you can leverage when extracting requirements. These could include existing systems, both hardware and software, or existing documentation, such as governance documents, previously captured business architectures, training manuals and service agreements.
A One- or Two-Person Job
In my last article, I encouraged group thinking for the development of a project's glossary of terms. For labeling and categorizing your sources, I recommend essentially the exact opposite strategy. Like building a glossary, categorizing sources is busy work, but it's busy work that should be taken on by as few people as possible; I'd recommend just the business analyst and, if he or she is feeling collaborative, the project manager. Too many opinions too early can lead to roadblocks of disagreement and the always dreaded analysis paralysis.
Within the categories, the business analysts should also identify each source's role and then the benefits that each source will realize from the completed products or services. The phrase "no stone shall go unturned" applies well here, because eventually everyone on your list-from the daily direct users to the software developer at your partner company to the CEO of your organization-will be affected by what you're creating. So, start with the big picture, and then become as specific as you can. Inevitably, you'll find that some of your sources fall into more than one category. This is not a problem, and is to be expected.
Once you've created your detailed list of categorized sources, you should share that list with the team for feedback
Is It Worth It?
In our need-it-yesterday business culture, your temptation may be to just start calling and e-mailing your sources and asking them questions about their requirements. But remember, business analysis is about planning, preparation and clarity. By going through the process of labeling and categorizing your sources, you and the project manager will begin to get a clear picture of the scope of your project and the amount of time, money and effort that will be required for successfully eliciting requirements. You'll also be able to identify the risks involved. For example, if you find that 60 percent of your sources are located in another country and many of them don't speak your language, well, you're going to have some extra work to do. It's best to realize that from the beginning as opposed to three months in.
Next Month-Choosing the Best Elicitation Techniques
How's this for a cliffhanger? Labeling and categorizing your sources is also essential for helping you identify the best techniques to use for requirements elicitation. Of course, this just so happens to be the topic for the next article in this series, which will appear here next month. Until then, remember, the more specific you are in your labeling and categorizing, the more valuable the information you'll have at your disposal later.
Glenn R. Brûlé has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. As the Director at Large for the International Institute of Business Analysis (IIBA), Brûlé's primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries, including financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.