Как сделать долгосрочный проект управляемым?

Когда проект короткий – все в нем собраны и идут к общей цели, и управлять таким проектом относительно просто. А вот при длительности в год и больше удержать фокус команды и стейкхолдеров и сохранить управляемость гораздо сложнее. Цифры приведены для ИТ и, понятное дело, условные, для разных областей они будут разными. Как же сделать так, чтоб и через год и через два проект по-прежнему был интересен команде и стейкхолдерам, нес разумное, доброе и светлое, и не требовал безумных усилий для управления им?

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

Кстати, умение сделать проект коротким – это отдельный навык, который стоит развивать, потому что управляемость таких проектов в разы выше. Но об этом как-нибудь в другой раз.

Итак, что нужно для того, чтобы сделать долгосрочный проект управляемым?

1. Четкие процессы и непримиримость к их несоблюдению

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

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

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

То же самое и с планированием отпусков – как только вы пропустите 1-2 встречи – народ начнет ходить как удобно ему, а вы потом в самый критический момент обнаружите, что ключевые сотрудники в отпуске именно в то время, на которое вы запланировали на них важные активности.

2. Разбиение проекта на стадии и отмечание завершения этих стадий

Если долгосрочный проект по каким-то причинам (часто финансовым или политическим, кстати) невозможно разбить на несколько, нужно, по крайней мере, четко обозначить его стадии и критерии их завершения. После того, как стадия завершена, необходимо ее официально закрыть – провести презентацию для управляющего комитета, наградить отличившихся, устроить какое-то тимбилдинговое мероприятие и отметить это дело. Это даст людям понимание того, что проект движется, а не стоит на месте, позволит поставить ментальную “галочку””я сделал” и продолжать бежать.

Отличный пример – “Красочный забег” в Москве, на котором каждый километр трассы был отмечен новым цветом, чтобы люди понимали, что они пробежали еще один кусок и могли получить “подзарядку”.

8

3. Извлеченные уроки по каждому этапу

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

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

4. Поэтапный ввод результатов в работу

Скорее всего, это не ваш случай (тогда вы с самого начала делали бы проект по гибкой методологии), но иногда можно как-то это исправить уже в ходе самого проекта. Если non-Agile – это политическое решение, то промежуточную версию всегда можно назвать тестовой или “для получения обратной связи” и делать себе спокойно проект так, как удобно и эффективно.

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

5. Регулярная переоценка необходимости проекта, требований, стейкхолдеров, рисков

Это печальный факт, но большинство результатов долгосрочных проектов устаревают еще до того, как попасть к конечным пользователям. А иногда и вообще выясняется, что они больше не нужны, стратегия компании поменялась, ключевые заинтересованные лица уехали работать в Лондон и еще сотни причин, почему ваша работа оказалась никому не нужной. Если по каким-то причинам Agile не для вас и сдавать проект по кускам никак нельзя – то нужно с определенной регулярностью возвращаться к целям проектам, убеждаться, что они для компании еще актуальны и утверждать их у новых должностных лиц. То же самое актуально для требований.

И, конечно, если в компании меняется топ-менеджер, имеющий непосредственное отношение к вашему проекту – необходимо убедиться, что он про проект знает и что с тем, что он принесет указанные выгоды и на него будут потрачены указанные деньги и ресурсы, согласен (как максимум – заручиться поддержкой, как минимум – подстраховаться, чтобы потом не оказалось, что он ни при чем, деньги потрачены, а вы крайний).

6. Бриф проекта

Бриф – хорошая штука, позволяющая в растянутом по времени проекте не забыть, а зачем, собственно, это все, и особенно о том, что разумное, доброе и светлое несет проект и для кого он делается. Подробно я писала о брифе тут.

Вот и все, правила простые, но их соблюдение поможет удержать проект на коротком поводке и не дать людям потерять фокус на нем. Иногда, выполняя какие-то из указанных выше пунктов (особенно п.5), можно понять, что проект уже нерелевантен и компании не нужен. Этот тот самый случай, когда несмотря на уже потраченные деньги, лучше поднять вопрос о его закрытии. Упорно догрызть кактус и сделать то, что не нужно никому – это не тот опыт, который вам нужен как руководителю проекта. А умение вовремя понять и признать правду и особенно сказать менеджменту “все, деньги выброшены на ветер, предлагаю дальше их не выбрасывать и проект закрыть и начать новый” – бесценно, и является одним из доказательств вашего профессионализма.

Всем коротких проектов и быстрых побед!

Давайте не теряться - подпишитесь прямо сейчас!

Чтобы получать новые практические материалы раз в неделю на вашу почту. Без спама и рекламы, только опыт и мысли практикующего специалиста по управлению проектами

А также
И не забудьте оставить комментарий :) мне важно ваше мнение!
Комментарии (2)
  1. Аноним

    Закрываю сейчас проект длившийся с 2011 года, я 6й ПМ в нем. Основной вывод такой, таких проектов лучше не делать, что делать с продуктом теперь не ясно…он мягко скажем не актуален.

    1. Yulia Bazhanova

      Зато есть повод гордиться, что из 6 человек вы единственный, кто смог его наконец закрыть и перестать впустую тратить деньги компании=)) А за актуальность продукта надо все-таки с Заказчика спрашивать.

Оставьте комментарий