Plan the Work, then Work the Plan.

Like any endeavor, the key to a successful journey is to plan ahead of time. In the following pages, we will discuss the roles of each member of your intranet development team, problems they may encounter, and strategies to keep development going.

What Information Should Go on the Intranet?

The content contributors provide the keystone of a successful intranet: the content. As simple as the content contributor's task sounds, it is the most time-consuming and important task of all the intranet development team. They must coordinate with both the managers and the end-users to determine what needs to be placed on the intranet and when.

Will your organization's intranet be used solely as a clearing house for brochure content? Brochure content consists of non-interactive content, such as commonly used forms, manuals, and policy guides. Though this information is valuable to the enduser, and a good way to populate the intranet with content, it does not really give them a reason to visit the intranet on a regular basis. Users, in this instance, will only visit the intranet when they need to fill out a form, or consult one of the policy guides.

Basic Services

As we mentioned before, there are some basic services an intranet is almost expected to have by its users. This includes (but by no means is limited to):

• Basic forms, such as expense reports, medical claim forms, and timesheets.

• An internal contact database, listing employees' names, extensions, and e-mail addresses.

• Quick company facts. The intranet at one organization has a "Who do I speak to about...?" section, which serves as an invaluable resource for new employees trying to find information.

• Company News. This could be as simple as a weekly listing of happenings throughout the company, given to you by the HR department. You can extend this by allowing employees within your organization to submit news items.

These basic services do not necessarily require much development time to put in place, since they mostly rely on static content (with the exception of the contact database). A rudimentary content management system (CMS) can help to make maintenance of this information relatively painless.

If you are putting a security model into place on your intranet, you can combine the user database for authentication with the user database for the contact list. When you create the user database, simply add fields for information you want to view in the contact database: full name, e-mail address, phone extension, and even their place on the seating plan if one exists.

Interactive Content

A good way to extend the basic content of the brochure-ware site is to replace some of the non-interactive content with interactive alternatives. Do your salespeople need to use an expense form on a regular basis? Replace the expense form on the intranet with an interactive one. You increase your sales team's productivity by reducing the time it takes to complete the form, and you also tie them into using the intranet on a regular basis. Once you hook the employees, they will start to explore the intranet to see what other benefits it offers.

The above example brings forth a very good question: should you tie the employee's job to the intranet? It is a two-edged sword. On the one hand, it ensures you get your ROI by forcing people to use the intranet to function within the company. On the other, it can backfire if you do not tie it seamlessly into their regular work routine. Endusers will either love you for it, or rue your very existence.

If you can develop a "killer application", which makes the end-user actually enjoy their intranet experience, you will have a much happier user-base. We will discuss the "killer app" - and the forms it can take - later in this chapter.

"Once you hook the employees, they will start to explore the intranet to see what other benefits it offers."

Department-Specific Information.

Does a department share a large amount of information among its members? Do members of a department need to collaborate and discuss details of their projects? Placing department-specific information such as project budgets, functional specifications, or even a message board on the intranet can provide a valuable service. No longer do members of the same department have to hold large, sprawling conversations through e-mail; they can now collaborate using a single, central, public resource.

Department-specific information can also be contained, by only making it available to users within the department. This takes sophisticated user management, however, which we will discuss in Chapters 5 and 10.

What Information is Critical to the Intranet's Success?

Most endusers have some fixed expectations when it comes to information on the intranet. The first of these is contact information. In a large organization especially, tracking people down can be a difficult exercise at best. By providing your intranet users with a (preferably searchable) contact list, you provide them with a service they expect, and make their lives a little easier in the process. You can also plan to expand the basic functionality of an internal contact list by allowing users to create their own contact lists, and share them between other members of your organization. In this way, members of your sales group can share contact information, and even add notes to each contact.

In addition to a contact list, common forms are another resource endusers expect to find on an intranet: expense reports, medical forms, product and policy documentation, and the like. The last thing people in your organization want to do is hunt down forms they need on a daily basis. By placing these on the intranet, you provide them with a central resource. As mentioned above, you can even convert these to interactive forms; this gives you control over their distribution as well, allowing you to make changes without having to worry whether they're working off the intranet version, or a local copy on their hard drive.

Other Considerations

Eventually, you are going to come across a situation where you want to share information with some endusers and not others. An example of this would be a functional design specification (usually referred to as a funcspec) for your development team. You will want to start gathering your content and endusers and matching them up in groups.

Another consideration to keep in mind for the development process is approval time. Content may need approval by senior management before placing it on the intranet. Add a little extra time on to your development schedule to account for approval delays, or try to get content pre-approved. Also add development time if you need to rely on other individuals within the organization for content. These individuals may not share the same enthusiasm about developing the intranet as you do.

The final consideration for a content contributor is whether other employees within your organization can submit content for inclusion in the intranet. People are already talking within your organization, whether it is through ad-hoc mailing lists, e-mail, or their own internal web servers, creating a primitive, uncontrolled intranet. By giving them a central, authorized place to hold these discussions, you give them a true voice within your organization. A good source of information on this is the Cluetrain Manifesto, which can be found online at http://www.cluetrain.com.

Setting Priority

Once you have determined what information should be included with the intranet, you need to determine a level of priority for each desired component. This will be revealed, at least partially, by the stakeholder interviews you carried out earlier. Common trends will begin to emerge when you analyze the responses. Users may feel that filling out forms online would increase their productivity. Likewise, they may feel that simply having the information available in a central location is enough.

The nice thing about setting priorities is you can stagger the development of content, delaying the development of less important content until after the initial release. Once you have decided what is being included on the intranet and when, the developer and designer can start their work.

Developing the Intranet's Content

The developer and the designer work hand-in-hand while developing the intranet; the developer works on the back end and content delivery systems, and other information-managing systems, while the designer works with both the developer and the content creators to determine what is the most effective and usable way to present the content to the enduser. The developer will need to know some basic information before working on the content delivery systems:

Intranet Content

If the intranet is merely a brochure content site, your developer's task is really quite simple. They merely need to coordinate with the designer to ensure the information is laid out in a logical fashion. Brochure content should be organized in the same way as the company. For example, all HR documents should be placed in an 'HR' section; all product documentation should be in a 'support' section, and so on. For a brochure content site, this makes a fair amount of logical sense.

If the site contains interactive content, this may or may not be possible however. In this event, you will want to organize the content in a more natural manner; perhaps having an 'online forms' section, which is then broken down by department along with a 'documentation' section, again broken down by department. Usability techniques will be discussed in more detail in Chapter 6.

Content Contribution

Do the content contributors need an administrative portal to manage the content? The chances are good that the answer to this question is a 'yes'. Content management systems (CMS) greatly increase the productivity of the Content Contributors. Instead of spending their time messing about with HTML, scripting, file placement, and other mundane technical tasks, the Content Contributors can simply select the area of the site they want to edit and paste text into a text field.

This does pose a problem for the developer, however, as it adds much more development time onto the schedule to either install and configure or develop a CMS. In addition, the developer will need to know how complex a workflow the CMS will need to have. Do the Content Contributors want several users to be able to post information to the intranet? If so, they may want the ability to approve or reject submissions before they are made public. We will see more on CMS in Chapter 8.

Security

Another consideration at this stage is security. Will information placed on the intranet be sensitive to specific groups within the organization? If so, the developer will have to plan for a security model, using either a form of network authentication, or an authentication method specific to the intranet. It is important that you are aware of these considerations now, as it is easier to build them in from the start, than retrofit them later.

If possible, it's best to use a network-based authentication method, such as LDAP or Active Directory to automatically authenticate users on the intranet. For more on security, see Chapter 10

Plan for the Future.

Though you may have the world's best plan for rolling out your intranet, it will be a dismal failure if you haven't planned what happens after its launch. The best time to make plans for the future is during this initial planning process. Things you should plan for include:

• Updating content. Who will be updating the content after the intranet's initial release? Will they also be responsible for maintaining it? It is useful to set up a single content editor, who takes information from each department within the organization and coordinates it for placement on the intranet. In turn, these departmental sources would gather and coordinate information inside of each department. It may seem hierarchical, but it will be an excellent filtering method to ensure that only important, useful information is posted to the Intranet.

• Future Development. Unless your developer is a programming deity, the chances of launching your intranet with all the features your users would like to see are slim. Plan out a release schedule for features on your Intranet.

• Hardware and software upgrades. What is the life cycle of your intranet's hardware? How often will software patches and service packs need to be applied to the server? Coordinate with the IT department to get the answers to these questions, and work out a maintenance schedule.

Build it, and they Will Come.

In an ideal world, you would generally have 6 to 12 months to design, develop, and test a usable intranet that answers everybody's needs. You and I both know that the real world is much different; there is a much better chance you'll have to develop it within 2 to 3 months, concurrent with other major projects. This means some sacrifices have to be made.

First, forget adding every feature requested by your stakeholders into the intranet; there just isn't enough time. Look through the interviews and the collaborative discussions to pin down commonly requested features, or common weaknesses in the current methods of communication. It is better to roll out the core functionality quickly, and then leave extras for later iterations.

"It is better to roll out the core functionality quickly, and then leave extras for later iterations."

