XML and Databases

An intranet doesn't have to use XML or databases of any kind. Every page can be static HTML with hard-coded content, format, and function - although the amount of functionality that will be available to static HTML pages will be quite limited.

The reason why XML or databases should be used in the implementation of your intranet is because they allow for the simple separation of content from format and functionality. This makes long-term maintenance of the intranet more efficient (thus less expensive). It also allows you to retain the value of your content because it will be easily reusable in other formats (wireless phones, PDAs, WebTV, etc.) and delivery channels can be created quite quickly.

A database should be used to store your data. This will likely be what the back-end of your CMS reads from and writes to. Also, any information from the functional components hosted on your own server will likely be tracked here.

XML comes into the picture when data needs to be transferred from one server to another (this is because transferring entire databases can be prohibitive due to their size). Depending on what system your IT department puts in place for your intranet, you may need to use XML to transfer information between servers.

Personalization

As stated previously, personalization is impossible without some level of security. This is because access to private information that you are likely to find in a personalized intranet needs to be restricted to only that user. There are many corporate policies and laws in some jurisdictions to this effect.

Very simple personalization such as a "Good morning Gwyneth" prompt, user defined color scheme, or itemized layout selections can be selected in forms and saved in cookies on users' machines, but this approach isn't recommended. The preference settings will not be transferable to other computers the user might move to. And extending the personalization to include personal information at a later date will necessitate taking one step backwards before taking a step forwards.

Practical, intelligent personalization involves authenticating users and then tracking their user sessions with either session variables (a relationship between the web server and a user's web browser) or token variables (a unique identifier which is passed as a string in the URL of all the intranet pages). Note that the latter method is less secure than the former.

Once you've authenticated a user and started to track them, you can display any personalized content to them that you (or they) might want. All you need to do is define what content and function pages should be personalized, and then make sure that information is detailed in the Project Scope Document.

See Chapter 10 for more information on Personalization.

The Production Process

There are many resources in print and online that provide information on project management techniques for planning, building, and deploying technology solutions. Also, there are globally recognized methodologies you can study and receive accreditations for. The two most common of these are the Microsoft Solutions Framework (MSF - http://www.microsoft.com/business/services/framework.asp) and the Project Management Institute (PMI - http://www.pmi.org) certifications. These courses and resources can provide you with an extensive degree of information and techniques not covered in this chapter.

Note

What this chapter will do for you is provide you with a solid roadmap to follow when you become responsible for planning, building, and deploying a corporate intranet. There are 20 steps listed in the following sections, and each one of them is important. Try to provide an output at each step for documentation and meetings.

Step 1: Conduct Needs Analysis

Do you know why you're building an intranet? Is it meant to solve problems, improve efficiency, or just to bring your organization into the 21st century? Or are you just setting out to improve the existing intranet that your company's Vice-President's best friend's nephew designed in 1997? All of these are legitimate reasons, but you need a breadth and depth of understanding with respect to all issues before you can go any further.

"Make sure to solicit feedback from the people who will use the intranet to increase the likelihood that it will provide them with utility"

Assess the current site (if it exists) and understand where it is hosted, who was originally responsible for creating it, what the history of the site is and who is currently responsible for maintaining it. Create a site map at this time so you're clear about how everything works (and you can refer to it when you're creating the new one).

Consider preparing a survey for all stakeholders that solicits their opinions on content, functionality, and design (including usability issues). Get feedback on current intranet (if it exists) as well as identifying "Needs" for the new intranet. Remember that the intranet should be for employees, and for making their work lives easier; it's not exclusively for managers of various departments and lines of business. Make sure to solicit feedback from the people who will use the intranet to increase the likelihood that it will be useful to them.

Aggregate all the information gathered during the Needs Analysis and prepare a document that states the particulars of the current site situation and what needs have been identified for the new site.

Step 2: Prepare Project Scope Document

Using the document you created during your needs analysis, create a detailed plan for what types of content and functionality will be included in the new intranet and how it will be organized. Each type of content and specific functionality should be described in as much detail as possible. If some fine points aren't available or decided upon, they should be noted so they can be reviewed, discussed, and settled during the scope document approval process.

As well as your written descriptions, it is recommended that you include an illustrated site map in your scope document. It should depict the hierarchy of information in the new intranet and allow people studying it to visualize what the user experience will be from a pure information-flow perspective. If you're not an artist and have access to a digital production artist, give them a roughly drawn sketch with specific details and have them create something slick and compelling (note that including basic symbols and a legend always goes over well with visually-oriented people). If you're going to produce it yourself and you're not an artist, then keep it simple and straightforward.

Once you know what you intend to do and how it will be done, it is important to determine: what resources are likely to be available for this project (technical personnel, non-technical personnel, and funds); what the development approach will be; where the site will be hosted; and what degree of personalization and security will be required. This information is necessary for determining scheduling and costs.

Ask each resource how much time will be required to complete their various aspects of the development process, and then double their estimate before including it in your schedule. This might seem excessive to someone who hasn't worked on projects like this before, but it is an unfortunate reality that almost all initial estimates by qualified, experienced professionals working on web-based projects fall short by approximately 50%. In cases where a "buffer zone" of 100% is not added to original time estimates and a deadline is inflexible, considerable overtime will be worked in order to meet the deadline. So, to keep the resources and their project manager less-stressed and more-loved, use the Factor of 2 Rule as a matter of course.

When all the time estimates have been gathered, prepare a Gantt Chart (using Microsoft Project, Visio, or some other project management software) that shows all the tasks required for your intranet's development and deployment. Each task should have a brief descriptive name (1-4 words), and should indicate what resources are required to complete it. It is also important to create relationships between the tasks and to state what preceding tasks must be completed before another one can begin. By creating a project schedule with an interdependent task list, managing changes and delays (and their bottom-line impact on the entire project's schedule) will be much easier.

