Generic Questions for Interviewing Stakeholders

88477 Views
2 Comments
67 Likes

The purpose of this article is to assist the business analyst engaged in the elicitation of stakeholder requirements. The key to any successful elicitation is asking the right questions whether it be in interviews or a facilitation session. Although the right questions are dependent on the solution scope, there are generic questions that the business analyst can use to start the elicitation regardless of the solution scope. The author begins the article using a mind map to capture keywords of generic questions and then provides a list of generic questions drawn from that map of which specific solution scope questions can be added by the business analyst.

As a professional instructor for business analysis and project management, I am often asked by students what questions they should ask stakeholders during the elicitation interviews. Of course the answer is that it depends on the solution scope. However, the business analysis team can use a list of generic questions as a start for all the interviews.

With this in mind, I have developed a list of generic questions. I started first with a mind map to organize my thoughts. With the purpose (Stakeholder Interview Questions) in the center of the map, I branched out in four need directions or threads: Business, Capabilities, Change, and System. For the first three threads, I associated targets of key stakeholder, user and sponsor. For needs involving a system, I associated targets of conditions and legacy; assistance from a systems analyst may be needed for these targets. Then for each target, I related question keywords. Note that the project manager may be the more appropriate role to cover the change branch since it deals with project execution questions even though solution scope changes may be discussed.

The mind map (Figure 1) is below, followed by a list of questions derived from the map keywords.

Stakeholder Interview Questions - Mindmap

 

Key Stakeholder Purpose is to capture business requirements that trace back to the stated business needs provided in the project vision and scope.
Key Questions - Purpose is to capture business requirements that trace back to the stated business needs provided in the project vision and scope.
  • Describe how your organization fits into the company?
  • How does your organization contribute to the strategic plan of your company?
  • Where are your organization’s locations?
  • What is your management organization structure?
  • What are the processes of your organization? What business decisions (business rules) are made in your processes? Who owns the processes? What process measurements are used? What regulations are abided by?
  • Who are your suppliers and what do they provide your organization? Who are your customers (internal/external) and what does your organization provide them?
  • How does the organization measure its success?
  • How does the organization obtain feedback from its customers?
  • Are there any significant organization events during the year?
  • What is the single item which will make this organization more successful?
  • What is the single item which will make this organization less successful?
  • On a scale of 1 to 10 (10 being highest) where would you put this organization regarding the risk to the company and why?
  • What doesn't get enough (or gets too much) attention in the organization?
User Questions Purpose is to capture user requirements for later analysis. During analysis, the business analyst develops solution requirements.
If a system solution is needed, then system functional requirements that describe the capabilities of the system are a result of the analysis. These system functional requirements must trace back to the user requirement which in turn trace back to the business requirements.
  • Describe your role in the organization?
  • What are your major responsibilities? What business decisions (business rules) do you make in your job?
  • With whom do you interact to carry out your responsibilities?
  • What information do you use in your job? What forms do you use?
  • What computer systems do you use in your job? Are there any events for which the system provides alerts? Are there any new alerts needed?
  • How do you measure success in your job?
  • What is occurring that is helping/inhibiting you to do your job?
  • What skills are needed in your present job?
  • What training did you receive for your present job?
  • What would you change about the way you carry out your responsibilities?
  • What do you see as the major critical issues facing the organization?
  • What areas for improvement have you observed?
Condition Questions
(assuming system solution)
Purpose is to capture the environmental conditions that are needed along with the capabilities of the system. These are referred to as nonfunctional requirements or possibly quality of service requirements if used in a service level agreement.
Purpose is to capture the environmental conditions that are needed along with the capabilities of the system. These are referred to as nonfunctional requirements or possibly quality of service requirements if used in a service level agreement.
  • How quick do you need for the system to respond?
  • How many users will use the system at the same time? What is the user growth expected?
  • When does the system need to be available?
  • Are there any environmental considerations for the system (weather, heat, cold, sunlight, humidity, power, etc.)?
  • What type of on-line help is needed for novices? What short-cuts are needed for power users?
  • What formal system training is needed? What formal system documentation is needed?
  • What frequency of backups is needed? How long do transactions need to be retained? For extensive outages, what disaster backup and recovery are needed?
  • What level of security is needed? What audit requirements are needed?
Legacy Questions
(assuming migration from an old to a new system)
Purpose is to capture system transition requirements needed for a smooth system implementation. These requirements are one-time events needed for production cutover.
Purpose is to capture system transition requirements needed for a smooth system implementation. These requirements are one-time events needed for production cutover.
  • Does a legacy system need to continue for a period of time after the new system is implemented?
  • Do any data files or business rules need to be converted upon implementation of the new system?
Sponsor Questions Purpose is to capture feedback how change needs to be managed and if there is any possibility for improvements to the project.
Purpose is to capture feedback how change needs to be managed and if there is any possibility for improvements to the project.
  • In your opinion what are the project risks? What are the chances of success vs. failure? Why?
  • How will you measure the success of the project? How will you measure the success of the business impact of the project?
  • If you received additional funding for this project, what would you do with it?
  • If you received additional time for the project, what would you do?
  • What items could be discarded from the project plan and no one would notice or care?
  • If you could have anyone in the world work on this project, who would it be and why would you want that person?
  • What information do you want to keep abreast concerning this project?
  • How often and by what means would you prefer to be informed about this project?

I recommend the business analysis team start with this generic list and augment it with solution scope specific questions. During or after elicitation, the team then needs to validate and analyze the answers and develop solution requirements using appropriate modeling and traceability techniques. Good luck with your interviews.


7Author: Mark Monteleone

Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSMTM) and Certified Scrum Product Owner (CSPOTM) by the Scrum Alliance. He holds an Advanced Master's Certificate in Project Management and a Business Analyst Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF). Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail - [email protected].

Like this article:
  67 members liked this article
88477 Views
2 Comments
67 Likes

COMMENTS

Tony Markos posted on Saturday, October 17, 2009 12:08 PM
Very good article. You emphasize the "Business" in Business Analysis. BA's today are often too focused in implementation issues (such as creation of UML models).

One suggestion: Especially for larger scale systems, when discussing the need for process definition, a heavy emphasis should be place also talking about the need to rigorously identify how each process interrelates to the others. Without such emphasis, this all important step is highly shiort changed

Tony
ajmarkos
Tim Bryce posted on Monday, October 26, 2009 8:11 AM
Good for project management and lacks substance regarding specifying information requirements. Good beginning but needs to go farther.

All the Best,
Tim Bryce
Palm Harbor, FL, USA
timbryce
Only registered users may post comments.

 



 




Copyright 2006-2024 by Modern Analyst Media LLC