Устав проекта (Project Charter)

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

Аудитория: спонсор, PM, стейкхолдеры.

Статус: устоявшийся (PMBOK, PRINCE2 PID).

Не путать с: Business Case (обоснование инвестиций — предшествует уставу), Project Plan (детальный план — следует за уставом), PRINCE2 PID (Project Initiation Documentation — аналог, но детальнее).

Общее #

Устав проекта (Project Charter) — документ, формально авторизующий существование проекта и наделяющий руководителя проекта (PM) полномочиями использовать ресурсы организации в работах проекта. Определение из PMBOK: устав — это «документ, выпущенный инициатором или спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия применять организационные ресурсы к операциям проекта» (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).

В PMBOK уставу посвящён отдельный процесс — Develop Project Charter («Разработка устава проекта»). Это единственный процесс группы инициации и одновременно вход в область знаний Project Integration Management (интегративное управление проектом): устав открывает проект и связывает его со стратегией организации. Входами процесса выступают бизнес-документы (business case, план управления выгодами), соглашения, факторы среды предприятия и активы процессов организации; выходом — сам устав и журнал допущений (assumption log).

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

Отсюда практическое правило, звучащее почти как лозунг: «нет устава — нет проекта» (no charter — no project). Работы без устава — это не проект, а чья-то деятельность за чужой счёт: у неё нет формального мандата, бюджета и единого ответственного, а у PM — полномочий останавливать, расширять или закрывать её. В зрелых организациях PMO просто не пропускает такую работу в отчётность и ресурсные циклы.

По объёму устав принципиально короткий — 1–3 страницы. Это документ уровня решений, а не деталей: цели, критерии успеха, границы, полномочия, бюджет укрупнённо. Детализация начинается после устава — в плане управления проектом и производных документах.

Разделение ролей при создании документа устоялось практикой: разрабатывает устав, как правило, сам руководитель проекта (или назначаемый будущий PM — участие в разработке устава считается лучшим стартом работы: PM с первых дней знает рамку, которую потом будет защищать), а издаёт и утверждает — спонсор или инициатор. Автор документа и его издатель сознательно разные лица: устав, написанный спонсором «для PM», остаётся чужим мандатом; устав, подписанный самим PM, — самоназначением.

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

Зачем нужен устав #

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

• Авторизация проекта. Устав — юридически и организационно значимый акт: с его подписанием проект начинает существовать для организации. Появляется точка отсчёта для бюджета, расписания и отчётности; одновременно фиксируется и база для будущих изменений — любое существенное отклонение от устава требует явного решения спонсора, а не «тихого дрейфа».
• Делегирование полномочий PM. Вторая половина определения PMBOK не менее важна первой: устав наделяет руководителя проекта правом запрашивать и использовать ресурсы — людей, бюджеты, инфраструктуру. Без этого мандата PM вынужден «занимать» авторитет у функциональных менеджеров в каждой транзакции. Полномочия в уставе полезно прописать конкретно: право формировать команду, управлять бюджетом в пределах утверждённой суммы, принимать операционные решения без эскалации.
• Единый источник правды о целях и ограничениях. Спор «а что мы вообще делаем и до какого момента» решается не воспоминаниями встречи трёхмесячной давности, а ссылкой на подписанный документ. Устав фиксирует цели, критерии успеха, границы и ограничения — то есть рамку, внутри которой только и возможны осмысленные компромиссы.
• База для коммуникаций. Устав задаёт первичный список стейкхолдеров и ожидания спонсора — исходную точку для плана коммуникаций: кому, что и как часто проект обязан сообщать. Регулярная отчётность против целей устава — стандартное содержание статус-отчётов.
• Вход для всех остальных документов проекта. План управления проектом, реестр рисков, реестр стейкхолдеров, план качества, WBS — каждый из этих артефактов выводится из рамки, заданной уставом. Изменение устава каскадом меняет всё вниз по цепочке, поэтому устав и меняется редко и только через спонсора.

