Steve Dale made a great point about my last post about putting Enterprise 2.0 tools in the flow of existing applications. 

“I don’t disagree with the general thrust of your argument, i.e. keeping the tools you use within the context of the business process. However, the last point you make (…the tools should do the thinking for us as to which communication mechanism to use – they shouldn’t require us to think) is arguably a utopian view and, certainly in my opinion, unlikely to happen. In fact, I was putting a presentation together yesterday for a group of people who we’re trying to encourage to get more involved in an on-line community, and one of my bullets read…”Live with the complexity; technology can’t solve everything”. So for me, I think we should strive to become more like Generation Y and learn how to use the tools in context until it becomes intuitive”

This is another example of the enterprise 2.0 pendulum – there is a balance to be struck between making things as easy as possible, but at the same time asking people to move some way toward “dealing with it”.

I must admit I get more and more frustrated with the “I don’t do computers” (Lucinda from the Apprentice anyone?) excuse that people sometimes come out with.  I’m not asking for everyone to be a geek, but how many of us would accept “I don’t use phones” or “I can’t come and see you because I don’t understand cars”.  There is an acceptance sometimes that it’s ok not to be able to perform the simplest of IT tasks, and sometimes (and only sometimes) the IT-literate need to stop doing things for their colleagues and help them understand how to do things for themselves.

If you enjoyed this post, make sure you subscribe to my RSS feed!

There’s a great article by Dave Pollard about how an edict banning email might look.  In summary it looks like this:

• For simple requests, use instant messaging
• For working on documents use screen sharing
• For FYI – post on e-library
• For surveys/opinion gathering, use survey tool
• For group training, use e-Learning

Whilst I wholeheartedly agree with the sentiment, I think this raises a question about whether or not Enterprise 2.0 tools need to be embedded into the existing workflow of employees.

Someone (apologies, I can’t remember who) told me that the real difference between Generation Y and the rest of the world was not that Gen Y was ‘good’ at technology and everyone else wasn’t, but that Gen Y had an intuitive understanding of which tool was best for any given situation.  If you show a traditional worker how to use a wiki and demonstrate that it is better (in some situations) than email, they will try to use the wiki for everything.  Most knowledge workers require one tool to do their job, they don’t want to have to think about what tool to use to communicate,  they want to communicate in the easiest way possible.

I’ve noticed this in my own behaviour.  If I see something interesting in Facebook I want to tell someone about, I’ll send them a message on Facebook.  If I happen to have Twitter open whilst thinking about contacting a colleague who is on Twitter, I’ll use Twitter to send them a direct message.  If Skype happens to be open as the thought crosses my mind, I’ll use Skype.

It takes a great effort to be contacted over one medium (say email) and reply via another (eg instant message).  It takes you out of your flow.

This is why infamous ‘reply-all’ email chains happen, because a user receives the message in email, they reply in email.

What has to happen is that all the tools mentioned above by Dave need to be in context.  I can live in my email client, if that email client also allows me to instant message / post documents to an on-line library etc. etc.

At Trovus, our email system prompts us if we send an attachment, asking if it is an internal email would it like the system to strip the attachment out, place it in our document library, and embed a link to the document in the email instead.  We can manage our document libraries completely from our email client, there is no real need to use the document library’s web interface if we don’t want to, we don’t have to break our flow.

This is where the next innovation in ‘email’ clients come from, you already start to see it as Microsoft embed OCS instant messaging into Outlook, and IBM Lotus Notes becomes a collaboration platform, which happens to contain email.

In short, the tools should do the thinking for us as to which communication mechanism to use – they shouldn’t require us to think.

If you enjoyed this post, make sure you subscribe to my RSS feed!

When I used to live in the world of SOA – business agility was all the rage.  SOA would allow IT to respond at the speed of business, business rules could be re-worked and implemented in IT processes and systems in matters of weeks not months or years.  Or so we promised.

The problem, is that true business agility lies in being able to handle an exception, as well as re-engineer the process.  The main cultural challenge to this is control.  Businesses put in systems and processes to reduce risk and ensure that everything is predictable and decisions are made according to well laid down principles.

But the world isn’t like that – it can be risky and unpredictable, and, whilst you do need systems and processes, you need to be able to account for the exceptions – which often happen more often than you think.  The irony is, as SOA-type systems handle processes more and more effectively, it means that people have less to do with processes, and therefore get more involved with exceptions.  The more processes get standardised the more costly exceptions become as a percentage of operating expense.  Customer requirements, supply problems, pricing can move incredibly quickly, and an SOA architecture isn’t going to help you when the problem is not knowing who to call.

You need to overcome the cultural barrier of letting your employees think, rather than administering processes.  The more you have invested in ’standardisation’ the more time your employees will spend handling exceptions.  Exceptions have be to embraced as a potential source of innovation rather than frowned upon as the 3 year ERP roll-out should have eliminated them.

From a technology point of view, employees need the social software tools required to resolve exceptions, and to disseminate the tacit knowledge that goes hand in hand with exception handling throughout the enterprise.  You need to be able to quickly find the veteran who knows exactly what to do when a particular supplier drops the ball and you need to bypass standard procurement in order to meet a customer’s expectations.  Once found, the resolution to that exception needs to be captured in a way that it can be found long after the veteran has retired.

