Developing Lean Processes -- What are the Common Mistakes?

Just this month, Matthew J. Zayko and Eric M. Ethington published about Lean process development entitled The Power of Process: A Story of Innovative Lean Process Development, which explores Lean Process Creation and teaches the specific frames -- the 6CON model -- to look through to properly design any new process while optimizing the value-creating resources. The framing is applicable to create any process that involves people, technology, or equipment—whether the application is in manufacturing, healthcare, services, retail, or other industries.  The result is 30% to 50% improvement in first-time quality, customer lead time, capital efficiency, labor productivity, and floorspace that could add up to millions of dollars saved per year. 

When I spoke with both authors earlier in the month, I asked them: "What are the common mistakes made when developing Lean processes?" Here is their full response:

Although every situation is unique, the three lean process development mistakes we see most often are:

Confusing Tools with Goals -- This is often rooted in not understanding the true purpose of the many Lean tools at one’s disposal, coupled with a poor grasp of the current state of the existing processes.  This results in a patchwork of “Lean stuff” stitched together – a veritable Frankenstein of a process.  First, understand your situation (CONtext) and then apply the right tools at the right time to learn what you need to know.

Losing Sight of Targets -- New projects most likely have a business case.  Done properly, this business case is based on assumptions that have been documented.  These might include a particular margin level, production rates, volumes – and the list goes on.  Likewise, these assumptions are calculated from a variety of other expectations such as cycle times, process uptime, projected yields, and material costs.  Once the money is approved, progress towards some of the high-level metrics is sometimes tracked, but often the more basic expectations that fed the calculations get lost.  Additionally, these assumptions are rarely translated into metrics that make sense to the project teams earlier and earlier in the development process.  End-state targets need to be translated backward to meaningful targets at key points, earlier and earlier, in the development process.  What does a final target of 15% margin look like to someone who is developing early process concepts?

Treating Development as an Event instead of a Process --  It is amazing what a properly selected and inspired team can accomplish.  Just think about the impact a 3-day kaizen event can have.  Yet, the organizations that really excel with lean have figured out how to make improvement part of everyone’s daily work.  The same thinking applies to process development.  It is okay to start your journey to better process development with a great, focused team.  But make certain to capture lessons learned along the way to incorporate into your “process of process development.” 

What do you think of Matt and Eric's perspective on mistakes regarding Lean process development? Have you experienced the same problems in your company during your Lean initiative and process creation? 

For more information about the 6Con Model and Mat and Eric's book, please visit: https://www.thepowerofprocess.solutions/

Strategic Planning -- Why Does it Often Fail?

In August, Sean Ryan published his first book entitled Get in Gear: The Seven Gears that Drive Strategy to Results, which helps business leaders convert business strategy to measurable results. When I spoke with Sean this month, I asked him: “Why do organizations rarely get it right when it comes to achieving the expected results from their strategic planning?” Here is his complete answer:

It’s well documented that 75% to 90% of organizations fall short of achieving the results they expect from their strategies. Sometimes, it really is just a matter of a bad strategy regardless of how well it’s executed. Maybe it’s a bad acquisition. Maybe it’s a poorly thought out effort into new markets or with new products or services. Maybe it’s New Coke! Most of the time, though, it’s a matter of a good plan poorly executed. Execution failures often occur because: 

• the organization doesn’t have the right people in the right roles with the right capabilities to execute, or
• the organization’s architecture (systems, structures, processes, and culture) isn’t aligned to the strategy, or
• the daily efforts of their team members are disconnected from the strategy. 

In Get in Gear: The Seven Gears that Drive Strategy to Results, we outline some of the failure points and how organization’s can better align the seven gears to the results that matter. 

Here’s a really common one: We ask people to outline their top five goals. Then, we ask their leaders to outline what they think the top five goals are. On average, only two out of five match. That means that 60% of the time people are working on the wrong priorities. It’s hard to achieve great results when people are working on the wrong stuff! 

You don’t have to fix all seven gears at once. You can pick the one or two that create the most friction and fix them. You’ll likely get at least somewhat better results. Then, you can work on another to get even better results. 

