7 лайфхаков для подготовки и планирования проекта

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

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

Поехали!

1. Кому конкретно нужен твой проект?

У тебя очередной проект? Интересный? Масштабный? Захватывающий? Полезный? Не спеши радоваться.

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

После того, как ты нашел такого человека, сядь и обсуди с ним – чего он хочет? Что для него будет успешным результатом проекта? Если по итогам такого взаимодействия ты понял, что хочет заказчик, и понял, что он будет как минимум рад, когда получит результаты проекта, то все хорошо, такой проект может иметь будущее. По итогам встречи обязательно письменно зафиксируй «хотелки» заказчика и вышли их ему. Это будет ваша с ним отправная точка.

Что будет, если такого человека не удастся найти?

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

Внимание, опасность!

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

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

2. Суть проекта должна быть проста и понятна

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

  • цель проекта;
  • результаты проекта;
  • скоуп проекта;
  • архитектура проекта;
  • дорожная карта проекта и т. д.

Четкого «научного» перечня составляющих нет. Как и четкого определения термина «суть проекта». Все определяется конкретной ситуацией. Главное – это чтобы можно было быстро и понятно объяснить, о чем твой проект. И чем короче ты сможешь это сделать, тем лучше. Пик мастерства – если ты сможешь представить проект на одной странице в виде простой визуализации/рисунка.

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

Многие могут возразить: бывают настолько сложные проекты, что их просто невозможно описать простыми словами, да еще и кратко, ясно и понятно. Это не так. Сложные проекты, действительно, бывают. Но описать их простыми словами, кратко, ясно и понятно можно. Но сложно (т. к. проект сложный). Кто говорит, что это невозможно – тот просто ленится это сделать. Неким доказательством того, что это возможно, могут служить TED-выступления. Если вы почитаете о внутренней кухне TED, посмотрите несколько ярких выступлений и проанализируете их, то увидите, что все они, как правило, об очень сложных вещах. Несмотря на это в них все предельно ясно, даже если вы не в теме того, о чем говорит спикер. Это одна из изюминок TED – представить сложную тему максимально простым и понятным языком. И, наверное, вряд ли кто будет спорить, что у TED это не получается. Еще как получается.

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

3. Что важнее для заказчика и стейкхолдеров?

В любом проекте при его реализации что-то идет не так, как запланировано. Часто это приводит к дополнительным денежным тратам, или к сдвигу сроков, или к изменению содержания/объема работ, или к снижению качества (или ко всему вместе). Из-за того, что проект имеет ограничения, в таких случаях руководителю проекта приходится принимать решение, что важнее и чем можно пожертвовать:

  • Попросить побольше денег (или залезть в резерв), чтобы успеть завершить проект в срок и не уменьшать содержание/объем?
  • Сдвинуть сроки без изменения содержания/объема и увеличения бюджета?
  • Уменьшить содержание/объем (не делать некритичный функционал)?
  • Снизить качество результата (в разумных пределах)?

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

После этого принимать решение при возникновении отклонений будет просто. Если важнее сроки, то не надо экономить бюджет. Если бюджет ограничен, то думайте, как можно сократить содержание/объем без потери ключевых результатов проекта. Если супер-важно качество, то не жертвуйте им. Если критично реализовать все содержание/весь объем, то не надо их сокращать.

Но не забывайте при этом проактивно информировать заказчика и стейкхолдера об ожидаемых изменениях в проекте.

4. Цель, задачи, результаты, критерии успешности и КПЭ проекта

Во время описания проекта и формирования его устава возникает необходимость сформулировать основные составляющие любого проекта:

  • цель проекта;
  • задачи проекта;
  • результаты проекта;
  • критерии успешности проекта;
  • КПЭ проекта.

И вот тут часто начинается путаница. Ни у руководителя проекта, ни у его руководителя, ни у заказчика, и, иногда, даже у проектного офиса нет понимания, что есть что. Цель путается с задачами и результатами, критерии успешности с КПЭ и т. д.

Ниже приведена краткая и лаконичная подсказка для данных понятий на примере вымышленного мини-проекта «Соорудить забор»:

Понятие

Рекомендации по формулированию

Пример в мини-проекте «Соорудить забор»

Частые ошибки при формулировании

Цель проекта

Начинать с глагола в начальной форме и совершенном виде (что надо решить/обеспечить).

Указывать на решение какой проблемы или к достижению какого состояния какого-либо объекта направлен проект.

Цель должна находиться вне проекта (т. е. результат проекта не может быть целью).

Обеспечить защиту участка от проникновения злоумышленников.

В цели указывается перечень задач или результатов.

В цели указывается, что конкретно надо сделать, а не что обеспечить или решить.

Задачи проекта

По сути, это второй уровень WBS (work breakdown structure) проекта.

В принципе, задачи не обязательны для указания в уставе.

·  Создать дизайн-проект забора..

·  Закупить материалы для сооружения забора.

·  Возвести забор.

·  Покрасить отдельные элементы заборы.

