Жизненный цикл проекта: стадии и что делать на каждой

Типичная картина: решили внедрить CRM, назначили ответственного, провели пару встреч. Через три месяца настроено наполовину, менеджеры работают по-старому, а на вопрос «когда закончим» никто не отвечает. Формально проект идёт. Фактически непонятно, на какой он стадии и что должно случиться, чтобы он закончился.

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

Дальше разберём, из чего цикл состоит, чем стадии отличаются от процессов управления (это разные вещи, и в рунете их путают почти повсеместно), что говорит российский стандарт и где проекты ломаются на самом деле.

Что такое жизненный цикл проекта простыми словами

Жизненный цикл проекта — последовательность стадий, которые проект проходит от появления идеи до передачи результата и закрытия.

Смысл деления практический. Пока проект — одно большое «делаем», управлять им нельзя: непонятно, чего ждать на этой неделе, что считать промежуточным результатом и когда останавливаться. Разделив путь на стадии с понятными выходами, вы получаете контрольные точки, в которых можно спросить и получить внятный ответ.

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

Фазы жизненного цикла проекта и процессы: почему это не одно и то же

Здесь самая частая путаница, и её стоит разобрать до всего остального.

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

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

	Фазы жизненного цикла	Процессы управления
Что описывают	как проект развивается во времени	что делает управляющий проектом
Зависят от	типа проекта: стройка, внедрение, разработка	не зависят от типа
Идут ли последовательно	да, одна после другой	нет, накладываются и повторяются
Пример	предпроект → пилот → тираж → сдача	планирование идёт и на пилоте, и на тираже

Важно: практический вывод не академический. Если считать контроль отдельной фазой, в проекте появляется дыра: пока идёт «фаза исполнения», никто не смотрит на отклонения, а к «фазе контроля» исправлять уже поздно.

Что говорит российский стандарт

Полезно знать, на что можно опереться, если в компании начинается спор о терминах.

ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом» введён в действие с 1 сентября 2012 года. Он структурирует управление проектом по пяти процессам, и порядок в нём такой:

1. инициация проекта;
2. планирование проекта;
3. организация исполнения проекта;
4. контроль исполнения проекта;
5. завершение проекта.

Обратите внимание на два момента. Первый: стандарт называет это именно процессами, а не фазами. Второй, и он важнее: терминов «жизненный цикл проекта», «фаза проекта» и «этап проекта» в стандарте нет вовсе. Поэтому фразы вида «по ГОСТу жизненный цикл состоит из пяти фаз», которые встречаются в интернете, некорректны — стандарт этого не утверждает.

Ещё одна вещь, которую стандарт даёт даром: роли. Заказчик проекта, руководитель проекта, куратор проекта и команда проекта. В небольших компаниях эти роли обычно схлопываются в одного человека, и именно отсюда растёт половина проблем — но об этом ниже.

Стадия 1. Инициация: проект появляется

Самая недооценённая стадия. Её обычно проскакивают за один разговор, а потом весь проект расплачивается.

Что должно появиться на выходе:

• Цель проекта — что изменится в компании, когда он закончится, в проверяемом виде.
• Границы — что входит в проект и, отдельным списком, что не входит. Второй список важнее первого.
• Заказчик — тот, кому нужен результат и кто будет его принимать.
• Руководитель проекта — тот, кто отвечает за ход и имеет полномочия.
• Грубая оценка сроков и ресурсов, чтобы понимать порядок величин.

Оформляется это одностраничным документом — уставом проекта или просто письмом, зафиксировавшим договорённости. Формат не принципиален, наличие — принципиально.

Стоит потратить время именно на формулировку цели. «Внедрить CRM» целью не является: это название работы, а не результата. Цель звучит иначе — «все сделки ведутся в системе, руководитель видит воронку без запроса к менеджерам, ни одна заявка не теряется». Разница в том, что по второй формулировке понятно, когда останавливаться, а по первой — нет, и проект будет тянуться, пока не надоест.

Хорошая проверка на этой стадии — спросить заказчика, что он будет делать по-другому, когда проект закончится. Если внятного ответа нет, проект пока не нужен: результат никуда не встроен, и его получение ничего не изменит.

Частая ошибка: пропустить фиксацию границ. Проект «внедрить CRM» без списка того, что в него не входит, к третьему месяцу обрастает интеграцией с бухгалтерией, телефонией и переносом архива за пять лет — и не заканчивается никогда.

