Requirements Gathering

EDBOK Guide

Knowing where you want to go (strategy) and what you need to do to get there (tactical steps) are critical elements to any project. Requirements Gathering covers the compilation and documenting of needs, necessities or obligatory elements prior to taking those strategic and tactical steps. It is a process.

In the Document Lifecycle, there are many players, agendas and requirements, so taking a panoramic look at an organization’s needs prior to a project and incorporating those needs will lead to the best result – satisfied stakeholders, on-time execution and a good return on investment.

Establishing the Current State

Most industry pundits agree that “starting at the beginning” and following current procedures to the end of the process is important to complete a baseline assessment (Craine, 2000). This baseline is established by determining what processes and tools are currently in place. The current state should identify the following:

• technology in place,
• processes used,
• operational costs,
• utilization of assets,
• Key Performance Indicators (KPIs),
• legal and regulatory compliance elements, and
• strengths, issues and challenges.

This information is garnered through physical inventories, visual observation and a cross-section of stakeholder interviews. In some cases requirements gathering is an informal process and in others cases it is more formal. The formal model is usually more efficient as it mimics a military-like, top-down, accountability format.

Formal Model

The steps in the formal model are:

1. Establish a Project.
2. Hold a Core Team kick-off meeting to review roles.
3. Hold a Management expectation meeting.
   • Define business goals and high-level objectives.
   • Review the current state.
   • Establish risk and success criteria to ensure all parties are aware of the variables and potential hurdles.
4. Create a project plan to ensure the project stays on track.
5. Distribute a formal communication or an official project charter from a senior executive to ensure all stakeholders are aware of the desired outcomes and direction.
6. Hold stakeholder meetings to gather data and requirements.
7. Facilitate focus groups or user surveys to provide a wider range of opinions and increase buy-in.

The Current State is now established.

The formal model usually has set milestones to keep all parties accountable and to encourage participation.

Establishing a Project

Document/communication projects involve many business units. They are usually kicked off due to a problem or challenge. Problems may be related to operational efficiencies, mistakes or outside audits demonstrating deficiencies. Challenges may come from demands by management to cut costs, a reduction of staff or an increase in output requirements. Once one or more of these have been outlined by someone and they have been presented to management, a project is born.

In some cases management may stimulate this activity. They may choose to have  the project lead by a well-rounded person with higher than average knowledge of the overall process and the various business units driving customer communications.

Core Team

Although this book is not about project management, Requirements Gathering requires organization and good documentation to:

• ensure completeness,
• report to project sponsors,
• acquire funding and support, and
• get the plan executed properly.

To get things started and organized the team size needs to be managed and everyone needs to know their role. The Project Stakeholders universe shown in Figure 1 demonstrates that many players are involved during the process. The Core Team needs to keep control and to make sure that the others are receiving the right amount of information through regular communication. This will keep the others engaged and up- to-date about the project.

In the initial Core Team kick-off meeting an outline of the goals and objectives should be established. To bring further structure to the process, the goals and objectives should be mapped to the calendar to align with the organization’s known current projects. This prepares the team for the next step – the Management Expectation meeting.

Figure 1 – Sample Project Stakeholders.

Management Expectation Meeting

Once the Core Team has established the goals and objectives, and created a high-level, calendared plan, it is time to present version one of the approach. A critical facet of  the management meeting is the discussion of risk and success criteria to make sure all parties are aware of the variables and potential hurdles. Management will usually have more insight into current projects or projects that are on the horizon, which will allow the Core Team to ascertain the feasibility of getting the project rolling.

If the project is sponsored by management, then the management team will want to understand the approach and should support the navigation of the information gathering. They will act as liaisons to engage subject matter experts in different business units, which will expedite the project and create good communication.

Eventually management will want a more in-depth project plan and overall budget figures to ensure it can be executed with a solid return on investment or a reasonable payback period. The foundation of the Business Analysis will be created during the next few steps:

• detailed project plan,
• communication protocols,
• stakeholder meetings
• Subject Matter Expert (SME) interviews,
• focus groups, and
• surveys.

Project Plan Creation

After the initial management meeting the project plan should be revised and milestones adjusted. The Project Plan should consist of the following minimum milestones:

• planning,
• current state review,
• data validation and correction (as necessary), and
• final current state established.

The plan should also include a regular status report meeting with management to keep them up-to-speed and to ensure that all deliverables are being met. Any challenges that are jeopardizing milestones should be discussed because weak information about requirements will be amplified later. Samples of these future challenges could include:

• incomplete solution design,
• poor return on investments,
• longer implementation timelines, and
• compliance breaches.

Once the plan is set, a formal communication or an official project charter is distributed from a senior executive to ensure all stakeholders are aware of the desired outcomes and direction.

