Unfortunately, the conflict that occurs at the final stage of the project is laid at the initial stages. And both sides of it are laid. Let's look at a few situations in more detail.

In any project, we deal with two visions of the project: the expectation of the customer and the representation of the performer.

The customer's expectations are their subjective vision of the future project and the work they expect, as well as their experience in implementing such projects. You can't demand professional knowledge from the customer, but you can expect a professional approach from them. The task of the contractor is to collect as much information as possible about these expectations and define the project boundaries that will suit the customer.

In addition to meeting expectations (if the performer does not want this to be their last project with this client), it is desirable to exceed them (as many books on client orientation have been written about, for example, Carl Sewell's “Clients for life”).

The performer's representation consists of collected information and experience in solving such tasks (sometimes template solutions become a significant obstacle to understanding the project's features).

The discrepancy between these two visions will remain in any case, and it is the task of both sides to reduce this difference as much as possible.

1. If the performer has not collected information about the client's expectations, the picture will look something like this.
2. Or so, if the performer is not sufficiently immersed in the client's” theme " and thinks in their own templates or standard means of the system in which they will implement the product.
3. An almost impossible scenario in which the customer knows almost nothing, and the performer is over-responsible.
4. The most common pattern. In which there is a zone on both sides that the other side does not know about.

Let's go into a little more detail. If the technical task is written by the performer, its representation will almost exactly match the boundaries of this TOR (diagram on the right). But not rare cases in which those. the task is developed by a third-party company, so it is possible to deviate from both existing points of view. So the vision of the project is just as important (diagram on the left) - it is always closer to who will use the product.

“Asteroid belt”

The contractor always provides a certain risks, such as in pricing, and in the drafting of the document. In this way, there is a small area of work outside the TOR that the contractor has put in the project, but not described in the documents.

It is important to note that the performer is already ready to go to work that will fall in this area (the"asteroid belt"). But until the project is completed, you do not know what kind of work can be “placed” in it, so we recommend that you do not insist on the implementation of a particular wish, but save them until you receive the main points of those. tasks.

Let's look at what these tasks are that can fall into this “belt”.

1. A border issue that is implicit in the TK, but not explicitly described.
2. A question related to the project, but very indirectly, the chances of including its implementation in the project are 50/50-it all depends on your ability as a negotiator.
3. This is usually the case for questions that are not explicitly described, but are a certain standard in the market.
4. A major task that goes beyond the TOR, here you are likely to be rejected by the performer.
5. Functionality not related to the project and not mentioned before-the chances of including it in the project are zero.
6. Functionality not covered in the tor, which looks like a small wish, but requires significant effort to implement. For example, a slightly different search algorithm. The contractor will refuse to implement this point in the project at all costs.
7. "Grey point" - a point or section that is very implicit or concise. The presence of such items shows the unprofessionalism of the performer, sooner or later he will give in and implement the functionality, but this may negatively affect your further relationships. In this case, we recommend that both sides compromise.

Who is a professional customer

No, this is not the customer who launches the 10th project, provides all the information himself, and is loyal to mistakes (because everyone makes them). There are such people, but it's easier for them to do everything themselves - why do they need you?

The customer's professionalism is shown in several ways:

• Ability to delegate-decision-making is not tied to 1 employee (Director), who can give feedback for 3 days, but is delegated, sometimes depending on the type of questions.
• A transparent decision - making scheme follows from the first, but sometimes even the CEO takes a time-out to approve the project with the business owner or investors. This is a normal situation, but you need to know about it and take it into account when approving it.
• The client is able to listen to the opinion of professionals - it is not just about the performer. The case when the client is able to focus not only on their vision, but also listen to specialists, their own or third-party.
• The project has a KPI. In addition to the project's KPI after launch, there is the project's implementation KPI. In the normal case, there are only 3 indicators: time, cost, and functions (or the value of functions). If the client proceeds only from the formal characteristics of the project, and not from the achievement of the goal for which the project is being implemented, then the risks for the performer in such a project increase.

I hope that this knowledge will help you avoid problems in your projects and allow you to look at the situation through the eyes of your partner.