The material in this article will be useful for those who want to conduct a tender and find an IT vendor for creating a website, developing a mobile application, localizing a game, etc. My recommendations will also be beneficial for tender participants. By reading this material, you will learn about the peculiarities of conducting tenders in IT companies.

The framework described in the article will enable you to successfully conduct a tender. You will learn how to accurately identify and appoint truly competent specialists who are capable of solving your problem on time and at a reasonable price.

My opinion – everything can be outsourced except decision-making.

All tables, images, and other files from the article can be found at the following link: http://bit.ly/3G0I5H1.

What is Needed for a Successful Tender?

A "successful" tender is one in which you find a vendor who can solve the task at hand, while strictly adhering to quality, budget, and timeline requirements.

What steps are necessary to achieve this?

• Agree within your team on who is responsible for what.
• Define the procedure and timeline for conducting the tender.
• Consider the criteria for evaluating proposals and the basis for making a decision.
• Send a Request for Proposal (RFP) to vendors that includes:
  • A statement of the problem/task.
  • A description of the conditions and procedures for work.
  • Clear instructions regarding the expected outcome and requirements for the vendor.
  • A specification of the necessary documentation from the vendor; the questions that the vendor must answer; and the expected deadline for receiving the proposal.
• Invite vendors to participate in the tender.
• Communicate with them during the tender process.
• Summarize the results.

Below, I will explain in greater detail each step on the path to a successful tender. You will find ready-made solutions for your challenges through the presentation of documents, practical advice, and key processes whose effectiveness has been proven over time.

Role Distribution

I recommend designating the following roles:

• Customer – the party that has a specific task which the tender winner must resolve.
• Manager – the person who conducts the tender.
• Tender Committee – the group responsible for deciding the winner.

If necessary, one person may combine two or even three roles; however, each role is essential.

It is always preferable to have a single point of contact for communication. Interaction where one person communicates with only one other individual is invariably more productive. This is why tender participants should ideally communicate solely with the manager rather than directly with the committee, the customer, and the manager all at once. It is more convenient for the manager to work with a single customer rather than with a group, as this streamlines communication.

Who is Responsible for What within the Team?

For a clear distribution of responsibilities, I recommend using a RACI matrix—a visualization tool for "who is responsible for what." The primary objectives of the RACI matrix are:

• To document agreements.
• To identify areas for which no one is yet responsible.

You may use the responsibility distribution provided below or develop your own, as long as all participants understand and agree to it from the very beginning.

Important: Always ensure that each task/process has only one "A" assigned.

Example of distribution:

Timeline and Procedure for Conducting a Tender

Tender Procedure

This is a universal model for conducting a tender. Use it or adapt it to your needs.

Tender Timelines

It is very easy to verify whether your tender process flow is optimal. The table below presents the average tender timelines conducted by a major IT company. If your stages are more complex or the execution times are longer, then the proposed option is suitable for you.

Request for Proposal

• RFI, Request For Information. The simplest type of request that allows you to learn about a company's activities, its origins, etc.
• RFQ, Request For Quotation. With this request, you can clarify under what terms and at what prices companies in a given niche operate. Detailed task specification is not required.
• RFP, Request for Proposal. This request involves a detailed description of the task and the desired working conditions. From vendors, you receive a specific and comprehensive proposal.

RFP is the most extensive and complex type of request. Therefore, we will focus on it.

Your RFP should consist of the following items:

• Key information about the project.
• The procedure for interactions and work: including operational communications, discussion of payment terms, guarantees, etc.
• Key requirements for the vendor.
• Requirements for the vendor's proposal.
• Additional materials.

About the Project

Description of Tender Timelines and Process

Specify when vendors should submit their proposals, the timeframe in which you can review them and make a decision, and indicate the contact person (or persons) authorized to communicate with the contractor.

The Main Objectives of Your Project

The vendor must understand the ultimate goals you wish to achieve. For example, "to create a corporate website as quickly as possible" and "to create a corporate website that is easy to administer" are fundamentally different objectives. Each requires a different proposal, despite the general nature of the task "to build a website."

Project Timeline and Key Dates

When is the project scheduled to start and finish? Into what phases do you plan to divide the project? What are the key dates for these phases? You might also want to obtain recommendations on key dates from the vendor. These questions must be addressed in this section.

Scope of Work

Briefly list the types of work and the responsibilities you expect from the vendor. A poor formulation would be: "build a website." A good example is a detailed description of all aspects of the project, such as:

• Drafting and finalizing the technical specifications.
• Creating the website and logo design.
• Launching the website.
• Providing instructions on how to use the website.

Technical and Functional Requirements

