2. Привлекать интернов на задачи, где не требуется экспертиза, чтобы разгрузить старших консультантов. По каждому направлению мы привлекали от одного до трех интернов из ведущих вузов РФ: НИУ ВШЭ, МГУ, МГИМО, МГТУ им. Н. Э. Баумана, РЭУ им. Г. В. Плеханова. Это позволяло не только разгрузить дорогостоящих специалистов, но и сформировать кадровый резерв, так как впоследствии многие из практикантов получали предложения о работе.

3. Формировать более «легкую» команду, перераспределяя старших консультантов на другие проекты. В ходе проекта всегда происходит рост экспертизы младших специалистов в команде (эффект «низкой базы»). Периодически мы оценивали новые компетенции младших сотрудников, чтобы использовать их для разгрузки старших специалистов.

4. Сократить время выполнения задач, лежащих на критическом пути. Проект изменяется, поэтому полезным правилом будет регулярно проверять статус по срокам основных задач и вместе с командой переоценивать время вовлечения консультантов с учетом внешних и внутренних факторов. Параллельно блок ИТ реализует проект по автоматизации планирования производства, который окажет влияние на состав доработок вашего проекта; либо изменение законодательства накладывает требования к экологии, что влияет на ценность результатов по проекту. Поэтому своевременно замеченные новые требования позволят сократить общие сроки для компании.

5. Поднять вопросы с заказчиком по возможности дополнительных продаж «запросов на изменение (ЗНИ)» по проекту и сразу рассчитать их влияние на экономику проекта. Если вы, как проектный менеджер, прогнозируете заниженную маржинальность проекта, то рекомендуем проработать возможные дополнительные задачи в проекте и за счет этих дополнительных задач получить рост общей маржинальности проекта. Кроме того, для консалтинга всегда полезно увеличивать объемы продаж у постоянных клиентов.

6. В фазе «завершение проекта» можно сократить количество часов участников, так как уже нет нужды держать всю команду.

2.7.2. Ведение контактных данных

Чтобы новые члены команды могли быстро сориентироваться, создается единый файл, содержащий контакты членов команды со стороны клиента, консультанта и ИТ-подрядчика (см. Таблица 9).


Таблица 9 – Список контактов членов команды

2.7.3. Статусные совещания

Слайд «Статус проекта» позволяет оценить, на какой стадии находится проект относительно общего объема задач, отслеживать сроки выполнения укрупненных задач. На статусе проекта важно коммуницировать по возникшим сложностям, для этого необходимо предоставить следующую информацию:

1. Дорожная карта по проекту (см. Рисунок 11).

2. Перечень выполненных задач по проекту за прошедший период (см. Таблица 10).

3. Перечень задач по проекту на будущий период.


Рисунок 11 – Статус проекта – иллюстрация слайда 1: «Дорожная карта»


Таблица 10 – Статус проекта – иллюстрация слайда 2: «Завершенные задачи за период»


В статус проекта обязательно выносятся вопросы, требующие эскалации на руководство и блокирующие факторы, которые препятствуют развитию проекта.

2.7.4. Протокол встречи

Крайне важно фиксировать договоренности каждого совещания. Иначе непонятно зачем собирались и потратили время все участники. Если вы проводите рабочее совещание, то достаточно зафиксировать договоренности в письме и отправить по почте на всех участников. Если у приглашены различные дочерние общества, внешняя компания, то принято фиксировать договоренности формально в шаблоне протокола. Подготовьте шаблон протокола заранее до совещания (см. Рисунок 12). При начале проведения рабочего совещания необходимо четко определить, кто является ответственным за ведение протокола. Этот сотрудник во время совещания фиксирует договоренности. В случае необходимости задает уточняющие вопросы для фиксации договоренностей и поручений. Не считается зазорным уточнить, о чем договорились и какую задачу нужно фиксировать в протоколе. Напротив, это является признаком хорошего тона, означает, что вы следите за ходом совещания и цените время участников. В крупных компаниях ведутся реестры всех решений по протоколам, чтобы следить за исполнением принятых руководством решений. Чем дольше проект и больше количество вовлеченных в него участников, тем очевиднее выгодны от использования протоколов.