Getting a job done requires more than just the work.  Often times, there are inputs provided and paperwork handed over, not only before the project, but also between tasks within the project. Now, paperwork may take the form of electronic documents, or records in a database. But either way, handing off or accepting documents is often how we set the boundaries between tasks and transfer control from one party (or project step) to another.

The map used to show the flow of paperwork is one of the seven most-used process maps that we are describing in our process map series.  The document map displays visually what information you should expect to receive, and from whom. It also shows you what information you are expected to produce for someone else. For an example, let’s go back to my family vacation story. One of my usual stops before any family vacation is AAA for a TripTik. You get a custom-printed series of roadmaps showing the territory that you plan to traverse. Tall skinny pages are comb-bound into a book. The route is highlighted, usually with an orange highlighter that is easy to see in daylight and darkness.

Handing off a simple document like a highlighted road map leaves little doubt about what is intended and that control is being handed off from the navigator to the driver.

In our vacation travel example, a TripTik map page could serve as an output document from the navigator to the driver at the “provide directions” step.  Sure, after several hours on the road my wife might just tell me where to go. But she might better show me where to go. With experience, we have agreed that a highlighted TripTik removes all ambiguity between right turns and left and otherwise clarifies the navigator’s intentions.

In this small area of the swim lane map, the navigator "provide(s) directions" to the driver. The navigator is actually handing off a highlighted roadmap, or TripTik, to the driver. This hand-off shows up on the document map shown here. See the previous blog post for the full swim lane map where this example comes from.

Document Maps Help You Recognize Hand-Offs

A simple document map like this one makes it clear what documents are inputs and outputs at each process step. You can see what documents you get, and which ones you need to hand off to others.

Look at the first row labeled “Navigator.” She obtains a TripTik map and tourist brochures (received from outside the process).  The navigator executes the ‘plan route’ process step and produces a ‘highlighted route’ and ‘turn-by-turn instructions’ for the Driver. All four documents are, literally, physical documents, and thus are shown on the map.

Next, the driver uses the documents obtained from the navigator in his ‘driving’ step and produces a status report showing the current location. Notice that a parallelogram is shown instead of a document symbol, indicating that the status report is not a written document, but a spoken one in this case.

The passengers, who don’t really own any process steps, produce a break stop request as part of a pre-defined process called “break process.” That is, the break process comes from somewhere outside of the Driving process. Here, passengers produce a spoken request for a break. Again, a parallelogram is shown, indicating that no actual written document is produced.

Document maps should show all the important written documents so that you could audit your inventory of reports for compliance purposes. The document map is not a recreation of the swim lane map. Decisions and process detail can be left out. You are showing the main steps in rough order.

Document maps come in handy in quality systems like ISO 9001, which require that certain records (like product requirements) be created and maintained. Since they show the records your process creates, documents maps remind and remind process owners to generate output documents without having to name someone as the “document police.” And if you’re in the middle of the process, document maps can tell you if you have the inputs you need to do your job.

Last week I took you along on a family vacation to the Eastern Shore of Lake Michigan near Muskegon. Yes, we got there. But it was a longer journey than it needed to be. We could have spent less time travelling, and more time vacationing in the cool climes of Lake Michigan. Responsibilities between driver and navigator could have been more clearly delineated. The hand-offs could have been better communicated to cut down on some of the indecision and waiting that occurred.  Sounds good but, So how do you do that?

This swim lane process map shows the passenger (customer) in the first lane. Their role is mostly to ask questions. In the second lane, the driver accepts requests for breaks from passengers, and route adjustments from the navigator, who is shown in the third row.

Asking, ‘how are we going to get from where we are to where we want to be,” is a question of implementation.  What are the concrete steps we have to take to get there?  Who is going to do what, and when are they going to do it?

Using Swim Lane process maps is one way to answer some of these questions.  We like to organize Swim Lane process maps by putting the ‘START’ on the left and the ‘END’ on the right.  It’s easier to read the chart from left to right.  Organizing the Swim Lane map and other process maps in predictable ways, and not over-stuffing your maps with information eases communications, which is mainly why you create process maps: to communicate to others a process that you already know.

What’s In A Swim Lane?

