Tim Walker
Cut the Fat, Not The Muscle from Your Lean Environment
Many organizations embrace lean methodology (also known simply as “lean”), a systemic approach to streamlining production, to make operations more efficient. Done correctly, lean methodology not only solves problems, but also provides value to customers better and simpler than before.
Unfortunately, organizations sometimes go overboard with the lean principle of eliminating waste, cutting what’s actually needed to do the job right — paradoxically reducing effectiveness.
Organizations can become overzealous about cutting if they lose sight of lean’s real purpose. The key misunderstanding, Mark Graban, a healthcare consultant who wrote the book on Lean Hospitals, says, is thinking that lean is “all about cutting waste,” which can trigger what he calls “errors of enthusiasm.”
That can lead to cutting for the sake of cutting, Dan Markovitz, a Lean Enterprise Institute faculty member and author of A Factory of One, says. He compares it to losing weight: “The logical conclusion of ‘losing weight,’” he says, “is anorexia — which doesn’t make you fit.” You would end up thin but lacking in strength, flexibility, and stamina. The same applies to organizations that cut rather than prune.
How can you avoid the problem of cutting too deeply in a critical part of your operations? And what are some prime areas where cutting should be done with caution?
Four Areas Where Cutting Too Much Will Come Back to Haunt You
These areas are worth special attention as you apply lean principles. With these, it is best to be slow to cut and even more clear about the value being produced.
1. Project or Product Requirement Documentation
If you don’t have a clear, detailed blueprint for a building, how can your contractor build to your specifications? The same logic applies to defining the requirements for a new product or project. You must answer these questions so clearly that they cannot be misunderstood:
- What are we trying to achieve?
- Which features are essential, and which are merely nice to have?
- When must it be delivered?
Any lack of clarity means confusion and rework, which defeats the purpose of lean production.
Markovitz thinks that people often rebel against documentation because they’re forced to use burdensome, outdated forms. “The reason they’re onerous is that someone in the dawn of time had a template,” he says. It’s probably not the right template anymore, but people keep requiring it, because that’s how it’s always been done. It’s tempting to scrap the whole thing.
To counter that — and make requirements gathering better, faster, and simpler — you should think of who needs the requirements documentation (in this case, the people who will have to execute the project or build the product) and what it will help them do (the value to be created). Retain all the detail that’s actually needed…but cut the rest.
2. QA Documentation
In many software companies, there is an ongoing struggle between developers and quality assurance (QA) staff. Maybe it’s inevitable, given that QA’s job is to find fault with what developers build.
From a lean perspective, each group is the other’s customer. QA receives code from developers to test its performance against specifications, while devs receive feedback from QAs to make the code better. Both groups should value 1) improving the application, and 2) having the information needed to do their jobs. Ideally, the specs to be tested should be spelled out in the requirements phase, giving everyone a clear sense of what the devs will deliver and how the QAs will put it through its paces.
Consider what happens if you diminish effective exchange of information between the teams at any point along the way: QAs might test for the wrong things for lack of clear specs. Or maybe devs can’t replicate an error, because QA feedback omitted some critical variable, for instance, about the exact sequence of actions taken. Be wary of anything that reduces the information flow between these two groups; if their communication is inefficient, invest in finding a better way.
Tracking it all can be tedious, but it’s hardly pointless. As Markovitz says, “If the QA person has to walk over four times to clarify stuff, we’ve screwed up.”
3. Compliance Documentation
Speaking of tedious…anyone who’s worked in a regulated industry, or even the accounting department of a publicly traded company, has lots of reasons to hate compliance paperwork. Yet any corners cut here could torpedo your organization.
Markovitz advises going back to core lean principles: Understand what customers need, and then make it better, faster, and simpler for them to get it. And when it comes to compliance, the ultimate customer is the regulator. Because of this, he says, the driving question could be, “How could we make compliance information easier to access?”
Make sure the team knows what the compliance requirement actually is, so they can create a lean way to produce it. This saves you from either omitting important information or creating an ever-more complex process nobody understands the purpose of, other than, “We think we need it.”
Whether you’re serving internal customers such as compliance officers, or external customers such as auditors and regulators, you can focus on processes that produce documentation faster and make it easier to spot problems.
4. Security and Safety, Physical or Virtual
It’s the same whether you’re talking to a Chief Information Security Officer or a foreman in a factory: There’s a balance to be struck, of course, because there is no point in making a computer network or factory so secure that it can no longer communicate with the outside world. It’s a case of making sure that you really are implementing what’s required to be safe and stopping exactly there.
Technology companies undergo detailed audits for SSAE 16 and other certifications to uncover problems with their internal controls. Building inspectors use highly detailed checklists to determine if a new building is up to code, and OSHA inspectors do the same to ensure that factories are safe places to work.
In all of these cases, savvy companies prepare in detail to pass muster because gaps in safety or security damage the business on many levels, whether or not an external audit is imminent. It’s true that the trigger for reviewing your security posture might be an examiner conducting the test, but the larger value created is a safe, efficient organization that is well prepared to deal with risks.
Lean is really about tailoring processes that are appropriate for your operational needs. So be careful how and where you cut, and make sure that cutting isn’t a disconnected activity pursued for its own sake.
What about your experience? Where would you advise caution about cutting too deep?
(182)
