We have to think of standard work in the context that it was
invented. Standard work is SPECIFICALLY there (according to Ohno) to give
a basis for Kaizen. His rules are clear:
1.
Standard work is a document of THE WAY THINGS ARE
CURRENTLY DONE, not the way they should be done.
2.
Standard work is there only to enable Kaizen – not to tell
people how to do their job. You can’t do data-based improvement
until you have a baseline measurement of the current way of doing things.
Period, end of discussion. Standard work is a baseline for improvement,
it is NOT a description of how to do the job, even if it appears to be.
Here is how I see standard work being abused:
1.
“We need documents so that anyone can do any job.”
Nonsense. The idea of
standard work is NOT to make people fungible. It is to encourage people
to do Kaizen. If it does not accomplish this purpose, it is being abused.
2.
“We need to use the same standard across the company.”
Why on earth? Where
ever did that idea come from? What good are standard processes across the
company? All they do is squelch Kaizen, so they clearly are not a good thing.
Well, I can be flexible on
that – standards across the company can make a good baseline for local
organizations to start Kaizen efforts. Some standards will have to span
organizations. But as a matter of course – “because everyone
knows that a standard should be used across the whole company” – I
don’t think that’s an adequate reason for corporate standards. I
had a saying in my department when we were doing company-wide plant information
systems: “Find out what people in the plants don’t care
about, and make that a standard. It will make their life easier. Find out what
they do care about, and let them make their own choices on those things.”
I’m beginning to think that the idea of company-wide standards
appears when you have monolithic organizational structures. 3M, Gore,
Semler, and – I now discover – the Pennsylvania Railroad, all
had/have small independent business units rather than a single monolithic
business unit. The Pennsylvania Railroad was universally recognized as the best
run railroad of the 1800’s – by far. It had 3 separate
divisions, each with less than 2000 miles of track to manage. The
person who designed this ‘decentralized’ structure for the Pennsylvania
railroad theorized that it might have higher management costs, but it would
result in better management decisions because managers were closer to and more involved
in the business. He was absolutely correct.
In such ‘decentralized’ organizations, there is no
concept of standard processes across the company except in a very few
centralized areas. In 3M, the centralized areas were finance, personnel, purchasing,
and capital equipment and facilities construction. Everything else was
local. Although processes were more or less similar across the company (good
practices spread because people moved around), there was not much interest in
standard processes across the company. Certainly there was not a standard
process (while I was there) in areas of core competence such as product
commercialization. And yet, all divisions had more or less similar
product commercialization processes, with differences stemming from the type of
business or product.
In monolithic/centralized organizations, I often see standard
processes used as a substitute for good management decisions, because managers
are too far from the work/customers. I’m not sure there is a fix
for this if decentralization is not an option. But when used in that way,
standard work has exactly the OPPOSITE effect from what Ohno – for example
– intended.
Mary Poppendieck
952-934-7998
www@...
Author of: Lean Software Development & Implementing Lean
Software Development
From:
leandevelopment@yahoogroups.com [mailto:leandevelopment@yahoogroups.com] On
Behalf Of Alfvin, Peter
Sent: Saturday, October 13, 2007 11:31 PM
To: leandevelopment@yahoogroups.com
Subject: RE: [leandevelopment] Using Deming to Define Standard Work in
Programming
Alan,
I, too, have been reading the Scholtes book and have had
remarkably similar reactions, starting with appreciation for Mary for pointing
the book out to us. I couldn't agree more with your blog and think
"Standard Work" more than anything is the key concept from Lean that
tends to be underappreciated in some agile adoptions (e.g. mistakenly
ignored or cast aside in the context of "empirical process
control"). I was also struck by Scholtes' discussion of
"extraordinary people" and how organizations need to understand what
makes them extraordinary. I cannot prove it of course, but suspect that
many "extraordinary people" are in fact "ordinary people"
(at least in the statistical sense) using very good work processes and tools.
In fact, I'd go so far as to say that once you understand the
Deming/Toyota notion of "standard work" (i.e. the current "best
practice" subject to continuous improvement), that CMMI suddenly becomes
not only acceptable but attractive, for it brings a completeness and discipline
to process (standard work) management. The problem with CMM in my
mind was not that
it was based on the concept of defined/standard processes, but that it resulted
in so many organizations attempting to institutionalize ineffective (e.g.
waterfall-based, stagnant) processes. Unfortunately, rather than
recognizing and addressing the essentially dysfunctional nature of the
processes, it's not uncommon for employees in these organizations, in their
frustration, to subsequently reject defined process (and process discipline)
altogether, with predictably bad results.
Pete
From: leandevelopment@yahoogroups.com
[mailto:leandevelopment@yahoogroups.com] On Behalf Of Alan Shalloway
Sent: Wednesday, August 29, 2007 9:20 PM
To: leandevelopment@yahoogroups.com
Subject: [leandevelopment] Using Deming to Define Standard Work in
Programming
Mary, thanks so much for referencing Scholte's The Leader's Handbook.
I've been reading it and it has been wonderful. It's given me some great
ideas on how to better explain some things in terms of Deming's Systems
thinking.
I just wrote a blog Using
Deming to Define Standard Work in Programming that may be of interest
to the developer types who lurk on this user group.
Alan Shalloway
CEO, Net Objectives