Gathering data and requirements is part art and part science. The project plan creates order and accountability. However, getting the information to solidify the strategy and creating buy-in and momentum along the way is an art form. By this point the general direction is known, but evidence is required to back up the theories.

There are givens and variables. Givens are things that you know and variables are things that are unknown, but can be solved for. Examples of givens could be:

• document volume produced,
• frequency of communication,
• physical inventories,
• expiring leases,
• software in use,
• software sunsetting (i.e. – version is at end-of-life),
• current budgets,
• a current shortfall in the operation (i.e. – currently at production capacity),
• a new regulation,
• retiring knowledge workers, and
• merger/acquisition.

Figure 2 – Current State Equation.

All of the givens in your equation should be data that is gathered and discussed. The impacts of these may not be known at the time of acquisition, but as discussions are had with stakeholders the picture will become clearer and the unknown variables will be discovered.

Another key step prior to speaking with stakeholders is to visually observe the operation in action ahead of time. Understanding the general document production workflow and the overall environment will provide a greater understanding of the current state. Both the good and bad will be seen, as well as how the personnel have adapted to the environment and their day-to-day challenges.

Stakeholder Meetings

A cross-section of stakeholder meetings should be held to gather data and requirements. After explaining what the project is about and the possible direction it may take, it is time to ask some questions. During these interviews many areas and issues of the business unit may be discussed and it is easy to lose focus, so it is good to be prepared with a set of questions that will guide the session. Questions should elicit both positive and negative discussions. Samples questions might include:

• How is the Business Unit affected by the project or document operations?
• Describe the current workflow or your part in it?
• Do you have any other projects on the go?
• What do you like about the current state?
• What do you dislike about the current state?
• Are there any financial and process challenges or issues with the current state?
• What would you like to see in the future state?

It is also important to limit the number of people participating in the interview to three people or less. This allows everyone to be heard while stimulating further conversation between interviewees to enrich the content. Ideas can be enriched by interactions and discussion. This is especially critical when trying to document old processes that have not been documented in the past. This tribal knowledge lives, but can be difficult to extract from one person.

The average attention span is about 45 minutes; therefore it may be necessary to break up the interview into two or three sessions. This also serves a few other purposes:

• As interviewees digest the conversation, they may come to the next session with more details.
• They may have to go in search of data that they can share in the next session.
• They may realize that there is another subject matter expert that will have better answers for you.
• There could be some processes that are already documented that can be brought next time.
• They may simply be more focused at another time when they are not distracted by another task.

There are many different stakeholders. Understanding each of their requirements and constraints will make it easier to develop a positive outcome for all.

Core Team

The Core Team is usually made up of no more than six people from Operations, Information Technology and Finance. The team may include two to three Subject Matter Experts and/or External Consultants. The target Critical Outcome(s):

• Create a business case for senior management and/or project sponsor.
• Implement a new and improved solution to achieve the goals and objectives.

Project Sponsor

This should be a senior manager with budget, infrastructure or compliance responsibility. The project sponsor may also have two or three advocates, usually from their peer group (Finance, IT, Compliance). The role of the project sponsor is to:

• drive the project,
• provide stakeholder liaison, and
• change management.

The target Critical Outcome(s):

• increase profit,
• improve processes, and
• comply with new regulations.

Business Units

Contributors to communications or business processes involved with customer communication may be drawn from between five and fifteen business units, including Finance/Billing, Marketing, Legal, Compliance, Operations, and Sales. The role of the Business Units is to:

• articulate issues, challenges and desired outcomes,
• provide detailed information about their role in the process, and
• Business Unit change management.  

The target Critical Outcome(s):

• increase profit, and
• improve processes

Vendors and Partners

Depending on the complexity of the project and integration requirements there may be no vendor interaction or the participation of a variety of vendors and partners. The role of this group is to:

• provide solution design as part of the team of providers of technology and services, and
• educate.

The target Critical Outcome(s):

• sales,
• improve processes, and
• implementation support.

Subject Matter Expert (SME) Interviews

Subject Matter Experts exist in many areas. You will find them in all of the stakeholder groups. These people are indispensable. They will provide key information from workflows, history, unwritten challenges and processes to integration possibilities. Typically, they are satisfied with the way things are as they have either built them or fixed them and have things working. It is critical that they understand the big picture and the direction that management wants to go. If their current situation can be improved by providing them with the tools, infrastructure, financial support or someone to hear their frustrations, they can be enablers to success.

On the other hand, there will be a few that would like to build very complex infrastructures that will not be economically feasible or may take too long to implement. Maintaining focus on data gathering and technical requirements to support the business analysis phase is vital.

SMEs are just that – experts. Do not waste their time with low level conversation.  Come prepared to the interview. Interview others first to create a base of knowledge. Be prepared with facts and a list of unanswered questions from the previous interviews. Focus on their expertise and ensure that your questions keep referring back to the project at hand.

