Как написать устав проекта

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

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

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

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

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

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

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

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

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

  • Цели

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Зачем»

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

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

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

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

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

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

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

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

«Что»

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

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

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

«Кто»

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

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

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

[Проектное задание] Устав проекта маркетинговой кампании

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Устав проекта (УП) разъясняет,
в каком направлении будет идти ваша компания и зачем,
что изменится и какие риски при этом возникнут.

Этот документ не только содержит базовую информацию, но и отражает общее видение стейкхолдеров.

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

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

Можно написать документ на несколько десятков страниц, наполнив его всевозможными деталями, однако вряд ли вы захотите потом это перечитывать. Поэтому лучше все вместить максимум в 3-5 страниц, идеально — 1-2 страницы.

Как пример, устав проекта может выглядеть как текстовый документ, Google-документ или презентация. Также он может выглядеть как задача с метками «Документы» и «Стратегическая» в программе управления проектами Worksection:

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

Что проясняет УП?

  • Какой специалист становится проектным менеджером (ПМ) и какой его круг полномочий
  • Цель проекта и его связь с деловыми показателями
  • Кем одобрен проект и кто будет его финансировать
  • Состав проектной команды, требования и ожидания от проекта, ответственность каждого из его участников
  • Критерии успеха

Когда создается УП?

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

Кто разрабатывает и одобряет УП?

Разработкой УП обычно занимаются опытные ПМ. Документ одобряется спонсором проекта.

Что должно содержаться в УП?

  • Обзор и обоснование
  • Требования и цели
  • Имена ПМ, спонсоров, стейкхолдеров
  • Состав ПК
  • Информация о вовлеченных сторонах
  • Риски, ограничения, сильные и слабые стороны, возможности и угрозы
  • Ожидаемые показатели
  • Распределение обязанностей между каждым участником
  • Все доступные и требуемые ресурсы
  • Методологии, которые будут использоваться
  • Стратегии коммуникации
  • Бюджет и сроки
  • Расписание
  • Ключевые показатели эффективность (KPI) для измерения успешности

Разработка устава проекта

Шаг 1. Определите конечную цель.

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

Проанализируйте, как проект может повлиять на бизнес-показатели организации.

Шаг 2. Создать организационную структуру.

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

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

Команда в Worksection

Шаг 3. Подготовить план имплементации УП.

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

Шаг 4. Предусмотрите риски и проблемные моменты.

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

3 главные причины, почему без устава ваш проект рискует провалиться

  1. Проектному менеджеру будет не хватать полномочий, а проекту — ресурсов. Готовый устав проекта же документирует одобрение от стейкхолдеров. Поэтому ПМ не придется постоянно выбивать дополнительное финансирование или сражаться за свои полномочия.
  2. Нет понятных ожиданий от проекта. А вот в уставе его цели и задачи подробно описаны. Это уменьшает вероятность, что содержание проекта начнет в дальнейшем разрастаться.
  3. Проект приведет вас к результатам, которые идут вразрез с целями организации. Ведь в УП, наоборот, обосновывается важность проекта для бизнеса и как он соответствует видению компании.

8 вопросов для создания более эффективного УП

  1. Было ли потрачено достаточно времени и сил, чтобы понять необходимость запуска проекта? Иначе вы не определите ключевые элементы и цели при составлении УП.
  2. Имеется ли четкая связь со стратегическими целями компании? Проект принесет пользу, если он имеет логику в глобальной миссии организации.
  3. Какую ценность проект принесет для собственников и руководства? Как он вписывается в бизнес-цели компании?
  4. Было ли описание проекта понятно составлено? Когда есть точные показатели для бюджета, сроков, качества, то будет намного легче отобразить более развернутую картину для стейкхолдеров, спонсоров проекта и ПК.
  5. Цели реалистичные и досягаемые? В обратном случае нет смысла дарить ложные надежды стейкхолдерам и спонсорам.
  6. Каковы риски для организации, если не запускать проект? Если они минимальные, тогда нужно проанализировать, стоит ли реализовать новую идею. Либо существующие внутренние и внешние риски напротив подталкивают быстрее начать проект.
  7. Доступны ли требуемые ресурсы? Если нет, то планирование проекта было неудачным. Даже если необходимые ресурсы имеются у компании, нужно предусмотреть нежелательные ситуации при анализе рисков.
  8. Как реалистично измерить успешность проекта? KPI должны быть пересмотрены, если необъективно отражают прогресс проекта.

