I'm a friend and occasional colleague of Nigel's. I've been using Patterns
in 'business process redesign' for the last couple of years. Specifically,
I've been employing pattern abstractions as a way of capturing internal
and 'tacit' knowledge about best practices for software development
management within an organization, and then as a way of documenting these
best practices for reuse and what the OO world calls refactoring.
BUT, (and this reflects what Nonaka and Takeuchi talk about in _The
Knowledge Creating Company_) more importantly, a pattern-based approach
facilitates the continuation of the knowledge creation spiral to the next
level: 'retacitizing' the knowledge that is documented. As these process
Patterns are formalized and communally reworked, they become part of the
organizational culture, a way of representing the right starting point for
a process in short form, almost like icons. This is the reason for the
popularity of Design Patterns in the OO world... a group of designers can
meaningfully discuss whether 'Chain Of Responsibility' applies, or whether
'Observer' really fits the situation at hand. They don't need to come to
an agreement about the basics of good design... it's become woven into the
fabric of their domain. And when patterns (process or design) become the
focus for documenting and applying best practices, you don't need two
years of formally organized Change Management to make things happen. The
culture takes care of it, and constraints become resources (oops, a
Pattern).
The problem with the Pattern papers on Process Improvement that have
emerged so far from the systems community is that they are authored by
people who are developers first, and only secondarily sensitive to issues
and emerging directions in the area of process improvement and redesign.
They tend to reflect less than leading edge ideas about things like change
management for example. They may have been at the mercy of Process
Improvement consultants who have formulas to apply and methodologies to
sell. Even Brad Appleton (whose site was mentioned) and who's
demonstrated some significant insights about process change, tends to
document the conventional when he develops Patterns about process
improvement.
A better place to start thinking about patterns for redesigning processes
and managing process improvement is in the area of OO I mentioned above,
refactoring.
The best starting point I can see for 'process refactoring' is "Lifecycle
and Refactoring Patterns That Support Evolution and Reuse" (Brian Foote
and William Opdyke), Chapter 14 in the Pattern Languages of Program Design
1, and available on the Web at http://laputa.isdn.uiuc.edu/Lifecycle.html.
The paper discuss patterns for reusing and reworking OO software over the
life of the software product, to make it more general and enhance reuse.
The patterns they talk about can be extended to provide a basis for
handling process change. In fact I've just finished 'refactoring' a
process for managing the selection and implementation of package software.
To give a hint of what the paper says, the authors start from Christopher
Alexander, who they quote up front:
"different patterns in different (pattern) languages have underlying
similarities, which suggests that they can be REFORMULATED to make them
more general, and more useable in a variety of cases" (Timeless Way of
Building).
The emphasis on reformulate is theirs. Briefly, they go on to identify
specific patterns that support refactoring in a development lifecycle...
** prototype a first pass design
** expand the initial prototype (quote from Alexander: "what
guarantee is there that this flux.... will not create chaos? It
hinges on the close relationship between the process of creation
and the process of repair")
** consolidate the program to support evolution and reuse with a
bunch of detail patterns that are 'plug-ins' like "use consistent
names"
.... along with a few others that are superficially too technical to
translate easily out of context.
When I read it, this paper seemed to me to be capable of being repurposed
(refactored?) into a more general statement on how to make process
improvement and 'change management' itself into an iterative, incremental
and improvisational process. And this struck me as being more consistent
with the needs of rapidly growing, rapidly changing organizations than the
formal, fussy and lengthy approaches required by industry standard models
such as CMM (the Capability Maturity Model) or the alternatives provided
by process management tool vendors such as LBMS.
Each of these patterns could have a process counterpart. Each process
pattern could be supported by detail patterns and tools (e.g. 'prototype a
first pass process' might emphasize the need to incorporate a risk
identification strategy as a way to start getting high payback efforts).
Now, this approach wasn't what I wanted to do at first, when I started
helping this particular client rework their process and management
framework. I initially proposed a more formal and long term change
management process based on traditional methodology practices, but time
pressures and the rate of growth of the company made that impossible. And
the adoption of a refactoring approach was a personal strategy, not a
formalized corporate one.
For what it's worth, there are other starting points that aren't Pattern
papers as well, such as "An Improvisational Model of Change Management..."
by Orlikowski and Hofman from MIT, available online at
http://ccs.mit.edu/CCSWP191/CCSWP191.html. My favorite paragraph in this
paper is one which implicitly criticizes most of the pattern papers on
process improvement:
>Traditional ways of thinking about technological change have
>their roots in Lewin's three-stage change model of "unfreezing,"
>"change," and "refreezing"... According to this model, the
>organization prepares for change, implements the change, and then
>strives to regain stability as soon as possible. Such a model,
>which treats change as an event to be managed during a specified
>period..., may have been appropriate for organizations that were
>relatively stable, bounded, and whose functionality was
>sufficiently fixed to allow for detailed specification. Today
>however, given more turbulent, flexible, and uncertain
>organizational and environmental conditions, such a model is
>becoming less appropriate....
And then there's the stuff happening at the Santa fe Institute.... etc.
etc.
The bottom line is that while traditional views and approaches to handling
organizational change are questionable at best in meeting the needs of
emerging 'agile', 'responsive' and technology-driven networked
organizations, alternatives are available from non-traditional sources
such as the Patterns community, as well as leading edge institutions such
as MIT and the Santa fe Institute. We just need some folks to cobble them
together.
Anyone interested?
--Paul Evitts <evitts@inforamp.net>
Learning-org -- Hosted by Rick Karash <rkarash@karash.com> Public Dialog on Learning Organizations -- <http://www.learning-org.com>