Aligning Process, People, and Technology to Facilitate the Speed of Change

Articles & Books

Facilitating Process Design

May 01, 2004
Jan Means

What is “process design” and why would I care to facilitate it?A process is an end-to-end set of activities which provide something of value to a customer. Examples include business processes such as documenting procedures, delivering customer orders, paying employees as well as non-business processes such as hosting a class reunion.

Process design (or re-design) confirms what the process produces (its outputs), what it requires as inputs, and the parameters which equate to success (the targets and accompanying measures). It also defines “how” the work gets done, and determines how the process will be supported by its two enablers: people and technology.

So how does facilitation fit in? There are always multiple viewpoints on how a process works, or how it should work. Designing processes in a vacuum according to one person’s viewpoint is a recipe for disaster. Although convening the right group of knowledgeable folks to collaboratively agree on process design doesn’t ensure success… it does stack the deck in your favor. Some may think “process design by committee” equates to extended time and money. On the contrary. Well-facilitated collaborative group efforts actually accelerate process design and improve the quality of the outcome. It also serves the purpose of establishing ownership early on, and incorporates learning into the actual design effort.

There is no cookbook. No guaranteed formula for successful facilitation of process design. However, there is a framework of questioning patterns that, when applied with the right mix of technical know-how and human dynamics skill, can provide a foundation for success.

Before we introduce this framework, let’s set some guiding principles to help you prepare for a successful process design work session:

  • Make sure you (the facilitator) have the right skillset: you must possess expertise in process analysis and process mapping techniques, as well as expertise in the managing of group dynamics – and be comfortable with letting others “find the answer.”
  • Do your homework. Prior to entering the actual work session to facilitate the process design, talk with the sponsor of the effort, obtain and review background materials, understand objectives, and understand how the process to be designed (or re-designed) fits into the context of a business initiative or project.
  • Ensure that you have the “right” participants in the room.
  • Plan the agenda and logistics well – make the environment comfortable and conducive to creativity and decisioning.
  • Prepare any materials that might be necessary.
  • Distribute to the participants any materials that they need to review in advance in order to make the work session productive.
  • Have a pre-work session conference call, if possible, to confirm scope and objectives for the process design work session, and to get all participants “on the same page”.
  • Be prepared to capture information effectively in front of the group – whether manually with flipcharts and post-it notes, or electronically with support of a process flowcharting tool and projector. Your capture of information must be visible, legible and confirmed by the group.

A Framework for Facilitating Process Design The framework consists of five major components.

The sequence of executing these components is recommended according to the outline below. The approach begins with context-setting, and moves topdown into process design – first understanding objectives of the process and its targets for success, then identifying process boundaries prior to defining “how” the process does its work. After the process is drafted, we identify the measurement points and data, and overlay the process with its enablers – people and technology.

This framework is not executed by mechanically asking questions in the sequence listed end-to-end, thus producing a process design. Rather, process segments are often designed and reviewed iteratively, in small cohesive chunks, to ensure correctness and completeness.

As you review the framework below, you will notice that each section of the framework includes several questions, sometimes asking the same thing in different ways. It is not recommended that you follow this list verbatim, rather it is there to provide you with an idea of how to formulate questions to accomplish information gathering for that component of the framework.

The framework consists of five major components:

I. Set the context
II. Define the process
III. Confirm measures
IV. Overlay with people (roles)
V. Overlay with technology

I. Set the Context:

Describe / discuss the business problem, charter of the team, vision themes, business targets, root causes, etc.
Depict where the process that is being discussed fits within the overall context.

II. Define the Process:

a. Process Objectives

  • What are the objectives of the process?
  • What is the purpose?
    What is the intent of the process?
  • What does the process “do”?
  • What are the process targets?
  • What will define “success” for this process? For its outputs?

b. Process Boundaries

i. Process Triggers

What triggers the process to start?
What causes the process to begin?
What event(s) happens to start the process?

ii. Process Outputs and Receivers of Outputs:

  • What do we have when we’re done?
  • What are the outputs?
  • What does the process produce for the “customer”?
  • Who receives the outputs?

iii. Process Inputs and Suppliers of Inputs:

  • What do we need to have in-hand to start the process?
  • What do we need to have to create the outputs?
    What comes into the process?
  • Who supplies the inputs?
  • Who provides the inputs?

