An exciting announcement over at Grow Your Wiki – Stewart Mader is leaving Atlassian (although he will continue to work part time on special projects) to start a new venture focusing on Wiki Consulting.  I’ve had the pleasure of meeting Stewart both on-line and in the real world, and I think this is a great move for him and his customers.

I’d particularly recommend his concept of BarnRaising workshops – check out his services for more details.  BarnRaising workshops solve the problem of having an empty wiki when you first launch, which no-one will use.  The wiki is actually built during the BarnRaising workshop so that when people go back to their desks, they have something of value they can use together.

Congratulations Stewart – and good luck!

Was talking to a client today about the culture they wanted around their wiki.

“The job’s not done until it’s in the wiki” was the instant reply – great idea!

Should I be scared that clients are better at this sometimes than me?!

PBwiki held another webinar a few weeks ago about a case study with Deloitte Digital.  Deloitte Digital is a startup of about 20 people within the Deloitte group (165,000 people).

Peter Williams from Deloitte Digital talked about two different wikis with two very different uses.

The first was a externally hosted wiki to allow a group of individuals within Deloitte Digital to collaboratively build a business case rather than sending documents over email.

They key benefit was that it removed the need for one person to have to fight with Word’s track changes and comments feature to compile, edit and bring the final document together.  Collaboration was much faster, and the business case was produced more quickly and with less friction than if it had been done over email.

The second wiki was more of a general ‘intranet’ style wiki.  It was kicked off by a few wiki ‘zealots’ (I prefer “Champions”!) and was found to have more and more uses as it grew.  Whereas it started being used as a knowledge repository and a place to find information it has now effectively become a CRM system as well!

Let’s look at how these wikis fit into our principles of wiki adoption:

• Targeted.  The business case wiki was very targeted.  Not only that, it was used by a small group of people, initially 3 which grew eventually to 11.  This made a great point, that you don’t need to belong to a large group or large organisation to benefit from wikis.  Deloitte saw value in just 3!  The ‘general’ wiki did not appear to be so targeted, Peter didn’t go into too much detail as to the initial purpose of that wiki, but it would be interesting to find out how it started and whether it had an initial focus, or it was always conceived as something more general
• Sponsorship.  Peter came up with a great term for dealing with a problem with sponsorship “CIO bypass“.  Peter is fortunate enough to be in a senior position so he is able to bring some sponsorship to the table, but part of the benefit of an externally hosted wiki for the business case was that he could get it up and running quickly without needing sign-off from the CIO.  An official ‘knoweldge management collaboration strategy’ is still 18 months in the making!
• Marketing/Communications.  As with RMC Vanguard - the fact that important information was on the wikis drove people to use it.  If the information to do your job was on the wiki, you had to use it!
• Champions.  Peter is a clear champion, and the strength of his personality was key in overcoming issues around sponsorship.
• Support.  Peter spent time showing people how the wiki could be used, and how it made their jobs easier.
• Accessible.  A key reason for using a hosted wiki for the business case was that it could be accessed (securely) by those outside the Deloitte firewall whose contributions were needed
• Enforcement.  The business case wiki demanded that people use the wiki.  To be involved, people weren’t going to tolerate the pain of wading through 15 different copies of the same document in order to try and find “the final version”.
• Get rid of the old.  For the business case wiki, there was no ‘old’ to get rid of.  Peter didn’t go into detail as to whether old sources of information were removed once they were placed on the general wiki.  They certainly seemed to have stopped using a dedicated CRM application and had moved to the wiki for this.
• Measure.  Peter didn’t really spend much time worrying about measuring.  “People vote with their mouse” he said, and as long as he could see a stream of page views and page updates he was happy.

The biggest key to Peter’s success here is the strength of personality of the champion.  Going with an externally hosted option and by-passing the CIO has obviously been successful, but you need confidence that it is not going to be a career-ending move depending on the political situation within your organisation!

Deloitte certainly followed the “try it at low cost and build examples from there” business case rather than an all-encompassing high level one, not only because it was easier but going down the “official” route would have taken over 18 months where he had an immediate need.

Certainly a very engaging and thought-provoking webinar/case study!

Great post by Steward Mader on second wave adoption of wikis.

“This demonstrates that no matter how much effort is put into designing a better product or tool, an equal-or greater-amount of effort must be dedicated to showing people how to use it, and guiding the necessary change in thinking that they must undergo in order to embrace it.

Just because you understand that it (whatever it is – wiki, blog, new milk jug, etc.) is better, doesn’t mean that the benefits are obvious to everyone. Therefore, the second wave (i.e. the non early adopters) are some of the most important people in the adoption process for anything new, because they help you hone and refine your message so that it appeals to a mainstream audience.”

