So, you have a Wiki ... so what? A story of real work life in NZ
Whilst the 21 days of Wiki adoption (Wiki Patterns) is an excellent set of techniques for growing your adoption of a wiki it doesn't cover the stage before the wiki is installed.
There are those out there that start from the following premise:
In fact that is an all too common first thought for a lot of software.
Because the common arsenal of Enterprise 2.0* software (blogs, wikis and the like) have mostly been derived from the consumer world, and even more specifically from the open source world, there is the added problem that they are:
Why is this a problem? Surely this is all good and stop whining about usable software Mike!!!
Wellllll, true ... but it's not about software. In fact it's not about technology at all.
If you start off with the mindset of the tool (in this case a wiki) and then search around for a problem to solve then you're going to have a difficult road ahead. Why?
Story time from NZ
A friend of mine (let's call him John) works for a major NZ governmental agency and has spent some time introducing a wiki to his team to solve a defined and specific business problem. The introduction of the wiki, however, is the end point in a series of attempted solutions to the problem - some software related, some not.
Point one - he knew what the problem was
The team could clearly articulate the issues and they had a vision of how it could be better. The business was in control of the whole process and not the technology or the technologists (generally your local IT Department).
Point two - he did not assume technology would solve his problems
John did not limit his attempts at solving the problem to just software (let alone specifically a wiki). He consciously asked, "Can software solve this problem?" which is a great question to ask. Another would be, "Without software, how could we solve this problem?" Sometimes the answer is, "We can't, we need technology" but the answer may also lie in removing barriers to work, people getting off their butts and talking etc etc.
During his ad-hoc investigation of software he had a clear idea of the business solution which, in his case, was that an "executive summary" will be produced quicker and the underlying resources available for both reference and sharing across the team and other projects. With this business success in mind he was able to see that a wiki would work for them - in this case software would solve all his problems (*ahem*)
Point three - always refer back to the business reason for the technology
And then he was off into introducing, educating and growing the Wiki during which he experienced a lot of the common barriers such as IT Department reticence, team wariness and management fear but was able to overcome them by constantly referring back to the original (and still valid) business problem that he was trying to solve.
Now John's issue is ensuring that the wiki does not grow too quickly away from solving the business problem as he curbs the enthusiasm of his management that want to "use the tool" for everything (again, back to that initial focus on the software and not the business problems to be solved). I'm sure that the wiki will grow to solve more and more problems in ways that they cannot know right now but John's insistence that it solves at least one business problem first is a fine stance to take.
It's funny, I look at the three points above and I can hear my wife (who doesn't live within the corporate world) saying to me, "Well duh! Isn't that just common-sense?!?" Yes, it is, but we all forget our ways sometimes when the bright shiny light of new technology shines into our eyes.
And so, in a nutshell - have a clear reason for your Wiki BEFORE you think about getting a Wiki
If you answer yes to the three questions you've started a wiki project well:
Further reading:
* Enterprise 2.0 is the application of the Web 2.0 technology and mindset within an organisation. - more ...
There are those out there that start from the following premise:
We have (can get) a wiki ... I wonder how we can use it!?
In fact that is an all too common first thought for a lot of software.
Because the common arsenal of Enterprise 2.0* software (blogs, wikis and the like) have mostly been derived from the consumer world, and even more specifically from the open source world, there is the added problem that they are:
- easy to use (more)
- easy(ish) to install
- free to licence
Why is this a problem? Surely this is all good and stop whining about usable software Mike!!!
Wellllll, true ... but it's not about software. In fact it's not about technology at all.
If you start off with the mindset of the tool (in this case a wiki) and then search around for a problem to solve then you're going to have a difficult road ahead. Why?
- people may not perceive the problem being important enough
- people don't have any reason to buy into the tool - they didn't ask for it
- people may already have another solution in mind
Story time from NZ
A friend of mine (let's call him John) works for a major NZ governmental agency and has spent some time introducing a wiki to his team to solve a defined and specific business problem. The introduction of the wiki, however, is the end point in a series of attempted solutions to the problem - some software related, some not.
Point one - he knew what the problem was
The team could clearly articulate the issues and they had a vision of how it could be better. The business was in control of the whole process and not the technology or the technologists (generally your local IT Department).
Point two - he did not assume technology would solve his problems
John did not limit his attempts at solving the problem to just software (let alone specifically a wiki). He consciously asked, "Can software solve this problem?" which is a great question to ask. Another would be, "Without software, how could we solve this problem?" Sometimes the answer is, "We can't, we need technology" but the answer may also lie in removing barriers to work, people getting off their butts and talking etc etc.
During his ad-hoc investigation of software he had a clear idea of the business solution which, in his case, was that an "executive summary" will be produced quicker and the underlying resources available for both reference and sharing across the team and other projects. With this business success in mind he was able to see that a wiki would work for them - in this case software would solve all his problems (*ahem*)
Point three - always refer back to the business reason for the technology
And then he was off into introducing, educating and growing the Wiki during which he experienced a lot of the common barriers such as IT Department reticence, team wariness and management fear but was able to overcome them by constantly referring back to the original (and still valid) business problem that he was trying to solve.
Now John's issue is ensuring that the wiki does not grow too quickly away from solving the business problem as he curbs the enthusiasm of his management that want to "use the tool" for everything (again, back to that initial focus on the software and not the business problems to be solved). I'm sure that the wiki will grow to solve more and more problems in ways that they cannot know right now but John's insistence that it solves at least one business problem first is a fine stance to take.
It's funny, I look at the three points above and I can hear my wife (who doesn't live within the corporate world) saying to me, "Well duh! Isn't that just common-sense?!?" Yes, it is, but we all forget our ways sometimes when the bright shiny light of new technology shines into our eyes.
And so, in a nutshell - have a clear reason for your Wiki BEFORE you think about getting a Wiki
If you answer yes to the three questions you've started a wiki project well:
- Do you know what the business problem is?
- Have you attempted potential non-technology solutions?
- Do you always refer back to the business reason when challenged about the technology?
Further reading:
- Are you one of them or one of the other?
- Enterprise 2.0 - factors to a successful implementation
- 6 fears of a wiki coming into your organisation
- Enterprise 2.0 starter pack
- 3 computer acronyms explained so you can fight the geeks in your IT Department
* Enterprise 2.0 is the application of the Web 2.0 technology and mindset within an organisation. - more ...
Comments
Post a Comment