Setting the Foundation

This should really go without saying. As with any project, if you have a clear set of objectives and a clear method of achieving those objectives, then you have the foundation of being able to cost the project. This is sometimes the most difficult part for people charged with web design and implementation - they have to pit themselves against the language of accountants. These are some of the factors that you should consider. Again these are open-ended lists.

• Decide on some metrics and make sure that they are achievable within your change process. We've been suggesting pilots and bringing people on board to ease both the workload and the acceptability of the whole project to the user and developer community. From these activities you should be able to realistically estimate the effort involved and hence the labor cost of changes.

• Calculate what proportion of content duplication you could remove - the page count should drop by XXXX and hence you can quantify the effort saved in maintaining them. Your pilot should give you an indication of how much smaller your intranet may become, although you should be careful in stating that the figure was arrived at during the pilot study of such and such a site. If the site you're piloting from has used coding that does not separate content and presentation, you will probably find that intelligent use of external stylesheets will significantly reduce the size of files, hence download time, hence network pressure even if you're unable to reduce page numbers significantly.

• Do you want to win an award with your re-developed intranet? Why - is it anything unusual? If you follow the guidelines of The Plain English Campaign then it may be. Find them at http://www.plainenglish.co.uk/ and especially their web site design guidelines at http://www.plainenglish.co.uk/webdesign.html. As the objective we've already stated is to make communication as easy as possible within your organization, clarity of language will only serve to aid this requirement. The argument may be expressed that all this attention to grammar and syntax is a waste of time and that this is a modern world, so all that sort of thing is outmoded. However, if your intranet has the possibility of being international then automatic translators may be used. If the syntax and grammar is of a recognized standard then translations may be better understood.

• When you are clear about objectives go back to your stakeholders and get their buy-in, the managers, the developers, and the ambassadors. You could do this in another meeting following on from your brainstorms - with luck they'll each be able to recognize their own input into the whole process and feel more motivated to continue to assist. This meeting should really be confined to the developers and ambassadors so that from among them you can recruit supporters. Then you and these supporters can present to senior management to get their OK. This is the stage where you should get an approval to continue with the entire project.

But how you organize all this depends on your own circumstances. Above all, make your objectives clear to those who matter, then you'll get their support.

Determining the Associated Costs

When you do finally present your objectives there will always be questions about costs. If you can demonstrate cost savings then this will work in your favor, but be sure to be able to back your arguments up with calculations. If one of those people you already have 'on your side' has some experience of doing this (or is the company accountant) then run the cost saving by them before presenting. See if they can pick holes.

Here are some of the aspects you should consider:

• Even if you're not implementing a CMS there will be costs of development, of maintenance, and of infrastructure.

• There will be internal costs and a corresponding return on investment (ROI). Can you determine what this is likely to be? You'll have to take into account both the costs savings from changing and the costs of leaving thing as they are.

• There's also the time cost from internal development - when developers are doing things for the intranet they're not doing other things.

• If you can quantify any of these it will probably be easier to get budgetary approval. But you have to estimate confidence limits in your calculations and say what these are.

• One of the questions you're bound to get is "I don't see the problem, why change?"; how you deal with this is up to you. Either the person does not see the need for change because they don't use the intranet or you haven't explained the reason for change very well. Or they're just testing you.

The Costs of Not Changing

The company we mentioned earlier in the case study was faced with the need to rationalize its server base. Not only were the licensing costs about to rocket because of new licensing policies being brought in by one of the suppliers and but also because a whole raft of the security of the whole network was being called into question.

An exercise had been completed to reduce the number of servers operating under the licenses mentioned above as infrastructure servers. Parallel with this there was an exercise to see if the number of web sites could be reduced and also reduce the number of license-carrying servers that they sat on. It proved easier to reduce the number of license fee-attracting servers than the number of web sites purely because of the time and administration involved. By the time the costs had fallen the number of web sites ceased to become an issue. The only issue then was one of maintenance costs rather than tangible costs like licensing.

There were, of course, vital personnel with the necessary skills already in place in the company for this to occur and their respective managers gave them the permission to change, and the freedom to make the changes. The only criterion was - keep the thing running.

The cost savings at the time the changes were made were $600.00 per server, and five were changed from a Windows NT server to Linux server in this exercise. The company would have had to bear the additional licensing costs when they came up for renewal.

Another advantage of the change was the lack of time chasing and applying critical updates - the estimate was an hour for each of the five servers per week. Then in eighteen months there was only one security update for Apache.

The purpose of this study is to illustrate cost savings at a certain point in time. We could have gone on to reduce the number of servers to reduce the maintenance costs even further, but circumstances did not permit that. I've also put this in to illustrate how items outside straight web costs can have a significant influence on projects. Investigate other operating systems that will fit on the same hardware and how you could deploy them, as you may be pleasantly surprised by the results.

Getting the Right Infrastructure