Стадия 2. Планирование: появляется маршрут

На этой стадии из цели вырастает план: что нужно сделать, в каком порядке, кто делает и к какому сроку.

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

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

Признак, что планирование закончено: любой участник может ответить, что он делает на этой неделе и от кого зависит.

Отдельно про глубину плана. Расписывать весь проект до задач на полгода вперёд — потерянное время: к третьему месяцу половина деталей изменится. Рабочий подход — подробно планировать ближайший месяц и держать крупными блоками всё, что дальше. Детализация следующего блока делается в конце текущего, когда уже понятно, с чем имеем дело.

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

Стадия 3. Исполнение: работа идёт

Самая длинная стадия и самая простая по описанию: команда делает то, что запланировано, руководитель проекта убирает препятствия.

Три вещи, которые определяют, будет ли она управляемой.

Ритм. Регулярная встреча по проекту с фиксацией решений — это то, что превращает список задач в движение. Как устроена такая фиксация, разобрано в статье про протокол совещания.

Видимый статус. У каждого участника должно быть понятно, что сделано, что в работе, что застряло. Если статус существует только в голове руководителя проекта, проект останавливается ровно в момент его отпуска.

Управление изменениями. Изменения в проекте неизбежны, вопрос в том, проходят ли они через решение. Незаметно принятое изменение — главный источник срыва сроков: объём вырос, а дата осталась прежней.

Где проекты ломаются на самом деле

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

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

Переход от планирования к исполнению. План есть, но люди не выделены: у всех остаётся основная работа, а проект идёт «по остаточному принципу». Формально стартовали, фактически нет.

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

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

Стадия 4. Контроль: не отдельная стадия, а сквозная работа

Мы уже говорили, что контроль неправильно считать отрезком времени. Но работа, которую он обозначает, реальна, и делать её нужно с первого дня.

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

Практический минимум:

• Точки контроля привязаны к результатам, а не к календарю. Не «статус каждую пятницу», а «к 15-му числу должен быть настроен и проверен блок продаж».
• Отклонение фиксируется, когда оно появилось, а не когда стало срывом. Неделя задержки, о которой сказали сразу, стоит недели. Та же неделя, о которой узнали в конце, стоит месяца.
• Изменение объёма проходит через заказчика. Любое «давайте ещё вот это добавим» — это решение о сроке и бюджете, а не мелкая просьба.

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

Риски: единственный процесс, который окупается заранее

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

Разбор занимает полчаса и состоит из трёх вопросов по каждому пункту плана: что может пойти не так, насколько это вероятно и что мы сделаем, если случится. Не «как избежать» — многое неизбежно, — а именно что будем делать.

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

Частая ошибка: заводить реестр рисков ради документа. Список из тридцати формальных строк никто не откроет. Пять реальных рисков с ответом «что делаем, если» — рабочий инструмент, который спасает сроки.

Бюджет проекта: что в нём забывают

Даже во внутренних проектах, где «денег не тратим», бюджет существует — просто он выражен во времени людей. И именно эта часть обычно не считается.

Что стоит заложить кроме прямых затрат:

• Время сотрудников, которых отвлекают. Внедрение учётной системы съедает десятки часов бухгалтерии и продаж, и эти часы уходят из основной работы.
• Обучение и период просадки. После запуска новой системы люди какое-то время работают медленнее, чем раньше. Это нормальная часть проекта, но её надо ожидать.
• Доработки после приёмки. Первый месяц эксплуатации всегда вскрывает мелочи. Если ресурс на них не заложен, они висят месяцами.
• Работа руководителя проекта. Это тоже время, и обычно немалое.

В Business Commandos при постановке управления проектами именно на этом месте чаще всего меняется картина: собственник видит не «внедрение стоит столько-то», а полную цену вместе с отвлечением команды — и часть проектов после такого расчёта разумно откладывается.

Как проекты живут рядом с текущей работой

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

Что с этим делают компании, у которых проекты доходят до конца.

Выделяют время явно. Не «занимайтесь проектом по возможности», а конкретные часы в календаре: вторник с 10 до 13 — работа по проекту. Всё, что не защищено в календаре, съедается текучкой.

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

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

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

