How To Choose a Software Development Company?

Here is a pretty standard situation when it comes to choosing a custom software development company. The client sends out Requests for Quotation (RFQ) to several perspective companies. The goal here is to get software project estimates, evaluate, and compare them. And ultimately decide which software development company will carry out the project. The proposals are not identical: the scope of work, technology stack, and prices may be quite different. The not so obvious problem is that, even though the RFQ requests to respond to the specific requirements, the suppliers evaluate different solutions. More on that below. This article provides a systematic view of the supplier choosing process. It also attempts to encourage a new way to address the problem that arises at the stage of defining the requirements and quotes evaluation.

According to TechTarget, IT Solution is a set of related software programs and/or services that are sold as a single package. In a stricter sense, however, an IT solution is an aggregation of products and services, as opposed to a single, discrete product[that] will help the customer successfully solve a problem or deal with a complicated situation.

Therefore, IT Solution refers to any software (mobile, web, desktop, sites, etc.) that is created during the development process to achieve the customer’s defined business objectives.

Breaking Down the Process of Choosing Software Development Cоmpany

1. Requirements Document Requirements document, which spells out the specification of an IT Solution, is an integral part of the process of choosing the software development company for the software project. The manager sends out the document to several potential development companies. Correspondingly, they price out every requirement listed in the documentation and send the estimates back.   2. Evaluating Project Estimates The client receives offers from potential companies. An offer is a document, which mainly outlines the scope of work, deadlines, cost estimates, expertise, and professional experience of the team members. Then the estimates are reviewed and compared with each other according to many criteria.   3. Shortlisted companies Based on the estimates the client shortlists 2 or 3 companies and holds a series of qualifying conversations with them. Consequently, these conversations lead to choosing the software development company that will be awarded the contract.   4. Contract The last step in this process is discussing and signing the contract with the selected company. A plethora of estimates creates an illusion the data is sufficient to make the right decision. Oftentimes, the criteria are reduced to the cost alone. In my opinion, such an approach does not provide the completeness and sufficiency of information to make a decision. Such a process is flawed because the knowledge that is transferred from one party (the client) to the other (the software development companies) is incomplete.

Requirements Document

Software Requirements Specification is a document that describes what the software will do and how it will be expected to perform. It also describes the functionality the software product needs to fulfill all stakeholders (business, users) needs. The document determines the conditions and procedure for the procurement; the delivery, performance, service provision, and acceptance criteria are formalized according to this document.

My take on the definition is as follows.

Software Requirements Specification  is a set of artifacts that help represent and relay a formalized information about the IT solution among the stakeholders of a software development project/process.

The key here is to become aware that how we arrive at what the solution should be – whether a solution to a business problem and/or an IT solution – is heavily influenced by many factors. And these factors vary from person to person. Here is why. It is only by examining the different projections, you can find the optimum solution. A one-sided view will hinder one from getting a full picture. Just as in the picture below, the cylinder is a square in one projection and a circle in another. For different people, the solution to the same problem will be different. Therefore, a systematic problem analysis is required. Such analysis allows one to accumulate the knowledge of how to solve a particular problem. The knowledge may be insufficient, however, but it exists to a certain extent.

How to transfer the knowledge about the solution

To understand how best to transfer the accumulated knowledge about the solution in the form of a Requirements Document, let’s consider the process of knowledge transfer.

Learning – the acquisition of knowledge or skills through study, experience, or being taught – occurs in several stages. They are: production, accumulation, distribution, and applied use.

Picture 1 – Stages of Learning

Let’s consider these stages in the context of the process of a software development company selection.

1. Production of implicit knowledge. Implicit knowledge is the information aggregated from various sources: consultants’ recommendations, competitor research, personal experience in developing IT solutions, the information about the organization of objects around the problem under research, and much more. Implicit knowledge is not formalized, i.e. not expressed in any way. In other words, implicit knowledge is in a person’s mind seeking out software development services.
2. Accumulation. The person formalizes the implicit knowledge in the form of a Requirements Document. At the same time, they never – NEVER – express the full extent of implicit knowledge but only a part of it, which in their subjective opinion, is necessary and sufficient for the understanding of the requirements for the IT solution. It is only a person with the same completeness of implicit knowledge about the subject matter, will understand the idea, concept, and the solution in more or less the same way as the person who authors the document. The thing is, even someone from a different department in the same company would have a different extent of implicit knowledge about the same solution.
3. Distribution. By means of sending out the Requirements document and requesting quotes from different, say, 3 software development teams, the person relays a portion of the formalized knowledge.

   Picture 2 – The perception of the requirements for the IT solution by the software development teams.

    

   The corresponding teams in different companies perceive the software requirements in the light of their own experience and circumstances and suggest implementations accordingly. As a result, the person collecting the quotes receives offers outlining the implementation and cost of 3 different solutions NOT 3 estimates of the same solution.

4. Applied Use of Knowledge. Once the client decides in favor of one of the software teams, they discuss and adjust the requirements, clarifying and revealing the implicit knowledge the client operated with to put the requirements together in the first place.

How to formalize the knowledge?

In my opinion, to get the full picture one should examine the IT solution from a minimum of 5 projections. To help with drafting a requirement document, the following is a list of projections or questions one should ask first.

1. Consider the IT Solution to be a part of a system and describe the system concerning how people work, what tasks they perform, what difficulty they face, etc.
2. Functional projection: who are the main stakeholders using the IT Solution and their user roles in the IT Solution?
3. Non-functional projection: what are the technical characteristics of the system that will influence and affect the IT Solution?
4. Business projection: what are the goals of the main stakeholders, whereby the goal is formulated as the means and the result.
5. Visual projection: create the prototype of the IT Solution (provided you have enough analytical and research data).

This list may vary depending on the industry and overall goals and objectives, etc. The point I am trying to make here is the methodology behind the approach so the list can be adjusted. The following list describes the situations in which you may find yourself before seeking out software development services.

1. You have an intention to do something useful, but you don’t understand what it is.
2. You know there’s a problem, but you don’t have a solution, and you’re trying to figure out what’s wrong. So you’ve analyzed the situation around the problem, you’ve seen the elements of disconnect, but you haven’t figured out what kind of solution, or what kind of technology is going to fix the disconnect. You also don’t know if it’s worth taking action at all to address this problem.
3. You have analyzed the situation and found a disconnect, as well as figured out a way to address it and what the desired outcome should be. That is to say, you have set a goal, but so far you don’t have a clear, structured solution. Moreover, you have faced a lack of resources: skills, human resources, technological, material, etc.
4. There is a vision of the ultimate solution, which is formulated through the goals (a goal is defined as a combination of the means and the result), outlined the first action point according to the desired outcomes.
5. You have a solution that has been considered and determined in its entirety with respect to a minimum of 4-5 items listed above.
6. You may feel that neither of the above situations applies. Unless you are not looking to implement an IT Solution and measure the effects from its implementation, you may consider the above points carefully as they are more likely to apply.

Your goal is to arrive at step 4 or 5. At each stage, you must necessarily produce and accumulate knowledge. You should have both formalized and non-formalized products of your activity: graphs, descriptions, personal skills and experience of how it works, descriptions through various projections described above. And when you come to step 4, your task is to spread the knowledge – to pass it on to your contractors and partners. The knowledge distribution stage most often contains the following procedures: analysis, discussion, and assimilation. Sending out the requests for quotes based on the requirements document is like shooting in the dark. Ask yourself a question – do you do the following when transferring knowledge of the situation to a software company:

• analyze formalized and non-formalized knowledge of the object or solution you’re looking to be developed,
• discuss with the development team formalized and non-formalized knowledge of the object of the transfer,
• assimilate the knowledge.

If you look to contract a software development company then you should research the potential service providers. Thus it is highly recommended to apply the systematic analysis such as described above.