Swim Lane Diagrams, as described in part I of our series on process maps, organize tasks by role.  A role gets a swim lane. You are responsible for every task, document or decision shown in your Swim Lane.  The chart above shows three swim lanes: Passenger, Driver, and Navigator.  In our swim lane maps, we always show the customer on top.  Arguably, my daughters in the back seat are the customers of the ‘drive home from camp’ process.  If it wasn’t for the customer, my wife and I might be in Cape Cod, or Colorado, or France.  But we wouldn’t be in the minivan in Michigan.  To determine who goes in the top lane of your Swim Lane map, use the “but for” test.  ‘But for my daughters, I would not be driving five hundred miles north to a very small town in Michigan.  The process would not be taking place.

How Swim Lane Maps Help

What really stands out in this Swim Lane map is that Driving and Navigation are in fact different roles.  Had we consulted a Swim Lane map before our trip, we would have clearly seen that the driver should not be attempting to navigate,  no more than the navigator should be grabbing the wheel and driving.  The roles are clearly distinct.  Swim Lane Maps visually communicate how the roles relate to and communicate with one another.

Swim Lane Maps keep you within the bounds of your role while defining hand-offs of control and information.

Customer Involvement Shows Up In A Swim Lane Map

Swim Lane Maps visually communicate the involvement of each role, the Customer role for example.  As in the example above from my family road trip, my daughters asks of the process, ‘are we there yet?’ and interrupts the process when it is, ‘time for a break.’ But my daughters are passengers, and not responsible for any process steps (rectangular boxes).  In simple processes, customers may provide information at the beginning of a process in the form of requirements, and at the end when they buy the product.  In more complex products, customer requirements may be injected more frequently. In the case of co-development or co-creation of products, customers may have responsibility for processes and therefore process steps would appear in their swim lanes.

ISO-certified organizations must gather requirements from customers. That could be shown as a requirements document, depicted in a process map as a process step box with a wavy bottom. Customer requirements could also stand alone in a separate requirements definition process.

In a Swim Lane Map, handoffs of control and information appear as vertical lines or arrows originating from an activity in one role and connecting to an activity in another. When my daughter asks, “Are we there yet?”, it shows up as a vertical line leading from a decision point. The answer produces different actions, which is another indicator that this role is a customer.

There are seven common Quality Tools you can use to understand and improve processes during a process improvement event.   Each tool helps you identify sources of variation and aids in the analysis, documentation, and organization of the information, which leads to process improvement. 

1. Flowcharts, or Process Maps, visually represent relationships among the activities and tasks that make up a process.   They are typically used at the beginning of a process improvement event; you describe process events, timing, and frequencies at the highest level and work downward.  At high levels, process maps help you understand process complexity.  At lower levels, they help you analyze and improve the process.
2. Ishikawa, Fishbone, or Cause & Effect Diagrams visually represent the causes of a problem – or effect – and help you determine the ultimate source of the problem — the root cause.  (This tool is called a “fishbone” diagram because of its appearance; Ishikawa was its inventor.)   The cause-and-effect diagram is used at the beginning of root cause analysis, to organize the causes of a problem (people, methods, equipment, materials, measurement, and environment) and prioritize them.
3. Data Checklists, check sheets, or recording tables are matrices designed to assist in the tallying, recording, and analysis of test results or event occurrences.  They are utilized in production to count defects and collect process data, which you analyze to identify opportunities for improvement.
4. The Pareto chart is named after Vilfredo Pareto, who came up with the Pareto Principle (or the “80/20 rule”), which says that 20% of the factors account for 80% of potential problems.  The Pareto chart ranks defects, causes, or data from the most significant to the least significant, in descending order.  Pareto charts help you separate the “vital few” from the “trivial many”.  They are typically used during process improvement analysis, to understand where to focus improvement for the greatest impact.
5. Histograms consist of vertical bars, side-by-side, that depict frequency distributions within tables of numbers and can help you understand data relationships over time (e.g., the familiar “bell curve”).  Histograms are generally used during process improvement analysis.
6. Scatter charts display relationships between dependent (predicted) and independent (prediction) variables.  They are used during hypothesis testing, to determine if there is a correlation between two variables and how strong the correlation is.  Less scattering indicates stronger correlation.
7. The control chart is a type of statistical process control tool.  Process performance is plotted over time against upper and lower control limits; this helps you readily identify process variations and enables determination of special cause and common cause variation.  Control charts are used during production, or after process improvement implementations, to ensure that processes are within control limits, or “in control”.

