It is fairly straightforward to budget for the hardware-software costs of setting up an intranet. You identify your requirements, specify a prototype, prepare a schedule of components, install the bits and pieces and then make them work. Your IT team has done it before and will do it again--that's their job--they're good at it.
However, the cost in human resources can be much harder to predict, much less specify. First, chances are that no one on your team has actually implemented an Intranet before. How many people will actually take advantage of the enhanced capabilities? Once the pieces are in place, the levels of usage and user support requirements will be hard to predict. User support can tie up the IT team for hours if the applications are complex and the users untrained.
The first step in building support for the intranet is clear and concise documentation. Documentation, at the very minimum, should contain step-by-step instructions to use the software, an easy-to-follow directory of what resources are available over the network, and a brief overview of how the system can be used in day-to-day activities. Although documentation can be online, instructions for access and trouble-shooting should be distributed in hard copy.
Training the initial set of users can also be an issue. Going on the assumption that staff are already using email and the network to access selected database assets within the organisation, staff will have to be retrained in the use of Web browsers. In some cases there will be no discernible advantage for the day-to-day user to use a browser when the current system works just fine. Convincing them that learning a new system can help them be more productive when they are already doing their jobs can be a challenge. This is where the documentation can be useful, especially if it deals with real applications.
Another issue is the actual training. Using most Web browsers is fairly simple--there are not a lot of commands or options to choose. However, finding what you are looking for is the issue. So a robust directory/indexing mechanism must be implemented in parallel with any sort of corporate intranet. And this as well needs to be documented and transferred to the end users.
One of the selling points of intranets is that they can be used to access a wide variety of internal documentation. However, even with many of the on-the-fly HTML translation software programs, a certain amount of hand-editing is required to build legible documents. For a large organisation, conversion can eat up a lot of human resource. You can count on it.
One way to streamline the implementation effort is to poll users before the fact to get their input on what how they would like the final product to look. This is a relatively small investment in time but can pay for itself many times over after the system is in place.
Building an intranet is like any other IT initiative. It means, however, a major change in the way users can interact with the organisational information resource. Understanding user requirements and building the system to respond to their needs will go a long way in reducing the costs associated with staff acceptance.