August 17, 2017

Closing the Business and IT Divide

Millions of dollars spent, countless hours wasted, and frustrated business users seem to be fairly standard outcomes when IT and business try to work together. While this problem seems apparent, little progress has been made. What is happening?

I believe two key factors are in play. First both the IT and business folks are operating under a number of faulty assumptions. Here are some flawed assumptions from the IT perspective.

  • Business users know their process.
  • Business users know what is wrong with the process and how to fix it. (Give me an IT solution even if that is not the problem.)
  • There is no value in doing an “as is” flow chart.
  • If we do an “as is” map, then let’s put every variation of the process on one map. (It ends up looking like spaghetti and meatballs.)
  • IT can go it alone, and IT professionals sometimes try to be heroes, and will attempt to make things work even if no one else does their part.
  • We don’t have the time to do a lot of analysis because business wants a quick solution. (Which may be true, but is damaging.)

From the business side, here are some flawed assumptions:

  • IT is the only solution to the problem.
  • I (the manager) have already figured out what IT solution I need, just implement it.
  • I (the manager) know the process well. At least I know what they “should be” doing.
  • I (the manager) know what’s wrong with the process.
  • Business users know what their customers want. (A customer is the entity at the end of the process and receives the output.)
  • Business expects that IT will take care of everything, with little or no effort on anyone else’s part. (Which may be true, but is damaging.)
  • We don’t have the time to do a lot of analysis because we want a quick solution. (Which may be true, but is damaging.)

The second factor which causes the divide is a deficient methodology. I researched the International Institute of Business Analyst’s Body of Knowledge (IIBABOK), Version 1.6. While the scope is wide, there are some glaring omissions.

IT folks spend a considerable amount of time gathering requirements. From the IIBABOK, Chapter 4: Requirements Elicitation, here is the intended audience.

• Marketing

• Project team

• Subject matter experts

• Primary and secondary stakeholders

• Current/potential users of a system.

Interestingly there is no mention of the Customer. (The customer can be internal or external. The customer is the entity at the end of the business process and receives the output.) What does the customer of the process need, want, expect, or desire? The most important group in any improvement methodology is the customer. The Customer requirements are critical since I believe the purpose of all business processes is to meet or exceed customer requirements. Both Six Sigma and Lean methodologies are built around customer requirements. Shouldn’t we find out how the process is performing based on customer requirements? I have numerous examples of where the business users guessed what their customers wanted. When we interviewed the customers, we found the guesses to be way off target.

The next problem in the IIBABOK is generating the process model. According to the IIBABOK, a workflow model represents:

• business activities,

• the sequential flow of these activities,

• the persons who perform the work,

• key business decisions that affect the flow of work, and

• the start and end points of the process flow.

In addition to the diagram, some textual information is also required to ensure that the diagram is useful and understandable. For example, each activity requires at least a meaningful description. Other information, such as process volumes (e.g. time, costs, resources), may also be collected.

 

The main omission in the above is finding out what’s wrong with the current process. In my 21 year career as a process improvement consultant, I have yet to find a perfect “as is” process. How can you create a better process if you don’t know what’s wrong with the current one?

 

When we analyze processes we look at the process from various perspectives which I call “lenses of analysis.” The lenses are:

Customer satisfaction (As mentioned earlier)

Worker frustration

Quality issues (Six Sigma and Lean methodology)

Timeliness issues (Lean Methodology)

Cost (Activity Based Costing)

Waste (Lean Methodology)

 

I seldom use all six lenses. My favorites are customer satisfaction, worker frustration, quality issues, and time. After we have analyzed the process and found issues, problems, and key data, they are then placed on the “as is” flow chart so everyone can see them.  By making the problems visible, it:

  • Helps pinpoint problem areas
  • Shows that the “as is” needs fixing. We can’t just automate the
    “as is.”
  • Allows everyone to reach agreement on prioritization of problems
  • Identifies some obvious solutions
  • Shows many solutions require no IT
  • Is an excellent way to gather requirements
  • Makes the case to senior management to make the change
  • Reinforces that the problem is the process, not the people.

 