To achieve the best results, start by (1) drawing up a process map, so you understand the process flow.  Next, (2) analyze the process flows for the primary causes of problems and develop your cause-effect diagram.  Then, (3) collect data using check sheets and (4) plot your data using a Pareto chart and/or (5) a histogram.  Next, (6) determine the relationship of various variables in your cause-effect chain using a scatter chart.  Once you have solved your problem, (7) use a control chart to ensure that the process is staying within process control limits — demonstrate process control.

The Seven Quality Tools

To summarize, using these seven quality tools:

1. Flowcharts or Process Maps;
2. Ishikawa, Fishbone, or Cause & Effect Diagrams;
3. Data Checklists, check sheets, or recording tables;
4. Pareto Charts;
5. Histograms;
6. Scatter plots; and
7. Control Charts (SPC)…

…especially in combination, will help you improve your processes and achieve your objectives.

At work, we talk a lot about minimizing waste, improving processes, and implementing best practices. Lean and five-S are common words in our collective vocabulary. Everyone at the office is usually on the lookout for improvement opportunities and we document small improvements as Kaizens. There are times when I find myself using lessons from work at home. I’m not really thinking of work, per se, but rather about ways to do things better and make my life easier.

The key is to be prepared and execute your responsibilities with minimal waste and maximum efficiency. That’s precisely what Bizmanualz’s products and services are intended to do to our customers.

I recently moved. In order to upgrade my 13-year-old son’s room, my wife and I bought some new furniture packaged in flat boxes. As the “head of the house,” the bulk of the assembly task fell on my shoulders. It’s not that I haven’t assembled furniture before, but with several different items to make in a short period of time, I started to look for ways to save time and to better prepare to finish a piece of furniture.

I ended up using several learning points from work to do a masterful job at assembling the furniture. The work lessons are in parentheses:

1. Assemble the furniture as close as possible to where it finally sits. (Don’t deviate from your goals)
   Obvious as it sounds, I have suffered in the past by having to move large pieces of finished furniture from one side of the room to the other.
2. Make sure you have all the parts BEFORE you begin the assembly. (Plan well before you begin the project)
   What if you are 70% done and realize that you are missing a cam screw or a specialized screw? It’s better to know that in advance so that you’re not waiting for replacements to arrive via mail next week.
3. If any additional tools will save you time, get them! (Look for tools and methods to increase efficiency)
   Those Allen wrenches work great, but if you have scores of screws to tighten, an electric drill with the appropriate bit will come in very handy.
4. Read the instructions. Visualize in your mind how the final piece will look like. (Use the procedures in place. Understand your final state).
   Don’t skip steps. That could mean rework, unscrewing, unfastening and lots of wasted time and energy. Understand how these steps will lead to the finished product.
5. Keep everything close. (Don’t deviate from your plan)
   Arrange your tools, parts, screws, nuts and bolts close so that you are not wasting time running around to get what you need. Also don’t be in a position where you are searching for things that might have gone under the packaging or containers.
6. Look for ways to improve. (Look for continual improvement opportunities).
   Learn constantly. If you think of a better way to do something, by all means, use that learning.

Granted, some of the things above might be derived from pure common sense, but, as the saying goes, common sense is not always very common. Bringing work home may not be exciting, but bringing ideas from work may not be a bad idea after all!

Do you bring home tips and ideas from work? If so, please share them. We’d love to hear your stories!

One way to set strategy is to use your clout.  As the company’s chief executive and majority shareholder, convince everyone else that the direction you want to take is essential to achieving the company’s objective goals – increasing sales, improving customer satisfaction, and complying with government regulations.  Maybe not the best way, but it’s one way.

Realistically, there are better ways to determine company strategy, and no one way is the best way.  Any time you can take more than one route to arrive at a desirable goal, you need to balance the relative value of projects, using financial measures like ROI, or prioritization schemes like Pareto charts.  This post considers the interactions between decisions, projects, and systems – in real life, few good decisions occur in isolation. Decisions must take into account that everyone in your company depends on everyone else for information and work-in-process.

