I've Moved this Blog ...

... to www.mrkieran.com.

Enterprise Learning from Morbidity and Mortality

In building out enterprise collaboration systems, I often see implementation practices in one area that can be successfully applied elsewhere.

Lately, I've noticed that the hospitals I work with all have regularly scheduled "M & Ms" – Morbidity & Mortality reviews, in which doctors and other clinicians analyze complications in patient care to better understand what went wrong, learn from it, and take appropriate corrective actions. (The practice was pioneered by Dr. Ernest Codman at Massachusetts General Hospital in Boston in the early 1900s – shortly before his colleagues banished him from the hospital, afraid that he'd make them appear incompetent. But don't let that discourage you.)

What does all this have to do with your organization?

Well, Enterprise 2.0 tools are spreading like wildfire right now, and many large companies have dozens of pilot or early-stage projects underway, exploring the business impacts of various social media (blogs, wikis, social networks, Twitter-like sharing tools, mobile apps). This strategy makes sense, given that social media are clearly going to have a profound effect on how business is conducted, though the specifics are not yet clear.

But a significant proportion of the E2.0 projects underway are doomed to failure, for all the usual reasons, plus a couple of new ones. In many companies, the people involved will simply move on to the next project, with little or no analysis of what went wrong. That's the perfect moment when the M & M process offers something of value.

To extract that value, you'll need to manage the M & M review carefully. Specifically:

1. Be impartial. You can only make improvements if you understand what really went wrong, and you'll never discover the truth if the review is seen as an exercise in attributing blame. 
2. Be sensitive. It's not that "mistakes were made"; the mistakes were made by people, or were inherent in the systems that people designed. People react differently to criticism, so the individual leading the review needs the tact and sensitivity of a family therapist.
3. Be thorough. A seriously ill patient may suffer multiple organ failures, making it difficult to ascertain the most serious problem. An M & M must be thorough to be useful.
4. Be consistent. Use a reporting template that collects and displays all the relevant information uniformly.
5. Focus on the important cases. The M & M process takes time and energy, so reserve it for projects where you're likely to find "teachable moments" that can be acted upon.
6. Share the results. Communicating the lessons learned isn't just part of the process; without effective communication the process is just wasting everyone's time.

Despite the resistance Dr. Codman's innovation faced a century ago, M & Ms have grown to become a crucial feedback mechanism for hospitals – because they help save lives.

Could your organization use something like that?

A Different Real-Time Web

I've often thought it strange, when watching a TV medical drama, to see amazingly realistic shots of surgical procedures, followed by scenes of what must be pure fiction, where the doctors are spurred into action via a page, from one of those 1980s pager things on their belt.

Come on, nobody these days actually uses a pager, do they?

Well, I learned today from an expert in medical informatics that pagers are alive and well in hospitals because they so effectively reduce the latency between when a message is sent and when it's received. "In patient care, a minute will make a big difference", he said.

Ironically, this came up in a conversation about how his hospital could extend their existing social networking implementation into the realm of patient care, in particular the possibilities for using internal micro-messaging tools (a secure internal Twitter-like app) to improve communication between the people treating each patient.

In the long term, hospitals will embrace such tools for the obvious patient benefits. Patient care teams provide an excellent use case for micro-messaging, because team-wide status updates enable faster, more error-free transfer of patient information from one team member to another. In an ICU (intensive care unit), for instance, a technician signaling that a patient's respirator had exceeded some limit would enable the nurses, residents, and attending physician to more quickly assess and treat the patient's emergent condition.

Why in the long term? Because people in medicine are not eager to adopt new technology. As a patient, I can understand why. Would you want your doctor treating you with some new but not thoroughly tested device?

And that's why pagers persist to this day. In a clinical context, a page may carry less information than a micro-message or an email, but it's less risky.

Only some of this is due to its lower latency; the cultural practices that grow up around a technology are also important. Email, for instance, is such a bullying time-suck that many people let their inbox become a "to-do" list that runs their lives. By contrast, a page is culturally understood to have immediacy, which frames the timeline in which you're expected to respond.

Social media will eventually have a deep and profound impact in the health care sector, as elsewhere. But don't be surprised if the medical community takes a lot of time to apply these new tools, operating as they do from a prime directive – first, do no harm.

Beyond the Use Case

I work in the Professional Services group at an Enterprise 2.0 software vendor, so I’m well aware that most companies licensing our collaboration platform do so because they have a specific application in mind – a use case.

But lately, I've started to suspect that too much attention is given to the use case throughout the enterprise software deployment process, from RFP through to implementation.

Don't get me wrong, I think use cases are wonderful. Whenever I launch a new customer that’s already thought through and documented their main use cases, I know the implementation process will go more quickly and smoothly.

But I'm increasingly convinced that with Enterprise 2.0 tools, some companies would realize greater economic benefit if they just jumped in and started using them, rather than focusing too closely on a previously defined use case.

Why? Because companies often end up using collaboration software in ways they simply couldn’t have anticipated when it was specified or purchased.

Among the real-life examples I've observed:

• By the time the software license contracts have been signed, the company’s needs or priorities have changed. Sometimes other valid use cases will emerge and get traction; other times the system withers on the vine.
• Within weeks of licensing the software, the project’s internal champion or executive sponsor is moved to another role, or worse yet leaves the organization.
• As the system is rolled out, the original champion or someone else identifies an even higher value or higher priority use case, which ends up taking precedence.
• A company licenses collaboration tools for a specific use case, such as a product development wiki, only to watch it spread across multiple departments until it eventually replaces their existing intranet.

I've also worked with companies that have created hugely successful collaborative systems starting with a use case that read, “Let’s begin using these new E2.0 tools and learn how we might benefit from them.” Without exception the process has involved senior management signaling their support for the new initiative, then nurturing the self-motivated champions who come out of the woodwork with their own applications – yes, their use cases.