Describe your desired outcome along with the technical and functional requirements, technologies, and so forth. Essentially, this is the technical specification (TS). The TS is extremely important: without a clear understanding of the final result, you will not achieve the desired outcome. I do not recommend phrasing the TS as "how to do it," but rather focusing on the problems that need to be solved and the conditions for their resolution.

Strive to write in a structured and concise manner, using numbering and attaching links to the corresponding sections of the TS to clarify details. In complex or debatable areas, provide justifications for your requirements.

Several examples of requirement descriptions:

About the Process of Collaboration

Communications

Describe how often you would like to have calls, whether you use Skype or telephone, and in which time zone your employees operate.

Change Management Procedure

Projects inevitably undergo changes. Indicate the volume of changes you anticipate, how you plan to implement them, and at which stages. Also, specify whether you will include an estimate of the expected changes in the budget.

Work Acceptance Procedure and Timelines

Describe how you will accept the work, how much time will be required, and the criteria you will use to determine that the work has been fully completed.

Delivery Package

Define the concept of a "delivery package." This includes not only the finished program, but also the user manuals, design source files, code, etc. Be sure to specify that the contractor must be available to clarify any questions during the acceptance phase, and that acceptance of all stages can only begin after receiving the complete delivery package.

Payment

Describe the steps for invoicing and the payment triggers. I recommend linking payments to specific stages where the results are significant for the task's execution.

Do not base payments on the "degree of completeness" of the work, as this benefits the vendor but not you.

Examples of Payment Triggers:

Vendor Requirements

Specify which parameters are important to you, for example:

• Availability of English-speaking specialists.
• A defined time zone corridor.
• Location.
• The ability to send employees on business trips.
• Possession of insurance for a specified amount or other certifications.

Proposal Requirements

What information, and in what format, do you expect from the vendor?

It is recommended to request:

• A portfolio with similar projects.
• A "professional profile" (CV) of the vendor's team: the skills of the key specialists involved in the project.
• The location of the team.
• A description of the risks the vendor identifies and the methods for managing them.
• A breakdown of the cost estimation by items.
• A list of technologies the vendor plans to use, along with justifications for their choice.

Risk Description

Describe the risks the vendor may identify and the methods they propose to manage them. A competent vendor may immediately point out issues with the chosen technology stack and suggest alternatives. They might also note if you have overlooked the need for managing user data for GDPR compliance, etc.

Cost Breakdown

The cost breakdown (breakdown structure, BDS) is a hierarchical decomposition of the required tasks with an estimate for each task. In its simplest form, it looks like this:

Always request the cost breakdown in a format that allows you to verify whether the vendor has correctly understood your task.

Examples:

• In the cost breakdown, you might see an item such as "Logo – 180 hours." However, if you are developing a website for the wholesale sale of cellophane bags, you do not require such an in-depth logo design, and you can discuss this with the vendor.
• If the cost breakdown does not mention the logo, even though the RFP specifies it, the vendor may not have read the brief carefully.
• If the vendor provides two separate estimates for the logo, this will help you understand the differences and choose the optimal option.

Additional Materials

Describe which additional files and materials you are providing and their purpose. It is recommended to include a link to a folder in cloud storage containing the documents, so they can be easily updated if necessary.

NDA

This section typically outlines which documents need to be sent and to whom for the signing of an NDA. Keep in mind that an NDA offers rather weak protection; treat it as a test of the vendor's legal flexibility and their genuine interest in your project.

Additionally

• Specify the units of measurement and the currency. For example, state the hourly rate in dollars or the total project cost in US dollars; indicate whether the time is measured in days or hours.
• Do not specify the evaluation criteria for proposals.
• Do not give vendors the opportunity to manipulate the results.
• Separate the sections of the RFP into distinct appendices. This way, the documentation will be easier to understand and reuse.

How to Evaluate Proposals?

Criteria and Their Priority Order

Define the evaluation criteria for proposals and their priorities from the very beginning to avoid manipulation and false priorities.

Evaluation of Proposals Based on Criteria

Define the exact number of points for each criterion (for example, for an "experienced team"). Without clear definitions, the evaluation will be less objective.

As basic criteria, use the proposed framework:

• A universal list of evaluation questions.
• An evaluation matrix with scores and weights.

Download the framework using the following Link.

Why Use 4 Points Instead of 5?

When using a 5-point scale, the median is 3, and in situations of uncertainty, the choice always defaults to 3. With a 4-point scale, you are forced to choose either above or below the average, which increases the specificity of the evaluation.

How to Evaluate Quantitative Metrics in Points?

Let's illustrate with the example of proposal costs by dividing them into 4 buckets (points from 1 to 4). Suppose you have 5 proposals:

• Proposal 1 – $120
• Proposal 2 – $30
• Proposal 3 – $150
• Proposal 4 – $90
• Proposal 5 – $70

Step 1. Define the Buckets and Their Boundaries

