"Build sites in order to throw them away - the Web isn't static and information doesn't last long." Words to live by, according to Robert Andrews, Web Site Director at Netscape Communications Corp.'s worldwide headquarters. How can clients and Web localization/ internationalization service providers take advantage of this fact of "cyberlife" without being overwhelmed by planning and budgeting issues, as the number of non-English sites continues to grow by leaps and bounds?

One way to maintain one's sanity when working together to localize and/or internationalize a Web site is to develop a "Request for Quote" or "RFQ" (also known as a "Request for Purchase", or "RFP"), and then implement it. There is no magic formula which allows the painless creation of an RFQ, so why should anyone in this frenetically paced sector of high tech called "on-demand multilingual Web publishing" take the time to create one?

Benefits of the Web RFQ Process for Clients

1. Focus

Developing a Web RFQ helps to focus clients on exactly which tasks need to be done when, making the establishment of project milestones much easier. Developing an RFQ should also push clients to develop specific goals and a plan for internationalizing/localizing the company's Web site(s). This is important since on-demand multilingual Web publishing is new for many clients, as well as service providers.

2. A Fairer Bidding Process

By enabling the client to compare "apples to apples," a standard Web RFQ "levels the playing field" for potential service providers. It is a sign of true partnership when a client takes the time to give all groups an equal chance during the bidding process.

3. Enforced Discipline

An RFQ is a natural metric for measuring performance, especially in the areas of budgeting. In addition, it will help to indicate if the project management functions in both the client and service provider organizations are functioning optimally.

4. Opportunity for Organizational Change and Improvement

Interviewing all necessary departments while creating an RFQ tends to reveal areas of an organization in need of new processes and/or improvement, e.g. the integration of home office content producers with the company's international publishing arm. It will also expose areas where inefficiencies exist, e.g. a lack of trained project managers. The organization can then choose to "seize the opportunity for change".

Benefits of the Web RFQ Process for Service Providers

1. Does This Client Really Belong?

An RFQ can quickly indicate to the service provider the cost structure involved in a Web internationalization/localization project. The service provider can then make the business decision as to whether it should take on the client and/or the particular project in question.

2. Preserving One's Reputation

The absence of an RFQ from a client and/or the lack of clear goals for a project can both serve as big red flags to indicate that a project will fail. The service provider must decide at this point whether or not to protect itself from a disorganized client who will eventually cost it money and/or negatively affect its reputation.

3. A Fairer Bidding Process

The RFQ levels the playing field for service providers by forcing the client to compare "apples to apples". It also brings out potential hidden costs which either the service provider is reluctant to mention or which neither party has thought of. Some examples are outlined in the next section.

Building the Partnership - Shared Benefit

A Web RFQ provides a way of measuring and tracking what this new type of project actually costs. In this way, terms can be renegotiated as both parties actually quantify the work required, as well as the costs involved. For example, it may be more rational for the client to pay a retainer fee to the service provider, as is done in the advertising industry, rather than a per word price for every change.

Developing the Web RFQ: Recommended Line Items

Provided below are suggestions for line items which are generally applicable to Web site internationalization/localization. The reader may wish to adapt LISA's Request for Purchase, develop their own RFQ, modify an existing one, etc. In addition to the sections recommended below, there should be columns for rates, units (per word, per hour, etc.), quantities, total cost and total hours.

Sections to Include in a Web RFQ

1. Separate RFQ for each language (line items may be the same, but prices and hours required will differ).
2. Project set-up time (including meetings with the client, formation of the project team, file preparation, etc.).
3. HTML (text translation/linguistic review), with each file listed separately.
4. Graphics (translation and editing), with each file listed separately.
5. CGI and Java scripts (linguistic work, code modification, test and QA, integration of client code updates).
6. Technical review (if necessary).
7. Final integration of all files, scripts and links.
8. Final test and QA (including a "linguistic double-check", link verification, code page fixes, etc.).

Forgotten Tasks: Potential Hidden/ Unrealized Costs

The following tasks are often overlooked when developing a Web RFQ. Some of them may represent significant costs, depending on the project. Others may represent difficult areas where decisions must be made and processes developed. Both the client and the service provider should be open to renegotiating prices and/or reinventing ways of solving problems once the initial project is complete.

