Разработайте устав проекта в условиях бизнес ситуации

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

Устав проекта (Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика.

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

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

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

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

2. Бизнес-цели компании или причины возникновения проекта.

Формулировка причины фактически дает ответ на вопрос » Зачем выполняется данный проект?».

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

3. Цели проекта.

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

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

Формулировка целей должна соответствовать следующим критериям ( SMART- Specific, Measurable, Achievable, Relevant, Time-bound ):

  • Конкретные (Specific) — позволяющие сформировать расписание проекта;
  • Измеримые (Measurable) — позволяющие качественно (или количественно) оценить, что результат получен;
  • Достижимые (Achievable) — принципиально реализуемые Исполнителем в рамках проекта, с учетом декларируемой помощи со стороны Заказчика;
  • Приносящие результат (Relevant) — соответствуют ожидаемой Заказчиком пользе;
  • Ограниченные во времени (Time-bound) — реализуемые в ожидаемые Заказчиком временные рамки проекта.

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

Примеры формулировок целей:

  • Проектирование единых унифицированных бизнес-процессов в Головной компании и дочерних компаниях холдинга.
  • Разработка единого унифицированного ERP-решения, которое предназначено для внедрения в Холдинге, состоящем из Головной компании и 10 дочерних компаний.
  • Разработка инструментальных средств развертывания/тиражирования полученного решения во всех дочерних компаниях Холдинга.

4. Границы проекта.

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

  • Организационные границы

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

  • Функциональные границы

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

  • Географические границы

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

Таблица
4.2.
Пример границ проекта

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

5. Содержание проекта (задачи проекта).

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

Пример описания содержания (задач) проекта

Автоматизация бизнес-процессов:

  • Управление основными средствами.
  • Учет затрат.
  • Управление персоналом.

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

  • Требования законодательства РФ в области бухгалтерского, налогового и статистического учета и отчетности.
  • Требования международных стандартов финансового учета и отчетности.
  • Требования управленческого учета Головной компании Холдинга.
  • Требования внутренней отчетности (внутреннего аудита).
  • Требования ТК РФ, отраслевой отчетности, отчетности Головной компании Холдинга.

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

Что считается проектом

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

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

ris1.jpg

Рисунок 1. Условия выделения группы задач в проект

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

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

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

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

Инструментарий управления проектами

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

  • PMI;
  • PRINCE2;
  • SDLC;
  • Agile;
  • Extreme;
  • Lean Six Sigma;

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

Таблица 1. Общее сравнение наиболее популярных подходов проектного управления

Подход PMI PRINCE2 SDLC Agile Lean Six Sigma
Типы управляемых проектов Все, в основном крупные Все, в основном крупные Сложные IT-проекты В основном IT-проекты Повышение качества производства
Региональная популярность Северная Америка Европа, Азия Глобально, крупные компании Глобально, в основном стартапы Глобально, крупные компании
Ключевые преимущества Хорошо структурирован под реализацию больших проектов Хорошо структурирован под реализацию больших проектов Хорошо структурирован под реализацию больших проектов Идеально для небольших проектов или проектов с часто меняющимися условиями Идеально для проектов по повышению качества продукции
Ключевые недостатки Излишне затратен для небольших проектов или для проектов с повышенной степенью неопределенности Излишне затратен для небольших проектов или для проектов с повышенной степенью неопределенности Излишне затратен для небольших проектов или для проектов с повышенной степенью неопределенности Вероятны отклонения от ожиданий заказчика проекта Неприменим для всех видов проектов
Сертификация для исполнителей Требуется Требуется Не требуется Не требуется Требуется

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

  1. Использование инструментария проектного управления в операционных или несущественных для деятельности компании задачах. Например, один из проектов на крупной производственной компании предполагал создание уникального IT-продукта сотрудниками IT-департамента. Однако возможная выгода от реализации этого проекта измерялась крайне малыми суммами. В этой ситуации раскрутка маховика проектного управления обошлась компании значительно дороже, чем выгода от реализации проекта.
  2. Стремление к излишней гибкости (возможности внесения изменений в одобренный бенефициарами план) или, наоборот, отказ от изменений при очевидном наличии такой необходимости. Стремление упрощать процессы планирования и контроля и оперативно реагировать на возникающие обстоятельства могут привести к результату, отличному от ожиданий заказчика.

Основные этапы проекта

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

Можно выделить группы процессов, которые свойственны каждому проекту (см. рисунок 2).ris2.jpg

Рисунок 2. Группы процессов проекта

Далее рассмотрим их подробнее.

Инициирование проекта

Инициирование проекта можно разделить на две части:

  1. Формирование устава проекта.
  2. Формирование команды проекта.

Устав проекта – это относительно небольшой по объему документ (6–7 слайдов максимум). Напомню, что мы говорим о внутренних проектах, где исполнитель и заказчик работают в одной компании. Устав проекта преследует следующие цели:

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

Устав проекта резюмируется в небольшую таблицу (см. таблицу 2).

Таблица 2. Резюме проекта.

Наименование проекта: Улучшение процесса обслуживания покупателей

Предпосылки:

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

Участники проекта:

  1. Спонсор проекта:
  2. Заказчик проекта:
  3. Куратор проекта:
  4. Руководитель проекта:
  5. Команда проекта:

Цели:

  1. Обеспечить ответ на каждый запрос.
  2. Сократить средний срок решения запроса покупателя на 60%.
  3. Сократить количество повторных обращений на 80%

Критерии оценки:

  1. Среднее время реагирования на запрос покупателя.
  2. Количество повторных запросов.
  3. Результаты ежегодного опроса покупателей

Периметр проекта: подразделение Южного-Федерального округа

Допущения:

Документация проекта будет рассмотрена не позднее20 декабря 2019 г.

Проектная команда будет утверждена в предложенном составе

Ключевые вехи:

Утверждение проекта – январь 2020 г.

Анализ и протоколирование источников – февраль 2020 г.

Утверждение рекомендаций – апрель 2020 г.

Внедрение рекомендаций – май 2020 г.

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

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

Планирование проекта

Этап должен ответить на следующие вопросы:

  1. Что планируется сделать?
  2. Как планируется сделать?
  3. Какие события являются критериями завершения проекта?

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

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

ris3.jpg

Рисунок 3. Структура плана проекта

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

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

  1. Финансовый план и план мероприятий должны быть синхронизированы.
  2. Финансовый план должен рассчитывать объем необходимых инвестиций и бюджеты проекта. Бюджеты могут быть разбиты по времени и подразделениям, но в сумме они должны быть сопоставимы с объемом запрошенных инвестиций.
  3. Финансовый план должен учитывать именно те ресурсы, которые будут предоставлены для его реализации. Из этого тезиса, например, возникает необходимость разделения учета расходов на персонал на операционную деятельность и непосредственно на реализацию проекта.
  4. Оба плана должны допускать возможность внесения изменений в рамках утвержденных процессов.
  5. Финансовый план и бюджет проекта должны быть синхронизированы с текущей учетной политикой компании. Неэффективно планировать расходы и доходы без возможности последующего сбора соответствующих фактических значений.

Планирование проекта – это сложный и порой дорогостоящий процесс. Самое важное на этом этапе понять два ключевых момента:

  1. Степень обоснованности доходной части проекта (если речь идет о проектах с запланированной отдачей на вложенный капитал). Недоработки в этой части были и остаются основной причиной неудач проекта.
  2. Способы управления рисками проекта. То, как команда проекта планирует управлять рисками, определит величину потенциальных убытков.

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

Исполнение проекта

Из всего, что важно для успешного исполнения задач проекта, можно подчеркнуть следующее:

  1. Необходимо защищать периметр проекта. Желание расширить его границы возникает практически всегда. И здесь важно донести до заказчика и спонсора необходимость внесения соответствующих изменений в утвержденные планы или о воздержании от внесения таковых.
  2. Основная роль руководителя проекта – это коммуникации. Важно ограничивать свое желание уйти в исполнение, разработку продукта, проектирование и т.п. Коммуникации на предприятии могут стать настоящим кошмаром проектного управления, если им не уделять большую часть своего внимания.
  3. Согласованные в проектной документации ресурсы должны быть реально предоставлены.
  4. Мотивация персонала для проектных и операционных задач должна быть разной. Проектные задачи – это всегда умение работать с неопределенностью. Здесь важно избегать формальных решений, и отдельная мотивация является одним из наиболее эффективных инструментов. Она может быть выражена в виде премий, доли в проекте и в виде любых других поощрений.

Мониторинг и контроль проекта

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

ris4.jpg

Рисунок 4. Иерархия проектов

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

Закрытие проекта

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

ris5.jpg

Рисунок 5. Варианты закрытия проекта

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

Заключение

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

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

Цель
работы:
Изучение
основных понятий: бизнес-цель, устав
проекта, технико-экономическое обоснование
проекта. Формирование практических
умений и навыков формулирования цели
организации; разработки устава проекта,
технического задания ИС.

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

знать:

  • решения
    задач обработки информации;

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

уметь:

  • создавать
    проект по разработке приложения и
    формулировать его задачи;

  • выполнять
    управление проектом с использованием
    инструментальных средств.

Задание
для практической работы:

  1. Изучить
    теоретическую часть

  2. Выполнить
    практическую часть

  3. Ответить
    на контрольные вопросы

  4. Оформить
    отчет.

Теоретическая часть

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

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

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

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

  • функцию
    постановки задачи;

  • функцию
    согласования;

  • авторизационную
    функцию;

  • функцию
    повышения дисциплины;

  • консолидационную
    функцию;

  • интеграционную
    функцию.

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

  1. Обоснование
    выполнения уникальной задачи развития.

  2. Цели,
    задачи и результаты.

  3. Имя
    и фамилию PM, границы его ответственности
    и полномочия.

  4. Определение
    и структуру продукта.

  5. Интересы
    и ожидания участников.

  6. Критерии
    успеха.

  7. Принципы
    организации и управления проектом.

Соседние файлы в предмете Управление проектами

  • #
  • #
  • #
  • #
  • #
  • #

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Просмотры: 38 842


Подборка по базе: Лабораторная работа 13.doc, Практическая работа 3.docx, Лабораторная работа 12.doc, Практическая работа №1 Лопатникова А.И..docx, Практическая работа №2.docx, Аттестационная работа_итоговая_9 кл.doc, Практическая работа № 1 Бренько Т.Ю..docx, Практическая работа № 4.docx, Итоговая работа 1.docx, Практическая работа № 3.docx


Практическая работа № 9

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

Цель работы: Изучение основных понятий: бизнес-цель, устав проекта, технико-экономическое обоснование проекта. Формирование практических умений и навыков формулирования цели организации; разработки устава проекта, технического задания ИС.

Практическая часть

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

Таблица 1. Требования к уставу проекта

Раздел Пояснения
1. Название проекта Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания
2. Бизнес-причина возникновения проекта Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте
3. Бизнес-цель Сформулирована заказчиком, исходя из стратегических и тактических целей компании.
4. Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта
5. Расписание основных контрольных событий На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта, принципиальные для организации-заказчика, теми, которые абсолютно необходимы, т.е. обычно тремя-пятью.
6. Участники проекта Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него.
7. Окружение проекта Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика — к использованию его результатов.
8. Допущения относительно организации и окружения, а также внешние допущения Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:

— компетенции команды проекта достаточно для выполнения предпроектного обследования;

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

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

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

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

— не менее 40% членов команды проекта, предоставляемых исполнителем, заняты на 100% в проекте.

Обратите внимание, что при составлении устава проекта ограничения формулируются со стороны организации-заказчика об организации-исполнителе и о проекте в целом

10. Объем денежных средств, выделенных на достижение бизнес-цели На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта. Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от -20% до +100%
11. Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта — объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта.

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

     — утверждать бизнес-цели проекта, включая расписания и бюджет, и вносимые в них изменения;

     — назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения;

     — формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта;

     — вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов;

     — принимать решения о внесении изменений в базовую линию проекта.

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

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

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

Приложение 1

Пример Устава проекта «Сайт «Абитуриент 31»»

Раздел Пояснения
1. Название проекта «Абитуриент 31»
2. Бизнес-причина возникновения проекта Многие абитуриенты как из Белгородской области, так и из других областей, имеют мало представления (или не имеют) о тех специальностях, на которых можно обучаться на территории Белгородской области. Им приходится искать все возможные учебные заведения, искать специальности. Так же многие абитуриенты не понимают до конца куда они хотят пойти, так как многие специальности в учебных заверениях не до конца описываются, и предоставляется мало информации о сути специальности и о изучаемых дисциплинах.
3. Бизнес-цель Создать сайт «Абитуриент 31» для помощи абитуриентам в выборе своей будущей профессии в Белгородской области до 8 марта 2020 года.
4. Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта Количественные:

1) Вовлечь в проект не менее 10 общеобразовательные и среднеобразовательных школ, для прохождения тестирования;

