How to Choose an Outsourcing Service Provider

This article will help you understand the key factors and criteria to consider when choosing an outsourcing vendor. The tips in this piece will be helpful for both clients and those who have to explain to the client why the price is not the paramount factor. 

Why is the price-based approach wrong?

Throughout my 17-year career in software development outsourcing business, I have run into a number of clients looking for low-cost software development solutions. The clients were looking for a budget outsourcing vendor that offers low project rates and at the same time can deliver high-quality output.

Inexpensive software development vendors may look like a bargain at a first glance. However, when you take a closer look, you’ll see the project deadlines aren’t met, the budgets are overrun, and the quality of the product is much lower than it should be. In such cases, the client switches from an inexpensive outsourcing vendor to a more pricey one, carrying over a non-working code and asking the new vendor to resolve the situation somehow.

In a majority of cases such a ‘price-only’ based approach can be explained by the fact that the client has a scant understanding of software and app development processes, and makes their decision based mainly on the most familiar and understandable factor – the price.

What is the meaning of the term “Service provider”?

A service provider is responsible for the software development of a service or an app. Outsourcing implies that the client provides its product requirements to a software development vendor to engineer, test and deploy a software product or its part. The granularity and complexity of the requirements can vary from just a short formulation of the app’s main idea to highly-detailed user stories. As an outcome, the client receives a fully-functioning and meticulously tested software. For increased security during the development process, some providers integrate an open source password manager into their workflow.

Outsourcing vs. outstaffing

The term outsourcing should not be confused with the term ‘outstaffing.’ Outstaffing or a ‘dedicated development team’ is a different collaboration type; when a client ‘rents’ a software development team or a professional to accomplish particular tasks or projects.

What is a project estimate?

A project estimate (or a quote) is an assessment of all the tasks needed to accomplish the project, evaluated in the terms of the required effort, duration and budget.

• The effort estimateis defined by the project complexity and project size. Commonly effort is formulated in a certain number of man-days/hours/months. The effort estimate can’t be directly converted into the duration estimate
• The duration estimate is defined by the effort needed and the size of the project team involved. The duration depends on whether the work can be done in parallel streams, taking into consideration all the dependencies between the modules.
• The budget is calculated based on the effort, duration and project timeline. The budget varies depending on the hourly/monthly rate of the developers, business analysts and other professionals involved in the project.

Therefore it’s essential for clients to understand that the high project price is not a sign of the vendor’s low qualification. On the contrary, it often signifies that the software development vendor can engage expert developers to deliver high-quality results.

Clients should bear in mind the real project duration can differ from the project estimate. The outsourcing vendor may estimate a one-year duration, but the project can last longer or shorter depending on:

• Scope change
• Technical risks
• Human-related risks

Therefore, it is crucial for clients to discuss key aspects before the project kicks-off.

How to choose the best project quote

Imagine you’ve just received two project quotes from two outsourcing service providers. The quotes you’ve got differ in price and duration. Let’s discover why the project quotes are different and how to choose the best option.

The uniqueness of software development implies that every task can be understood and implemented in various ways. Therefore, the project estimate for the same task can differ significantly.

The difference in the project estimates are influenced by multiple factors:

• Distinct understanding of task complexity
• Existence of the ready-to-use components
• Size and the structure of the development team
• The rate for one man-hour.

The project quote by itself can’t tell you anything and can’t be precise by its nature. In the IT industry the 70% quote accuracy level is considered to be not bad and the 90% quote accuracy is considered to be perfect.

That’s why it’s important to consider other factors.

What factors to consider when choosing a software development provider?

• The depth of project understanding by a service provider
• The assumptions on which the provider’s quote is based
• The exact description of the vendor’s and client’s responsibilities
• Proposed delivery process and framework
• Client’s involvement in the project delivery
• Risks
• The list of included items in a proposal

Let’s dive into each of these items in detail.

The depth of project understanding by a service provider

Different providers and even different software developers can understand a particular task in very distinct ways. For instance, a task ‘Login screen’ can be understood as ‘a simple login form with the login and password fields’ as well as ‘implement fully-functional user authentication using a two-factor mechanism, with the ability to reset a password and an option to login via social networks.’

Obviously, the estimates for these two views will be different as well. It’s important to scrutinize the questions asked by the software development provider, before the project estimation, in order to evaluate whether the proposal includes a deep understanding of the tasks needed to accomplish it and to what extent this understanding corresponds to yours.

The higher the level of correspondence, the closer the estimates are to the actual duration and price of the project.

The assumptions on which the provider’s quote is based

A first-class service outsourcing provider will definitely include an ‘assumptions’ section in the proposal to a client. A project specification can never be perfect or absolutely complete by its nature, and in the majority of cases it will have some uncertainties that lead to gaps in the provider’s understanding of the project requirements.

Therefore, a premium software development vendor will fill in the gaps in the project requirements with the assumptions on how to interpret the overlooked and/or poorly described details.

If the provider’s proposal does not contain a section with assumptions, is too short, or completely contradicts your understanding of the project, it may be a sign of an inaccurate low-quality estimate.

