Delight or Dismay: Intranet Launch Methods

By Paul Chin

Originally published in Intranet Journal (26-May-2005)

back back to portfolio

Think back to your last major intranet release: Was it launched with your entire intranet team gathered around in a T-minus countdown or did it creep its way into the corporate bloodstream with nary a sound?

As in life, first impressions are important in defining how you're perceived by others; and this is even more true with your intranet. The manner in which you unveil a new system will reflect how users view it from that moment on. It can be looked upon as an edifying experience or an annoying social barnacle you can never seem to shake at a party.

While it's not entirely impossible to change people's negative perceptions of a system, it's never easy to erase the preconceived notions they may have built up in their heads over time—justified or not. Why not get it right from the beginning?

Loud Versus Quiet Launches

IT views system rollouts in terms of deployment; i.e., how to release an application into the organization's production environment with minimal end-user disruption. Intranet content providers view rollouts in terms of marketing and promotion. But there's another aspect of intranet launch that doesn't get as much attention as it should: user reaction.

How you launch a new system—or a new version of an existing system—will greatly effect how the user community reacts to it. You can't expect to drop it into production and hope for the best. Some may see it as a much needed addition to their existing toolset, while others may see it as an unnecessary burden on an already bloated IT infrastructure.

Every organization's user community will react differently to the introduction of a new system, so it's best to tailor the launch to the community rather than taking a blanket approach. Intranet owners have two primary forms of system launch: Loud and quiet.

Loud launches are used to create buzz and public awareness of an upcoming system. There's a build up of anticipation and expectation months or weeks prior to a system's official launch date, which is usually also the basis of an internal marketing campaign. Those taking a loud launch approach can employ an arsenal of promotional tools to maximize exposure such as banners, newsletters, and e-mail announcements.

All of this buzz leads to a grand unveiling, but there's one overriding caveat with using loud launches: Intranet owners must be certain that the intranet will be ready by the launch date. Otherwise, with all the fanfare surrounding system launch, a failure to deliver on the promised date will be a very open advertisement of the failure. A missed launch date—whether as a result of unforeseen delays or system bugs—may create some embarrassment for intranet owners and cause users to lose faith in the intranet team's ability to keep a promise.

The idea of quiet launches is a little unconventional as far as IT systems go. They involve very little pre-release fanfare and rely mostly on word-of-mouth advertisement. Rather than a big promotional campaign, intranet teams work on new systems and upgrades quietly, with very little knowledge from the users. Once the application has been completed and thoroughly tested, it's slipped into production without a lot of hoopla. If there's any advertisement, it's usually low-key such as a simple corporate-wide e-mail message, and it's done only after system launch.

Quiet launches provide intranet teams with more flexibility since they won't have the pressures of a firm launch date to weigh on them. The obvious downside, of course, is that word-of-mouth is highly unpredictable. Because of the low-key nature of quiet launches, there's a chance that users won't even know of the existence of the new system or upgrade.

Launch Characteristics
Loud Quiet
Marketing and promotion takes place before system launch Marketing and promotion takes place after system launch
An official launch date is announced months or weeks prior to system release A target date is used only by the intranet development teams and content owners; there's no publicly advertised launch date
Employs an aggressive internal marketing campaign to create buzz within the user community Relies on low-key, word-of-mouth promotion
Used to build up user anticipation and curiosity There's little knowledge from users that a new system is in the works until it's been released into production

Choosing the Right Launch Method

You should never assume that all users will see the introduction of a new system as a good thing. The practice of quiet launches came about as a direct response to users' growing frustration with all things IT. Perhaps, having gotten weary of negative experiences with past systems—perpetually overdue systems, missing features advertised in the marketing campaign, systems that don't live up to its hype—they have become cynical of IT and their empty promises. Attempting to win them over with yet another loud launched system will do more harm than good. There are only so many times users will fall for the old "this time things will be different" routine.

In cases like these—even if the system does live up to its promises—users will view the announcement with a lot of cynicism. So, regardless of how good the system ends up being, users will never know because they won't even give it the chance to win them over. They will simply ignore it as another doomed project on IT's application assembly line.

Instead of thrusting an upcoming system in front of users with weeks of marketing exposure, a better approach would be to use a quiet launch. The new system or upgrade can then be advertised via a simple e-mail announcement or a blurb in the organization's newsletter.

Understanding your user community's perception of IT as well as the products and services that come from them will help you determine what system launch method to use. The following table will give you a good idea of when to put each launch method into practice:

When to Use Launch Methods
Loud Quiet
You're certain that the system will be ready by the official launch date, and there's little chance of delay The system is a "work in progress" and an official launch date can't be guaranteed
The user community hasn't been jaded by past IT failures The user community has grown weary of broken promises from IT, or by past system failures
Reasonable time has passed since the last loud system launch; you don't want to overwhelm users with constant system releases There has been little or poor response to previous loud system launches

What Are You Launching?

When deciding on the type of launch to use, you need factor in not only the culture and perceptions of your user community but also the size and type of what's being launched. Intranet launches can be divided up into three major categories:

  1. Initial intranet roll-out
  2. Major system updates and feature revisions
  3. Bug fixes and minor enhancements (unless they're high profile or well-known problems, bug fixes and minor enhancements are rarely, if ever, loud launched)

During a system's life cycle, intranet teams will use a combination of both loud and quiet launches depending on the situation. For example, a loud launch can be used for the intranet's initial release into production; a quiet launch for incremental upgrades such as a jump from version 1.0 to 1.1; and then back to a loud launch to promote a major system revision such as a jump from version 1.0 to 2.0.

But it's never a good idea to use loud launches exclusively. You don't want to diminish the significance of new system announcements with repeated loud launches. Users will lose interest and become desensitized with overexposure. And then they will look upon these "grand unveilings" as little more than corporate white noise.

Closing Thoughts

You need to think beyond your own perception of an upcoming system when deciding how to launch it. You may see it as a huge contribution to the organization's application library because you were directly involved in the development process. But users who experience the system for the first time—and are somewhat detached from it—might not see it the same way.

Look back at previous system launches and how they turned out—even if they're systems you had nothing to do with. Often, users lump all IT applications together regardless of which team developed it; and they see one failure as a failure on the IT department as a whole. Because of this, it's possible for another team's misfortune to mar your own system launch.

It's the responsibility of every intranet team to decide whether their organization's user community will respond better to a loud or quiet launch. So choose wisely because once you commit to the launch you won't get a second chance to make a first impression. And if it doesn't work out, the team will have no choice but to go into PR mode.

Copyright © 2005 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.