2) Вовлечь в проект не менее 5 молодых преподавателей учебных заведений по Белгородской области.

Качественные:

1) Создание удобный и простой интерфейс;

2) Обеспечение регистрацию пользователей;

3) Предоставление тестирования, в котором будут затрагиваться вопросы, касающиеся интересов абитуриента, предметов, которые нравятся абитуриенту;

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

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

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

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

8) Если встречается одна и та же специальность в нескольких учебных заведениях, то предоставляется возможность сравнения обучения в данных заведениях по следующим критериям: стоимость обучения, количество бюджетных и внебюджетных мест, возможность продолжения обучения в вузе (если СПО), магистратура, аспирантура и т.д., необходимые баллы при поступлении, вступительные испытания.

5. Расписание основных контрольных событий Время начала и завершения проекта:

08.02.2019 — 08.03.2020 гг.

Ключевые вехи проекта:

— Создание списка специальностей и образовательных учреждений высшего и среднего профессионального образования Белгородской области. 08.02.2019 — 08.03.2020.

— Создание списка общеобразовательных учреждений Белгородской области с разделением на муниципальные районы. 10.02.2019 — 10.03.2019.

— Предпроектная подготовка к созданию сайта. 02.03.2010 — 02.04.2019.

— Разработка и согласование дизайна. 03.04.2019 — 03.06.2019.

