How to Successfully Outsource Software Development

Even the biggest companies face outsourcing failures. For example, the administration cost of the payroll app the Queensland health department ordered from IBM increased from $6 million to $1.2 billion. This is a 16,000 % increase! Another example, Virgin Airlines, which experienced thousands of canceled flights because of bugs in the Navitaire, and eCommerce service that Virgin hired for growing airlines. All of these failures could have been prevented.

MindK has been working as an outsourced IT vendor for more than a decade and we also faced issues, frankly speaking. Several years ago we started a development project for hardwood floor manufacturers. The project was progressing as usual until our contact in the client company quit. After that, the client ignored our emails and calls. Developers managed to complete the project on time but the client wasn’t satisfied with the final design. The result was so different from what they imagined that we had to redo the whole thing from scratch.

Thanks to this experience, we know firsthand that most of the reasons that lead to project failures can be avoided. So, if you or your business partners have had a bad experience with IT outsourcing, it’s not a final verdict. We collected a set of golden rules focused on eliminating the negative outcome and putting outsourcing on the right track.

Lessons from the front lines: how to make outsourcing a success story

Lesson #1: Define the outsourcing risks mitigation plan

To avoid a disaster, first of all, it’s necessary to review the risks that come with outsourcing. We addressed this topic in greater detail in our previous article about the risks of outsourcing and ways to mitigate them.

We mentioned that among the most common fears of the clients are choosing the wrong vendor, loss of control over the project, low quality of the product, information leaks, and unexpected costs. All these risks are very dangerous to the success of the project—unless you have a strong mitigation plan at your fingertips.

How unwise it would be to go into the water without knowing how to swim, and just as unreasonable to outsource development if you do not know how to deal with the hidden dangers. The selection of the right development partner is the key pillar of outsourcing success. Choosing a good vendor can eliminate almost all the other risks and possible dangers, like low quality, loss of control, and others.

Very often businesses make their decision without proper research of the market. They simply share their idea with a development company, ask for pricing and decide which company can build the application cheaper. And that is a big mistake when selecting an outsourcing partner.

The price factor indeed plays an important role, but it’s not the only one and not the first one to be guided by. For instance, feedback, reviews, the company’s reputation, portfolio, level of internal workflows, qualification of the engineers, and business expertise, are critical and worth evaluating. We even published a guide to software budgeting to help people understand what components constitute the cost of software development. So, we highly recommend you check it out.

In view of the above, spending a little extra time in the selection of a reliable software development partner and developing a risk mitigation plan may save you time, money, and nerve cells in the long run. To get a bigger picture, we recommend you check our latest post on how to build outsourced IT department properly, where we also explain how outsourcing software development works and provide practical steps you can follow.

Lesson #2: Make sure you have clear project requirements

From the very beginning, it’s important to set clear and formal expectations about the desired results. Without clear criteria to push from, it’s nearly impossible to produce a product that operates as defined, accomplishes its goals, and satisfies end-users.

At MindK we make sure that spending time gathering requirements result in a considerably superior product with fewer product issues and frustrations. Among the other advantages of well-worked requirements are fewer project chaos, an ability to get to know the client and their business, faster final product delivery, and less development rework.

That is why you should be ready to spend some time communicating your project requirements with the IT partner.

Here is an example of how it works in MindK. As a rule, we hold a requirements workshop (also called requirements gathering session). This is an initial meeting where both parties need to discuss the product vision and overall scope of features.

The workshop typically involves a Sales Manager, Business Analyst, Tech Lead and Project Manager from our side, and key stakeholders from the customer’s side. After, to give a client an understanding of how much the project may cost, we provide a rough estimate.  Sure, the rough estimate isn’t enough to draw up a detailed budget, but it can serve as a roadmap for your project.

This is a good start to keep on gathering requirements for the project. As already mentioned in our article about the effective requirements gathering process, requirements gathering is an iterative process. You will likely require a series of interviews with stakeholders at all levels, end-users, or their representatives.

You should expect two main scenarios in terms of requirements gathering. The first is to hold a detailed separate Discovery and Specification phase that will result in a specification document. The second one is to collect an initial backlog of features for the start of the development and add or reprioritize features during the project.

The first one is a characteristic of the traditional Waterfall development model, while the second – for a more flexible Agile approach.

Difference between Agile and Waterfall development methodologies

Source: apifuse.io

“If it’s completely clear that requirements are the basis of the Waterfall model, how to collect clear requirements for Agile?” –  you may ask. It’s a very good question. The Agile team starts working without knowing all the requirements upfront. For example, it may happen that some features will turn out more valuable for clients than others.

However, it doesn’t mean that the team doesn’t have clear requirements for the initial version of the product, they completely know what should be developed. Before the start, the team forms a set of clear requirements (pulls the features from the backlog) for the first iteration (or sprint), and repeats it for each of the following sprints.

Sometimes we also offer our clients a hybrid approach. For example, in cases when the project is complex and requires precise documentation, but the client wants to keep track of progress and save some flexibility in requirements. In such a case we gather detailed requirements to specify the scope, budget, and timetable and then divide it into releases. Each of the releases has its own specification. After the release demo, we can include enhancements and improvements.