Once the scope and schedule have been determined, a cost must be calculated. If all resources are on salary in your organization, then attributing a cost to the project will depend on your company's algorithms. It's best to discuss this with your accounting department, if it is relevant to your project. There are certainly many cases where the only costs that are important to an organization are outside costs. If this is the case, obtain quotes from your various suppliers (if necessary) and reserve the right to ask for new quotes if the scope of work changes during the revision and approval of your Scope Document.

Once your deliverables, schedule, and cost have been established, finesse them all into your Project Scope Document. Take extra care to be realistic and explicit. Don't promise more than you can deliver. Being realistic means setting expectations that you can meet; and being explicit means including as many details as possible instead of generalizations. This applies to everything in your Scope Document. Remember that you don't want to be making the complaint that you need to meet impossible deadlines and fulfill unrealistic expectations with inadequate resources. This is one of your key opportunities to make sure this doesn't happen.

Step 3: Review, Revise, & Approve Project Scope Document

Once the Project Scope Document has been completed, it should be distributed for review to all relevant stakeholders and decision-makers. You should request that they read it thoroughly and provide comments and questions. This will help you ensure everything is clear to those who are going to be involved. If necessary, have a meeting to review the document.

Regardless of the how spectacular, intricate, and fascinating your Project Scope Document is, the question you will typically hear most often at this stage will be similar to this: "what will it look like?". Sometimes people will be able to articulate this clearly and ask: "Can I see the new design before I review this document, so I can see the context in which the content and functionality will fit?". Regardless of how they ask to see the designs first, it is important to explain that designing the look of the GUI is not part of the planning phase; it is part of the production phase. While visually oriented people may not appreciate that, explaining it in terms they might (designing a product without approved definition will cost time & money) will help.

Discuss the Project Scope Document to whatever degree is required and make revisions until consensus is reached among stakeholders. This document will be the master plan for your efforts. If some aspect of your project is not explicitly captured inside, it will not be delivered. That being said, there will still be people who give their approval, then contact you shortly thereafter with requests for modifications and additions.

Step 4: Managing Changes

It is important to define a process for managing changes from this point forward. A formal "Change Request Form" and approval process for making amendments to your Project Scope Document will eliminate the lion's share of requests (many of which will be frivolous). The rest of them should be detailed by the person making the request and submitted to you. You should then determine the cost and time required to implement the change(s) and calculate how this will affect the greater project definitions. Also, you should make a recommendation about the degree to which the request is reasonable. Your information, with the original request, should then be reviewed and approved through appropriate channels. When approval is received, revise your Project Scope Document and make sure all stakeholders receive a current version.

Note

Remember to manage expectations. If you do this, you will live longer.

Step 5: Create Detailed Site Map

Using the site map in your approved Project Scope Document as a base, work with your designer and information architect (if you have one) to determine a detailed site map. Define a hierarchy of all the information on the site and organize it from an intelligent perspective. If you want to know if it's intelligent, show it to some potential users for some feedback.

The detailed site map will identify the number and type of different template pages that require design. Normally, designs will be required for:

• The splash page (if desired - this is a matter of personal preference). This can also be the user login page.

• The home page.

• The primary content group page (if required for sites with hierarchical groups of content).

• The individual content page for a news story or content item.

• Functionality pages (for search results, discussion forums, address books, and other interactive functions listed in the Needs Analysis section of this chapter).

• CMS interface (if required).

Step 6: Create First Draft of GUI

The first draft of the Graphic User Interface (GUI) should be derived directly from the information hierarchy defined in the Detailed Site Map. Attention should be paid to the varying degrees of importance that some content types and functionality will have over others.

It is recommended that the creation of the First Draft include the production of three distinctly different design concepts. These concepts should each consist of designs for all defined template pages. The differences between the concepts should primarily be in regard to navigation approaches (how the site will be used) as color schemes for intranets usually come from standardized corporate palettes.

The rationale for three designs is that it allows a designer to conduct an exploration of possibilities that is ideally a lucid, thorough thinking process. If they understand good web design and usable interface theory, there are many GUI variations that can arise. As they think of different approaches, they may return to earlier ones and refine them.

The more significant benefit of multiple GUI concepts is that the stakeholder group will have a selection to review, analyze, and discuss. People with minimal interface design experience will point to aspects of concepts they like and don't like, and use a visual language that can more clearly state their intention than a halting non-technical vocabulary.

"Try to accommodate the non-technical people as much as possible, and listen to what they're saying even if they're not using the standard web designer lexicon"

Before the GUI designs leave the realm of the designer, it is important that your project's senior technical developer and usability expert review them.

The developer needs to review the designs to make sure they are technically possible. They should advise you (and the designer) if they cannot be implemented at all (which may happen) in accordance with the schedule defined in the Project Scope Document. Remember the Factor of 2 Rule.

The usability expert should review the designs to make sure the design is intelligent. Sometimes a great flat design will become a nightmare when it becomes a fully functional web site. It's the usability expert's role to predict this and make appropriate recommendations.

When the team that is going to implement one of the designs has given their nod of approval to each of them, call a meeting of stakeholders. The meeting will be for the presentation and discussion of the three design concepts. If possible, have the senior developer and designer attend to answer specific questions and get first-hand exposure to the feedback. Bring printouts for people to refer to. And prepare for chaos.

If someone during the meeting is trying to convey an idea that they can't articulate, request that they provide a sample URL where the group can review their suggestion. Try to accommodate the nontechnical people as much as possible, and listen to what they're saying even if they're not using the standard web designer lexicon.

The goal of the meeting is to walk away with either a stated preference for one of the presented concepts or at least a very clear understanding of what type of design is wanted by the stakeholder group. The meeting attendees should be told that a refinement of the chosen concept will be created by the designer and two variations of the final design will be forwarded to them as per the original schedule.

During the meeting, take extensive notes. If you can't do this while presenting, have someone meticulous take care of this for you. Note suggestions, who made them, what was agreed on, what was dismissed (sometimes good ideas can be disregarded and brought back to life later), and what the action items moving forwards are going to be. Then create two reports, one for your personal use (with all the specific details) and one for distribution to the stakeholders (a detailed summary).

Note

The group document should be a comprehensive summary of the discussion outlining what was agreed to and an itemized schedule for next steps. Make this document one to two pages, if possible, but don't sacrifice detail for space when needed. Noting "the idea to have a webcam stream pictures from the Grand Canyon was dismissed as impractical and expensive" can keep you from having to explain later why it wasn't included when someone thought it would be.

Your personal document should include information about which stakeholder didn't say much and might need a one-on-one visit to get them on board or answer questions and address concerns. The intranet can be a highly political animal because it touches all departments, lines of business, and individuals within an organization. So be politically savvy when necessary, but remember to protect yourself with extensive documentation.

Make sure that all legal requirements are fulfilled - if your company employs people who are visually challenged or physically challenged the intranet should be accessible to them - or be prepared to spend time answering questions in court. See Chapter 6 on usability for more information on the implications of this.

Step 7: Second Draft of GUI

Use the feedback from the presentation of the First Draft concepts to create the Second Draft. This design iteration should be a refined concept with polish. It is recommended that a variation on the Second Draft be created as part of this design round so two refined concepts can be submitted to the stakeholder group for review or approval. This allows them to compare designs and state a preference (perhaps a request for further changes submitted with comments) instead of just returning a single concept with a request for further revisions.

Make revisions as necessary until the design for all templates has been approved.