— Верстка сайта. 04.06.2019 — 04.07.2019.

— Разработка профориентационного теста. 04.06.2019 — 04.08.2019.

— Программная часть проекта. 05.08.2019 — 05.11.2019.

— Заключение соглашений о сотрудничестве с образовательными учреждениями высшего и среднего профессионального образования Белгородской области. 05.08.2019 — 05.10.2019.

— Информационное наполнение сайта. 06.11.2019 — 06.01.2020.

— Тестирование сайта в Интернете. 07.01.2020 — 07.02.2020.

— Информирование общеобразовательных учреждений Белгородской области. 08.02.2020 — 08.03.2020.

— Официальный запуск сайта. 08.02.2020 — 08.03.2020.

6. Участники проекта Управление образования Белгородской области,

руководитель проекта,

команда разработчиков,

спонсор.

7. Окружение проекта Поддержка проекта Департаментом образования Белгородской области
8. Допущения относительно организации и окружения, а также внешние допущения — компетенции специалистов по разработке дизайна сайта достаточно;

— компетенции специалистов по разработке верстки сайта достаточно;

— компетенции команды проекта достаточно для разработки профориентационного теста;

— компетенции специалистов по созданию сайта достаточно;

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

9. Ограничения относительно организации и окружения, а также внешние ограничения — увеличение стоимости проекта не более чем на 20%;