We propose another methodology to do process analysis, gather requirements, and create a new process. We think this methodology addresses the faulty assumptions mentioned earlier and at the same time overcomes the shortfalls in the IIBABOK approach. As you examine the approach, you will find that the IT representative is part of a team. And it is the team that identifies problems, finds solutions, and invents the new process. IT is there to enable the improved process.

 

This methodology has four phases and ten steps.

 

Phase 1:  Getting Started

 

1.         Introduction to Business Process Improvement:  This step is comprised of two parts.  The first is a meeting with senior management. In this meeting there is a discussion regarding barriers to process improvement, impact of job change, clarifying roles and responsibilities, identifying the project manager, and creating the communication plan to staff. The second part is an all-hands meeting to launch the effort and answer questions from staff.

 

2.         Process Improvement Team Formation:  The team is largely comprised of the people who work in the process.  We look for those who want to make a change and are considered the best and the brightest. One team member comes from outside the targeted process. This person is “hard-wired” to ask “why.” We call this person the Maverick. It is this person’s job to challenge the team to think outside-the-box. The team has a representative from IT. This person will learn in detail the “as is” process and the problems with the “as is.” She will be very helpful when the team creates the “to be” process. The team also has a facilitator and a project manager. The first work of the team is to create ground rules on how they want to function. Next the team crafts a communication plan to all affected stakeholders.

 

 

Phase 2:  Flow Charting, Interviewing and Benchmarking

 

3.         “As Is” Flow Chart:  Flow charting is a technique that allows us to map the current process in detail.  To create an accurate “as is” map, the team remembers a time in the past when the process occurred.  This is a true “as is” because this really happened. While this is only one variation of the process, other key variations are mapped on separate documents. By remembering a time in the past, it allows the “as is” map to be created very quickly. The process is documented in terms of time, poor quality, and where frustration occurs.  The bottlenecks, delays, areas of poor quality, and high frustration areas are ranked and prioritized.  Through process mapping, the team will identify which process design principles should be used in the redesign.

 

4.         Customer Interviews:   The customers of the process are interviewed to discover what they think of the current process, what they like about it, and what they do not like about it.  The process is evaluated by the customer in terms ranging from “excellent” to “unacceptable.”   In addition to interviewing customers, the staff members that work in the process but are not part of the Process Improvement Team are also interviewed to get their ideas, comments, and suggestions.  All of this information is shared with the team, Project Manager, and Senior Management.

 

5.         Benchmarking and Best Practices:  Often, other organizations have discovered innovative ways to design processes.  Instead of “reinventing the wheel,” we find out who does this process the best.  Members of the team will develop questions and then interview innovative organizations.  This information is shared with the team in order to incorporate the best ideas into the redesign.

 

Phase 3:  Process Redesign

 

6.         First Cut Redesign:  Since the IT representative now knows the process very well, we ask this person how IT can enable the changes the team is thinking about. We then ask each team member to create a new process that incorporates design principles, customer feedback, fixing frustrations, fixing quality problems, eliminating non-value added steps, and information technology. This task is done with a “clean sheet of paper.”  We ask:  “If we were to invent this process today with what we know, what would it look like?”  Here we are looking for “out-of-the-box” thinking and innovative ideas.  Process design principles significantly enhance creating the new process. Process design principles are distilled best practices from world class organizations. The team also creates a list of things necessary to bring about the redesign.  These items become action items when we move into implementation.

 

7.         Share Redesign with Senior Executives, Employees and Customers:  If the redesign has any controversial elements or requires major capital outlays, then the Senior Executives need to review and approve the plan.  Turf issues and other types of resistance may surface at this time.  In addition, the redesign is shared with the rest of the people that work within the process in order to get their ideas, comments, and suggestions.  If some customers are available and involved, the redesign is shared with them as well.  This type of feedback is extremely helpful and is used in the final redesign.

 