The higher the price, the fewer points should be assigned.

You can allocate points after receiving all proposals.

Step = (Maximum Amount – Minimum Amount) / Number of Buckets (points)

Step = (150 – 30) / 4 = 30

Step 2. Distribute Proposals into Buckets

Don't work with those who gave the highest and lowest scores — often, they misunderstood the task or overlooked the risks. Work with those who offer market rates and realistic timelines.

Inviting Vendors to the Tender

I recommend inviting 8–12 vendors. With fewer vendors, it is difficult to assess market conditions, and with more, communication costs increase.

What Should You Write in the Initial Email to a Vendor?

• Introduce yourself.
• Briefly state the purpose of your email and the tender.
• Concisely list the key dates for the tender and the project.
• Inform where more detailed information about the tender can be found.
• Find out if the vendors are willing to participate.
• Outline the next step for those interested.
• Optionally: If you cannot disclose project details immediately, describe the NDA signing procedure.

Example Email

Hello, "Integral",

My name is Dmitry Filatov, and I am the manager at "Roga i Kopyta." Our company is planning to create a new corporate website, and we are looking for a vendor who can help us implement the project (design, front-end development, programming).

To find a vendor, we will conduct a tender and invite you to participate. We found your website and contact details during a cold search on Google.

The tender will be held from February 23 to March 18, inclusive. From March 18 to March 25, we will select the winner and clarify the details of the proposals. On March 26, we will notify all participants of the tender results.

The project is scheduled to begin on March 28. You can find more detailed information about the dates, project tasks, vendor proposal requirements, etc., in the documents at the following link – [link].

Are you interested in participating in the tender? We would be pleased to receive your response within 2–3 days.

Where to Find Vendor Contacts?

In addition to searching via Google and receiving recommendations from colleagues, you can use http://vendors.dimafilatov.ru — my vendor catalog for GameDev. It mainly features small and medium teams, and offers a convenient search, the ability to export to Excel, and statistics.

Is it Possible to Work with Freelancers?

Yes, but not always. Determine whether your project is suitable for working with freelancers by answering a few questions. Record the number of the answer for each question, tally the points, and draw a conclusion.

Freelance Meter via the Link.

Communication with Vendors During the Tender

Evaluate not only the proposals, but also the level of the vendor's communication culture. How well do they resonate with you? Let's consider some examples.

Positive Indicators:

• The vendor asks several insightful questions that prompt you to reconsider the project.
• After the conversation, the vendor sends a brief follow-up.
• The vendor uses quotations and text highlighting in their responses to questions.
• The vendor identifies missing aspects and offers options for their resolution.
• The vendor submits the proposal within the established deadline.

Negative Indicators:

• The vendor asks a multitude of irrelevant questions that have already been answered in your RFP.
• They insistently propose a call without clearly explaining its purpose.
• They communicate through an incompetent salesperson who is unable to provide a precise answer.

"Let's have a call!"

Do not agree to constant calls if everything is already described in the RFP. Suggest that the vendor compile their questions in writing and send them via email.

Knowledge Sharing Among Vendors

If one vendor asks an important question, forward it to the other vendors to ensure equal conditions for everyone.

Tender Log

Keep a brief log of communications with each vendor – for example, "request sent," "questions received, promised response by the 27th." This will help preserve important information.

When communicating with vendors, include 1–2 colleagues in the CC so that if you are unavailable, work can continue.

Wrap-Up

What Should You Write to the Winner?

Do not directly inform the vendor that they have won the tender, so as not to strengthen their negotiating position. Instead, let them know that they have been selected among the winners and suggest discussing the terms of the partnership.

Short List and Plan B

Inform those who ranked 2nd and 3rd that they were very close to winning, and ask whether they would be interested in collaborating if the winner is unable to sign the contract.

Notification to the Unsuccessful Vendors

Be sure to send emails to the vendors who did not win, leaving a positive impression. Highlight the strengths of their proposal, as well as areas for improvement, by explaining the reasons for their loss and inquiring about their willingness to participate in future tenders.

Example Email:

Additional Recommendations for Conducting a Tender

If you conduct tenders on a regular basis, design your documents in a way that allows them to be easily reused.

Adapt your tender practices based on the specific tasks at hand and share your experiences within the company to improve the quality of partner selection.

Acknowledgements

This material was not developed by me alone. A significant part of it is the result of the work of professionals in the field of IT technologies and tender procedures—my former and current colleagues from various companies. The greatest contributions were made by: Alexey Eynor, Dmitry Zenevich, Ekaterina Verbi, Vladimir Skrynko, Alexey Ugolkov, Sergey Berezhnoi, and Andrey Lankin.

Many thanks to those who assisted in preparing the material:

Sergey Evdokimov, Viktor Koroteev, Roman Zhikharev.