— не менее 5 молодых преподавателей учебных заведений по Белгородской области заняты на 100% в проекте.

10. Объем денежных средств, выделенных на достижение бизнес-цели 372184,6 р.
11. Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор Полномочия руководитель проекта:

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

Полномочия спонсора проекта:

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

Полномочия координатора проекта:

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

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

Султанов Искандер Анварович

Автор статьи:

Основатель Projectimo.ru

Свежие публикации автора:

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

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

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

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

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

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

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

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

модель процессов инициации проекта

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

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

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

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

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

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

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

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

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

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

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

устав инвестиционного проекта

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

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

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

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

Источник

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

Устав проекта должен:

  • Описывать суть проекта.
  • Обеспечивать общее понимание проекта.
  • Обозначать зоны ответственности между спонсором проекта, основными заинтересованными сторонами и проектной командой

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

По Initiative for Policy Dialogue (IPD) этот документ называется устав проекта. В системе управления взаимоотношениями с клиентами (CRM) он известен как определение проекта. И IPD, и CRM требуют чтобы этот документ был частью процесса управления проектами.

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

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

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

Три основных вида использования проекта:

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

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

Устав проекта создается инициативной группой в самом начале. Разработка устава и определение заинтересованных сторон — это два основных действия инициативной группы.

Вклады для разработки устава могут быть:

  • Заявление о работе проекта
  • Технико-экономическое обоснование
  • Соглашения и договоренности
  • Стандарты предприятия, отраслевые стандарты, правила и нормы
  • Организационный процесс, структуру и шаблоны

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

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

