As an independent tool, SiteManager^SM shines in the simplicity it provides regular users to control the content of informational web pages. When "web sites" turn into "Service Sites", SiteManager's capabilities are proving crucial as a method to control the overall costs and schedules. This paper describes how we accomplished this feat in interpreteraccess.com.

In contrast to a traditional web site, a "service site" includes capabilities beyond the display of information. Service sites help manage a business. A traditional service site is an online store front or auction site, but that is only the tip of a very large iceberg. These webs are used to handle demand chain management, supply chain management, customer relations management, and overall internal process improvements.

Interpreteraccess.com brings together a collaboration of providers of interpreter services and consumers of these services consisting initially of medical and healthcare providers. The objective of the site is to create a comprehensive exchange for interpreter services. In fact, this is the first exchange of its kind in the nation.

When we were approached by the collaborative to create this site, two things were immediately obvious: The site would require constant change; and the site would need a relatively sophisticated back-end to manage the process. After all, the site had to manage the supply pool of interpreters within independently managed entities. The site had to address the complete process of moving a consumer's request very rapidly through the system (especially for emergency conditions), as well as maintain a high level of customer interaction and constant communication.

Within the project's limited consulting budget (and I have seen no projects otherwise) both aspects could not be given the proper attention. Unlike other projects, however, our first instinct was not "what gets the hatchet?", "where do we cut?", or "what do we live without?" This time we had the benefit of a more obvious solution. SiteManager!

This solution was obvious because:

1. It removed some of the long term cash requirements for ongoing changes and management of information.
2. It shifted the requirements for the informational section from a technical problem into an adminstrative user capability which could be managed inhouse.
3. It moved some of the customer management aspects of the site to the hands of the collaborative members and allowed the creation of an interactive response management system.
4. Most importantly, it allowed the use of limited budget funds to create a world class software to manage the "services" portion of the site.

The role of the project manager was now focused on resource allocation from a whole new perspective. We broke the required high-level functions into two categories:

1. User Managed.
2. Software Needed.

The Result: The members of the collaborative got very quick access to create the desired information. The software creation proceeded independently and a comprehensive "services site" was developed in a matter of weeks.