That’s where process maps come in

Implementing strategy without a process map is like navigating a family road trip without a road map. It usually doesn’t work out. Ask my wife about my driving and navigating from St. Louis, Missouri, to Michigan. Fortunately, we had plenty of food and water in the minivan, and the kids were already in Michigan at summer camp.

Today in the article section, we continue our series on process maps by introducing three types of process maps: High-level, Low-Level, and Swim Lane Process Maps.

Consider that before packing the minivan, I might have consulted a map of the United States. Were I to look at the big picture, I would have seen right away that the eastern shore of Lake Michigan is north and somewhat east of Saint Louis and that it’s faster to drive through Illinois and Indiana to get there than say, through Missouri, Iowa, Wisconsin, and the Milwaukee Ferry. In that sense, the national map is a High-Level Process Map. It shows the major systems (states) and how communication (highways) pass through them.

My wife asks the question, "why do they call this a minivan?"

If you were updating your company’s automation supporting order-to-cash software, you might want to review a high-level picture showing how Purchasing moves a quote to Production, and Production sends finished goods to Shipping. A High-Level Process Map would show you right away that Shipping has to receive materials before shipping Finished Goods to customers. Knowledge of sequence and dependencies depicted in a High-Level Process Map helps you determine what happens first.

Back on the road

Once we were in Wisconsin, the big US map showed that Milwaukee was to the right (er, east) of Dodgeville. Easy enough. Once we got to Milwaukee we searched for the ferry. There, the big USA map was not much help, so I pulled out the more detailed (or low-level) Wisconsin state map.  On it, I looked for the Milwaukee area insert.  Furthermore, had I stopped to ask directions, someone might have advised staying in the southbound lanes of Carferry Drive rather than end up back on Lake Parkway heading toward Chicago.

That is the kind of insight you can glean about your business from a Low-Level Process Map. Credit checks and accounts-receivables reviews happen before granting credit to customers, so you might want to work on the estimating and accounting software packages before redoing the invoicing systems.

Now my family and I are all safely home.  I’m contemplating our next road trip, and I have become a big fan of Swim Lane Maps. Like a Low-Level Process Map, Swim Lane Maps show the functions that must occur for a successful journey, like “Drive” and “Navigate” (and maybe “Keep your hands off your sister’s iPod”).  Swim Lane Maps show responsibility for each activity and when various parties need to accept information from (or hand off to) one another.

All this, and they're still happy campers, on the eastern shore of Lake Michigan.

Had I consulted a Swim Lane Map before repacking the family in the minivan, it would have been visually apparent that I was responsible for driving, not navigating, and I was supposed to accept information somewhere north of Chicago.

One can come to appreciate that maps get all the information out in the open. And should things go in the wrong direction, you can point to the map. Interested parties can discuss the map calmly, with no need to comment on anyone’s innate abilities such as hearing or sense of direction.

At this point, you might see how Swim Lane Maps could come in handy in your company, when you consider how systems will support people who provide information and work-in-process to each other, and vice versa.  For example, the sales department is supposed to hand off orders to the credit department which, in turn, performs the credit check based on management criteria.  The IT department should want to know about responsibilities, dependencies, and hand-offs — which a Swim Lane Map can convey easily and concisely – before they begin to plan, develop, debug, and roll out software.

So, check out this week’s installment about High-Level, Low-Level and Swim Lane process maps.  An introduction to the series appeared last week in a blog post of ours and in the article site where we posed the question, ‘What is a Process Map?’

I trust that next week, you will find your way back here for more types of maps.

Process improvement is occurring at many organizations throughout the world.  Yet people constantly ask about how to get started.  How do you get your organization moving in a direction of continuous improvement?

First off, you have to have Management Commitment.  The obvious question, then, is how does top management show commitment to change and improvement? The answer is about inspirational leadership, it is about communication.  To be an inspirational leader, one needs to be a great communicator.  Management commitment takes both leadership and communication.

Second, it takes SMART Objectives.  Planning by management must result in clearly defined objectives that the organization can work towards.