So, I'm not arguing against the use case, just trying to keep it in perspective.

As any successful technology comes to market and is purchased by successive waves of customers (from so-called early adopters through the mass market), there is always a point, just before widespread adoption, where companies that haven’t yet deployed it look around and realize it’s only a matter of time.

For Enterprise 2.0 software, that time is now.

Twitterville: My Kind of Town

Shel Israel's new book Twitterville has modest ambitions – providing an overview of how Twitter is currently being used for business. It's a quick read that doesn't attempt the impossible task of cataloging all of Twitter's enterprise possibilities, or spend much time comparing Twitter with other kinds of communications and collaboration tools.

But it's precisely for these reasons that I liked Twitterville; instead of blathering on about theories of social networking, it simply presents anecdotes about how companies large and small are using Twitter to respond to complaints, improve their products, and in a few cases, measurably increase sales.

I appreciated the author being up-front about how the book was written – he tweeted his few thousand followers asking for suggestions for each chapter, then captured and edited the best responses. I'm relatively new to Twitter, and had used a similar process of asking the people I trust for advice when taking my tentative first steps with this new but undeniably powerful communications medium.

Most of Twitterville documents the way Twitter has spurred the growth of different kinds of what the author calls "global neighborhoods":

1. Large consumer-oriented companies: these arguably have the most to lose by ignoring the rise of social media, such as Twitter. There are already many examples of major consumer brands (including Amazon, United Airlines, and Motrin) that have damaged themselves by responding slowly, ineffectively, or not at all to consumer complaints distributed via social networking. At the same time, companies that proactively use Twitter to listen for and respond to customer mentions of their brands are getting disproportionately positive press, just for doing something they should have been doing all along.

2.  Business-to-business: not many B2B companies have leveraged Twitter effectively to date, though some have gone beyond standard sales and marketing tactics and started using Twitter as a recruiting tool. As Twitterville points out, any business seeking to gain a competitive advantage via Twitter, whether globally or locally, needs to look carefully at the issue of identity. For instance, @comcastcares is the Twitter handle for a real human being, Frank Eliason, who has more than 30,000 followers and has tweeted more than 35,000 times. By contrast, @timewarnercares is being followed by more than 500 people, but has yet to issue a single tweet.

3.  Small business: for many small companies, Twitter provides a better ROI for sales and customer service than any comparable expenditure of time and money. Twitterville documents a number of exemplary small businesses, from coffee houses and pizza joints (and a popular San Francisco crème brûlée cart) to Web 2.0 companies such as Seesmic (which makes the Twhirl Twitter client). In particular, it describes how the entrepreneurs behind these companies are breaking the traditional customer / vendor boundaries that until very recently governed business, replacing them with a model in which customers aren't just consumers but are actively courted to co-define a brand and thus have an active stake in its success.

4.  Personal branding: Using Twitter (and comparable internal micro-sharing tools) is the fastest way to build your professional identity, whether you work in a global corporation or as a freelance contractor. But you need to have a very clear career mission in tweeting, focusing on what you're solving for your customers or employer, says Jeremiah Owyang (now of the Altimeter Group, formerly an analyst at Forrester Research). "Don't focus on the minutiae of tools; instead, think of the greater problem and solution you'll provide."

I found the second half of Twitterville especially interesting, as the author goes beyond commerce to look at how Twitter-based communities can be further the growth of philanthropy, government 2.0, and what Israel calls "braided journalism". Of these, journalism is the first to experience gut-wrenching change as a result of the explosion of information sources on the web, a trend that can only get more severe as "the web" evolves to become "the real-time web". Recent examples include the US Airways flight that landed safely in the Hudson River, and the worldwide push-back against corrupt elections in Iran, both most effectively reported via Twitter.

These are early days for the 140-character phenomenon of micro-sharing, but savvy companies and individuals are already staking out turf in the neighborhood.

If you've been tweeting for a while, Twitterville isn't likely to rock your world. But if you're new to Twitter and want a quick overview of the commercial possibilities, a visit to Twitterville is a good place to start.

Let's Stop Talking About Adoption

As more and more organizations start using social media tools, I'd like to propose a modest change in the way we talk about the "adoption" process. Let's start calling it something else.

Over the past year and a half, I've helped over a hundred organizations implement social networking tools, and have fallen easily into the industry-standard practice of calling the process "adoption". Yet I've never been comfortable with using adoption in this context, for reasons that only recently have begun to crystallize.

First, adoption – real adoption, the adoption of a human child – is a heart-achingly beautiful process that can generate indescribable life and love. Software can be pretty amazing at times, but it rarely makes you weep with joy. And adoption in this context can be an emotionally laden term, not the best way to encourage someone to use a new software program.

Adoption involves taking on a lot of responsibility. Many of the people expected to become "users" of the new system are already using tons of applications – in fact, they're learning new ones all the time. No wonder it can be difficult to get people to use a new tool, even one that would genuinely save them time and work.

So, if adoption isn't the right word for this process, what is?

I'm proposing that we use "traction" instead, because it's a better metaphor for the way enterprise software really is used in an organization:

1. Adoption is an event; traction is an on-going process that applies both to organizations and to the people who work in them, allowing for differences in their backgrounds, motivations, and capabilities.

2. Adoption is relatively rare; becoming proficient with a new software tool is something most office workers do on an almost daily basis.

3. Adoption is abstract; traction is a familiar physical sensation, like the grip of a tire on a road.

But for me, traction comes with an even better connotation – the idea of directed forward motion. Smart organizations, and the smart people who comprise them, are always striving to move forward. It takes time and trouble to become proficient with a new tool, but people do it for a reason – they're convinced it will improve their existence.

They're right.