Ссылки[править | править код]

Источник

Юлия Бажанова

Редактор проекта, РМР, ICP-PPM

Устав проекта это бизнес план проекта

Устав проекта это бизнес план проекта

Устав проекта это бизнес план проекта

Устав проекта (Project Charter) – это документ, который обычно готовит руководитель проекта после получения вводных о проекте.

Зачем нужен устав проекта

Устав содержит основные характеристики проекта и согласуется основными заинтересованными лицами (как минимум – Заказчиком и Спонсором проекта). Как правило, разработка и подписание Устава несет в себе 3 основные функции:

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

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

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

Как написать устав проекта

Содержание устава проекта часто зависит от специфики Компании. В качестве примера можно привести следующий набор разделов устава:

  1. Начальные условия (Project Background) – что привело к инициации проекта, входные условия, «боль» Заказчика.
  2. Цели и ожидания проекта (Project Objectives / Expectations) – чего мы хотим достичь на выходе. Это что-то должно быть измеримым (по SMART или как-то еще, неважно) и не допускать двойного толкования. Например, цель «сделать систему CRM, чтобы привлекать больше клиентов» – как-то не очень, правда? А вот «разработать и внедрить систему CRM для сотрудников отдела продаж Северо-Волжского филиала до 01.12.2015 для обеспечения мгновенного доступа к информации о тратах клиентов в разные периоды года» – это уже немножко лучше.
  3. Содержание и результаты (Scope and deliverables) – что именно мы включаем в состав проекта и какие конкретные результаты получим? Например, если нужно выпустить новую систему CRM, то на выходе мы должны иметь саму систему, сервера, на которых мы ее поставим, обученных пользователей и документацию для передачи в поддержку (а может, и саму организованную с нуля поддержку). В этом разделе вы четко ограничиваете, что вы сделаете. Еще очень полезно сюда же включить подраздел со списком того, что в содержание проекта не входит в явном виде (чтобы все это согласовали и потом никто не удивлялся, почему вы в рамках проекта еще и систему управления инцидентами для техподдержки системы не внедрили).
  4. Ключевые требования и характеристики (Requirements and Characteristics) – то, что не является результатом проекта, но важно для него. Если опять вернуться к системе CRM, то типовым требованием может быть «Срок обучения сотрудника системе не должен превышать 1 рабочего дня», «Поддержка системы не должна быть дороже 200 000 р. в год», «В системе одновременно должно работать не менее 300 человек» и подобное.
  5. Бюджет и сроки (Cost and Timelines) – деньги, сроки и их взаимоотношения с другими сторонами проектного треугольника. Например, сюда полезно вписать приоритеты по убыванию типа Бюджет-Содержание-Сроки. Т.е. потратить больше денег прямо никак нельзя, уменьшать получаемые результаты сильно нежелательно (но можно, в самом крайнем случае), и если надо ради первых двух пунктов увеличить срок – это ок. Часто тут многие зависают, мол, «да нам все важно!», но в правильно мире вы идете к Спонсору и спрашиваете его, если спонсор адекватен – у него это понимание приоритетов точно есть, и он поделится им с вами.
  6. Ключевые участники (Key Stakeholders) – основные заинтересованные лица, как минимум – Спонсор, Заказчик, те, кому придется делиться с вами ресурсами (в матричной структуре), ваш руководитель, держатель бюджета и т.д. Включать сюда всю компанию не стоит, просто подумайте и напишите: а) кто должен знать о проекте на этой стадии б) к чьему авторитету вам будет полезно апеллировать в ходе проекта
  7. Допущения и ограничения проекта, основные риски (Project Assumptions and Restrictions, Main Risks) – про эти вещи мы еще поговорим подробнее, но в целом цель включения их в устав проекта – донести до всех заинтересованных лиц особенности того окружения и того момента, в которых вы делаете проект, озвучить свои опасения и получить подтверждение их готовности в этих вопросах вам всячески помогать. Ну и чтобы потом никто не говорил «а нам не сказали».