Отдельно стоит функция «порог выхода» (kill switch): устав с критериями успеха даёт организации легитимный механизм остановить проект. Если бизнес-условия изменились и цели устава недостижимы в рамках ограничений — проект не «дотягивается» молча, а закрывается явным решением с фиксацией уроков. Проекты без устава умирают долго и незаметно, потребляя ресурсы уже без всякой цели.

Содержание устава (по PMBOK) #

PMBOK не предписывает жёсткого формата — состав разделов варьируется от организации к организации, — но описывает типовое содержание. Ниже — десять блоков, покрывающих практику; два из них (цели с критериями успеха и полномочия PM) — обязательное ядро, без которого устав не работает.

Информация о проекте #

Формальная «шапка»: название проекта, спонсор, дата издания устава, версия документа, связь с программой или портфелем, если проект входит в них. Здесь же — краткая формулировка сути проекта одним-двумя предложениями: чтобы человек, впервые открывший документ, за полминуты понял, о чём проект.

Цели проекта и критерии успеха #

Центральный раздел. Цели фиксируют, что проект должен достичь; критерии успеха — как организация узнает, что достигло. Рабочий стандарт формулировок — SMART: конкретность (specific), измеримость (measurable), достижимость (achievable), релевантность (relevant), ограниченность во времени (time-bound). Разница между лозунгом и целью видна сразу:

В организациях, живущих в логике OKR, цели устава удобно сверять с квартальными key results: проект не обязан совпадать с ними один в один, но конфликт («проект идёт туда, куда OKR не смотрят») — сигнал пересмотреть либо устав, либо сам проект.

Критерии успеха стоит писать проверяемыми: метрика, базовое значение, целевое значение, срок измерения. Тогда вопрос «закрыт ли проект успешно» перестаёт быть вопросом мнений.

Бизнес-кейс #

Одним-двумя абзацами — зачем проект нужен организации: какую проблему решает, какую выгоду приносит, чем обусловлена срочность. Полное обоснование живёт в отдельном документе Business Case; устав лишь резюмирует его и ссылается. Читатель устава должен понимать мотив, не открывая бизнес-кейс.

Руководитель проекта и его полномочия #

Имя PM и границы его власти: право распоряжаться бюджетом до согласованной суммы без дополнительного согласования, формировать команду, эскалировать решения на спонсора, останавливать работы. Распределение ролей детализируется позже — в матрице ответственности RACI (готовящаяся статья, /docs/project-managment/raci-matrix) — но уровень полномочий PM фиксируется именно здесь, потому что делегирует его устав.

Бюджет и ресурсы #

Суммарная оценка бюджета и ключевых ресурсов high-level: команда в составе (роли, количество), внешние подрядчики, лицензии, инфраструктура. Точность — порядок величины и структура, а не постатейная смета: детальный бюджет — часть плана проекта, который создаётся после устава. Полезно сразу указать, какие резервы заложены и кто ими распоряжается.

Ограничения и допущения #

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

Допущения (assumptions) — утверждения, принимаемые истинными без доказательств: «интеграция с платёжным шлюзом займёт месяц», «команда высвобождается с 1 октября». Каждое допущение — потенциальный риск: систематическая работа с ними ведётся в управлении рисками, и журнал допущений (assumption log), начатый при разработке устава, становится входом реестра рисков.

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

Основные вехи #

Ключевые контрольные точки (milestones) укрупнённо: 3–7 событий, значимых для спонсора и стейкхолдеров, — прототип, готовность к пилоту, промышленный запуск, завершение приёмки. Календарная детализация — в расписании проекта; здесь достаточно ориентировочных дат. Вехи устава — тот каркас, по которому спонсор отслеживает ход проекта; их визуализация — классика диаграммы Ганта.

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

Первичный перечень заинтересованных сторон high-level: кто влияет на проект, кто получает выгоду, чьи интересы надо учитывать. Полный анализ — по атрибутам власти, легитимности и срочности — выполняется по модели Митчелла-Агле-Вуда уже в реестре стейкхолдеров; устав лишь называет ключевых фигур и характер их заинтересованности.

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

Scope in / scope out: что входит в проект и — не менее важно — что не входит. Явные исключения («в проект не входит миграция исторических данных», «поддержка после запуска передаётся эксплуатации») защищают проект от расползания содержания (scope creep): когда заказчик просит «ещё чуть-чуть», ссылка на границы устава возвращает разговор в русло управления изменениями. Границы, зафиксированные на старте, — основа будущего управления содержанием.

Подписи #

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

Шаблон устава #

Готовый шаблон, покрывающий все разделы выше. Рассчитан на 1–2 страницы: заполнение «не влезает в две страницы» — сигнал, что в устав попадает детализация уровня плана, которой здесь не место.

# Устав проекта: <название проекта>

- **Версия:** 1.0
- **Дата:** <YYYY-MM-DD>
- **Спонсор проекта:** <имя, роль>
- **Руководитель проекта:** <имя>

## Суть проекта

<1–2 предложения: что делаем и зачем>

## Цели и критерии успеха

| # | Цель (SMART) | Критерий успеха | Срок |
|---|--------------|-----------------|------|
| 1 | <цель> | <метрика: база → цель> | <дата> |

## Бизнес-обоснование (кратко)

<Проблема, ожидаемая выгода, ссылка на Business Case>

## Руководитель проекта и полномочия

PM уполномочен:

- распоряжаться бюджетом проекта в пределах <сумма>;
- формировать команду и распределять задачи;
- принимать операционные решения; эскалация — спонсору.

## Бюджет и ресурсы (high-level)

- Бюджет: <сумма, точность ±30%>, резерв <% или сумма>.
- Команда: <роли и количество>.
- Внешние зависимости: <подрядчики, лицензии, инфраструктура>.

## Ограничения

- Срок: не позднее <дата>.
- Бюджет: не более <сумма>.
- <Технологические, регуляторные, договорные рамки>

## Допущения

- <допущение 1>
- <допущение 2>

## Основные вехи

| Веха | Ориентировочная дата |
|------|----------------------|
| <веха 1> | <дата> |

## Стейкхолдеры (ключевые)

| Стейкхолдер | Роль / интерес |
|-------------|----------------|
| <имя, группа> | <что им важно> |

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

**Входит:** <перечень>

**Не входит:** <перечень — не менее конкретный, чем «входит»>

## Утверждение

| Роль | Имя | Дата | Подпись |
|------|-----|------|---------|
| Спонсор проекта | | | |
| Руководитель проекта | | | |

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

Пример заполнения #

Тот же шаблон, заполненный для условного проекта внедрения service-деска. Показывает уровень детализации, уместный в уставе: конкретика — в формулировках целей и границ, а не в декомпозиции работ.

# Устав проекта: Единый service-desk для клиентского сервиса

- **Версия:** 1.0
- **Дата:** 2026-03-02
- **Спонсор проекта:** И. Петров, директор по клиентскому сервису
- **Руководитель проекта:** А. Смирнова

## Суть проекта

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

## Цели и критерии успеха

| # | Цель (SMART) | Критерий успеха | Срок |
|---|--------------|-----------------|------|
| 1 | Сократить среднее время первого ответа | С 14 ч до 2 ч (медиана за месяц) | 01.09 |
| 2 | Перевести обращения в единую систему | ≥90% обращений регистрируются в системе | 01.08 |
| 3 | Обеспечить прозрачность статуса | Доля обращений со «стухшим» статусом >5 дней — <5% | 01.09 |

## Бизнес-обоснование (кратко)

Три несвязанных канала дают дублирование обращений (≈18%),
невоспроизводимую статистику и штрафные риски по SLA крупных
контрактов. Полный расчёт — Business Case v2.1 (вкладка «Файлы проекта»).