If you are going to try to host all of the diverse variety of web sites on a single server, how is the network and machine infrastructure going to cope? You'll already have done some traffic analysis from the portal and the satellite servers, so now's the time to do the sums. Do you need to employ a load-balancing cluster, or do you just need to integrate a number of satellite web sites into one or two other servers? There are advantages to each approach and of course disadvantages. It is assumed that normal system administration functions such as backup would be implemented on all servers.

The advantages of using one large intranet server are:

• One point of administration

• Expensive hardware can be concentrated in a secure area

• Only one place to hack

And the disadvantages are:

• Single point of failure

• More server power required to host traffic

• Bandwidth can be a problem for high-usage sites

• I/O operations similarly can get choked

On the other hand the advantages of using several distributed servers are:

• Possible to arrange failover in case of faults

• Bandwidth restrictions less of a problem especially if you can locate servers on different network segments

• Can mix servers close to authoring areas - distributed administration can reduce the workload on a single person or department

And the disadvantages of this arrangement are:

• Greater administrative requirement

• Security must be applied in a number of places

Getting the Right People on Board

You won't have time to do all the changes yourself. So it's a matter of getting the people to do the changes. You could recruit more staff to your department, but that would require extra expenditure. So involve the existing designers, they've got the experience in providing the content; in fact, they probably wrote most of it. You get them on your side but you must let it be known by this that you appreciate their efforts. This is most important - you're changing their working pattern, so a little word of thanks will enthuse them to help what you're doing.

Another reason for involving the existing people who understand the content is that you don't have to learn what they've already done which is less of a learning curve for you, and because they won't need so much training the cost is going to be reduced.

You may, however, run up against the "my boss won't let me" factor. It may have been all very well putting up the web site in the first place on the departmental server, but to now lose that control is not what they'd intended. This is a symptom of what you're going to face in trying to achieve the change. However you may like to play to this by requesting that some of that web server's power be brought into the intranet - and leave the person administering more. It's all in the politics of the situation, unfortunately. It does depend on how you handle it, but doing so is not an easy job.

Here are a few points to bear in mind:

• Gaining senior management support - can you? Have you been able to prepare the ground well enough? Have you been able to get enough converts? The more the merrier in most cases.

• Bearing in mind what we've been saying about recruiting existing web site authors if you have the budget for doing so, do you have or can you get the right people in place and have the resources necessary to support them?

• If you are getting stuck, do you need an external agency to guide you through the initial stages? This may not necessarily be a commercial consultancy - try negotiating with a local university. A consultant may only try to sell you something. A university doesn't usually have any product to sell except its knowledge. Also consider whether having a university report adds or detracts from the perception of your reports internally. One caveat is the university might not necessarily have the personnel and enough experience of business to advise you correctly. Some university personnel have entered the academic environment after a period of employment within industry, so you should look at the CVs of the individuals before deciding. Employing outside people may be valuable as a way of 'seeing the wood from the trees' and getting a fresh perspective on your situation.

• Another benefit of consultants is that an intranet is often a direct representation of a company's internal politics. It's often easier for external consultants to say things that are politically sensitive, as well as bringing in fresh ideas, enthusiasm, and the befit of experience.

• Have you thought of trying to create an Intranet Renewal Steering Group to more closely focus on the issue? To make this a success you must ensure that they are supported by senior management and have both responsibility and authority to carry out the tasks assigned to them. Of course this could get out of hand and just delay things for you, but you must assess this requirement with a mind to your organizations' own policies and practices.

• You'll need to get the necessary technology on-board sooner rather than later. Build once rather than build and copy - which takes time. The engineering adage "measure twice, cut once" applies.

• What's the impact on existing web developers if you can't use them directly? They might feel threatened by the re-development, so you will need plans to deal with this type of situation, such as forming these people into small teams to get various aspects of the intranet working.

• With the new intranet you're going to create new roles of Content Publisher and Content Author. Ensure that you have some definitions so that you can define who does what.

The web is a live, modern medium. After implementation of a CMS and intranet you give publishing power to various members of staff. However the intranet you so carefully designed can become a laughing stock if you allow what happened in this case study to occur.

Restricting the Input

The question about who to trust for putting content onto the intranet CMS exercises the mind of many executives. In this case, the intranet developers were asked to provide a simple method (they did) and the management decided that it was too dangerous to allow the common software developers to post items directly onto the intranet - they may post some inflammatory or defamatory material. So the only people in a position to post material were those used to handling sensitive issue -the secretaries of the senior managers, who unfortunately were not web-oriented people. A procedure was set up such that these secretaries would be mailed the stuff you wanted put onto the CMS. So they were put on as attachments. They also put on the CMS an explanation of what was on the attachment.

But it was soon found that people were not reading the intranet. It hadn't been sold well enough. So the secretaries started sending round the document as supplied as an attachment in an e-mail to everyone.

This rather defeated the object of having a single document on the intranet. So to solve this problem, e-mails started going round saying please read the posting just made, with a link. Then it was a case of open the link, read the message, and take the necessary action. The result was double the number of links in the CMS and also a circular e-mail and a load of time wasted, all for the want of a bit of training.

This example represents, in my opinion as an intranet advocate, gross mismanagement and under-utilization of the intranet - caused by lack of trust.