c. Process Steps / Activities

  • What do we need to do to create the outputs?
  • What happens first? next?
  • How do we do the work?
  • Help me to walk through the process… what do I do first (next) ?

NOTE:

  • You won’t always get the process steps in correct sequence the first time you ask the question(s).
  • Review “cohesive segments” of the process regularly to test for completeness and proper sequence.
  • Keep aware of where decisions might be made. Listen for words or phrases that indicate that there is a choice made, or that multiple paths of activity might be followed. This indicates the need to document a decision.
  • When working with a decision symbol – don’t try to diagram multiple paths of outcome simultaneously. Diagram the “most typical / most common” path first… go back to the “anomalies”, or less common paths, later.

III. Confirm Measures / Key Performance Indicators (KPI):

When addressing measures and KPIs, the information can be documented in supporting attachments to the process map. However, it is helpful to utilize a measurement symbol (standard flowcharting symbology) within the process map to indicate where in the process the measure is taken. These can then be cross-referenced to a more complete measurement framework which can be published as an attachment to the process map.

Two principles to keep in mind:

  1. just because you can measure it doesn’t mean you should measure it.
  2. measures of the process and its outputs should be traceable to a specific project objective or target which the measure supports.
  • Review the process targets / success measures identified in Step II.a.
  • What indicates to us that the process is staying “on track”?
  • What indicates to us that the outputs are of the quality expected?
  • What metrics might support the indicator?
  • Where in the process will we perform this measurement?
  • What data is necessary to measure success?
  • Who / what will capture the data?
  • Who is responsible for monitoring the measure(s)?
  • What is my tolerance? Upper limit? Lower limit?
  • How will out-of-spec conditions be addressed?

NOTE:

  • Indicators are such things as processing time, cycle time, cost thresholds, or “customer feedback”.
  • Metrics are the specific measures applied to an indicator, e.g., measuring the time from receipt of request to satisfaction of the request, or performing annual customer surveys asking for information regarding satisfaction with the customer experience or problem resolution, etc

IV. Overlay with People (Roles):

It can be very helpful to “swimlane” the process map to depict the roles that work within the process. If you are drawing the process map left-to-right in time, swimlaning (adding the 2nd dimension to the map to depict “who” does the process steps) is an easy formatting job.

  • Who (what role) does this step(s) of the process?
  • Who (what role) is responsible for this step of the process?

NOTE:

  • Search for the “responsible” party… the role that “does the work” to get the activity done.
    If there are truly multiple roles responsible for an activity, this step of the process will appear in multiple swimlanes of the process map.
  • Rather than “swimlaning” in the live work session… consider taking different color markers and marking on the process steps the name of the role that does this step. (Using a different color marker for each rolename can visually cue the audience to confirm the roles.

You can then put the process steps into swimlanes when documenting into a process flowcharting/mapping tool outside the work session.) It may be helpful to create an accompanying “RACI” matrix to support the process:

  • Using the rolenames, create a matrix of process steps to rolenames, and note:
  • R = responsible (the owner)
  • A = approver
  • C = consulted (involved but not ultimately the owner)
  • I = informed (needs to be informed of the outcomes)

V. Overlay with Technology:

It can be very helpful to review the process again, this time thinking of necessary supporting tools or technology. Process steps / process segments can be annotated with the required/recommended supporting tool or technology to ensure that process step or segment is done effectively and efficiently. This exercise does not capture detailed information system requirements, rather the high-level expectations regarding tool / technology support of the process.

  • What technology / tools (including templates) are needed to support the process?
  • What do we expect the technology to do for us?
  • What technology / tools support is required?
  • What data is needed to support this process step / process segment?
  • What information is needed to support the process activities?
  • What processing rules exist that the technology needs to support?
  • What should the system do to support us in this work?

NOTE:

May also try to explore “acceptance criteria” at this point in time, by asking “What do you need to experience / see to be convinced that the requirement has been satisfied in the system?” This provides a basis for testing and implementation planning.

In summary, we recommend that you conduct the process design work session by first setting the context, then moving into process design by defining process objectives, process boundaries and then the process steps. Follow by confirming measures, and overlaying the process with people/roles and supporting tools/ technology.

Regardless of the level of detail required, this pattern of approach and questioning provides a framework for executing successful process designs. oe

© 2002 Resource Advantage, Inc..