·  Юридически зарегистрировать забор.

Указывается слишком детальный перечень задач.

Указываются работы разного уровня WBS.

Результаты проекта

Результаты проекта бывают качественные и количественные.

Качественные результаты лучше формулировать в виде объекта (физического или виртуального), который получится по итогам проекта, и его статуса (возведен, зарегистрирован, согласован и пр.).

Количественные результаты проекта – это количественные характеристики объекта, получаемого по итогам проекта.

Количественные результаты = КПЭ проекта.

Качественные результаты:

·  Возведенный и юридически зарегистрированный забор.

Количественные результаты:

·  Высота забора 2 м.

·  Толщина забора 0,5 м.

·  Ударопрочность забора 10 условных единиц.

Формулируются только количественные результаты проекта.

Не указывается статус качественного результата проекта.

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

Критерии успешности проекта

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

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

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

Дополнительные возможные критерии успешности: допустимый уровень качества результатов проекта.

Допустимый уровень удовлетворенности пользователей/ клиентов (NPS, CSI).

и т. д.

·  Достигнуты все результаты проекта.

·  Превышение бюджета от запланированного – не более 10%.

·  Превышение сроков от запланированных – не более 15%.

Забывается сформулировать критерии успешности проекта до начала проекта.

Критерии успешности ограничиваются только один критерием – достигнуты все результаты проекта.

Допустимые нормы превышения бюджета и/или срока отсутствуют (т. е. при малейшем превышении проект считается неуспешным).

КПЭ

КПЭ проекта = Количественные результаты.

См. пример количественных результатов проекта.

См. описание в разделе про результаты проекта.

5. Делай только реализуемые проекты

«Это ключевой, очень важный для компании проект. Ресурсы, конечно, сильно ограничены, но, думаю, за полгода, если всем поднапрячься, можно справиться. Наконец-то вам представляется реальный шанс проявить себя!».

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

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

Типовая ошибка неопытных молодых руководителей проектов!

А избежать этого можно достаточно просто, если придерживаться простых и очевидных правил на стадии инициации:

  • сокращать скоуп проекта;
  • максимально увеличивать объем выделяемых ресурсов;
  • максимально увеличивать срок проекта.

Естественно, делать это надо обосновано. А единственно возможное обоснование на стадии инициации – разбиение скоупа проекта на части и максимально объективная и корректная оценка. Уходить в детальное прописывание проекта сильно вглубь не стоит (слишком трудозатратно), важно описать проект «вширь» – не забыть все работы, все затраты, все требуемые ресурсы и т. д.

А дальше – вопрос переговоров с заказчиком. Хочешь результат через полгода – хорошо, смотри, согласно оценкам, получаем, что для этого нужен такой вот объем ресурсов. Нет такого объема? Хорошо, давай сократим скоуп – через полгода можно сделать такой вот MVP (minimum viable product), остальное можно сделать еще через полгода. И так далее. Имея на руках проработанный скоуп и оценку проекта, можно вести с заказчиком предметный и содержательный диалог. Не имея этого на руках, итог диалога будет один: заказчик всегда прав и ответить ему нечего.

Поэтому не ленись уделять проработке проекта на стадии инициации нужное для этого время. И не геройствуйте на стадии инициации. Лучше сделать это потом, на стадии исполнения.

6. Планируй, но с умом

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

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

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

  • Составляешь список ключевых вех до конца проекта и примерно прикидываешь их сроки, исходя из ограничений, требований заказчика, собственного понимания, верхнеуровневых оценок и т. д. Сроки вех ставим не «абы как», а реально их оценив и заложив риски.
  • Дальше детализируешь на 1-2 уровня план для первых нескольких вех (примерно на полгода-год вперед).
  • Потом детализируешь еще на 1-2 уровня ближайший квартал.
  • Затем еще на 1-2 уровня ближайший месяц.

В итоге у тебя получается предельно понятный и детальный план работ на месяц, чуть менее детальный план работ на следующие 2 месяца, еще чуть мене детальный план на следующие 3 месяца и просто ключевые вехи и их сроки па период после полугода от текущего момента и до конца проекта.

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

  • В начале каждой недели, кроме планирования недели, детализируешь план на 4-ую неделю.
  • В начале каждого месяца детализируешь план на 3-ий месяц.
  • В начале каждого квартала детализируешь план на квартал, следующий за текущим.

Дополнительные важные моменты:

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

7. Идеально, когда РП для выполнения проекта «не нужен»

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

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

Конечно, если случится форс-мажор, то, возможно, потребуется более активное участие руководителя проекта.

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

Расскажите коллегам:
Комментарии
Генеральный директор, Ульяновск

Полезные лайфхаки. Лаконично и по существу. Спасибо.

HR-директор, Москва

Я бы еще добавила про необходимость мониторить промежуточные результаты и сверяться с ожиданиями заказчиков: если у них вдруг что-то поменяется в видении результатов проекта, то об этом нужно как можно раньше узнать, иначе придем к проблеме пункта 1: проект никому не нужен. 

 