Step 8: Obtain Approval for GUI and Start Developing

The GUI approval can take weeks or months to arrive. This is because it is the only really concrete stage of your intranet development that can be approved by non-technical stakeholders. As such, many corporate communications and design department members will want to have their say. After this stage, these stakeholders will have to wait until the project is about 90% done before they will see anything else. So be prepared to receive a plethora of opinions from corporate communications team members who want to have their say about the design. Stick to your guns here and remember that you're building the site for its users.

While you can certainly have the technical teams and content aggregators working concurrently with the designer, they may reach a point where they can do no further work without the final design. This can result in team members sitting idle, causing cost overruns and other miscellaneous problems.

Step 9: Create GUI Design Specifications Document

After the final GUI has been approved (and concurrently with the following steps, if you wish), ask its designer to create a GUI Design Specifications Document. It should be considered an addendum to the Project Scope Document and distributed to all members of the development team. This document will serve as a design bible during development and likely include (but not be limited to):

• A palette with HTML hexadecimal color values for all the colors used in the design.

• An explanation of what HTML colors should be used on the template pages for various text, table cell backgrounds, body backgrounds, and links (including active links, selected links, and visited links).

• Instructions on how link behavior should be implemented, in regard to mouse-hovering, underlines, and title texts.

• A font guide that includes information on all the fonts to be used in the site. This should include all the particulars your developer will implement in the site-wide Cascading Style Sheets.

• An explanation of usability and accessibility features and a detailed explanation (perhaps with illustrations) of how they should be implemented.

Step 10: Start Gathering Content

The Detailed Site Map outlines all the content areas that will exist in your new intranet. Each content area will have content items in it. You or someone on your team will need to make sure all this content is aggregated and organized so it can be included in the new site. These documents will usually exist in multiple formats across numerous locations and require various personal connections to obtain.

Meticulously tracking the particulars of all this information during this phase is important. Depending on the scale of this work, a master Excel spreadsheet might be useful. This can serve as a guide for the person responsible for the work, for the person managing the project, and for the developer or data-entry person who moves the content into the new system.

Creating a backup version of the content in its original format before conversion is always a good idea. This allows for comparison of original content with new, reformatted content, to verify data integrity. It also provides some insurance in case of problems.

Step 11: Design Conversion

To convert the designer's work into HTML, the developer will require individual images for various components of the design. The designer and developer need to discuss the specifics of this to make sure the developer gets exactly what they need.

Typically, designers creating templates for web sites will use a program like Adobe Photoshop to create multi-layered .psd images that can be displayed as a single flattened image ("flattened" refers to the multiple layers all being reduced to one flat layer when the image is printed or saved in another format). .psd files, however, cannot be used in an intranet site because web browsers don't display them. The only formats that can currently be used for images are .jpg, .gif, .png, and .swf (flash). Usually, however, .jpg and .gif files are those most often utilized.

A designer can't simply save their .psd file as a .gif or .jpg. This is because an intranet site consists of images and text, and it's considered bad practice to simply overlay text on top of a large image. Instead, the designer should convert their .jpg into a series of smaller web-ready images that can be used in HTML pages to accurately convey the visual effect of the design. The developer who will be creating the HTML templates can normally bestadvise the designer on exactly how to do this to make the HTML pages efficient.

When the designer converts their single image to a series of smaller images, they should keep some things in mind:

• The files should be optimized to have small file sizes for increasing the efficiency of page download times. This can be done with Adobe ImageReady, Macromedia Fireworks or Debabilizer. There may be some resistance to this by a designer who thinks an intranet is always accessed on a high-speed local network, but remind them that this process is considered best practice for web design and that some users may access the intranet from a dial-up account.

• File formats (.gif, .jpg, .png) for images should be carefully chosen based on requirements. Your designers will typically know quite well the issues surrounding the differences between formats.

• The filenames should be short, but descriptive (that is, title.jpg, logo.gif, icon-print.jpg, etc.). Numbered image names are discouraged. Also, images automatically given cryptic names when processed by Adobe software should be renamed.

• Numerous templates will probably all be converted to web-ready images at the same time. These templates' images should be placed into their own respective directories (for example, /images/splash/ and /images/home/), with common files such as logos placed in (/images/). This organization will make a difference in the short-term development cycle and become invaluable to site maintenance staff in the long-term.

• Whole, uncut images should be included in web format in a reference directory (/images/reference/). This allows a developer who is implementing the site to compare the presentation of their HTML pages with the original design.