8.         Final Redesign:  Any changes that were required from the Senior Executives, the staff, and customers have now been incorporated.   Key items get prioritized, and the project is now ready for implementation.

 

9.         Implement Changes:  This stage of process improvement is often the hardest to gauge in terms of time, resources, and obstacles.  The project manager makes sure that everything gets done on time and that people meet their commitments.  Action plans are developed and assigned. The IT representative will begin implementing the key requirements which might require software changes, writing code, and equipment upgrades.

The facilitator can work with the organization to address obstacles that arise.  He can smooth the transition into the new process and help people adjust to new ways of working together.  Sometimes simulations or pilot programs are initiated in order to test the new design before a complete changeover is made.  This reduces risk and allows for a smoother transition.

 

 

Phase 4:  Celebrate Results and Continuous Improvement

 

10.       Monitor Results and Continuous Improvement:   At this point the Process Improvement Team has made significant, measurable progress in improving the process.  Feedback mechanisms, measurements, and continuous improvement become embedded in the process.  The team is rewarded and recognized for its accomplishments.  Expect the team to continue to meet on some regular basis.  Improvement in cycle time and quality will be an ongoing part of your organization’s culture.

 

We have been using the above methodology for 22 years with great success. The keys are:

Strong project manager

Senior management commitment

At least one bright team member

The IT person knows the technology cold

 

Let’s close the IT and Business divide. I think the above is a big step in that direction.

 

If you would like to discuss any aspect of this article feel free to call (925-459-8755) or email me (dan@valuecreationpartners.com).

What does the law, policy, rule, directive, etc really say?

When we are engaged in a process improvement effort it is not uncommon for someone to say, “The policy says we can’t do that.” Since this person has been with the organization a long time, we accept that pronouncement. However, I have found in about 50% of the cases, the interpretation of of the law, policy, rule, etc is wrong. In fact it can be radically incorrect.

I tell the folks on the team I am from Missouri. The Missouri state slogan is “Show me.” So when a policy, rule, or law is mentioned, I say “show me.” What I find is often surprising. I think there is a tendency in organizations to gradually drift to being more conservative. Consequently, the organization becomes more and more handcuffed.

Statements around policy, laws, directives, and rules often don’t challenged. But they should be challenged. You might be amazed by what you find. I know I  have.

Risk-Free Process Improvement for the Public Sector

Many public sector organizations are stuck in the status quo. Why is that? There are a couple of reasons:

In some places, the pressure to change has not reached a critical level.

Making changes entails risk. The perceived risks outweigh the rewards.

The current budget situation has been placing huge stress on many public sector organizations. The typical response has been to cut services, since these leaders do not see the waste that exists in their organizations. People who practice “lean” techniques can identify waste and then apply methods, techniques, and countermeasures to eliminate or shrink these wastes. If waste could be cut 20-30%, services could likely be maintained. Our Analyzing and Improving Office and Service Operations (Lean Office) seminar trains participants to see waste in their own organizations. By using lean tools and techniques, these wastes can be dramatically reduced.

What about the risk of making changes? A mistake in the public sector is disproportionately punished, especially if the mistake gets in the news. It is safer to maintain the status quo, even though the status quo is incredibly inefficient. So what can be done to make change safe?

The first and most important step is to test, practice, simulate, or role play the change. If we were using a military metaphor, we would not be using live ammunition. Of if we use a sporting metaphor, this is what a professional football team does from Monday through Saturday, practice. Hardly any organization tests, practices, or experiments with the changes they are considering. They go from idea to doing. Then they pick up the pieces.

If we precede every process change with a safe test, experiment, role play, or practice, then we can work out the “bugs” until things are going smoothly. We can do “what if” analysis in our practices, tests, and experiments. We can stress the new process until it breaks. Once our testing, practice, or role play is running smoothly, then we can up the risk a little.

