The intranet post-mortem Part III

By Paul Chin

Maximising the life expectancy of a corporate intranet is one part planning, one part experience, and one part crystal – ball gazing. It is as much an art form as it is a process of critical analysis. But in order to ensure an intranet has a long and useful life, predictions of that lifespan need to be made during the planning stage, before the first fingertip is laid on a key to commence programming.

It may seem strange to devote an article to intranet planning in a series that takes as its theme post-mortem assessments of intranet projects, but there is a very important lesson to be learned: what we do at the beginning of an intranet’s lifecycle will determine what happens at the end of its lifecycle. To a greater extent, this process of lifecycle planning will also determine how we handle, or are able to handle, system post-mortems.

Maximise system lifespan

There is no denying the fact that all information systems have a lifespan. However, pre-development planning is a major factor in whether the system eases gracefully into its twilight years after a lengthy period of service or comes crashing down in a ball of flames after only a few months in production. And the more flexible a system is, the more likely it is that elements of its content and structure can be recycled to form the basis of new projects when it comes to the end of its lifecycle.

Naturally, intranet stakeholders want to maximise system lifespan in order to maximise their investment, and to minimise the need to retrofit or rebuild the current system. The only way to do this is to build a system capable of adapting to changing circumstances, environments, and business practices.

Foresight is the name of the game here. But foresight should not be confused with padding an intranet with unnecessary and unrequested features. The goal is to design a system that meets all current requirements, while leaving enough ‘wiggle room’ to accommodate future system expansion. Just because a feature or function is not needed at the moment does not mean it will not be needed in the future. Maximising intranet life requires foresight in four core areas:

Infrastructure – Build an extensible system infrastructure capable of accommodating future additions;
Technology – Use only industry-standard and firmly established technologies;
Structure – Implement a modular and portable structure capable of adapting to additions and deletions of sub-sections and applications;
Knowledge – Encourage the transfer of knowledge among intranet team members.

Extensible system infrastructure

It is human nature to try to achieve as much as possible with the least amount of effort. It is also an unfortunate aspect of human nature to only think of satisfying immediate needs with minimal consideration for long-term effects and outcomes.

Corporate developers are often pressured by tight schedules, cost limitations and demanding supervisors to get a job done and to do it quickly. To achieve sometimes unrealistic goals, they are forced to cut corners, blurring the line between efficiency and carelessness. In order to save time, money and effort, they end up building a system that meets only the minimum requirements at the expense of expandability. Initially, that may not be a problem – until, of course, those requirements change. Developers will then be caught up in a mad dash to meet the expectations of a user base that constantly demands bigger and better things.

There are so many variables that can affect the future face of an intranet that it is entirely understandable that it might eventually look very different from what was originally conceived. Departments and workgroups that were not part of the initial version might be added to the system; remote locations may start to access the intranet via a virtual private network (VPN); and features that were deemed superfluous might quickly become necessities.

In an instant, an intranet can outgrow its current infrastructure; the important thing is to ensure that the infrastructure does not act as a barrier to future expansion. Building an extensible system and infrastructure that can adapt to rapidly changing requirements and business processes is crucial for system longevity.

Industry-standard technology

The choice of technology is vital to building an extensible intranet. While it is impossible to predict what will happen in the future of technology, we can make educated assumptions that certain technological stalwarts will stand the test of time better than some fly-by-night trends.

Because of the fast-paced ‘here today, gone tomorrow’ nature of the IT industry, it is necessary to have not only a good understanding of the technology on offer, but also a familiarity with the companies or organisations that promote them. For example, there is a far greater risk in adopting a proprietary software tool from a small, start-up company with a limited customer base as opposed to, say, a tool from an industry giant such as Microsoft or IBM.

Basing an intranet’s backbone on industry-standard technology and firmly established software (see figure 2) will provide developers and content owners with many more options in terms of:

Finding skilled personnel – standards that are promoted and accepted industry-wide attract a large following of skilled developers than niche, proprietary technologies, giving end-user companies more choice when recruiting or contracting personnel;
Developing a flexible system – using standard tools and technologies will help intranet developers avoid handcuffing themselves to more faddy proprietary technologies. When proprietary technology vendors go out of business, developers are left with orphaned tools and no means of getting the right support;
Getting support – Support, education and training for industry-standard technology is abundant, from either third-party media, such as Web forums, discussion groups, books, magazine articles – or software vendors;.

Implement a modular structure

Intranet structures often reflect an organisation’s business structure, so that users can access content and navigate the system in a manner they are accustomed to. It therefore follows that, in such cases when the organisation’s business structure changes, so must the intranet. An intranet needs to be able to accommodate the addition or the offloading of sub-sections and applications without any adverse affects on the rest of the system. A modular approach is the best way to accomplish this.

Although the key to an effective multi-disciplinary intranet is tight integration among various organisational sub-sites, integration should not mean restriction. Depending on the structure of the organisation and business, intranet owners need to determine the best way in which to structure their intranet so that new sections and applications can be added or removed with minimal reworking.

Implementing a fairly self-contained, yet still integrated, structure will provide much more flexibility. There are two different intranet structures: a modular structure organised by business unit, and a non-modular structure organised by content type.

The first structure enables any sub-site to be added or offloaded without affecting the rest of the structure, and with minimal effort. If one of the organisation’s business units were ever to be sold off to another company, that business unit’s entire intranet structure can be offloaded and given to the new owners or archived.

If the intranet were organised like the second structure, the entire tree would have to be traversed, all the content related to the departing business unit would have to be extracted, and a new structure would have to be built at its new destination.

Encourage knowledge transfer

No one person should ever be made responsible for the sum total of an intranet’s various parts. An intranet is typically developed and maintained by a group of multi-disciplinary personnel that includes information technologists, graphic designers, business analysts, and content owners and authors. All of these intranet team members work together to facilitate a centralised knowledge pool for an organisation’s user community.

But employees come and go; they leave the company, they transfer to other departments, or they are taken off the intranet team and assigned to other projects.

When intranet team members leave, however, the system must continue to operate without them. That is why no person should ever be the sole knowledge holder in any one area. Every intranet team member – be they from the technology, business, or content camps must have a ‘shadow’ or a back-up. In that way, if a key intranet team member leaves, the temporary gap they leave behind will not quickly become a gaping wound, blighting the whole project. Instead, the backup, or backups, will have the knowledge and ability to assume the responsibilities with minimal training.

This approach only works if there is a co-operative sharing of knowledge among intranet team members. Unfortunately, this does not always happen. Some employees have a natural tendency to hoard information for reasons of job security, personal gain, or to place themselves among a class of ‘informationally privileged’ employees. This is, of course, the antithesis of the co-operative spirit an intranet is meant to foster – and this is why it is so important to choose the right people to work on an intranet. If certain individuals have shown to be information hoarders in the past, it may be best not to include them in the intranet team – or at least minimise their influence and responsibilities.

Think about tomorrow today

Getting through an intranet post-mortem successfully depends on the condition of the current system and how easily it can be updated – if, of course, the system is still needed. Short-sighted intranet development that addresses only immediate needs is detrimental to the longevity of any system. When user and business demands outweigh an intranet’s ability to accommodate them, intranet team members will be forced to struggle with a system that seems to be locked in a static and inflexible state.

While intranet team members might be tempted to take shortcuts in order to get the job done, they will be creating more arduous work for themselves in the long run.It does not take a lot of additional effort to develop a flexible intranet; it just takes a bit of planning and foresight. This will open up many more options during a post-mortem review.

A bit of analytical foresight during the planning stage is a lot more productive than regretful hindsight during the post-mortem.

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

Promoting an extensible intranet infrastructure

Implement an expandable data storage system (such as disk arrays) so that capacity can be increased when necessary;
Allocate adequate bandwidth, memory and processor speed to accommodate growing user traffic, I/O intensive applications such as databases and new technologies that demand more resources;
Carefully consider system architecture such as distribution of servers and network resources;
Organise content and applications in a portable and modular structure so that individual sections can be moved in or out.