Страница 11 из 30
2.7.1. Мониторинг бюджета
Насколько менеджеры проектов управляют бюджетом? Может ли менеджер сразу ответить на вопрос о маржинальности проекта на конкретную дату и сделать прогноз маржинальности проекта по его завершении?
Чтобы добиться «управляемости», мы разработали простой инструмент для прогнозирования финансовых показателей по проекту. Для удобства планирования бюджета используется единый стандарт расчета: в модель необходимо внести данные по команде, а также запросить фактические затраты у ответственных служб компании (например, финансового контроллинга) (см. Рисунок 9).
Рисунок 9 – Расчет стоимости проекта по ставкам консультантов
Чтобы контролировать возникшие затраты на проекте, используется шаблон прогнозирования маржинальности проекта (см. Рисунок 10).
Рисунок 10 – Пример прогнозирования маржинального дохода по проекту
Имея информацию по прогнозу расхода, руководитель проекта получает возможность влиять на итоговую экономику проекта, используя в том числе следующие пути улучшения маржинальности:
1. Привлекать к работе экспертов рынка на точечные задачи по схеме гражданско-правового характера (ГПХ). Так, на внешний договор мы привлекали экспертов SAP, чтобы решить несколько специфических задач, но при этом экспертиза не требовалась на протяжении всего проекта; технических специалистов с большим опытом работы в логистике для консультации по проектированию складов или транспортных решений; технических специалистов для нормализации записей нормативно-справочной информации (НСИ).
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). При начале проведения рабочего совещания необходимо четко определить, кто является ответственным за ведение протокола. Этот сотрудник во время совещания фиксирует договоренности. В случае необходимости задает уточняющие вопросы для фиксации договоренностей и поручений. Не считается зазорным уточнить, о чем договорились и какую задачу нужно фиксировать в протоколе. Напротив, это является признаком хорошего тона, означает, что вы следите за ходом совещания и цените время участников. В крупных компаниях ведутся реестры всех решений по протоколам, чтобы следить за исполнением принятых руководством решений. Чем дольше проект и больше количество вовлеченных в него участников, тем очевиднее выгодны от использования протоколов.
Рисунок 12 – Иллюстрация шаблона протокола встречи
2.7.5. Ежедневное планирование
Хорошей практикой оперативного планирования и приоритизации задач стал agile-подход, работа со спринтами и ежедневные стендапы. Это не дань моде, а реально работающий подход, который помогает минимизировать трудозатраты на формирование и поддержание планов работ в Excel. К тому же облачные технологии инструментов agile позволяют одновременно работать всем участникам и с любых устройств. Например, Trello, Jira, Yandex Tracker.
Подход использования готовых онлайн-решений прост и понятен:
Шаг 1:
из дорожной карты выделяются ключевые вехи с образом результата.
Шаг 2:
перед планированием первого спринта формируется перечень (backlog) задач, которые необходимо реализовать в рамках этой вехи. Это делается руководителем проекта совместно с руководителями модулей.
Шаг 3:
происходит планирование спринта. Максимальная длина спринта не должна превышать две недели, иначе теряется оперативность. Намечать планирование лучше на утро понедельника и обязательно проводить всей командой. Время на планирование: 60–90 минут. Подход простой: из backlog’а выбираются задачи, которые, по оценке рабочей группы, необходимо реализовать. При этом задачи на спринт формируются таким образом, чтобы каждая длилась не более двух-трех дней. В противном случае она должна декомпозироваться. У каждой задачи есть срок, ответственный и образ результата.