Over time, individuals and organizations can bring all the gears into much better alignment and achieve dramatically better results for both themselves and the broader organization.

What is your experience with strategic planning? What do you think of Sean's take on the failure points and how to rectify them?

Lean System Management -- Can Structured Systems Unify and Align Quality Practices Throughout an Organization?

It has been argued that that the proven practices of performance excellence and quality cannot be sustained over the long term. A new book by Richard E. Mallory entitled Lean System Management for Leaders: A New Performance Management Toolset postulates that the reason for this failure is that there is no cohesive guidance on the management of groups of people working together toward specific goals. The author believes we currently have only a patchwork of two very specific knowledge areas -- one for process management and one for project management. I asked Richard a series of questions about how his book seeks to rectify this situation. I'm including those along with Richard's very interesting answers here:

Why do you believe that system management is new to management?

System management shows how to create and define a best practice ‘map’ for any or all management systems, and how to identify and define its influencing factors of success.  This allows manager to create an operational best practice map with measurable metrics and indicators of success.  Once that is done, the model itself provides a foundation of a perfect ‘learning organization’ that can review and improve on its practices over each performance cycle.  There is nothing in existing management practice that shows how to provide this kind of structure, evaluation, and learning for the management structure overall. 

Why do you call it a “fundamental” body of knowledge for all managers?

Much of current management literature is focused only on one-to-one interactions with individuals--“supervision“-- or generic group practices like “motivation”, “goal-setting”, “employee engagement”, or “encouraging the heart.”   Another approach puts its focus on generic organizational frameworks that provide a cookbook of advisory or prescriptive tactics under headings like “Baldrige”, “ISO”, or “The House of Lean."   It is a great omission of current management knowledge that there is firm structure for defining, analyzing, standardizing, or implementing best practices for the specific practice areas of individual managers – either for a program office or for specific management functions like governance, strategic planning, budgeting, quality control, and project management.

Isn’t systems management mentioned in a lot of management books?

Yes, many books use the plural word ‘systems’ with the same meaning as an organizational environment.  One business book says that “systems thinking is more of a concept than a tool,” and describes the system as ALL the factors that surround a process.  Another calls systems “a set of inter-related processes.”  Either definition will blind managers to the possibility of documenting and improving a SINGLE area of management practice with specific goals – the real definition of a system.  When systems are looked at one at a time, it is possible to define and map their primary activities and success factors, and this kind of documentation of systems redefines management. 

What is the difference between a process and a system?

A business process uses a specific set of sequential steps, each of which can be defined, to produce a specific output with a definable set of output requirements.  A process is often completed by a designated work team, and is designed to be done the same way with the same sequential steps time after time.  A system is more easily seen as a project, in that it produces a valuable output but will have a production cycle that may not be rigidly sequential, that is more changeable because of intervening factors in each cycle, and that may produce a number of outputs all of which cannot be defined in advance.  A system is less likely to follow a single predictable path and may have to obtain its result using personnel that are not a designated work team. 

Given all those differences, what makes you think that a system can be mapped?

All human knowledge is based on science, which itself is based on observation of repetitive cycles and learning about the factors that drive success in any given cycle.  If you start with the premise that each management system is cyclical and has quantifiable goals, then we can define and predict the principal activity groups (or milestones) that are necessary to achieve those goals. We can also then define the measurable attributes of success in each group.  Using cause and effect analysis, we can further break down the influencing factors (or “causes”) of success, and the metrics or indicators that can be seen when those practices are followed.  Even though the operational best practices of system are not sequential with specific assignable steps, the system map does provide a documented operational plan that can be evaluated and improved.

 

Can you explain the concepts of “native systems” and “design systems” that you refer to in your book?