• Do most of the departments complain about a lack of communication? Make it easy for users of the intranet to talk to each other. This could mean forum software, the ability to make comments on content within the intranet, or even an intranet messaging service.

• Do people complain files are hard to find? Spend time developing the site structure, and develop an advanced search application on the intranet.

"Killer Apps"

I think it's best to take a moment here and tell you what most intranet developers have to learn the hard way: At some point during the development of the intranet, somebody will ask, "So how are we going to get people to use this thing?"

The answer seems simple at first: "Have a killer application."

If you want people to use the intranet you are about to spend so much time developing, you need to give them a very good reason to use it. Unless the intranet provides something that makes the users' lives seem so wonderful and complete when they're using it regularly, it just won't be successful. This is where the "killer app" comes in. The killer application not only brings the users to the Intranet; it brings them back.

"The killer app not only brings the users to the Intranet; it brings them back."

The answer seems much less simple when you actually have to figure out what that "killer app" is. It could be as simple as a way for salespeople to make feature requests to the developers, or as advanced as a complete system to track customer relations and support issues. Your stakeholder interviews will be valuable here; they can be used to identify trends in commonly requested features.

The easy way out is to ensure the intranet plays a part in their day-to-day life as an employee. This can be relatively easy for development and QA staff, by including something like a bug-tracking database. For sales staff, building a Customer Relations Manager would be an excellent option.

So, you know you need a killer application to bring users back to the Intranet. But what is it? What your particular killer application will end up being depends on what your stakeholder interviews and functional needs assessment hold within them.

Some of the best killer applications are the most basic. Take, for example, a software company I used to work with. The killer application in their case was an off-the-shelf open source bug-tracking suite. Since the company was entering a long research and development process, a system that allowed developers and QA testers to collaborate on software development was a perfect addition to the organization.

It allowed the QA team to effectively communicate potential problems to the development team, without clogging up the e-mail server with messages that might be forgotten or ignored by the developers. It also gave management a way to track the developer's progress without hovering over and watching their every move.

For a sales-driven organization, a solid Customer Relations Management (CRM) system might be the killer application you need to hook them into the intranet. A good CRM can be integrated with a support database, to provide both salespeople and product managers with valuable information about product trends.

Your killer app will be specific to your organization, it could even be as basic as a searchable contact database, with pictures and a dynamic seating plan. The key to finding your killer application is asking the questions: "What will bring users to the Intranet?" and "what will keep them there?".

"The key to finding your killer application is asking the questions: "What will bring users to the Intranet?" and "what will keep them there?"

Scheduling

Now you have a basic plan in place for the intranet, an idea for a "killer app", and a basic idea of who is doing what. Do not plan to start everybody off at once; your developer and designer will only be spinning their wheels until they know what they are dealing with for content. If all your development team members start working, the disastrous will happen: your developer will start building a database that isn't scalable to the variety of information the content contributors need to classify; the designer will come up with a visually beautiful, yet functionally vacant design for the intranet; finally, the Management will look at the entire mess, and decide that it is just not worth the trouble to follow through.

Instead, plot each intranet team member's schedules on a graph; MS Project and Outlook are very useful Windows tools for this task. Linux users can install the above tools using Crossover Office (http://www.codeweavers.com/products/office/), or can turn to an open source solution, such as Evolution (http://www.ximian.com/products/evolution/). Any of the above tools will help you to better visualize how the different team members interact; you can see a sample in the diagram to follow.

Something to keep in mind is that not all members of your intranet team are going to start working on the intranet immediately. Some processes cannot be started until others are well under way, or even complete. For example, the developer cannot create the database until they know what information it has to contain. Likewise, your designer cannot display information if there is no content to pull out of the database.

Ask your developer and designer to give you an estimate on their part of the intranet. Things to consider are:

• How dependent on the content are they?

• Can they work off a basic outline and refine from there?

• How long will it take the designers to come up with a usable look and feel for the intranet?

• How much can they work on without content? How much artwork needs to be created by them?

• If the developer is installing an out of the box solution, how long will it take to configure and customize?

That's not to say that each member of the intranet team has to wait until the other is done before proceeding, however. Tasks can - and should - overlap each other, as seen in the following diagram. In this way, information can pass both up and down the development team. This will also help you to avoid costly delays, by having all members in full communication with each other.

Ensure there is a high level of conversation between the various people on your development team. Things will change once development starts; a high level of communication between members of your development team (and between the development team and the stakeholders) will help to reduce any delays that occur.

Nothing is better for stable development than lots of conversation between the people developing it. Create a temporary forum on an internal web server, or ask your IT department to set up an internal mailing list for the members of the intranet development team.

Your intranet is all about getting people to communicate with each other; it seems fitting that you should place communication among your development team as a high priority as well.