• The original .psd files should be included in their own directory (/images/PSD/) as a proactive long-term measure. This will make updating the intranet's visual components in the future significantly easier on designers who may succeed the site's original designer.

• If the designer has time, they should create a basic wireframe for each template design that indicates the height and width of every image and content area. This can help a developer, but it is a "nice to have" and not a "need to have."

Step 12: Develop HTML Templates

When the design conversion has been completed by the designer, the developer can create HTML versions of the templates. Prepared with the reference images, the GUI Design Specifications Document, the web-ready images, and possibly a wireframe outline for each template, he will be able to accurately recreate the approved design in HTML.

When developing the HTML templates, it is important that an intelligent architecture be created. Planning and implementing this now will allow the rest of the intranet site to expand over this framework and be exponentially more manageable over the long term

Intelligent architecture, in this instance, refers to a clear separation of content, presentation, and functionality. An example of this would be an HTML content page with information about a corporate division's historical milestones. The actual HTML page (milestones.html) will just consist of the HTML layout and the content. The information about how the content is formatted (the colors and font information defined in the GUI Design Specifications Document) will be in a separate Cascading Style Sheet file (/includes/css/format.css). And the information about how the page behaves (image rollovers, document object triggers, etc.) will all be in a JavaScript file (/includes/js/rollover.js).

Note

HTML is used to describe the coding language because it is probably going to be the major part of the technology used during this phase. It is possible and perfectly acceptable for the HTML templates to be developed in XHTML or a scripting language and appear as CFM, ASP, JSP, PHP files, or a number of languages. In any case, the technology will be transparent in this phase.

The formatting and functionality documents will be referenced by the content page's HTML sourcecode. This code will instruct users' web browsers to download the appropriate include files and process them when it is being displayed in their browser. When these include files have been downloaded for the user's intranet session, they will just need to be downloaded once, and then all other content files can refer to them. This can have a dramatic effect on page load times when compared to having all formatting and functionality embedded in every page.

The additional advantage of this method is its extra-special selling point. By clearly separating the content from the presentation and the functionality, any of these three things can be changed without affecting the others. If the design evolves and/or users want larger font sizes, one CSS file can be changed to update every content page's layout. The functionality, similarly, can also be modified in the same way and to the same effect.

