Facilitating Meetings: Stakeholders in Business & SMEs (Subject Matter Experts)

Some think there is no need to learn about the different types of questions used to gather information. Most think all are born with the ability to ask questions. To some extent this is true. However, when defining a business solution; the only way to successfully design a business system is to extract all of the necessary information from the stakeholders and subject matter experts (SMEs). Keep in mind that stakeholders are people who are impacted by a software project's success or failure. And, stakeholders can be anyone ranging from end users to the end users' managers or even the executives that the managers report to. The primary stakeholder is usually the person whose department owns the system. For example, an HR system may be owned by the HR Department and the HR Director may be the primary, internal stakeholder and system owner. SMEs, on the other hand, are people who are considered experts in a business area. The SMEs may or may not be a stakeholder. But analysts may go to an SME to learn more about a business area (i.e., asset management,  project management, staffing, etc).

This post discusses the importance of designing questions; it tells how questions assist the systems analyst in designing a system; and, it describes some of the questioning techniques that can be used when meeting with stakeholders and SMEs.

Designing Questions for Requirements Gathering

Designing and defining a business solution is a costly process. It is imperative that the customer receive the product that is both needed and expected. The job of a Business Systems Analyst can, to some degree, be compared to that of a person who investigates crimes. For example, the U.S. Department of Justice Office of Justice Programs, National Institute of Justice produced a document title, "Eyewitness Evidence, A Guide for Law Enforcement Research."  The Guide includes the questioning procedure followed by Department of Justice investigators who interview witnesses. The Guide directs investigators to encourage the witness to volunteer information without prompting; ask open-ended questions (types of questions is discussed later in this post); augment the open-ended questions with closed-ended, specific questions; avoid leading questions, avoid interrupting the witness, etc.

Notice the procedure specifically identifies the types of questions to ask first and then the types of questions that should follow the initial screening. This is done because it has been determined that questions can be phrased a certain way to obtain a certain type of results. For example, leading questions are not used because they often result in the respondent providing answers the interviewee wants the respondent to provide. Outside of question types, the procedure also mentions investigators should "avoid interrupting the witness" so the respondent does not loose his/her train of thought and leave out important details. So, as can be seen by the information gained from the Department of Justice guide; using a procedure to strategically design question types; and, determine when to ask specific questions is very useful.

Questions Help Gain Insight Into Stakeholders & SME Needs;

Much like an investigator, a systems analyst must ask questions to uncover the unknowns related to business problems, needs and wants associated with a system. The unknowns are discovered by asking stakeholders & SMEs questions and documenting Their responses.  In addition, the systems analyst does the following:

• Draws conclusions from stated facts;
• Identifies gaps in information provided; and
• Pursues answers to close identified gaps.

The facts mentioned are obtained by questioning stakeholders and SMEs. And, once all information is obtained then gaps are closed and conclusions are drawn. Using this approach ensures all system requirements are traced from statements made by the stakeholder. Note in this context assumptions are not converted into requirements. Instead, the system is designed from stated facts, which ensures an accurate system design.

Types of Questions

It may surprise some to learn that there are different types of questions used; based on the type of desired response. Following is a list of the type of questions (please note that the list is not all inclusive) used; and, descriptions and examples for each question type is also included:

• Hypothetical
• Open-Ended
• Closed-Ended
• Probing
• Leading
• Reflective

Hypothetical Questions

When asking a Hypothetical question, the question should be phrased to paint a picture of a scenario. The respondent then provides feedback based on the scenario painted by the individual asking the question.

Example:  "If we automate the invoicing component of the CAI system, could you then processes 1 application each day?" Or, "let's say we add 2 more people to your team, how many applications could you process in 1 day?". Notice in each example the stakeholder or SME is expected to respond to the specific scenario provided. This approach does not leave room for them to provide additional information. Instead, the question is asked in such a way that the answer will either be yes or no.