The next step is to conduct a pilot program with the new process. Here we are using “live ammunition” so if something goes wrong it could have negative consequences. We reduce the risk by watching and monitoring the pilot very closely so we can react immediately to any issues. Secondly, because it is a pilot, the process change has not been rolled out extensively. Once the pilot has been operating successfully for some time, then we can begin to expand the process change in other areas. In fact, those who worked in the pilot can become trainers for others in the organization.

Make testing, practice, experiments, role plays, and simulations a part of your organizations change management approach. Stress the process change in a safe way to find its weaknesses. Do “what if” analysis in your practice or role plays. These techniques allow you to safely change your processes while dealing with the pressures of budget reductions. Manage the organization in a state-of-the-art, best practice fashion. Continue to deliver needed services, even though your budget is reduced. If you want to learn how to experiment, practice, test, or role play process changes, contact us at 925-459-8755.

The Advantages of Process Mapping

A process map allows us to see the flow of work and information through an organization. In office and service organizations it can be very difficult to see the process especially as work moves from department to department. Often, this visual representation creates “ah-ha” moments from staff, supervisors, and managers. You hear comments like, “I didn’t know it was that complex.” Or “Now I know what that other department does.”

The first map mirrors how work is currently done, and is called an “as is” map. The “as is” map can be analyzed from different perspectives, called “lenses of analysis.” The typical lenses are worker frustration, time, cost, and quality. Each lens reveals aspects of the process which are working or not. This visual representation of issues and problems allows everyone to come to a shared understanding and provides motivation to make improvements in the status quo.

Picking which lens to use on the map can be driven by customer complaints, staff frustrations, or management concerns. For instance, if the customers are complaining about how long something takes, then the time lens is used. Or if there are many mistakes, errors, and rework, then the quality lens makes sense. For each lens, there are robust process improvement methodologies. The methodology for the time lens is the Toyota Production System, which is called Lean in North America. The methodologies for quality are Six Sigma and Lean. The methodology for cost is Activity Based Costing. As you can see, there is a specific methodology that is applicable to the goal of the process improvement effort.

My favorite lens to begin a process improvement effort is the worker frustration lens. The advantages are:

  • Staff gets a chance to vent about their frustrations, which is cathartic.
  • The frustrations are often linked to quality and timeliness issues.
  • By coming up with quick wins, buy-in for process improvement soars.
  • Many of the frustrations are linked to process design principles, which are best practices from world-class organizations.
  • The design principles give us direction on creating a new process that is dramatically better than the current one.

Research has demonstrated that the bulk of organizational issues have their root cause in the process. If we are not attacking root cause, the problems are sure to resurface. A process managed organization can make remarkable progress in efficiency and effectiveness. In addition the work life of everyone improves because staff involvement in root cause analysis makes an engaging work place, which is much less stressful.

The journey on process management starts with process mapping, followed by process analysis, process improvement, process redesign, and finally continuous process improvement. Join us in this exciting journey in building organizations that are robust, efficient, happier, and more effective. Check out our Process Mapping and Process Improvement seminar here.

Process Mapping, Functional-Activity Flow Chart

The last post described the big picture process map, which I call the Macro. The next level down in detail is titled the functional-activity level flow chart. Function means job title, not department title. Activity means the task the person is doing. Here we can see who does what and when it is done. These maps are often called “swim lane” maps or in Visio, they are called cross-functional maps.

It is at this level when the “lenses of analysis” can be applied. The lenses include the following:

  • Customer Report Card
  • Worker frustration
  • Timeliness
  • Cost
  • Quality

In future posts I will talk more about the lenses of analysis.

The map you create will be one variation of the process. Remember if we put every variation on one map, it becomes very difficult to understand the map. Time is flowing from left to right. That means we can not have arrows that go from right to left, which would indicate we went backwards in time. Arrows can go straight down, which means two activities happen very close together in time.

Here are the steps to complete a functional-activity flow chart.

1.  Name the process, write it at the top of the page. Remember a time in the past when this process was performed, or create a map on what typically happens. Remember this is an “as is” map, not a could be, should be, or might be.

