Allow me to give you a view on standardization. As part of this view, I will give you my background which will give you some insight into why I see things this way. Gone is the moniker of “Lean basher” or being part of a group that takes pleasure in being experts, but not very helpful. I represent only myself and what I have learned.
I started my “organizational improvement” journey back in industrial distribution in the mid-80s. I was influenced by the work of W. Edwards Deming as his message was far different than what I had learned in my MBA program. I made lots of mistakes (and still do) and continue to learn. I do not believe there are experts when I consult, the true experts are those doing the work. I can only offer what I have experienced and learned.
I’ve worked with just about every type of service organization and spent a large bulk of this time working with information technology companies. Upon reflection of these years, most of the work was to standardize and improve processes as coding to a standard process is much easier than coding to large variation.
The more I saw standardization being written into business requirements the more I saw workers and service suffer. Standardized menus to choose from call center workers that don’t reflect the actual demands. In contact centers, I saw the most popular choice of call type being “miscellaneous” or “other” – worthless data that could help no one.
I also saw workers being forced to standardized processes, scripts, rules, procedures that did not fit the questions customers were asking. This caused customers to call back or leave – you can measure the ones that call back, but it can be difficult to measure who left or gave up and will eventually leave.
I have also seen that as I worked with information technology customers’ that making a change to the software became an event. Even small changes had to be vetted and prioritized while workers and customers waited. Governance meetings were held and items would move up and down the list. I knew there was something seriously wrong when a developer after a governance meeting stated, “I could have made that change in 5 minutes and we discussed it for two hours.” The software development cycle (a form of standard work) to build software had become the inhibitor to enabling the work that mattered to workers (end users) and customers. IT had lost its aim – to help users create value for customers.
Side note: Information technology companies have made it much harder than it used to be or needs to be. The answer to budget and time overruns to IT projects was building more bureaucracy with BAs, Testers and PMs. Most of the time the PMs are just asking the developers when they will be done or ticking some other box. The truth is the only role that creates value is the developer. The way software has been split into multiple specialists has created more complexity and waste. Even small changes can take weeks and months. All in the name of process.
Today, when I work with a client I don’t even talk about standardization. I talk about a customer’s interactions and aims, and organizational perspectives, beliefs and assumptions. The first two help you see what the customer sees and that last three help you understand why you designed the work that way. I call it a Model to Unlearn as part of the 95 Method – it is explained in the 95 Method video.
During this exercise, I typically will find where standardization is driving in avoidable demand (demand that customers don’t want to have and service organizations don’t want). If I was talking about 1 or 2% that might be OK, but when you see 25, 50 – 80% you know there is something seriously wrong. The root of the problem is not all standard work, but it is certainly its brothers and sisters . . . scripts, rules, procedures, etc. All these things create barriers between front-line worker and customer. And many were created by management and support areas without worker input.
Instead, what I find works best is smartening up workers. Learn the end-to-end system and the beliefs and assumptions that went into it. Armed with knowledge, understanding and wisdom . . . workers can decide how best to design the work. This is not what I see happening under any moniker (lean, six sigma, TQM, continuous improvement, etc), instead we get the “smart” people from support areas and management to make standardized work to control the worker. Adding additional waste by inspecting them, pressuring compliance and then rewarding or disciplining them – how fun a job is that? The worker I mean.
The key to me is that I don’t even bring up standardized work until the worker says, “It would be nice to have something that helps me do this.” It is natural and unprovoked by outside influence – you won’t have to reward, discipline, inspect or seek compliance because the worker understands the need. The added benefit is increase morale.
Take a look at your organization as your customers see it – our 4-day workshop has been called “an awakening experience.” You will understand the customer view of your organization and take inventory of the assumptions, beliefs and perspectives that drive performance. Tripp Babbitt is a service design architect and organizational futurist. His company helps service organizations understand future trends, culture and customer. The 95 Method designs organizations to improve the comprehensive customer experience while improving culture and management effectiveness. Read his column at Quality Digest and his articles for CallCenterIQ. Reach him on Twitter at www.twitter.com/TriBabbitt or LinkedIn at www.linkedin.com/in/trippbabbitt.
Share This:
If change is to occur, it shouldn’t mean everyone needs to change except management. The new design will simply fall back into the old design without a change in management perspective. This means all the work to get an improved experience for your service is negated by old management perspectives – like Frederick Taylor’s scientific management (from Deming’s Profound Changes).