The best way to start is to state the givens than you know. Map the workflow and ask them to confirm or correct your drawing. If they are making multiple corrections that create confusion, ask them to map out the workflow for you and ensure that you understand it. Workflows should include at least the following elements:

• Data / Inputs: Source and owners of the data.
• Composition / Design: How are the documents are composed or created from the data?
• Post-composition: How are the documents are adjusted, transformed or prepared for output?
• Archive: How is the output stored, how long it is retained, when it will be purged?
• Output and Distribution: Electronic (emailed / web content) or physical (printed and mailed).
• Tracking and Reporting: How are documents tracked and productivity reported?

It is critical to keep detailed notes about the components of the workflow if even you have not heard of them or if they use a different vernacular specific to their organization. These will come up again. It also provides a list for further research with other SMEs or to provide details to vendors.

Facilitating Focus Groups

Depending on the project, testing concepts or soliciting feedback early on can help to find the holes in data or to add some credibility to the current direction. This voice of the internal or external customer or even SMEs may provide information that has not been thought of by people that are very close to the project. This feedback will provide a good indication of shortcomings and the future solution adoption success.

Professor Glenn Blank (Blank, 2002) of Lehigh University suggests that a focus group session should concentrate on:

• gathering opinions, beliefs, and attitudes about issues of interest to the organization,
• testing your assumptions,
• encouraging discussion about a particular topic,
• building excitement from spontaneous combination of participants' comments, and
• providing an opportunity to learn more about a topic or issue.

Focus group methodologies differ and are well documented. The key is to ensure that the subject is clear and that a good moderator facilitates the session involving all of the participants. Limit the group to no more than a dozen people to be effective for a session of 60-90 minutes. Here are sample steps from David Pitre (Pitre, 2010) of Davis & Company that you can use to prepare for a focus group session:

1. Determine your research question (or subject of focus).
2. Manage logistics.
3. Recruit and invite participants.
4. Develop questions.
5. Conduct the focus group(s).
6. Analyze your notes.
7. Summarize your findings.

User Surveys

Sometimes a wider audience is necessary to ensure awareness and to gain an understanding of the support for change. This panoramic view can be accommodated by online surveys or town hall type meetings. A skilled person in survey development is important to make sure that information is statistically sound or that the confidence in its accuracy is high. Sample size and test questions within the survey are important.

According to CustomInsight (CustomInsight, 2013), a provider of online HR assessment and development tools, determining the correct sample size requires three pieces of information:

1. The size of your population.
2. Your desired error level (e.g. 5%).
3. Your desired level of confidence (e.g. 95%).

For example, if you have a company population of 1,000 and you would like a confidence level of 95% with an error rate of 5% or range of +/- 5%, you would need 278 people to participate out of 695 if there was a 40% response rate. The calculator can be found on the following website:

http://www.custominsight.com/articles/random-sample-calculator.asp

Current State – Version One

After all data and requirements gathering is complete, the information should be presented in a logical manner for validation prior to the business analysis step. A samples Findings Report is shown in Figure 3.

Current State Review

When the Current State document is complete, it is time to gather the Project Sponsor, the Core Team and any key Stakeholders to review and validate the Findings Report. This step accomplishes a few things:

• It completes a key milestone; the review process brings stakeholders together once again to collaborate.
• It eliminates any misconceptions.
• It usually reveals some unknown facts.

Data Validation and Correction

Once the current state document is presented, it needs to be validated, adjusted, and/ or corrected. This step is critical to ensure that everyone agrees on starting point. From here, solutions can be developed based on this snapshot in time. Without this step, solution development and business analysis activities do not have a foundation.

Figure 3 – Sample Current State document content.

This is not a new concept. In Eliyahu M. Goldratt’s (Goldratt, 1984) book titled The Goal, he introduced the Theory of Constraints (TOC), an overall management philosophy intended to help organizations attain their goals. Within the book, Thinking Processes were discussed. The order of operations in the Thinking Processes helps create a buy-in process just like the Management Expectation Meeting and Data Validation steps. The Thinking Processes are:

• gain agreement on the problem,
• gain agreement on the direction for a solution,
• gain agreement that the solution solves the problem,
• agree to overcome any potential negative ramifications, and
• agree to overcome any obstacles to implementation.

The Core Team and Project Sponsor must remain focused on completing this task since every elapsed day weakens the Current State as new variables are introduced by business units and economic pressures. The following should be established:

• deadlines for correction submission, and
• schedule the presentation or delivery of version two of the current state documentation.

The project sponsor must solidify the:

• business analysis plan,
• RFI/RFP development, and
• the team lead.

Informal Model

