Книга: Проджект-менеджмент: Как быть профессионалом
Назад: Глава 3. Карьера: как заставить себя учиться?
Дальше: Глава 5. Содержание проекта. Требования и иерархическая структура работ проекта
Глава 4

Устав проекта

Устав проекта (Project charter) — это короткий документ, который «в крупную клетку» описывает детали проекта, формально авторизует его существование, закрепляет за ним руководителя, которому предоставляет полномочия использовать ресурсы компании для работы над проектом.

Устав проекта — это не единственное название документа. В разных компаниях его могут называть по-разному: «карточка проекта», «one-pager», «executive summary», «описание проекта» и т.д.

Начнем с начала. На каком этапе менеджер узнает о своем назначении на проект?

Этап идеи — это, как правило, этап внутренних проектов. Начальник вызывает менеджера и говорит: «Слушай! Есть идея!» У таких проектов обычно только один спонсор — непосредственный руководитель менеджера.

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

Этап победы в тендере — обычно выглядит так: к менеджеру подбегает радостный сотрудник отдела продаж и говорит: «Отличные новости! Мы тут продали одному клиенту такой огромный проект! В общем, нужно еще и CRM им сделать. Короче, на все у тебя две недели. Удачи!» В этом случае у менеджера еще остается возможность обсудить с заказчиком содержание работ, составить расписание и сверстать бюджет проекта.

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

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

Итак, что нужно в первую очередь сделать менеджеру на старте независимо от того, на каком этапе находится проект?

Конечно же, познакомиться с проектом и найти ответы на простые, но самые важные вопросы:

Чтобы помочь найти ответы на эти вопросы, существует классный инструмент — устав проекта.

Что должно быть в уставе

1. Бизнес-цель проекта. Как уже было сказано в начале книги, руководителю проекта очень важно знать, какую цель преследует бизнес своим проектом и какую проблему он хочет решить с его помощью. Иногда бывает сложно докопаться до сути сразу, и происходят примерно такие диалоги: «Вячеслав, зачем мы автоматизируем бухгалтерию?» — «Для того, чтобы автоматизировать…» — «Хорошо, а для чего мы ее автоматизируем? Что вы хотите получить в итоге от проекта? Какова цель бизнеса?»

Автоматизация как таковая никогда не является целью бизнеса. Автоматизирован процесс или нет — бизнесу все равно. До тех пор, пока всех все устраивает. Обычно при помощи автоматизации бизнес хочет улучшить управляемость, получить прозрачность, ускорить процессы, повысить уровень удобства для клиента или снизить расходы. Вернемся к примеру с банком. Для него бизнес-цель, прописанная в уставе, будет выглядеть следующим образом.

Бизнес-цель: увеличение базы клиентов банка на 1 млн человек за год.

2. Цель проекта. Описание того, каким образом будут достигнуты бизнес-цели проекта. Бизнес принимает решение о запуске конкретного проекта, проанализировав различные альтернативы и выбрав один вариант. В примере с банком таким решением может быть, например, приложение, помогающее выдавать мини-кредиты. Оно служит единственной бизнес-цели — увеличить базу клиентов банка. Решение должно быть задокументировано кратко и на высоком уровне. Это своеобразная карта, по которой нужно двигаться, чтобы помочь бизнесу достичь цели. Как это прописать в уставе? Примерно так.

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

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

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

3. Требования / результаты поставки. Здесь нужно описать крупные результаты поставки проекта и основные требования к ним. В итоге должен получиться список дел, «to do» проекта. Если все пункты этого списка выполнены, проект успешно завершен.

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

Список результатов поставки для примера с банком:

Если мы выполним все эти задачи, проект будет успешно завершен.

4. Ограничения и допущения. Ограничения проекта — это перечисление факторов, которыми в проекте нас ограничивает заказчик. Есть решения, которые уже приняты, и мы их не можем менять. В нашем банковском примере есть всего одно ограничение.

