Several of my Knowledge Management colleagues have pointed me to George Siemens' site Knowing Knowledge,
and his upcoming self-published book of the same book (to be made
available as free pdf's as well). Much of what George says really
resonates with my KM experience. His approach appreciates that many of
the systems that KM is applied to are complex ones, and do not lend
themselves to hierarchical, top-down, 'designed' and centralized
solutions.
The four 'stages' to his approach are:
- Analysis and validation of existing organizational structures and activities
- Ecology and network design and creation
- Adaptive learning and knowledge cycles to meet developing needs of organizations
- System review (a "meta-analysis") and strengthening to ensure an ongoing spiral of increased competence.
This approach is an evolutionary, iterative one rather than an imposed
one. It responds to needs as they emerge rather than pre-supposing what
they are. It demands a deep knowledge of the current state (which
requires going out and talking to and observing people on the front
lines to see what is really happening in their use of information and
technology, and appreciating what they need and how they learn). It is
a continuous process rather than a disjoint series of projects and
'releases'. It is focused on developing competence and capacity, rather
than just increasing the volume of information flows. For all of these
reasons it is superior to the methodologies that have been Standard
Operating Procedure in KM for more than a decade.
The illustration above from Siemens' site exemplifies this approach's
adaptability. It is cyclical, two-way, and accommodates the needs of
both managers and front-line staff. Here's how Siemens' explains it:
Change pressures arise from
different sectors of a system. At times pressure is mandated from the
top of a hierarchy; other times it forms from participants at a
grass-roots level. Some changes are absorbed by the organization
without significant impact on, or alterations of, existing methods. In
other cases, change takes root. It then causes the formation of new
methods within the organization.
Initially these methods will be informal, as those aspects of the
organization nearest to the change begin to adapt. Overtime, the
methods significantly impact the organization, resulting in the
creation of new structures and new spaces (an alignment to the nature
of change). These structures and spaces then create new
affordances—enabling the organization to change and adapt. The
new affordances then create a new cycle of change pressures.
This, and not the way described in the corporate policy manual, is the way organizational change actually occurs. Change is a consensual
process: If changes (e.g. the use of a new process or website) are
mandated by management but don't 'make sense' to those who actually
have to effect the change, those people will find ways to not change, and will find workarounds that are effective in spite of
the nonsensical mandates of management. Only when there is a consensus
that change is valuable will it "take root". The four change enablers
in the graphic above actually operate almost like a pendulum: The
demand for change (usually from customers, sometimes from management,
sometimes from front-line workers' learning and adaptation)
precipitates 'affordances' (possibilities, ideas, alternatives and
potentials) which, in turn, if they can achieve consensual traction,
precipitate structural, systems, and infrastructure change within the
organization, which, in turn, finally produce new methods and processes
-- different ways of doing things in the organization.
Those new methods and processes reciprocally create evolutionary
structural, systems and infrastructure changes to accommodate them, and
these 'institutionalized' changes reciprocally create new 'affordances'
(possibilities), and the realization of the opportunity (i.e. the
exciting possibility in the eyes of customers, workers and management)
raised by these 'affordances' reciprocally create new pressure to
change. Through several iterations (swings of the pendulum) all four
elements converge on a new stasis, until new change pressures restart
the change process.
In this article,
Siemens elaborates further on how the traditional 'presupposed problem
and imposed solution' approach to KM 'simply' does not work in complex
environments, where problems and appropriate solutions constantly
emerge and co-evolve. Here are some extracts:
Changes are still being
interpreted through existing beliefs of how we should structure our
organizations, and what it means to know and learn. When people first
encounter distributed tools, the first attempt at implementation
involves “forcing” decentralized processes into centralized
models. We then end up with LMS for learning, learning object
repositories to manage our content, corporate lock-downs on instant
messages, and district-wide bans on social networking tools...The
desire for centralization is strong. These organizations want learners
to access their sites for
content/interaction/knowledge. Learners, on the other hand, already
have their personal spaces (myspace, facebook, aggregators). They
don’t want to go to someone else’s program/site to experience content. They want your content in their space...
The desire to control and manage communities (the notion that control
equates to better prospect of achieving intended outcomes was, as
usual, evident) struck me as being a bit at odds with how things need
to happen for online spaces to prosper...When we try and create
Communities of Practice (CoPs) online, we take the same approach
– come to our community. I think that’s the wrong approach. The community should come to the user.
Most individuals have started to create a scattered identity and
presence. I have pieces of my thoughts scattered across numerous
articles, website, podcasts, and presentations. I don’t really
want to join a CoP. I want the connection values of communities to be
available to me in my own online space and presence...
We have a mindset of “knowing before application”. We feel
that new problems must be tamed by our previous experience. When we
encounter a challenge, we visit our database of known solutions with
the objective of applying a template solution on the problem. I find
many organizations are not comfortable suspending judgment. The moment
a problem takes an initial known shape, the solutions begin to flow...
Applying solutions to problems is an order-creating attempt.
This is, I think, a very natural process. We all engage in it..Perhaps,
in a learning sense, part of the concern here is our views that order
doesn’t exist unless we enforce it.... It’s difficult to
accept that order and meaning can emerge on its own (think chaos
theory)...
Instead of trying to force these tools into organizational structures,
let them exist for a while. See what happens. Don’t decide the
entire solution in advance. See the process as more of a dance than a
structured enactment of a solution. React as the environment adjusts.
Allow feedback to shape the final product. Let the process bring its
own lessons before applying structured approaches. Perhaps a learning
experience exists in the knowledge/information that emerges...Relaxing
on control is vital for sustained knowledge growth, sharing, and
dissemination.
The views that we must know before we can do, and that problems require
solutions, can be limiting in certain instances (especially instances
of high complexity or uncertainty – see Snowden’s knowledge
ontology). Knowing often arises in the process of doing. Solutions are
often contained within the problems themselves (not external, templated
responses). And problems always morph as we begin to work on them.
You can appreciate that such an approach is enough to give both
management and 'project leaders' apoplexy. Both groups want change
initiatives to be controlled, and to have a clear beginning and end, a
prescribed measure of 'successful' implementation, and closure when
that measure is (or is not) achieved. Siemens' approach is open-ended,
continuous, and evolutionary. That's why the evolution of the solution
(and the simultaneous co-evolution of understanding of the 'problem')
must be self-managed by the
stakeholder group -- they know enough and care enough to steward it
through the lengthy and continuous evolutionary, emergent process (a
process that is inefficient but very effective), long after the 'design team' and the 'IT implementation team' have lost patience with the changes.
For KM 'solutions' to be self-manageable, they must be very simple and intuitive (or, as Einstein put it, "as simple as possible but no simpler".
So suppose you're a Knowledge Director and you want to help the people in your organization use knowledge more effectively. What do you do? Here's a few ideas of my own:
- Conduct personal productivity improvement 'cultural
anthropology' observation sessions with users. You'll find out how they
learn, and what they really need, not what they think they need (or management
thinks they need). A lot of what they need will be highly individual,
and you'll probably find it doesn't need a 'solution', just a bit of
demonstration of what already exists that they don't know about, plus
some personal content management coaching. And as you observe more and
more people you'll start to see patterns of unmet collective information and technology needs.
- Then, rather than
designing solutions for these unmet collective needs, create the
simplest possible framework for solutions to these unmet needs to
evolve, empower the group that has indicated they need and care about
the issue to experiment and iteratively change the tool or solution as
their understanding of the need and its possible solutions evolves. It
is possible that rather than stabilizing, the lightweight 'framework
solution' will continue to evolve indefinitely, or the need may
disappear as circumstances change. Only if the
solution stabilizes and there is sufficient critical mass of users,
content and technology to justify it, should the stabilized solution
then be formally re-designed to make it more elegant, user-friendly,
standards-compliant, efficient and powerful.
- Focus on KM initiatives that enable sense-making (making
content more valuable by providing better context), and peer-to-peer
sharing, rather than the archiving and 'broadcast' dissemination of
'available' content. These are the applications that, in complex
environments, users find most valuable. Most users are pretty clever at
getting the content they need, and, as Siemens says, the last thing
they want is to have to go to your site, no matter how elegantly designed, to get it -- they want it accessible to or delivered to their site, space, or hard drive, their way, when they want it. If it's hard to find or access, make it easy for them, and then let them
do it. Otherwise, don't fuss about the format or site architecture of
'raw' information content -- you'll get much further helping them make
sense of it, and helping them send it peer-to-peer, than by creating
elegant, beautifully designed websites to house it.
- Likewise, rather than 'creating' communities of practice and elegant sites and tools to empower them, focus
on peer-to-peer expertise finding and connectivity applications, and,
once people with common interests and imperatives have found each
other, provide them with the simplest and most flexible possible tool
to self-manage that community. And again, only if the tool's evolution stabilizes and
there is sufficient critical mass of users, content and technology to
justify it, should the stabilized solution then be formally re-designed
to make it more elegant, user-friendly, standards-compliant, efficient
and powerful.
I'll be looking forward to the publishing of Knowing Knowledge
(tomorrow) and will be writing further about it once the pdf's are
available.
In the meantime, what do you think of Siemens' idea that KM is all
about a "spiral of increased competence"? And what, beyond the ideas
described above, could organizations do to precipitate such a spiral? |
MADE IN CANADA
trust your
instincts 
