Understanding the work is the most important and first step. There is no point doing anything else until you understand what people are doing now, what they are expected to be doing, the gap between those two things and why there is a gap in the first place. The good news is that this\u00a0does\u00a0not have to be a mysterious process. We have been analyzing processes, roles, tasks, and jobs for years and it comes down to clarifying the following. (Just to avoid entering the entire string every time, we will just use the word “process” to refer to both the process and the work or tasks.)<\/p>\n
- \n
- Overall Mission<\/strong><\/span>: What is the process for? Why does it exist? What does it achieve?<\/li>\n
- Output(s):<\/strong> <\/span>What tangible output is generated?<\/li>\n
- Criteria:<\/strong> <\/span>How can you tell a good output from a poor one?<\/li>\n
- Tasks or Steps:<\/strong><\/span> What do people have to do to produce the output? \u00a0If you have time, you can define criteria for tasks as well.<\/li>\n
- Gaps and Causes:<\/strong><\/span> Where do outputs or tasks fall short of what the criteria specifies? \u00a0Why?<\/li>\n
- What tools<\/strong><\/span> are used at what steps in the process? Note: This is not really the process anymore but tools, especially information tools, are used so frequently today that they are part of the environment in which the work is performed.<\/li>\n<\/ul>\n
To improve capability, start looking for gaps with causes that can be fixed. Look for difficult tasks (i.e., those that require lots of skill or practice or even those that fall short of standard frequently). Then, look for effective ways to improve performance. Usually, there are three choices, listed below in order of preference<\/p>\n
- \n
- Simplify the task. Take out some steps or decisions.<\/li>\n
- Transfer capability to a tool. For example, move complicated or difficult calculations\u00a0to a tool. Or create a quick-reference guide so performers rely less on memory.<\/li>\n
- Train people.<\/li>\n<\/ul>\n
Collecting and Documenting the Work Model<\/h3>\n
So if we are starting with the work, we need to capture that information so that we can see it and talk about ways of changing it.\u00a0We use the format below for 98% of our analysis, whether the project is to build training or improve a process and whether we are facilitating a group meeting or working with an individual SME. \u00a0We like this model for several reasons.<\/p>\n
- \n
- It focuses on the work<\/strong><\/span>. Swimlane process maps are more popular but they can get confusing. They focus on the roles but we find that they can sometimes hide unnecessary steps. On the other hand, the horizontal flow seems to push you towards finding ways of simplifying or eliminating steps. And, in a lot of environments, roles can get\u00a0fuzzy or shared between different job titles, but the steps are usually pretty constant.<\/li>\n
- Allows identification of trouble steps and tools.<\/strong><\/span>\u00a0When you are thinking about a given task and the problems that can arise, it is a natural time to consider what to do to eliminate that problem. This extra information really doesn’t fit on a swimlane model.<\/li>\n
- Complex processes work fine using decision boxes.<\/strong><\/span> We once mapped an entire quality system (using eleven \u00a0teams and 84 separate processes in an eight-week period of time…it was a busy summer) for a large medical device company using this format. There were a lot of complex and interdependent tasks but the format held up. I would argue that this approach supports a work simplification mindset because you see the necessary sequence of steps or outputs needed to get something done (and you get rid of things that are not necessary).<\/li>\n<\/ol>\n
Here is an overview of the format. (For larger view go to http:\/\/www.prhconsulting.com\/resources\/newsletters\/downloads\/ProcessDoc_prh_08-28-14.pdf<\/a> .)<\/p>\n
- Allows identification of trouble steps and tools.<\/strong><\/span>\u00a0When you are thinking about a given task and the problems that can arise, it is a natural time to consider what to do to eliminate that problem. This extra information really doesn’t fit on a swimlane model.<\/li>\n
- It focuses on the work<\/strong><\/span>. Swimlane process maps are more popular but they can get confusing. They focus on the roles but we find that they can sometimes hide unnecessary steps. On the other hand, the horizontal flow seems to push you towards finding ways of simplifying or eliminating steps. And, in a lot of environments, roles can get\u00a0fuzzy or shared between different job titles, but the steps are usually pretty constant.<\/li>\n
- Output(s):<\/strong> <\/span>What tangible output is generated?<\/li>\n
![\"ProcessFormat_prh_08-28-14\"](\"https:\/\/prhconsulting.com\/blog\/wp-content\/uploads\/2014\/08\/ProcessFormat_prh_08-28-14.png\")
<\/a> \u00a0 Next issue, we will look at how to use this information to improve a process. Later, we will look at how to use it to identify supporting capabilities and tools.<\/p>\n