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

Место устава в процессах инициации

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

Дальше производится серия новых действий и принятие новых решений для того, чтобы запустить начало проектного мероприятия. Мероприятие в результате этих действий становится объектом управления. Иными словами, определяется менеджер проекта, и ему предлагается уникальная задача со всеми необходимыми параметрами. Можно спросить в этой ситуации: «Позвольте, но в бизнес-плане все это описано?!». Действительно, бизнес-план подробно прорабатывает всю логику, инфраструктуру и экономику задачи, ее перспективы и финансовое обоснование. Но менеджер в большинстве случаев не может отвечать за все результаты, сформированные в бизнес-плане. Его задача имеет более узкий контекст.

Основные выходы процесса инициации проекта

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

1. Ответственность менеджера ограничивается созданием нового продукта.
2. PM обеспечивает создание продукта и его производство.
3. Менеджер отвечает не только за создание и производство новой продукции, но и за его продажу в течение заданного периода времени.

Выписка из модели процессов инициации проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привожу пример устава проекта , который явился результатом бесплатного экспресс-обследования. Он отличается по форме от рекомендуемого 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 г. Переход в режим промышленной эксплуатации Консультационная поддержка Пользователей в режиме «горячей линии» Подведение итогов проекта, оценка достижения целей и задач проекта Принятие решения о развитии ИС
Документы по проекту, требующие согласования и утверждения
Приказ о запуске проекта	Готовит Начальник АСУ, утверждает – Генеральный директор компании
План проекта
Техническое задание	Составляет Консультант, Согласовывает – Руководитель проекта, Утверждают – Генеральный директор и Консультант
Технический проект	Составляет Консультант, Согласовывает – Руководитель проекта, Утверждают – Генеральный директор и Консультант
Итоговый отчет по проекту	Готовит Начальник АСУ, утверждает Руководитель проекта

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

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

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

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

1. Вы, как руководитель проектов, получили некое сообщение о том, что есть возможность выполнить проект. Это может быть RFP (запрос на предложение), которое вам передали из отдела продаж с просьбой помочь в подготовке коммерческого предложения, а может быть приглашение, пришедшее от вашего руководителя, с назначением на новый проект. В любом случае, вы знаете, что проект начинается.
2. Подготавливается контракт на проект. Вы, проработав примерный список работ и прикинув стоимость, совместно с руководителем заключаете контракт с Заказчиком.
3. Вы начинаете работу.

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

Первая и самая простая - устав является формальным объявлением начала проекта. Как вы сможете оценить, сколько длится проект, если вы не знаете, когда именно он начался? С даты подписания устава отсчитывается длительность проекта.
Вторая цель - закрепление полномочий за руководителем проекта. Проект может стартовать, но как вы будете руководить им, если у вас нет полномочий? Обычно, внутри компании, устав проекта подписывается значимым лицом (генеральным директором или его заместителем). Таким образом, получив устав проекта, менеджер проекта формально объявляет, что данный проект это не его личная прихоть, за ним стоит руководитель организации, который считает необходимым выполнить этот проект и для достижения этой цели предоставляет руководителю проекта определенные полномочия.
Третья цель устава проекта - зафиксировать первоначальные цели проекта. Ведь в процессе выполнения проекта, его цели могут меняться, в связи с чем, будут изменяться и сроки. В этом случае, руководитель проекта имеет возможность показать взаимосвязь между изменением целей и изменением сроков.
Четвертая цель устава проекта озвучить руководству в общих чертах риски, связанные с возникновением проекта и с работами на проекте. Когда запускается новый проект, возникают риски с ним связанные. Эти риски опасны не только для самого проекта, но могут быть опасны и для организации в целом. Соответственно, все начальные риски, которые вы идентифицировали, помещаются в устав проекта и озвучиваются руководству.

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

Успешных вам проектов!

В продолжение первой публикации “Как разработать корпоративную методологию управления проектами”- в данном материале мы рассмотрим основной документ выше упомянутой методологии – Положение «О корпоративной системе управления проектами» или Корпоративный стандарт по управлению проектами, а также шаблоны следующих рабочих документов проекта, рекомендованных 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. ЛИСТ СОГЛАСОВАНИЙ
ПРИЛОЖЕНИЯ

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

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

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

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

Давайте рассмотрим процесс «Разработка устава проекта» подробнее. На диаграмме ниже изображены входы, инструменты и методы и выходы этого процесса.

Входы процесса «Разработка устава проекта»

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

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

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

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

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

Факторы среды предприятия

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

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

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

Инструменты и методы процесса «Разработка устава проекта»

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

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

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

Выходы процесса «Разработка устава проекта»

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

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

Дмитрий Халдин,

руководитель департамента управления проектами PM Invest Group

Просмотры: 14 258