Third, in order to achieve the SMART objectives, the organization will require operational Action Plans with accountability and responsibility for each action.  This means the Who-What-When is spelled out for proper execution.

Fourth, you will need a User Focus.  Defined customer requirements, an understanding of the voice-of-the-customer — your customer, and a method of constantly integrating your customer’s requirements into your processes.

Fifth, there has to be Profound Knowledge, which results in your ability to anticipate results.  Really understanding your customer, your markets, and your processes lead you to anticipating what your customer needs next.  How do you reach this state?

Sixth, you will need to learn and implement Management By Fact, which will lead you to profound knowledge.  Collect the facts from data, use the data to derive information, and obtain knowledge about your customers, markets and processes.

Seventh, in order to manage by fact, you will need the facts in the form of Real-Time Data.  Your processes will require increased visibility and transparency.  Real time data is needed to build a strong competitive advantage.  The longer the delay in getting data, the slower your reaction time is and the less competitive you become.

Eighth, with so much going on you will need a good Change Management System that can document and control all of these changes.  This will build on your system of management by fact and lead you to greater profound knowledge.

Ninth, Execution Audits, internal audits or process audits.  Either way you will require a system of monitoring to ensure that the system is working, that your change management system is effective, and that you are in fact achieving progress towards your SMART objectives.

Tenth, still unsure of where to start?  Then Continuous Learning is needed to build your knowledge management.  No improvement will take place unless knowledge is identified, acquired, shared, and used.  Training, learning and practice are crucial to build competence.

What are these Performance Improvement Drivers?

1. Management Commitment (Leadership & Communication)
2. SMART Objectives (Goals)
3. Action Plans (Accountability, Who-What-When)
4. User Focus (Customer, Employee, Supplier)
5. Profound Knowledge (Anticipates Results)
6. Management By Fact (Data, Information Knowledge))
7. Real-Time Data (Visibility)
8. Change Management System (Documentation & Control)
9. Execution Audits (Monitoring)
10. Continuous Learning (Improvement)

Recently we have been interviewing our customers to find out how they are using the policy and procedure manuals.  Many are using them as templates for policies and procedures as intended, but some are using them to infer the processes from which the policies and procedures were derived.

Many customers say they are creating process maps as aids to implement and update their processes, and to capture and communicate the information they have found.  Some customers say they are looking to Bizmanualz for the best practices of many organizations.

Like any process map, rendered maps shown above help communicate information to others and are tailored for communication. Rendered maps represent the information in familiar, more realistic graphics and can represent elements of a process in physical proximity or time.

Clearly, our customers are telling us that there is more we can do for them.  We could provide more process maps that can be customized for specific purposes.  We believe that providing a set of coherent process maps would help you get your job done better, faster and cheaper.  If your job is to implement and improve processes, and support processes with training, procedures and other communications, then clearly process maps can help you.

We’re talking to more customers right now to solidify our understanding. So if you had a conversation with us recently, and agreed to a follow-up call, you will probably hear from us again soon.  If you haven’t already heard from us, but would like to weigh in on this issue, please get in touch.  Just comment at the end of this post, or contact us online and let us know what you’re thinking.

Defining Process Maps

The trouble is that “process map” means different things to different people. You will find everything from strange spaghetti diagrams of everything going on in an organization, to abstract block diagrams that tell you little about what’s actually going on in a company.

As a step in creating our library of policies and procedures, we have created many process maps. We have had to, to make sure that everything works together.  In fact, we have standardized on seven types of maps, each type with a specific purpose, its pros and cons, and its role during implementation.

As a step toward providing you with useful, best-practice process maps, we plan to share our mapping methodology with you, our readers, friends, and customers.  We have written a white paper defining seven types of process maps and will publish it in installments (read part I).  The paper provides an example of each type of map, its best uses, and the positives and negatives of each one.

So stay tuned over the next several weeks as we fine-tune an approach to process mapping that will work for the majority of our customers, and share what we learn with you here.

The Information Technology Infrastructure Library (ITIL) is becoming an international standard for describing the best practices for IT Service Management.  Just like with ISO 9000, the standard evolved out of efforts by the UK government during the 1980′s to model successful organizations and their IT service management approach.  Version 3 was released in 2007 and takes a more circular or complete cycle approach than its predecessors, just as ISO 9000 has evolved into a more dynamic, process-based approach.  The two have much in common and can be used side-by-side.

