FOWA: Enterprise Adoption of Social Software (Suw Charman) [en]

Here are my live notes of this Future of Web Apps (FOWA) session. They are probably incomplete and may contain mistakes, though I do my best to be accurate. Suw has written a blog post about her presentation.

Suw is a freelance consultant, has done a lot of work with businesses and vendors. Guide on getting your stuff used by businesses, based on her experience.

A couple of areas to think about:

• tech readiness? does our tool work?
• support readiness? are we ready to provide support to our customers, and how they will adopt our tool and convince people in their business to adopt the tool?

Two sides of the same tool.

Important: make sure your tool is really ready. If it’s still buggy, if the interface or language is confusing, don’t try to sell it into enterprise. Get more funding first. You only get one chance in enterprise. They won’t come back to see where you’re at.

Incremental improvements based on user feedback won’t work in businesses. They want something that works now, and regular but not-too-frequent updates. Stability.

Have a process for feature requests. Difference between big vendors (MS, Oracle) “this is what we’re giving you, deal with it” and small vendors.

Pilots aren’t an opportunity to do user testing. They’ll shy away if they feel they’re being used as guiney-pigs.

Don’t assume simple tools will automatically get adopted. People very resistant to use software. They don’t use software because it’s cool. They just want to get the job done, and will find ways to work around the tools they’re given.

Where do you start? Try to figure out what businesses want from you as a vendor, and your tool.

• integration with their existing systems, single sign-on, active directory, LDAP
• very concerned about security: “can our employees use this and put data in it and have that data be safe from accidental stupidness or prying eyes?” Technical security and user stupidness security (delete everything by mistake). Big plus for wikis, which have history. Disaster recovery: offices burn down, how will you help them retrieve their data

Understanding time scales. It can take months for things to happen. Lots of things can get in the way of adoption, even with vocal evangelists inside. Contracts, lawyers, packaging…

• be aware of internal political rankings (stakeholder management)
• be flexible about how you intend to sell into business. You might end up having to host your service (very different from selling a chunk of software). Trojan mouse solutions.
• be prepared for runaway success. Can you scale? Really? Quickly? Administration can turn around from “against it” to “we want this everywhere, now!” in the space of weeks
• be prepared for failure — understand what happened, and have processes in place so that you can learn from failure, but possibly not the same way. Try and fail in new and innovative ways.

Businesses are quite happy to spend money on hardware, software, but not really on operational (people) stuff. Bundle in your support costs into your selling price. If you do an unsupported package, they’ll take that, and you’ll still get the calls. You need to make sure you can afford to help your client get the best out of your tool. How will you be responsive? How will you deal with your contacts in the business, and all the (possibly tens of thousands) of people in the business using your tool?

Sales! One case where a business tried to get through to the sales people to buy, and didn’t get a response. Had to call the CEO! Have someone available to talk to a client.

How are you going to explain your tool to the people who are going to use it? You need an adoption strategy. No use in just giving people your tool. steph-note: as I say, throwing blogs at people doesn’t make them bloggers. What kind of materials are you going to provide them with?

A good place to start: pilots. Groups of like people. Who are groups of people who might benefit from this? Case with wiki: PAs and secretaries, for example. People like very specific use cases. Not good at generalising. Who are you talking to and what do they need from your tool?

Adoption isn’t a business goal. Running the business is the business goal. You need to meet both the wider business goals and the individual people’s goals.

People don’t use documentation. They don’t click help. They ask human beings instead. There is a lot of informal and semi-formal learning going on in businesses. 80% is informal, it seems. Formal learning, training courses aren’t effective. How can you provide ad hoc support? IRC channel? Social collaborative learning tools? (blogs, wikis)

Centralised support is important for the people using the tool. If the company is going to take over that role, they’ll need the materials for it. Make your material user task oriented, not software task oriented. “This is how you do a meeting agenda in the wiki.” Not “this is how you make a page”. Present it to them on a plate.

A qualitative leap needs to be made between old and new things, even if the new things aren’t so much more complicated. That leap can be difficult. But at some point, when enough people in the organisation are using the tool, they start helping each other. Provide the materials for that. Giving people the confidence that they know how it works.

Don’t try to make it up as you go along. Plan in advance. Bring people in. You don’t have to do it all alone (materials, etc).

More about this! Important: both management and grassroots buy-in. Balancing top-down with bottom-up approaches.

Q: tips for demonstrating tool usefulness?
A: work on the use cases. ROI: investing time and money and getting something in return. Important to understand those metrics. Careful, metrics don’t tell you what an individual’s use of something is. One of the problems with social software is that it can sound a little fluffy. “It improves collaboration.” But people think like “I want it to improve productivity to the point I can fire someone.”

Q: is it different for open source tools?
A: enterprises can be very wary of it (how will we get support?) even though there is a huge amount of open source being used. The more technically savvy they are, the more likely they’ll go for it, and the more business-oriented, the less. No hard and fast rules.