Hypothetical questions should only be using in systems analysis when a stakeholder conveys a business problem; and, research results provide insight on possible solutions. Possible solutions can be posed as hypothetical questions directed to the stakeholder. These hypothetical questions would be used to solicit the individual's opinion on whether or not the solution would yield the desired results in the stakeholder's business environment.

Open-Ended Questions

Responses to open-ended questions solicits a broad statement from the stakeholder. This approach results in obtaining a vast amount of relevant information. With open-ended questions; no information is provided to lead the stakeholder or SME down a path. For example, "tell me about the process you use to approve applications."  Notice the question is general and only limits the stakeholder or SME to discuss information relevant to approving applications. However, the respondent can discuss any area that pertains to approving applications including business problems, business process steps, employees, etc. Investigators typically use this line of questioning when asking a witness about something he or she saw. The witness then provides the details in his/her own words without coaching from the investigator.

Closed-Ended Questions

Closed-ended questions should be used to confirm facts stated by the stakeholder or SME when open-ended questions were asked. Typically, close-ended questions are phrased in a way such that only a yes or no answer is required. An example of a close-ended question might be, "you stated one business problem is that applications are never completed in time for customers to take advantage of the Red-tag sale. Is this correct?" The respondent would then answer yes or no.


Probing Questions

Probing questions provide SMEs an opportunity to provide greater details about one or more topics previously discussed. For example, a systems analyst may have a list of use cases along with the related actors and descriptions. However, a series of probing questions may be needed to gain steps for the normal and alternate flows and functional requirements. For example, "earlier you mentioned all students must enroll for the Fall semester to receive a discount. What process should a student use to enroll for classes?" Probing questions are used to gain additional insight in areas where the responses already received resulted in information gaps.

Leading Questions

Leading questions are used to obtain the desired answer to a question. For example, "since you stated Red-tag employees rarely perform well; you think it's best to automate that component don't you?" This line of questioning forces the respondent into providing the desired answer, which is yes. Leading questions should never be used by a Systems Analyst because they lead to documenting requirements that will change when the stakeholder changes his/her mind and wants to reword a statement to provide a different answer. It's best to let stakeholders provide the answers they want to provide based on their business needs or problems.

Summary

Before you host a requirements gathering session; take time to formulate a list of questions. Be sure to reference the various question types that should be used. And, make sure you phrase each question type appropriately. Lastly, it's a good idea to stay away from leading questions that will result in poorly defined or inaccurate requirements. Inaccurate requirements result in increase project costs since stakeholders usually will not accept an incorrectly implemented business system.

The Business Process Analyst & the Business Process

A business process analyst, business analyst or systems analyst is used to review the business process if a new system is about to be built; or, massive changes are about to be made to an existing system. This post focuses on documenting the business process associated with implementing a new or updated system. The topics that will be discussed are gathering business requirements, documenting business requirements, tracing business requirements and generating the data dictionary.

Gathering Business Requirements

When defining a new system or system updates; the business process analyst will typically review the business process steps as they are performed by the worker. Some organizations use MOST work measurement to not only capture business process steps, but determine the amount of time it takes to perform each step. This information is then used to define the exact number of people needed to complete a job within a specific time-frame. However, for Information Technology projects MOST work measurement is typically not used because companies are looking at the process steps and related information; usually, they aren't looking  to assign time values to the process.

To review the business process the business process analyst may be tempted to want to "talk" to individuals to capture this information. But there are one of two approaches that will guarantee the information documented is accurate:

1. Review & Validate a business process already documented: If the business process has already been documented; the business process analyst may ask for a copy of the document. Next, ask a worker if you can shadow him/her as the worker performs the process one time. This provides an opportunity to validate the accuracy of the business process document. In other words, determine whether or not some of the process steps have changed since the document was written. If so, update the document to reflect the changes and circulate the updated document for review.