Ограничения: решение должно работать на телефоне Lenovo P780 под управлением Android 5.1.

Допущения проекта — это факторы, которые для целей планирования считаются верными, реальными или определенными без предоставления доказательств или демонстрации (такое определение дает нам PMBOK). Если коротко, то это предположения, которые можно считать фактом на данном этапе работ. Без них мы не сможем продолжить планирование проекта.

В нашем примере это будет вопрос интернет-соединения: не везде стабильно работает 3G-связь, следовательно, из некоторых районов почти невозможно будет отправить в банк фотографию из паспорта, сделанную в хорошем качестве. Допущением же, необходимым для работы над проектом, будет тот факт, что во всех городах и деревнях стабильно работает как минимум 2G-связь.

5. Ключевые и контрольные события. В уставе проекта оговариваются ключевые и контрольные события — важные события в проекте — и то, когда они должны произойти.

Например, проект начинается 6 июля. Менеджер планирует, что backend-разработчики должны сделать серверную часть по проверке фотографий из паспортов к октябрю. Для этого нужно успеть за месяц согласовать контракты API между сервером и мобильным приложением. Если удастся, то только в этом случае можно будет закончить мобильное приложение к ноябрю.

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

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

Ключевые и контрольные события:

Обратите внимание, что ключевые события указываются в прошедшем времени, что дает менеджеру четкое понимание того, выполнены эти задачи или нет. Если писать в настоящем времени («Разработка мобильного приложения: 4 ноября»), не будет понятно, что имелось в виду: мы планировали начать разработку, вести разработку или закончить разработку к 4 ноября. Прошедшее время четко дает понять, что работа должна быть завершена к соответствующей дате.

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

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

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

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

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

Практические рекомендации по составлению устава проекта

По методологии устав проекта должен создавать заказчик. Но в нашей практике этим часто занимался руководитель проекта. Это короткий документ, который легко прочитает и спонсор со стороны заказчика, и начальство менеджера. Этим документом руководитель проекта как бы переспрашивает: «Все ли я понял верно?» Если вдруг на этапе подготовки устава что-то упущено или понято не так, то это может привести к большим изменениям в проекте и, соответственно, большим дополнительным затратам. Если же менеджер получил письменное подтверждение того, что все понято верно, то проект пойдет в нужном направлении.

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

Устав может корректироваться в ходе реализации проекта. Почему? Например, у бизнеса поменялись цели. Такое бывает: время не стоит на месте, рынок меняется. В управлении проектами нет документов, которые «ламинируются». Любые планы нужно будет обновлять согласно новым вводным. Обратите внимание, что такая же история происходит и со стартапами. Очень редко стартап становится успешен со своей оригинальной идеей. Обычно только в ходе работы становится понятно, что именно нужно рынку. И успеха добиваются те, кто способен быстро адаптировать свою идею под нужды рынка или, если потребуется, полностью изменить ее. Например, YouTube начинался как сайт знакомств, фишкой которого была возможность записать короткое видео о себе. А сейчас это крупнейший провайдер видеоконтента.

Устав проекта стоит пересмотреть и утвердить заново в том случае, когда вас как менеджера ставят управлять уже идущим проектом. Если у существующего проекта нет устава, начните с его создания.

Самая опасная ситуация для любого проекта — это смена спонсора. Если человек, придумавший проект, уходит, а ему на смену пришел кто-то другой, устав нужно пересматривать и утверждать с новым спонсором. Здесь важно понять: по-прежнему ли мы делаем то, что делали. Обычно смена спонсора ведет к пересмотру содержания проекта. Если вы не согласуете проект заново с новым спонсором, то будете продолжать работать по своему старому техзаданию, которое для нового спонсора может быть полной чушью. В таком случае неизбежны потери времени и денег.

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

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

Выводы

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

Назад: Глава 3. Карьера: как заставить себя учиться?
Дальше: Глава 5. Содержание проекта. Требования и иерархическая структура работ проекта