Often times groups of people develop a habit, understanding, or “culture” about the way things are done around here, and this is the native system.  Like standing in line at the grocery store, people make things work based on assumptions of what is considered fair or right.  The same is true in larger organizations, so the way that we operate a program office, develop a budget, or decide on projects is often a combination of guess work and detective work.  The idea of design system is a deliberate decision of a leadership structure that for critical management outputs, there should be a focused effort to define how it will work best, to let everyone know about that operational plan, to evaluate its operation at the end of each cycle, and to innovate and improve based on learning.  This mirrors the practices recommended by the Framework for performance excellence of the National Quality Award that management systems should have a documented approach and deployment combined with periodic learning and innovation. 

The book title mentions Lean.  Does that mean if follows established process improvement methodology?

System management shows leaders how to achieve superior leadership results by applying a Lean DMAIC (Define, Measure, Analyze, Improve, and Control) structure to leadership systems and program office operations.  It shows leaders how to align and evaluate these systems using a Lean approach, and how to evaluate and score the maturity of management practices through the American Society for Quality System Management Standard (http://asq.org/gov).  It offers analytic skills to eliminate duplication and waste of executive and senior management time, and reduce the wait time and non-value add in dependent processes.

Explain how lean system management provides an agile framework for organizational change.

Lean system management presents a structured framework for defining and controlling organizations, along with a system maturity standard that allows regular measurement of the maturity and capability of defined management systems.  In this way it provides an agile framework for the organization-wide practice of quality (which we will refer to as “Performance Excellence”), and enables the use of a system maturity scorecard, showing the capability and maturity of quality management function throughout the organization.  It also allows and enables an organization-wide scorecard on the practice of quality at the process level, through use of the Process Management Standard (See Measuring Maturity, Quality Progress, Sept. 2016 --

http://asq.org/quality-progress/2016/09/process-capability/measuring-maturity.html).

What do you think of Richard's view of system management? Do you agree with his views on why performance excellence is currently not sustained by many organizations?

What Can Lean Do for the Banking Industry?

The banking industry comprises many accounting, regulatory, process, and management challenges, and because its customer-satisfaction and efficiency rates are ripe for improvement, many feel Lean improvement initiatives can transform these financial institutions. A book published just this month titled Lean for Banks: Improving Quality, Productivity, and Morale in Financial Offices, authored by Bohdan Oppenheim and Marek Felbur,shows how Lean and Six Sigma can significantly improve the efficiency of bank operations.

During a recent conversation with Bohdan Oppenheim, I asked him: "Why should financial organizations choose Lean as a methodology to transform and improve their culture and results?" Here is his complete response: 

Few traditional banks are aware that they have vast reserves of productivity. Typically in such banks, both managers and staff work extremely hard, often overtime. Their intuition tells them that there is no reserves left in the system, and that the system is "as Lean as it can be." The knee-jerk reaction is to blame this frantic pace on an excessive amount of work and a lack of employees. The solution appears to hire more employees, but this often has the opposite effect. With more people hired, the system becomes even more difficult to manage, more convoluted, and less efficient.

Fortunately, an excellent solution exists: Lean Thinking. In Lean, employees transition from fighting crises to increasing both customer satisfaction and bank competitiveness. Work becomes more predictable, stable, and pleasant. It soon becomes truly shocking to both management and staff how much work can be accomplished in the same amount of time and with the same resources, simultaneously improving productivity, quality, cost, work morale, and customer satisfaction.

The effects of Lean can be dramatic: up to doubled productivity in the entire system; process times cut by 50-90%; the number of errors reduced by 50-90%; development time for new bank products reduced by half; approval time cut by 90%; modest capital investments (only training); dramatically better human relations at all levels; and, most importantly, vastly better customer satisfaction and company competitiveness.

When faced with stiff competition, traditional companies brutally cut costs, usually by massive layoffs, head-count reductions, and by overworking the remaining employees and suppliers. Without addressing underlying systemic problems, these cuts simply eliminate needed resources and therefore slow down the operations. This causes more frantic work pace, loss of quality, and decreasing customer satisfaction. When this happens, additional customers and profits are lost, resulting in even more cuts and more layoffs. This spiral of failure can easily lead to collapse.

In contrast, Lean focuses on recovering productivity reserves by waste elimination. This in turn leads to lower costs, higher quality, and increased customer satisfaction. Lower operating costs enable banks to keep the employees on the payroll because they will be needed as customer satisfaction attracts more business. During the Lean deployment period, the employees can address those improvements for which there was never enough time, contributing to better productivity and quality. So, the success spiral occurs without layoffs.

One of the most pervasive myths in banking industry is that higher quality requires higher costs. This may be true in the superficial sense of marble floors in front offices, but is totally wrong in terms of the cost of operations. Lean demonstrates that a high quality of operations is actually the least expensive. In Lean, we avoid the high costs of mistakes, errors, defects, rework, delays, frustrations, and subsequent crises, and focus instead on making operations better and better.

The bank industry seems to be one of the last Lean frontiers, delayed no doubt due to the severe 2007-2011 crisis and subsequent massive layoffs in the industry. However, pioneering banks, listed in the book, are rapidly implementing Lean. 

Do you agree with Bohdan's assessment? In which area do you feel Lean can acutely improve financial institutions and the banking industry?

Process Problems -- Just Five Types?

I recently spoke with Kicab Castaneda-Mendez, who recently published a book titled What's Your Problem? Identifying and Solving the Five Types of Process Problems, about root cause analysis and his definitions of process problems. I asked him specifically: "How is reducing process problems to just five types a breakthrough in process improvement? What are the key benefits?" Here is his complete response:

Typically, root cause analysis is taught by explaining a variety of tools that requires users to gain considerable experience before being able to apply them correctly in the proper settings. To provide practice, tools are often taught without context which results in users not knowing when to apply them. A third common condition is when problem solving is taught as a sequence of expansions and contractions, specifically in finding root causes and solutions.

By reducing all process problems to just five types based on the cause, we eliminate the need to search for what the cause is. Since these specific causes can be addressed in time-proven ways, the search for solutions is also reduced. The result is that we can significantly simply process problem methodologies to a three-step procedure:

• Identify the type of problem,
• Find the root cause (where it occurs -- we know what it is), and
• Address the root cause.

We benefit in several key areas: vastly simplified teaching, learning, applying, and mentoring. Because virtually every adult has solved these types of problems using the proven techniques, we can easily create lessons that build on this knowledge without burdensome language. With training time reduced by as much 50% to 80%, students can go through multiple cycles of practice on the three-step procedure on all problem types versus at most one cycle of other methodologies on one problem.

Isn’t that what process improvement is all about: increasing quality while reducing costs and time?

What do you think Kicab's methodology? Do you think all process problems can be reduced to just five types?

Perceived Quality and Market Share

Last week, I had a phone conversation with Robert Fantina, co-author of the recently released book, Your Customers' Perception of Quality: What It Means to Your Bottom Line and How to Control It, about customers' buying habits and what they consider value-adds. Many attendees at conferences I attend often state that their companies' products and services are of very high quality, yet they struggle to maintain market share. Shouldn't the quality speak for itself? I posed this question to Robert, and here is a summary of his answer:

Unfortunately, many companies do all the right things in terms of quality, including reducing their defects to near zero, eliminating call waiting times, etc., and still struggle to hold onto their customers. Repeatedly, this appears to be because their customers do not perceive them as delivering quality.

High quality in products and services is vital but insufficient; despite high quality, customers may still perceive quality to be inferior. What is causing that perception?

The answers to that question are many and complex. Unfortunately, it appears that a variety of concerns experienced by customers translate in their minds into ‘poor quality.’ For example:

• A customer that buys a product though a third-party distributor and has problems with that distributor, may view the quality of the product as poor.


• A customer who loves his/her product, but then struggles to find some information on a difficult-to-navigate website, may begin to view the quality of that product as poor.


• The company that orders 1,000 widgets, and receives them all individually wrapped, and must discard/recycle all that wrapping, may say that quality is poor.

While it is clear that none of these issues in any way reflects the actual quality of the product, they can influence customers' perception of quality. And if their perception of quality is poor, the actual high-quality of the product is meaningless.

Do any of you suffer from this situation? How did you recover? Have you experienced an instance in which the delivery of a product or service affected its popularity? How did you discover this?