In previous articles, I have discussed how Business Analysis has suffered an identity crisis of sorts. But if there’s one area which people think is core to Business Analysis, it is most likely summed up by the Elicitation and Collaboration Knowledge Area. You’d think I’d be cheering for that. Not quite.

Business Analysis involves so much more than determining and confirming requirements. Yet without Elicitation and Collaboration, much of the analysis effort could not even begin. In many ways, this is often a starting point for getting into the “what are we going to do” for this product, where Planning and Monitoring (KA-1, which I also wrote about previously) tends more toward administrative endeavors – determining how is the Business Analyst going to do their job.

The Elicitation and Collaboration Knowledge Area describes the tasks to be used to gather information and verify findings. Elicitation must be a multi-directional process, which is why it is paired with Collaboration. The ideas discussed from one stakeholder often influence discussions with others. As the saying goes, “Everyone is smarter than anyone,” and that saying could be a model for Elicitation and Collaboration. Involving everyone (or representatives of constituent groups) in the best way possible, whether by one-on-one interviews, focus groups, JAD sessions, surveys, or other means, is the primary task of this Knowledge Area. And the primary result of that effort is the gathering of requirements and supporting documentation. 

But it doesn’t end with the stakeholders as the sole focus of elicitation. Collaboration with the development team and other technical or support elements is also a critical aspect of this Knowledge Area. This additional feedback will make the resulting product successful. Without it, not so much.

So, with Elicitation and Collaboration in mind, we will look at how the Six Core Concepts apply.

Change

Here, the word “Change” refers to the scope of the analysis. It is the definition of what the analysis effort is intending to explore. During Elicitation and Collaboration, the analysis will collect and determine the characteristics of the “Change,” including impacts and concerns. Several factors can determine the techniques and depth of the Elicitation and Collaboration effort, including environmental factors, cultural factors, stakeholder’s interests, existing documentation and the nature of the change. So the Core Concept of “Change,” when applied to Elicitation and Collaboration, involves assembling all the details surrounding the requested “change.” I know that sounds a bit cyclic. Yet, when you get past that, the Core Concept of “Change” is the primary boundary and driver for the other six Core Concepts during Elicitation and Collaboration.

You may be thinking that all 6 Core Concepts are supposed to be viewed as equal within the BACCM. However, I didn’t elevate Change over the others. Change does provide a boundary and a driver for everything else. But everything else also helps define what Change is, so it all comes around.

Context

Context is always present and must be understood. 

Say someone built a great Lawn Mower. It’s Zero-Turn, rugged, has a 70″ cutting area, and has mulching capabilities. And – get this – it is Self Driving. Just lay back and drink your lemonade (or whatever) while it runs circles around your hammock. And when you think it doesn’t get better – get this – it’s Solar Powered. Well, technically, it’s battery-powered but uses a Solar charging station. So there’s no engine noise, no emissions, and no runs to the gas station with the smell stinking up your car. And since it’s a mulching mower, there are no cuttings to worry about. This mower won’t spray you with clippings while you’re drinking that lemonade in the hammock. It runs for 4 hours when it’s batteries are fully charged. It finishes your yard in 40 minutes. Attachments include a built-in edger and trimmer. Life is good! 

But the project which funded this great device was NASA’s next deep-space mission. As great as the Driverless, Solar Powered, Mulching, Edging, Trimming Lawn Mower sounds (whisper-quiet actually, so it doesn’t sound), it’s probably not a good fit for what NASA has in mind. Although many possibilities have been discovered in what NASA calls “the Goldilocks Zone” (not too hot, not too cold), we’ve yet to find vegetation on other planets. The time spent developing this machine was wasted and has delayed the multi-billion dollar space exploration project for a year. The developer of the super-mower just got charged with obfuscation of government funds and will likely serve ten years. 

Putting aside the silliness of the above scenario, the point does remain – Context can mean everything to the success or failure of the project. Whatever the team does must fit the context. Things like the platform, security, legal requirements, existing assets, existing capabilities and a host of other contextual factors affect the Solution. And there’s only one way to discover what the context is – Elicitation and Collaboration.

Need

One could take the view that “Need” would refer to “why do we need this change.” That would be an incomplete view of what Need means to Elicitation and Collaboration. A better understanding would include every aspect needed for the change to be successful. That would include everything from process redesign, to resources, to systems design and implementations and more, in the detail that defines the Need, or requirement, completely. So, the Core Concept of “Need” forms the backbone of the requirements that we are attempting to identify and define. This is tied closely to “Change” in that one could say that the collection of all the identified Needs are required to enable the Change to become a reality. To make the point a little more directly as it relates to the Knowledge Area, Elicitation and Collaboration is not complete until all of the Needs have been fully defined.

Solution

The focus of this Knowledge Area is to collect the information, to translate into ideas, refining those ideas into requirements, finally communicating and confirming those requirements into the Solution. We started with the desire for a “Change” – which could be viewed as a response to a business need (or high-level requirement). The Solution is the end goal – it answers, “What are we going to do about it?” Any solution which was not derived from a full understanding of all of the other Core Concepts will be incomplete. So, Solution is the output of Elicitation and Collaboration.

If the goal was to help the disabled live in their homes in a self-sufficient manner, including enabling them to maintain their yards, one part of the solution could be a self-driving, solar-powered, mulching, edging and trimming mower.

Yes, I had to find a way to re-use that product. But this isn’t a complete solution to the stated need. All analogies have their breaking point.

Stakeholder

One of the primary sources for information on the Needs for this Change, the Stakeholders are the ones who must sign-off on the requirements, as well as on the final product. As such, it is necessary to gather their thoughts, concerns, and insights. It is also important to collect what will satisfy them, that the proposed solution is the one which will meet their expectations and needs.

Value

Through Elicitation and Collaboration, consultation with various stakeholders will help to define “Value” for the change. Defining Value doesn’t just stop at determining what is relevant to the stakeholders. It involves understanding how value relates to the change as a whole. And it also involves using the Value of the proposed solution as a benchmark measure of the success or shortfall of the implementation. In other words, Value determines whether the Solution is the right one, whether it meets expectations, and whether it was implemented in the right way. Without Elicitation and Collaboration, the analysis would have no actionable guide for this.

BABOK v3, ch4

• BA Certification
• BACCM
• Business Analysis