The intranet post-mortem Part II

Sooner or later, an intranet will reach the end of its working life and a choice will have to be made: to retrofit the system or to rebuild it from scratch.

By Paul Chin

An old adage tells us that all good things must come to an end. While we do our best to maximise our investment in the software we use, it too has a lifecycle. It is only a matter of how long it lives and whether anything productive comes out of its use while it is ‘alive’.

Intranets, being corporate systems and often developed internally, are influenced differently compared to packaged software. Their development is driven less by marketing and more by an organisation’s current business processes. And as such, user expectations of these corporate systems will change in relation to the evolution of the business. A system considered a crucial business tool one year could be merely adequate, or completely defunct, by the next.

Since an organisation’s needs are in a constant state of flux, the systems supporting them must change and adapt in parallel. But when the gap between business process and technological tool becomes too wide, it is a clear indication that the system may be coming to the natural end of its lifecycle. Sooner or later, an intranet will have to be put out to pasture – at least in its current incarnation. A decision will then need to be made: to build a new system from scratch or retrofit the existing system to meet the organisation’s new requirements.

Why are intranets kept past their prime?
An intranet can come to the end of its lifecycle because of technological advancements, changes in process and functionality, or a failure to meet user expectations and business requirements. This is something that every system owner will have to deal with at one time or another. But once they do come to the realisation that their intranet is no longer productive, what happens next?

The answer to this question can never be found by the intranet team, alone. Aside from the business and technological implications of moving from one system to another, there are human factors at play as well. When an intranet team – programmers, designers and content owners – is so heavily involved in the development of a system, it is understandable that there will be an element of personal attachment to it. And because of this attachment, any motivation or justification for keeping a system alive might not be the most logically or financially sound.

There is also a more paradoxical reason why some intranet owners prefer to keep a system around. They invest additional time, money and effort – to the benefit of no one – to keep their intranet alive for fear of what may appear to some as a waste, should the system be scrapped. What intranet owners need to understand is that no system is permanent. Therefore, nothing is wasted if the intranet was productive during the prime of its life. There is no waste if the system has already served its purpose. Allowing an intranet to come to the natural end of its lifecycle is far more cost effective than pouring large amounts of money into an obsolete system, merely for the sake of appearances.

For these reasons, the future of an intranet often requires the involvement of more objective third parties. These could include senior members of management who helped champion and finance the project; outside intranet consultants hired to audit and review the organisation’s system and business needs; or, a combination of the two.

The post-mortem review
An intranet post-mortem usually takes place before any final decisions are made about the fate of the system (regardless of whether it failed or came to the natural end of its lifecycle). Despite its somewhat morbid moniker, a post-mortem is basically a formal review process involving all upper-level intranet stakeholders, from both the business and IT camps. Their primary goal during this review is to determine the next steps for an intranet:

Retrofit – The existing system and infrastructure is updated to meet new business requirements;
Rebuild – Build a brand new system from scratch or replace with a commercial, off-the-shelf solution;
Scrap – Scrap the system entirely (this option rarely happens without replacing the outgoing system with something else, and typically only when there is drastic change in business direction).

A very common pitfall to be aware of during these reviews, however, has nothing to do with either technology or process. Intranet post-mortems can sometimes become very heated, and it’s crucial, if the process is to succeed, not to play the blame game. It is highly unproductive (and even destructive) for intranet stakeholders to waste hours behind closed doors, arguing about ‘who should have done what’ and ‘why so-and-so didn’t do their jobs’. Do not harp on about what should have been done. Instead, concentrate on what needs to be done.

Retrofitting versus rebuilding
It is a common misconception to believe that it will always be easier to retrofit an existing system as opposed to starting from scratch. In certain circumstances, an existing system can actually act as a millstone around the necks of developers, limiting them in what they can do within the confines of that existing system.

Attempting to retrofit an existing system that is incompatible with the new technology’s vision will force intranet teams to have to repair the old system first, before they can add any new functionality. And it is the extent of these repairs that will be the deciding factor on whether a system is retrofitted or rebuilt. It’s like trying to rebuild a house after it has been badly damaged by a fire. When a charred frame is all that is left of the structure, it would make more sense to demolish it and build a new one.

Retrofitting an existing system
Retrofitting is the process of modifying and updating an existing system in order to meet the standards of new business requirements or changes in technology.

It can include:

Adding intranet modules to support new processes, projects, or departments;
Removing old processes that are no longer applicable;
Adding functionality with newer technology, which may have been unavailable when the system was first conceived and developed.

The greatest advantage of retrofitting is that intranet owners will be working with a stable and established infrastructure. The intranet is well past the growing pains associated with the introduction of a brand new system, having already spent a considerable amount of time in the production environment. It’s simply a matter of building upon an already solid foundation.

On the surface, it may appear as though retrofitting is the easier of the two options. But, depending on the condition of the existing system, it can actually tie the hands of developers. The existing system might not be flexible enough to accommodate the new changes – both in terms of technology and functionality.

Building a new system
There are times when it might not be possible to retrofit an existing system – at least not without much effort. If very little of the current system can be re-used, rebuilding from scratch might make more sense. This provides intranet teams with a blank canvas that is unrestricted by the confines of an obsolete system. Some reasons for building from scratch include:

The old system is too restrictive and hinders developers’ ability to make necessary changes;
Organisational needs change drastically, making the existing system obsolete;
The requirements for the new system differ vastly from the current system;
The time and effort required to build a new system is significantly lower than that of repairing and retrofitting an existing intranet.

Although this is the path of least technological resistance, it is also the tougher option for intranet teams to accept (because of the ‘attachment issues’ I mentioned previously), and the tougher option to sell to management (they will be asking, “What happened to the old one?”).

Intranet resurrection
It is undeniable that systems will die. Some will fail outright, while others will outlive their usefulness over the course of time. Deciding on whether to retrofit or rebuild is dependant on the state of the current system. If retrofitting, there must be a stable foundation to build upon. If rebuilding, care must be taken to ensure that reusable components are being discarded.

The goal here is to start a new system lifecycle, not to slap a plaster onto an obsolete system for the sake of keeping it alive.

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

Core post-mortem issues that must be addressed
First and foremost: Whether an intranet is actually still needed, or if there is another active production system available that can take its place.

If the intranet failed:

Whether it was a pre or post-production failure.
What caused the failure? For example, personnel, technology, politics, corporate culture, lack of funding, lack of time, no user interest and so on.

If the intranet came to the natural end of its lifecycle, establish:

The organisation’s new requirements and how much of the existing functionality is still applicable;
How much of the existing system’s technology is still current;
How much of the existing system’s content remains applicable and relevant.
Does a new intranet team need to be assembled?
New members may be needed to support new modules and some existing team members may be re-assigned if their part of the system is no longer needed.
Does newer technology need to be adopted?

Building upon an outdated set of technologies will shorten system longevity and make future support more difficult.