The steps in the informal model are similar to the formal model, but as the name indicates it is informal or more relaxed. The accountability, the scheduling, the timelines and the urgency are not present. This activity is usually led by a change agent to create a groundswell to enlist supporters. Informal models often evolve into formal models depending on the culture of the organization or the financial impact. The steps in the informal model are as follows:

• an individual or a Core Team kick-off meeting is held to establish the goal or to discuss the concept,
• stakeholder meetings are held on an ad hoc basis,
• management is informed on occasion of the work that is being done, and
• the current state is established with or without validation.

Identifying the Gaps and Business Problem(s)

As the data is gathered to create the current state, gaps in processes are identified, consistent requirements become apparent and business problems are found. Documenting the impact of the gaps and business problems during this stage helps to support the Business Analysis component. Gaps can include some of the following: competencies or incompetence, performance levels, or internal and external customer impact.

During this stage, the project leader or consultant identifies business problems. Identifying the business problems can be challenging. Sometimes the symptom of a problem emerges to get the attention of stakeholders, but the root cause is not as easily identifiable. A simple analogy can clarify the concept. A weed appearing in the grass (above the surface) is the symptom or the effect of a root that germinated from a seed (under the surface). If the weed is cut or removed without the root then the problem weed will continue to surface.

The source of the problem can take many forms - dated methodologies and technologies, lack of budget and resources, or ignorance of upstream business requirements and downstream operational processes – so getting to the root of the problem and articulating the options, provides the key to the next steps – Business Analysis, Technical Analysis, Stakeholder Agreement, Design Specifications and Project Execution.

There are many ways to get to the specific underlying causes. These three techniques can stimulate your own approach. The three approaches are:

• The 5-Why Analysis
• Root Cause Analysis (RCA)
• Gap Analysis

The 5-why analysis

Masaaki Imai (Imai, 1986) founded the Kaizen Institute Consulting Group (KICG) to help western companies introduce the concepts, systems and tools of Kaizen. Since then it has been used in various permutations throughout the world. Karn Bulsuk (Bulsuk, 2009) states that “the 5-Why Analysis is used throughout the kaizen concept and in quality control, is a tool to discover the root causes of a problem.” The methodology truly follows the name and suggests that the interviewer ask the interviewee ‘why’ up to five times to get to the root cause.

1. Identify the problem.
2. Ask yourself: why did this happen? Come up with all the causes you can think of.
3. For each of the causes you just identified, ask “why did this happen?” again.
4. Repeat until you’ve done steps 2 and 3 five times. You should have identified the root cause by this stage.
5. Find solutions and countermeasures to fix the root cause.

Root Cause Analysis (RCA)

In Root Cause Analysis for Beginners by James J. Rooney and Lee N. Vanden Heuvel (Rooney & Vanden Heuvel, 2004), they state that “RCA helps identify what, how and why something happened, thus preventing recurrence.” Their process involves the following four major steps:

1. Data collection.
2. Cause charting.
3. Root cause identification.
4. Recommendation generation and implementation.

Data collection has been discussed throughout this section. The key point that Rooney and Vanden Heuvel make is that data collection takes the most time, but it is absolutely necessary because root causes cannot be identified without having complete information prior to analysis.

Their Causal Factor Charting step “provides a structure for investigators to organize and analyze the information gathered during the investigation and identify gaps and deficiencies in knowledge as the investigation progresses.” This is very similar to the SME workflow whiteboard session. The difference is that the causal factor chart diagram includes logic tests that describe the events leading up to an occurrence, plus the conditions surrounding these events.

The third step is root cause identification.This step entails “the use of a decision diagram called the Root Cause Map to identify the underlying reason or reasons for each causal factor.” The map, much like the SME workflow diagrams, creates a starting point for the interviewer to get questions answered about causal factors and why happen.

The final step of recommendation generation and implementation crosses into business analysis.

Gap Analysis

Gap Analysis is a technique that people use to determine what steps need to be taken in order to move a business or project from its current state to its desired, future state (Business Dictionary, 2014). Once the current state is documented and as the future state becomes defined more clearly after further business analysis and solution design, the gaps become evident. The gap between the two states creates requirements to close the delta.

Insight from finance, IT, vendors and consultants can help to solidify the analysis and lead to a sound business decision. A few factors to consider at this stage are:

• financial forecasting and planning,
• regulations and applicable laws,
• suppliers,
• staff skills,
• economic conditions,
• opportunity costs,
• competition, and
• available technology.

Alignment of Leadership Vision and Operations

Most of the time, leaders have a vision of what they would like to occur. Just as often, they are unaware of what options exist to achieve the vision or the implications on their Operations team. The vision usually has a simple objective – improve the bottom line – make money or save money. Operations are usually tasked with saving money through efficiency while the business units are trying to both, improve the top line, while reducing expenses if possible. Aligning these two or making the rubber hit the road is part art and science.