Transition Strategies

Whatever you hope, any transition from distributed web servers to a more centralized system is going to be aiming at a moving target. During the period of time that you've allocated for the transferal task, web site content, people, and company policy may well change. It would be difficult to envisage a company where this didn't happen. So any strategy you choose must obviously be flexible enough to cope. It would be sensible to write into your strategy a means of reviewing the strategy as time goes by - a regular self-examination. In this way the nasty surprise element is, while not being eliminated, at least somewhat controlled. It also provides for avenues for feedback from the users to enable that feedback to be incorporated into the revised strategy.

Revising any strategy for change is another iterative process, but with the added benefit of fitting your revisions to a moving target (or should that be challenge). The balance is very hard to achieve and will undoubtedly give you headaches. How you go about this obviously depends on your own organization's situation, but in general your initial plan should have taken this into account, as we've already mentioned. Your own flexibility will both be needed and be called into question: it will be needed for the adaptation to take place and will be called into question. Those questioning your changes will often be senior managers who were 'sold' on the initial plan and think that since it's been agreed by them, the plan is immutable. Employ your caveats when you initially present carefully and with sufficient inbuilt leeway to cope - easier said than done.

We all know how sudden global changes can greatly influence economic activity and confidence. Although you cannot hope to build this type of change into your plan a regular review schedule will assist you to cope. And once you have a review schedule, stick to it and don't let it slip - even if you conduct the review and see that there's nothing to change. That way you have a positive plan instead of something less so.

So one of the words you should be considering when designing your plan is flexibility. However there is a world of difference between flexibility and woolliness, or fudge. Unless the published plan is couched in terms of some positive action with a schedule, then any holes and uncertainty will be quickly seen by your audience and you'll not be off to a very good start. As we mentioned a couple of paragraphs ago, the nature of the moving target that is your grand plan will also influence the type of action that you can take. But action is required and hopefully your grand plan will not be too much off course.

Note

You'll also no doubt have heard of Buzzword Bingo, the game played by people who have had just about enough of corporate marketing speak at company meetings, marking the words used on a score card. Some readers of this book will have played this game (guilty) in order to stay awake during some of these events. If you have heard of this, then the people of your target audience for your plan have undoubtedly heard of it as well. So keep the plan positive but be prepared to change through regular reviews. And say that there will be a review process when you publish the plan.

So what actually makes an effective transition strategy? My answer is controlled flexibility. The ability of the system you design to adapt to and adopt changes that are inevitably going to be forced on you. And if you get questions like "when's it going to stop changing?" or "when's it going to be finished?" the truthful and possibly reasonably effective answer you can give is "when the company stops changing". And if the company stops changing and does not react to current conditions that's the time the company stagnates and contracts, maybe to a point where the point of the intranet is not necessary because there are too few people to use it.

The bleak prognosis at the end of the previous paragraph is all too common, but if you see your intranet as a way of maintaining the vitality of the company then you may well be an agent for positive change - proactive rather then reactive. The difficult thing is to keep the balance and that unfortunately is beyond the scope of this book - you are the one who has to have the vision - all this book can do is guide.

Navigation Development

The navigation from your main start page will either make or break the intranet. If users can find what they want quickly and easily using obvious links, then you have the makings of a success on your hands, otherwise success will be more difficult to obtain. If you are using the initial model we discussed in earlier, navigation will be a problem in that it will not be consistent. If you are completely restructuring the intranet architecture then you are more in control of the navigation style. The navigation style would have been presented and agreed upon when you obtained buy-in from your stakeholders, so you have the framework. Developing this into a practical navigation system needs thought and you may have to make minor design changes, but major changes to the navigation structure, however easy that is to achieve in your programs, will put users off as they will have a stylistic sea-change to assimilate. So carefully think through if there is any real benefit to such a change, and be aware that even though your navigation system is less than perfect, it's consistent and the users are familiar with it.

If, of course, you have managed to follow web standards and separated content and presentation with external stylesheets, whether CSS or XSLT, then changing your structure is more simple and you can provide users with a choice by giving them access to different stylesheets. For an example of this see the homepage of the expert in this field, Eric Meyer, Standards evangelist for Netscape, at http://meyerweb.com. His stylesheets are selectable from his page, and as long as you're using a browser that recognizes standards you'll be able to vary the look and feel of the page, including the positioning of the page elements.

You can also put considerable barriers in the way of easy access to information by asking your users to log on before each use. Security of your intranet is important, but consider whether putting a logon screen in front of everyone who tries to use your intranet to find a phone number is really efficient. Sure you have to protect sensitive and private information (like personnel details), but the point at which you ask for the authentication can be vital. It can speed up or slow down your user's experience and create annoyance at delays in getting into the system. You could also consider the use of cookies - but this may be counter-productive if you have screens in public areas - if your last logon was from an administrator then there's a danger that the cookie will grant the next person the same access rights. Think carefully how you want information to be used or secured.