“Fear of failure” is often seen as an inhibitor in life, both professionally and personally.  I was with a client the other day who certainly had a fear of failure around Enterprise 2.0.  They wanted to get it absolutely right, and had spent up to a year getting input from various stakeholders – essentially doing a traditional requirements gathering exercise.  They then prioritised the list, and had come to a loose agreement on the features of phase 1, due for release in August 2009!

During the workshop, we gradually got them to realise that they didn’t need to get it right all in one go.  With Enterprise 2.0, you can quickly start a wiki or a blog for a small department.  If it doesn’t work, you haven’t failed, you’ve learned how not to do it.  So you try again, until you get it right.  Then as usage grows, you can start to implement profiles so that people from different departments can find each other, again, learning as you go.

This is great for Enterprise 2.0 champions as you don’t have to convince management to sign off on a big project as you would for an SAP implementation.  Finance love it because it’s cheap, and if it doesn’t work you haven’t wasted much time or money.  When you want to eventually roll out corporately and get asked the pesky ROI question, you will have real world examples from within your own company as to what the payback is.

So with Enterprise 2.0, failure really is an option!

I attended a webinar last night hosted by PBwiki titled “Growing in a down market with PBwiki“. All in all it was very interesting. Here are the main points:

The webinar went very smoothly. This is not to be underestimated, I’ve lost count of the number of webinars where there are problems with sound/video but this was great. Slides/screenshare and question submission was handled by GoToMeeting - and I was very happy to find out I could stream the audio via Ustream rather than have to pay for a 60 minute international call to the States. Video was snappy, and audio was crystal clear, made the experience much more enjoyable.

The case study was RMC Vanguard, a mortgage company in the States which is experiencing the slowdown of the US mortgage market. The benefits they obtained from the wiki were as follows:

• Time saving – wiki pages with frequently asked questions, links to important websites (with usernames and passwords where appropriate) were all included on the wiki
• Productivity – with four underwriters serving fifty loan officers, and a habit of loan officers to keep asking a question until they got the answer they wanted, having a place where underwriters could post information rather than having it asked of them constantly made both the loan officers and the underwriters vastly more productive, which resulted in more time spent with clients which ended up with increased sales
• Retention – there is a strong attrition rate in the loan officer role. Many role officers worked from home and struggled to remember the details to access internal systems once they returned to their home office, and felt isolated. How-to’s on the wiki increased their productivity when they first joined, which meant they earned more, which meant they were happier, which meant they didn’t leave
• Improved customer experience – in a down market you need to retain customers. By providing loan officers with a single point of reference where they could obtain information in a fast changing market meant that they could answer clients’ and potential clients’ questions on the phone there and then. This led to a significantly improved customer experience and increased customer retention, which is essential in a down market.

What was really interesting is that this successful wiki implementation hit nearly all of our principles of wiki adoption:

• Targeted – there were clear reasons for the wiki – internet passwords, How-To’s for working from home and market information. There were also clear audiences who would use it slightly differently, underwriters (generally content contributors) and loan officers (generally content seekers). The motivations of each were addressed differently – for the underwriters posting wiki content stopped them being asked the same questions several times a day. For the Loan Officers using the wiki as a first point of call allowed them to provide an improved customer experience and therefore sell more.
• Sponsorship – the wiki manager worked for the President of the company. Interestingly, he commented that during a ‘down’ period was actually a good time to introduce new technology, as people actually had some time to get used to it!
• Marketing/communcations – a lot of company communications were pushed out on the wiki. A catchphrase developed in the office when people asked “where is…?” with the response “it’s on the wiki!”
• Champions – there was a clear champion for the wiki who spent a great deal of time educating and working with users to ensure that the adoption was successful
• Support – a lot of support was provided. Effort went into ensuring that templates were available so that people were not presented with a blank page when creating new content. Effort was put into ensuring the wiki was searchable so that people could find what they needed quickly. The wiki champion spent time one-on-one with staff to ensure they knew how to use it
• Accessible – the wiki could be accessed by those who worked from home, which was key to driving adoption with the loan officers
• Enforcement – people started to say “it’s on the wiki” when asked a question rather than providing the answer
• Get rid of the old – the wiki champion slowly started to take away the old sources of information. After one week of information being posted into the wiki and one on one training showing the users how to find it, it was removed from its original source
• Measure – this is the one principle not followed. Any measurement was word of mouth and anecdotal. Given adoption was so high, however, I can see why this was not a priority.

When asked what the number one benefit that provided growth in a down market, the strong response was that it was the improved customer experience. RMC Vanguard won best customer experience award for mortgage providers in the US – and the wiki is seen to be key to this, and allowing them to cope with the downturn in the US mortgage market.