Инженер, Екатеринбург

Денис, мне кажется, что с целью проекты Вы лукавите. Цель проекта (проект всегда конечен по времени) - соорудить забор. А "Обеспечить защиту участка от проникновения злоумышленников" - это запудривание мозгов заказчика. Если не так, то и назовите проект согласно данной цели. Но за такой проект РП , скорей всего, не возьмется, т.к. забором дело не ограничится и отвечать пожизненно за непроникновение желания нет.

Директор по развитию, Москва

Отличная статья!! Взаимодействие с заинтересованными сторонами и  управление их ожиданиями (выявление и точная формулировка) - это то, на чем сыплются большинство проектов больших и маленьких!!!  По моему опыту, вся остальная грядка технических, кадровых и ресурсных проблем проекта, дает  по Паретто не более 20% косяков, а 80% - это то, о чем говориться в данной статье. Коснулся автор и  "избыточных запасов планирования", когда все нормальные люди понимают, что расписанный по часам годовой проект - это трэш, но руководство уверено, что именно это и гарантирует успех. 

Сохраняю статью себе в базу знаний, надеюсь автор не против.  

Руководитель, Москва
Олег Кузнецов пишет:

Денис, мне кажется, что с целью проекты Вы лукавите. Цель проекта (проект всегда конечен по времени) - соорудить забор. А "Обеспечить защиту участка от проникновения злоумышленников" - это запудривание мозгов заказчика. Если не так, то и назовите проект согласно данной цели. Но за такой проект РП , скорей всего, не возьмется, т.к. забором дело не ограничится и отвечать пожизненно за непроникновение желания нет.

Олег, но ведь забор сам по себе ради забора не нужен. Он нужен для чего-то другого. И именно с этой "какой-то другой" целью и открывается проект. И в зависимости от цели требования к проекту и результат проекта будут разные.

Варианты цели проекта по строительству забора (к формулировкам целей и описанию требований не придирайтесь, указал их просто для демонстрации своего подхода):

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

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

- Защитить участок от ветра (нужен очень прочный и очень высокий забор и т.д.)

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

- И так далее

Руководитель, Москва
Александр Груздев пишет:

Полезные лайфхаки. Лаконично и по существу. Спасибо.

Александр, спасибо!

Руководитель, Москва
Владимир Скитяев пишет:

Отличная статья!! Взаимодействие с заинтересованными сторонами и  управление их ожиданиями (выявление и точная формулировка) - это то, на чем сыплются большинство проектов больших и маленьких!!!  По моему опыту, вся остальная грядка технических, кадровых и ресурсных проблем проекта, дает  по Паретто не более 20% косяков, а 80% - это то, о чем говориться в данной статье. Коснулся автор и  "избыточных запасов планирования", когда все нормальные люди понимают, что расписанный по часам годовой проект - это трэш, но руководство уверено, что именно это и гарантирует успех. 

Сохраняю статью себе в базу знаний, надеюсь автор не против.  

Владимир, спасибо! Конечно, не против.

Консультант, Ростов-на-Дону

Спасибо автору, весьма полезно. 

Вопрос. Денис, скажите, пожалуйста, где Вы видите место Scrum и agile в проектной деятельности?  

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

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

За статью спасибо, хорошо, по делу написано!

Генеральный директор, Санкт-Петербург

Статья интересная. Не хватило про гибкие методологии. Не согласен с описанием цели проекта - в цели всегда должна стоять финансовая выгода. Мало про мониторинг и контроль проекта (важная фаза). Про закрытие проекта тоже не увидел. Интересен реестр извлеченных уроков - как ведется, где складируется. Подбор ресурсов наверное тоже стоило указать. Показалось, что отношение к срокам слегка легкомысленное, хотя после начала проекта можно поменять расписание, ресурсы, масштаб проекта но сроки лучше не трогать. Риск менеджмент отсутствует как методология, системно реализованная в проекте, по крайней мере не упомянут. Ну а в общем статья полезная. Хотя конечно в очередной раз убедился - Rita рулит.    

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
3
Павел Вайнштейн
Раз я в очередной раз сюда заглянул, отвечу на Ваш запрос.Алкоголь - это конечно не моя тема, но ...
Все дискуссии
HR-новости
Треть сотрудников российских компаний хотят этой осенью поменять работу

64% сотрудников положительно оценивают шансы устроиться на новую работу осенью, потому что это наилучшее время для поиска.

Две трети работодателей не ждут от соискателей сопроводительные письма

Сложная ситуация на рынке труда трансформирует практику сопроводительных писем.

В Японии трудоустроили кошек, чтобы спасти сотрудников от выгорания

Большинство усатых работают по графику 24/7, а остальных отпускают домой вместе с их хозяевами.

Названы сферы с самым высоким уровнем конкуренции

Для того, чтобы оставаться конкурентоспособными на рынке труда, треть респондентов получают дополнительные непрофессиональные навыки.