Устав проекта пример ремонт квартиры. Что такое устав проекта. Примеры устава проекта

В продолжение первой публикации “Как разработать корпоративную методологию управления проектами”- в данном материале мы рассмотрим основной документ выше упомянутой методологии – Положение «О корпоративной системе управления проектами» или Корпоративный стандарт по управлению проектами, а также шаблоны следующих рабочих документов проекта, рекомендованных PMI к разработке при управлении проектом:

Устав проекта (project charter);
Документ, определяющий содержание проекта (project scope statement (preliminary and detailed);
План управления проектом (project management plan).

КОРПОРАТИВНЫЙ СТАНДАРТ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ

Мы предлагаем рассматривать Положение о КСУП или корпоративный стандарт по управлению проектами (далее – корпоративный стандарт) как документ верхнего уровня в структуре внутренней нормативной документации, регламентирующей управление проектами в компании.

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

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

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

Подходы, описанные во втором и третьем случае, по нашему мнению, имеют определенные недостатки.

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

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

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

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

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

В корпоративный стандарт целесообразно включать следующие разделы:

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

УСТАВ ПРОЕКТА (PROJECT CHARTER)

Устав проекта (рroject charter) – один из самых «мифологизированных» рабочих документов проекта. Краткость описания этого документа в основном стандарте PMI – PMBOK в редакциях 2000 и 1996 года, с лихвой окупается богатством интерпретаций предназначения и содержания данного документа как российскими, так и зарубежными экспертами в области управления проектами.

Если обобщить существующие в проектной практике точки зрения, то получится, что под Уставом проекта разные специалисты, в т.ч. ориентирующиеся на PMBOK, понимают:

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

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

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

Предназначение документа: Устав проекта предназначен для определения проекта. На фазе инициализации, он включает в себя:

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

Когда разрабатывается документ: после заключения контракта (если заключается контракт с внешним контрагентом)

Кто разрабатывает документ: Устав проекта могут разрабатывать:

инициатор проекта;
спонсор проекта;

Кто утверждает документ: Устав проекта может утверждать:

инициатор проекта;
спонсор проекта;
представитель внешней стороны, связанной с проектом.

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

контракт;

Бизнес-потребности или требования к продукту, который будет создан в рамках проекта;
Цель проекта или основание для разработки проекта (justification);
Потребности и ожидания заинтересованных лиц (stakeholders);
Укрупненное расписание контрольных событий;
Влияние заинтересованных лиц на проект;
Распределение функций (functional organizations);
Предположения, связанные с внешним окружением и внутренней организационной средой;
Ограничения, связанные с внешним окружением и внутренней организационной средой;
Бизнес-обоснование проекта, включающее возврат на инвестиции (ROI);
Укрупненный бюджет.

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

ДОКУМЕНТ, ОПРЕДЕЛЯЮЩИЙ СОДЕРЖАНИЕ ПРОЕКТА (PROJECT SCOPE STATEMENT (preliminary and detailed)

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

Предназначение документа: PROJECT SCOPE STATEMENT (preliminary или предварительный) необходим для высокоуровневого определения проекта (что должно быть сделано) и включает в себя:

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

Когда разрабатывается документ: После утверждения Устава проекта.

Кто разрабатывает документ: PROJECT SCOPE STATEMENT (preliminary) могут разрабатывать:

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

Кто утверждает документ: PROJECT SCOPE STATEMENT (preliminary) может утверждать:

спонсор проекта;
представитель внешней стороны, связанной с проектом.

Входы (исходные данные) для разработки документа:

Устав проекта;
документ определения работ (Statement of work);
факторы внешнего окружения и организационной среды;
организационные активы (Organizational process assets).

Цели проекта и цели предметной области проекта;
Требования и характеристики продукта или услуги;
Рамки проекта;
Проектные решения (deliverables);
Критерии приемки продукта;
Проектные ограничения;
Проектные предположения;
Организация проекта на начальной стадии;
Идентификация рисков на начальной стадии;
Расписание контрольных событий;
Предварительный расчет стоимости (Order of magnitude cost estimate);
Требования к управлению конфигурацией проекта;
Согласованные требования (Approval requirements).

Порядок изменений документа: Команда проекта осуществляет дальнейшую разработку PROJECT SCOPE STATEMENT (preliminary), на этапе определения содержания проекта прорабатывает данный документ более детально (статус PROJECT SCOPE STATEMENT изменяется с preliminary на detailed), а также осуществляет контроль изменений документа.

ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ (PROJECT MANAGEMENT PLAN)

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

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

Когда разрабатывается документ: План управления проекта разрабатывается после утверждения Устава проекта и PROJECT SCOPE STATEMENT (preliminary). Если последние два документа не разрабатываются, то после сбора или приобретения соответствующей информации.

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

Кто утверждает документ: План управления проектом может утверждать:

спонсор проекта;
представитель внешней стороны, связанной с проектом.

Входы (исходные данные) для разработки документа:

Устав проекта;
Project Scope Statement (preliminary);
Процессы управления проектом;
Прогнозы
Факторы внешнего окружения и организационной среды;
Организационные активы (Organizational process assets);
Информация о выполнении работ.

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

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

План управления содержанием;
План управления расписанием;
План управления стоимостью;
План управления качеством;
План улучшений;
План управления персоналом;
План управления коммуникациями;
План управления рисками;
План управления поставками.

Порядок изменений документа: Изменения Плана управления проекта проходят через процесс Интегрированного управления изменениями и могут быть связаны с модификациями, дополнениями и ревизиями проекта. При этом статус Плана меняется на обновленный (updated).

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

А.Ю.Сооляттэ, партнер ИП «Finexpert.ru», адрес электронной почты – [email protected] .

Приложение

ПРИМЕРЫ УСТАВОВ ПРОЕКТОВ КОМПАНИЙ

Пример 1. УСТАВ ПРОЕКТА (международная компания, занимающаяся производством компьтерной техники, разработкой программного обеспечения и проектами в сфере системного интеграции).

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

Данный документ – Устав проекта – уточняется/изменяется и утверждается заново на каждой из стадий: на стадии предложения, на стадии исполнения (после подписания контракта).

СОДЕРЖАНИЕ:
1. Обзор Устава проекта
2. Организация проекта
2.1. Менеджер Проекта по интегрированию систем
2.2. Привлеченная команда по системному интегрированию
2.3. Роли и обязанности
2.4. Полномочный орган по финансированию Проекта
2.5. Комитет спонсоров Проекта
2.6. Комитет директоров Проекта
3. Краткое изложение требований по системному интегрированию
3.1. Обзор системного интегрирования
3.2. Определение потребности в системном интегрировании
3.3. Содержание и цели системного интегрирования
3.4. Факторы и риски, влияющие на системное интегрирование
4. Краткие сведения по Проекту
4.1. Описание
4.2. Процессы Проекта
5. Деятельность по интегрированию системы и поставляемые позиции
5.1.1. Работы Этапа I
5.1.2. Поставляемые позиции Этапа I
5.1.3. Работы Этапа II
5.1.4. Поставляемые позиции Этапа II
5.1.5.Работы этапа III
5.1.6. Поставляемые позиции Этапа III
5.1.7. Работы Этапа IV
5.1.8. Поставляемые позиции Этапа IV
5.1.9. Работы Этапа V
5.1.10. Поставляемые позиции Этапа V
6. Графики хода процессов
7. Документация

Пример 2. УСТАВ ПРОЕКТА (международная компания, занимающаяся разработкой и внедрением информационных систем)

СОДЕРЖАНИЕ:
1 ВВЕДЕНИЕ
1.1 НАЗНАЧЕНИЕ ДАННОГО ДОКУМЕНТА
1.2 ИЗМЕНЕНИЯ ДАННОГО ДОКУМЕНТА
2 ОПРЕДЕЛЕНИЕ ПРОЕКТА
2.1 НАЗНАЧЕНИЕ ПРОЕКТА
2.2 ЦЕЛИ ПРОЕКТА
2.3 НЕОБХОДИМЫЕ УСЛОВИЯ ДЛЯ ДОСТИЖЕНИЯ ПОСТАВЛЕННЫХ ЦЕЛЕЙ
3 РАМКИ ПРОЕКТА
3.1 ЛОГИЧЕСКИЕ РАМКИ ПРОЕКТА НА МОМЕНТ ЕГО НАЧАЛА
3.2 ВРЕМЕННЫЕ РАМКИ ПРОЕКТА
4 ОРГАНИЗАЦИЯ И УПРАВЛЕНИЕ ПРОЕКТОМ
4.1 ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2 РАСПРЕДЕЛЕНИЕ РОЛЕЙ УЧАСТНИКОВ ПРОЕКТА
4.2.1 Спонсор Проекта
4.2.2 Управляющий Совет
4.2.3 Председатель Управляющего Совета
4.2.4 Руководители Проекта
4.2.5 Группа внедрения
4.2.6 Состав группы внедрения
4.3 ДОКУМЕНТООБОРОТ ПРОЕКТА
4.3.1 Общие документы
4.3.2 Отчетные документы
4.3.3 Рабочие документы
4.3.4 Периодичность подготовки отчетной документации
4.4 ПРОЦЕДУРА РЕШЕНИЯ ПРОБЛЕМ
4.5 ПОДХОД К УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ РАМОК ПРОЕКТА
5 ЗАВЕРШЕНИЕ ПРОЕКТА
ПРИЛОЖЕНИЕ 1 – ДЕКЛАРАЦИЯ ЦЕЛЕЙ ВНЕДРЕНИЯ ИИСУ НА ОАО «ХХХ»
ПРИЛОЖЕНИЕ 2 – СПИСОК ФУНКЦИЙ АВТОМАТИЗИРУЕМЫХ ПОДРАЗДЕЛЕНИЙ.
ПРИЛОЖЕНИЕ 3 – ФОРМА РЕГИСТРАЦИИ ПРОБЛЕМЫ
ПРИЛОЖЕНИЕ 4 – ЖУРНАЛ РЕГИСТРАЦИИ ПРОБЛЕМ
ПРИЛОЖЕНИЕ 5 – ИНДИВИДУАЛЬНЫЙ ОТЧЕТ О ПРОРАБОТАННОМ ВРЕМЕНИ
ПРИЛОЖЕНИЕ 6 – ОТЧЕТ РУКОВОДИТЕЛЯ ПРОЕКТА
ПРИЛОЖЕНИЕ 7 – РЕГУЛЯРНЫЙ ОТЧЕТ О СОСТОЯНИИ ПРОЕКТА
ПРИЛОЖЕНИЕ 8 – ОТЧЕТ О РЕЗУЛЬТАТАХ ЭТАПА.

Пример 3. УСТАВ ПРОЕКТА (Российская компания – системный интегратор)

СОДЕРЖАНИЕ
1. ПРОФИЛЬ КОМПАНИИ
1.1. СФЕРА ДЕЯТЕЛЬНОСТИ
1.2. АДРЕС КОМПАНИИ
1.3. КОНТАКТНЫЕ ЛИЦА
1.4. СОТРУДНИКИ
2. ЦЕЛИ И ОПРЕДЕЛЕНИЕ ПРОЕКТА
3. ПЛАН ПРОЕКТА
4. СТРУКТУРА ПРОЕКТА
4.1. ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2. КЛЮЧЕВЫЕ РОЛИ И ОТВЕТСТВЕННОСТЬ
4.3. ПРОЦЕДУРЫ ВСТРЕЧ И ПОДГОТОВКИ ОТЧЕТОВ О СОСТОЯНИИ ПРОЕКТА
5. РИСКИ ПРОЕКТА
6. ПЛАН ОБУЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
7. КОНТРОЛЬ ИЗМЕНЕНИЙ И ПРОЦЕДУРЫ ПРИЁМКИ РАБОТ
7.1. УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
7.2. ПРОЦЕДУРЫ ТЕСТИРОВАНИЯ И ПРИЕМКИ РАБОТ
7.3. СТАТУС И СОСТАВ ПРИЕМОЧНОЙ КОМИССИИ
7.4. ПЕРЕДАЧА В ОПЫТНУЮ ЭКСПЛУАТАЦИЮ
8. ЛИСТ СОГЛАСОВАНИЙ
ПРИЛОЖЕНИЯ

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

Разработка устава проекта – это процесс разработки устава проекта.

В стандарте PMBOK 5 – разработка устава проекта относится к области знаний .

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

Обоснование проекта
Измеримые цели проекта и критерии их успеха. Подробнее про критерии успеха можно прочитать в статье Постановка целей по модели SMART .
Первичные требования. Часто эти требования называют высокоуровневыми.
Ограничения и допущения.
Описание проекта и его границы
Упоминания об основных рисках проекта
Бюджет проекта
Информацию о .
Информация о
Информация о
Информация о

В самом просто виде устав может выглядеть как-то так:

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

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

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

Бизнес-вопросы.

Каковы реальные потребности бизнеса? Какие выгоды бизнес хочет получить от внедрения этого продукта?
Список работ и услуг, которые должны быть созданы во время проекта? Например, вы запускаете сайт. Значит, вам необходимо составить список того, что этот сайт должен точно содержать, например возможность просматривать видео, возможно легко добавлять в него новые статьи и новости. Информацию по этому описание вы можете получить из бизнес-потребностей клиента, из стратегических планов компании.
Кукую экономическую выгоду планируется получить от запускаемого проекта? Эту информацию можно получить: проведя исследование потребностей рынка, получив информацию об аналогичных решениях в вашей сфере, проанализировав социальные потребности ваших клиентов, проанализировав технические преимущества вашего решения.
Каковы ожидания заказчика от вашего проекта?

Технологические вопросы.

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

Структурные вопросы (эти вопросы учитывают возможные влияния законов и культуры компании на проект).

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

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

Вопросы прошлого опыта (эти вопросы помогут вам использовать прошлый опыт ваш и ваших коллег для ускорения работ по проекту)

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

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

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

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

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

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

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

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

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

Привожу пример устава проекта , который явился результатом бесплатного экспресс-обследования. Он отличается по форме от рекомендуемого 1С. Но, для понимания того, что именно должно быть указано в этом документе – вполне достаточно. Как и для того, чтобы понять, стоит ли начинать такой проект.

Устав проекта «Создание и внедрение системы 1С:Предприятие 8 в ХХХ»

1. Обоснование целесообразности проведения проекта	На предприятии используются несколько автоматизированных систем управления: Навигационная система движения автотранспорта (АСУТП) Система оперативного учета и обработки путевых листов в DOS; Система расчета заработной платы ХХХ Система учета ХХХ Система учета расчетов с поставщиками, бюджетом, учёта банковских и кассовых операций ХХХ Система сдачи налоговой отчетности «Контур-Экстерн» В отдельных файлах Excel производится: Расчёт себестоимости по видам перевозок и статьям затрат; Учёт расчетов с заказчиками; Ведение операционного бюджета движения денежных средств ; Регистры бухгалтерского учёта ; Бухгалтерская отчётность. Вручную ведётся множество операций, которые могут быть автоматизированы, например: Выдача доверенностей; Журналы регистрации кассовых и банковских документов ; Журналы регистрации счетов-фактур; Заполнение налоговых деклараций и регистров налогового учета Ведение книги покупок и книги продаж Составление различных планов осуществляется в смешанном режиме. Необходимо отметить, что удалённость разработчика систем ПП ХХХ затрудняет поддержку системы и в итоге делает невозможным получение из неё необходимой информации. Данная ситуация приводит к несопоставимости данных в системах из-за влияния следующих факторов: Различные требования пользователей систем; Отличия в методологическом основании систем; Несовпадение нормативно-справочного наполнения систем; Ошибки при вводе данных и при составлении отчетности (человеческий фактор) Это приводит к постоянной неопределенности при принятии управленческих решений менеджерами всех уровней. Таким образом, назрела необходимость создания единого информационного пространства.
2. Цель(и) проекта	Стратегическая: повышение определенности при принятии управленческих решений через создание единого информационного пространства планирования и учёта финансово-хозяйственной деятельности .
	Оперативные: Повышение прозрачности и достоверности данных Повышение скорости получения запрашиваемой информации Уменьшение трудоемкости учётных работ и увеличение аналитических функций пользователей Повышение технической надежности системы Построить систему с чистого листа, избегая известных существующих ошибок Получить экспертную оценку системы учёта и управления от Консультантов
3. Ожидаемые результаты проекта	Получение отчетности «по нажатию одной кнопки»: Оперативной По сравнению плана и факта Финансовой и налоговой отчетности Повышение квалификации пользователей;
4. Продукт проекта	Информационная система 1С, работающая в соответствии с поставленными задачами
5. Структура продукта проекта	Методологическое обеспечение (методологии планирования и учёта; нормативно-справочная информация) Техническое обеспечение (сервер, сети, места пользователей) Программное обеспечение (система 1С, интегрированная с АСУТП и прочим внешним ПО) Обученный персонал (пользователи, администратор, служба поддержки) Документационное обеспечение ИС (техническая документация на изменения, инструкции пользователей)
6. Заинтересованные в развитии проекта стороны	Генеральный директор Менеджеры различных уровней Начальник отдела АСУ Заказчики проекта (Главный бухгалтер, Главный экономист) Члены команды проекта со стороны предприятия Консультанты () Пользователи ИС Также в качестве заинтересованных сторон могут рассматриваться контрагенты предприятия и сотрудники.
7. Ожидания заинтересованных сторон	Генеральный директор: достижение целей проекта с минимальными затратами Менеджеры различных уровней: увеличение информированности при принятии управленческих решений Начальник отдела АСУ: снижение трудоемкости обслуживания ИС; повышение роли своей службы в системе управления; бонус за успешное выполнение проекта, опыт Заказчик проекта: снижение трудоемкости ведения учета; увеличение прозрачности учета; повышение профессионализма подчиненных. Члены команды проекта со стороны предприятия: бонус за успешное выполнение проекта, опыт, возможно, карьерный рост Консультанты: своевременная оплата работ, интересная работа, успешность проекта Пользователи ИС: повышение профессионализма, повышение рыночной стоимости
8. Риски проекта	Выход из бюджета проекта Недостаток финансовых ресурсов Ошибки в планировании работ по проекту Отсутствие необходимых технических возможностей в требуемый момент Недостаток квалификации пользователей Противодействие системы управления Страхи и опасения пользователей и команды проекта Саботаж пользователей при внедрении Потеря ожидаемого функционала информационной системы Изменение законодательства Изменения в составе команды проекта Ошибки в организации работы по проекту Низкая скорость принятия решений по проекту (затягивание процедуры согласования) Недостаточная компетентность членов команды проекта Не кому проводить аналитическую работу по документации проекта Узость интересов членов команды Самоустранение руководства от участия в проекте
Ограничения проекта
1. Время исполнения проекта	До 1 года – первый этап проекта (автоматизация бухгалтерского и оперативного учёта).До 1 года – постановка и автоматизация бюджетного управления и BSC
2. Затраты по проекту	Не более 3,5 млн. руб. на оплату услуг Консультантов в первый год и 4 млн. руб. – во второй год
3. Организационные	Работы по проекту осуществляются в тесном контакте и под руководством Консультанта (компании – внедренца); Внедрение всех контуров учёта осуществляется единовременно, что требует серьёзной подготовительной работы и работы с персоналом (пользователей); Поддержка пользователей после окончания работ по проекту должна обеспечиваться силами сотрудников службы АСУ
4. Время команды проекта		До 06.10.20ХХ г. Проведение Консультантом анализа методологии и принципов организации учета на предприятии. Составление технического задания на проектирование ИС 1С. Выбор базовой конфигурации. Описание рисков проекта и мероприятий по их снижению. Разработка плана проекта.
3. Проектирование	До 25.11.20XX г. Разработка Консультантом технического проекта на основании согласованного технического задания
4. Реализация проекта	До 22.01.20XX+1 г. Создание Консультантом информационной системы согласно технического проекта. Закупка программного обеспечения Модернизация аппаратно-технического обеспечения и сетевой инфраструктуры в соответствии с техническими рекомендациями Технического задания. Подготовка нормативно-справочной информации Подготовка данных по остаткам активов и пассивов
5. Опытно-промышленная эксплуатация	До 07.05.20XX+1 г. Обучение администрированию базы данных Ввод в ИС начальных остатков (по всем участкам учета) по состоянию на 01.01.20XX+1. Ввод первичных документов Пользователями с одновременным обучением и под контролем Консультантов по всем участкам учёта Работа Пользователей при дистанционной поддержке Консультантов Доработка ИС по результатам опытно-промышленной эксплуатации Разработка и оформление индивидуальных инструкций по наиболее сложным процессам учета и эксплуатации ИС
6. Завершение проекта	До 04.06.20XX+1 г. Переход в режим промышленной эксплуатации Консультационная поддержка Пользователей в режиме «горячей линии» Подведение итогов проекта, оценка достижения целей и задач проекта Принятие решения о развитии ИС
Документы по проекту, требующие согласования и утверждения
Приказ о запуске проекта	Готовит Начальник АСУ, утверждает – Генеральный директор компании
План проекта
Техническое задание	Составляет Консультант, Согласовывает – Руководитель проекта, Утверждают – Генеральный директор и Консультант
Технический проект	Составляет Консультант, Согласовывает – Руководитель проекта, Утверждают – Генеральный директор и Консультант
Итоговый отчет по проекту	Готовит Начальник АСУ, утверждает Руководитель проекта

Ресурсы проекта

Отчетность по проекту

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расширенный материал по формированию системы целей с иллюстрациями приведен в статье ?

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

Мадорская Ю.М. Разработка устава проекта. Методическое пособие. //Практика проектирования систем.-2017.. - Загл. с экрана

Литература

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

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

В трех предыдущих статьях серии «Что нужно сделать до старта проекта» я рассказал, что перед стартом необходимо:

Сформулировать бизнес-проблемы, цели проекта и ожидаемые результаты .

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

Документ, с которого проект стартует, называют Уставом проекта (или Паспортом проекта).

Устав проекта - это документ, с которого начинается проект и по которому происходит оценка его успешности.

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

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

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

В популярном подходе к управлению проектами - PMBOK - в состав «Устава проекта» входят следующие разделы:

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

На своих проектах я часто использовал шаблон Устава, структура которого немного отличалась, от предложенной в PMBOK, но содержала все разделы, кроме списка заинтересованных сторон, описания сферы ответственности и уровня полномочий руководителя проекта (пример - ниже). Как правило, компания, которая идет по пути стандартизации проектной деятельности, разрабатывает шаблон Устава под специфику своей деятельности и этот шаблон используется для старта всех проектов.

Кто разрабатывает Устав проекта?

Разработчики PMBOK считают, что в разработке документа должны участвовать спонсор, заказчик и руководитель проекта.

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

Значение Устава для руководителя проекта

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

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

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

При закрытии проекта именно Устав позволяет заказчику и руководителю подвести итоги проекта и определить степень его успешности.

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

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

Для понимания структуры документа приведу пример Устава внедрения CRM-системы.

УСТАВ ПРОЕКТА
Автоматизация процессов CRM. Версия 1.0

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

Выводы

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

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

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

Максим Якубович

Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».

Опыт работы в сфере управления проектами - более 10 лет.

20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.

Опыт преподавания - 10 лет. Около 2200 студентов, прошедших обучение на его семинарах.

Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.
Ведущий

Документы