The post has been translated automatically. Original language: Russian
Most conflicts with the customer in IT projects do not arise at the moment of disagreement, but much earlier — at the moment when the project manager prefers not to specify the wording so as not to seem picky, or agrees with a vague requirement so as not to delay the meeting. Each such omission seems insignificant, but the accumulated effect manifests itself after a few weeks — in the form of a claim for the amount of work that no one explicitly agreed upon. Avoiding an uncomfortable conversation at the start systematically leads to a more serious conflict at the finish.
Three formulations worth clarifying
Certain phrases of the customer regularly lead to a discrepancy in expectations if the project manager takes them literally and does not specify the details.
The general principle is that any formulation that can be interpreted in more than one way must be clarified before being included in the scope, and not after starting work on it. The clarifying question is perceived by the customer not as a quibble, but as a manifestation of professionalism — provided that it is asked calmly and to the point, and not in the form of an objection.
How to react if you don't want to conflict
Managers who try to avoid conflicts usually intuitively choose an action that seems safe at the moment, but creates a risk in the long run. Below are typical instinctive reactions and what works best in practice.
- Instinct tells us to keep silent about the agreements, relying on the memory of both sides. In practice, the opposite works: a short written summary immediately after the meeting removes most of the future disputes about what exactly was discussed, and does not look like distrust of the customer.
- My instinct is not to mention deadlines when discussing a new wish, so as not to seem unyielding. In practice, it is more effective to say right away: "if we add this item, the deadline is shifted by a week" — what is said at the moment is perceived as a fact, and not as an excuse in hindsight.
- My instinct is to write down all the customer's wishes without prioritizing them, so as not to appear to be rejecting them. In practice, it is more important to explicitly separate the required and desirable functionality, otherwise a dispute about readiness for delivery is almost inevitable.
- Instinct tells us to meet less often, so as not to bring up uncomfortable topics once again. In practice, a short weekly synchronization reduces the risk of discrepancies accumulating more than one detailed report once a month.
- Instinct tells us to formulate a refusal as a prohibition — "this is not within the scope of the project." A more workable option is to offer an alternative: "this can be implemented in a separate stage, the assessment will take a day" — this is how relationships are preserved and boundaries are defined at the same time.
Managing customer expectations is not about avoiding difficult topics, but about raising them at a time when the price of the issue is minimal. The checklist above does not eliminate disagreements completely - they are a normal part of any project — but it moves the moment of their discovery to the earliest possible stage, where the decision is worth an hour of discussion, not a week of rework.
Большинство конфликтов с заказчиком в IT-проектах возникают не в момент разногласия, а значительно раньше — в момент, когда менеджер проекта предпочитает не уточнять формулировку, чтобы не показаться придирчивым, либо соглашается с расплывчатым требованием, чтобы не затягивать встречу. Каждое такое умолчание кажется незначительным, однако накопленный эффект проявляется через несколько недель — в виде претензии по объему работ, который никто явно не согласовывал. Избегание неудобного разговора на старте систематически приводит к более серьезному конфликту на финише.
Три формулировки, которые стоит уточнять
Определенные фразы заказчика регулярно приводят к расхождению ожиданий, если менеджер проекта принимает их буквально и не уточняет детали.
Общий принцип: любая формулировка, которую можно интерпретировать более чем одним способом, обязана быть уточнена до включения в скоуп, а не после начала работы над ней. Уточняющий вопрос воспринимается заказчиком не как придирка, а как проявление профессионализма — при условии, что задается спокойно и по существу, а не в форме возражения.
Как реагировать, если конфликтовать не хочется
Менеджеры, которые стараются избегать конфликтов, обычно интуитивно выбирают действие, которое кажется безопасным в моменте, но создает риск в перспективе. Ниже — типичные инстинктивные реакции и то, что работает лучше на практике.
- Инстинкт подсказывает промолчать о договоренностях, полагаясь на память обеих сторон. На практике работает противоположное: короткое письменное резюме сразу после встречи снимает большую часть будущих споров о том, что именно обсуждалось, — и не выглядит как недоверие к заказчику.
- Инстинкт подсказывает не упоминать сроки при обсуждении нового пожелания, чтобы не показаться неуступчивым. На практике эффективнее сказать сразу: «если добавляем этот пункт, срок сдвигается на неделю» — сказанное в моменте воспринимается как факт, а не как оправдание задним числом.
- Инстинкт подсказывает записать все пожелания заказчика без приоритизации, чтобы не показаться отказывающим. На практике важнее явно разделить обязательный и желательный функционал — иначе спор о готовности к сдаче почти неизбежен.
- Инстинкт подсказывает встречаться реже, чтобы лишний раз не поднимать неудобные темы. На практике короткая еженедельная синхронизация снижает риск накопления расхождений сильнее, чем один подробный отчет раз в месяц.
- Инстинкт подсказывает формулировать отказ как запрет — «это не входит в рамки проекта». Более рабочий вариант — предложить альтернативу: «это можно реализовать отдельным этапом, оценка займет день» — так одновременно сохраняются отношения и обозначаются границы.
Управление ожиданиями заказчика — это не про избегание сложных тем, а про то, чтобы поднимать их в момент, когда цена вопроса минимальна. Чек-лист выше не устраняет несогласия полностью — они являются нормальной частью любого проекта, — однако переносит момент их обнаружения на самую раннюю возможную стадию, где решение стоит часа обсуждения, а не недели переделки.
Share