The core disciplines of ITIL V2 used to focus on “what” Service Support and Service Delivery should be done.  Ten processes tightly defined ITIL V2 around some of the main operational elements of running IT services.

 The Ten Original ITIL V2 Processes:

1. Finance Management
2. Availability Management
3. Capacity Management
4. IT Service Continuity Management
5. Service Level Management
6. Change Management
7. Service Asset & Configuration Management
8. Release & Deployment Management
9. Incident Management
10. Problem Management

ITIL V3 Processes expanded the original ten processes into 27 processes organized into five core areas or books: Service Strategy, Service Design, Service Transition, Service Operations, and Continual Service Improvement Processes.  The intent is to explain “how” more than just the “what” based approach of V2. 

1. Service Strategy
   1. Service Portfolio Management
   2. Demand Management
   3. Finance Management (V2)
2. Service Design
   1. Availability Management (V2)
   2. Capacity Management (V2)
   3. IT Service Continuity Management (V2)
   4. Service Level Management (V2)
   5. Information Security Management
   6. Supplier Management
   7. Service Catalog Management
3. Service Transition
   1. Change Management (V2)
   2. Service Asset & Configuration Management (V2)
   3. Knowledge Management
   4. Release & Deployment Management (V2)
   5. Service Validation & Testing
4. Service Operations
   – Functions
   1. Service Desk Management
   2. Technical Management
   3. IT Operations Management
   4. Applications Management
      – Processes
   5. Event Management
   6. Incident Management (V2)
   7. Problem Management (V2)
   8. Request Fulfillment
   9. Access Management
5. Continual Service Improvement Processes
   1. CSI Service Level Management
   2. Service Measurement & Reporting
   3. CSI Improvement Process

ITIL V3 processes have expanded to cover the complete service management lifecycle and are closely aligned with ISO 20000.  Similar to ITIL but integrating the process-based approach common to ISO standards, ISO 20000 is an international standard that describes best practices for IT service management.  ISO 20000 was published in December, 2005, and replaced ISO 15000.

While ITIL provides guidance to service companies, those companies cannot be ITIL-accredited; individuals may be certified as ITIL practitioners.  Companies may be accredited to ISO 20000, however, and while ISO 20000 does not require companies to use ITIL, company accreditation to the ISO standard is made far easier by implementing ITIL beforehand.

The thing about IT systems is that people have to use them. No matter the on-time, on budget performance of the development, the success of your install will be judged on how you move the needle on the metrics that the system was designed to affect. And to move the needle, users have to use your system effectively.

Getting users to use it takes two things. It takes buy-in, which you no doubt facilitated by involving users early to define their requirements. It was at this stage that you investigated and communicated to users the underlying core process that would be automated by your system. You got on the same page with users at the very beginning that the right work is in fact being automated.

Getting people to use your system requires their buy-in from the start, and bite-sized, context-sensitive training and communications after your system launches. Copyright, Bizmanualz, Inc. © 2009.

The second thing that you need to get users to use the system is communications and training, aka: a roll-out. Roll-out is when you remind users that they defined the requirements in the first place, and at that time you all agreed that by automating the core process, their lives would be easier, and the enterprise would benefit through improved metrics.

Remember, your million-dollar technology investment is at risk if people don’t use it. Your IT development was certainly serious. So your roll-out needs to be serious too, not a Band-Aid slapped on to try and recover.

Deployment: Who needs to know what, and when do they need to know it?

A serious roll-out reflects your understanding of how your system will actually be used. Remember those use-cases? OK, dig those up and consult them when planning your training and communications.

Develop a training plan that is consistent with the use-cases that you captured when you gathered user requirements. Copyright, Bizmanualz, Inc. © 2009.

Develop training from the point of view of your users. Think about the context in which the information will be used. That is, deploy training in formats appropriate for the setting. For example, field-delivery workers will have their hands full, literally. They may not have the time to attend live training for extended periods. Instead, break up the information into bit-size nuggets, and deliver it digitally to their mobile devices in visual or video format.

