The intranet post-mortem Part IV

Intranet re-launches must be carefully planned to ensure a positive end-user response.

By Paul Chin

There is something very upsetting about people who go to great lengths to find fault, but never bother to offer any solutions or suggestions. Constructive discussion leading to positive change is a natural part of progress. But if there is no action, it is just complaining for the sake of complaining.

The goal of an intranet post-mortem review is not just to gain an understanding of why a system failed or why it came to the natural end of its lifecycle, although that is clearly important. Any discussion of intranet post-mortems would be incomplete without taking a look at what comes out of the whole process – namely, whether an intranet is still the right tool to address current business needs and, if so, what needs to be done to launch a new, improved system.

In this final part of my intranet post-mortem series, I’ll be discussing the re-launching of an intranet after the review process has been completed.

Defining a system launch path

It is crucial not only to have an understanding of what needs to be done – in terms of functionality and design – to resurrect an intranet, but also how to get it from the development stage to a fully fledged production environment.

That path is not a simple process. In order to avoid having to hold another post-mortem in another few months, organisations need to make sure that three core components are defined prior to development:

1. Requirements

A new intranet that arises out of a post-mortem review has a very big advantage over a brand-new system being introduced for the first time. Intranet stakeholders should already know what works and what does not.

When re-tooling an intranet, however, be prepared for major changes. Drawing up a new set of system specifications might require large portions of the current system to be re-written or discarded altogether. The important thing here is not to become over-attached to features that do not work as intended or are simply not needed or used.

Understandably, it can be tough, on an emotional level, to throw away parts of an intranet that took a lot of time and effort to build – especially for those who were directly involved in the development.

But if these features are not needed, they will end up acting as a millstone that hinders user acceptance and unnecessarily weighs down the overall system. All intranet stakeholders – content owners, business analysts and developers – must agree upon a formal set of system requirements before development begins. Since each core stakeholder group will have its own set of priorities, expect a certain amount of compromise. Do not, however, try to cram everything into a single release. This will cause ‘system bloat’ and will affect delivery time.

2. Game plan

A strategy and clear objective of what tasks need to be done is crucial. A development game plan is a formal set of guidelines, spelling out personnel involvement, task assignment, project milestones and timelines, and deployment strategy. An official game plan helps intranet developers avoid ad hoc decisions during the development process. It also helps to place useful limitations on the project, preventing over-ambitious intranet team members with big ideas from falling victim to ‘feature creep’.

3. Migration path

A pre-defined migration path – a carefully plotted course from development to production – is essential to ensure that the system goes through proper testing in several controlled environments before heading into real-world usage. If the existing (and soon-to-be-obsolete) intranet is still required to run ‘in production’ during the post-mortem review – and during the system retrofit or re-build – a proper migration path will prevent the development of the new system from adversely affecting the operation of the one currently in production.

Migration paths will vary depending on the size and complexity of the intranet (key factors might include the amount of content, number of integrated applications and size of the active user-base, for example), but should follow the general four-stage process shown in figure one.

Intranet launch methods

How a new system is launched, or re-launched, into the production environment can play a big part in how the user community responds to it. Users who are technically inclined may be more receptive and will usually find the introduction of a new system less of a disruption. But users who are less tech-savvy, or who have had prior bad experiences with IT, might regard a new system with an, "Oh no, here we go again" attitude. Depending on the organisation’s IT history – and to a greater extent,

users acceptance of previous IT systems – intranet teams can adopt, broadly speaking, two primary launch methods, ‘loud’ and ‘quiet’.

Loud launches

‘Loud’ launches are used to generate ‘buzz’ before, during and/or immediately after, the launch of a new system into the production environment. Loud launches enable intranet teams to create organisational awareness – through various marketing techniques – of the new system, in order to generate a certain amount of expectation within the user community leading up to the system’s official launch.

With all this build-up and anticipation, however, intranet teams must be certain that the new system will be ready by the advertised release date. Delaying the launch of a heavily marketed system will undoubtedly create some embarrassment for the intranet development teams and cause users to doubt their ability to deliver on what was promised.

Quiet launches

‘Quiet’ launches, as the name suggests, come with minimal pre-release fanfare. Intranet teams rely on word-of-mouth advertising at the user level. There is no big promotional campaign, and in some cases, users might not even know that a new system or version is being developed. Most, if not all, development takes place behind the scenes and the intranet is released into production without any active marketing on the part of the intranet development teams.

Quiet launches provide intranet teams with much more flexibility since they do not have the stress and pressure of having to meet an official launch date.

The sound of silence

Never assume that users will be grateful for the introduction of a new system. Depending on the user community, a loud system launch can do more harm than good. The practice of quiet launches was developed as a direct response to users’ growing frustration with all things IT, both real and imagined. Bad experiences such as overdue systems, failure of those systems to live up to their pre-launch marketing hype, missing features and so on, will have caused many users to become weary and cynical of anything that comes from the IT department.

Quiet launches are also very useful in helping users avoid IT overload. Releasing multiple systems, or versions, one after another in close chronological proximity will cause disorientation. Eventually, new system releases will simply become ‘white noise’ to users and, regardless of how loud the system launch is, their arrival will be ignored. Having a good understanding of the organisation’s user community will go a long way towards choosing the appropriate launch method (see figure three).

Post-mortems: Action and reaction

Despite its morbid moniker, the intranet post-mortem should be seen as a natural part of the information management system lifecycle. Post-mortems should not be dead ends; they should result in a good understanding of why an intranet failed or came to the end of its lifecycle. It is this understanding that will enable intranet development teams to re-launch a better system with some longevity, a system that users will actually appreciate.

Paul Chin is an IT consultant and freelance writer. Previously, Paul worked as an intranet specialist in the aerospace and competitive intelligence industries. He can be contacted at post@paulchinonline.com

Migration path stages

1. Development

New requirements are gathered (via discussions with intranet stakeholders, user surveys, intranet analytics software), a new set of specs is drawn-up and initial development takes place in a controlled test environment with test data or data mirrored from production.

2. Developer testing

Testing by developers, and possibly key intranet sub-site owners, follows after the completion of initial development. This is done in a controlled test environment with test data or data mirrored from production.

3. User testing

After most of the system bugs are weeded out in stage two, the retrofitted/rebuilt intranet is made available for testing by a carefully selected control group of users. This is done in a controlled test environment with data mirrored from production. Feedback from the control group is gathered during this stage and reviewed for possible action.

4. Production

Once the system has been polished, production data is ported over to the new intranet and the system is moved to the production environment. This must be done during off-peak hours in order to minimise impact on the user community. Depending on how the system is to be launched, marketing and promotion of the new system might take place.

System launch-method characteristics

Loud launch

Heavy marketing and promotion (from the official intranet teams) before and after system launch;
An official launch date is announced to the organisation’s user community;
Aggressive marketing to maximise system exposure.

Quiet launch

Little to no formal marketing or promotion by the intranet teams;
The official intranet teams establish a target launch date for purposes of development (nothing is formally announced to users);
Relies on low-key, user-based word-of mouth promotion.

Loud-versus-quiet launches

Loud launch

Launch date can be guaranteed, and there’s little chance that system delivery will be delayed.;
The user community has had mostly positive experiences with IT and their systems;
A reasonable amount of time has passed in between system launches.

Quiet launch

The system is a work in progress and a delivery date can’t be absolutely guaranteed.
The user community is jaded by broken promises from IT, or there has been poor user response to past IT implementations.
Too many other systems are being (or have been) launched. word-of mouth promotion.