Проектный менеджмент 📈 (управление проектами) — как реализовать проект

Управление проектами (или проектный менеджмент, project management)— это методология планирования, организации и реализации проектной деятельности. Проектный менеджмент это в первую очередь практический инструмент, который позволяет эффективно реализовывать проекты.

В настоящее время принято выделять два подхода к проектному менеджменту: * Классический проектный менеджмент (каскадная модель менеджмента, или «водопадная», «Waterfall») * Гибкий (Agile) проектный менеджмент

В первую очередь нужно определить цель. Далее необходимо определиться с составом команды и сформировать ее. Далее вам нужно разработать календарный план и стоимость реализации проекта вместе с участниками.

Проектным менеджментом обычно занимается специальный эксперт — менеджер проекта (project manager).

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

Проектный менеджмент это в первую очередь практический инструмент, который позволяет эффективно реализовывать проекты.

Принципы и практики проектного менеджмента сформировались на основе конкретного практического опыта и были обобщены. Сегодня эта область достаточно подробна разработана — мы имеем множество книг по проектному менеджменту. В то же время эта область продолжает развиваться и меняться в связи с изменением ситуации в мире и на рынке.

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

Таким образом, формирование проектного менеджмента и его реализация всегда имеют непрерывный цикл, включающий в себя три элемента: опыт; обобщение; адаптация.

Что касается самой проектной деятельности, то она обладает несколькими характеристиками, которые нужно учитывать:

• Проектная работа ограничена во времени — она имеет конкретные начало и конец;

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

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

В настоящее время принято выделять два подхода к проектному менеджменту:

• Классический проектный менеджмент (каскадная модель менеджмента, или «водопадная», «Waterfall»)

• Гибкий (Agile) проектный менеджмент

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

Давайте разберем два подхода к проектному менеджменту более подробно.

Классический проектный менеджмент — Waterfall

Waterfall — каскадную или водопадную модель — принято считать классической, потому что это тот вариант менеджмента, который появился первым. «Каскадность» заключается в том, что здесь работа идет по изначально сформулированному плану.

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

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

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

Вы можете просто запланировать то, что нужно, в определенной последовательности и с предсказуемым результатом — и сделать это.

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

Проектный менеджмент Agile — гибкий подход

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

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

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

Наиболее распространенной сегодня является работа по фреймворку Scrum, которая подразумевает работу итерациями («спринтами»), с постоянным мониторингом текущего состояния проекта и подстройкой под новые условия (инспекция и адаптация).

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

Больше по этой теме рекомендуем читать в разделах Scrum и Agile.

У этих двух подходов к проектному менеджменту есть и общие элементы, которые должны быть в любом проекте.

Вот, как начинается проектная работа.

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

Далее необходимо определиться с составом команды и сформировать ее. Для сложных проектом это особенно важно. Кто именно войдет в команду — довольно нетривиальный вопрос.

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

Проектный менеджмент в отличие от продуктового менеджмента всегда ограничен во времени — поэтому вам нужно ясное понимание того, как быстро вы сможете реализовать проект. Эти временные рамки никогда не будут точными на 100%, но примерный «разброс» необходимо обозначить как ориентир, если вы хотите придерживаться плана.

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

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

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

Это может показаться сомнительным, однако у такого подхода есть серьезные преимущества.

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

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

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

«Треугольник ограничений проекта» — это визуально отображенные три ключевых ограничения проекта, которые существуют всегда:

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

• Время — как быстро это должно быть готово. Для некоторых инновационных проектов это крайне важно, так как если вы не первые в нише, то ценность результата может быть менее значимой, а то и вообще нулевой.

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

Эти три ограничения всегда взаимосвязаны между собой.

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

Жизненный цикл проекта — это важное понятие проектного менеджмента, в котором заключается суть того, как проект начинает жить, развивается, завершается и умирает.

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

Давайте начнем с того, каким бывает жизненный цикл проекта, если у вас вообще нет менеджера проекта, или что–то в реализации процесса идет не так:

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

А вот так выглядит простейший жизненный цикл проекта в хорошей реализации:

Конечно, конкретная реализация этого жизненного цикла будет отличаться в зависимости от подхода к проектному менеджменту.

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