Business Analysis Thought Leadership - Articles



BA ARTICLE ARCHIVE
» July 2014 (7)
» June 2014 (7)
» May 2014 (5)
» April 2014 (5)
» March 2014 (7)
» February 2014 (6)
» January 2014 (6)
» December 2013 (7)
» November 2013 (4)
» October 2013 (5)
» September 2013 (6)
» August 2013 (8)
» July 2013 (8)
» June 2013 (7)
» May 2013 (8)
» April 2013 (8)
» March 2013 (4)
» February 2013 (6)
» January 2013 (6)
» December 2012 (5)
» November 2012 (7)
» October 2012 (6)
» September 2012 (6)
» August 2012 (5)
» July 2012 (9)
» June 2012 (5)
» May 2012 (9)
» April 2012 (7)
» March 2012 (7)
» February 2012 (5)
» January 2012 (7)
» December 2011 (6)
» November 2011 (6)
» October 2011 (8)
» September 2011 (6)
» August 2011 (8)
» July 2011 (7)
» June 2011 (7)
» May 2011 (5)
» April 2011 (8)
» March 2011 (6)
» February 2011 (5)
» January 2011 (6)
» December 2010 (5)
» November 2010 (9)
» October 2010 (5)
» September 2010 (6)
» August 2010 (8)
» July 2010 (6)
» June 2010 (6)
» May 2010 (10)
» April 2010 (5)
» March 2010 (8)
» February 2010 (7)
» January 2010 (7)
» December 2009 (7)
» November 2009 (7)
» October 2009 (6)
» September 2009 (8)
» August 2009 (10)
» July 2009 (9)
» June 2009 (5)
» May 2009 (10)
» April 2009 (5)
» March 2009 (12)
» February 2009 (8)
» January 2009 (6)
» December 2008 (9)
» November 2008 (8)
» October 2008 (9)
» September 2008 (4)
» August 2008 (6)
» July 2008 (8)
» June 2008 (17)
» May 2008 (12)
» April 2008 (7)
» March 2008 (21)
» February 2008 (16)
» January 2008 (13)
» December 2007 (9)
» November 2007 (25)
» October 2007 (2)
» September 2007 (23)
» August 2007 (12)
» July 2007 (11)
» June 2007 (7)
» May 2007 (6)
» April 2007 (9)
» March 2007 (5)
» February 2007 (3)
» January 2007 (2)
Articles and White Papers
Thursday, October 15, 2009
29598 Views 2 Comments 62 members voted Article Rating

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.

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
  • 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.
  • 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.
  • 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.
  • 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: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 - mark.a.monteleone@sbcglobal.net.

Rate this:

COMMENTS

Posted on Saturday, October 17, 2009 12:08 PM by
ajmarkos
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
Posted on Monday, October 26, 2009 8:11 AM by
timbryce
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.

Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



Featured Digital Library Resources 

Copyright 2006-2014 by Modern Analyst Media LLC