Lesson #3. Define the process and areas of responsibilities

The next important thing worth your attention after the requirements gathering is defining the process and responsibilities. If you haven’t worked with an outsourcing provider before, then you can rely on the provider’s expertise to help you define the process.

If you have already outsourced the development then you definitely know what to avoid and what works well. Consider your previous experience with outsourcing no matter good or bad it was to set up the process with a new IT provider.

When defining the process, make sure to include the following:

• Inputs and outputs of the process: decide what your team is able to provide to the outsourced software development partner, as well as discuss what you want the provider to deliver to you.
• SLAs (Service Level Agreements) to document all the arrangements: the documents should define the key aspects of the outsourcing like quality, availability, and responsibilities.
• Roles and responsibilities: define who is in charge of each operation as well as specific roles within the process. For example, when you choose the Agile development approach, you need to allocate a Product Owner (PO) to the project. It is a strategic role representing a person who promotes the interests of the customer for the development team and takes responsibility for managing the product backlog to reach the desired outcome.
• Communication plan: should include communication rules, tools and other factors combined with the escalation mechanisms. At MindK we always devise and ratify a communication strategy with our customers, identifying the most convenient means of contact for both parties, as well as who is responsible for certain tasks and project stages, and how frequently we need to have meetings and offer demos. This results in our clients having a clear idea of what to anticipate from us and when to expect it, allowing them to plan their work conveniently and efficiently.
• Metrics and reporting: capturing and reporting should be an essential part of the process. It shouldn’t add to the management burden, allowing resources to be concentrated on delivering the service.
• Handling of exceptions: nothing ever goes as planned. Ascertain that a mechanism is in place to handle such exceptions.

Lesson #4. Plan like a team

The key message here is to do all the planning in terms of the project together with a software provider. It means that you should be on the same page about what is planned and what should be received as the end product.

Depending on the software development methodology, you need different planning approaches.

Since Waterfall assumes developing software in a sequential, linear process, the proper planning step is a critical success component for the entire project. So, it requires high involvement of the client. The more information the client gives during the planning phase, the higher the chances for the project’s success.

Agile, as opposed to Waterfall, assumes a more flexible approach to the software development process. Responding to changes is more important to Agile teams than sticking to a plan. However, it doesn’t mean there is no plan. Agile planning works on three horizons: release, iteration, and the present day.

Planning across three-time horizons has two important advantages. First, it highlights that plans are made for a variety of reasons. The daily plan is quite detailed, the iteration plan is less precise, and the release planning is the least precise of all, containing merely a prioritized list of desired project features. Second, it allows you to see the project from different angles. The development process is not amorphous; it is loaded with planning throughout each phase and level. The client or client representative in the form of Product Owner should be involved during the whole project. 

Lesson #5: Monitor progress made by the team

When you give the project into the hands of a third-party vendor, it’s very important to keep an ear to the ground. Make sure that the IT partner is providing you with all of the relevant information about the project so that you have the full picture.

However, resist the need to seek excessive quantities of reporting as this will simply waste their and your resources. Do you, for example, require  daily reporting from the provider when weekly reports may provide a clear picture? A monthly report, in its turn, may be sufficient if there is a limited volume of activity with minimal variation.

A great reporting instrument in Agile is a demo. Each iteration should result in a piece of working software. A demo is a meeting where the team demonstrates the completed functionality and receives feedback.

We love making demos for our clients at MindK as it allows the team together with key stakeholders to discuss concerns and possibilities. We believe that it is a fantastic advantage for business because the client can view the results at regular intervals that allow the product to adapt to market changes, and provide feedback on the team’s performance.

 [BONUS] Lesson #6: Maintain flexibility

Many lessons from above talk about requirements, SLAs, and tight processes. Quite often, outsourcing is associated with strict contracts and paperwork. However, in a continuously changing business environment, companies should learn to adapt.

Both the industry of the client and the outsourcing software development companies undergo changes.  Thus, it is critical to remain flexible, not only to adjust, but also to benefit from the changes. So, when opting for outsourcing, selecting an IT-provider and signing up the agreement, keep in mind that outsourcing should offer you a flexible approach. For example, there must be an opportunity to scale the team up and down based on your project needs. The partnership should allow you to match resources to your company’s needs.

In short, be flexible and allow your service provider to be flexible. By focusing on your requirements and results, you may provide the provider the freedom to adjust to changing conditions while still receiving the benefits that were initially planned.

Make outsourcing work for you

You are not alone in your doubts about outsourcing the development. Outsourcing has its strong and weak points, but don’t let your negative experiences and unjustified fears get in the way of your digital transformation, software improvement, or just the growth of your entire business. Outsourcing can help, you just need to do it right.

Think, analyze, read reviews, check ratings, and see who your potential contractor is already working with. Be more attentive to documents and do not be afraid to talk about things that concern you. We believe that our tips can make your next outsourcing experience pleasant and painless.

If you are looking for a reliable outsourcing contractor, consider MindK. We have over a decade of experience in software development, lots of projects in our portfolio, and satisfied clients who keep on recommending us to others. Just drop us a line and our managers will schedule a consultation to discuss your needs.