The California High-Speed Rail Authority is working to build a true high-speed rail system – something that has never been done in the United States. For any new endeavor, knowing your business processes is critical, and the Authority generally depends on process maps to understand who does what and when across the high-speed rail program. These process maps are used by:

• New hires to learn the work they will be doing
• Cross-functional teams to understand the role they play in a business process
• Executives to understand exactly the work that is being done and by whom
• Our Information Technology team to configure information systems
• Our Quality team to conduct audits
• Our Lean practitioners to identify opportunities for improvement

In short, the process maps have become our roadmaps to success. Presented here are a few of our process mapping standards and techniques.

Where to Begin?

When telling a story through a process map, it can be challenging to know exactly where to begin, especially when mapping a complicated process involving multiple cross-functional groups. Having the right people in the room, asking the right questions and making the distinction between process owners and task owners is key.

At the Authority, we start our process mapping sessions by asking: What is the goal? What is the expected outcome of this process? Identifying the goal gives you the process output. Next, we ask the question: What is the trigger? How do we know when this process begins? Identifying the trigger of the process gives you the input of the process. Since a process is essentially turning inputs into outputs, all there is left to do is identify the steps in between.

The Basics of Process Mapping

To ensure the consistency, continuity, quality and effectiveness of our process maps, we adhere to the following basic tenets:

• Define the output first. What is the goal?
• Define the process title based on the output. For example, if the goal of the process is to review and approve an invoice, title your process, “Invoice Review and Approval Process.”
• Define the input. What begins the process?
• Identify the steps necessary to turn the input into the output.
• Be sure every step is actionable.
• Every step should be measurable.
• Keep steps limited to a single action if possible.
• Describe steps using a present tense verb plus object statement, such as “Prepares package,” “Reviews report” or “Requests approval.” Describe the work the responsible individual or group does.
• A single step within a process may have many inputs, but it can have only one output. In other words, a step can have many incoming arrows, but only one outgoing arrow because there is no way to determine which path to follow if a step has two or more outgoing arrows.
• Use containers to represent simultaneous activity. A container can house multiple steps across multiple functional areas of activity that occurs simultaneously. For example, a container can be used to represent the concurrent review of a document distributed to multiple individuals at the same time. A container should have only one outgoing arrow.
• Identify roles and responsible functional groups based on the organizational chart. Be consistent.
• Identify the time it takes to complete each step within a process.

How much detail should a process map include? A process map should explain the who and what, but not necessarily the how. The how is better represented in desktop instructions or other documentation. We assign a level (1, 2 or 3) to our processes here at the Authority, an action we call leveling, to help determine the scope of information and degree of detail to collect and include in a map.

Three Process Levels

The process requirements for all of our process maps are derived from a combination of Authority contractual requirements, the Authority’s project management plan, the standard framework established by the Project Management Institute (PMI) and industry best practices.

A Level 1 map contains high-level information and typically represents a framework or management lifecycle. It is not cross-functional or role-based. The example shown in Figure 1 illustrates each of the functional areas within our Infrastructure Delivery Branch and identifies key processes in each of those areas. A Level 1 map is a great source for understanding the process requirements and responsibilities of a functional area. The following map shows the results of a preliminary analysis of key delivery processes. It was created for executive management as part of an analysis to identify process requirements and to determine the need for process improvement and/or supporting documentation.

A Level 2 map, as shown in Figure 2, is cross-functional, typically spanning multiple functional areas across the organization. A Level 2 map is somewhat high-level and focuses on the cross-functional activity between functional areas or departments throughout the organization.

A Level 3 (Figure 3) map is cross-functional, typically spanning multiple roles within a single functional area. A Level 3 map is a bit more granular in detail and captures the cross-functional activity at a task level between individuals within the same functional area or department.

Most of our process maps at the Authority are Level 2, as our primary focus is the interaction between functional areas throughout the agency. Using different levels for our processes gives us a clear picture of the work that has been done and the work that is left to do. For example, if all we have is a Level 1 or Level 2 process map, we know there are still layers of the onion left to peel away to fully examine the process. Leveling our processes also helps to manage expectations and tells us exactly how many layers of the onion to peel to create the process map.

The Business Process Register

We consider our process maps valuable assets at the Authority, so we take special care in controlling and monitoring them. All of our process maps are housed in a custom SharePoint repository – the Business Process Register. Everyone in the agency can access the Register, and it is organized based on the structure of the agency. It mirrors our organizational chart, which makes it easy to quickly identify process owners, so we know exactly which functional group is responsible for any given business process.

The Register provides key performance metrics and important metadata we use to analyze our processes at an enterprise level. At a glance, the Register tells us who owns a process, who does the work, how many steps are in the process, how long it takes to complete the process and the cross-functional groups involved in producing the output. Each entry in the Register includes a link to a PDF of the process map. The Register also provides an audit function that allows us to periodically review our processes for changes as the organization and program evolve.

And that is the art and technology of business process mapping at the California High-Speed Rail Authority.