How to choose a contractor for the software development and what benefits from such partnership

Launching software development is like giving birth to a child: hurry up with the choice of a partner and at some point you will raise yourself, and the “rotten” genes of an unsuccessful partner will remain …

Every day, many new IT projects are born in the world. Previously, most successful projects were born “on the knee”, but the time for quick results is passing. For simple and standard tasks, there is always a ready-made service, but for more complex and complex tasks, a completely different approach is needed.

If you want to develop, launch and successfully develop your software, one of the most reliable ways is to contact an outsourced development company. Despite the many positive aspects, this path has a significant drawback – the risks associated with attracting a third-party company.

“All is well” is a relatively rare case (more like a “survivor’s mistake”), so I will focus on the possible negatives and how to choose a contractor with whom the risks of failure will be minimized. After all, not everyone can become a reliable technology partner like Svitla Systems. A problem arises that is often not recognized: these proposals are not only unequal, but also evaluate different solutions.

Development deadline violation

A parable in the talk of the industry. Everyone, without exception, violates the deadlines – the only difference is how the development team works with this.

The best break only within the framework of individual stages and are able to see the problem in time. The best not only see, but also know what to do.

The most common reasons for delays are:

• An attempt to please and “hook” –
  in an effort to please the client, the contractor immediately names the terms that the client will be pleased to hear. Basically, this is a sin of start-up companies, or sales managers who want to interest the client at any cost. When the contract is concluded, and the prepayment is made, it becomes a matter of technique to keep the client, even after the deadline has been missed.
• Underestimation of technical complexity and / or poor analytics – the development of any product is the work of a whole team of specialists (I do not take freelance or attract internal “tyzh programmers”). In complex projects, different people are responsible for analysis, design, and development functions. Everyone has their own vision and experience. What is clear and transparent for one person may be something super complicated for another.
• Lack of experience in the joint implementation of projects by the development team – projects in IT require different competencies and composition of specialists. Developers are like the crew of a ship – each member of which performs its own function. Even when all project participants have a serious level and more than a dozen projects behind them, if they work together for the first time, they will need time to “grind”. The more professional the specialists and the more developed the development standards in the company, the less this time is needed.
• Incorrect phasing of the project and / or large-scale planning horizon – the further it is necessary to predict the work, the more assumptions accumulate. For projects lasting more than 3-6 months, the probability that there is a clear TOR that is static and unambiguous is 0.0…1%. Most often, there is a “Wishlist”, or an approximate technical specification, which will definitely be refined as it is developed. With refinement, the scope of work tends to increase, not decrease.

The list can be continued for a long time: lack of resource planning, lack of discipline, incorrect prioritization and sequence of tasks, lack of a risk and change management system, insufficient control over implementation, accumulation of technological debt, and even a banal illness of a key employee.

To reduce the likelihood of missed deadlines when choosing a contractor, I recommend asking the following questions:

• How is the project planning process, work with changes, risk management arranged?
• What resources will be allocated to the project and what is the experience of the team working together? In what sequence and how will the participants be integrated into the development process?
• What standards are used in the analysis, planning, documentation, development, testing of the project?
• How much experience does the project manager have in project management in this particular area?
• What penalties for failure to meet deadlines are specified in the contract and what is the procedure for their application?
• What is the responsibility of the development team for meeting deadlines? Does the motivation of employees depend on compliance with the terms of the contract?
• How often and in what form will progress reporting be provided? What should be paid particular attention to in order to anticipate possible problems?

There are no single correct answers to these questions, but by asking them you will learn about the processes of your potential contractor and be able to foresee how he will act under certain circumstances.

Breaking the development budget

Another frequent guest in software development – “we thought we would do it for 3 kopecks, but it turned out to be more expensive than building a Boeing.” It is worth accepting right away – if the product is successful and develops, then the budget will definitely grow. The only question is how much of a surprise this can come to you.

The most common reasons for budget violations are:

• The contractor dumps in order to take the order – some market participants have the following business model: to announce the cost for the implementation on the instructions of the client is significantly lower than most competitors and even give guarantees of performance. The bottom line is that the developer does only what has been fixed and, as far as possible, with minimal effort. In such a case, it should not be expected that the strategically most effective solutions will be chosen. And the need for qualified specialists is not high – the more improvements you need in the future, the more you will pay.
• Profitability on maintenance and improvements is another business model, the essence of which is: to lay a small margin at the beginning of work, and only then “milk” the client on improvements and maintenance. The likelihood that at least one serious team will undertake to support someone else’s code for “reasonable money” is very low, so you are unlikely to leave them. As a result, you can sell you services for maintenance and improvements with a significant margin, recouping the initial risks and lost profits.
  In this case, what is meant by violation is that it may not be predictable for you initially, which will increase the cost of ownership of the product and may not be as effective as planned.
• Underestimation of technical complexity and / or weak analytics – and again this point. Many development customers greatly underestimate the need for high-quality analytics. Surprisingly, the disdain for planning and elaboration is found even among IT specialists with experience.
  Weak attention to analytics is the scourge of the industry. It is difficult to sell analytics, and no one wants to do it at their own expense and overtime. As a result, each issue not fully worked out turns into an additional estimate, the volume of which is often unpredictable.
• Not matching the result to the needs and/or expectations of the customer is another variation of poorly executed analytics. Often in the head (and on paper too) the expected result seems beautiful, concise, functional … But in fact, it often happens differently. The intended target may be false. The problem to be solved is the effect, not the cause. Seemingly clear and consistent connections may have gaps and “dark zones”.
  This is the most common reason why the budget grows. It is unlikely that you just need a picture. Most likely, you want to close some need and will be willing to pay to get exactly what you really need, even if this leads to an increase in the originally planned budget.

These are also only the main reasons and there are many more possible ones: an attempt to compensate for one’s mistakes within the framework of this project, an attempt to compensate for less profitable or unprofitable projects, the accumulation of technological debt, an increase in demand for performers, poorly designed documentation/architecture and the departure/rotation of performers, etc. The main recommendation: transparent planning and high-quality analytics are the key to budget predictability.

In order to understand in advance the required budget, you can ask the contractor :

• What is the methodology for calculating the project cost? What cost sharing should be expected?
• How often do prices for services change and what do they depend on?
• How much will project support cost after launch? (here you should think about how large-scale improvements you plan if successful, so as not to force the contractor to take numbers out of thin air)
• In what budgets is the contractor interested in long-term cooperation?
• How financially stable is the company and how often does it attract new projects?
• Who makes the cost estimate and how does it compare to the actual work done?
• What risks are included in the price and are they included?
• The level of specialists involved and the contractor’s prices relative to the market? Does the contractor focus on highly qualified and expensive specialists, or on mid-level specialists with the involvement of beginners? Is it expected that specialists will be replaced during the project implementation?
• What documentation standards are adopted by the company and will it be possible to connect a third-party team / leave the contractor? How much will the process of transferring the project to support and development to another team cost?
• Is there a practice of increased coefficients for urgency and how is it used?
• What does warranty service include and what are the terms for solving warranty cases?
• Are prices fixed in the contract for calculating the cost of work and how is indexation carried out?
• What stages, according to the contractor, can be the most expensive?

By asking these questions and getting clear answers to them, you will surely be able to plan a budget taking into account all the risks. You do not have to voice your estimated estimates to the performer, but you should calculate not only optimistic, but also negative options.