## Руководитель проекта и полномочия

PM уполномочен:

- распоряжаться бюджетом проекта в пределах 9,5 млн руб.;
- привлекать до 6 штатных специалистов по согласованию с ФО;
- выбирать подрядчика из короткого списка закупки;
- останавливать работы при блокере >3 рабочих дней с эскалацией спонсору.

## Бюджет и ресурсы (high-level)

- Бюджет: 9,5 млн руб. (точность ±20%), резерв 10% (распоряжается PM).
- Команда: PM, бизнес-аналитик, 2 интегратора, 0,5 методиста.
- Внешние зависимости: лицензии (закупка Q2), подрядчик внедрения.

## Ограничения

- Срок: промышленный запуск — не позднее 01.09 (сезонный пик обращений).
- Бюджет: не более 9,5 млн руб. (лимит CAPEX года).
- Данные клиентов — только в контуре организации (требование ИБ).

## Допущения

- Действующие SLA контрактов не пересматриваются в 2026 году.
- Функциональные руководители высвободят специалистов с 15.03.

## Основные вехи

| Веха | Ориентировочная дата |
|------|----------------------|
| Пилот на одном направлении | 15.05 |
| Все каналы переведены в систему | 01.08 |
| Промышленная эксплуатация | 01.09 |

## Стейкхолдеры (ключевые)

| Стейкхолдер | Роль / интерес |
|-------------|----------------|
| Директор по клиентскому сервису | Спонсор: SLA, издержки |
| Руководитель ИТ | Владелец инфраструктуры |
| Руководители линий поддержки | Процесс и обучение команд |
| Крупные корпоративные клиенты | Скорость реакции (SLA) |

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

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

**Не входит:** чат-бот и самообслуживание (отдельная инициатива 2027),
внедрение в филиале Казани (повторное использование, вне бюджета).

## Утверждение

| Роль | Имя | Дата | Подпись |
|------|-----|------|---------|
| Спонсор проекта | И. Петров | | |
| Руководитель проекта | А. Смирнова | | |

Обратите внимание на границы: исключения («чат-бот», «филиал в Казани») сформулированы так же конкретно, как включения, — это половина защитной функции устава.

Устав vs Business Case vs Project Plan #

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

Логика последовательности: бизнес-кейс убеждает организацию, что проект делать стоит; устав констатирует, что организация решила его делать и делегирует полномочия; план описывает, как его сделать. Устав без бизнес-кейса — авторизация без обоснования (типично для «политических» проектов); бизнес-кейс без устава — обоснование без запуска (инициатива, живущая в презентациях).

Цепочка работает и в обратную сторону — по ссылкам между документами. Хороший устав ссылается на бизнес-кейс (обоснование), план — на устав (рамка), а статус-отчёты и запросы на изменение — на оба: любой change request в зрелом процессе проверяется дважды — против плана (влияет ли на расписание и бюджет) и против устава (не выходит ли за границы и не меняет ли цели). Изменение, задевающее устав, эскалируется спонсору; изменение в рамках устава — прерогатива PM и change-совещания.

PRINCE2 PID #

В методологии PRINCE2 роль устава играет Project Initiation Documentation (PID) — документация инициации проекта. По назначению это тот же акт: PID авторизует проект в рамках процесса Initiating a Project и служит основой для решения «go/no-go». По наполнению PID существенно шире — это не 1–3 страницы, а сборник из нескольких стратегий и описаний (подробнее — в готовящейся статье «PRINCE2», /docs/project-managment/prince2).

Что PID добавляет по сравнению с классическим уставом:

• Project Product Description — описание продукта проекта: критерии приемлемости, качество, контекст. В PMBOK этот уровень детализации живёт в плане управления содержанием, здесь — уже на старте.
• Communication Management Strategy — стратегия коммуникаций: кто, кого, чем и когда информирует. Разворачивает первичный список стейкхолдеров устава в полноценную схему информирования — по сути встраивает план коммуникаций прямо в инициационный пакет.
• Quality Management Strategy — подход к качеству: стандарты, метрики, процедуры контроля и приемки.
• Risk Management Strategy — как проект управляет рисками: процедуры, роли, шкалы, допущенный аппетит к риску; фундамент для последующего управления рисками.
• Проектные процедуры (strategies for controlling): управление изменениями, конфигурацией, эскалацией — то, что PMBOK относит к планам подчинённых процессов.

Практическое различие: устав PMBOK — короткий акт-мандат с рамкой, а детализация следует за ним в плане; PRINCE2 собирает значительную часть этой детализации в PID до старта исполнения. Отсюда и репутация PRINCE2 как более «тяжёлой» методологии: порог входа документации выше, зато к началу работ зафиксировано больше соглашений. Для малых проектов PRINCE2 официально допускает lightweight-варианты, вплоть до одностраничного PID.

Выбор между подходами — не вопрос «правильности», а вопрос цены соглашений: чем дороже проекту ошибка несогласованности (регуляторика, внешние контракты, много подрядчиков), тем больше смысла в подробной инициации по образцу PID; чем быстрее нужно стартовать, тем уместнее короткий устав с достройкой по ходу.

Устав в Agile #

В Scrum формального устава нет: фреймворк описывает роли, события и артефакты, но не акт авторизации проекта — предполагается, что решение о запуске принято где-то за пределами Scrum. Роль устава в Agile-среде распределяется между другими артефактами:

• Product Vision — видение продукта берёт на себя функцию «куда идём и зачем»: целевой клиент, проблема, ценность. Это ближайший аналог целевого блока устава, но язык другой — не критерии приёмки проекта, а образ будущего продукта.
• Sprint Goal — цель спринта выполняет функцию микро-авторизации: команда на планировании договаривается, зачем спринт, и эта рамка легитимирует решения внутри итерации. Устав авторизует проект разово; Sprint Goal — каждую итерацию заново.
• Product Goal (добавлен в Scrum Guide 2020) — долгосрочная цель для Product Backlog, ещё один уровень «зачем» между видением и целью спринта.
• Definition of Done отчасти покрывает функцию критериев успеха — но на уровне инкремента, а не проекта.

В масштабируемых фреймворках формальность возвращается: SAFe требует Lean Business Case для каждой инициативы (облегчённый бизнес-кейс, живущий в lean-портфеле) и Vision на уровне программы; авторизация происходит решением LPM (Lean Portfolio Management), функционально — тем же актом спонсора.

Практика выработала и прямой облегчённый вариант — lightweight charter, одну страницу, часто заполненную на фасилитационной сессии команды: цель, критерии успеха, границы, правила совместной работы. Такие сессии (project kickoff / chartering workshop) ценны не документом, а самим разговором: команда, совместно сформулировавшая цели и границы, держится их лучше, чем команда, получившая устав по почте. Даже там, где бюрократия не требует устава, час сессии «зачем мы это делаем и как поймём, что готово» окупается: без явных критериев успеха Agile-проект тоже не знает, когда он завершён.

Когда даже в Agile-среде полноценный устав оправдан:

• бюджет выделяется под проект, а не под продукт: финансы организации требуют акт авторизации с суммой и владельцем;
• внешние контракты и подрядчики: договорные обязательства и ответственность перед третьими лицами не покрываются Product Goal;
• регуляторные требования: аудируемые отрасли (финансы, медицина, энергетика) требуют формального следа авторизации независимо от методологии разработки;
• несколько команд и общая рамка: программа из нескольких Scrum-команд нуждается в общей границе и критериях успеха, которые не сводятся к видению одного продукта.

Типичное разрешение конфликта «гибкость против формальности» — гибрид: короткий устав на уровне программы или проекта (цели, бюджет, границы, спонсор) при полностью agile-механиках внутри (vision, sprint goal, бэклог). Форма авторизации не диктует процесс работы.