Сперва создайте проект, придумайте для него название соответственно целям. С помощью меню «Пригласить в проект» пригласите пользователей, которые помогут вам создать устав. Заполните поля с информацией об участниках проекта: имя, фамилия, e-mail, отдел.

Также вы можете пригласить заказчиков, выбрав тип «Клиент» при добавлении компании.

Теперь создавайте задачи, которые соответствуют 3-5 целям вашего проекта, упомянутым в уставе. Выбирайте меню «Поставить новую задачу», добавьте ее подробное описание: к чему вы стремитесь, какие критерии успешности, есть ли привязка к другим целям.

Создание задачи в Worksection

Далее установите приоритет задачи, назначьте ответственного за выполнение, укажите сроки и затраты.

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

Чтобы завершить создание задачи, нажмите «Создать задачу». Если нужно разбить задачу на несколько подзадач, вы можете сразу добавить в режиме «Пакетного добавления задач».

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

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

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

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

Обоснование

Зачем инициирован проект, какие возможности он откроет для компании?

Цели и критерии их выполнения

Краткий план

Какие процессы будут выполнены?

Стейкхолдеры

Заказчик

ФИО

Спонсор

ФИО

Проектный менеджер

ФИО

Участники
проектной команды

ФИО, ФИО, ФИО, …

Ключевые этапы

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

Бюджет

Внесите главные расходы.

Ограничения, предположения, риски и зависимости

Ограничения

Какие факторы могут повлиять на проект?

Предположения

Какие ситуации возникнут, которые помогут вам достичь целей?

Риски и зависимости

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

Подписи

ФИО,
Заказчик проекта

ФИО,
Спонсор проекта

ФИО,
Менеджер проекта

Вердикт

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

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

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

Чудо-бумажка, или зачем нужен устав проекта и как его написать





Устав проекта (Project Charter) – это документ, который обычно готовит руководитель проекта после получения вводных о проекте.

Зачем нужен устав проекта

Устав содержит основные характеристики проекта и согласуется основными заинтересованными лицами (как минимум – Заказчиком и Спонсором проекта). Как правило, разработка и подписание Устава несет в себе 3 основные функции:

  1. Определить основные требования к результату проекта и основные характеристики самого проекта (бюджет, сроки).
  2. Формально запустить проект, т. к. только после подписания проект считается действительно существующим в Компании.
  3. Наделить руководителя проекта определенным уровнем полномочий (каким именно – зависит от Компании).

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

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

Как написать устав проекта

