Beginning at the End: Requirements Gathering Lessons from a Flow Chart Junkie - Part Three

Cari Stieglitz
This is the last feature of a three-part series that will examine the project management responsibilities of requirements gathering and facilitating the forward-backward methodology.

In Part Two we discussed planning how requirements will be gathered. In this last installment of the series, we will focus on facilitating the forward-backward pass during the workshop.

Let’s go through the forward pass, “The Process List and Visualization” 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 is the first stakeholder to “touch” the process. 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 step and second step will go in the contractor “who” box. The third step will start a new “who” when the front office receives it.

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?
  • 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, “generates the invoice” can be revised to “After completing the work, generates the invoice.”

You can easily see the process begin to form and some of you may have already identified exceptions. 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.

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 in 12 steps is shown in the table below.

WhoAction
Contractor 1. After completing the work, generates the invoice.
2. Mails the invoice.
Front Office 3. After the receiving the invoice, stamps with date received.
4. Places in project manager's interoffice mail.
Project Manager 5. After receiving the invoice, verifies the work billed has been approved and completed.
5a. If the work is not aligned with the invoice, sends invoice back to contractor and ends process.
6. Verifies invoice against budget and updates project cost sheets.
7. Stamps invoice with approved and writes account code and PO on invoice.
8. Places invoice in accounts payable inbox.
Accounts Payable 9. Enters invoice into accounting system.
10. Generates check.
11. Mails check to contractor.
Contractor 12. Receives payment.
Exhibit 1


Now that our process is completely documented, we will take that information to the next level, translating the list into a visual flow chart – adding it step by step moving backward in a swim lane. By moving backward, you are focusing the group’s attention on each singular step. I prefer using a white board for this step but you can also use index cards and tape.

Begin by outlining the swim lane. A swim lane diagram is laid out similar to how it sounds. Each “who” is given their own lane which will include what actions belong to them. This identifies clear ownership of each step and also where the handoff is.

Don’t write the steps yet, we want to focus on the steps one at a time. Your swim lane should start out with just the names and the “lanes” as seen in the completed example below.

Beginning with the last step, write the action under the correct “who” on the swim lane. Using Exhibit 1 as an example, you would write, “Receives payment” at the very end of the swim lane for contractor as shown in Exhibit 2 below.

Step 11 and Step 12 example

Exhibit 2: Step 11 and 12 example


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 comments from the questions in between the steps, including any potential issues with the interaction between those steps. Some issues may be highly improbably but since 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 the completed in the Step 12 and Step 11 example below.

Continue down the entire list asking similar questions for each step to validate if any steps were missed, 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 where the problems are.

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.

An example of the final process can be seen in Exhibit 3 below.

Swim Lane Example

Exhibit 3: Completed Swim Lane Example


Once we have the overall process up on the board, take a red pen and look at the flow chart. Begin by asking if you see any issues with high-probabilities of occurrence. Circle steps, duration or lack of process that is are a problem. 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, “Decrease invoice processing time by 10 days.”

The original forward pass will also be revised to show durations, as in Exhibit 4 below. It is best to show durations per “who” because it places ownership on the stakeholder to manage their overall process.

WhoActionPre-Project DurationIssues
Contractor 1. After completing the work, generates the invoice
2. Mails the invoice.
2-4 days
Front Office 3. After the receiving the invoice, stamps with date received.
4. Places in project manager’s interoffice mail.
1-4 days The project manager may not be known.
The PM may be on vacation or not check mail and it will just sit in the inbox.
Interoffice mail staff charges our department for processing these.
Project Manager 5. After receiving the invoice, verifies the work billed has been approved and completed.
5a. If the work is not aligned with the invoice, sends invoice back to contractor and ends process.
6. Verifies invoice against budget and updates project cost sheets.
7. Stamps invoice with approved and writes account code and PO on invoice.
8. Places invoice in accounts payable inbox.
2-20 days There are no guidelines or limitations on how long a PM should take or what they should verify against.
No contract administration involvement in approval.
Contractors could submit invoices that do not match the project WBS – slowing down the process.
PM is only person to verify work and approve invoice – doesn’t match our financial/ audit requirements.
Accounts Payable 9. Enters invoice into accounting system.
10. Generates check.
11. Mails check to contractor.
2-30 days A/P could enter wrong code.
Project Manager has no feedback loop if different code is entered or required.
Project Manager isn’t notified when the check is sent.
Contractor 12. Receives payment. 2-4 days Checks have been lost in mail
Exhibit 4: Process Action Document