If you have a firewall-protected network with only employees able to access machines inside the network, and maybe VPN contact from your sales force and home workers, then when they log onto the network will this give sufficient information protection? Consider the areas you want to protect from every user access: individual personnel files, intranet administration, or departmental staff planning. Then let everyone have access to all other groups. Let's just construct a sample intranet with these groups and a few more:

If we consider the frequency that several of these areas of your intranet will be accessed, then it's fairly obvious that the restricted areas will be accessed less frequently than others. So putting an access restriction at the front end of the intranet will just waste time, even though you are able to arrange a single sign-on. Just put the restriction where it's going to be needed. It's also going to be easier to resist the idea of cookies being used to hold passwords if you can do this. If you force everyone to sign on every time, you will be pressurized to use cookies to remember passwords. This is exactly what you should avoid, especially for parts of the intranet containing sensitive data where users should have to log in every time.

Back now to navigation. After entering the system you are usually presented with a global menu. How this is presented is important as well. You have to start designing this with your users' needs in mind rather than any organizational convenience. The language must be simple and straightforward and use terms that are understood generally. It's a good idea to avoid acronyms, as then you'd have to provide a dictionary for users unfamiliar with the company structure. To illustrate, a couple of samples. First a silo menu, organized on departmental lines, and then a user-oriented menu organized on logical lines for ease of use.

The menu is organized according to departmental constraints - some of the functions are obscure and the language used is corporate-speak rather than English. Compare this with a very similar menu organized along functional lines and using plain English. The same information is conveyed, but with language that normal people use. The structure is not that different, except that Development Opportunities becomes Job Vacancies, and that International and Sales have reorganized themselves along more logical lines. Titles have been reworded to sound less corporate and more understandable.

New User Requirements

