The Process Triage™ Mapping Style Guide

Process Triage

Our deliverable-oriented map makes identifying root causes easier than conventional flow charts.

Readability

There are principally two symbols -- arrows (representing work) and circles (representing work product).

Durability

Process Triage™Workflow maps illustrate what work is done, not how the process is implemented. Most maps last many months, sometimes years, with constant reuse.

Focus on Deliverables

Process Triage™ Workflow Maps are deliverable chains in earliest finish order

Finding the symptoms and causes of workflow problems requires an ability to examine the things that are created within and by the it.

Process Triage™ Workflow Maps are primarily an illustration of these work products or deliverables.

Deliverables must be physical and have measurable attributes. Their arrival or presence must be knowable.

Their completion is an event that the business may want to know and remember for purposes of starting another activity or stopping something, like counting costs or time other resources consumption.

Deliverables are illustrated in earliest finish order, following the direction of the connecting arrows.

A Process Triage™ Workflow Map is, first and foremost, a deliverable chain.

Deliverables are known and nominated by Process Triage workshop participants; those who are most familiar with the workflow.

Activities or Tasks (the solid arrows) are derived from deliverables

Activity Numbers do not necessarily indicate sequence.

Generally, an activity's start cannot be determined from the map.

Successful process triage requires one be able to trace some symptoms to activity or task that created the deliverable.

Resource consuming tasks or activities that create deliverables are illustrated by a solid arrow. The arrow points to and touches the deliverable it produces.

An activity arrow connects from the last previous deliverable in the chain.

Each activity is given a unique name and number. The name format is [active verb + noun (direct object)], such as "Review Sales Proposal."

ACTIVITY NUMBERS

Unique activity numbers are provided for faster identification for the users who become familiar with the map sheet. The number does not indicate sequence or precedence, even though they generally appear to follow in order.

Numbers typically increment by 5 or 10 to allow insertion of additional deliverables and provide a number somewhat in sequence if possible.

DETERMINING AN ACTIVITY'S START POINT

Because the map is focused on deliverables and their earliest finish order, the map, absent additional notation, does not illustrate earliest activity start! In reading the map, we know the activity must consume the last previously finishing deliverable (the one it is connected from) in order to create its own deliverable. In reality, actual work may legitimately start sooner, perhaps after three or four predecessor deliverables earlier.

An examination of each activity's true earliest start is required to determine a critical path. See the Work Breakdown Structure Triage Exam for this work-around.

back to top

Four types of Deliverables.

Triggers (Green)

Milestones (Red)

Non-Milestones (White)

Externals (Blue)

Milestones & Non-Milestones (reds & whites) are made within the workflow.

Externals (blues) are contracted for.

Successful process triage recognizes that not all deliverables are equal.

We distinguish between four types of deliverables:

Deliverables that cause a workflow to start are called triggers. They are represented by a green circle. They are physical things, including the passing of time (i.e. "Accounting Period Ended). Every workflow has at least one trigger. (Think "green light, "Go!")

A deliverable that constitutes a significant or natural end of a series of deliverables is noted as a milestone deliverable, represented by a red circle (think "red light, Stop!"). A workflow with several segments will have a milestone deliverable in each segment.

A deliverable that represents the conclusion of all resource consumption (time, labor and materials) is called a final deliverable. It is always a (red) milestone.

Non-milestone deliverables, represented by white or plain circles, are necessary to illustrate a process's complexity. Generally, non-milestone deliverables are less subject to process control and oversight.

A workflow creates only milestone (red) and non-milestone (white) deliverables. Trigger (green) deliverables are outside the process's boundary.

External deliverables are important to the workflow but are not produced by it. They are represented by blue circles. They must be contracted for in some fashion. They must arrive on time and in the required quantity and quality. For this reason, external deliverables require dedicated management attention, as they are often business model risks.

back to top

Remaining two symbols:

Conditional activities have a hash mark, meaning the previous deliverable involved a choice about which deliverable completes next.

When a deliverable's completion depends upon deliverables from more than one workflow (such as work being done in parallel), a dashed arrow connects these additional deliverables to the nearest predecessor.

Two more symbols are needed to map more complex workflows.

A hash mark is added to an activity arrow when the activity is conditional upon a decision or business rule related to the deliverable that precedes it. The condition is added to the activity's name in parenthesis.

Notes: A decision is a deliverable. It passes the tests; it is physical and has measurable attributes. A different symbol, like a flow chart diamond is unnecessary. In the exhibit (right), the activity "Draft Sales Proposal (#110)" could follow its predecessor deliverable or be "repeated" if revisions are decided in "Review Sales Proposal (#120)." Both #110 arrows are the same activity, just different predecessor deliverables.

A dashed arrow connects multiple predecessor deliverables when they are required to complete the same successor deliverable. In the exhibit (right), the activity "Review Sales Proposal (#120), consumes both the Sales Proposal Draft (#110) and the Published Sales Budget (external blue). The dashed arrow is not a resource consuming activity; it's a dummy task.

This dummy task notation sometimes frustrates the classic flow charter, as the deliverables connected by the dashed arrow do not depend upon each other. Read the map as a flow of deliverables, not a flow of activities.

back to top

Reading the map correctly.

Focus on deliverable completion order.

Remember, a Process Triage™ Workflow Map is deliverable-oriented, meaning, focus on the circles, not the arrows when reading it.

Readers familiar with common flow charts expect the work to be in the circle, not on the arrow, as common flow chart arrows just indicate flow control.

Say the phrase "We can then complete ..." and describe the deliverable, then go on to the subsequent deliverable, again saying, "... then we can complete..." and so on.

When you encounter multiple, simultaneous upstream deliverables, just point to them in order saying, for example (see exhibit), "After the Sales Budget is Published and the Sales Proposal is Drafted, we can Complete the Proposal Review. If the proposal needs revisions, we revise and re-review it. If it's approved, we can then complete the Sales Proposal Presentation... and this concludes this milestone."

Here is a map sheet that compares Process Triage style to typical flow charting. Requires .pdf reader.

back to top