Enterprise 2.0 Vendors – An Implementation Lifecycle Model

On a phone call with a Connectbeam customer, I heard what seemed like a good description of the way in which Enterprise 2.0 – and perhaps other enterprise software – achieves enterprise-wide adoption. This particular customer started with an internal advocate who started with a departmental implementation, and is now rolling it out to thousands in the organization.

Now anyone following the space knows there are many, many factors in the process of gaining adoption. What I’m going to describe is a slice of those factors, but I think it’s a juicy slice.

The graphic below depicts the model:

Four stages in this simple model. Let’s break ’em down a bit.

Implement

This is the initial toehold in the organization.  Where will the app makes the most sense? For many vendors, the place where it makes the most sense is the department where the most enthusiastic advocate resides.

Clearly, the vendor needs to consider where its app will have the highest impact, and where an office culture will be receptive to a new way to working.

Implement also includes any integration with other apps. Don’t underestimate this. It takes a bit of time to set things up, and often at the departmental level, employees aren’t as familiar with corporate apps.

But really, the Implement process revolves around the manager who has the most passion for your app.

Try It

Next, employees need to actually use your application. This is important (obviously). If you’re going to show ROI for your app, it starts with people actually using your app.

Measure usage stats. These are the early markers of whether the app will be successful inside the company.

The internal advocate needs to recruit fellow passionates into this process. Try out the service. Put some real live near-term projects and tasks up on the service, be it a wiki, microblogging, blogs, social bookmarking, RSS, etc.

The internal advocate and his/her fellow travellers should celebrate when other employees use the product. Give them a shout-out for their usage, recognize the useful stuff they create.

The Try It stage needs to run for a few weeks or even months. The app really needs to prove its utility in this stage.

Anecdotes

After sustained usage by a group for a while, there will be interesting Anecdotes that emerge. Let’s be clear on the value of these…

Anecdotes drive company-wide adoption

Dry stats such as entries per day, clicks per user, etc. are the stuff you need to measure whether people are Trying It. Anecdotes are what sell the app to other departments and locations inside the organization.

Anecdotes are tangible examples of value. Other employees can hear these examples, and imagine the app being used in their daily work.

Anecdotes that put real dollars behind the use of the app are incredibly value. “So-and-so did this with app, and ended up saving $XX,XXX” types of stories. Those get the attention of senior management, make heros of the internal passionates, and put the social software app on an equal footing with other apps inside the company.

The internal advocate is best-positioned to hear and solicit these Anecdotes. They are the key to company-wide rollout.

Adoption

Welcome to the world of big-time software. Once you break through the departmental and geographic barriers, you’re going to get a lot of feedback on your app. More use cases will emerge than you knew. And more feature requests will come in.

But, attention will still need to be paid to the Try It stage. These other departments may not have a dedicated passionate. The key here will be recurring communication about Anecdotes. The group of internal advocates from the original pilot will become ambassadors and trainers on the best ways to use the app. This continues their role as internal heros and stewards of the app, and leverages their energy and experience.

Wrapping Up

This is a simple model, with a few observations provided. If you’ve got others to share, feel free to weigh in with a comment below.

I’m @bhc3 on Twitter.