Think before Acting

This could be viewed as yet another self-evident heading, but it's easier to say than live up to. Under pressure from all sorts of people you may be pressured to implement a solution. You will not be able to satisfy everyone but the more time, within reason, that you are able to consider an answer the better your solutions may become. Conversely too much time spent in thought may alienate your audience.

Create a 'Strategy' Rather Than a 'Fix'

A fix is for a one off, a strategy allows you a path of action and growth. The initial fix will of course be consistent with your strategy, won't it? If it is a fix for an unusual set of circumstances that will change then your strategy has got to say so. Any strategy you develop will be dictated by any number of circumstances, not least the performance of the company in its chosen marketplace and the general economic climate. You should be in a position to review your strategic intranet objectives with relation to the overall company objectives, performance and strategy.

• You won't solve the problem if you just tidy up what you've got. All the portal menu has done thus far is to bring any shortcomings more into the open. You'll still have the lack of standards, the different designs, the different navigation. You have to look at the content as well to determine that duplication and holes do not occur. It needs a rethink. Look at the next case study to find out how one rethink failed.

• In this process you'll have to create solid foundations for the future - and you have one chance to do it. To take something that isn't working well to convert it with a load of time and effort into something else that doesn't work well is not really an option. If this seems like stating the obvious, then it is, but it really is amazing how many organizations limp from one redesign to the next without coming up with a solution. More of the Dilbert factor, I fear, or maybe not being allowed to complete the task, or having an inadequate model to start with.

