Quite a standard situation: in search of a contractor to develop an IT solution, a customer sends requests to several companies. Its purpose is to decide on cooperation with the contractor by collecting and analyzing proposals. The selection process is complicated by the fact that the scope of work, the proposed technologies and prices differ significantly from each other. A problem arises that is often not recognized: these proposals are not only unequal, but also evaluate different solutions.
This article offers the reader a systematic view of contractor selection. Our goal is to stimulate the search for innovative approaches to solving problems at the stage of formulating the problem and collecting estimates.
Throughout the text, the terms "IT solution" and "development object" are used interchangeably. They refer to any software (mobile, web, desktop applications, websites, etc.) that is created during the development process to achieve specific business goals of the customer. There is a term "research object" - the stage of creation of a development object until the implementation of the solution.
Situation and problem
A typical contractor selection process is as follows.
1. Terms of Reference
Part of the procurement process is a document describing the solution - terms of reference (TOR). The customer's manager is a person interested in development services (hereinafter referred to as the subject), sends the TK to several organizations. Subjects in these organizations receive TK and evaluate the work based on the specified requirements. ( How a customer gets a technical assignment - see in the paragraph “Terms of reference for the studio!” For an example of “a situation close to the ideal”)
Schematically, these relationships are as follows.
2. Response from organizations and analysis of proposals
The customer receives offers from potential contractors. Proposals are a document format in which the scope of work, deadlines, cost estimates, description of experience and team expertise are most often indicated. The proposals are studied and compared with each other according to a number of criteria.
3. List of selected organizations
Based on the analysis of proposals, the list of potential contractors is being reduced. The final choice is made after communication with each of them and discussion of the submitted documents.
4. Contract
Signing a service contract with a selected contractor.
Often at stages 2 and 3 a problem arises: this is evidenced by my experience of cooperation with small and medium-sized businesses. Proposals with a different composition of work and differing estimates create the illusion that this data is sufficient for making a decision. At the same time, the selection criteria are reduced to the cost and scope of work.
In my opinion, this approach does not provide a condition for completeness and sufficiency of information for making a decision. There is no conscious understanding of the situation and the presence of an “incomplete” process of transferring knowledge about a potential solution between the two subjects.
Terms of reference for the studio!
Technical assignment (TOR, technical assignment) - a document containing the customer's requirements for the procurement object. The TK determines the conditions and procedure for the procurement, in accordance with it, the delivery of goods, the performance of work, the provision of services and their acceptance are carried out.
I will try to complete the definition.
The terms of reference is a set of artifacts through which formalized knowledge about the procurement object in this context is transferred - knowledge about the created IT solution.
In order to analyze steps # 1-3, let's now briefly construct a close to ideal situation of step 1. At the moment, there are many GOST standards on the market for writing technical specifications for the development of information systems. I will not describe them, they are all well developed and have their pros and cons.
Suppose the client, to determine the optimal solution, looked at the research object from different angles. By examining different projections, you can find the optimal solution. One-sided projection will not show the full picture. As in the illustration below, a cylinder is a square in one projection and a circle in another. For different people, the solution to the same problem will be different.
You can also come to an optimal solution through a systematic analysis of the problem, by examining an object with functional, genetic, dynamic, procedural projections.
Scheme 1 - Projections of the object examination based on the 2nd concept of the system according to Dubrovsky.
I will not dwell on this approach, but I can share in the comments my experience of application in practice, if there are requests.
Thus, after certain actions, the subject has formed the Knowledge of how to solve the problem. Knowledge may be insufficient, and problems may be different on the way to the goal, but knowledge exists in a certain volume.
How do we transfer knowledge about the solution?
Learning - the acquisition of knowledge, skills, skills - occurs in several stages: production, accumulation, distribution, use.
Figure 2 - Learning Steps
Consider this diagram in relation to the process of interaction with contractors.
- Implicit knowledge production. Manufacturing is the collection of information from various sources: consultants' recommendations, competitor research, personal experience in developing IT solutions, information about the organization of objects around the problem under study, and much more. Implicit knowledge is not formalized, i.e. not expressed in any way. In simple words, implicit knowledge is in the memory of the subject, the manager of a company interested in development.
- . . , — ! — , , , , . , , , , , - , . , . .
- . , . , (, , ..). . , , , N ( ).
3 — . - . , , , , .
Checklist of projections for formalizing knowledge and describing situations preceding the selection of a contractor
To help managers and managers avoid mistakes when creating and transferring technical specifications for assessment to IT contractors, I propose a list of projections to formalize knowledge about an IT solution and a checklist with descriptions of situations that will help apply the “learning stages” scheme I have described.
In my opinion, an IT solution should be considered from at least 4-5 positions to get the most complete picture.
Checklist No. 1 - "List of projections"
- Description of the situation around the object within the framework of the activity at the time of the study: how people work, what types of activities they perform, what difficulties arise, etc.
- Functional projection regarding the main roles in the solution.
- Non-functional projection with model of technical characteristics influencing the decision.
- Business projection in relation to the main stakeholders, where the Objective is formulated through the Method and the Result.
- Visual projection of the solution prototype (provided that you have already passed the research stage on the prototype).
Of course, there may be more positions and projections, and someone will say that this checklist will change in relation to the industry, tasks, etc. ... Most likely this will be so, but my main task is to focus on the methodological foundations. So they can be used everywhere, and create checklists for each situation.
Types of situations in which a manager may find himself before attracting contractors:
- You have a desire to do something useful, but do not understand what exactly.
- , . .. , , , . , .
- , , . .. , . , : , , , ...
- , ( = + ), 1- , - №1.
- , 4-5 , - № 1.
- , - . , 1-5 .
Your task is to come to point 4 or point 5. At the same time, at each stage, you must necessarily produce knowledge and accumulate it. You should have both formalized and non-formalized products of your activity: diagrams, descriptions, personal skill and experience of how it works, descriptions through the positions of checklist number 1. And when you come to point 4, then your task is to disseminate knowledge - to transfer it to your contractors and partners.
The dissemination stage most often contains the following procedures: analysis, discussion and assimilation.
If you simply sent the TK to contractors in order to look at prices and analyze the scope of work, then this is tantamount to trying to sit on a chair without putting it under your butt. Someone may be lucky and he will sit down, but for someone there will be unpleasant consequences =)
So, ask yourself a question: how, when transferring knowledge to a contractor regarding your situation, you:
- analyze formalized and non-formalized knowledge about the transfer object
- discuss with the contractor formalized and non-formalized knowledge about the transfer object
- assimilate this knowledge.
Some of the readers will say that it is difficult and often physically impossible to carry out these procedures when sending out TOR and collecting prices from contractors. I completely agree with them. But it makes me think that the goals are formulated incorrectly.
If I need to find a contractor, then the search should take place through the research of contractors. Therefore, we can apply the same systems analysis and, for example, pattern # 1, to plan a program to achieve this goal. And most likely the tasks will change and will be very different from the steps described in the “Situation and problem” section.