Устав проекта по PMBOK 8: образец и пример для ИТ-проекта
Заказчик говорит: «Нам нужно приложение, ну вы поняли, сделайте красиво. Денег дадим, потом разберёмся». Вы киваете, команда начинает кодить. Через два месяца выясняется, что заказчик хотел одно, команда делала другое, бюджет никто не утверждал, а сроки уже горят.
Знакомая боль? Я её проходил не раз.
Всё потому, что не было устава проекта — документа, который фиксирует правила игры с самого начала. Без устава вы не руководитель проекта, а просто энтузиаст, который что-то делает на общественных началах. И в любой момент спонсор может сказать: «А кто вас вообще просил?» — и снять ресурсы.
В этой статье я разберу на реальном примере, как составить устав по PMBOK 8, покажу готовый шаблон (копируйте и вставляйте) и объясню, как устав защищает вас от главной беды ИТ-проектов — расползания содержания. А также отвечу на вопросы: чем отличается устав от технического задания, можно ли начать проект без устава и какова цель устава проекта согласно PMBOK.
Что такое устав проекта (простым языком)
Устав проекта (project charter) — это документ, который даёт вам легальное право управлять проектом.
Он отвечает на пять вопросов:
- Зачем мы делаем этот проект? (какую проблему решаем)
- Что именно делаем (и чего не делаем)?
- Кто за что отвечает?
- Сколько у нас времени и денег?
- Кто принимает ключевые решения?
Без устава вы не знаете, законно ли вы тратите ресурсы компании. С уставом — знаете. Без устава приёмка превращается в спор. С уставом — в проверку соответствия.
Важно не путать. Устав — это не техническое задание. ТЗ говорит «как должна работать система» (кнопка синяя, по нажатию отправляется запрос). Устав говорит «зачем мы это делаем, кто платит, кто принимает результат». ТЗ можно менять в процессе разработки. Устав — только через формальное согласование со спонсором.
Зачем нужен устав даже если вы работаете по Agile
«Мы по Scrum работаем, нам не нужны бумажки» — слышу это постоянно. Это заблуждение.
Даже в чистом Agile есть понятие «цель продукта», «бюджет на разработку», «ожидаемый срок выхода релиза». И эти вещи нужно фиксировать. Не в виде 50-страничного документа, а в виде одностраничного устава.
Устав не запрещает гибкость. Он задаёт границы. Внутри этих границ вы можете менять приоритеты бэклога, уточнять требования, перепланировать спринты. Но как только возникает предложение выйти за границы (добавить новый модуль, увеличить бюджет, сдвинуть релиз), вы смотрите в устав и запускаете процедуру изменений.
Образец устава для ИТ-проекта (готовый шаблон)
Возьмём реальный кейс. Компания «ТехноЛогистик» внедряет модуль «Командировки и авансовые отчёты». Ниже — как выглядит устав этого проекта.
Название и описание проекта
Название: Внедрение модуля «Командировки и авансовые отчёты» в компании «ТехноЛогистик»
Описание: Автоматизация процессов оформления командировок, утверждения авансовых отчётов и интеграция с 1С:Бухгалтерия.
Бизнес-обоснование: текущий бумажный процесс занимает в среднем 3 дня на одну командировку, содержит до 15% ошибок в авансовых отчётах, что приводит к задержкам выплат.
Цели проекта (измеримые)
Цели должны быть SMART: конкретные, измеримые, достижимые, релевантные, ограниченные по времени.
Цель | Критерий успеха | Срок |
Сократить время оформления командировки | с 3 дней до 4 часов | через 1 месяц |
Снизить количество ошибок в авансовых отчётах | на 80% | через 2 месяца |
Обеспечить выгрузку в 1С | не позднее 2 минут | на старте ОПЭ |
Границы проекта
Входит: автоматизация заявок, маршруты согласования, электронная форма авансового отчёта с чеками, интеграция с 1С, обучение 50 пользователей.
Не входит: мобильное приложение, интеграция с CRM, другие виды отчётов (только авансовые).
Бюджет
3 000 000 рублей + резерв на риски 10% (300 000 рублей)
Сроки
Старт 01.03.2026 → опытная эксплуатация 20.05.2026 → закрытие 10.07.2026
Ключевые участники и роли
- Спонсор — финансовый директор (Петров А.А.). Утверждает бюджет, снимает блокеры.
- Руководитель проекта (заказчик) — начальник отдела командировок (Сидорова Е.В.). Предоставляет требования, принимает результат.
- Руководитель проекта (исполнитель) — менеджер внедрения (Иванова М.С.). Управляет командой, отчитывается.
- Технический архитектор — главный разработчик (Смирнов Д.А.). Отвечает за интеграцию с 1С.
Допущения
- Ключевые сотрудники заказчика уделяют проекту не менее 8 часов в неделю.
- API 1С остаётся стабильным.
- ИТ-инфраструктура работает штатно.
Основные риски
Риск | Вероятность | Влияние | Что делаем |
Сопротивление пользователей | 60% | высокое | обучение, вовлечение лидеров мнения |
Задержка согласований | 40% | среднее | еженедельный контроль, эскалация |
Изменение API 1С | 15% | высокое | резерв времени 2 недели |
Порядок утверждения изменений
Изменения, увеличивающие бюджет >10% или срок >2 недель, утверждаются управляющим комитетом (спонсор + финансовый директор + ИТ-директор). Остальное решает руководитель проекта.
Как составить устав за 6 шагов
- Соберите входные данные — договор, коммерческое предложение, бизнес-кейс.
- Проведите встречу со спонсором и заказчиком — за час пройдите по пяти вопросам.
- Заполните шаблон — не больше двух страниц.
- Отправьте на согласование — спонсор, заказчик, технический лидер.
- Утвердите устав — подписи спонсора и заказчика. Без подписей не начинайте работы.
- Опубликуйте в общем доступе — команда и стейкхолдеры должны знать.
Типичные ошибки в уставе
Скачать готовый шаблон устава в Google Docs → ссылка
Ошибка | Последствие | Как избежать |
Цели не измеримы («улучшить качество») | непонятно, достигли цели или нет | формулируйте по SMART |
Нет раздела «Что не входит» | заказчик требует доработки как «очевидные» | явно перечисляйте исключения |
Устав пишет один руководитель | спонсор не разделяет ответственность | создавайте устав на встрече |
Допущения не перечислены | ключевое предположение оказывается неверным | фиксируйте все допущения |
Устав не утверждён до старта | ресурсы могут снять в любой момент | не начинайте без подписанного устава |
Часто спрашивают
Какова цель устава проекта согласно PMBOK?
Устав формально санкционирует проект и даёт руководителю проекта полномочия использовать ресурсы организации для достижения целей проекта.
Можно ли начать проект без устава?
Технически — да. Но спонсор может в любой момент снять ресурсы и сказать «я не утверждал». Даже одностраничный устав лучше, чем ничего.
Чем устав отличается от технического задания?
ТЗ говорит «как должна работать система». Устав говорит «зачем мы это делаем, кто платит, кто принимает результат». ТЗ можно менять часто, устав — только через формальное согласование.
Нужен ли устав, если проект маленький (на 2 недели)?
Да, но в упрощённом виде. Название, цель (одна строка), бюджет (диапазон), сроки (дата начала и конца), подписи. Одной страницы достаточно.
PmBok устав проекта — где взять пример?
В этой статье есть готовый образец. Копируйте структуру, подставляйте свои данные.
Чем устав отличается от плана управления проектом?
Устав — это документ уровня «зачем мы это делаем, кто платит, кто принимает решения». План управления проектом — детальный документ уровня «как мы это делаем, по какому расписанию, с каким бюджетом, с какими рисками». Устав создаётся на инициации, план — на планировании. Устав меняется редко, план — регулярно.
📌 На воркшопах мы тренируем заполнение устава на вашем реальном проекте. Вы приносите свой кейс — мы вместе находим слабые места и правим их. Записаться →