Elicitation (BABOK KA)

Business people call remote meetings virtual or on-line sessions, or simply conference calls. For many years we have been utilizing this form of communications to save time and money. Due to the global virus pandemic, remote meetings are now not just convenient, but a necessity for maintaining social distancing. Fortunately we have technology that assists us in managing these remote sessions to not only hear the stakeholders, but see them as well. However, remote stakeholder interviewing and meetings have their additional challenges beyond face-to-face encounters. Regardless of the technology used, we need to be keenly aware of these additional negative risks and pursue mitigations.

While the IIBA-AAC exam is not the most challenging exam that I've ever taken, it does require you to have a very specific type of understanding of the Agile Extension to the BABOK Guide. Though it's not a requirement, I recommend taking an exam prep course to increase your chances of passing the exam. Those who did not initially pass the exam reported that they underestimated the exam and figured that they would be able to rely on their agile experience to pass the exam. WRONG!! In fact, the exam doesn't focus much on the details of agile ceremonies or daily activities, but more so on the general principles of agile business analysis.

 “Clean Language” is a conversation technique developed by a psychotherapist, David Grove. It is a method of asking neutral questions to avoid influencing patient responses. Besides psychotherapy, clean language can be used in various fields for interviewing and facilitating meetings with stakeholders. This is particularly true for business analysis. The context of this article is interviewing and facilitating meeting with a focus on using clean language to ensure that stakeholder requirements are captured without the influence of the business analyst. In this article, you will note that I have cited several sidebar comments to help the reader connect the dots with various business analysis aspects.

Learning about mental models and how to apply them to their work is one of the best investments for business analysts interested in achieving the level of deep thinking that leads to better outcomes for their projects and organizations.  There is incredible power in using inversion at the outset of a project to imagine ourselves in a future where the solution has not only been delivered, but is in the hands of end-users to get their job done. Rather than simply going through the typical project phases in forward motion, we can then look backward and gain additional perspective into what might go wrong so that preventive steps can be taken to avoid those bad outcomes.

Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.

One of the three activities encompassed under Requirements Analysis is the process of ‘ Requirements elicitation’. IIBA’s definition of ‘elicitation’ is “An activity within requirements development that identifies sources for requirements and then uses elicitation techniques to gather requirements from those sources.”

However, this definition appears incomplete from an analyst’s point of view as it relies solely on the assumption that one can come up with requirements only by running elicitation techniques; however, the process of elicitation is not as simple and straightforward as it seems. Let’s see why.

This article provides high-level steps for eliciting requirements when interviewing or holding a facilitated meeting with stakeholders; it was motivated by an attendee question at a recent Modern Analyst webinar: “Functional vs. Nonfunctional requirements.”  The question was, “Can a Business Analyst elicit functional and nonfunctional requirements in the same iteration?” 

In a classic business analyst universe, requirements are the soul of all the work a business analyst does. If a business analyst fails to identify and translate the right requirements, they’re out of a job. This is the reason why a successful business analyst is always good at requirements handling/management process. What makes requirements...

Project statistics state that most project rework/failure is due to incomplete/improper/unclear requirements, hence the role the Business Analyst becomes even more critical as they shoulder a huge responsibility of eliciting and collaborating with the stakeholders to obtain clear, concise and complete requirements.  The elicitation and collaboration knowledge area focuses on drawing forth or receiving information from stakeholders and other sources by directly interacting with stakeholders, researching topics, experimenting or simply being handed information.

Chaos! Stress! Everyday mess! Isn’t this an everyday situation for a business analyst? If not, either you’ve job satisfaction or you’re not being introduced to the real world of business analysis.

A person might possess great skills, however, (s)he might not be able to utilize skills without the right mix of tools and environment. A toolbox enables a person to implement the skills in the most efficient way. Possessing necessary tools is just the one part of it. Another is the knowledge to utilize the right tools at the right time to cater the solution and ensure timely committed delivery.

What are these tools? How do we map the usage of tools to the given circumstance? How can we efficiently utilize the tool? Does it depend on the solution or the approach?

During a recent presentation to business analysts, I used one of my consulting projects as an example of how to apply an analysis technique we were discussing. A member of the audience asked, “What made this company hire you as a BA consultant to tackle this project, when they already have so many in-house product managers and business analysts on their teams?”

Prior to proceeding with a strategic project, project leadership needs to ensure that the project still:

• aligns with the direction of the business entity, and
• fits the needs of the targeted customer segment,
  as it did when the project was an initiative. This brief article starts at the inception of an initiative during Enterprise Analysis to the validation of a strategic project prior to kickoff. Note in this article, I include both the private and public sectors when I use the terms such as “business entity” and “customer segments.”

Ground rules are essential for any meeting. It may be what makes the meeting a success or failure. As a Business Analyst we are constantly organizing and facilitating meetings of various sizes to progress through the SDM (System Design Methodology) for a project. It is important that all sponsors and participants of the project understand what to expect from the upcoming meetings to be organized. Ground rules are generally discussed during the kickoff meeting, documented, and then displayed moving forward.

A common challenge of enterprise Business Analysts is the discovery, understanding, and description of requirements in the context of implementing packaged solutions. Management assigns us to projects with a predefined solution, and we struggle to figure our role when there seems to be no significant build activity. What are we supposed to do in this situation when there seems to be no need to produce standard requirement deliverables?

 

Put a typical Business Analyst in this environment and do not be surprised to hear the phrase “I’m not sure of my role.” Why do packaged solution projects cause discomfort?