Содержание устава проекта часто зависит от специфики Компании. В качестве примера можно привести следующий набор разделов устава:

  1. Начальные условия (Project Background) – что привело к инициации проекта, входные условия, «боль» Заказчика.
  2. Цели и ожидания проекта (Project Objectives / Expectations) – чего мы хотим достичь на выходе. Это что-то должно быть измеримым (по SMART или как-то еще, неважно) и не допускать двойного толкования. Например, цель «сделать систему CRM, чтобы привлекать больше клиентов» – как-то не очень, правда? А вот «разработать и внедрить систему CRM для сотрудников отдела продаж Северо-Волжского филиала до 01.12.2015 для обеспечения мгновенного доступа к информации о тратах клиентов в разные периоды года» – это уже немножко лучше.
  3. Содержание и результаты (Scope and deliverables) – что именно мы включаем в состав проекта и какие конкретные результаты получим? Например, если нужно выпустить новую систему CRM, то на выходе мы должны иметь саму систему, сервера, на которых мы ее поставим, обученных пользователей и документацию для передачи в поддержку (а может, и саму организованную с нуля поддержку). В этом разделе вы четко ограничиваете, что вы сделаете. Еще очень полезно сюда же включить подраздел со списком того, что в содержание проекта не входит в явном виде (чтобы все это согласовали и потом никто не удивлялся, почему вы в рамках проекта еще и систему управления инцидентами для техподдержки системы не внедрили).
  4. Ключевые требования и характеристики (Requirements and Characteristics) – то, что не является результатом проекта, но важно для него. Если опять вернуться к системе CRM, то типовым требованием может быть «Срок обучения сотрудника системе не должен превышать 1 рабочего дня», «Поддержка системы не должна быть дороже 200 000 р. в год», «В системе одновременно должно работать не менее 300 человек» и подобное.
  5. Бюджет и сроки (Cost and Timelines) – деньги, сроки и их взаимоотношения с другими сторонами проектного треугольника. Например, сюда полезно вписать приоритеты по убыванию типа Бюджет-Содержание-Сроки. Т.е. потратить больше денег прямо никак нельзя, уменьшать получаемые результаты сильно нежелательно (но можно, в самом крайнем случае), и если надо ради первых двух пунктов увеличить срок – это ок. Часто тут многие зависают, мол, «да нам все важно!», но в правильно мире вы идете к Спонсору и спрашиваете его, если спонсор адекватен – у него это понимание приоритетов точно есть, и он поделится им с вами.
  6. Ключевые участники (Key Stakeholders) – основные заинтересованные лица, как минимум – Спонсор, Заказчик, те, кому придется делиться с вами ресурсами (в матричной структуре), ваш руководитель, держатель бюджета и т.д. Включать сюда всю компанию не стоит, просто подумайте и напишите: а) кто должен знать о проекте на этой стадии б) к чьему авторитету вам будет полезно апеллировать в ходе проекта
  7. Допущения и ограничения проекта, основные риски (Project Assumptions and Restrictions, Main Risks) – про эти вещи мы еще поговорим подробнее, но в целом цель включения их в устав проекта – донести до всех заинтересованных лиц особенности того окружения и того момента, в которых вы делаете проект, озвучить свои опасения и получить подтверждение их готовности в этих вопросах вам всячески помогать. Ну и чтобы потом никто не говорил «а нам не сказали».

Пример из жизни! Давайте сделаем очень короткий устав проекта «Ремонт в квартире», как образец, а то теория  – это хорошо, но не всегда понятно:

  1. Начальные условия – живу в квартире уже 15 лет, краска на потолке облупилась, батареи старые и вообще мне некомфортно. Я заказала дизайн-проект, мне нарисовали квартиру моей мечты, осталось только сделать.
  2. Цель – сделать ремонт в квартире площадью 65 метров в строгом соответствии с дизайн-проектом не позже чем к такому-то числу и не больше чем за такие-то деньги.
  3. Содержание и результаты (Scope and deliverables) – на выходе должны быть полностью замененные коммуникации (сантехника, электрика, отопление), новая входная дверь, новая сантехника, косметический ремонт (плитка в санузле, ламинат, обои и потолки во всех комнатах), заказанная и установленная кухня, полностью все освещение и вся мебель. Что не буду делать: отдирать стяжку пола (что ей стало-то за 15 лет), делать теплые полы и звукоизоляцию, и менять окна (они хорошие, только 2 года назад поставила).
  4. Ключевые требования и характеристики – все должно быть в строгом соответствии с дизайн-проектом (см.пачку приложенных чертежей и смету), если что-то сделать нельзя или дороже больше чем на 10% – надо согласовывать на семейном совете. Разводку электрики и сантехники надо согласовать с местным ЖЭКом.
  5. Бюджет и сроки (Cost and Timelines) – 2 млн. рублей на все, включая мебель и кухню (30% на черновую отделку и коммуникации, 20% на чистовую, включая сантехнику, 20% на кухню и 30% на мебель). Срок – максимум 4 месяца, т.к. мы всего на 4 месяца договорились к родителям переехать, в крайнем случае можно добавить еще 2 недели (поживем в гостинице). Приоритеты бюджет-качество-сроки (лучше в гостинице поживем, пока штукатурка будет сохнуть, но денег на тепловую пушку для сушки не выделим и клеить обои на мокрую штукатурку тоже не будем).
  6. Ключевые участники (Key Stakeholders) – я, муж, родители, бригада, с которой я уже договорилась, соседи (надо уточнить, когда у них дети спят), ЖЭК (с ними надо проект согласовать).
  7. Допущения и ограничения проекта, основные риски (Project Assumptions and Restrictions, Main Risks) – допущения: соседи нескандальные, работать можно весь световой день, бригада адекватная и не будет бухать на объекте, курс доллара глобально не вырастет и стройматериалы сильно не подорожают; ограничения: нельзя работать после 22.00, не могу приезжать контролировать работу в будни (работаю), первая выплата бригаде возможна только в апреле (закончится депозит, где деньги на ремонт лежат); риски: возможно, ошибочно посчитана смета и денег на все не хватит, в дизайн-проекте ошибка, такую перепланировку узаконить нельзя, т.е. придется ремонт останавливать и все переделывать.

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

