Replying to LO31063 --
Chris, great questions. Great axioms. Here is my experience.
All of us know in my company that there is a hierarchy, and that there
is "the process" by which work gets done. We also understand that the
process can be viewed as several interdependent subprocesses. We also
understand that there are numerous exceptions to "the process."
80-20 is the name of the game. 80% flow through the normal process,
20% actually take 80% of the time and energy, and don't flow through
the normal process.
People involved in "the process" would like very much to codify the
subprocesses that are used in the numerous exceptions. Senior
management does not want to codify those subprocesses on the grounds
that a) they are unpredictable and non-repeatable, b) codification
will eventually require a process team focused on that exception
process, and that is not how we want to invest scarce resources, and
c) dignifying exception processes by codification is actually a
mistake, even though we all know they happen and will continue to
happen. The fact that they happen is not a reason to make them easy
and efficient to happen. Actually, making exceptions difficult,
expensive, and fraught with risk keeps the exceptions from becoming
too common. But we all know we cannot eliminate the exceptions
either. They will always exist.
So, to attempt to respond to your questions in a very limited case, in
my company the subdisciplines have made the costs and risks abundantly
clear, and senior management has said we would rather accept the risks
than codify processes that, while they will never go away, should also
never be made easy. Actually, sr mgmt understands the costs and
risks. They are not all that big in the grand scheme, and the
opportunity is worth the risks. Finally, sr mgmt does care that we not
invest in standardizing expensive exception processes. That is not
where limited resources should be put.
Is this at all helpful? I would love to hear any responses.
Rol
>I would like to list a few axioms (as I see them - tell me if you
>disagree) and then a question
--"Rol Fessenden" <rol@fessenden.net>
Learning-org -- Hosted by Rick Karash <Richard@Karash.com> Public Dialog on Learning Organizations -- <http://www.learning-org.com>
"Learning-org" and the format of our message identifiers (LO1234, etc.) are trademarks of Richard Karash.