Управление ожиданиями на проекте

Дмитрий Изыбаев, IT-компания Lad

Ожидания есть у всех — и у заказчика, и у исполнителя: как и для чего ими управлять? Как сделать так, чтобы они стали реальностью? Могут ли неправильно сформированные ожидания послужить причиной провала проекта? Опираясь как на успешные кейсы, так и на неудачные примеры из практики проектных команд, постараемся в статье дать ответы на вопросы.

Что такое ожидания?

Что может быть хуже неподписанного акта или непринятых работ? Правильно, недовольный заказчик. Вроде и работы сданы в срок, и система запущена в эксплуатацию, а заказчик (пользователь системы) разочарован, потому что система хоть и работает, но не так, как он себе представлял. А нам об этом сказать забыл. Или мы не уточнили, как будет удобнее конкретному пользователю.

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

Таким образом, помимо формальных требований, зафиксированных в договоре, необходимо учитывать пожелания ключевых участников проекта. При этом важно, чтобы исполнитель не превратился в «золотую рыбку», стремясь угодить каждому. Как же соблюсти эту тонкую грань?

Управление ожиданиями — это приведение всех заинтересованных лиц к единой картине мира, когда все одинаково понимают, что происходит на проекте и какой результат будет на выходе.

Причины «неудачных» проектов

На проектах возникают сложности при взаимодействии с заказчиком, потому что:

• на старте не согласовали требования к проекту и не зафиксировали их в договоре:
  Например, запрос заказчика звучит так: «Нужно перейти на ERP». Первое, что делаем на входе в проект, выясняем: кому нужно? кто является владельцами бизнес-процессов? каковы их цели?
• исполнитель и заказчик по-разному трактуют цели и задачи проекта:
  Например, генеральный директор хочет прозрачности в процессах отдела продаж. Что это может означать в рамках проекта по внедрению? Начальник отдела продаж видел это как возможность мониторить в режиме онлайн, сколько звонков совершает каждый сотрудник, сколько заказов оформляет, как продвигается по выполнению ежемесячного плана, есть ли дебиторская задолженность. В ходе совместных переговоров мы пришли к единому пониманию целей проекта и согласовали перечень отчетов.
• отсутствует единый подход и методология на стороне исполнителя:
  Например, один консультант подготовил описание контрольного примера, структурированное, с картинкам и схемами, с описанием текущего процесса, а второй — переписал на 20 страницах учебник по внедрению ERP. Очевидно, к кому из них у заказчика не будет вопросов.
  Есть и такие случаи, когда консультант или программист не получает обратную связь от заказчика, имея возможность внести коррективы на промежуточных этапах, а демонстрирует готовое решение, которое не всегда устраивает заказчика.

Как управлять ожиданиями заказчика

• На каждом статус-совещании по возможности напоминаем цели проекта:

• как новые требования коррелируют с целями проекта?

• как ввод новых сотрудников в проектную команду приблизит нас к цели?

• как изменение процессов отразится на итоговой цели?

• Составляем реестр заинтересованных сторон, куда вносим сотрудников, определяем степень их влияния и уровень заинтересованности. Такая матрица сразу покажет лояльных и нелояльных к проекту сотрудников, а также позволит определить, к чьему мнению стоит прислушиваться особо внимательно и с кем работать плотнее, а кого на стороне заказчика достаточно просто информировать.
• Совместно с заказчиком изучаем устав проекта, где прописаны риски, и рассматриваем каждый пункт. Важно отнестись к этому не как к формальности, скопировав возможные риски из документации по предыдущему проекту, а выявить реальные риски, их владельцев, а также наметить план А и план Б по их устранению.
• «Сверяем часы» — проводим регулярные статус-совещания и оформляем подробные протоколы, в которых обязательно фиксируем:
• дату и место проведения встречи;
• состав участников с обеих сторон;
• цель встречи;
• круг обсуждаемых вопросов;
• договоренности с указанием сроков и ответственных лиц.

В ходе таких совещаний отчитываемся о проделанной работе, намечаем план работы на ближайшее время, поднимаем проблемные вопросы, периодически уточняем цифры с владельцем бюджета. Статус-встречи позволяют управлять и корректировать ожидания заказчика на всех уровнях.

Как работать с ожиданиями команды

При работе со своей командой руководителю проекта следует опираться на два вида ожиданий:

1. То, что сотрудник (консультант или программист) ожидает от проекта, команды и руководителя проекта: сюда входит и то, сколько денег заработает специалист, и то, какой опыт получит.

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

Что может предпринять руководитель проекта, чтобы не «обмануть» ожидания команды:

• Распределить роли в команде. Мы используем матрицу RACI, в которой прописываем: кто выполняет задачу, кто помогает, а кто принимает задачу и несет итоговую ответственность за результат.
• Грамотно ставить задачи и контролировать их исполнение:
• Разработать порядок и довести его до подчиненных, убедившись, что каждый правильно понял входящую задачу и обладает ресурсами для ее реализации.
• Контролировать выполнение задач исполнения. Для этого нужно на старте установить сроки исполнения. Сейчас удобно вести учет задач при помощи таких инструментов, как 1С, Jira, Битрикс.
• Применять санкции в том случае, если сотрудник систематически «заваливает» задачи. Возможно, причина в том, что руководитель некорректно отработал по первым трем пунктам — тогда исправляем свои ошибки. Возможно, сотруднику не достает компетенций — в этом случае обучаем. Выяснить причину можно в ходе встреч 1:1 — руководитель может донести свою озабоченность, выслушать сотрудника, прийти к единому видению проекта. Если сбоит процесс, его необходимо наладить, иначе руководитель проекта так и будет заниматься микроменеджментом и вручную рулить всеми задачами.
• Скрупулезно вести проектную документацию: четко прописываем «правила игры», то есть как должен работать тот или иной процесс и какой результат мы должны получить на выходе. Проектная документация позволит руководителю поддерживать процессы и работать с ожиданиями получаемого результата.
• Донести до команды важность работы с рисками: если сотрудник видит триггеры риска, необходимо сразу поднять этот вопрос на ранних стадиях, а не тянуть до последнего.

Всегда помним, что правильно сформированные ожидания — ключ к успешной реализации проекта.