Мораль: устав даже на 1 страничке А4, подписанный заинтересованными лицами, лучше чем неподписанный на 5 страничках. И требование подписать его до начала работ со стороны РМа полностью законно в любой компании, более того – это прибавляет вам профессионального веса, позволяет понять «а чего же мы все-таки делаем» и получить хоть какие-то полномочия. Если управление проектами в компании отсутствует как класс, то даже неподписанный устав лучше чем его отсутствие, вы хотя бы разберетесь, что делать, и настроитесь на правильный лад с самого начала проекта (да простит меня РМВОК).

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

Всего за 99 руб вы можете скачать готовый детальный шаблон устава ИТ-проекта в docx. В готовом примере устава проекта вы найдете все необходимые пункты – от содержания проекта и описания ролей и обязанностей участников проекта до перечня типовых рисков. После оплаты на почту вы получите архив с шаблоном. Сэкономьте свое время, оно стоит намного дороже!
Скачайте готовый пример устава проекта и начните работать прямо сейчас вместо траты нескольких часов на поиск и написание типовых разделов.
Купить готовый шаблон Устава за 99 руб.

Рекомендуем! Также за 249 руб вы можете скачать набор из трех разных готовых шаблонов уставов ИТ-проектов в docx, в том числе – два расширенных примера готовых уставов проектов (для работы с подрядчиком/заказчиком) и один сокращенный пример готового устава проекта (для внутренних проектов). Набор примеров уставов поможет вам создать на их основе именно тот устав вашего проекта, который нужен именно вам!

Купить 3 готовых шаблона Устава за 249 руб.





Информация полезна? Поддержи развитие проекта!

На кофе и новые материалы для читателей блога :)

Еще статьи

Показать еще

комментарии

Подписаться на нашу рассылку

Еженедельная рассылка полезных материалов

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