I know of mobile phone retailers who have lost sales as recent post code changes (zip codes) have meant the ‘automated’ system failing to reconcile bank addresses with the UK Post Office database.  The sales rep had to cancel the contract because he didn’t know who to call and felt that even if he did they wouldn’t be able to resolve the situation.

I know of software sales teams in large software organisations such as IBM, HP and Microsoft who rely exclusively on one individual who is an expert at the ’special bid’ or discount process (discounting is such a common ‘exception’ in software sales processes I think list price is actually the ‘exception!)

I am not saying that SOA cannot deliver business agility – it can get you half way there by automating processes and integrating systems that previously could not be done, or would not have been cost-effective.  But you’re only half way there if your business process integration strategy isn’t matched with a social software strategy to handle exceptions.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Currently reading Seth Godin’s Meatball Sundae.

In a section – “what does marketing do?” he answers “we close the sale”.

Love to see a sales director’s response to that…

If you enjoyed this post, make sure you subscribe to my RSS feed!

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?!

If you enjoyed this post, make sure you subscribe to my RSS feed!

In my last post, Peter Williams from Deloitte talked about bypassing his CIO to help get Enterprise 2.0 tools (PBwiki in this case) through the door.

I’ve recently been thinking about the different ways to justify Enterprise 2.0, and the most natural to me seems to be one that fits with Peter’s thinking – find a way to do it at very low cost and ask for forgiveness later.

Peter had some great tales to tell about his battles with his CIO, and some analogies/tactics he’s used to get around the problem.

First of all, if your fight with the business is about ROI – your fight with IT is about control.  The CIOs wanting to ‘ban’ social software are the same people who wanted to ban external email and internet access, now seen as critical business tools.

Peter made some great points around this:

• In a meeting / brainstorming, it is natural to stand up, pick up a pen and draw on a whiteboard / flipchart.  What would it be like if you had to go and get three levels of permission before doing this and make a business case for your actions?
• Exploit this technology rather than hide from it.  Facebook, for example, is a free collaboration system, with a high level of adoption.  Yet it is banned!  What Peter has managed to do is to build a Facebook application whereby any job vacancies can be advertised through employees Facebook network.  And there’s an Aus $5,000 reward if the job gets filled via you!  How long would it take and how much would it cost to build and populate such a system from scratch, yet Facebook gives it to you for free!
• Facebook is not under the CIO’s control – that’s the problem.  Ask the people scared of controlling collaboration how they currently control face to face conversations.  Wikis or instant messaging can be moderated, audited, transparent and are logged.  Face to face conversations are none of these – what is the CIO doing to crack down on face to face conversation?

Personally, I can’t wait to try the crack down on face to face conversation line with the next Norman Naysayer I meet!

If you enjoyed this post, make sure you subscribe to my RSS feed!

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!

If you enjoyed this post, make sure you subscribe to my RSS feed!

PBWiki have posted an ROI calculator tool for wikis.  It’s not my preferred Enterprise 2.0 ROI method, I like to start small and use case studies, but for those who work in an organisation which demand the sorts of ROI cases that look at man hours saved per month it could be very useful!

If you enjoyed this post, make sure you subscribe to my RSS feed!

Great article about Comcast and SouthWest airlines monitoring Twitter for customer feedback

“When C.C. Chapman noticed a blemish in his high-definition television’s reception during the NBA playoffs recently, he blasted a quick gripe about Comcast into the online ether, using the social network Twitter.

Minutes later, a Twitter user named ComcastCares responded, and within 24 hours, a technician was at Chapman’s house in Milford to fix the problem.”

Thanks to Jeremiah Owyang for promoting on Twitter.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Another day, another article which looks at making the case for Enterprise 2.0 ROI.  The premise is:

• the average amount of productivity lost due to ‘distraction’ is 2 hours per day,
• the average hourly salary of a knowledge worker is $21
• therefore the monthly productivity loss is 21 * 2 * 20 = $840 / month / knowledge workers.
• therefore $100 – $200 / month / knowledge worker is a not unreasonable price to pay for an Enterprise 2.0 platform

I’ve looked a fair bit at wiki ROI and other ROI subjects around Enterprise 2.0 - and there are definitely two approaches.  One is the above approach, but I still can’t help but feel that it has an abstract and not particularly measurable feel to it.  Is this something you would be comfortable approaching your CFO with?

The other way is to start with a small pilot that costs so little it doesn’t need approval.  Get positive stories around its success and start to grow and spread useage of the system.  Then you have a provable ‘ROI’ based on metrics and success within your own company.  It may not be a case of “we can save each employee 37 minutes and 21 seconds a day” but more of “if we didn’t have it that team wouldn’t have won that contract” - therefore we’ll get more wins of similar sizes if it is rolled out to other teams.

The best course of action will always depend on the personality of your CEO / CFO / decision maker.  But the low entry cost of Enterprise 2.0 allows you to ask for forgiveness rather than permission, and avoid having to have an all or nothing conversation with unenlightened decision makers.

If you enjoyed this post, make sure you subscribe to my RSS feed!