Стадия 5. Завершение: чем проект заканчивается

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

Что должно произойти, чтобы проект действительно закончился.

Приёмка результата заказчиком. Не «вроде работает», а явное подтверждение: результат соответствует тому, что договаривались получить на инициации. Именно здесь окупается время, потраченное на формулировку цели в начале.

Передача в постоянную работу. У любого проектного результата есть владелец после проекта: кто отвечает за CRM, когда внедрение закончилось; кто ведёт регламент, когда он написан. Без этого шага результат деградирует за пару месяцев.

Разбор итогов. Двадцать минут на вопросы: что сработало, что нет, что сделаем иначе в следующий раз. Компании, которые ведут проекты годами и каждый раз наступают на те же грабли, обычно просто не делают этого шага.

Формальное закрытие. Объявленное всем участникам: проект завершён. Это звучит формальностью, но без этого люди продолжают числить проект в своей загрузке.

Отдельно стоит сказать про проекты, которые закрываются не результатом, а решением остановиться. Такое бывает: обстоятельства изменились, экономика не сошлась, нашлось решение проще. Останавливать проект — нормально, но останавливать его нужно так же явно, как завершать: объявить решение, назвать причину, зафиксировать, что из наработанного сохраняем и куда кладём. Проекты, которые не закрыли и не остановили, а просто перестали делать, — худший вариант: они не дают результата, но продолжают висеть в головах и в отчётах, и каждый раз при разговоре о планах кто-нибудь спрашивает, что там с ними.

Признак здоровой работы с проектами — не отсутствие остановленных, а отсутствие подвешенных. В компании, где за год два проекта закрыты результатом и один остановлен решением, порядок есть. Там, где пять проектов «в работе» второй год, порядка нет, сколько бы графиков ни было нарисовано.

Документы проекта: минимальный комплект

Проектная документация в среднем бизнесе вызывает отторжение, и справедливо: толстые регламенты никто не читает. Но минимальный комплект нужен, и он умещается в четыре документа.

Устав проекта — одна страница. Цель, границы, заказчик, руководитель, грубые сроки и бюджет. Пишется на инициации и дальше почти не меняется. Нужен для одного: чтобы через три месяца можно было свериться, тем ли занимаемся.

План — одна-две страницы или график. Что делаем, в каком порядке, кто отвечает, к каким датам. Живёт и обновляется всю дорогу.

Журнал решений и изменений. Самый недооценённый документ. Каждое изменение объёма или срока — строка: что решили, когда, почему, как это повлияло на дату. Через два месяца именно он отвечает на вопрос «почему мы отстаём», без взаимных обвинений.

Акт приёмки или письмо о завершении. Фиксирует, что результат передан и принят. Даже во внутреннем проекте это письмо на пять строк, которое ставит точку.

Всё остальное — протоколы встреч, переписка, технические документы — накапливается по ходу и хранится вместе, но отдельного производства не требует.

Совет: заведите один каталог на проект и держите там всё. Проект, документы которого размазаны по личным папкам и переписке, невозможно передать другому человеку — а передавать придётся, как только руководитель проекта уйдёт в отпуск или уволится.

Модели жизненного цикла проекта: водопад и итерации

Разбивка на стадии — не единственный способ организовать проект, и выбор модели зависит от того, насколько заранее понятен результат.

Последовательная модель (водопад). Стадии идут строго друг за другом, следующая начинается после закрытия предыдущей. Работает там, где результат известен заранее и стоимость изменения велика: стройка, монтаж оборудования, внедрение по типовой методике.

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

Смешанный вариант — то, что чаще всего встречается в среднем бизнесе. Каркас проекта последовательный, внутри стадии исполнения работа идёт итерациями. Скажем, во внедрении учётной системы контур определяется заранее, а настройка идёт блоками с проверкой на каждом.

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

Как выглядит цикл на живом примере

Абстракция становится понятнее на конкретике. Возьмём типовой для среднего бизнеса проект — наведение порядка на складе с запуском учёта остатков.

Инициация. Цель: остатки в системе сходятся с фактом с расхождением не больше процента, инвентаризация занимает день вместо недели. Границы: склад готовой продукции, без сырья и без изменения логистики доставки. Заказчик — собственник, руководитель проекта — начальник склада. Ориентир: три месяца.

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