Deliver training in bit-sized nuggets as it is needed. Use formats that work in the situation. Make it as easy as possible or people to know what they need to know to use your system effectively. Copyright, Bizmanualz, Inc. © 2009.

Close the loop by updating standards, policies and procedures.

Remember how, early on, you and your users got on the same page about the core processes that you would be affecting? Ultimately, you need to close the loop. You need to update company standards, policies and procedures to reflect any changes that you have made in the work flow, compliance or standard practices.

It’s too easy to focus on the project management metrics and forget that ultimately it’s the impact of automation that matters. Do users remember that they set the requirements? Do they know how to use the system to do their job? Are people making the connection of improving metrics back to the technology causing it? Take a good look at your roll-out plans, and make sure that you get payback for your technology investments.

PR: wait… I: wait… L: wait… LD: wait… I: wait… wait… Rank: wait… Traffic: wait… Price: wait… C: wait…

Problems manifest themselves in many ways but to truly solve a problem you must make sure you have found the root cause.  A good place to start is by understanding the top ten root causes to most business problems you will encounter.

The number one root cause management usually jumps to is (1) Poor Training.  Yes, training is a root cause to some problems but, it is not the sole reason why things go wrong.  Many times employees may not be (2) following procedures.  Unused procedures are not effective.  Why aren’t they following procedures?  Perhaps because they are (3) poorly written procedures.  If a procedure is unclear it is a lot harder to follow.  Even well-written procedures are not perfect.

(4) Poor employee placement can result in mistakes too.  Your employee may not be the right person for the job.  Better screening, job descriptions, or testing can help you to place the right person in the right job.  Yet even with the right person you could have (5) poor methods that have been outdated but not changed, or at least the changes were poorly communicated.

We are half way through the list of the top ten root causes.  Next, (6) poor inspection causes mistakes.  This is really about attention to detail, understanding your product, and caring for the output that you are passing on to the next step in the process.  Pay attention and take the time to inspect your product and you will reduce a very common root cause.

Related to inspection is (7) poor maintenance.  If you neglect your equipment then it is more likely to malfunction.  Lean thinking focuses on preventive maintenance, which means regularly maintaining your equipment to ensure it does not break down in the middle of something important you are doing.  Of course it could be breaking down because of a (8) poor engineering or design in the first place.  Focus on designing in quality by doing it right the first time and you will avoid this root cause.

Are you selecting (9) poor inputs or materials because the price is right?  If so, then perhaps your management has (10) poor rewards or incentives in place?  I am not talking about just money.  Recognition of good quality or pointing out poor quality performance may be all that is needed to send the message that quality is important and thus preventing many of these root causes in the first place.

Top Ten Root Causes of Business Problems

1. Poor training – Mistakes are made due to the lack of proper training.
2. Poor procedure usage- Mistakes are made because procedures are not or cannot be followed.
3. Poorly written procedures – Mistakes are made due to unclear procedures.
4. Poor employee placement- Mistakes are made because the employee is not physically capable of executing the procedure and is in the wrong role or position.
5. Poor methods- Mistakes are made because employees are following outdated methods that used to produce quality product but, conditions have changed and the method has not been updated.
6. Poor inspection- Mistakes are made because inspections are either not performed at the right time or with the right scrutiny, or not performed at all.
7. Poor maintenance- Mistakes are made because the equipment is not sustained or preserved, either by neglect (see 2) or ignorance (see 1).
8. Poor engineering or design- Mistakes are made because of a bad initial design.
9. Poor inputs or materials- Mistakes are made because of poor quality raw materials.
10. Poor rewards or incentives- Mistakes are made because of either a lack of emphasis on good quality performance or the failure to reject poor quality performance.

People don’t make mistakes. Systems make mistakes.  If you have a system for training, well-written procedures, following-up on procedure usage (i.e. internal auditing, metrics, rewards), developing competent employees for the role they are placed in, updating and innovating methods, attention to detail, disciplined maintenance, quality designs, constant rewards and incentives for good work, and supplier validations, then you would have eliminated 80% of all of your failures or mistakes.  The last 20% is left to the individual’s ability to operate the system you have just created.  What do we call such a system?  A Quality Management System!