2.  Begin mapping. Your map will start with a job title. Write it on the upper left side of your flip chart page. Now write the activity that person performed. The process starts on the left and flows to the right. Use verb-noun combinations to describe the activities and questions to describe the diamonds.

3.Continue mapping as the flow moves from left to right. Add new job titles as the work flow moves to the next person.

 

4.  Separate job titles by horizontal lines.  Connect all of the boxes and diamonds with arrows which indicates the direction of the flow.

5.  Number each box and diamond.

Here is an example of an Insurance process where the application was complete and the review was done by an underwriter.

 Imagine we put every variation on the map, it would look something like the following.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

While is may seem like more work to break out the variations, it really helps the reader to understand the map when one or two variations are on a single map. Remember, the goal is to make the map easily understandable. If you want to practice on creating these maps, join us for our seminars in San Francisco.

Macro Level Process Map

When I begin the facilitation of a process mapping effort, the first map I create is the macro level map. The macro level is the “big picture.” We are looking for the main steps in a process. To make sure the team does not delve down into detail, I allow the map to have only 2 to 7 steps. If we get 8 or more steps, then we have to combine steps.

The macro map is largely for me, the facilitator. With this map, I can see the main steps that comprise the process. I can also see the scope of the process. Are we mapping world peace or is it something manageable?

Often there is discussion by team members as they try to construct the map. There might be disagreement on where the process starts or ends. I let this conversation run as long as it takes. The reason is that the team needs to come to consensus and this discussion is useful. At the end, there is an agreement on the main steps and a shared understanding of the process.

The macro map is also useful if we are in a hurry and need to get to the key issues fast. I will ask the team, are there one or two steps that are most problematic? Very often the answer is “yes.” If that is the case, we can then dive into detail on that step instead of mapping the whole process.

Below are some macro level maps.

Once in awhile, I can actually see issues at the macro level. I had one client have a rework step as a regular part of their manufacturing process because they built the system before all the customer requirements were obtained. When they finished getting the specifications, they then had to go back and do rework. That was the first time I ever saw that type of manufacturing process.

Our next entry will be on the the functional-activity level. Sometimes you hear these called swim lane maps. In Visio they are called cross-functional maps. At the functional-activity level, we go into more detail. Imagine you have a microscope and you now increased the magnification. That is the same concept in process analysis and it is at this level that most of the analysis is done.

If you find this useful, please check out our San Francisco public seminars on Process Mapping and Improvement here.

Dan’s Second Rule of Process Mapping Continued

The second rule of process mapping is that the problems in the process should be easy to see. In my last post, I talked about using different colored post it notes and symbols to draw attention to process issues. I suggested using blue post it notes for worker frustrations, orange notes for quality issues, green post it notes for value-added activities, and red dots for delays and waiting.

The next way to make the problems visible is with data. Here is a list of items that can give us insight into process performance:

  • Process time (P/T)
  • Lead time (L/T)
  • Setup time
  • Batch sizes
  • Demand rate
  • Percent complete and accurate (%C%A)
  • Number of people
  • Inventory
  • Reliability
  • Available time

Process time is the amount of time spent working. One way you can get this data for a particular activity is to ask people “If you were not interrupted, how long would it take you to do _______?” Or you can use a stop watch to time someone when they are doing the activity. We represent process time as P/T.

Lead time is the amount of time from when the step or activity starts to when it ends. Lead time includes process time,  move time, set up time, wait time, review time, and rework time. There is lead time for a particular step. There is lead time for a complete process, called total lead time. Lead time is represented as L/T. If you find a small amount of process time for a step, yet a large amount of lead time, usually the difference is caused by waiting. A simple equation might make this easy to understand. Lead time = process time + wait time. 

Setup time is the amount of time consumed in preparation to do the work. For instance, suppose you have to do a report. Before you can start the report, you must go get files, load a software program, and finally scroll to the page you need. Now you can begin the report. Setup time is the work that precedes the work of the step. If setup time is large, it encourages people to do multiple activities of the step, which we call batching. In lean, we do not like batching. So in order to cut batch sizes down, setup time needs to be shrunk.

