The value of guided failing in knowledge management

-------Follow us at @GeertSWillems on Twitter or www.whiteravensconsulting.com

Creative and passionate people, having a good set of brains do not tend to following other ideas and people without questions.

"yes but"
"my experience says"
"there is a shorter way"
"I used to do this in another way"
"I'd like to do it another way"
"Can't the software really do that?"
"What if"

These remarks are very useful. These are personal remarks. And as a part of change - human change - it's a good idea to have these questions answered.

Last week I went to a company, delivering 2 days of consultancy to check if a certain tool could support their knowledge sharing.

There were a few ways to do this exercise:

One way to prepare this meeting was:
investigating the information model that they already had,
investigating the features of the tool,
downloading it, installing it, testing it.
That way I could propose a solution. Knowing it won't be perfect with the preparation I had.

But I looked to solve the concrete problem which triggered them to hire me, discovered how to solve it but saw that plenty more were coming, and lot's of them I couldn't predict.

So I looked at the information model upfront, at the tool capabilities and I knew that these smart people, who wanting to set-up the environment themselves, so I decided to follow the strategy of guided failing, the day after...

--------------------------------

So I went with a rather blank mind and a very simple strategy: let's sit together, pick a part to implement, and start implementing. The low hanging fruit was to defuse the problem had, and use the momentum to start implementing.

We worked in team for about five hours. I guided them through failures and successes, every idea they were enthusiastic about we implemented, or hit the bounderies of the tool.

And the result after those five hours were phenomenal:
- The most complex part of the information architecture was implemented in the tool
- The people who are using the tool:
    - did the implementation themselves
    - know why the way things is implemented
    - know the bounderies of the tools
    - know why the implementation is done the way it is
    - know all the failed ways of implementations and why



Instead of 2 days, we spent five hours.
And my customer was really happy, and more important, the knowledge of implementing their architecture really was internalised!

Compared with: presenting "this is your solution", this approach really proved his value!

And what's more - for me as a consultant - it was really fun to do!