Устав проекта (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-систем.

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

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

Таблица
4.2.
Пример границ проекта

Раздел функциональности Процессы, не подлежащие реализации
Организационный менеджмент Формирование фонда заработной платы по специфичным методикам.
Система оповещения по функциям Управления персоналом в целом.
Ведение аттестации рабочих мест, вредных условий труда
Администрирование персонала Ведение параллельных данных на английском языке
Учет рабочего времени Фактический учет рабочего времени (будет использоваться негативный учет).
Учет рабочего времени по заказам/объектам.
Учет работы во вредных условиях
Расчет зарплаты Сдельная система оплаты труда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1. Контекстная диаграмма А0

Рисунок 1. Контекстная диаграмма А0

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

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

Рисунок 2. Диаграмма А1 «Выполнить проект»

Рисунок 2. Диаграмма А1 «Выполнить проект»

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

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

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

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

Имя потока Определение потока
Данные проекта * данные, дополнительные к исходным данным, которые были получены в ходе разработки устава проекта *
Исходные данные проекта * любые исходные данные, полученные до организации проекта. Это могут быть требования заказчика, данные о предметной области проекта и др.  *
Корпоративный стандарт УП * стандарт предприятия, определяющий требования к процессам управления проектами. Может включать правила выполнения, детальное описание процессов, шаблоны документов. Степень детализации определяется в рамках каждого предприятия. Данный стандарт может являться частью стандартов СМК *
Корректировки * предложения по изменению проекта *
План проекта * оперативный план проекта с назначенными ресурсами, на основании которого выполняются работы *
Проектная база или редактор * инструмент для разработки проекта, в зависимости от выбранной технологии  управления проектом – документоориентированной или ориентированной на данные *
Результаты проекта * все результаты, полученные в ходе выполнения проекта *
Руководитель проекта * лицо со стороны исполнителя проекта, отвечающее за координацию и исполнение проекта *

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

Рисунок 3. Диаграмма А1.1. «Разработать устав проекта»

Рисунок 3. Диаграмма А1.1. «Разработать устав проекта»

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

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

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

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

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

Рисунок 4. Диаграмма процесса A.1.1.1 «Выявить и проработать систему целей проекта»

Рисунок 4. Диаграмма процесса A.1.1.1 «Выявить и проработать систему целей проекта»

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

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

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

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

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

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

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

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

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

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

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

Рисунок 5. Диаграмма процесса A.1.1.2 «Провести стратегическое планирование».

Рисунок 5. Диаграмма процесса A.1.1.2 «Провести стратегическое планирование».

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

Имя потока Определение потока
Границы проекта * цели, требования и задачи, не входящие в проект *
Задачи по предупреждению рисков * задачи, которые необходимо учесть в плане работ, чтобы предупредить риски*
Методы контроля хода проекта * процедуры определения состояния (хода) проекта, в т.ч. периоды отчетности, формы отчетности *
Риски проекта * событие, наступление которого может привести к нарушению обязательств по проекту. Риск проекта описывается по следующей схеме:
1. Название — кратко отражает причину возникновения риска
2. Причина — полное описание причины возникновения риска
3. Возможное событие — событие, наступление которого возможно в следствие данной причины и которое может привести к нарушению обязательств по проекту
4. Результат — последствия наступления события для проекта
5. Предотвращение — меры по предотвращению причины события или самого события
6. Смягчение — меры по смягчению последствий наступления события
Также необходимо указать статус и тип обработки. *
Этапы и результаты * список или иерархия основных этапов проекта, а также результаты, которые должны быть получены на каждом этапе *

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

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

Рисунок 6. Диаграмма A1.1.3 процесса «Спроектировать организационную структуру проекта»

Рисунок 6. Диаграмма A1.1.3 процесса «Спроектировать организационную структуру проекта»

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

Имя потока Определение потока
Офиц. коммуникации проекта * признанные каналы  (e-mail, телефон, личная встреча, автоматизированная система)  и формы  передачи (форма сообщения, необходимость подписей) официально подтверждаемой информации. *
Роли и области ответственности * роль описывается набором функций, выполняемых ролью, а также процессами, за успешное выполнение которых она отвечает *
Участники проекта и их роли * список участников проекта, в котором для каждого участника указывается его роль в проекте *
Орг. структура проекта * организационная структура проекта *

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

Заключение

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

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

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

Мадорская Ю.М. Разработка устава проекта. Методическое пособие. //Практика проектирования систем.-2017. [электронный ресурс] — Режим доступа: http://reqcenter.pro/project_charter/ , свободный. — Загл. с экрана

Литература

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

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

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

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

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

Он помогает определить уровень полномочий руководителя проекта и направление проекта.

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

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

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

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

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

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

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

1. Определите видение проекта

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

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

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

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

2. Определите заинтересованные стороны и клиентов

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

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

Карта заинтересованных сторон - Анализ заинтересованных сторон

Карта заинтересованных сторон (нажмите на шаблон, чтобы отредактировать его онлайн)

3. Создайте организационную схему

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

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

Шаблон организационной схемы

Шаблон организационной схемы (нажмите на шаблон, чтобы отредактировать его онлайн)

4. Определите этапы проекта

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

Шаблон расписания проекта

Шаблон расписания проекта (нажмите на шаблон, чтобы отредактировать его онлайн)

5. Создание плана ресурсов

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

6. Установите бюджет проекта

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

7. Перечислите зависимости, ограничения и риски

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

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

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

8. Наметьте план реализации

Здесь вы составите план действий, выделив основные даты или этапы.

Шаблон плана действий

Шаблон плана действий (нажмите на шаблон, чтобы отредактировать его онлайн)

Визуальный устав проекта

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

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

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

Шаблон 1

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

Шаблон устава проекта (нажмите на шаблон, чтобы отредактировать его онлайн)

Шаблон 2

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

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

Шаблон 3

Одностраничный устав проекта

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

Каковы ваши мысли по поводу руководства?

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

Есть ли лучшие практики, которым вы следуете при создании устава проекта? Поделитесь ими с нашими читателями в разделе комментариев ниже.

Понравилась статья? Поделить с друзьями:
  • Как написать успокой
  • Как написать успокоился правильно
  • Как написать успокоилась правильно
  • Как написать успешный сценарий
  • Как написать успешный проект