Batch sizes tell us how many items are processed at one time. Batching is only convenient for one person, the batcher. Everyone else has to wait for the batch to be done. Batching leads to waiting, overproduction, inventory, mistakes, extra processing, and movement. As we cut down on batch sizes and run them more frequently, the above issues diminish and we get closer to continuous flow (nirvana).

Demand rate comes from the customer. Demand rate is the time frame expected by the customer for something to be done.

The percent complete and accurate is our quality measure for office and service processes. Don’t we want everything we get to be complete and accurate? This measure is represented as %C%A.

The number of people refers to the number of people who perform a particular activity.

Inventory is measured by how long items are in inventory. This could be measured in seconds, minutes, hours, or days. Obviously if the amount of time something is in inventory is large, we want to find out why.

Reliability refers to the reliability of the systems and software you use. Here we are looking for uptime. If your system is “down” how long does that typically happen?

Lastly is available time. Available time is the amount of time allocated for this person to do this activity. In office and service work, people wear multiple hats. It could be that demands for other tasks impinge on the amount of time available for another task. By calculating available time and comparing that to demand rate, process time, and the number of people, we could see the cause of a bottleneck.

Below is a process map with some of these items. There is a time line across the bottom of the map that shows process time and lead time by step and also the sum totals for the process. Batch sizes, inventory and percent complete and accurate are also shown. If you compare this process map to the one from the prior post, you can see we converted the post it notes and symbols into data.

Process data helps us focus our resources. It tells us how large a problem might be. And when we institute countermeasures, it tells us if our countermeasures are working.

 

Dan’s Second Rule of Process Mapping

Dan’s second rule of process mapping is that the problems in the process should be easy to see. The “as is” process map is the starting point for analyzing a process. I often talk about “lenses of analysis” which refer to the different ways we can look at the flow of work and information through an organization. In this blog entry, I am going to show some simple graphic symbols and comments to identify issues.

The first lens I use is the frustration lens. Here we ask those who work in the process what frustrates them. The frustrations are written on blue post it notes and placed on the map where the frustration is experienced. I like the frustration lens for these reasons:

  • People get to vent about the things in the process that aggravate them.
  • The frustrations often link to quality problems.
  • A grouping of blue post it notes highlights a big problem.
  • By finding quick fixes to the frustrations, buy-in for process improvement goes through the roof.
  • The frustrations often link to process design principles. Process design principles are best practices from world class organizations. I discuss 38 design principles in my book, Process Mapping, Process Improvement, and Process Management.

Another lens is time. Here we are looking for places where the work stops and waits. These are represented by red dots with a W. The W is for waiting. Ask your staff what is causing the waiting? Is it how work is prioritized? Is it a staffing problem? How can you shrink or eliminate these wait areas?

Where quality problems crop up, I use a pink or orange post it note with the quality problem written on it. You would want to know what is the root cause of quality issues. If we do not find root cause, the issue will likely resurface.

In the example below you can see a simple process map with these symbols. See how these symbols makes the map much more interesting and focuses our attention to where the problems are occurring.

 

In my next blog post I will discuss the types of data that we can insert in our process maps. We cover this and much more in our Process Mapping and Improvement seminar. Hope to see you there.

Dan’s First Rule of Process Mapping

The first rule:  The process map should be easily understood by a naive person. What is the purpose of a process map? I believe it is to show the flow of work and information through an organization. Obviously, there can be a variety of paths that work and information can take, even in one process. Imagine what happens when we put all the variations that can happen on one map. It can look like spaghetti and meatballs. I have seen these maps and could not make any sense out of them. What is the value of the map if everyone gets confused?