2. Document a business process that has never been documented: If the business process has not been document the business process analyst should shadow a worker and watch as the worker does his/her job. The business process analyst will watch closely and ask questions as the worker performs the process steps necessary to complete the task. The business process analyst will ask about the business rules applied, software used to capture data (inputs) or generate documents (outputs). The business process analyst will also capture the process flow. The benefit here is, if a new business software is to be built it can be built to support the existing process so the business process changes very little. This means instead of the process changing, the tools used to perform the business process changes. Or, if the business process will change, the process changes can be documented so workers can do their job once the new/updated system is implemented.

The following sections provide one way to document the business process, business rules, inputs, and outputs.

Documenting Business Requirements

Business requirements are typically documented in the form of business rules. But, capturing the business process provides more than just business rules. You will also document business process steps, inputs and outputs. The inputs and outputs typically provide requirements used to define reports or user interface fields.  These elements are ultimately used to define database table fields and the table field relationships needed to generate the outputs.


The document reflecting the current business process is the As-Is business process. After stakeholders/users discuss how they would like to do business with the new/updated system in place; you will need to write the To-Be business process document.

In the following As-Is example, Company "A" users upload enhancement requests to a shared drive to request changes to the company's software product. This section provides a high-level overview of the current business process, the actors, and process owners. The To-Be Business Process Operations Report outlines how the business process is performed with the new/updated system in place.

Input Documents

Document Name	Description	Step ID	Notes
Enhancement Request	The Enhancement Request is currently created using an Exchange Form. The re-engineered process will need to store each request in a database. Users will be able to submit these requests online using the updated system.	Step 1	(For the TO-BE environment, the customer wants a document library using content types so that all related documents for an Enhancement Request are centralized and easily accessible. )
Impact Analysis Report	The analyst emails a copy of the Impact Analysis report to the CCB reviewers.	Step 2	A COTS will be used for the TO-BE environment.
Test Documents		Step 4
Release Notes	The Technical Writing Department is responsible for updating the Release Notes and uploading the document to the shared drive. The path is sent to Product Support and the Deployment team.	Step 4

Output Documents

Document Name	Description	Step	Notes
N/A	Currently there are no outputs. The TO-BE Business process should include information on the reports to be generated for the new process.	Step 5

Sub-Process Operations

In this example, the BSA uses a separate process to create the Impact Analysis report. Therefore, a Sub-Process Operations report would be created to capture the steps. The ID of the Sub-Process Operations Report would include the Parent ID and the step number (i.e., Business Process ID:  2237.2). The business rules, inputs and outputs would also be captured.

Generating the Data Dictionary 

Once you have documented the inputs and outputs, it's a good practice to create a data dictionary. At a minimum the data dictionary should include the element name (such as Enhancement ID or user ID), description, whether or not the element is required, the data length based on any forms and/or business rules, data format (for example dates must be mm/dd/yyyy), data type (i.e., date, string, etc.). Following is one example of a data dictionary. Microsoft Press published a book titled "Software Requirements. It also includes an example of a data dictionary. 

Business Process To-Be Report
 

To capture the To-Be business process requirements stakeholders should review how business is currently done. In addition, a list of current business problems is also captured. The Analyst should look for opportunities in which automation can help the business process become more efficient. And, users and stakeholders should be prepared to discuss problematic areas. All of this information can help the organization look for opportunities to improve the way business gets done.

Business Process Flow Diagram
 
Another way to capture the business process is to create a business process flow chart, which uses symbols to define the business process. The following picture shows the As-Is business process used to Bill Customers.

In the previous process flow diagram the process begins with the IT Department. The rows shown on the process flow diagram includes horizontal swimlanes. A swimlane is the rectangle that depicts an actor. A swimlane can be horizontal or vertical depending on the number of actors and number of process steps. The shapes inside the horizontal swimlane depict the process start, process documents (i.e., complete timesheet), sub-processes (i.e., Process Customer Bill), process decisions (i.e., approved?) and process end.