Software localization can get a bit overwhelming since it often involves many types of content, from code strings, to help desk documentation, including multimedia, and UI/UX design. Not only does it encompass these quite different types of content, but there is also the potential for errors that could actually break the product functionality.
Depending on your software product, choosing a translation and localization technology solution requires a complex set of requirements. This guide will outline everything you need for developing both a request for information (RFI) document and a request for proposal (RFP) so that you go for the software localization technology vendor that best suits your needs.
RFI and RFP: What Is the Difference, and Do You Need Both?
These two documents are similar information-gathering tools, but while the RFI is basically a way of narrowing down choices, an RFP takes those choices that make the cut and gives them a chance to compete for your business. It should detail the working arrangement including cost, time factors, set-up, and training.
The RFI is basically a survey sent to any platform developers who claim space in the software localization specialty. The goal is to determine which vendors have the required functionality you need. It is a research tool.
The RFP is a decision-making tool. Responses are assessed and a choice made based on a number of factors. The effectiveness of both of these processes determines the purchase of a set of tools you will likely be using over and over, as you add languages and make the transition to a multilingual software/hardware technology product.
RFI: Determining That a Solution Fits Your Requirements
The RFI should be a brief document, often in the form of a questionnaire, to determine whether a vendor fits the basic requirements you need. These requirements are often specific to software localization, including supported coding languages, the ability to deliver extracted text content from a variety of places, including context, and support that understands software development processes.
A Nice-to-Have or a Must-Have?
Before you create your RFI, you need to define these requirements and then determine which are must-haves and which are nice-to-haves. The latter is critical at this stage because you do not want the RFI to turn into a long wish list that overly narrows your choices.
Typical must-have feature requirements include:
- Standard features of a translation management system (TMS) including translation memory, centralized communication, progress tracking, billing and vendor management, as well as a quality review process,
- Systems connectors and APIs,
- Required programming languages and environments, including agile development tools and built-in machine translation,
- Your requirement for either cloud-based SaaS hosting or on-premise (often required for legal or security reasons),
- The ability to tag and track content throughout the process for reassembly of the translated content,
- Support for related materials including help desk, knowledge base, documentation, marketing materials, and audio-video content,
- Required onboarding and training, implementation, and basic pricing models.
As you define your requirements, be merciless in determining if they are absolutely essential at this stage. You are going to need to format them as questions and decide whether they will be open-end or checkbox answers. Open-end questions provide a space for a more detailed explanation, while checkboxes limit the answer to a yes/no or a set of predetermined options. Open-end will require more time on the part of the vendors.
Because part of the goal of an RFI is to quickly gather preliminary information, making this simple to complete will get you more responses.
Moving to a Software Localization Platform RFP
If you have set a deadline for returning RFIs and designated a point person for Q&A during the process (sometimes if you do not want to enter an aggressive sales process at this point, a consultant may be used to anonymize your interest), you should have replies when your deadline is reached.
This is where keeping the RFI relatively brief is important to keep the process going. If replies are not coming in you likely have one of two issues: The RFI is too complex for your deadline or it is so detailed that no provider can provide every required functionality.
Once you have narrowed the field you may take one of two routes. The first is to open a sales dialog and the second is to create a formal Request For Proposals that serves as a future basis for a contractual agreement.
Your RFP should request the following:
- Vendor backgrounder,
- Vendor point of contact,
- A brief pitch on why they should find you a valued potential partner (important because this will be an ongoing relationship if successful),
- Implementation and training plan with associated costs and timeframe,
- The pricing structure, including base subscription, per-user cost, any extra charges for things like data used, etc; this should describe your expectations as far as the number of users, features that may require custom development, etc.
- Customer support plan(s) and associated costs,
- Basic communications plan.
An Open-Ended Document That Is Concise
The RFP and the response are not going to solve every detail of the working relationship. These will get worked out as you narrow your choices and enter a back and forth Q&A stage where details start to get hammered out. This is the stage where softer issues like cultural fit and working relationships start to take form.
This is critical because a software localization platform is a business decision that will materially affect your ability to rapidly enter lucrative new markets and to introduce new products and upgrades to those markets.
Basic Internal Process Practices That Help With RFI/RFP Creation
To reach this goal of successfully choosing a platform and making a buying decision, there are basic internal planning processes that will proceed with the writing of the RFI or RFP. First, you should have some guiding principles that all internal stakeholders agree to:
- What is the purpose of the RFP?
- What are the objectives of the RFP?
The SMART Model
These guiding principles help keep everyone focused and on message. To define whether consideration is a basic principle, the second step is to apply a useful model like the SMART model:
- S: Specific. Can it be defined?
- M: Measurable. Can its value be determined?
- A: Accepted. Does everyone agree on it?
- R: Realistic. Are we asking for too much?
- T: Time-bound. Is the proposed schedule doable?
When applied to the purpose and objectives these become benchmarks for determining if the team is on track and realistic in their expectations.
Assign a Project Lead for the RFP Creation and Evaluation Process
When you consider that developing a localization strategy affects nearly every area of a company from management to product development, marketing, and finance, choosing and empowering a Project Lead is an important early step. Ideally, they should have a basic understanding of the translation and localization process. They should also be able to reach across departments and hierarchies to keep things moving.
If you do not have an internal resource, a consultant with specific software localization experience can help with requirements and RFP creation. As mentioned earlier, if you want to do a blind quotes process that does not reveal your company identity at this stage, this becomes a must. Examples, where this may apply, are military or defense contractors or other businesses with security or legal concerns.
If you use a consultant, your Project Lead should be with them every step of the way, learning how these processes work. This is a valuable investment that will deliver a return for years to come.
Evaluating Responses to Your RFP
You have reached your deadline and you have several responses that appear to fit your requirements. You have had followed on Q&A meetings to clarify any issues either party encounters. Your team assembles each response and it is assessed according to our predefined parameters. The goal here is to normalize the responses so you can make fair comparisons.
There are basic top-level considerations. These may include:
- Quality of response and timeliness. This will tell you a lot about how important they see the relationship being to their business. A slow response or a generic one that does not address your specific needs can signal a sloppiness that is a bad sign at this stage.
- Time and money. How fast can they implement things? What are the unexpected costs? Are they above or below your budget and why? Is there clarity around costs and terms? Are they financially solvent? Are they being clear about any ongoing merger or acquisition activity and its effect?
- Culture and values. Is there a good fit between your business culture and theirs? You are going to be working together on a function critical to your business growth for years to come, so this value question is important. Are they flexible? Do they have a growth plan that can mirror yours? Have you talked to their other customers? Have they handled a product like yours in the past?
You Are Not Just Investing in a Tool, You Are Investing in a Learning Curve
Unlike an RFP for services, you are using this to make a buying decision for a tool that will become a part of your business. Unless your first choice of a system is a failure, your RFI/RFP process, in this case, is unlikely to turn into a template. However, if you do have to go back to the drawing board, the experience of planning for and creating these documents is a learning process with its own value.
Translation and localization projects can be confusing and challenging if you have never done them before, especially with technology products. Add in multiple languages and the complexity explodes unless you build strong internal processes as part of the entire RFP and buying experiences.
These processes represent a steep learning curve and the development of an internal culture that is more globally conscious across your business. That is the major investment you start when you decide to enter new global markets.