Deploying a new collaborative web environment to power your organization’s Intranet or Extranet can be a daunting and often times frustrating project. The number one problem that new Intranet/Extranet deployments face above all else is poor adoption, when users simply can’t be convinced to use the application. Poor adoption can adversely affect any enterprise application, but it is especially costly for a collaborative one. It’s simply not possible to derive any real value from a collaborative web environment that isn’t used by a significant portion of a given organization.

Having both deployed collaborative portal environments myself and having seen many customers struggle with their own Intranet/Extranet deployments, I’ve noticed at least five important things that people often overlook that eventually lead to poor adoption. Keep these tips in mind before setting out on your next Intranet or Extranet project. Hopefully they will come in handy!

#1: Never underestimate the incumbent solution

When deploying a new Intranet/Extranet to replace an existing, legacy Intranet/Extranet solution, always remember to pay close attention to the incumbent solution. Users become quite comfortable with all the quirks, usability issues, and defects in any legacy application with a lifespan beyond a few months. The rather ironic thing about any unusable or even semi-unusable application is that it can build people’s self esteem once they master it. Having to surrender that mastery in order to adopt an entirely new system often comes as a blow to the application user’s self esteem, and in retaliation they will revolt.

When customers switch over immediately to a new application without any transition, they typically encounter roughly 30% or more of the user population accustomed to using the legacy system who will not hesitate to complain that the new system is worse than the old one, despite the fact that the new one is easier to use, has fewer bugs, runs 50% faster, etc.

The bottom line: a portion of people take pride in having mastered any application and may therefore be resistant to change, and a good portion of people hate any kind of change whatsoever. The better you can model your new deployment after the old, and gradually phase into the new, the more likely you’ll avoid complaints and poor adoption rates.

#2: Slow and steady wins the race

Rather than go with the “big bang” approach to deploying an Intranet or Extranet solution, the best deployments typically focused on one particular problem area or use case, and gradually expanded from there. It’s often best to find a project to tackle that fits into one or more of the following categories:

• An application that everyone hates to use
• An application that a distinct and identifiable group of users most frequently uses (example: the Marketing group, the Sales group, etc.)
• An application that involves manual, paper-based processing that could be easily automated
• An application where key business executives would be willing to sponsor the effort

Take the slow and steady approach: identify key areas to invest in up-front, set achievable deliverable dates, and build a solid reputation throughout the organization that’ll help carry you and your project team through the entire deployment process.

#3: Identify, listen to, train and reward your lead users

The ideal lead users are the people in your organization that are always on the cutting-edge of technology. I’m sure you’ve met them before: they’re the type of users that typically switch to new cell phones two times or more per year, the type who people regularly seek out for advice on any new technology-based product, and the type that probably could tell you more than you ever wanted to know about how to use Microsoft Excel. But keep in mind that they may not always be the tech-savvy types. Other types of ideal lead users are the folks who routinely keep in contact with large parts of your organization, who routinely train new members/employees, or are generally recognized as been well-liked, outgoing individuals. These are the folks that are crucial to have on your side when starting your deployment, as their opinion and ability to adopt new technology easily will heavily influence other people who might otherwise be resistant to change.

In order to satisfy them and bring them onto your side, it’s important to get their opinion early and often, and to insure that they are fully equipped to begin evangelizing your new Intranet/Extranet solution. It’s also critical to reward them for helping spread the word by appealing to their vices: advanced sneak-peeks at new technology, or a promise to further extend their notability throughout the organization will often be enough incentive for them to aid you through the deployment process.

#4: Plan, plan, plan… Plan!

It’s easy to get caught up in the excitement of any new project and want to begin seeing change immediately without proper planning. This can obviously lead to disastrous situations where certain key items are overlooked that should have been considered early in the planning phase. Areas that particularly get overlooked are:

• Knowing and communicating deadlines and “go-live” dates to the organization
• Preparing and having enough training sessions scheduled for end-users
• Preparing enough hardware, software, and consulting/developer time
• Preparing a clear, understandable information architecture, including a corporate taxonomy (if applicable for document management)
• Preparing user interaction and visual designs

Of all of those items, the one that can end up affecting adoption the most is the last one. It is absolutely critical that a good amount of time is spent on the project investigating and designing the best user interaction and visual designs for the Intranet/Extranet. Any Intranet/Extranet application with confusing user interaction or poor visual design could potentially cause irreversible user revolt. Users will lose faith in your team’s ability to develop a quality solution, and more often than not will perceive confusing menus, dialogs or poorly designed graphics as critical bugs.

#5: Be ready to measure your success

This may seem obvious, but it’s something that I’ve seen even the most experienced web project leads neglect during the early phases of their deployment. Make sure that you have clear expectations from your organization as to what they believe will be a successful deployment. This means having a clear set of metrics for success, and insuring that you are well equipped with the appropriate tools to measure the required metrics. These metrics are often referred to as Key Performance Indicators, or KPI. Be prepared to invest some time and money into selecting and setting up the appropriate tools to measure KPI. Even a minimal investment in a tool to track and report KPI is crucial to proving a successful deployment.

In many cases, I have seen customers reach the end of a deployment, feeling as though they had made grand accomplishments throughout the project, only to realize that they had no idea whether or not they were truly meeting their initial goals.

In particular, key things to consider are:

• How many users regularly contribute content? This can be an indication of how usable the system is, but also a sign of how well the users understand the system and its benefits.
• How long do users spend on the system? There are two sides to this: ideally people are looking for content and/or using applications, but in some cases you may want them to be spending less time, not more, such as when looking for relevant documents or locating experts or applications.
• How many users routinely use the application? If the project was replacing an existing Intranet or Extranet, having the original routine usage numbers and comparing the two side-by-side may give you some insights into adoption rates.
• How much time is saved with each use of the new system/application? Calculating this can often help provide concrete ROI to the organization, helping to justify expanded investments.

In addition to automated analytics tools collecting KPI, it’s important to also survey end-users. Ideally the survey should be short and to-the-point, but effectively you should be seeking to promote regular communication between your Intranet/Extranet project team and your end-users so that any minor points of frustration they encounter don’t ultimately boil over and cause them never to return.

Conclusion

Hopefully the five things outlined in this post will help guide you to a successful Intranet/Extranet deployment. Above all else, it’s important to remember that all applications and tools will evolve over time. If you’re measuring for success from the start, and solicit regular input from your users, you can make gradual improvements to your Intranet/Extranet to keep the adoption rate high and consistent.

Filed under: Enterprise Web