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

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

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

Поехали!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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