I promised that I would explain why questions that focus on your stakeholders business could deliver you better results.
Out of the correct approach to elicitation you collect data that provides you with an understanding of your stakeholders’ business. It also accurately informs you about how their problems might be solved through process or technology changes.
I can best explain this using an example. Say you’re gathering requirements to implement a new analytics and reporting platform. Consider the following two scenarios.
Business Analyst: Do you want Business Objects or Cognos BI? What do you think of Oracle Reports?
Stakeholder: Huh? I just want a system that gives me my report.
Business Analyst: OK. What do you want on your report? Do you actually want a report or do you prefer a dashboard?
Stakeholder: I don’t know. Show me what it looks like.
Business Analyst: What is your role in the organisation?
Stakeholder: Manager of mining operations. I oversee all mining operations for the Acme Mine. This includes safety, environment and regulatory reporting.
Business Analyst: Where do you work most of the time?
Stakeholder: I divide my time between the head office and the mine. Some overseas travel is required.
Business Analyst: What types of decisions do you make on a daily basis?
Stakeholder: [The mine manager explains a wide range of decisions]
Business Analyst: What type of information do you need to make each of these decisions?
Stakeholder: [The mine manager explains the types of information needed to support his or her decisions]
Business Analyst: How do you get that information?
Stakeholder: From data kept in Acme’s process control system, environmental reporting system, other management systems, various spreadsheets, reports, emails and hand written logs. The data is collated and sent to me in reports containing production statistics, scorecards, graphs and written analysis.
Business Analyst: Why do you need this information?
Stakeholder: So I can ensure the profitable, safe and sustainable operation of the mine. To make sure that this is done in line with government regulations and the mining company’s strategic plan.
Business Analyst: What is your main pain point with the current process?
Stakeholder: It takes 2 days to produce a report when I need the information almost immediately.
Business Analyst: Why does it take two days to receive your reports?
And so on…
The first scenario is an exaggerated demonstration of how not to conduct your questioning process. This is because it focuses on a solution without trying to understand the real need of the business. The solution matters later when assessing various technology options against your stakeholders’ requirements. But first, you need those requirements.
The second scenario demonstrates the correct approach to eliciting requirements by focusing your attention on the stakeholders’ business. From the above information you may be able to derive that “as a mine manager, he or she needs to access (from anywhere) scorecards that allows him or her to make instant decisions about the operation of the mine in real time.” This requirement would be expanded to support each decision and information requirement of the mine manager.
Further, from this questioning technique much can be gained from the type of reporting system that needs to be implemented. Here are 2 basic examples of system requirements that could be further validated and prioritised by your stakeholders:
“The system must provide real-time operational scorecards.”
“System reports and scorecards must be accessible via mobile devices.”
This is an example of how you can produce good results in eliciting requirements.