Referring to single CSS and JS files is probably an oversimplification of your intranet needs. You are more likely to have multiple CSS files for different templates (for example, all templates will use the same /includes/css/global.css global font definitions, but the splash page and discussion forum page won't need the /includes/css/navigation.css navigation font definitions).

While HTML files can theoretically refer to an unlimited number of CSS and JS files, the goal here is to create an intelligent architecture that will be extensible, maintainable, and sensible over time. Be careful not to micromanage functionality and layout to an extensive degree.

The last item to mention here is in regards to scripting languages. There are many advantages to using these technologies, but plan your implementation well, as per the above. Use the /includes/templates/template-top.inc and /includes/templates/template-bottom.inc include files to separate the advanced functionality of some sections from the formatting elements (note that the file structure of the site that is referred to here will be discussed later on). The advantages are also great in regards to organization and long-term maintenance, but the savings are more recognizable on the server-side (corporate benefits) than the client-side (user benefits).

Step 13: Test Templates

Your organization's IT department has most probably defined a standard software installation for all desktop computers. This is almost always an evolving standard, with some users just getting upgraded to the current configuration and others slowly moving past it. Two components of this standard that you have to become very familiar with are:

• What machines are currently deployed in the organization (platform, operating system, bandwidth capability)?

• What web browser software is installed on these machines?

You need to know what computers and software your users are running so you can test your templates on appropriately configured machines. Many problems about how users will see the intranet can be identified, trouble-shot and resolved at this stage by previewing the static HTML pages on typical machines.

A major advantage of standardized software deployment is that you can know a lot about your users in advance of your launch. Public internet development is often complicated by an ever-increasing number of web browsers that display HTML pages in their own special ways. Be thankful for corporate IT standards, if they exist.

Test all the template pages in the web browser and computer configurations included in your IT standard. If there are errors, make revisions as necessary.

Step 14: Develop CMS

Develop the CMS (if required) as per the specifications in the Project Scope Document. Integrate it with the user authentication system (if necessary) and then test all the required functionality from different user profiles with distinct access privileges. Also port some sample content into the system for testing purposes. This can be "lorem ipsum" mock Latin text to make the selection of sample text easier.

You should now have a functioning navigation that defines a "sense of place" for the user within the intranet site. As well, the CMS should be ready for content to be added.

When the CMS has been completed, an instruction manual on its use and administration should be created. This manual should be distributed to the relevant administrators, and also be posted inside the CMS for other users who will be making updates in the future.

Note

The developers can begin this process by including inline comments in their code to serve as basic documentation for future developers. These comments are like notes in the margin that are not read by the intranet server but are visible to people who are reviewing and editing the code now and in the future.

Step 15: Develop Functional Components

All the functional components identified in the Project Scope Document need to be developed and transparently integrated with the CMS. Regardless of development approach, hosting environment and scripting language, the look and feel of the site should be consistent across all functional areas. This is because the users for whom you are building the intranet site should not ever notice the technology that powers it.

If the site is based on a hybrid development approach, attempt to have all components use the same dynamic templating system. If that's not possible due to incompatibilities in scripting format, at least use the same HTML template and make absolute references to common images, CSS and JavaScript files.

When development is done, ask the developers to properly comment their code. This means that they should review and insert lines of text into their code that explain their rationale for approaching various sections of logic the way they did. This will make updating the code much more efficient in the future because less time will be required for other developers to learn how the code works.

Step 16: Monitor Progress

There is no substitute for a periodic formal review of development with all the people involved in the design, development and implementation of the site. The team should review progress towards the expectations (technical goals, schedule, and cost) and discuss any concerns. To make these meetings constructive, do not attempt to assign blame if problems arise; instead, seek out a solution as a group. And remember to manage the expectations of your stakeholders.

Note

One thing to remember as the process continues is that you must document everything. Sending summary e-mails to relevant stakeholders after conversations and meetings will allow you to prevent he said/she said arguments. These e-mails should include details about participants, decisions and action items. Not only will they include and inform the right people on the project's development, but it will also give you a paper trail to reference if things start heading in an awkward direction.

Step 17: Integration of Content

When the CMS is complete, the aggregated content should be added to the site in accordance with the Detailed Site Map. A content administrator should do this. He should obtain a copy of the CMS manual and follow directions to create the correct content structure.

If any problems occur during this process, they should be reported to the project manager and the senior technical developer. As well, changes to the manual should be suggested at this time if some areas are inaccurate or incomplete.

Step 18: Small Group Testing

The Small Group Testing stage should include all the developers, designers, content aggregators and people involved in the production process. This is because these people will know the intranet best and be able to thoroughly test it ensure expectations are being met.

Upload the site to a live server, but don't activate it to the public yet. A good way of doing this is to have the root folder's default file (that is, index.html) have a "coming soon" message and to have the test intranet's main page available at another location (for example, index2. html). Communicate that URL to the Small Testing Group and ask them to return comments, feedback, and suggestions within a defined time frame.

When the comments, feedback, and suggestions come back, review them with an open mind, but be careful about making changes to anything outlined in the Project Scope Document. Defer those for the next testing stage. For everything else, modify the various functions, content, and design as necessary.

In larger organizations, remind your IT department to load-test your intranet server(s) to make sure they can deal with numerous simultaneous users. Having the site crash on the day it launches will not look good.

Note that Quality Assurance and Testing companies (known simply as QA firms) are available to do this testing for you, if you wish. They will evaluate a site's design, usability, content structure, and overall impact for a reasonable fee.

Step 19: Large Group Testing

Large Group Testing should occur when you are reasonably sure the Project Scope Document's promises have been met. This means that expectations regarding its appearance, usability, and technical functionality should all have been delivered. If this is the case, schedule a presentation of the intranet site to all stakeholder groups and review the developed intranet. Any changes that were deferred should be discussed at this point, and appropriate action should be taken.

Unless approval to launch the intranet is given at this meeting (possible, but unlikely), provide the stakeholder group with the test URL on the live server and ask them to send you comments, feedback, and suggestions within a defined time frame. Make changes as necessary and ask for approval to launch the site.

Make sure to allow time after testing and before approvals for the development team to fix any bugs and address other issues which may have arisen during testing.

Step 20: Approvals

When approval to go live arrives (probably 3 to 6 months after starting the project), do a little happy dance and twirl around. Then send word to your senior developer that the test URL should be changed so that everyone in the organization has access to it.

Step 21: Launch

Typically, the best way to launch an intranet site is to send out a company-wide broadcast e-mail announcing the launch and inviting people to visit it. Do be careful, specifically in larger organizations, to be sure that load-testing has occurred before this, so the site's servers don't fail minutes after the corporate launch.