Руководство проектами устав

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

Устав проекта (Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика.

Процесс разработки Устава проекта относится к группе процессов Инициация и осуществляется в фазе (на этапе) проекта внедрения ИС, которая имеет свое специфическое название в каждой методологии внедрения ИС, например, «Предварительное определение проекта«, «Определение проекта» — методология внедрения продуктов Microsoft, «Концепция» — методология внедрения ASUP.

Исходными документами для разработки Устава проекта внедрения ИС являются контракт и результаты предпроектного обследования, определяющие содержание работ по проекту. Результаты предпроектного обследования оформляются в виде отчета, включая описание бизнес-процессов верхнего уровня.

Устав проекта содержит следующую информацию:

1. Название проекта.

2. Бизнес-цели компании или причины возникновения проекта.

Формулировка причины фактически дает ответ на вопрос » Зачем выполняется данный проект?».

Бизнес-цели компании обязательно учитывают стратегию развития компании, включая стратегию развития информационных технологий, на которую ориентирован проект, — например, увеличение капитализации Холдинга и привлечение инвесторов.

3. Цели проекта.

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

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

Формулировка целей должна соответствовать следующим критериям ( SMART- Specific, Measurable, Achievable, Relevant, Time-bound ):

• Конкретные (Specific) — позволяющие сформировать расписание проекта;
• Измеримые (Measurable) — позволяющие качественно (или количественно) оценить, что результат получен;
• Достижимые (Achievable) — принципиально реализуемые Исполнителем в рамках проекта, с учетом декларируемой помощи со стороны Заказчика;
• Приносящие результат (Relevant) — соответствуют ожидаемой Заказчиком пользе;
• Ограниченные во времени (Time-bound) — реализуемые в ожидаемые Заказчиком временные рамки проекта.

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

Примеры формулировок целей:

• Проектирование единых унифицированных бизнес-процессов в Головной компании и дочерних компаниях холдинга.
• Разработка единого унифицированного ERP-решения, которое предназначено для внедрения в Холдинге, состоящем из Головной компании и 10 дочерних компаний.
• Разработка инструментальных средств развертывания/тиражирования полученного решения во всех дочерних компаниях Холдинга.

4. Границы проекта.

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

• Организационные границы

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

• Функциональные границы

Указываются бизнес-направления, бизнес-процессы, которые будут покрываться ИС. Данным пунктом определяются модули ERP-систем.

• Географические границы

Указываются территориально удаленные объекты, подлежащие автоматизации.

5. Содержание проекта (задачи проекта).

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

Пример описания содержания (задач) проекта

Автоматизация бизнес-процессов:

• Управление основными средствами.
• Учет затрат.
• Управление персоналом.

Требования к бизнес-процессам должны включать:

• Требования законодательства РФ в области бухгалтерского, налогового и статистического учета и отчетности.
• Требования международных стандартов финансового учета и отчетности.
• Требования управленческого учета Головной компании Холдинга.
• Требования внутренней отчетности (внутреннего аудита).
• Требования ТК РФ, отраслевой отчетности, отчетности Головной компании Холдинга.

Начало работы над новым проектом или инициативой может быть радостным событием, но что насчёт последнего шага перед этим — согласования проекта?

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

Что такое устав проекта?

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

Устав проекта — это один из многих материалов, которые можно создать в процессе его планирования. Далее приводится сравнение устава с другими элементами планирования проектов:

Планировать проекты с помощью Asana

Устав проекта и план проекта

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

План проекта включает в себя семь основных элементов:

• Цели

• Показатели успешности

• Заинтересованные стороны и роли

• Объём и бюджет

• Вехи и ожидаемые результаты

• Хронология и график

• План обмена информацией

Читать о том, как создать план проекта, который будет вести вас правильным курсом

Устав проекта и проектное задание

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

Проектное задание состоит из четырёх частей:

• Общая информация

• Цели проекта и критерии его успешности

• Хронология проекта

• Целевая аудитория

Читать о пяти шагах к созданию отличного проектного задания

Устав проекта и экономическое обоснование

В основе устава проекта и экономического обоснования лежит один и тот же принцип: оба этих документа являются инструментами представления проекта заинтересованным лицам. Главное отличие между уставом проекта и его экономическим обоснованием заключается в объёме.

Экономическое обоснование — это формальный документ, который объясняет преимущества и риски существенных бизнес-вложений. Например, если вы предлагаете крупномасштабный инвестиционный проект с участием внешнего агентства, существенное расширение текущей деловой активности или новый продукт/услугу, вам будет необходимо представить экономическое обоснование. Если же ваш проект нуждается в согласовании, но невелик по объёму (например, схожая с прошлыми кампания или запуск продукта, соответствующий текущей стратегии выхода на рынок), подготовьте устав проекта, а не его экономическое обоснование.

Читать руководство для начинающих по написанию эффективного экономического обоснования проекта

Нужно ли создавать устав проекта?

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

• Создайте устав проекта, чтобы представить проект и получить его одобрение. Устав даёт заинтересованным лицам чёткое представление о задачах проекта, объёме, а также о том, кто будет отвечать за его реализацию. Главные заинтересованные лица могут использовать устав проекта в целях согласования проекта или внесения изменений.

• Создайте экономическое обоснование, если проект подразумевает серьёзные инвестиции. Экономическое обоснование может содержать дополнительную информацию и документацию, включая оценку рентабельности инвестиций и все сопутствующие риски проекта.

• Создайте план проекта, если проект уже согласован. План проекта будет основан на уставе и предложит дополнительные сведения, такие как хронология проекта и его основные вехи.

• Создайте проектное задание, если вам нужен документ, в котором собрана вся ключевая информация общего характера из плана проекта.

Планировать проекты с помощью Asana

Как создать устав проекта

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

«Зачем»

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

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

• Specific — конкретными

• Measurable — измеримыми

• Achievable — достижимыми

• Realistic — реалистичными

• Time-bound — ограниченными по времени

Читать статью «Как создать эффективную цель проекта (с примерами)»

«Что»

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

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

Читать краткое руководство по определению объёма проекта за 8 действий

«Кто»

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

Читать руководство по первым шагам в управлении ресурсами

Пример устава проекта

Шаблон устава проекта

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

Название проекта

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

Менеджер проекта

Кто является контактным лицом по этому проекту?

Дата последнего изменения

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

Назначение проекта

Зачем вы работаете над этим проектом?

Задачи проекта

Какие результаты и активы вы планируете получить по завершении проекта?

Объём проекта

Каковы рамки ожидаемых результатов проекта? Какие инициативы не входят в него?

Проектная группа и ресурсы

Кто работает над этим проектом? Какие ресурсы (люди, инструменты и бюджет) доступны для выполнения этой работы?

Заинтересованные согласующие лица

Кто является заинтересованными лицами проекта? С кем нужно согласовать его устав и ожидаемые результаты?

От устава к успеху проекта

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

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

Планировать проекты с помощью Asana

Мадорская Ю.М.

Искусство управления проектом заключается в том, чтобы неведомое сделать предсказуемым. И чем раньше выявятся подводные камни – тем больше шансов не нахлебаться воды.

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

Устав проекта определяет каркас проекта в 5 измерениях:

• ЦЕЛИ и ТРЕБОВАНИЯ
• ЗАДАЧИ
• РИСКИ
• УЧАСТНИКИ
• ПРАВИЛА

Также может добавляться еще шестое измерение – РЕСУРСЫ (бюджет и иные).

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

Чтобы определить каркас проекта в этих измерениях необходимо:

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

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

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

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

Рассмотрим подробнее эти задачи.

Для описания задач воспользуемся методологией функционального моделирования IDEF0.

Модель процесса разработки устава проекта

Цель моделирования: показать основные этапы, необходимые для начала проекта, их взаимосвязь и результаты, приводящие к формированию отчетного документа «Устав проекта», а также определить основные требования к процессу разработки устава проекта и требования к содержанию устава проекта.

Точка зрения: Руководитель проекта.

Контекст:  Для того, чтобы показать место процесса по разработке устава проекта и самого устава проекта в жизненном цикле проекта, контекстная диаграмма А0 соответствует процессу выполнения проекта в целом и затем детализируется на отдельные этапы. Данная модель не противоречит  PMBOK 4, но обладает большей детализацией с точки зрения процесса разработки устава проекта.

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

На диаграммах А0-А1 (рисунок 1 и 2) отражен контекст интересующего нас процесса.

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

Обычно работы по проекту начинаются с получения каких-то исходных данных, будь-то брошенная вскользь идея заказчика или формализованное ТЗ на 200 страниц. С этих исходных данных и предстоит начать «разматывать клубок» в ходе разработки устава проекта.

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

Если проект инициирован, то собранные в ходе разработки устава проекта высокоуровневые данные по всем 5(6) измерениям проекта должны быть детализированы на следующих этапах. Устав проекта является руководящим документом для последующих этапов, что и отражено на диаграмме А1 на рисунке 2.

Хотя на диаграмме А1 не отражена обратная связь между блоком А1.4 Анализировать проект и А1.1 Разработать устав проекта, нельзя забывать, что и устав проекта не является его «догмой» и может быть пересмотрен в любой момент для лучшего соответствия актуальным целям проекта и ситуации. Например, в ходе выполнения проекта выяснилось, что появляется несколько ключевых пользователей разрабатываемой системы, они безусловно должны быть включены в проект и его систему коммуникации, а их ожидания учтены и соотнесены с целями проекта.

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

Введенные на первых двух диаграммах потоки, определены в таблице ниже.

Таблица 1. Потоки данных для А0-А1

Далее нас интересует детализация процесса «Разработать устав проекта»:

Прежде чем разбирать сам процесс необходимо познакомиться с определениями потоков данных:

Таблица 2. Потоки данных для А1.1

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

На диаграмме процесса A.1.1.1, раскрывающей  процесс «Выявить и проработать систему целей проекта» показано, что выявление целей проекта начинается с определения их источников —  сторон и лиц, оказывающих влияние на ход проекта: кто принимает решения о проекте, кто принимает решение о приемке продукта, кто оказывает на него хоть какое либо влияние, пусть даже косвенное. Система целей проекта должна быть согласована с их ожиданиями. Противоречия целей проекта и ожиданий заинтересованных сторон неизбежно приводят к конфликтам как в ходе проекта, так и на этапе его сдачи. Поэтому за процессом разработки иерархии целей проекта стоит важная задача согласования целей проекта  и ожиданий заинтересованных сторон. Этот процесс необходимо будет продолжить при подборе команды проекта (процесс «Спроектировать организационную структуру проекта»), которая также определяет ход проекта.

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

Хорошая практика формулирования целей заложена в принципах SMART [2].  Чтобы можно было добежать до цели, а не только согреться, необходимо указать критерии достижения целей проекта (блок A1.1.1.3) , т.е. показатели, которые возможно измерить, а также их значения. Это позволяет снять целых комплекс конфликтов и рисков неуспешного завершения проекта.  Представьте, что вы руководитель проекта, вы выполнили проект в срок, уложились в бюджет, достигли сформулированной цели проекта — снизили затраты на изготовление продукции. А заказчик считает проект неуспешным, отказывается принимать результаты и соответственно делать выплаты. В чем же дело? Дело в том, что вы снизили затраты на 3% за 1 год, а заказчик считал, что они должны быть снижены на 10% за полгода, тогда проект для него считается успешным.

Эта сложная задача часто игнорируется, что приводит к неуспешным проектам и отражено в известной статистике ИТ- отрасли [1].

Таблица 3. Потоки данных для А1.1.1

Расширенный материал по формированию системы целей с иллюстрациями приведен в статье Цели проекта — упущенные возможности?

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

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

Риски проекта сильно влияют на его план и ресурсы, т.к. в нем[плане] должны быть предусмотрены меры по их предотвращению или хотя бы по снижению негативных последствий.

Для каждого риска рекомендуется прорабатывать поля, описанные в определении потока Риски проекта (см Таблицу 4).

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

Таблица 4. Потоки данных для А1.1.2

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

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

Таблица 5. Потоки данных для А1.1.3

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

Заключение

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

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

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

Литература

1. Тимофеев А.Н. Почему падают ИТ-проекты? //Практика проектирования систем.-2017. [электронный ресурс] — Режим доступа: http://reqcenter.pro/why-it-fails/, свободный. — Загл. с экрана
2. Duncan Haughey. Smart Goals //Project Smart.-2017. [электронный ресурс] — Режим доступа :https://www.projectsmart.co.uk/smart-goals.php, свободный. — Загл. с экрана

Initiation is one of the most crucial stages of every project. If you fail to gain sufficient support for a planned endeavor, it will never see the light of day. A project charter is a document (and planning tool), designed to help managers secure support for a new project, plus shape its overall trajectory. After reading this post, you too will be able to develop a project charter and effectively “sell” it to sponsors during a presentation. 

What is a Project Charter?

The PMBOK® Guide gives the following definition of project charter in project management:  

A project charter is a document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities.  

In layman’s terms, a project charter sets the scene for an upcoming execution by specifying: 

• What needs to be done
• Who’s responsible for which objective 
• What timeline and resources should be allocated.  

Who creates the project charter? Typically, that’s the job of the project initiator — a project leader, manager, or another stakeholder who’s going to be in charge of the initiative. This is an overview document, worth creating at the early phase of the project management lifecycle to ensure better alignment between all the parties involved. 

The main elements of the project charter include:

• Requirements — a succinct overview of jobs-to-be-done and main deliverables to be completed.
• Business needs — a summary of the reasoning behind the project, a short business/use case.
• Summary schedule — a timeline for when all the planned items will be done and the set results reached. 
• Assumptions and constraints — an acknowledgment of the risks/blockers that can derail the project from the proposed track.
• Results or Return on Investment — a list of outcomes, obtained after successful project completion.

A simple project charter runs 1-2 pages long and provides a bird-eye overview, rather than an exhaustive list of details. For complex, long-term initiatives managers usually create a set of supporting documents such as the scope of work (SOW), workload breakdown structure, project communication matrix, and so on. 

Helpful template: Project Management Pack PowerPoint Templates

The Purpose of a Project Charter

Depending on the project size and the company’s project management (PM) practices, a project charter can be treated as either:

• A formal document that’s a part of a more comprehensive project management plan.
• A self-contained informal document used internally as a reference.

In either case, the main purpose of the project charter document is to formalize the planned endeavor, plus gain authorization for it from senior stakeholders/sponsors for execution. 

In that sense, the key components of the project charter serve as a ‘sales’ document for promoting the suggested project. Your goal is to persuade others that there’s a strong need for pursuing it and justify the provisioning of requested resources. PMI research found that projects with highly engaged sponsors are 40% more likely to be successful. Additionally, one in four companies reports that inadequate sponsorship is the primary reason for project failures. A project charter helps prevent low engagement scenarios. 

Also, a project management charter is a great place to “connect the dots” between the project scope and wider organizational strategy. For example, when writing a project charter for implementing a new MarTech platform, you can reference the company’s go-to-market strategy and explain how the new tool can help drive greater brand awareness in the new market. 

Thirdly, the project charter serves as the underlying reference document for planning subsequent steps in the project lifecycle. It helps ensure that your project:

• Stays within scope
• Remains on budget
• Is sufficiently stuffed

To sum up, the importance of project charter is manifold. First, this document helps secure sufficient sponsorship for your project (from top-to-bottom). Engaged stakeholders are more likely to facilitate the project execution by removing roadblocks, assisting with change management, and provisioning extra resources should the need arise. Well-aligned grassroots teams, in turn, are less likely to lose focus or become disengaged/derailed by slow approvals or issue resolutions from the top. 

Project Charter Example + Project Charter Template

To provide you with a working example, we’ll use our project charter template (PPT) as a reference point for writing:

Here’s how a sample project charter can look launching a new workplace mentorship program. 

Project Goals

1. Formalize the scope and format of mentorship engagements. 
2. Enlist 10 department heads and c-suits for participation.
3. Conduct at least 5 group mentorship sessions and 15 private ones in 6 months. 

Scope 

• Objective 1: Collect employee feedback on the training & mentorship format they’d like to receive. 
• Result: Determine the optimal session format and preliminary program structure. 

• Objective 2: Develop an internal mechanism for matching mentors with mentees. 
• Result: Introduce a formal assessment process for match-making mentorship tandems. 

• Objective 3: Prepare supporting resources for facilitating meeting sessions.
• Result: Deliver a set of the syllabus of sessions, meeting agendas, and extra training materials. 

Team: 

• Project Manager: Sarah Tompson
• Mentorship Coordinator: Jim Robins
• Confirmed Executive Participants: Loty Johns, Samuel Lorry, Mitchel Walles, Suzan Morris, Patric Delon, Kiki Liu. 
• Unconfirmed participants: Jamal Singh, Katie Cardozo, Amanda Leeds, Jeffrey Chong. 

Results: 

• Create a 6-month mentorship program (with regular group and 1:1 sessions)
• Improve employee engagement by 5%. 

Timeline:

• Project start date: March, 15th
• Milestone 1: Employee survey launch: March, 18th
• Milestone 2: Results analysis and reporting on findings: March, 23rd
• Milestone 3: Program presentation to mentors confirmation of participation: March 27th. 
• Milestone 4: Match-making assessment development and presentation: March, 30th. 
• Milestone 5: Company-wide announcement of the program: April, 1st.
• Milestone 6: Finalization of syllabus and agendas: April, 3rd.
• Project End: First group mentorship session launch: April, 5th. 

How to Write a Project Charter: Best Practices

The above example provides a general overview of the information that should be highlighted in your project charter. Now let’s zoom in on how you should approach data collection and structuring as you develop a project charter for your initiative.

Formalize Your Project Vision, Goals, and Key Objectives

To “sell” the idea both to the stakeholders and other project participants, you need to clearly articulate the ‘why’ behind your project. 

To arrive at that ideal wording, seek input from your team first. Ask their opinion on the main opportunities, values, and possible risks they see within this project. Going back to the above example, a workplace mentorship program may flop if not enough mentors will want to participate. Thus, you may want to enlist some of your team members to help with conveying the value of the program to them. Check out our Team Charter guide to learn more.

Also, take into account wider market implications and corporate environment and connect your project goals with them. For example, you know that the company struggles with hiring for certain roles. When presenting your project charter, you can focus on how mentorship can help with upskilling certain employers and positioning them as better candidates for an internal promotion. 

Define The Scope of Work (SOW)

Provide a preliminary overview of the objectives your project will pursue. Clearly explain what issues you plan to solve and which ones to leave out. To ensure the project’s ability to deliver on its promised goals, set project boundaries via the SOW.

To create a solid SOW statement for a project charter, do the following: 

• Identify the main deliverables first 
• Determine which tasks support their successful delivery
• Indicate project charter roles and responsibilities for parties who’ll complete those tasks 
• Set a timeline for completing different tasks (milestones) 
• Provide any extra information for associated payment costs, terms, and deadlines 
• Specify if any extra work resources, software, or equipment will be needed 
• Spell out the criteria you’ll use to determine which deliverables are acceptable 

While not all of the above information should go into a less formal project charter, it’s still important to produce for your internal reference and subsequent reporting to stakeholders. 

Determine the Project Organization Structure

Based on the scope of work, list the roles you’ll need for the project, including stakeholders (internal and external), and the execution project team. If you plan to rely on extra resources (e.g. subcontractors or freelancers), specify this too. 

To effectively determine who should be on your project team and what they should be responsible for, use a RACI matrix. 

Pro tip: You can also add a RACI slide to your project charter persuasion to provide a quick overview of the main roles and responsibilities of the project. 

Map Out an Implementation Timeline

Break down your SOW into specific milestones with fixed dates. Then set a proposed start and end date for the projects. It’s okay to use preliminary dates in an Agile project charter, as long as you have the capabilities to make rapid adjustments.

Recommended article: How to Kick off a project with a Project Kick off meeting

Also, map the dependencies between different tasks on the timeline to ensure that you’d be pursuing the right course of action at the right time.  

Mention The Project Risks

Show the stakeholders that you are being realistic with your plans by referencing potential blockers and disruptors. Briefly, specify what can jeopardize the project’s success. On top, provide a brief walkthrough over how you plan to mitigate those risks and what plans you have put in place to prevent them. 

You can borrow a few slides from this risk mitigation template from SlideModel to better communicate your ideas to other stakeholders. 

Final Tip: Presenting Your Project Charter 

Given the current circumstances, you’d be most likely doing so remotely, rather than in-person. So be sure that your PowerPoint presentation looks good in digital format. In particular: 

• Ensure that the font sizes will work for different screen sizes 
• Avoid using animations as these may not look great during screencasting if someone’s connection is slow 
• Provide enough white space to make the on-screen reading experience easier. 

Also, when doing your virtual project charter presentation, always look directly at the camera (viewers), rather than at your slides. Maintaining eye contact is important for making such interactions more personable and delightful! 

Finally, remember that a project charter should be short and snappy. It has to succinctly summarize the main points of your initiative, rather than provide a complete walkthrough over the entire project life cycle.You can always email supporting project documents to those interested in more details! 

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

Что считается проектом

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

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

Рисунок 1. Условия выделения группы задач в проект

Отдельного пояснения заслуживают два признака для выделения задач в проект:

1. Снижение критичных рисков. Отдельные задачи, не носящие при этом уникального характера, могут выделяться в проект. Например, если критично важно привлечь финансирование по какой-либо из государственных программ. По своей сути, это операционная задача финансового департамента. Но если провал задачи приведет к крайне негативным последствиям, то есть смысл выделить эту задачу отдельно и усилить над ней контроль через инструментарий проектного управления.
2. Контроль за людскими ресурсами. Нередко в рамках какой-либо задачи сотрудник одного подразделения подчиняется руководителю другого подразделения. Для урегулирования конфликта интересов или для более эффективного контроля использования ресурсов, отдельные задачи могут быть выделены в проект. Примечателен пример из практики управления проектами, когда операционные задачи сотрудника были выделены в проект. В результате, ключевой для компании менеджер выпал из зоны прямого контроля одного из бенефициаров и перешел под контроль другого бенефициара.

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

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

Инструментарий управления проектами

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

• PMI;
• PRINCE2;
• SDLC;
• Agile;
• Extreme;
• Lean Six Sigma;

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

Таблица 1. Общее сравнение наиболее популярных подходов проектного управления

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

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

Основные этапы проекта

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

Можно выделить группы процессов, которые свойственны каждому проекту (см. рисунок 2).

Рисунок 2. Группы процессов проекта

Далее рассмотрим их подробнее.

Инициирование проекта

Инициирование проекта можно разделить на две части:

1. Формирование устава проекта.
2. Формирование команды проекта.

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

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

Устав проекта резюмируется в небольшую таблицу (см. таблицу 2).

Таблица 2. Резюме проекта.

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

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

Планирование проекта

Этап должен ответить на следующие вопросы:

1. Что планируется сделать?
2. Как планируется сделать?
3. Какие события являются критериями завершения проекта?

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

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

Рисунок 3. Структура плана проекта

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

Два других раздела итогового плана, о которых стоит упомянуть отдельно – это финансовая модель и план мероприятий. Приведем несколько основных тезисов, обязательных при формировании этих разделов.

1. Финансовый план и план мероприятий должны быть синхронизированы.
2. Финансовый план должен рассчитывать объем необходимых инвестиций и бюджеты проекта. Бюджеты могут быть разбиты по времени и подразделениям, но в сумме они должны быть сопоставимы с объемом запрошенных инвестиций.
3. Финансовый план должен учитывать именно те ресурсы, которые будут предоставлены для его реализации. Из этого тезиса, например, возникает необходимость разделения учета расходов на персонал на операционную деятельность и непосредственно на реализацию проекта.
4. Оба плана должны допускать возможность внесения изменений в рамках утвержденных процессов.
5. Финансовый план и бюджет проекта должны быть синхронизированы с текущей учетной политикой компании. Неэффективно планировать расходы и доходы без возможности последующего сбора соответствующих фактических значений.

Планирование проекта – это сложный и порой дорогостоящий процесс. Самое важное на этом этапе понять два ключевых момента:

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

Проектные задачи – это всегда умение работать с неопределенностью.

Исполнение проекта

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

1. Необходимо защищать периметр проекта. Желание расширить его границы возникает практически всегда. И здесь важно донести до заказчика и спонсора необходимость внесения соответствующих изменений в утвержденные планы или о воздержании от внесения таковых.
2. Основная роль руководителя проекта – это коммуникации. Важно ограничивать свое желание уйти в исполнение, разработку продукта, проектирование и т.п. Коммуникации на предприятии могут стать настоящим кошмаром проектного управления, если им не уделять большую часть своего внимания.
3. Согласованные в проектной документации ресурсы должны быть реально предоставлены.
4. Мотивация персонала для проектных и операционных задач должна быть разной. Проектные задачи – это всегда умение работать с неопределенностью. Здесь важно избегать формальных решений, и отдельная мотивация является одним из наиболее эффективных инструментов. Она может быть выражена в виде премий, доли в проекте и в виде любых других поощрений.

Мониторинг и контроль проекта

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

Рисунок 4. Иерархия проектов

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

Закрытие проекта

Проект должен закончиться. В отличие от операционной деятельности, проект носит подчеркнуто временный характер. Причины закрытия проекта я привел на рисунке 5.

Рисунок 5. Варианты закрытия проекта

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

Заключение

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

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