Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
26 октября 2016 Из жизни РМа
500 2

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

Юлия Бажанова
Редактор проекта, РМР, РМЕ, PRIME

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

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

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

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

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

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

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

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

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

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

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

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

8

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

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

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

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

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

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

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

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

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

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

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

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

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

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

2комментария

сначала новые
по рейтингу сначала новые по хронологии
1

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

Автор2
Юлия Бажанова

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

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: