Что такое вехи в проектном управлении? Управление по вехам

Работать с вехами можно в любом современном программном обеспечении для управления проектами – ИСУП (информационная система управления проектами). Вехи можно использовать, даже если вы управляете проектами при помощи Excel. В этой статье мы будем показывать примеры из своей практики и своей системы Корадиум.

Функционал создания вехи в Корадиуме:

Что такое вехи и почему они так важны?

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

• Блок процессов закупок принят заказчиком

• Остатки загружены и утверждены

• Обучение проведено

• Акт подписан

• Аванс получен

Обратите внимание, у всех этих примеров однозначный статус – сделано или нет. Веха не может быть «сделана на 65%».

Вехи помогают РП (руководителю проекта), команде, руководству компании и отделов понять, что проект движется по графику, вовремя определить наличие возможных рисков.

Предположим, в проекте есть 100 вех, а плановый срок проекта 6 месяцев, из которых 3 месяца прошло. Если пройдено 50 вех, есть вероятность, что проект идет по плану. Если 25 – почти наверняка в проекте проблемы. А если 90 вех позади? Либо мы идем с большим опережением, либо у нас ситуация как в анекдоте:

– Не так страшны первые 90% проекта, как вторые 90%.

Отклонение от графика, просроченная веха, почти наверняка означают, что сработал один или несколько рисков. Вехи помогают увидеть такое отклонение ещё на раннем этапе, пока не поздно исправить ситуацию и наверстать план.

Как выглядит отображение повторяющегося переноса сроков в Корадиуме:

Критерии, которым должны отвечать вехи

Чтобы вехи не были простой формальностью, а приносили реальную пользу, они должны отвечать нескольким критериям:

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

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

Пример формулировки конкретной вехи в Корадиум:

2. Измеримость. Косвенно связано с предыдущим пунктом, но подходят для того, что может быть количественно определено. Например, «в ходе тестов система успешно обработала 1000 транзакций на складе без ошибок» – результат, который можно измерить и доказать.

3. Равномерность. Вехи должны быть равномерно распределены по плану этапа и проекта. Причем равномерность относится не только к срокам (ставим веху каждую неделю). Но и к сути, к содержанию выполняемых задач.

Если вы впервые внедряете в свой проект управление по вехам, возможно, вам придется изменить сам план, последовательность задач. Важно помнить: веха должна финализировать, «отсекать» выполненную, законченную и принятую работу. Это помогает избежать ситуации, когда 90% прогресса достигнуто за месяц, а на оставшиеся 10% нужен ещё один.

Расскажем на нашем примере. Около 7 лет назад, мы начали внедрять управление по вехам, и в своем первом после этого решения проекте расставили вехи. Вот что получилось:

Одним из этапов проекта является «Обследование». В ходе этапа проводятся интервью по блокам «Закупки», «Продажи», «Склад и доставка», «Производство», «Себестоимость» и «Финансовый результат». Затем собранная на интервью информация систематизируется, уточняется, и благодаря работе бизнес-аналитика превращается в схемы и описания бизнес-процессов. Результатом этапа является документ «отчет об обследовании», который мы передаем клиенту на прочтение. В ходе изучения у клиента всегда возникают вопросы и уточнения. Как правило, мы уточняем и детализируем процессы в плотном контакте с заказчиком, пока он не признает, что это «его процессы», и он готов так работать.

На такой план мы расставили вехи примерно так:

• Интервью по блоку «Закупки» выполнены

• Интервью по блоку «Продажи» выполнены

• …

• Документ «Отчёт об обследовании» написан и передан заказчику

• Заказчик вычитал документ и прислал 1-е правки

• …

Вехи постарались расставить равномерно.

Какой получился результат?

Примерно до 80% этап шел четко по плану, и пройденные вехи это подтверждали. Мы анализировали небольшие отклонения, работали с ними. Все как в книгах.

И вот наконец мы отдали собранный документ заказчику. Веха «заказчик вычитал документ и прислал 1-е правки» задержалась в 3 (три!) раза – мы ее прошли не через неделю, а через три недели. Последние 20% проекта шли еще 2 месяца: документ давался заказчику тяжело, правки и вопросы приходили не за один раз, слоями, один за другим. Сотрудники клиента не могли договориться друг с другом – пришлось помогать им, организовывать их.

Кажется, управление по вехам не сработало.

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

Теперь в том же этапе вехи такие:

• Интервью по блоку «Закупки» выполнены

• Результаты обследования блока процессов «Закупки» переданы заказчику

• Интервью по блоку «Продажи» выполнены

• Обследование блока процессов «Закупки» принято заказчиком

• Результаты обследования блока процессов «Продажи» переданы заказчику

• …

• Обследование блока процессов «Продажи» принято заказчиком

• …

• Объединенный документ «Отчет об обследовании» принят заказчиком

В этом варианте расстановки вех в плане, каждая веха «отсекает» работу, которая точно закончена, и, скорее всего, не «вернется» обратно.

Пример планирования вех в Корадиуме:

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

Проблемы использования вех и их решения

1. Недостаточная детализация вех

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

Пример недостаточной детализации вехи:

2. Слишком много вех

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

Руководитель проекта пытается управлять по вехам. Он расставил их в проекте после каждой группы задач: 2-3 задачи – веха, 2-3 задачи – веха. Но это излишняя детализация. Вехи должны «отсекать», однозначно завершать существенную работу, группу задач, результат которых имеет ценность для клиента.

3. Отсутствие регулярного мониторинга.

Без постоянного контроля руководителя за прогрессом, можно упустить момент, когда ещё не поздно выявить существующую проблему. Даже если распределить вехи в плане проекта совершенно правильно и четко, но после запуска проекта не заглядывать туда, не считать число пройденных вех относительно оставшихся, не анализировать скорость хода проекта – такой план по вехам был сделан «в стол», он не повышает управляемость.

Пример отображения предупреждения о неоднократном переносе сроков вехи в АРМ «Вехи и риски» в Корадиуме. Напротив такой вехи появляется предупреждение в виде восклицательного знака:

4. Отсутствие связи вех и рисков, работы с рисками.

Руководитель проекта осуществляет мониторинг вех, но из него делает выводы лишь о том, идет ли проект по плану, или задерживается. При задержке пытается предпринимать действия для ускорения проекта не системно, не думает категориями рисков и управления рисками.

Пример из отраслевой практики. Запущен проект по автоматизации управления цепочкой поставок в производственной компании. На этапе интеграции с системой складского учёта происходит значительное отставание.

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

В итоге ситуация повторяется, отставание от графика увеличивается.

Справочник рисков и связь вех и рисков в Корадиум:

Заключение

Вехи – не просто контрольные точки в проекте, которые отслеживаются «для галочки». Это ключевой инструмент, который помогает эффективно управлять проектом.

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

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

Оставьте заявку нашим специалистам, если хотите получить больше информации о нашей системе управления проектами.