Printer Friendly Version

In a similar, albeit less dramatic, vein to Hamlet's famous "To be, or not to be" soliloquy, we, as intranet professionals, suffer from the same type of existential angst: How do we justify our, and our system's, existence to management? Not only do we face the challenges of convincing them of the benefits of developing an intranet in the first place, but we also have to convince them of the necessity of maintaining it after we do develop one.

The main problem stems from the fact that intranets are more than mere applications. An intranet is a community — made up of technology and personnel — that represents and supports an organization's collective knowledge and culture. And as such, the benefits of an intranet are not always apparent. Perhaps they're taken for granted as normal part of day-to-day operation; only in its absence will we truly discover the worth of an intranet.

So how do we justify an ongoing commitment to a system with largely intangible benefits?

Understanding the Differences

The majority of corporate IT systems we have today are relatively low maintenance once they reach the post-production stage. You build (or buy) an IT solution, implement it to work withing your environment, and then leave it alone. They will, of course, need the occasional tweak, patch, or upgrade but these can be automated to run with minimal human intervention.

An intranet, on the other hand, requires a much larger commitment even — or especially — after the initial stages of development. Rather than a single up-front investment of time, effort, and money, intranets — depending on their size and purpose — may require an investment over a much longer period of time. And because of this long-term commitment, it can be difficult to get management on board with this project.

Before I begin discussing the issue of justification, you need to understand how an intranet differs from many other IT implementations:

• They're often implemented to solve a general corporate requirement — knowledge sharing, online collaboration, content management — rather than a specific business-process-oriented goal such as ERP and CAD, or a preventative measure such as corporate anti-virus/anti-spyware tools.

• Investment — mostly in the form of time and manpower — extends beyond initial development and lasts for the life of the system. Intranets are an ongoing initiative and must be treated like the running of a daily publication.

• The core benefits of an intranet come in the form of soft returns that are often difficult to quantify with a traditional dollar value.

• Justification for the system often needs to be made both during pre-production (i.e., system development) as well as post-production (i.e., content management)

Pre-Production Justification

When trying to justify the need for an intranet to senior level management, it's vital to have the support of your colleagues as well as your immediate superiors who can champion the cause higher up in the corporate ladder — there's strength in numbers. When there's solidarity among those involved in the project, the system will be viewed upon with a lot more credibility and not just some small special interest group looking for something to keep themselves busy.

Senior management is rarely happy to see project proposals that replace existing processes. This is a common reaction associated with the "If it ain't broke, don't fix it" mentality. The justification for the development of an intranet must be based on a substantial improvement or addition to current business processes, not a mere replacement. Using an intranet to replace the traffic of paper and electronic documents constantly flowing from department to department is a good sell; replacing a recently purchased CMS application with an in-house intranet is not.

While senior management is accustomed to reviewing new project proposals by way of a business case — an executive summary detailing the system, its objectives, its benefits, and its cost — a more valuable tool exists: a pilot project.

A pilot project allows senior management to kick the tires of a small-scale working model with little-to-no initial investment or commitment. Pilots usually contain only a fraction of the potential system's functionality, but enough to give testers a practical overview at what can be accomplished.

Pilots can also be used within a control group over a period of time to gather feedback on the system, which can in turn be used as real-world testimonials towards the justification of the project. Positive user feedback on how the system can make their daily operations easier is worth more than a hundred business cases.