Confessions of a Flow Chart Junkie

By Cari Stieglitz

We’ve all been in a room with the business user, trying to understand their pain and create a solution that will make them happy. Requirements can’t just be gathered as many customers don’t know the best way to solve their problems. We can deliver a project on time and on budget and still fail if it doesn’t meet the needs of the business user. When our approach doesn’t work, what is our excuse?

The fact is, as project managers, we are responsible for the project’s success and asking the right questions to identify who or what makes that project successful. Project management needs to constantly identify and validate the very foundation of what creates the scope of the project—the customer’s requirements.

Some 70 percent of project failure can be attributed to poor requirements gathering. 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?

The forward-backward pass isn’t a new concept to project managers. We use it to verify early and last starts in a schedule and mathematicians use it to smooth out equations. The premise of the methodology is that the boundaries of each step are discovered when looking at the same flow, two different times.

The forward-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. It may seem like a lot of effort up front but invaluable deliverables result from this approach, including a way to justify the requirements, a documented process and a consensus on requirements for going forward.

The three-step methodology for the facilitated workshop is as follows:
• The forward pass: A list format of the process with a “Who” and “Action” column. In this step, we just focus on getting the process down on paper.
• The backward pass: Starting at the end, we focus on the relationships between only two steps at a time. One relationship at a time, we determine durations, pain points and issues.
• The overall review: We highlight the biggest issues and translate those into requirements by asking multi-level questions.
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”.

Continue down the table, creating a new line for each action that can be separated by time, tool or person responsible. While doing this exercise, ask questions like:
• Whose hands does it pass through? Is it electronic or physical?
• Do they approve it? Who else approves it?
• Is it always coded correctly?
• Do you have a paper copy and an electronic copy?

Start with the “Who” column and determine who is the first stakeholder to “touch” the process. Document this from beginning to end and capture triggers along the way. Capture the exceptions with “If” statements like, “If the work is not aligned with the invoice, sends invoice back to contractor and ends process.”At the end of the exercise, you will have a complete process from best recollection of memory documented with clear roles. For example:
• Step 1: After completing the work, Contractor generates the invoice.
• Step 2: Contractor mails the invoice.
• Step 3: Front office receives the mail and stamps with date received.

Continue until the entire process has been captured. Remember, this is just to capture the existing process. We aren’t trying to assign durations or problem solve at this point.

After you have captured the entire process, it is time to do the backward pass, using a white board and a swim lane diagram. A swim lane diagram is laid out similar to how it sounds. Each “Who” is given their own lane in which to see what actions belong to them. This identifies clear ownership of each step and also where the handoff is.

Beginning at the last step, write the action under the correct “Who” on the swim lane. Ask the following questions while capturing the relationship between the last step and moving backward to the second to last step.
• 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?

At the end, you have a thorough process with all of the pain points along the way. By asking 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.

Once the entire process is documented, write down the entire duration of the process. Ask what is wrong with the process as a whole and highlight the issues that were discussed along the way. These issues can be translated into a usable requirements document that focuses on the needs—not the solutions.

Cari Stieglitz is a project manager for Faithful+Gould, a New York-based cost consulting and project management consultancy. Her background includes PMO implementations that have successfully transferred process improvement and Project Management Information Systems into a variety of tools.