Many thanks to both PBwiki and RMC Vanguard - it was a great webinar!

Was watching a Stephen Fry programme last night about the Gutenberg printing press. What struck me was the similar language he used to describe the barriers and effect the printing press had compared to how we describe blogs and wikis. There were three main points of similarity:

• The invention of the printing press democratised ownership of information. The power was no longer held by the scribes who uniquely owned the means of production. In the same way, today’s media no longer owns the means of production or the content. Bloggers take up authoritative positions once held by news anchors. BBC News actively courts phone camera images of people who are at the scene before their news crew.
• The scale and pace of change was unbelievably quick. According to the programme, in 50 years over 20 million books were published from a standing start of 0. Some probably had a readership of 1, whereas others (such as the Bible) had a fundamental effect on the culture of the time. Similarly, there has been a massive proliferation of blogs in the last 5 years, many with a readership of one. Yet the popular ones rise to the top and the insignificant fade away
• There was a lot of fear about this revolution in information ownership. The Church, in particular, feared the end of their monopoly on interpretation of the Bible. Yet others recognised that if there was a widely available, universally consistent text (as opposed to messages transmitted verbally which were error prone, and even the scribes making copies were subject to error) this could allow a consistent understanding of faith. In the same way, some organisations fear the new world – Blockbuster, for example, seems fixated on a retail strategy whilst NetFlix, AppleTV, and even iPlayer and BT Vision clearly show the way of the future in on demand.

Could this change the world in the same manner as the printing press? Probably not on the same scale, it seems more of an evolution rathern than revolution, but the similarities were stunning.

Speaking of iPlayer, those within the UK can watch the programme here.

Social software/Web 2.0 tools such as blogs/wikis/instant messaging can be a great way to manage the exceptions to your business processes. Here’s why…

In a previous life, I was an SOA Evangelist for IBM’s WebSphere integration suite. A large amount of IT spend in the early 2000s went on systems like this one to integrate processes, both internally and with suppliers and customers. The idea was one of cost reduction, reduce the cost of doing business by reducing the time it took to add a customer to a vendor list from 3 days to minutes. The ROI cases were strong and compelling, and many customers managed to get ahead of the market through early adoption.

Now, however, such integration capabilities are more commonplace. Most business processes have been automated to the point where there is not a lot of cost left to be squeezed. Further, (and this is something that bugged me at the time) the vast majority of ‘real’ working practices don’t actually follow the process. The process becomes more of a guideline than a set of rules – exceptions to the process are the norm. Once you have an exception (payment terms are 30 days, but they’re a really important client so we won’t send them a nasty letter until 60 days) – the ROI breaks down as humans have to get involved again. Also, because the ROI cost case relies on people following the process barriers are often put in the way of breaking it, making it even more costly to “do the right thing”, be innovative, and follow an exception.

I was trying to find some stats on how much impact exceptions have on business processes. I am convinced somewhere I found something about 80% of processes resulting in an exception at some point. Vitria are so concerned about exceptions in business processes they’ve created a product for it and claim 50% of process related costs are down to exceptions.

