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. Идеально, когда РП для выполнения проекта «не нужен»

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

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

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

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

Комментарии
Генеральный директор, Краснодар

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

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

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

 

Knowledge manager, Екатеринбург

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

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

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

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

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

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

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

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

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

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

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

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

- И так далее

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Эксперты: 4-дневная рабочая неделя приведет к снижению зарплат

Закон не препятствует пропорциональному снижению ФОТ при переходе на четырехдневную рабочую неделю.

75% россиян не верят в пенсии

Три четверти россиян не верят в пенсии, показал опрос Райффайзенбанка. А те кто верят, полагают, что она составит всего 10-20 тыс. руб.

Японцы доказали, что при четырехдневной рабочей неделе производительность растет. В Microsoft сообщили о росте на 40%

Японское подразделение Microsoft подвело положительные итоги месячного эксперимента по переходу на четырехдневную рабочую неделю.

 
Кто счастлив в России?

Самыми счастливыми оказались - медики, госслужащие и HR-ы. Об этом сообщается в исследовании Headhunter.