So let's look at this in a little more detail. As the intranet develops it's going to be more and better used. As it becomes better used, new and modified user requirements will be raised. The fact that more people can see more of the content means that there will be better awareness of the potential of the intranet, so user expectations and requirements change accordingly. You have a duty to be aware of those expectations (you will be, if you've put the correct feedback solutions in place) and modify your own plans and designs accordingly. Again we mention that radical change of design halfway through will tend to alienate your user base so it is best avoided, unless there is a compelling reason to do so. However design adjustments can be dealt with. And if you do make design adjustments it would be a good time to publicize the intranet to your staff members by the same type of e-mail circulation that you used to launch the new intranet in the first place. This way it keeps the user community aware that you're still alive and functioning.

A bit of research is called for here before you make wholesale changes - use your ambassadors as a test bed, it'll keep them involved with the intranet. You can't rely on previous traffic figures because some important piece of information may have been hidden, and you will almost certainly have provided new facilities within your redesign. So you have to look afresh at traffic figures.

Thus far we've talked about changes to the intranet as redeveloped. In this whole process you need to consider the users of the existing microsites and how they have been finding information on their own site. Incorporating them into the general structure can be problematic - especially if you break up the navigation too much. If you can keep the same groupings then all will be well, but this will not be possible if you have significant duplication of information that you can usefully prune. You won't be able to please everyone, so it'll be up to you to explain your actions in one of your launch e-mails. Asking for feedback and review will assist in the adoption of your standards. From experience many objections are raised for the sake of raising objections even though there are benefits to be had from the modifications. The majority of users will see your reasons and accept them, as long as they're well-considered and well-argued.

One of the common menu structures on any intranet is the silo route. This places all access menus in the same structure as the organizational structure of the company, so from a user's perspective this demands that they know the organizational structure before they are even able to access information!

Silo Menus

So there was a big company meeting - posh hotel, free lunch, free drinks - a new MD had been appointed six months beforehand and he'd been the new broom, the product line had been re-launched and new revitalized budgets and presentations were seeing the light of day for the first time. Some people who used to be there six months ago were no longer there. There was an air of expectancy.

Near the end of the proceedings the person in charge of Human Resources steps up. He presented his bit of the change process, the new Personal Development scheme. Using this we could develop our careers within the company, the sky being our limit. One of the questions from the floor was about training policy and courses. And we got told that this information was available from the company intranet.

Next day, still enthused, back at the office a few of us tried to find mention of training on the company intranet. It took some time. It was hidden in a silo. We all thought that training was pretty important to the company, and should really smack you in the eyes, However the people who designed the intranet menu system didn't see things from our perspective. To find information about training you had both to identify the jargon used and jump through five hoops:

• Human Resources

• Personal Development

• Education

• Training

• Training courses

A few months later, when a couple of us were running internal weekly training courses, the menu item was still the same and we had to use other methods of publicizing. It wasn't anything to do with the developers being unapproachable, they didn't ask the questions and there weren't facilities in place for user-feedback.

So you have a difficult task. What you do first time out will be wrong. When you change it that'll be wrong as well because some users will have become used to the menu hierarchy you defined previously. And if you then change it back that'll be wrong because you're changing it too often. So any menu hierarchy must be user needs-driven, remembering that 100% happiness is unachievable - there will always be compromises, even in your own designs and ideas.

Note

You may find it more convenient to have your menu structure follow the directory structure of the web site. It might be worth considering designing the directory structure alongside or a little after the menu structure. At least the directory structure should be designed for change and not fixed.

Here are some things to bear in mind when re-designing the navigation:

• To overcome the silo your structure should be needs-based

• Your menu structure should do what it says

• Try to make your access hierarchy needs-based

• Get your ambassadors and developers involved by asking them how the menu hierarchy should work and get them to ask their local users

• Call an ambassadors meeting and come up at that meeting with a first menu structure

• Have a real, not fictional, pilot site

• Put a feedback mechanism in place so that you can get comments

Your structure should be needs-based organized by subject, task, and activity. This should get over the silo effect. You should by this time have defined in your own mind what's in the sites you're bringing into the intranet so classifying them should not be too difficult. However in making the classification you have to perform some lateral thinking. You may have a product site designed by a product division and they're going to hand it all over. So it'll go in under the product category of your new system. But the content of the site is actually about the technical details of product installation. People wanting to know about the product are going to be bamboozled, and installers are not going to be able to get their information where they expect it to be.

"Does exactly what it says on the tin" is an advertising slogan used in the UK for the 'Ronseal' wood preservative range. If you can make your hierarchy do just that, having sensible headings in plain language avoiding jargon then you're well on the way to succeeding. Clever menu headings do no one any good. If you mean "training" say "training" and not "personal development". If you mean "self study" say so and not "personal self-development".

Try to make your access hierarchy needs-based. The silo case study above was a case in point of how not to do it. But how do you find out what your users need? This is one way that starts with a top-down design. Get your ambassadors and developers involved by asking them how the menu hierarchy should work and get them to ask their local users. But don't give them very long to do it - you need to retain momentum. You'll now have defined in your own mind that the developer and ambassadors groups have now become one, so we'll deal with them as one group from here on in. If they want, provide them with a simple outline menu to get them started and put what you think are going to be the most frequently used items at the top, and ask them to do the same when they make their suggestions. Then call an ambassadors meeting and come up at that meeting with a first menu structure. Implement it. That'll give you an important advantage in future dealings with the ambassadors group. You could also create an "Intranet Ambassadors" e-mail group.

You will have pilot sites. If they are completely fictional then effort will have been expended into something that's not going to continue. Try to pilot on a real site that you want to have as part of the final intranet. If you use a site that's already on the intranet then you'll give yourself an easier job. But if you use a site from one of the satellites then you'll be testing yourselves in a real-world situation. This has the psychological advantage of involving the people you want and testing the effectiveness of your transition strategy.

Put a feedback mechanism in place so that you can get comments. If you use e-mail feedback, respond to all those comments with at least an acknowledgment at first - but don't make it automated. You could operate a feedback forum and have the comments on display. You'll have to make sure all comments are attributable otherwise you won't be able to get back to the people who have given the feedback. But having attracted the feedback, don't change things round too often, you'll only confuse your users. You could consider publishing a schedule against which you'll make changes so that there is a warning. That also looks like good planning.

Handling New Microsites

This is almost a section that could be entitled "How to prevent this happening again". Naturally as your intranet develops you will find it expanding and you will have new sites and possibly microsites to plan. Would you consider an embargo on new sites? If so, you'll have your development smoothed but at the risk of annoying some staff. You'll have to set priorities for development. You could do this by writing into the review process a provision for changing the priorities for handling new sites. How you do all this will be dictated by your own organization's circumstances, and the urgency with which the request for a new site is needed, and probably by whom. The only thing you can do is plan to recognize for when you spot this happening. Really the worst thing you can do is stifle initiative, you'll force people out of the company and those are the ones you want to keep. So if you can design an iterative process and keep reviewing the situation then you'll stand more chance of maintaining control of the situation.

"The worst thing you can do is stifle initiative, you'll force people out of the company and those are the ones you want to keep"

Whether new sites are hosted on your main servers or on a satellite is up to you. Whatever method is adopted you should ensure that they conform to the standards you've declared. Elsewhere in this book there has been talk of templates, whether for use with CMS or for 'normal' web pages. This is the perfect time to introduce them for your site. Some of the common tools, DreamWeaver, for example, allow the creation of templates for use, but wholesale introduction of this technology across the company could be expensive. If people still hand-code web pages, as many do, then an outline code would be just as well understood and probably more effective. If you have chosen to adopt separate external CSS stylesheets then the imposition of templates and styles become easier. A little training for your people will allow them to construct pages to our declared style with little hassle.

One way of doing this is to set up a "Center of Excellence" where the principles of creating sites are laid down with examples to follow.

Active Server Pages error 'ASP 0113'

Script timed out

/viewer_r.asp

The ma