Hence for the sake of clarity, do not pack every variation on one map. Instead put each variation on its own map. I title every map with the name of the process and the variation being shown. For instance, the map might be titled Sales Order Process, Order Validation Correct. While this might cause a little extra work for the mapper, it makes it much better for the person trying to understand it. Variations typically occur at reviews, inspections, or decisions. For instance, the reviewer asks, “Does it pass?” The answer could be “yes or no.” Each of those paths is a variation.

When I start mapping a process, I ask “Which variation of this process do you want to map?” We might start with what is considered “typical.” When I get to a decision or review, I ask “What typically happens here?” The person might say, “It typically passes.” I will not be mapping the “does not pass” route. That would go on another map.

Since I am on this topic, another issue surrounds “do loops.” In this case something does not pass an inspection and it gets sent back several steps in the process to do over. The do loop process can happen multiple times. Imagine a situation that the do loop can happened three times. You might indicate that with a 3 on the loop. What I suggest is to copy the do over steps as often as they occur. Why? The visual of all of the steps being repeated is a powerful message of the waste occurring. The do loop actually hides the impact of repeated work. Showing all of the steps as they occur makes the waste jump out.

My next entry will be on my second rule, which is: The problems in the process should be easy to see.

Check out our Process Mapping and Process Improvement seminars in San Francisco to learn these concepts and techniques. 

Is Micromanaging an Aspect of Lean

What is micromanaging? It is when a manager closely observes or controls the work of her or his subordinates with excessive attention to minor details. In micromanagement, the manager not only tells a subordinate what to do but dictates that the job be done a certain way regardless of whether that way is the most effective or efficient one. A pattern of micromanagement suggests to employees that a manager does not trust their work or judgment, it is a major factor in triggering employee disengagement.

Two important factors are at work in micromanagement. First is the lack of trust that the employee will do the job well. Second is the underlying lack of respect regarding the worker’s intelligence and desire to do a good job.

If you have someone telling you how to do your job and monitoring it closely, it sends a message that the worker is not valued. Research has shown that being valued is one of the main factors in loyalty and retention.

How does Lean approach the goals of doing high quality work? The first step is to identify the best way of doing the job today. That would include evaluating worker quality and speed. When we can quantify a superior way to do something, shouldn’t everyone who does that job do it in the best way we know how to do it? That best way is called Standard Work. Standard Work is the best way to do work right now, which also implies we might find a better way to do it tomorrow, and then that way will become Standard Work.

In Lean we encourage and reward people for finding improvements in work processes and the ergonomic aspects of the work space. One of the ways to get workers to focus on improvements is to teach them to find waste. Then we want ideas to shrink or eliminate these wastes.

The most important place in a Lean organization is where the work is done, the Gemba. Consequently, the most important person is the one working in the Gemba. There is intense focus on the Gemba, with managers and supervisors doing “Gemba walks” regularly. In this fashion, lean can resemble micromanaging, but not with the attitude of distrust or disrespect. Quite the contrary, managers and supervisors have an eye for the things that get in the way of the worker. Managers and supervisors have the desire to partner with the worker to make the work processes and work space the most conducive to safe, efficient, and effective activities.

A micromanager would likely blame the worker when something goes wrong. In Lean, the manager would partner with the worker to uncover the root cause and jointly create countermeasures. It might be the workers responsibility to test the countermeasure, and ultimately implement it. We have confidence that the countermeasure will be implemented because the worker was highly involved in creating it. Remember people support what they help create. And people resist, fight, and sabotage what we ram down their throats.

Yes the devil is in the details. However there is a world of difference on how we manage them. If you find this useful, please check out our training class titled Analyzing and Improving Service and Office Operations (Lean Office).

Micromanaging Approach

Lean Approach

Little respect for the worker

The worker is the most important person

Little trust that the work is done correctly

The worker is following standard work

Boss tells me how to do the job

The worker is following standard work

Boss comes up with improvements

Worker engaged in finding improvements

Blame the worker when something goes wrong

Worker and supervisor jointly find root cause, jointly come up with countermeasures, and the worker tests and implements the countermeasures