Stakeholders know everything but just can’t express the requirements
Stakeholders explaining the requirements reasonably well during the elicitation phase is taken for-granted. But, what if they can’t express the requirements or can’t express it well enough? What would you do in that situation?
I faced this situation while working on a project for a large commercial bank. Internet banking was new to the bank and even to the country. Everyone was used to traditional banking. During the first few meetings, we got more confused about what was needed? So, we stopped those meetings and brainstormed to find a way.
This blog is based on my experience in that particular project. Of course, I have added a few more approaches based on my experience and learnings. The approaches mentioned below is not in any particular order.
These approaches can be used individually or a combination can be used on a case to case basis. Here are 3 approaches:
Simulated demonstration to evoke reactions
If they can’t express, make them react, at least they are not dead – Anonymous
I will start with the approach, our team took in the internet banking project. Even though, it was new to that country, it was being used elsewhere. We had recently done a similar project for an Indian bank. So, we decided to use it.
With some white labelling and configurations, we modified the product and conducted a detailed walk through with that. It was an instant success as bank officials could say – what’s needed and what’s not? We were able to finish the elicitation phase within a couple of weeks.
This approach was effective in this case for two reasons:
- We had a similar product ready to use (of course, you may need white labelling)
- The bank officials were available for the meetings for the entire duration
What if, you don’t have a ready product for demonstration?
Use job shadowing to witness and prototype
Job shadowing is an elicitation technique, which involves observing the stakeholders doing their day-to-day activities. That provides the business analysts the opportunity to understand the nature and details of the work.
This understanding can be then be used to create prototypes (with workflows). The prototypes, then can be demonstrated to the stakeholders in walk through sessions to help them react and confirm the requirements.
Get the stakeholders express using collaborative games
Collaborative games are wonderful tools. These games can be used to elicit information like high level features – a good starting point for any system study.
Games like product box can help stakeholders in identifying the high level features of the proposed product. This is achieved by asking them to imagine themselves in a trade show selling the product by explaining the features.
This helps business analysts also in understanding in customer’s own words – what’s important for them? By default, the focus is on understanding business objectives and goals.
Visit this product box page to know more and try a game as well.
Speedboat, Spider Web, Affinity Map, Fishbowl, Buy a feature are some of the examples of collaborative games. Affinity Map and Fishbowl are also mentioned in the IIBA BABOK v3 guide as techniques for elicitation.
Do you have any other ideas, do share?
About Techcanvass
Techcanvass offers IT certification courses for professionals. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.
Our ECBA Certification training program is a well structured course, which not only helps you in becoming a Business Analyst but also helps you in getting prepared for ECBA Certification.