If after a meticulous and attentive examination of the provider’s proposal and assumptions list, you find out some of the assumptions are invalid, you need to discuss it with the vendor and understand how the corrected requirements impact the project duration and expenditures.

The exact description of the vendor’s and client’s responsibilities

Software development and deployment involve multiple activities and tasks. The responsibility for these activities often is distributed differently between the client’s and the provider’s teams. For instance, an outsourcing vendor may be responsible for the software development and testing while the client is responsible for specifying product requirements and deploying the project into production.

In other cases, the client provides the vendor a general description of the project along with high-level product requirements and the vendor executes the full cycle of software development and delivers a fully-functional product.

The vendor’s proposal should include a detailed list of the activities performed and the ones that are in the client’s area of responsibility. Normally the responsibility distribution is discussed during the proposal preparation and is included in the quote as a separate section.

The absence of this section may signify that the provider didn’t think about the responsibility distribution or has it only in their own mind. This will most likely lead to misunderstandings and conflicts. Also, the project price is highly dependent upon the vendor’s responsibility area size.

Proposed delivery process and framework

The vendor and the client have to agree on the software development framework suggested for the project delivery – it could be Scrum, Kanban, SAFe, or something else.

Besides, the software development vendor and the client should explicitly agree whether the project schedule includes any kind of fixed-date or fixed-scope releases, etc. It is paramount to discuss fixed-scope releases before the project starts so that both parties know what to expect.

Client’s involvement in the project delivery

The client’s involvement in project delivery is highly interconnected with the responsibility areas listed above. The software development vendor should distinctly highlight what type of involvement is expected from the client and to what extent. For example, the user acceptance testing usually involves the client’s participation, so it is highly recommended to agree upon the testing dates beforehand.

Moreover, it’s crucial to discuss the client’s involvement in the requirements preparation and the client’s participation in team meetings. For instance, it should not come as a surprise to the client that in the early stages of the project their representatives need to participate in meetings with the team 3 days a week.

There is one more component that may impact the overall project price: the vendor’s business trips to the client’s office. It is essential to understand how much they will cost and who pays for them.

Risks

The list of risks in the project proposal answers the question: “What can possibly go wrong during the project implementation?” This section of the proposal also describes what the client can do to assist in risk mitigation.

The risks may be:

• Technical – e.g., the product may depend on 3rd-party services on which the vendor has no influence.
• Organizational – a new regulation may come into force and affect the client’s business model and, therefore, the product.
• Environmental –  natural or man-made disasters, etc, like the current virus situation, or say, if your client is in California this could include earthquakes.

Usually, the list of risks in the quote is followed by a brief description of the risk response strategy which the vendor and provider can follow to decrease the risk occurrence and impact. The software development vendor may also advise the client to accept certain risks and allocate the expenses required to eliminate the risk’s consequences.

Quite often the risk assessment varies for different outsourcing vendors – one vendor may take into account more risks compared to another.

In any case, the client has to pay for the risks (even though the client might have chosen the quote with a lower initial price). However, it depends on whether the expenditures will be a surprise for the client, or if they are equipped with the knowledge beforehand.

The list of included items in a proposal

In addition to the essential sections (and usually the most interesting for the client) of the proposal which reflects the project duration and budget, the proposal has to include many other sections describing what exactly is included in the project estimation.

Here is an approximate list of such sections:

• Scope (what is and is not included in the project)
• Suggested technical architecture
• Assumptions
• Risks
• Suggested delivery approach and the degree of the required client’s involvement
• Effort estimate (together with a high-level project backlog)
• Suggested team composition (team roles and the number of people in each role)

Only after evaluating the proposal as a whole (not just the numbers), the client can access why one provider is more “expensive” while another one is “cheaper”.

What should you be aware of when working with outsourcing service providers?

So, now you are equipped with all the necessary knowledge and you know how to choose the optimal service provider. Nevertheless, it is essential to keep in mind a few more things:

Software development is very similar to a house renovation

The client’s involvement is required at every stage of the project. With a good service provider, the client will expend less time and effort, and even with a higher hourly rate the client will eventually pay less.

With a ‘cheap’ provider the client will pay for the rework and for the consequences of any misunderstandings.

The project budget is likely to grow

There are many reasons why the actual price can be higher. It’s essential to understand that neither the client nor the service provider knows all the project details before the project actually kicks-off.

Many things are adjusted as you go, especially after the first demos. The client starts thinking of the things that never came to their mind before, when the project was only ‘on the paper.’

Absolutely precise estimates do not exist

They don’t exist, due to the reasons described above. But a responsible service provider (and usually a more ‘expensive’ one) will organize the delivery process in a way that the client is informed about all the changes ASAP, so that the client can stop the development or change the priorities at any (or almost any) given moment.

A fixed-price contract is a rare thing

In the majority of the cases, the project (especially a big one) has so many uncertainties that a service provider will not take the responsibility to commit to a fixed price. It’s not because of the provider’s lack of experience or qualification, but exactly the opposite – the understanding and acknowledgment that you cannot promise things you don’t fully understand. Otherwise, you risk creating inaccurate expectations.

It is much better to break down the project into smaller and easily manageable parts and implement them iteratively – the approach that has already become a de-facto standard in the world of software development.