This week I started a major KM
project. I can't talk much about it yet, but it involves both natural
(ecological) and social systems, so it is imbued
with complexity. There's a tendency to jump right into information
architecture, taxonomy, and community of practice building, and the
project's requirements document assumes that how to do all these things
would be self-evident to an experienced KM practitioner. If only it
were that simple.
But even if I were to ask the internal and external 'customers' of my
client what their information and networking and related technology
needs were, they wouldn't know. It's the nature of complex environments that understanding of the 'problem' and potential solutions co-emerge from the exploration, discovery and learning process.
Most of my writings on complexity to date have been about big-issue, save-the-world problems and the use of Open Space and other collaborative processes to invite and bring together the right people to address them collectively. But what happens if it's your individual
job to deal with a complex situation, and you don't have the resources
to convene large groups of people passionate about understanding the
issues and surfacing ways of coping with them? Is there a scaled-down
methodology that can be applied in such situations?
I think there is. Here's the methodology I'm trying out on the new project:
- Identify the Customer:
Determine who the internal and external 'customers' are -- how they can
reasonably be segmented. There are usually multiple customer groups,
often with conflicting interests. Don't expect the interests or needs
of management and of front-line staff to be congruent. Expect that this
will create problems of irreconcilable needs, expectations and
priorities for you.
- Research & Observe: Study the status quo to understand what is really happening, what the real
processes and workarounds are, not the idealized conception described
in the procedure manuals or suggested by the corporate website. Don't
judge them -- understand them. In the above diagram, this is called sensing and suspending.
- Converse:
Have lots of iterative discussions with different customer segments to
clarify your understanding of what is happening and why. Question and
challenge suppositions and implausible explanations. Between steps 2
& 3, an understanding of unmet needs and 'problems' (things that
one or more customer segments are having difficulty with or are worried
about) will start to emerge.
- Define and Articulate the Needs & 'Problems':
Some of the emergent needs and problems will be personal, and you may
be able to solve many of these just by observing, conversing, and
providing the individual with your ideas and the benefit of your
experience. Other needs and problems will be shared and require (and
justify) a more substantial 'solution' process, and these can be ranked
by the customers' assessment of their severity and urgency. Feed these
back to the customers to make sure you understood. Steps 3 and 4 are pattern-recognition and inferential activities, synthesis rather than analysis.
- Imagine Ways of Addressing These Needs and Problems: Now you have reached the real
starting point: Not preconceptions and solutions looking for problems,
but qualified, articulated needs and problems with no obvious solutions
(if the solutions were obvious, someone would have done them already).
Find the creative minds in the organization (or outside it, if
necessary) and brainstorm, imagine possible ways of addressing these
needs and problems. A lot of the problems and needs you identified in
step 4 are likely to be competency and capacity-building needs -- avoid
the temptation to jump to the conclusion that 'awareness' and
'training' are the right solutions to such problems and needs (things
happen for a reason, and if people aren't aware and aren't motivated to
learn themselves, it's unlikely that your awareness and training
solutions will get traction). In the above diagram, this step is the letting come phase.
- Create a Future State Vision If Your Imagined Solutions Were Implemented:
Tell a compelling story of how things could/would happen if the
solutions you imagined in step 5 were implemented. Then deconstruct how
to get there and use it to budget the money, time and resources needed
to implement them. The story becomes your business case: present it
with the request for needed resources.In the above diagram, this is the envisioning phase.
- Experiment and Prototype:
Start small -- your imagined solutions will never be perfect, and
small-scale experiments and prototypes will allow you to refine the
solution before spending all the resources on an imperfect solution.
These experiments and prototypes will also allow pilot users to embrace
and champion and virally market them to the rest of the organization,
since in the piloting process they become a 'part of the solution', and
make it theirs.
- Scale Up: Expand the pilot to all users who share the need or share and appreciate the problem. Make adoption voluntary. Let the users own and collectively self-manage the solution. Once it's realized, set it free.
So suppose you follow this methodology and discover (a) there are a lot
of fledgling, disorganized, self-identified communities of practice and
communities of interest in (and extending beyond) the organization that
need some enabling knowledge-sharing, context-building, sense-making
and connectivity technology and processes to self-organize and
function, and (b) there are a set of significant risks, 'costs of not
knowing', that could be addressed through a prevention and
early-warning detection program.
Project (a) may be hard to sell to management because there's nothing
in it for them, and they may be concerned about corporate-sponsored
networks operating under their radar. But this need not be an expensive
application, and you may have so many zealots clamouring for it by
virtue of following the first six steps above that management won't
have the heart to say no.
Project (b) may be hard to sell to any of the customer groups because,
while the consequences of not knowing are huge, the likelihood of these
risks actually arising may be low (it always happens to 'the other
guy'). But since Enron, Katrina and other low-probability,
high-consequence risks have come true, management has a much greater
appetite for risk prevention and detection applications. The big
challenge is more likely getting the people in the field to comply with
the monitoring and reporting requirements of the new system.
What you may also discover with this methodology is that a lot of
existing 'legacy' applications, processes, programs, websites and tools
actually don't address any
important needs or problems. Some of these would have been 'pet'
projects of someone with resources or decision-making authority. Some
would be simple-to-implement solutions (like automation of previously
manual processes, or broadcasting of information to everyone in the
organization) that were instituted as 'quick wins' even though they
weren't really needed or valued. These 'solutions in search of a
problem' are major components of many large organizations' processes
and infrastructure. The secret (as long as you don't run afoul of the
person whose 'pet' project they were) is to get authority to get rid of
these unnecessary, low value processes, programs, apps, websites and
tools and see if anyone even notices their disappearance. Such
'cleanup' activities are thankless, but they can eliminate a lot of
clutter and wasted maintenance time, and allow more valuable solutions
to get more visibility and achieve more traction.
The largest challenge that this methodology presents is that it takes
longer than 'presupposed problem and imposed solution' approaches. It's
not precise, often defies quantitative 'success measures', and rarely
has a discrete 'project end'. To those brought up with traditional
management methodologies, this could be very troubling. Part of your
job is therefore likely to be bringing management up to speed on
complex, adaptive systems and the failure of prescriptive, fast-track,
top-down, centrally-managed, discrete-start-and-end projects and
programs to deal with them effectively.
I believe that in ten years understanding complexity will be essential
learning for all business students and managers, and this task will be
much easier. In the meantime, we pioneers will have both the excitement
and the frustration of being ahead of the curve.
I'll keep you informed on how it's working on my new project. |
MADE IN CANADA
trust your
instincts 
