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

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

Устав проекта определяет каркас проекта в 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

Литература

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

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

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

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

· стратегические и тактические цели организации-заказчика;

· формулировка требований организации-заказчика;

· контракт;

· внутрикорпоративная методология управления проектами и соответствующие политики.

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

В табл. 1.5 приведены требования к уставу проекта - перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению.

Рис. 1.2. Модель комплексного анализа участников и окружения проекта. На рисунке ИКС - исследовательская команда спонсора

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

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

· все разделы предложенного формата устава проекта заполнены в соответствии с рекомендациями;

· в самом документе отсутствуют противоречия;

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

Разработка Устава проекта – это процесс разработки документа, который формально

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

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

устанавливает партнерство между исполняющей организацией и организацией,

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

проекта формально инициирует проект. Менеджер проекта определяется или

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

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

чтобы менеджер проекта участвовал в разработке Устава проекта, так как данный

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

выполнения проекта.

Санкционирование проектов производится внешним по отношению к проекту

лицом или лицами, такими как спонсор, офис управления проектами (Project

Management Office, PMO) или комитет по управлению портфелями. Уровень

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

проекта. Они либо сами разрабатывают Устав проекта, либо делегируют эту

обязанность менеджеру проекта. Подпись инициатора на Уставе санкционирует

проект. Санкционирование проектов обуславливается внутренними бизнес-

потребностями или влиянием извне. Обычно это приводит к подготовке анализа

потребностей, экономического обоснования или описания ситуации, которую будет

решать проект. Написание Устава проекта связывает проект со стратегией и текущей

деятельностью организации.

На рис. 4-2 показаны входы, инструменты и методы, а также выходы для данного

процесса, а на рис. 4-3 представлена блок-схема данных.

Рис. 4-2. Разработка Устава проекта: входы, инструменты, методы и выходы

Рис. 4-3. Блок-схема данных при разработке Устава проекта

4.1.1 Разработка Устава проекта: входы

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

Описание работ (Statement of work, SOW) – это словесное описание продуктов или

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

Перечень работ отражает:

Бизнес-потребность.

Описание содержания продукта.

Стратегический план.

2 Экономическое обоснование

Экономическое обоснование или подобный документ предоставляет необходимую с

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

Экономическое обоснование создается как результат действия одного или нескольких из следующих факторов:

Требования

Потребность организации

Требования заказчика

Технологический

Правовые требования

Экологические

Социальные

3 Контракт

Контракт является входом, если проект выполняется для внешнего заказчика.

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

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

Устава проекта, включают в себя среди прочего:

Государственные и промышленные стандарты;

Инфраструктуру организации;

Ситуацию на рынке.

5 Активы процессов организации

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

разработки Устава проекта, включают в себя среди прочего:

Стандартные процессы организации, правила и описания типовых процессов для

использования в организации;

Шаблоны (например, шаблон Устава проекта);

Историческую информацию и базу усвоенных уроков.

4.1.2.Разработка Устава проекта: инструменты и методы

1 Экспертные оценки

Применяются в отношении любых технических и управленческих деталей. Такие

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

знаниями или подготовкой, и доступны из множества источников, включая следующие:

Другие подразделения в рамках организации;

Консультанты;

Заинтересованные стороны проекта, в том числе заказчики или спонсоры;

Профессиональные и технические ассоциации;

Отраслевые объединения;

Эксперты по отдельным вопросам;

Офис управления проектами (Project management office, PMO).

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

Устав проекта – документ, с которого начинается планирование проекта.

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

Устав проекта должен содержать следующую информацию:

Название проекта;

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

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

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

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

Рис. 2. Принципиальная схема участников проекта.

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

Участниками проекта считаются все лица и организации, включая команду проекта, чьи интересы могут быть затронуты исполнением или результатом проекта Участники могут влиять на цели и результаты проектакак положительно, так и оказывать отрицательное воздействие. Поэтому рекомендуется с особым вниманием подходить к задаче определения участников проекта и степени их влияния. Неполный список участников проекта не позволит правильно сформировать требования к результату проекта, к его содержанию, что повлечет ошибки в планировании проекта. Для составления списка участников проекта можно воспользоваться инструментом, известным как карточки Кроуфорда (Собирается команда из 7-10 человек, каждый получает 10 листочков. Ведущий задает вопрос «Кто является участником проекта?». Каждый из присутствующих пишет свой ответ на одном из листочков. Эта процедура повторяется 10 раз. Один и тот же ответ может использоваться одним человеком только один раз. В результате получается список участников, который затем корректируется.

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

Ключевые участники любого проекта: руководитель проекта, заказчик/пользователь, исполняющая организация,члены команды проекта,спонсор, источники влияния. В таблице 1 представлен пример возможных участников проекта внедрения ИС:

Таблица 1

Внешние участники проекта внедрения

Отношения между участниками проекта Участники проекта имеют различные уровни ответственности и полномочий в проекте. В таблице 2 представлены функциональные обязанности участников проекта. Менеджер проекта должен обеспечивать постоянный контакт команды проекта с ее участниками.

Таблица 2

Функциональные обязанности участников проекта

Условные обозначения :З - заказчик;РП -руководитель проекта;П - проектировщик;ГП – генеральный подрядчик;СП – субподрядчик;Б – банки;ОВ – органы власти;ПС – поставщик;В – владелец земли;Л – лицензоры;И - инженер;ИП – изготовители продукции;ПП – потребители продукции;* - должен осуществлять; Х - может осуществлять;

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

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

Сроки выполнения проекта включают даты начала и окончания проекта или продолжительность проекта

Контрольные события и ключевые даты. Контрольные события – это основные события проекта. Контрольное событие определяет значительное достижение в рамках проекта. Результаты проекта и контрольные события могут совпадать или иметь разные значения.

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

Примеры ограничений.

10% членов команды проекта должны иметь сертификат PMI.

Увеличение стоимости проекта не более чем на 10%

Примеры допущений.

Планируемую стоимость проекта. Первоначально, стоимость проекта определяется только на порядковом уровне. Ошибка в оценке стоимости колеблется (-20%)- (+100%) Стоимость проекта определяется контрактом между Заказчиком с Исполнителем. Исходя из стоимости проекта, в дальнейшем составляется бюджет расходов проекта с указанием статей расходов на внедрение ИС в разрезе месяца, квартала, полугодия, года.

Границы проекта. Определяются организационные, функциональные и географические границы проекта

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

Функциональные границы. Указываются бизнес - направления, бизнес-процессы, которые будут покрываться ИС. Данным пунктом определяется модули ERP-систем.

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

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

Устав официально закрепляет назначение руководителя проекта , сдержит имена спонсора и руководителя проекта и определяет их полномочия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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