9. Customization work to globalize and/or adapt a domestic Web site to specific international markets.
10. Hardware/software budget.
11. Development/maintenance of in-house tools to automate/smooth the Web internationalization/localization process.
12. Recruitment and support of in-country networks of marketing-oriented translators/ editors to work directly within HTML.
13. Implementation of a staging area where everyone (client, contractors, service providers) can post files for content review, testing, archiving, etc.
14. Adaptation and/or constant updating of CGI and Java scripts (interactive sites mean code localization and all that the latter entails).
15. Constant updating of the site in several languages at once.
16. Management of in-country content creation.
17. Version control for the client, i.e. in lieu of the client doing its own.
18. Multilingual Web site management software.
19. Terminology management (development, verification, maintenance, etc.).

Guidelines for Implementing the Web RFQ Process

Implementing the Web RFQ process within an organization depends, of course, on current workflows, the personnel available, management support, etc. However, here are some suggestions on how to implement the RFQ process, from both the client and service provider perspectives.

The Client Perspective

1. Developing a Prototype Web RFQ

The person responsible for Web site internationalization/localization must first develop a prototype RFQ for a specific project. This requires "interviewing" other groups within the organization to understand the following components:

• Content of deliverables.
• Format of deliverables.
• Timelines.
• Quantities (word counts, number of graphics, number of strings, etc.).
• Dependencies on other groups/ service providers.
• Any other tasks/processes specific to the particular group.

The groups to be interviewed include:

• Originator(s) of the programs.
• Content group(s), i.e. the people who create the text, graphics and scripts for the site, domestically and/or internationally.
• Webmaster(s) for domestic and international (if they exist) site(s).
• Domestic QA personnel (if they're involved).

2. Integration of Specific Line Items

Next, the Web Site Localization Manager must add whatever line items apply to the project in question (see above). If the organization develops software products, then how to integrate software localization into the Web site localization process (or vice versa) must be considered in the areas of terminology, choice of service providers, schedules, test and QA, etc.

3. Applying Estimated Costs

At this point, the Web Site Localization Manager should apply estimated costs to each line item for each language. In this way, the RFQ can either be used to develop a budget or for comparison with an already existing one. The Web site internationalization/localization project can then either proceed or be resized to match the resources available.

4. Instructions

Instructions for filling out the RFQ should be documented. Areas such as project milestones, discounts, how to include a service provider's "competitive advantage" if not covered by the RFQ, etc. should be spelled out.

5. Testing the Web RFQ

The Web RFQ and its formulas should be tested to ensure that the instructions make sense and that there are no math errors.

6. Service Provider Selection Criteria

A list of weighted selection criteria should be developed by the Web Site Localization Manager with two goals in mind:

• To make the service provider selection process more objective.
• For adaptation as a list of qualification questions to be posed by phone/e-mail, in order to narrow down the number of service providers.

7. Distributing the Web RFQ to Potential Service Providers

After narrowing down the list of potential service providers, the Web Site Localization Manager can send out the RFQ, preferably electronically. It should be made available to all groups on the same day, and enough time given for them to make an informed quote. The Web Site Localization Manager should also be willing and available to answer questions promptly. However, care must be taken not to give any service provider an unfair advantage.

In addition to the instructions, two other documents may be included with the RFQ:

• Sample texts (e.g. marketing text in HTML with a Java script).
• A list of required software/hardware and areas of expertise.

8. Final Selection Process

Using the RFQ and the weighted selection criteria, the Web Site Localization Manager can base the decision on more important criteria than the per word price, thus forming a solid basis for partnership.

The Service Provider Perspective

Even if a potential client does not provide an RFQ for the bidding process, it is still well worth the effort to present the bid in this format for the following reasons:

• The RFQ provides visual and very clear proof of Web site internationalization/localization expertise on the part of the service provider.
• All issues can be brought out in the open prior to starting the project.
• If the client is not fully "up-to-speed" on the Web, the RFQ can be used as an important reference tool.
• If all steps in the project can be worked out with the potential client, then the RFQ can be used to justify fair prices.

Summary

An RFQ for Web site internationalization/localization serves both the client and service provider in the following ways:

• By helping to ensure that the bidding process is as fair as possible.
• By enforcing disciplined project management.
• By enabling clients to compare "apples to apples" and highlighting more important criteria than the per word price.
• By revealing potential hidden costs.
• By providing a way to measure a project's success.
• By serving as an effective tool to justify fair prices.