PMO Consulting

Цели проекта. Почему важно понимать и какие цели бывают

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

Почему же важно понимать реальные цели проекта?
Предположим, руководителя проекта подключили к проекту уже после планирования проекта, дали документы с требованиями, оценки и посчитанные сроки, команду и попросили выполнить проект в соответствии с договоренностями с клиентом. К чему это приведет, если PM просто возьмет под козырек и пойдет выполнять проект? Будет формальное выполнение проекта, попытки попасть в сроки, сделать всё и т. д. Возможно, по пути будут находиться какие-то "упрощения", возможно "незначительно" поедут сроки, возможно, UI/UX будет не настолько качественно реализован. И как-то проект сдадут. При этом велики шансы, что заказчик не получит желаемого результата, команду будут загонять не понимая зачем и куда идем - очень велики.
А что, если PM не возьмет под козырек и побежит работу работать, а на старте остановится и убедится, что он правильно понимает цели проекта? Возможно, узнает, что сроки критичны до дня, т. к. проект нужен к выставке клиенту, которая планируется за 2 года. Возможно, качество приоритет и лучше сделать меньше, но без огрехов, так как будет демо очень педантичной аудитории и т. д.
Разница в результатах и в том, как PM будет вести проект - очень большая.

Звучит как нужно организовать встречу с клиентом, познакомиться с ним, ещё раз проговорить цели, убедиться что мы их верно понимаем. Всё просто (хотя даже этого делают далеко не все и не всегда, т. к. "ну тут всё понятно"). Но обычно заказчики говорят о том, что важно всё (все фичи, чтобы было в срок, и высокого качества, и ещё с запасом по срокам). И вот тут начинается магия, как из заказчиков вытянуть реальные цели. Тут тоже можно не усложнять, как минимум просто уточнив у клиента "а почему это важно". Обычно несколько таких вопросов бывает достаточно, чтобы понять какие-то реальные ограничения проекта.

А давайте ещё усложним? Выше мы говорили о заказчике проекта. Но ведь не только заказчик заинтересованная сторона при запуске проекта? По классике, хорошо бы провести анализ целей каждой из стороны, вовлеченных в проект и/или зависящих от его результата и видеть всю картинку, чтобы принимать максимально эффективные решения. Для простоты предлагаю выделить 3 группы заинтересованных сторон.
1
Заказчик и его представители (сотрудники). Самая очевидная группа целей. Определяем, зачем мы делаем определенный набор фич, кто будет этим пользоваться, что там по бюджету, срокам и качеству. Но тут важно помнить, что, если мы работаем с крупным клиентом, там могут быть внутренние заинтересованные стороны, которые не очевидны, но по факту будут принимать решение об успехе проекта. При этом часто бывает, что представитель заказчика, с которым мы ведем переговоры, искажает (ненамеренно, но нам это мало помогает) цели, которые ставит перед проектом его руководство и руководители смежных подразделений. Тут важно иметь карту стейкхолдеров и стараться в идеале подключать на отчетные встречи по проекту реальных лиц принимающих решения со стороны клиента (или, как минимум, четко прописывать все риски и договоренности в отчетных документах, которые, возможно, идут куда-то дальше внутри организации заказчика).
2
Наша компания. Если мы говорим про заказную разработку, очевидно, наша компания должна делать успешных бизнес и берется за проект со своей вполне определенной целью. Это могут быть как конкретные показатели по маржинальности проекта, по получению позитивного отзыва от важного клиента, чтобы попасть в вендор-лист этого важного клиента, а, может, чтобы рассказать о том, что мы умеем другим и зайти на новую для компании технологическую или бизнесовую нишу. В зависимости от целей компании у руководителя проекта могут появиться дополнительные ограничения или, наоборот, ресурсы.
3
Команда. Проекты делают люди, и они также соглашаются работать на проекте, чтобы достигать своих вполне определенных целей. Кто-то хочет спокойно работать, чтобы его никто не трогал, кто-то хочет изучить новую технологию, или видит для себя возможность в развитии тим лидерских компетенций на этом проекте. Непонимание целей членов команды - прямой путь к демотивации команды и, как следствие, к неожиданным сюрпризам в ходе проекта (вынужденная замена человека, низкая продуктивность, конфликты внутри команды и т. д.).
В больших и сложных проектах могут добавляться подрядные организации и другие стейкхолдеры, которые (неожиданно) имеют свои цели, которые важно понимать PM. Поэтому никогда не ленитесь составить полную карту стейкхолдеров проекта и провести анализ целей каждого из них.