Пример из жизни! Давайте сделаем очень короткий устав проекта «Ремонт в квартире», как образец, а то теория  – это хорошо, но не всегда понятно:

  1. Начальные условия – живу в квартире уже 15 лет, краска на потолке облупилась, батареи старые и вообще мне некомфортно. Я заказала дизайн-проект, мне нарисовали квартиру моей мечты, осталось только сделать.
  2. Цель – сделать ремонт в квартире площадью 65 метров в строгом соответствии с дизайн-проектом не позже чем к такому-то числу и не больше чем за такие-то деньги.
  3. Содержание и результаты (Scope and deliverables) – на выходе должны быть полностью замененные коммуникации (сантехника, электрика, отопление), новая входная дверь, новая сантехника, косметический ремонт (плитка в санузле, ламинат, обои и потолки во всех комнатах), заказанная и установленная кухня, полностью все освещение и вся мебель. Что не буду делать: отдирать стяжку пола (что ей стало-то за 15 лет), делать теплые полы и звукоизоляцию, и менять окна (они хорошие, только 2 года назад поставила).
  4. Ключевые требования и характеристики – все должно быть в строгом соответствии с дизайн-проектом (см.пачку приложенных чертежей и смету), если что-то сделать нельзя или дороже больше чем на 10% – надо согласовывать на семейном совете. Разводку электрики и сантехники надо согласовать с местным ЖЭКом.
  5. Бюджет и сроки (Cost and Timelines) – 2 млн. рублей на все, включая мебель и кухню (30% на черновую отделку и коммуникации, 20% на чистовую, включая сантехнику, 20% на кухню и 30% на мебель). Срок – максимум 4 месяца, т.к. мы всего на 4 месяца договорились к родителям переехать, в крайнем случае можно добавить еще 2 недели (поживем в гостинице). Приоритеты бюджет-качество-сроки (лучше в гостинице поживем, пока штукатурка будет сохнуть, но денег на тепловую пушку для сушки не выделим и клеить обои на мокрую штукатурку тоже не будем).
  6. Ключевые участники (Key Stakeholders) – я, муж, родители, бригада, с которой я уже договорилась, соседи (надо уточнить, когда у них дети спят), ЖЭК (с ними надо проект согласовать).
  7. Допущения и ограничения проекта, основные риски (Project Assumptions and Restrictions, Main Risks) – допущения: соседи нескандальные, работать можно весь световой день, бригада адекватная и не будет бухать на объекте, курс доллара глобально не вырастет и стройматериалы сильно не подорожают; ограничения: нельзя работать после 22.00, не могу приезжать контролировать работу в будни (работаю), первая выплата бригаде возможна только в апреле (закончится депозит, где деньги на ремонт лежат); риски: возможно, ошибочно посчитана смета и денег на все не хватит, в дизайн-проекте ошибка, такую перепланировку узаконить нельзя, т.е. придется ремонт останавливать и все переделывать.

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

Мораль: устав даже на 1 страничке А4, подписанный заинтересованными лицами, лучше чем неподписанный на 5 страничках. И требование подписать его до начала работ со стороны РМа полностью законно в любой компании, более того – это прибавляет вам профессионального веса, позволяет понять «а чего же мы все-таки делаем» и получить хоть какие-то полномочия. Если управление проектами в компании отсутствует как класс, то даже неподписанный устав лучше чем его отсутствие, вы хотя бы разберетесь, что делать, и настроитесь на правильный лад с самого начала проекта (да простит меня РМВОК).

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

Всего за 99 руб вы можете скачать готовый детальный шаблон устава ИТ-проекта в docx. В готовом примере устава проекта вы найдете все необходимые пункты – от содержания проекта и описания ролей и обязанностей участников проекта до перечня типовых рисков. После оплаты на почту вы получите архив с шаблоном. Сэкономьте свое время, оно стоит намного дороже!
Скачайте готовый пример устава проекта и начните работать прямо сейчас вместо траты нескольких часов на поиск и написание типовых разделов.
Купить готовый шаблон Устава за 99 руб.

Рекомендуем! Также за 249 руб вы можете скачать набор из трех разных готовых шаблонов уставов ИТ-проектов в docx, в том числе – два расширенных примера готовых уставов проектов (для работы с подрядчиком/заказчиком) и один сокращенный пример готового устава проекта (для внутренних проектов). Набор примеров уставов поможет вам создать на их основе именно тот устав вашего проекта, который нужен именно вам!

