Abstract
With over 70% of project failures being attributed to requirements gathering, why are we still using the same techniques and expecting different results? Requirements need to be discovered before they can be “gathered” and this requires a robust approach to analyzing the business needs.
This flowchart junkie has increased project success through an emphasis on approaching requirements gathering from a list-to-visual process. The forward pass in the visual process flow establishes the basics — what steps are taken during an action. The backward pass is much like asking a person to recite the alphabet backward. The customer is forced to consider each step individually, without jumping to the next item in the memory line. When they are focusing on that one step, critical information can be discovered.
We will be able to tangibly show how the process affiliated with the requirement was improved, and how the same diagram can be used to verify that requirements were completed; the efforts for following this process also lead to better post-project ROI, training, and documentation.
Introduction
With all the approaches to identifying requirements, this flowchart junkie still prefers a white board and team brainstorming at the center to discovering the major pain points of the customer. Requirements can't just be gathered, because many customers don't know the best way to solve the problems they have. It is your job as a project manager to know how to discover the requirements through gathering consensus on where the problems are.
Most projects now have some sort of process improvement wrapped into them, whether it is the physical flow of how a building fit-out is designed or the routing of documents and approvals in an IT project. With the current state of the economy, the emphasis is on doing even more with less, which means removing inefficiencies and unnecessary lag times from what currently exists.
The second issue often found with process improvement is how do we show the value of completing the requirements? By using the same diagram and process after the project is complete, we can measure the improvements made for the customer, thus confirming to the customer that we resolved their issues and successfully completed the project.
Section 1: Requirements Gathering
“It's not my fault!”… or is it?
“It's not my fault, the customer didn't identify that he wanted this at the beginning!” or “The customer changed his mind halfway through and I had to rework everything! Of course I am not on schedule or budget!” I hear these statements when a project manager needs to justify a troubled project to management. Even if he or she can show the history through change orders, he or she can't explain why the end product is so vastly different from the original scope.
“Why do we need to involve all of these people? I can just tell you what we need.” Another common response I receive from clients is that they do not have the time or budget to do the in-depth requirements gathering sessions I propose. The sponsor or management feels strongly that they already know what the project should deliver.
“The requirements were already identified, I just followed orders!” In the real world, the project manager may not have been part of the requirements gathering. We may be handed the requirements as part of the RFP or from another project or department. It is easy to say that we did not have control over the requirements and therefore can't be held liable for their success.
The issue with all of this thinking is that, ultimately, we ARE responsible for the project's success and asking the right questions that ensure we are doing our due diligence to identify who or what makes that project successful. If we encounter issues along the way, it is our job to identify the consequence and communicate it to the right people. Project management is iterative and we need to constantly identify and validate the very foundation of what creates the scope of the project.
Why is Robust Requirements Gathering so Important?
Start thinking about how you gathered the requirements for your last project. Write down any surprise requirements that were exposed later in the project or complaints the customer had with the deliverable. Were they incorporated into the project? Were they left out? What were the impacts to the scope, schedule, or cost?
The statistics on project “failure” range from 50% to 75%, depending on the industry and project type. Seventy percent of those projects fail due to poor requirements gathering (infotech.com). This means the majority of us have been a part of a project that has failed.
The failure of a project due to requirements means the project manager could have come in under budget and on schedule—but failed to understand the most important factor of all. What did the customer want? No, what did the customer REALLY want? We can deliver the best, most user-friendly piece of software or beautiful building possible, but if the right requirements weren't identified, we can still fail.
Why it Works
The forward-backward pass isn't a new concept to us. Mathematicians use it to smooth out equations and we use it to verify the early and late starts of a schedule. The premise of the methodology is that the boundaries of each step are discovered when looking at the same flow, two different times. Additionally, the combination of a list format and a visual format helps varying thinking styles process and retain information.
The forward pass in the visual process flow establishes the basics—what steps are taken during an action. The backward pass is much like asking a person to recite the alphabet backward. The customer is forced to consider each step individually, without jumping to the next item in the memory line. When they are focusing on that one step, critical information can be discovered. We do this by asking questions, such as:
- “How long does this take?”
- “Is anyone else involved?”
- “What can go wrong with the process during this step?”
- “Why is this step important?”
It may seem like a lot of effort up front but you get some invaluable deliverables from this approach, including a way to justify the requirements, a documented process, and a consensus on requirements for going forward.
Section 2: Planning and Selecting Techniques
Before you Begin
Before starting a requirements gathering plan, there are two things that must occur as input—the signed Charter and the Stakeholder Register. The Charter (or whichever version it is called in your organization) officially gives notification to the business that you are the project manager, that you have executive level support, and that the resources you are after should give you time to complete the project.
The Stakeholder Register can be a formal analysis or a brainstorming session on who should be involved. Whichever method is chosen, it should be thorough, because you want the right people in the room during the requirements gathering session. My favorite questions involve who will be using the product the project delivers on a daily basis. Also, who has the power to help the project along? Even more importantly, who has the power to hinder the project? Involve those who are the biggest complainers early on; if they help to create the solution, it is harder for them to bad mouth it.
Choose your Weapon
There are many methods of gathering requirements, and the project manager needs to select the best mix of methods for the project. PMI's A Guide to the Project Management Body of Knowledge (PMBOK® Guide) outlines many options, but my favorite option relies on the pre-workshop survey, brainstorming sessions, and the nominal technique. I also conduct one-to-one interviews throughout the process, whether formal or informal. Sometimes the best information gathering session is sitting in front of that person and witnessing what he or she does to accomplish the activity the process is addressing. Give plenty of timing in between sessions to accommodate the different ways people internalize information—from the quick reactors to the deep thinkers.
Each option has its own strength and weakness. It is the project manager's job to understand which mix of approaches will be the most beneficial for the stakeholder group at hand.
The Requirements Documents
Whichever methodology is chosen, it is imperative to capture the approach and ongoing requirements gathering methodology as part of the requirements gathering plan. This includes how new requirements will be captured, who is in charge of determining whether or not they are in scope, and how they will be tracked and verified.
Of equal value is the Requirements Traceability Matrix. Whether you capture the history of the requirement in its own document or as a source field in a scope log, knowing where this requirement came from is invaluable for future evaluation.
Communicate and Share
As with any good plan, you will want to communicate your intentions to the identified stakeholders. Show them your approach before the session and what information you would like them to begin considering. By demonstrating the level of effort you are putting into requirements gathering, you are setting expectations from your attendees. It also justifies their involvement and attendance to their management by demonstrating you won't be wasting their time.
If you are going to send out a pre-workshop survey, allow time to process the results into something that is meaningful. Share the results of the pre-workshop survey with participants to show that others are equally committed to getting usable requirements out of these sessions.
I know some of you won't like the next step. Identify your biggest complainers, protesters, or those with the strongest opinions, either through word of mouth or the pre-workshop survey. Hold individual interviews with those folks. Sometimes the loudest complainer is the person you can learn the most from because they aren't afraid to share their ideas and state the issues. You may find some points to talk about during the facilitated workshop or gain additional trust that you want to work toward a solution (and sometimes you will also find out they are just complainers).
Section 3: Facilitating the Forward-Backward Pass
The Facilitated Session
Once you have determined the approach to uncovering and capturing the requirements, it is time to schedule and facilitate the requirements-gathering session. Because you communicated up front and sent out the results from the pre-workshop survey, the attendees should come ready to begin.
During the workshop, it is best to have a facilitator, a notes keeper, and a time keeper/parking lot administrator in the room. The facilitator concentrates on leading the session and getting the best information possible by critically asking questions. The notes keeper scribbles or types like mad to capture what is being said. The time keeper/parking lot administrator gets to call a time out when the group gets off topic or is taking too long on an item. He or she will then write down the item on the “parking lot” to be addressed later or in another meeting.
The three-step methodology for the facilitated workshop that we will now focus on is the forward-backward pass and these three steps are:
- The forward pass: A list-format of the process, with “Who” and “Action” columns. We will ignore what goes wrong and how much time it takes.
- The backward pass: Starting at the end, we will focus on the relationships between only two steps at a time. We will determine durations, pain points, and issues.
- The overall review: We will highlight the biggest issues and translate those into requirements by asking multi-level questions.
Forward Pass: The Process List and Visualization
Let's go through the process with an example: processing an invoice. For this exercise, a table with two columns will be created. The first column will be labeled “Who” and the second column will be labeled “Action.”
Start with the “Who” column and determine who the first stakeholder to “touch” the process will be. In most cases, it will start with the contractor generating the invoice. Let's assume the contractor mails a hard copy to the business. In this case, the first and second steps will go in the contractor “Who” box. The third step will start a new “Who” box when the front office receives it.
Your first three steps should be outlined as shown in Exhibit 1.
Exhibit 1 – First Three Steps of the Forward Pass.
Continue down the table, creating a new line for each action that can be separated by the time, tool, or person responsible. While doing this exercise, ask questions such as:
- Whose hands does it pass through? Is it electronic or physical?
- Do they approve it? Who else approves it?
- Is it always coded correctly?
- How many people type the information?
- How many systems contain information?
- Do you have a paper copy and an electronic copy?
You will also want to capture triggers for events. This isn't duration but more what needs to happen before the action can take place. For example, Action 1 in Exhibit 1 above can be revised to “After completing the work, generate the invoice.” And Action 3 can be revised to “After receiving the invoice, stamps with date received.”
You can easily see the process begin to form and some folks may have already identified exceptions. Capture the exceptions with “If' statements, such as “If the work is not aligned with the invoice, send the invoice back to the contractor and end the process.” At the end of the exercise, you will have a complete process from the best recollection of memory, documented with clear roles.
Continue until the entire process has been captured in the table. Remember, this is just to capture the existing process, we aren't trying to assign durations or problem solve at this point.
A simplified example of what a final, documented process looks like is shown in Exhibit 2.
Exhibit 2 – Final Forward Pass (Simplified Example).
Backward Pass: The Swim Lane Diagram
After you have captured the entire process, it is time to do the backward pass, using a white board and a swim lane diagram. By moving backward, you are focusing the group's attention on each singular step.
Begin by outlining the swim lane. A swim lane diagram is laid out similar to how it sounds; each “Who” is given his or her own lane in which to see which actions belong to whom. This identifies clear ownership of each step and also where the handoff is.
Don't write the steps yet, because we want them to just focus on one step at a time. Your swim lane should start out with just the names and the “lanes” as shown in Exhibit 3.
Exhibit 3 – Empty Swim Lane Diagram.
Beginning at the last step, write the action under the correct “Who” on the swim lane. Using Exhibit 2 as an example, you would write, “Receives Payment” at the very end of the swim lane for Contractor, as shown in Exhibit 4.
Exhibit 4 – Last Step in Swim Lane.
Ask the following questions while capturing the relationship between Actions 12 and moving backward to 11.
- Does the Contractor always receive payment by check in the mail?
- Does anyone but Accounts Payable issue checks?
- How long does it take for the contractor to receive the check in the mail?
- Can anything go wrong between these two steps?
Capture their comments in between the steps, including any potential issues with the interactions between those steps. Some issues may be highly improbably but, because this is a brainstorming session, don't stifle stakeholder involvement by correcting them at this point. We will be revisiting these issues and their probability at the end of the documentation exercise.
Depending on the answers to your questions, you may want to add a step to reflect reality. Again, we are not problem solving at this point—we are identifying what reality is and where the problems are. A simplified example of what the interaction could be documented as is seen in Exhibit 5.
Exhibit 5 – Steps 12 and 11 Example.
Continue down the entire list, asking similar questions for each step to validate if any steps were missed and durations and any issues that can occur. Every statement should be captured in some way. Remarks on the entire process should be written on a separate list to the side of the swim lane. Don't ask how we can solve the problems; just keep asking them where the problems are.
At the end, you have a thorough process with all of the pain points along the way. By asking about durations, we can also assign a total time lapse or time range to the process. This will be important to show improvements to the system or process.
An example of the final process can be seen in Exhibit 6.
Exhibit 6 – Completed Swim Lane Example.
Overall Review: Identify the Problems and Requirements Statements
Once we have the overall process up on the board, take a red pen and look at the flowchart. Begin by asking if anyone sees any issues with high-probabilities of occurrence. Circle the steps, duration, or lack of process that is/are a problem(s). Circle any unnecessary lags or inefficiencies.
Evaluate specific issues as well as overall issues and durations. For example, most public agencies or contracts have a requirement that says they must pay within 30 days. This may even be a KPI for some companies. If by documenting this process, you notice the average time to process invoices has about 10 days of inefficient wait time, you can easily identify the requirement to state, “Decrease the invoice processing time by 10 days.”
The original forward pass will also be revised to show durations. It is best to show durations per “Who” because it places ownership on the stakeholder to manage his or her overall process.
Exhibit 7 – Process Action Document.
Digging Deeper
Stakeholders may not always know how to define requirements. Sometimes they may just keep offering solutions, such as “The Contractor should email the project manager directly.” The reason we want to dig into these statements is the best solution may not be one they are considering. For example, combined with other user requirements, the best solution may be for the Contractor to upload the invoice to the accounting system.
Instead, try to dig deeper on statements or problem-solving statements by asking questions and receiving better requirements statements. Using the “Contractor should email the project manager directly” statement above, and asking questions like the ones shown in Exhibit 7 can lead to the better requirements.
Exhibit 8 – Examples of Questions to Get Better Requirements.
The requirements statements will need to be captured during or after the meeting using whichever method the Requirements Gathering Plan outlined. The final list should be sent out to the stakeholders that participated to ensure everything was captured correctly.
Section 4: After the Workshop: Tracking and Verifying Requirements
At the end of this exercise, we will have requirements statements that are captured, a beginning process, and a procedure that documents the current process.
After the workshop, the project manager will do the following:
- Capture the requirements statements and verify them against the project goals/business case.
- Schedule a follow-up meeting to prioritize the requirements.
- Begin to capture success criteria based on workshop statements.
- Capture the final written process and flowchart. These will be used to show process improvement and also used as a basis for training, knowledge transfer, or company assets.
All other requirements and scope management should be accomplished in best practice format and captured in the Project Management Plan.
The requirements will be tracked and the success criteria confirmed during the project. Use the Requirements Traceability Matrix and other requirements documentation throughout the process as new requirements are discovered, changes to the project occur and other questions are brought to the surface. Remember, the goal is to meet customer needs and the requirements are the ways to meet those needs.
These documents can also be used during and after the project as part of company assets:
- During the project, re-trace and update the swim lane and action document to use for training and knowledge transfer.
- After completion of a phase, re-visit the documents to see if requirements were met. Go through the same exercise, does it still require x days? Does this still happen? etc.
- After the project, go through the same process to show a decrease in duration, resolved issues, etc.
Where projects have a difficult to measure ROI, the before and after of these documents are great ways to visualize the benefits of completing the project. You can show a decreased duration, limited issues and risk, and overall decrease of inefficiencies and lag time.
Conclusion
Requirements aren't always known and need to be uncovered through techniques like the forward-backward pass. By using the backward pass in a visual manner, the group stays focused on potential pain points, risks, and issues on that particular action, which enables them to dig into the real problems that need to be solved. Once the problems are identified, it is easier to define and prioritize requirements.
The documentation created during this process will benefit the project in the long run because it can be used to verify requirements and show the benefits of the process improvement exercise.
