In my previous articles, I have introduced you to the basic concepts and building blocks of a swimlane process map. In this article, I will go through a simple example of creating a process map. I will lead you through the method I usually use when starting to create a new map. Naturally, there are other ways of doing the mapping depending on your personal preferences and your company's general methodologies.
As I mentioned in my first article of the series, you first have to set the boundaries for the process: where does it start and end. I typically start from the end, asking "What is the deliverable that comes out of the process?" In this example, the deliverable is "Contents Specification," so I write a definition for the specification:
Name: Contents Specification Description: A document describing the planned contents of a user manual. Template: Stored in: shared group disk on the project folder Quality criteria: complies with the template, reviewed by editor, approved by relevant approver
The next question I ask is "What triggers the creation of a contents specification?" It is important to understand what the actual trigger is. With contents specifications, it could be a project milestone (after this milestone, we start creating contents specification), another deliverable outside the documentation project (when product requirement specifications have been approved, we start contents specification phase), or it could be, as in this example, a documentation project plan in which all the phases and schedules for deliverables have been planned. I would then write a definition for the project plan or rather re-use the definition created in the project planning process.
When the trigger has been identified, I find out what the first activity in the process is and what role will be performing the activity. Remember that a process activity is a series of steps performed by a single actor and can thus be something relatively small, like approval, or something that will take weeks in working time, like writing a contents specification. So, in this case, the first activity is "Write draft contents specification," and the role performing the work is "Author." Both need to be defined in more detail to understand what is actually happening.
Activity: Write draft contents specification Description: Author studies product documentation and available user and task information to understand what should be included in the manual. Based on the analysis of the information and further discussions with SMEs, author creates a draft contents specification. Additional inputs: requirement specifications, product briefs, user and task analysis, information from SMEs Templates: Guidelines:
Note that the Guideline could also be a link to a work instruction but in this case, the company uses examples as guidelines. Note also that the template is now linked both to the deliverable specification of the contents specification and to the activity in which the template is used to create the contents specification. You could also link the template just to the deliverable definition. Linking it to both places gives the process users more ways to find the template but naturally means more maintenance as the link has to be maintained in several places.
Role: Author Description: A person responsible for specifying the contents of individual documents and writing them.
Note that the Author role has been specified so that the same role can be used when describing the process of writing the actual document based on the contents specification. If the role definition would concern only contents specification work and you would have a separate role for the writing work, the role name would have to be more descriptive, like "Document planner" or similar.
Then it is time to start drawing the map. The map can be drawn with a specific process-mapping tool or even with flip-charts and post-it notes, which can be used very effectively with a group that's trying to map an unclear process since then you are able to move things around easily and the whole group can see the outcome. The map begins with a starting point that triggers the first activity.
After you begin, the steps for creating a process map are quite straightforward: you identify what comes out of the activity and what is the next activity handling the output until you reach the end, the final deliverable of the process. The process can have alternate flows depending on some of the decisions made in the process, and it can also have parallel flows in situations where two roles perform some tasks concurrently.
Below is an example of is the full process map for creating a contents specification. All the activities, roles, and deliverables are defined as shown above but not included in this article. Note that there are two alternative ways of handling the reviews and approvals depending on whether or not the contents specification is sent back to the reviewer after the modifications. In this process, I have assumed that the editor gives feedback but does not receive the contents specification back for another review, whereas the approver gets the document back if it is initially rejected.
With more complicated processes, the process diagrams can become quite long and complex, in which case the process can be broken down to sub-processes. The main process then consists of a series of sub-processes that are described separately in detail in different sections.
Swimlane process mapping is a good method to show the process flows in a structured, visual way. However, the graphical representation is not enough to understand in detail what goes in the process—the detailed descriptions are needed as well.
This article is the personal opinion of the author and does not necessarily reflect the opinion or practice of Nokia.