The Future As Seen By Me In 2010

Well looky here, things one has scanned in eh. (ignore the photo, that's some guy that made some accounting software, not sure what became of him ;) MIKE RIVERSDALE is fuming. The expensive headphones he bought in Sydney three weeks ago have just died. His first reaction is not to randomly spill expletives into his coffee, but to use his iPhone to vent his frustration to his Twitter con- tacts, under the moniker Miramar Mike. "I will also put, 'What should I do?' It's a conversation. I'm reaching out to the people following me." The council predicts hand-held digital devices such as smartphones will rule the world in 2040. They already rule the life of Mr Riversdale, whose company WaveAdept helps businesses adapt - their computing sys- tems to allow staff to work from anywhere - and with anyone. In order of fre- equency, he uses his iPhone to tweet (1136 followers; 8363 tweets since joining), e-mail, make phone calls and use online services, such as checki

So, you have a Wiki ... so what? A story of real work life in NZ

Flickr: Serious business womanWhilst 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:
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:
  1. easy to use (more)
  2. easy(ish) to install
  3. 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
But, if you see a problem that would perfectly fit the wiki you will never have to "sell the idea". If it solves the problem PLUS is easy to use, easy(ish) to install and free to licence ... you're laughing.

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:

  1. Do you know what the business problem is?
  2. Have you attempted potential non-technology solutions?
  3. Do you always refer back to the business reason when challenged about the technology?

Further reading:
And one, like 'John', for the Public Servants out there:

* Enterprise 2.0 is the application of the Web 2.0 technology and mindset within an organisation. - more ...


Popular articles

The Future As Seen By Me In 2010

Knowing good info from bad - how do we?

How To Facilitate A Barcamp/Unconference

The 3 C’s – Communication, Consultation and Collaboration

21 days of Wiki adoption (Wiki Patterns)