• One way to ensure that you do activate a redesign is to instigate standards for the future. If you adopt something that's going to improve the browser, Internet device, and user accessibility, you're going to have to force a redesign and not be tempted to "leave it as it is, it's OK". My own preference is to take a radical approach and remove all frames and layout tables and really separate content and presentation using XHTML 1.1 and CSS2 (or whatever are the latest standards to apply when you're reading this book) - and this will force you to redesign. If you do this then you make it easier to ensure that your designs will be current for the next generation of browsers, which are at the time of writing making the transition from version labels 6 to 7. Another advantage is that using the standards approach minimized file sizes, useful for traffic reduction on the network. You'll only want to re-engineer once. The old adage 'An ounce of prevention is worth a pound of cure' applies here as it does in all aspects of life.

• Failure to re-engineer correctly will involve you in continuing work similar to painting the Forth Bridge. Once you've finished at one end you'll start again.

• However in all this remember that you're creating a strategy. Be aware that standards change and that technological advances may occasionally outpace you. If you create a fix then you'll have run yourself into another dead end that's worse than the one you've just come from - they'll have someone to blame for this one!

• So use all the research you've gathered and collate into tangible recommendations. Make sure that you can account for all the reasons why you chose one course and not another. You'll not have to justify this all to your managers but you may well have to justify it to the ambassadors you've been preparing. If they feel alienated then you not only stand the danger of losing them but having them work against you. In this area you can't afford to be dismissive of anyone's efforts. Take a deep breath and remain calm and only swear about it while you're on your own.

• What you're doing is creating a change model at this stage of the game. You can set standards, but if you go into specific page redesign at this time you're in danger of making your model too inflexible. Retain all the options you can at this stage - as you change things because of external pressures then you want to leave yourself enough degrees of freedom.

So how do you actually make sure that you're not just creating a fix? The one question I would ask is "can changes in the company be handled without changing the model you've created with your strategy?". Play round with your model of change by looking at potential changes and how it copes. If the answer has an unreserved "yes", that is a pretty good indication that your model is going to stand up.

You're going to have to be a bit ruthless with yourself. As we've already said you can't afford to run into another dead end, so before presenting it make sure it works. Recruit some of your developers and ambassadors to assist you in this task - let them pick holes. If you've recruited them correctly then they're on your side and want to see the project succeed. In this arena people with lateral thinking skills are the most valuable, so if you can discover who these people are, and use them.

How to Alienate Your Key Workers.

This is a short tale of politics and the stifling of initiative. It comes from a company with a number of departmental and individual web sites all running successfully and all being used. One day they were noticed and came the decree from the senior management: "We are going to have to reduce the number of web sites". So everyone waited with bated breath. A meeting was convened between the person making the declaration and a number of others, none of whom had actually designed or owned the sites. Out of that meeting came the resolution that yes, there were too many web sites and one person was designated to oversee their consolidation. This person had no involvement with any of the web sites prior to this.

A year later, there were still the same number of web sites. The only difference was that before the original declaration they had been live and kept updated. After that declaration no work whatsoever was done on any site. There was an instant loss of pride and ownership because of really bad handling and a lack of understanding of what people were striving to achieve.

Eighteen months after the meeting the rationalization program had still to see the light of day. One web site had closed because the machine hosting it had failed. It was not replaced, neither was the information it contained.

And if this wasn't bad enough the developers were being asked to prove their competence by taking tests - on web site development.

Manage Expectations

It's fairly natural to want to show quick results. It's also easy to give promises under pressure that you later regret. When you've designed your strategy you can start applying specifics to see if you can build a workable initial solution.

• Manage the expectations of your colleagues, the organization's, and especially your own. Be realistic in the development plan. Make realistic demands of your own and other people's efforts - there are only a certain number of hours in the day.

• Plan to take on a pilot project to see what it looks like. Remember that the intranet is still being used. See how your pilot looks before putting anything more concrete into time-scales.

• Build the pilot if you can before saying too much publicly - test your own theories in private and make sure they will work.

• Is the pilot going to provide you with the templates or are you going to design the templates and build the pilot on them? Either way will work, but you have to be clear which way you're doing things. If you find it necessary to change a template, make sure you do it and not leave it till later - the change will get forgotten.

• Time the development - create a prototype first. Make sure that what you eventually promise has a realistic chance of working.

• Most importantly have a realistic plan - don't neglect the maintenance time for the stuff you've already built.

• Set clear goals for the intranet long-term. When these are done set the goals for this project.

• What's the business cost of not doing these changes? You should have already identified the amount of duplication and holes.

• Impress upon everyone that this is not a quick fix - it's intended to set your organization up with a strong basis for going forward for intranet development for the next X years.

• Go for the low-hanging fruit first. After the pilot, plan to tackle the obvious ones, the ones where there have been the most complaints and the most problems, but at the same time where you can be sure of success.

• Talk to others about the pilot, especially the other developers of the departmental and individual web sites, showing them what the first delivery looks like. Involving them will work wonders for acceptability and they're going to have to be your workforce if not for building, for maintenance.

• Modify the pilot as you think fit - it's only the pilot and think of it all as a phased or iterative process, with simultaneous activity streams that you manage but not necessarily execute.

• Give example time-scales - we'll achieve such and such in one year, two years. Don't be pressured and say that you'll have it done in time for Christmas.

Don't Underestimate the Human Factor

Set out to deliver a renewed intranet that will delight the people in your organization. You have a significant opportunity to touch the lives of each person inside your organization, so respect it and use it wisely. They may not realize it in those terms, but they certainly feel it even if unable to express it. You're not going to win friends for the jazzy interface, the superbly executed Flash movie - these will pall in a very short time, as will the extensive logos at the top of the page. Your users want a straightforward entry into information that takes the least time to find. That way they'll be able to add value to what they're doing as their everyday job and add value to the organization.

However be prepared for some resistance to change. In changing the intranet you may affect someone's carefully organized list of bookmarks on their browser. You can counter this by replacing every page you remove with a page directing to the new location and remind the users that they need to update the bookmarks or provide the necessary code to automatically bookmark the new page. You will also have resistance from those for whom any change is anathema.

If you've used a color scheme that's not really clear then those working under less than ideal conditions may not thank you for it. Remember also that 5% of the white male population is color-blind. Deal with it, don't ignore it. Either provide an acceptable color scheme on startup or make a stylesheet available that will change the colors for them alone on demand.

"Be prepared for some resistance to change"