Купить 3 готовых шаблона Устава за 249 руб.

Устав проекта это бизнес план проекта

Устав проекта это бизнес план проекта

Информация полезна? Поддержи развитие проекта!

На кофе и новые материалы для читателей блога 🙂

Еще статьи

Показать еще

комментарии

Подписаться на нашу рассылку

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

Источник

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

Устав проекта (УП) разъясняет,
в каком направлении будет идти ваша компания и зачем,
что изменится и какие риски при этом возникнут.

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

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

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

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

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

Устав проекта в Worksection

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

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

Когда создается УП?

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

Кто разрабатывает и одобряет УП?

Разработкой УП обычно занимаются опытные ПМ. Документ одобряется спонсором проекта.

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

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

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

Шаг 1. Определите конечную цель.

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

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

Шаг 2. Создать организационную структуру.

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

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

Команда в Worksection

Шаг 3. Подготовить план имплементации УП.

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

Шаг 4. Предусмотрите риски и проблемные моменты.

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

3 главные причины, почему без устава ваш проект рискует провалиться

  1. Проектному менеджеру будет не хватать полномочий, а проекту — ресурсов. Готовый устав проекта же документирует одобрение от стейкхолдеров. Поэтому ПМ не придется постоянно выбивать дополнительное финансирование или сражаться за свои полномочия.
  2. Нет понятных ожиданий от проекта. А вот в уставе его цели и задачи подробно описаны. Это уменьшает вероятность, что содержание проекта начнет в дальнейшем разрастаться.
  3. Проект приведет вас к результатам, которые идут вразрез с целями организации. Ведь в УП, наоборот, обосновывается важность проекта для бизнеса и как он соответствует видению компании.

8 вопросов для создания более эффективного УП

  1. Было ли потрачено достаточно времени и сил, чтобы понять необходимость запуска проекта? Иначе вы не определите ключевые элементы и цели при составлении УП.
  2. Имеется ли четкая связь со стратегическими целями компании? Проект принесет пользу, если он имеет логику в глобальной миссии организации.
  3. Какую ценность проект принесет для собственников и руководства? Как он вписывается в бизнес-цели компании?
  4. Было ли описание проекта понятно составлено? Когда есть точные показатели для бюджета, сроков, качества, то будет намного легче отобразить более развернутую картину для стейкхолдеров, спонсоров проекта и ПК.
  5. Цели реалистичные и досягаемые? В обратном случае нет смысла дарить ложные надежды стейкхолдерам и спонсорам.
  6. Каковы риски для организации, если не запускать проект? Если они минимальные, тогда нужно проанализировать, стоит ли реализовать новую идею. Либо существующие внутренние и внешние риски напротив подталкивают быстрее начать проект.
  7. Доступны ли требуемые ресурсы? Если нет, то планирование проекта было неудачным. Даже если необходимые ресурсы имеются у компании, нужно предусмотреть нежелательные ситуации при анализе рисков.
  8. Как реалистично измерить успешность проекта? KPI должны быть пересмотрены, если необъективно отражают прогресс проекта.

Сперва создайте проект, придумайте для него название соответственно целям. С помощью меню «Пригласить в проект» пригласите пользователей, которые помогут вам создать устав. Заполните поля с информацией об участниках проекта: имя, фамилия, e-mail, отдел.

Также вы можете пригласить заказчиков, выбрав тип «Клиент» при добавлении компании.

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

Создание задачи в Worksection

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

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

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

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

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

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

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

Обоснование

Зачем инициирован проект, какие возможности он откроет для компании?

Цели и критерии их выполнения

Краткий план

Какие процессы будут выполнены?

Стейкхолдеры

Заказчик

ФИО

Спонсор

ФИО

Проектный менеджер

ФИО

Участники
проектной команды

ФИО, ФИО, ФИО, …

Ключевые этапы

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

Бюджет

Внесите главные расходы.

Ограничения, предположения, риски и зависимости

Ограничения

Какие факторы могут повлиять на проект?

Предположения

Какие ситуации возникнут, которые помогут вам достичь целей?

Риски и зависимости

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

Подписи

ФИО,
Заказчик проекта

ФИО,
Спонсор проекта

ФИО,
Менеджер проекта

Вердикт

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

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

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

Понравилась статья? Поделить с друзьями:

Другие крутые статьи на нашем сайте:

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии