Саботаж команды во время проекта

Те, кто на ежедневной основе управляют проектом, часто сталкиваются с типичными проблемами. Независимо от того большой проект или нет, внутренний или для внешнего заказчика и при любой выбранной методологии, вам нужна сплоченная команда.

Доверие в проектной команде – на мой взгляд, недооцененный фактор успеха. Чаще оценивают силу команды по составу ее участников. Но если каждый эксперт начинает играть сам на себя, то о командном успехе мечтать не приходится.

Как проявляется саботаж

Итак, давайте представим, что потенциально сильная команда «вдруг» начинает саботировать проект. Сначала о том, в чем это может проявляться:

Любые управленческие решения слишком много обсуждаются командой, есть несогласные.
Задачи не реализуются в срок систематически, т.к. «в ходе реализации решил/решила, что нужно по-другому».
Ресурс проектной команды все время расфокусируется. Например, если сотрудник участвует в нескольких проектах, ресурс все время «утекает» на другие проекты, вразрез ресурсному плану. А если проект один, то все время нарушаются приоритеты.
Участники проекта отказываются делать задачи по причине отсутствия опыта/компетенций. Такое бывает с неплановыми задачами или, когда меняется участник проекта.

Его последствия

Следствием таких шагов со стороны команды мы имеем:

падение авторитета руководителя проекта,
отставание от графика,
возможное снижение качества,
недовольного заказчика проекта,
и скорее всего ухудшение экономики проекта.

Что делать

А чтобы понять, что делать, нужно разбираться в возможных причинах происходящего:

Прежде, чем обсуждать с участниками нарушения правил игры, нужно сначала сформулировать и утвердить эти правила . Поэтому вам для начала предстоит ответить на вопрос: есть ли в вашем проекте документ с описанием ролей каждого участника (например, устав проекта или матрица RACI)? Если такой документ есть, то читал ли его кто-либо из вашей команды? Обсуждался ли документ внутри? Такие вещи требуют валидации, иначе участники могут не принять ваши правила.
Важным фактором успеха является авторитет руководителя проекта. Если он на высоком уровне, то договориться с командой вам гораздо проще и вероятность саботажа низкая. Если авторитета нет, его нужно заработать путем принятия правильных решений, а также их обязательному разъяснению команде. Ведь если все участники знают и понимают причины возникновения задачи, то ни у кого не возникнет вопроса, нужно ли ее выполнять. Мы часто заточены на управление ожиданиями наших клиентов, но забываем, что такой же процесс нужен и с обратной стороны – внутри команды. Так что я очень рекомендую уделять этому внимание на внутренних статусах с командой.
Следствием предыдущих 2 пунктов является тот факт, что экспертиза и власть не должна быть сосредоточена в одних ваших руках. Привлекайте технических и бизнес экспертов к обсуждению вопросов их компетенции, формируйте совместные гипотезы и решения, заручайтесь их поддержкой. Если вы принимаете решение на основании мнения экспертов, вероятность его успеха выше, чем в случае ваших единоличных решений. Особенно в спорных ситуациях.
В случае если протест идет со стороны только конкретных людей, но не команды, лучше пообщаться с каждым индивидуально и для начала – услышать доводы вашего собеседника. Ведь умение слушать – важный инструмент руководителя. А уже услышав, делать выводы.

Итак, если все процедуры, описанные выше, проведены, то вы уже понимаете:

Кто и за что отвечает и как к этому относится.
Какие есть принципиальные для разрешения вопросы в команде.
Какие есть экспертные мнения по разрешению вопросов, их сторонников и противников.
Готовность команды двигаться за вами в качестве лидера этого проекта.

На мой взгляд, когда есть такая ясность, можно действовать. С одной стороны – решать задачи проекта, с другой – работать над микроклиматом в команде.

Никогда не бывает слишком поздно, чтобы заняться созданием сплочением команды!