Исполнение. Еженедельная встреча по проекту, статус в общем документе, изменения объёма — через заказчика. На третьей неделе выясняется, что часть номенклатуры заведена дублями — это становится отдельной работой, срок сдвигается на две недели по решению, а не молча.

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

Завершение. Собственник проверяет: расхождение по контрольной выборке — 0,7%, инвентаризация заняла день. Результат принят. Владелец после проекта — начальник склада, процессы закреплены документом. Разбор итогов: недооценили чистку справочника, в следующий раз закладываем её отдельным блоком. Проект объявлен закрытым.

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

Как понять, на какой стадии ваш проект

Диагностика на три вопроса, без методологии.

1. Есть ли согласованная цель и границы? Нет — вы на инициации, независимо от того, сколько работы уже сделано.
2. Знает ли каждый участник, что он делает на этой неделе? Нет — планирование не закончено, даже если график нарисован.
3. Назван ли тот, кто примет результат, и известно ли, по каким признакам? Нет — проект не сможет завершиться, и это выяснится в самом конце.

Самая частая находка при такой проверке: проект, который считался идущим полгода, на самом деле не выходил из инициации, потому что цель так и не была согласована между заказчиком и исполнителями. Открытие неприятное, зато оно объясняет всё остальное — и лечится одним разговором на час, а не новым графиком работ.

Кто управляет проектом в небольшой компании

Отдельная сложность среднего бизнеса: стандартные роли есть, а людей на них нет.

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

Минимальное разделение, которое реально работает: собственник остаётся заказчиком — формулирует, что нужно, и принимает результат. Руководителем проекта назначается другой человек — тот, кто ведёт ход работ и отвечает за сроки. Даже такое разделение на двоих резко меняет управляемость: появляется тот, кто обязан прийти и сказать, что проект отстаёт.

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

Что делать, если проект уже буксует

Отдельный сценарий: статья читается не до старта, а посреди проекта, который встал. Порядок разбора тут другой — не «начать правильно», а «понять, где обрыв».

Шаг 1. Вернитесь к цели. Спросите заказчика и исполнителей отдельно, каким должен быть результат. Если ответы различаются — это и есть причина, и никакие графики её не лечат. Сначала согласовать, потом всё остальное.

Шаг 2. Проверьте, кто владелец. Если на вопрос «кто отвечает за проект» звучит несколько фамилий или должность вместо имени, проект не управляется. Назначьте одного и дайте ему право принимать решения в рамках согласованных границ.

Шаг 3. Пересоберите план от текущей точки. Не пытайтесь догнать исходные сроки — это почти всегда самообман. Честнее зафиксировать новую дату с учётом того, что уже сделано, чем третий месяц двигать старую.

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

Внимание: самое вредное, что можно сделать с буксующим проектом, — добавить в него людей. Новые участники требуют погружения, а времени на это у тех, кто уже в проекте, нет. Обычно помогает не расширение команды, а сокращение объёма.

Частые ошибки

• Начинать с инструмента. Куплена система управления проектами, а цель проекта не сформулирована. Инструмент делает видимой неразбериху, но не устраняет её.
• Не фиксировать границы. Проект без списка «что не входит» растёт, пока не потеряет смысл.
• Считать контроль отдельной стадией. Отклонения обнаруживаются, когда исправлять поздно.
• Планировать только сроки. Ни бюджета, ни ответственных, ни порядка изменений — такой план разваливается на первой неожиданности.
• Не закрывать проект явно. Результат не передан, разбора не было, участники до сих пор числят проект в своей загрузке.
• Назначать руководителя проекта без полномочий. Человек отвечает за срок, но не может ни попросить ресурс, ни изменить порядок работ — проект стоит на согласованиях.

С чего начать

Если проектов несколько и все буксуют, разбирать стоит не все сразу.

1. Возьмите один проект, самый важный, и проверьте его тремя вопросами из диагностики.
2. Закройте то, чего не хватает, начиная с начала: сначала цель и границы, потом ответственный, потом план.
3. Назначьте одну регулярную встречу по этому проекту и фиксируйте на ней решения — этого достаточно, чтобы движение стало видимым.

Через месяц станет понятно, дело было в организации проекта или в том, что он вообще не нужен компании. Второй ответ тоже полезен: закрытый ненужный проект освобождает людей для нужного.

Выводы

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

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

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