Типичные ошибки #

• Устав «для галочки». Документ утверждён, положен в папку — и больше не открывается; решения принимаются вопреки ему, изменения не проходят через спонсора. Устав работает только пока на него ссылаются: в статус-отчётах, при спорах о границах, при пересмотре целей. Если за полгода проекта устав не процитирован ни разу — его не было.
• Слишком детальный устав. Автор соблазняется и втискивает в документ WBS, календарный план, постатейный бюджет. Устав превращается в плохую копию плана: детализация мгновенно устаревает, а изменение каждой строчки формально требует визы спонсора. Следствие — документ либо забрасывают, либо спонсор становится бутылочным горлышком. Правило: устав в 5–10 раз короче плана; всё, что можно отложить до планирования, откладывается.
• Отсутствие критериев успеха. Цели записаны лозунгами («повысить удовлетворённость клиентов»), проверить их нельзя. Проект не знает, когда он завершён: закрывается «по усталости», по бюджету или по чьей-то воле. Без измеримых критериев невозможен и честный разбор завершённого проекта — оценивать не по чему.
• Нет подписи спонсора. Устав «согласован на словах» или подписан менеджером без полномочий делегировать ресурсы. Авторизации не произошло: PM по-прежнему выпрашивает людей и бюджет, стейкхолдеры не считают себя связанными рамкой. Подпись — не формальность, а сам смысл документа.
• Границы проекта описаны только «что входит». Половина границы — исключения. Без явного «не входит» каждая просьба заказчика легитимно расширяет содержание; проект живёт в режиме перманентного scope creep, а команда — в режиме перманентного овертайма.
• Устав не обновляется при смене реальности. Бизнес-условия изменились радикально, а проект продолжает идти к целям, в которые уже никто не верит. Устав, который нельзя изменить, — не рамка, а оковы: пересмотр устава спонсором — нормальный механизм, альтернатива которому только тихая деградация проекта.

Чек-лист качества устава #

Быстрая самопроверка перед утверждением — по одному вопросу на типовую ошибку:

• Цели сформулированы SMART — у каждой есть метрика, базовое и целевое значение, срок?
• Полномочия PM конкретны — суммы, права, границы эскалации?
• Границы содержат явные исключения — «не входит» не пустое?
• Подпись спонсора реальна — подписывающий вправе выделить ресурсы?
• Объём 1–3 страницы — ничего из содержания не является планом?
• Вех проверяемы — спонсор поймёт их без пояснений PM?
• Допущения перечислены явно — ни одного «само собой разумеется»?
• Документ кто-то, кроме автора, уже прочитал и понял рамку?

Связанные статьи #

• Введение в управление проектом — место устава в общей картине проектного управления.
• Треугольник проекта — ограничения, которые устав фиксирует на старте: содержание, сроки, стоимость.
• Управление рисками проекта — куда попадают допущения устава: из журнала допущений — в реестр рисков.
• Модель Митчелла-Агле-Вуда — как приоритизировать стейкхолдеров, первичный перечень которых даёт устав.
• План коммуникаций — разворачивание стейкхолдеров и ожиданий спонсора в регулярную схему информирования.
• Проект, программа, портфель — устав как механизм запуска элементов портфеля.
• Диаграмма Ганта — визуализация вех, зафиксированных в уставе.
• Видение продукта — артефакт, играющий роль устава в продуктовом контексте.

Первоисточники #

• Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide), 6th/7th ed. — процесс Develop Project Charter.
• AXELOS. Managing Successful Projects with PRINCE2 — Project Initiation Documentation (PID).
• Portny S. E. Project Management for Dummies — практические шаблоны устава.
• Verzuh E. The Fast Forward MBA in Project Management — структура устава и распределение полномочий.
• Project Management Institute. Business Cases for Projects: Practice Guide — связь бизнес-кейса и устава.