Устав проекта: как составить, что включить и кто утверждает

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

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

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

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

Устав проекта (Project Charter) — документ, который формально разрешает запуск проекта и закрепляет полномочия его руководителя использовать ресурсы организации. Он также описывает цели, ожидаемый результат, основные ограничения и условия успеха. Такое понимание назначения устава приведено в публикации Алекса Брауна в библиотеке PMI.

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

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

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

На практике он помогает решить четыре задачи:

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

Кто разрабатывает и утверждает устав

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

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

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

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

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

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

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

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

Раздел	Что указать
Общие сведения	Название, дату, версию документа, инициатора и подразделение
Обоснование	Проблему или возможность и ожидаемую пользу для бизнеса
Цель и критерии успеха	Целевые показатели, сроки их достижения и способ проверки
Результат и границы	Что будет передано заказчику, какие работы включены и исключены
Требования высокого уровня	Ключевые условия, которым должен соответствовать результат
Участники и полномочия	Спонсора, заказчика, руководителя, основные заинтересованные стороны и пределы решений руководителя
Этапы и сроки	Ключевые контрольные точки без подробного перечня задач
Бюджет и ресурсы	Предварительную оценку затрат, согласованный лимит и потребность в специалистах
Ограничения и допущения	Обязательные условия и предположения, на которых основаны оценки
Основные риски	События, способные помешать достижению цели, и первоначальные меры реагирования
Приемка и утверждение	Кто принимает результат, кто утверждает документ и как согласуются существенные изменения

Не смешивайте ограничения, допущения и риски. Лимит в 600 000 рублей — ограничение. Доступность администратора на восемь часов в неделю — допущение, пока загрузка не согласована. Его возможная занятость на аварийных работах — риск.

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

Как правильно составить устав проекта: пошаговый алгоритм

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

Шаг 1. Определить бизнес-цель

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

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

Шаг 2. Описать результат и границы

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

Шаг 3. Назначить участников

Четкое распределение ролей помогает избежать проблем с ответственностью.

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

Шаг 4. Оценить сроки, ресурсы и риски

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

Шаг 5. Согласовать критерии приемки

Для каждого основного результата определите способ проверки: тестирование, отчет, демонстрацию или подтверждение заказчика. Формулировку «сотрудники прошли обучение» уточните: сколько пользователей должны обучиться и чем подтверждается готовность к работе.

Шаг 6. Получить утверждение

После согласования всех разделов документ передается ответственным лицам.

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

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

Ниже приведен учебный пример внедрения системы управления задачами. Имена, суммы, даты и показатели вымышлены; это не описание кейса Bitcop.

Поле	Пример заполнения
Версия и дата	1.0 от 25 сентября 2026 года
Причина запуска	Задачи двух подразделений ведутся в таблицах и переписке. Нет общего реестра исполнителей и сроков; среднее время согласования задачи — два рабочих дня по данным внутреннего замера за сентябрь
Цель	До 31 декабря 2026 года перевести два подразделения, всего 40 пользователей, на единую систему и сократить среднее время согласования задач до одного рабочего дня
Ожидаемый результат	Настроенная платформа, перенесенные открытые задачи, инструкция и обученные пользователи
Входит в объем	Выбор и настройка готового решения, перенос открытых задач двух подразделений, настройка прав доступа, пилот и обучение
Не входит в объем	Разработка собственной платформы, интеграция с бухгалтерской системой, перенос архива закрытых задач и подключение других подразделений
Основные требования	У каждой задачи есть исполнитель, срок и статус; руководители видят задачи своих подразделений; права доступа соответствуют согласованной матрице ролей
Спонсор и утверждающее лицо	Операционный директор Анна Смирнова
Заказчики	Руководители двух участвующих подразделений; согласуют требования и подтверждают готовность результата к приемке
Руководитель проекта	Иван Петров, менеджер проектного офиса
Полномочия руководителя	Распределяет задачи внутри выделенной команды и корректирует рабочий график в пределах утвержденных контрольных дат. Изменения общего бюджета, состава подразделений и конечного срока передает спонсору на утверждение
Бюджет	Лимит — 600 000 рублей: лицензии — 180 000, настройка и перенос — 220 000, внутренние трудозатраты — 100 000, обучение — 40 000, резерв — 60 000. Использование резерва согласует спонсор
Ресурсы и ограничения	Работы выполняются без остановки текущих процессов. Требуется участие системного администратора до восьми часов в неделю и представителей подразделений до четырех часов в неделю от каждого подразделения
Допущения	Выбранное решение поддерживает импорт открытых задач; руководители подтвердят выделение сотрудников до 30 сентября
Риски и меры	Неполные данные при переносе — выполнить пробный импорт; низкая вовлеченность пользователей — провести пилот с представителями обоих подразделений; недоступность администратора — заранее согласовать резервного специалиста
Критерии приемки	Созданы 40 учетных записей; перенесены все открытые задачи из согласованного реестра; проверены права доступа; все 40 пользователей выполнили учебное задание; отсутствуют дефекты, блокирующие создание, назначение и завершение задач
Проверка бизнес-эффекта	Руководитель проекта сравнивает среднее время согласования за сентябрь и за первые три полные рабочие недели декабря по одной методике: от передачи задачи на согласование до решения. Цель — не более одного рабочего дня
Порядок завершения	Заказчики подтверждают выполнение критериев приемки. Спонсор до 31 декабря рассматривает отчет о приемке и достижении цели и принимает решение о закрытии либо корректирующих действиях

Контрольные точки:

Этап	Срок
Подтверждение ресурсов и исходных данных	До 30 сентября 2026 года
Выбор решения и согласование требований	До 15 октября
Настройка и пробный перенос	До 31 октября
Пилот и устранение замечаний	До 15 ноября
Обучение и запуск для 40 пользователей	До 30 ноября
Проверка показателей, приемка и решение о закрытии	До 31 декабря

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

Чем устав отличается от технического задания и плана проекта

Устав проекта и техническое задание часто воспринимают как похожие документы, но они решают разные задачи.

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

Документ	На какой вопрос отвечает	Что фиксирует
Устав	Зачем и на каких условиях запускается проект?	Цели, полномочия, границы, основные ресурсы и условия успеха
Техническое задание	Каким должен быть результат?	Требования к функциям, характеристикам и проверке результата
План проекта	Как команда организует выполнение работ?	Задачи, зависимости, исполнителей, сроки и порядок управления

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

Частые ошибки при подготовке

Чрезмерная детализация

Устав не должен превращаться в полноценный проектный план.

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

Размытые цели

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

Ответственность без полномочий

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

Непроверенные предположения

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

Создание документа только «для отчета»

Устав проекта должен использоваться в работе, а не просто храниться после подписания.

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

Краткий шаблон для заполнения

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

FAQ об уставе проекта