В проектах постоянно срываются сроки. Почему так происходит, как правильно работать с расписанием и какие подходы к планированию помогут избежать выхода проекта за временные рамки — об этом рассказывает Елена Филипова, сертифицированный специалист по управлению проектами PMP, автор курсов и книги по проектному менеджменту.
Проблемы неисполнения сроков
Сейчас многие проекты используют гибридные методы управления: scrum-команды, Agile. В них много гибкости, но нет четких дедлайнов. Это навевает мысль, что сроки не так уж и важны.
Но если сроки нарушаются, компаниям сложно достигать своих стратегических целей. А при переносе дедлайна приходится пересматривать модель окупаемости. В итоге непонятно, что вообще делать с проектом: продолжить, потому что в него уже много вложили, или остановить, потому что проект не окупится.
Если проектов много, они могут финансировать друг друга: один закончился, переложили деньги в другой. Обратная сторона — кассовые разрывы из-за задержки закупки и оплаты выполненных работ.
Когда срываются сроки, руководители недовольны, сотрудники ощущают давление со стороны менеджмента. Возникают конфликты, что приводит к оттоку персонала.
По международному стандарту управления проектами (PMBoK), когда вы на этапе идеи и входа в проект озвучиваете сроки, они на самом деле очень далеки от реальности.
Исключение составляют проекты по возведению сложных инженерных конструкций, строительству самолетов, где есть госстандарты и план с заранее известными сроками. Но в большинстве компаний это не так. Решение о том, выполнять или не выполнять проект, чаще всего принимается, когда сроки даже не проработаны с исполнителями.
А когда план проработан, задача декомпозирована, спущена до исполнителей, и они понимают, что делать, оценивают, планируют — вот тогда погрешность оценки будет либо на 10% больше срока проекта, либо на 5% меньше.
Даже если у вас есть план, сроки могут отличаться. Например, проект запланирован на год, по стандарту вы можете не вписаться на 1,5 месяца. То есть сроки всегда неверны на входе. Если кто-то вписался — это скорее «ошибка выжившего». Ну а как реализуется план в реальности можно охарактеризовать картинкой ниже.
Почему сроки могут быть неверны
Причин для этого много:
- Их в чистом виде спускают сверху без обсуждения с исполнителями.
- Если в компании нет четкого процесса получения решения сверху, сроки не будут выполнены из-за длительных согласований.
- Не зафиксирована ответственность за исполнение работ: не персональная или исполнители не подчиняются ответственному.
- Большая неопределенность результатов, много изменений. Часто в проектах есть инновационная часть, но нет специалистов для оценки дедлайнов и отсутствует понимание технического исполнения. Например, проекты по Agile не гарантируют выполнение в срок, потому что работа в них построена в формате гипотеза-проверка. А спринты это вообще не про пунктуальность.
- Слабая коммуникация. Когда отсутствует проработка рисков и обратная связь с заказчиком, приходится постоянно переделывать.
- Низкая мотивация. Мотивация за исполнение срока проектных работ не определена, при этом исполнители работают в матричной структуре (в своем отделе и на проекте).
Как оценивать сроки и успевать
Для успешной оценки сроков, нужно выполнить несколько шагов.
Один из способов рассчитать сроки, который я постоянно использую в своей практике — метод PERT. Он учитывает оценку по трем вариантам: оптимистичный прогноз (O), наиболее вероятный (M), пессимистичный (P). Формула: PERT = (P + 4M + O) / 6
Например, для вашей задачи есть такие оценки:
2 часа — оптимистичный срок O
8 часов — наиболее вероятный M
24 часа — пессимистичный прогноз P
Вероятный показатель умножаем на 4, прибавляем к нему оптимистичный и пессимистичный прогноз и делим на 6. Так получаем оценку сроков по методу PERT.
Если же на входе в проект, вы неправильно оценили сроки и в процессе выполнения поняли, что не успеваете, вам нужно ускорить реализацию проекта.
Как ускорить выполнение проекта
В международной практике существуют всего 2 метода для ускорения сроков проекта.
Метод сжатия — привлечение дополнительных ресурсов для работ, находящихся на критическом пути. Нужно добавить исполнителей, увеличить количество или качество техники либо перераспределить ресурсы с задач с не приоритетными результатами.
Как выполняется метод сжатия:
- Оцениваете возможность разделения задач и продуктов на потоки, можно ли несколько процессов вести параллельно.
- Определяете, получится ли увеличить ресурс внутри компании или нужно привлекать специалистов со стороны.
- Находите наименее приоритетные результаты, исключаете или сокращаете их содержание.
- Выносите вопрос для решения, включив в него:
- важность исполнения срока вашей задачи (потери или выгоды исполнения в срок)
- предложение обновленного плана работ
- изменение стоимости, если это применимо
Увеличение команды имеет свои минусы. Это долгая процедура подбора персонала, что критично при коротких сроках. Новых сотрудников нужно обучить или переобучить. Большой командой сложнее управлять.
Второй способ ускорения проекта — метод быстрого прохода «Fast Tracking».
Если первый метод предполагает увеличение бюджета, то в этом усиливаются риски. Ведь суть быстрого перехода — параллельно вести те работы или фазы проекта, которые должны выполняться последовательно.
Поделюсь примером из своей практики. Наша команда вела большой проект, где для любых изменений нужно согласование 9 человек. За месяц до запуска я понимаю, что архитектурное решение неправильное и нужно все переделывать. Я собрала встречу из 9 человек и архитектора. Мы обсудили все детали и пришли к согласию. На другой день архитектор представил проект нового решения, ответственные поставили визы, мы уложились в сроки. Вместо стандартных 2 недель решение было принято за 2 дня.
Но обратная сторона этого метода — большое количество рисков, давление со стороны руководителя проекта на архитектора и ответственных лиц.
Быстрый проход применим в разных ситуациях: например, при создании продукта можно начать разработку до завершения проектирования, запустить тестирование до завершения аналитики или параллельно вести разработку и аналитику.
Как организовать «Fast Tracking»:
Важно, чтобы вы зафиксировали риски. Для глобальной перестройки проекта понадобится акт согласования с первым лицом. И еще: исполнители должны быть согласны с новым планом.
Другие возможности оптимизации расписания
Метод сжатия и «Fast Tracking» — это практики из международных стандартов. Они легальны, проверены и понятны. Но в России есть такие варианты, которые отличаются от международных:
- Пересмотреть риски
- Исключить результат с низким приоритетом. Кстати, резать содержание принято только в российской практике, в международной так не делают
- Отказаться от изменений
- Работать сверхурочно
- Привлечь консультантов для применения более эффективных технологий производства
- Убедить руководство, что ускориться нельзя. Для этого метода нужна диаграмма Ганта с оценками, со всеми согласованиями, чтобы обосновать, почему это нельзя сделать.
Как еще можно работать со сроками
Еще один шаг, чтобы успеть вовремя и не потерять на сроках — это приоритизация результатов с заказчиком в формате «светофора»: критично (красный), средне (желтый), не критично (зеленый).
Далее сформируйте и согласуйте перечень рисков. А потом еще раз на него посмотрите, можете ли так рискнуть. Затем определите MVP результатов и его характеристики.
Я воспринимаю MVP, как шанс успеть сделать проект вовремя. MVP — не что иное, как плановая поставка части функционала, который может быть использован. Можно запланировать несколько поставок до вывода готового продукта в промышленную эксплуатацию. Это позволит вам раньше передать заказчику результат и получить обратную связь, сократить срок начала использования, повысить окупаемость и снизить обеспокоенность заказчика о сроках.
Еще один пример из моей практики. В проекте длительностью в 5 лет, который я веду сейчас, технически сложно создать продукт, потому что в нем задействовано много серверов, систем, интеграций. Поэтому сначала мы решили вывести продукт только для определенных ситуаций. Для этого взяли довольно узкий сегмент — оборонно-промышленный комплекс. Максимально сократили набор функций, документов, проверок, сервисов и вывели в продакшн только такую версию. Нашли клиентов и построили концепцию на таком MVP. И вот недавно вышел последний релиз — спустя 15 месяцев от MVP до полного выполнения для всех сегментов.
Что можно сделать для MVP/определения этапов поставки
Лучше всего подойдет принцип Парето 80х20: «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата». Первая поставка может отражать только главные функции, которые заказчик будет опробовать, или вообще быть прототипом. Создайте карту приоритетов: определите, сложно это или просто для разработчика, а также желательно это или обязательно для пользователя. Самое легкое и желательное и войдет в первую поставку.
Важно понимать, что план проекта проекта и реальные сроки выполнения всегда будут отличаться. Только правильно оценивая и рассчитывая сроки, обсуждая план с исполнителями, можно значительно сократить расхождения в цифрах.