Содержание устава проекта

ДОКУМЕНТ, ОПРЕДЕЛЯЮЩИЙ СОДЕРЖАНИЕ ПРОЕКТА (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 CHARTER)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Содержание документа: Устав проекта непосредственно включает в себя следующие данные или ссылки на соответствующие документы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

контракт;

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

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

Компоненты хорошего устава

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

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

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

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

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

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

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

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

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

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

Удачной документации!

Newer news items:

• 12/12/2010 20:08 — Выгоды документирования
• 12/12/2010 20:06 — Написание проектного предложения
• 07/03/2010 22:57 — Написание отчёта о работе
• 07/08/2009 21:05 — Основные документы для управления проектами
• 07/08/2009 20:47 — Как снизить уровень документации по управлению проектом

Older news items:

08/07/2009 18:58 — Предложение о финансировании

Как в Worksection создать устав?

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

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

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

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

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

Состав и структура устава

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

Этот документ выполняет несколько функций, среди них важно отметить:

• функцию постановки задачи;
• функцию согласования;
• авторизационную функцию;
• функцию повышения дисциплины;
• консолидационную функцию;
• интеграционную функцию.

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

1. Обоснование выполнения уникальной задачи развития.
2. Цели, задачи и результаты.
3. Имя и фамилию PM, границы его ответственности и полномочия.
4. Определение и структуру продукта.
5. Интересы и ожидания участников.
6. Критерии успеха.
7. Принципы организации и управления проектом.

Типовая структура устава проекта

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

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

Форма устава проекта

Форма приложения к уставу проекта

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

Требования к структуре и содержанию разделов

Шаблон «Запрос на изменения в проекте» включает следующие разделы:

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

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

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

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

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

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

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

Как определить допущения проекта?

1. Включить голову. Правда, на самом деле нужно просто абстрагироваться. Особенно если вы делаете первый проект в этой компании или с этими стейкхолдерами. Просто подумайте на минуту, что ваши представления о том, что вокруг вас и в каких условиях этот проект будет делаться – это не истина в последней инстанции. Например, если на прошлом месте работы чтобы купить ноут новому участнику проекта достаточно было подписать служебную записку у начальника отдела, сходить за ноутом в магазин и потом оформить авансовый отчет, то в новой компании это может быть процесс длительностью 3-4 месяца. Подобные базовые представления желательно «прокрутить» в голове, понять, какие из них с большой вероятность могут быть ошибочны, уточнить и записать сюда. Ну например, если вы еще ни разу не имели яркого опыта закупки оборудования в новой компании, а только почитали внутренний документ об этом, говорящий, что любая закупка – это максимум 2 месяца, напишите «Закупка ноутбуков потребует не более 2х месяцев в соответствии с Процедурой Компании».
2. Посмотреть уставы ранее сделанных похожих проектов, поговорить с руководителями этих проектов (если это возможно). Заодно и список потенциальных рисков пополните.
3. Подумать, влиять на какие параметры проекта вам важнее всего (в разумных пределах, понятное дело). Если вы знаете, что проект очень-очень-очень срочный и на словах вам Заказчик говорил, что все его люди будут всячески вам помогать 24 часа в сутки – самое время это тут записать в форме «такие-то сотрудники могут привлекаться на проект до 100% рабочего времени по решению руководителя проекта без дополнительного согласования со стороны Заказчика».
4. Вспомнить все обещания, которые вам давали Спонсор и Заказчик, а также остальные стейкхолдеры. Обещали, что, т.к. проект срочный, вы сможете купить нужное ПО без тендерной процедуры, чтобы не затягивать? Пишите «Покупка ПО возможна без применения тендерной процедуры (исключение из процедуры будет организовано Заказчиком проекта Петровым П.П.)»!

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

Описание работ проекта

Описание работ (statement of work, SOW) проекта — это словесное описание продуктов, услуг или результатов, которые должен произвести проект. Для внутренних проектов инициатор или спонсор проекта предоставляет описание работ на основании бизнес-потребностей, требований к продукту или услуге. Для внешних проектов описание работ может быть получено от заказчика как часть документации по предложениям (например, запроса предложения, запроса информации, запроса заявок) или как часть договора. SOW отражает:

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

Бизнес-кейс

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

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

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

Соглашения

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