Why Digital Workspaces fail to launch, and how to ensure they don't (part 1)

A huge amount of effort and resources go into planning, designing, building, testing and deploying a new Digital Workspace. A Digital Workspace may include a traditional intranet site for top-down communications, sharing of content like forms and contact lists, document management, and teamwork tools. Nowadays, to qualify as a Digital Workspace, your platform may also include live chat, integrated work tools (e.g., individual files and email), and deep integrations into back-end business systems like CRM or IT-service management.

Yes, a lot of effort and thought goes into building and launching. But what about after launch? If you build it, will they come? Far too many intranets and Digital Workspaces get too little investment into making sure corporate users use and get value from the tools—known as adoption.

Another area that gets far too little attention is the who, when and how of the ongoing maintenance and control of the solution—which in the trade is called governance.

Our strong advice based on decades of experience in these projects is to plan, at the kickoff, for what will happen when the solution is delivered into the users' hands. This is too important, with too much money at stake, to leave to chance and hope.

What can go 'wrong' after the launch?

Almost all of the things can go wrong after the launch of any technology tool within an organization are actually the same thing—failure of adoption. The project team markets the solution to the user base and trains them up on how to use it...and nobody actually does.

Why do solutions fail to launch?

There is a wide variety of causes of adoption failure:

1. Users were not consulted enough in the planning and design phase, and thus the features/experience are not a fit. The platform itself may have been the wrong choice.
2. Training failure:  user training was not well planned, or was insufficient (or, in more than one case we've seen but were not involved in, nonexistent).
3. Training was sufficient, but ongoing user support (not just incident tickets, but governance assistance such as Site Creation or move-add-change) is not, and users give up. (This is often a sign of insufficient help-desk training.)

 What are the symptoms of adoption failure?

Sometimes there are no acute symptoms because the organization is not checking for them, that is, not asking for user feedback or not reviewing the analytics regularly. But if you are looking, you will find one or more of the following:

1. Analytics indicate what my old friend, Martin Bald of Elev8 Consulting (formerly of Microsoft), used to call an "elephant's graveyard": a ghost town nobody ever visits. Or, users are using only one or two features.
2. The Search engine logs, which show what people are searching for, are full of the same keywords over and over again—often common terms that should be easily found in the navigation.
3. Users forget (or ignore) the training and start using the solution 'wrong' (e.g., creating new Sites or Teams for every little task, instead of adding pages/lists/Channels to existing Sites/Teams).
4. Users, who have been presented with safe, integrated tools for collaboration, are observed going back, en masse, to public third-party tools that are not controlled or secured by the organization, such as Dropbox, Slack or Google Docs.
5. Those same users go back to what I consider the undead, unkillable zombie tools that they find comfortable:  email attachments as document management, and Excel spreadsheets as absolutely everything. Note that these resources, created by what I call with fully intentional derision the 1990s approach, tend to vanish when the individual employee leaves the organization.
6. Users complain (either in surveys or on the grapevine) that the workspace is too hard to use, or navigate, or find content in.

The bottom line in failure of adoption is that your end users do not trust the solution, either because they don't see the value, or the project team has not actually provided the value (for the users).

What can go 'right' after the launch?

Things change after the launch of new tools, but not always for the worst. A sign that users are seeing/finding the value in the collaboration suite (besides good analytics reports):  the solution owners are getting regular requests for MORE features, applications and integrations. When the IT team is overwhelmed with requests, well, that may be a bad sign (namely, that the initial design was not ambitious enough). But a steady trickle of requests for more is a very good outcome of a launch. But if mismanaged, this enviable situation can turn on you, and ruin the good will caused by the initial strong uptake.

So, what is the answer?

Your project team needs to plan for what happens after launch from day one. As the cliché goes, you can't manage what you don't measure. You're going to need to prove the whole project was worth the investment, right? That means customer satisfaction surveys—regular ones. You'll also need to plan your usage analytics from the very beginning, and create a plan to review them regularly. In both cases, you'll need to decide, before you start building, the solution's raison d'être, its goals and targets, and to do that, you'll need to plan what questions to ask (of both the users and the logs).

Is there a perfect approach to making sure everything goes smoothly? No, but there is one that is almost perfect. I'll be discussing that in Part 2 of this blog series.

‍