Vitria (and others – I’m not picking on Vitria, they just happened to come high up on Google for “Business Process Exceptions!” offer exception management, but it sounds like another process. To quote from their site:

“Vitria’s Exception Manager is a purpose-built application that provides a systematic approach to resolve exceptions across your enterprise. Exception Manager classifies incoming exceptions, automatically resolves problems, guides resolutions with context-sensitive workflow when human involvement is still required, restarts the normal process flow, and provides full visibility and audit trails across the entire exception resolution lifecycle. “

So what happens when there’s an exception during the classification process. Or an exception during automatic problem resolution? The point is that Business Process Management vendors try to solve the exception problem with what they’re good at, a process. Where Web 2.0 can help here is by providing a tool that fits the problem at hand. What you really need when an exception arises is to communicate with the person who can fix the problem or authorise the exception. The problem is, traditionally, it’s hard to get hold of this person or even know who the right person is! That’s where enterprise social networking, blogs, wikis and especially instant messaging can become vital tools in resolving exceptions whereas email is not that helpful at all. This is why instant messaging is fantastic for large organisations during quarter end – the conversations are all around exceptions to the process – the key is to get the order in the books in a legal manner. We work with one of the world’s largest IT vendors who told us that the accepted downtime for instant messaging during quarter end is measured in seconds, whereas email is hours. Tools such as social networking can also help you find the right person in a time constrained situation, especially if your ‘usual suspect’ in finance or HR isn’t around and you need to find someone similar with the same skills quickly.

The aim of a lot of social software tools is they are based around tacit knowledge. Business processes, however, are all about explicit knowledge. Social software is the yin to business process yang. Exception management definitely falls into the ‘tacit’ space, however, which is why the explicit, systematic approaches to exception resolution fail. The exception is an exception precisely because a systematic approach does not work in this instance, and it is down to employee initiative and innovation to find a solution.

Looks like we’ve found another ROI for Web 2.0 – reducing the cost of business process exceptions which can be up to 50% of the cost of a process.

Just some final thoughts around wiki ROI and to pull together some conversations that have been happening off-blog.

Luis was kind enough to get in touch and shed some light on some of my assumptions. Yes, he is internally facing but evidently does have some contact with customers – but mainly uses IM, Facebook or Twitter to communicate rather than email! I personally find it interesting that Facebook starts to become a one-to-one business communication channel as opposed to something like LinkedIn!

Ross Mayfield from SocialText was kind enough to link and point out that he sees a 30% reduction in email volume (as opposed to my guestimate of 25%) amongst his customers when they adopt wikis instead of email.

Andrea over at Rewarding Dialogue commented that in order to fully understand the net value of Luis’s exercise we need to understand how much time Luis is spending on alternative communication tools. I addressed this to a degree in my follow-on post on Wiki cost savings vs revenue growth and hope to talk further with Luis to get more details on this (watch this space!) but would like to add some thoughts here:

• Even if a large amount of time is spent on alternative forms of communication – Web 2.0 activity such as wiki edits and blog posts tend to be driven by the author’s schedule. Email has a tendency to be driven by the sender’s schedule (how many times have you seen someone answer a Blackberry email in a meeting, or worse, at dinner!) So moving the ‘ownership’ of the activity to the sender will have an increase in productivity anyway
• I mentioned that I found Luis’s initial email volume (30-45 per day) somewhat low. Luis points out to me that this is because he has been an advocate of social computing over email for over 8 years! So he was already reaping the benefits of this working pattern compared to the rest of us who may get hundreds of emails per day, and this experiment has been taking it to an extreme.

Luis also pointed me to a post on the Wikinomics blog which uses this picture courtesy of Chris Rasmussen at US National Geospatial Intelligence Agency to sum up the efficiency argument in a devastatingly effective way.

However, there is another area of ROI which I think we will always struggle to quantify. How do you factor in those moments of serendipity, where three people via their posts to a wiki realise there is a new way of doing things, a new product, a new channel, a new business partner which could fundamentally change the future of an organisation? You can put KPIs in to measure these things (such as % of revenue from new products, % of projects initiated by ideas from outside the organisation, % of products sold direct vs referrals) but making the ROI case for initial investment is difficult because these tools do not guarantee success or new innovative ideas, rather they increase the chances of it happening.

The way I believe the ROI case should be made is on low, modest claims amongst a small focused group of people. Wikis are extremely cheap to deploy, especially on a trial basis. You need to identify this group carefully and get the behaviour/culture right (that’s where people like me come in!) So wikis can be deployed on the ‘reduce email’ argument, but where they will really prove their worth is those moments where people come together and ideas form in a way that would not have been possible previously.

So the efficiency/cost saving ROI argument might be what gets wikis (and Web 2.0/Social Media) in the door on a pilot. What will make them scale within an Enterprise, however, will be the success stories about how they fostered innovation and revenue growth.

There’s a really interesting article on CIO.com with Ross Mayfield, the co-founder of Socialtext. In it, he talks about how wikis can end ‘Reply-All’ email threads.

Luis Suarez of IBM has taken it a step further, and on 15th February gave up on work related email. The idea would be that he would refuse to respond or initiate email communication and would instead communicate via social networking tools such as those provided internally by IBM. If you read a little closer, he doesn’t completely give up on email, and recognises that for certain private conversations where sensitive information is exchanged, email is still a must. I see nothing wrong with this exception – no-one ever said email was fundamentally bad, just that it wasn’t always used for the right purpose. Also, I am guessing that Luis is internally facing, or that this applies to internal email only. I can’t really see a brand sales rep at IBM stopping using email to communicate with customers (although am happy to be proved wrong!)

Another interesting point is that he claims to receive, on a busy day, 30-45 emails. I personally think this is somewhat on the low side, I was always suspicious of people who claimed to go away for 5 days and come back to 2,000 unread emails (average of 400 per day), but I have certainly gone through periods of my life where 100 (on a busy day) was not unusual.

However, the results are still interesting, even if we take the case study as a low-volume email user who communicates mainly internally. It appears as if people took the hint and stopped sending Luis email. The results were most dramatic at the beginning, where the volume dropped from 35/day (175 per week) to 45 in the first week. The drop off has continued, but at a slower pace as shown here: