Здравствуйте, в этой статье мы постараемся ответить на вопрос: «Оформление устав проекта». Также Вы можете бесплатно проконсультироваться у юристов онлайн прямо на сайте.
Содержание:
В административном судопроизводстве в соответствии со ст. 2 Закона об адвокатуре выступать лица, получившие установленный данным Законом статус адвоката и право осуществлять адвокатскую деятельность. Родители представляют свидетельство о рождении детей и собственный паспорт.
Чудо-бумажка, или зачем нужен устав проекта и как его написать
Устав проекта (Project Charter) – это документ, который обычно готовит руководитель проекта после получения вводных о проекте.
Зачем нужен устав проекта
Устав содержит основные характеристики проекта и согласуется основными заинтересованными лицами (как минимум – Заказчиком и Спонсором проекта). Как правило, разработка и подписание Устава несет в себе 3 основные функции:
- Определить основные требования к результату проекта и основные характеристики самого проекта (бюджет, сроки).
- Формально запустить проект, т. к. только после подписания проект считается действительно существующим в Компании.
- Наделить руководителя проекта определенным уровнем полномочий (каким именно – зависит от Компании).
Иногда устав проекта используется для оценки выгод от его реализации и принятия решения о запуске. Хотя это не соответствует классической методологии, по которой устав готовится только для уже оцененного и утвержденного к реализации проекта.
Как написать устав проекта
Пример из жизни! Давайте сделаем очень короткий устав проекта «Ремонт в квартире», как образец, а то теория – это хорошо, но не всегда понятно:
Ну и напоследок. Меня часто спрашивают, насколько детальным должен быть устав проекта? Точного рецепта здесь нет, но в общем случае – детализация устава проекта должна быть такой, чтобы в случае какого-то серьезного запроса на изменение в проекте вы могли обратиться к уставу как к истине в последней инстанции и сказать «нет, мы это не делает, т.к. это не приближает нас к цели проекта или противоречит характеристикам результата». По большому счету, если проект дошел до такого состояния, что запросы на изменение с уставом уже не «бьются» – похоже, ваш проект закончился неудачей и его лучше закрыть, требования и ограничения пересмотреть и начать новый.
Мораль: устав даже на 1 страничке А4, подписанный заинтересованными лицами, лучше чем неподписанный на 5 страничках. И требование подписать его до начала работ со стороны РМа полностью законно в любой компании, более того – это прибавляет вам профессионального веса, позволяет понять «а чего же мы все-таки делаем» и получить хоть какие-то полномочия. Если управление проектами в компании отсутствует как класс, то даже неподписанный устав лучше чем его отсутствие, вы хотя бы разберетесь, что делать, и настроитесь на правильный лад с самого начала проекта (да простит меня РМВОК).
Конечно, в уставе проекта могут быть и другие пункты в зависимости от специфики проекта, в посте перечислен “кандидатский минимум”, сам документ можно и нужно переделывать под себя.
Рекомендуем! Также з а 249 руб вы можете скачать набор из трех разных готовых шаблонов уставов ИТ-проектов в docx, в том числе – два расширенных примера готовых уставов проектов (для работы с подрядчиком/заказчиком) и один сокращенный пример готового устава проекта (для внутренних проектов). Набор примеров уставов поможет вам создать на их основе именно тот устав вашего проекта, который нужен именно вам!
Источник: https://upravlenie-proektami.ru/chudo-bumazhka-ili-zachem-nuzhen-ustav-proekta-i-kak-ego-napisat
Разработка устава проекта. Методическое пособие
Искусство управления проектом заключается в том, чтобы неведомое сделать предсказуемым. И чем раньше выявятся подводные камни – тем больше шансов не нахлебаться воды.
Устав проекта – это документ, который формализует ключевые договоренности по всем измерениям проекта между его участниками. Он разрабатывается в ходе инициации проекта – до решения о его начале.
Устав проекта определяет каркас проекта в 5 измерениях:
-
ЦЕЛИ и ТРЕБОВАНИЯ ЗАДАЧИ РИСКИ УЧАСТНИКИ ПРАВИЛА
Также может добавляться еще шестое измерение – РЕСУРСЫ (бюджет и иные).
И хотя на этапе инициации проекта, пока не выполнено детальное планирование, точно определить потребность в ресурсах довольно сложно, вполне возможно выявить ограничения по ресурсам, которые придется учитывать при планировании.
Чтобы определить каркас проекта в этих измерениях необходимо:
- выявить и проработать систему целей проекта;
- определить границы проекта и требования к его результатам;
- выявить предположения и риски;
- разработать стратегический план проекта;
- спроектировать организационную структуру и правила взаимодействия.
На практике результаты выполнения этих задач могут фиксироваться в разных документах, таких как: договор, устав проекта, план управления рисками, техническое задание. Структура и объем каждого документа, а также распределение по ним этих данных определяется спецификой каждой компании и зависит от выбранной методологии и технологии управления проектами. При использовании современных технологий управления проектами эти документы не разрабатываются самостоятельно, а генерируются как отчеты на основе единой проектной базы, содержащей трассируемые данные по всем измерениям проекта.
Устав проекта может быть как внутренним документом, так и документом, согласуемым с внешними сторонами проекта, фактически выполняя роль контракта между заказчиком и исполнителем. Последний подход чаще используется зарубежом.
Успешной команде нужна разработка устава проекта — «прощупать» проект, пока корабль еще не укомплектован и не отошел от берега. И важен не сам документ, а те задачи, которые придется решить, чтобы наполнить его смыслом.
Рассмотрим подробнее эти задачи.
Для описания задач воспользуемся методологией функционального моделирования IDEF0.
Точка зрения: Руководитель проекта.
Контекст: Для того, чтобы показать место процесса по разработке устава проекта и самого устава проекта в жизненном цикле проекта, контекстная диаграмма А0 соответствует процессу выполнения проекта в целом и затем детализируется на отдельные этапы. Данная модель не противоречит PMBOK 4, но обладает большей детализацией с точки зрения процесса разработки устава проекта.
Допущения: Процесс подготовки и выполнения проекта итеративен и многие задачи часто выполняются в параллель, поэтому приведенное в модели разбиение на этапы отражает информационные зависимости между процессами, но не означает, что процессы всегда выполняются в такой последовательности.
На диаграммах А0-А1 (рисунок 1 и 2) отражен контекст интересующего нас процесса.
Предполагается, что в организации есть корпоративный стандарт управления проектами, в котором определены основные правила ведения проектов. В этом случае в уставе проекта вводятся ссылки на данный стандарт и указываются только те данные, которые являются специфичными для выполняемого проекта. Если такого стандарта нет, это означает, что такие правила нужно определять каждый раз индивидуально для каждого проекта.
Обычно работы по проекту начинаются с получения каких-то исходных данных, будь-то брошенная вскользь идея заказчика или формализованное ТЗ на 200 страниц. С этих исходных данных и предстоит начать «разматывать клубок» в ходе разработки устава проекта.
Рисунок 1. Контекстная диаграмма А0
Разработка устава проекта (см. рис 2) является подготовительным этапом и по его результатам принимается решение об инициации проекта. Важность этого этапа сложно переоценить, т.к. от него зависит «быть или не быть» проекту. Кстати, те, кто пропускают этот этап в начале проекта, в итоге вынуждено возвращаются к этому вопросу позже, уже израсходовав некоторую часть ресурсов двух организаций.
Если проект инициирован, то собранные в ходе разработки устава проекта высокоуровневые данные по всем 5(6) измерениям проекта должны быть детализированы на следующих этапах. Устав проекта является руководящим документом для последующих этапов, что и отражено на диаграмме А1 на рисунке 2.
Рисунок 2. Диаграмма А1 «Выполнить проект»
Хотя на диаграмме А1 не отражена обратная связь между блоком А1.4 Анализировать проект и А1.1 Разработать устав проекта , нельзя забывать, что и устав проекта не является его «догмой» и может быть пересмотрен в любой момент для лучшего соответствия актуальным целям проекта и ситуации. Например, в ходе выполнения проекта выяснилось, что появляется несколько ключевых пользователей разрабатываемой системы, они безусловно должны быть включены в проект и его систему коммуникации, а их ожидания учтены и соотнесены с целями проекта.
При этом стоит помнить, что изменение ключевых ограничений проекта, отраженных в уставе, может существенно изменить картину по всем измерениям – начиная от требований, заканчивая сроками и бюджетом. Это может испугать неопытных руководителей и увести от проведения измений в явном виде. Однако суть от этого, конечно, не переменится – если изменения есть, их лучше зафиксировать и довести до участников проекта.
Введенные на первых двух диаграммах потоки, определены в таблице ниже.
Таблица 1. Потоки данных для А0-А1
| Имя потока | Определение потока |
| Данные проекта | * данные, дополнительные к исходным данным, которые были получены в ходе разработки устава проекта * |
| Исходные данные проекта | * любые исходные данные, полученные до организации проекта. Это могут быть требования заказчика, данные о предметной области проекта и др. * |
| Корпоративный стандарт УП | * стандарт предприятия, определяющий требования к процессам управления проектами. Может включать правила выполнения, детальное описание процессов, шаблоны документов. Степень детализации определяется в рамках каждого предприятия. Данный стандарт может являться частью стандартов СМК * |
| Корректировки | * предложения по изменению проекта * |
| План проекта | * оперативный план проекта с назначенными ресурсами, на основании которого выполняются работы * |
| Проектная база или редактор | * инструмент для разработки проекта, в зависимости от выбранной технологии управления проектом – документоориентированной или ориентированной на данные * |
| Результаты проекта | * все результаты, полученные в ходе выполнения проекта * |
| Руководитель проекта | * лицо со стороны исполнителя проекта, отвечающее за координацию и исполнение проекта * |
Далее нас интересует детализация процесса «Разработать устав проекта»:
Рисунок 3. Диаграмма А1.1. «Разработать устав проекта»
Прежде чем разбирать сам процесс необходимо познакомиться с определениями потоков данных:
Таблица 2. Потоки данных для А1.1
| Имя потока | Определение потока |
| Заинтересованные стороны | * стороны и лица, которые принимают решения или оказывают влияние на лиц, принимающих решения относительно хода проекта. Под сторонами подразумеваются организационные структуры, участвующие в проекте, под лицами — конкретные персоны, принадлежащие или нет данным организационным структурам. * |
| Критерии SMART | * требования к формулированию целей * |
| Критерии отсева проектов | * правила определения проектов, которые не должны браться в работу * |
| Орг-структура проекта | * организационная структура проекта * |
| Система целей проекта | * согласованная система целей проекта и ожиданий заинтересованных лиц, включающая измеряемые показатели и критерии достижения целей * |
| Стратегический план проекта | * включает основные этапы и результаты проекта, методы контроля хода проекта, риски проекта * |
| Правила детализации СП | * корпоративные правила детализации (декомпозиции) задач и результатов стратегического плана * |
| Правила взаимодействия | * корпоративные правила организации взаимодействия с заказчиком и внутри проекта, например, время отклика на запрос * |
| Правила оформления УП | * корпоративные правила оформления отчетного документа «Устав проекта» * |
Первоочередная задача подготовки и оценки проекта – понять и определить систему целей. Все цели проекта должны быть взаимоувязаны, даже те, которые невозможно зафиксировать в явной форме. Выявление и согласование целей – сложная задача, результаты которой определяют его успех или провал [1]. Чаще всего она не решается «с наскока», а некоторые важные цели мимолетно всплывают и тонут в несущественных деталях, подменяясь на составляющие их подцели. Задача руководителя проекта – держать в фокусе максимально полную картину, начиная с самого верхнего уровня.
На диаграмме процесса A.1.1.1, раскрывающей процесс «Выявить и проработать систему целей проекта» показано, что выявление целей проекта начинается с определения их источников — сторон и лиц, оказывающих влияние на ход проекта: кто принимает решения о проекте, кто принимает решение о приемке продукта, кто оказывает на него хоть какое либо влияние, пусть даже косвенное. Система целей проекта должна быть согласована с их ожиданиями. Противоречия целей проекта и ожиданий заинтересованных сторон неизбежно приводят к конфликтам как в ходе проекта, так и на этапе его сдачи. Поэтому за процессом разработки иерархии целей проекта стоит важная задача согласования целей проекта и ожиданий заинтересованных сторон. Этот процесс необходимо будет продолжить при подборе команды проекта (процесс «Спроектировать организационную структуру проекта»), которая также определяет ход проекта.
Рисунок 4. Диаграмма процесса A.1.1.1 «Выявить и проработать систему целей проекта»
Обычно цели проекта организуются в одну или несколько иерархий. Это означает, что для каждой цели верхнего уровня должны быть определены конкретные задачи, за счет выполнения которых предполагается достигнуть цели проекта. Например, если цель верхнего уровня — снизить затраты на изготовление продукции, то она может быть достигнута различными путями — снижением заработной платы, накладных расходов, автоматизацией производства и т.п., но это не значит, что в проекте будут использованы все способы, поэтому необходимо указать конкретные способы достижения цели, выбранные для данного проекта. Этот процесс также помогает оценить достижимость выбранной цели.
Хорошая практика формулирования целей заложена в принципах SMART [2]. Чтобы можно было добежать до цели, а не только согреться, необходимо указать критерии достижения целей проекта (блок A1.1.1.3) , т.е. показатели, которые возможно измерить, а также их значения. Это позволяет снять целых комплекс конфликтов и рисков неуспешного завершения проекта. Представьте, что вы руководитель проекта, вы выполнили проект в срок, уложились в бюджет, достигли сформулированной цели проекта — снизили затраты на изготовление продукции. А заказчик считает проект неуспешным, отказывается принимать результаты и соответственно делать выплаты. В чем же дело? Дело в том, что вы снизили затраты на 3% за 1 год, а заказчик считал, что они должны быть снижены на 10% за полгода, тогда проект для него считается успешным.
Эта сложная задача часто игнорируется, что приводит к неуспешным проектам и отражено в известной статистике ИТ- отрасли [1].
Таблица 3. Потоки данных для А1.1.1
| Имя потока | Определение потока |
| Критерии достижения целей | * значения измеряемых показателей, при которых цели проекта считаются достигнутыми * |
| Ожидания заинт. сторон | * ожидания от проекта заинтересованных сторон. Должны быть согласованы с целями проекта* |
| Система целей и ожиданий | * иерархия целей проекта, включающая ожидания заинтересованных лиц и отражающая с каким целями данные ожидания согласованы (на что трассируются) * |
Расширенный материал по формированию системы целей с иллюстрациями приведен в статье Цели проекта — упущенные возможности?
После разработки системы целей возможно приступить к более детальному планированию, хотя на данном уровне оно все равно остается в рамках стратегического — описываются основные этапы проекта и их результаты. Фактически, это продолжение разработки иерархии целей. Теперь определяются конкретные задачи и их результаты, которые помогут их достичь. (см рис. 5)
Кроме этого необходимо определить события, которые могут воспрепятствовать достижению целей — риски проекта, а также методы, которые позволят отслеживать ход выполнения проекта, т.е. понимать, насколько мы близки к цели.
Риски проекта сильно влияют на его план и ресурсы, т.к. в нем[плане] должны быть предусмотрены меры по их предотвращению или хотя бы по снижению негативных последствий.
Для каждого риска рекомендуется прорабатывать поля, описанные в определении потока Риски проекта (см Таблицу 4).
Еще один прием, позволяющий более точно определить каркас проекта — это описание его границ. Границы описываются за счет указания целей и задач, которые не входят в проект. Таким образом, более точно определяется развитие проекта, которое будет считаться успешным.
Рисунок 5. Диаграмма процесса A.1.1.2 «Провести стратегическое планирование».
Таблица 4. Потоки данных для А1.1.2
| Имя потока | Определение потока |
| Границы проекта | * цели, требования и задачи, не входящие в проект * |
| Задачи по предупреждению рисков | * задачи, которые необходимо учесть в плане работ, чтобы предупредить риски* |
| Методы контроля хода проекта | * процедуры определения состояния (хода) проекта, в т.ч. периоды отчетности, формы отчетности * |
| Риски проекта | * событие, наступление которого может привести к нарушению обязательств по проекту. Риск проекта описывается по следующей схеме: 1. Название — кратко отражает причину возникновения риска 2. Причина — полное описание причины возникновения риска 3. Возможное событие — событие, наступление которого возможно в следствие данной причины и которое может привести к нарушению обязательств по проекту 4. Результат — последствия наступления события для проекта 5. Предотвращение — меры по предотвращению причины события или самого события 6. Смягчение — меры по смягчению последствий наступления события Также необходимо указать статус и тип обработки. * |
| Этапы и результаты | * список или иерархия основных этапов проекта, а также результаты, которые должны быть получены на каждом этапе * |
После того, как стратегический план проекта разработан, можно переходить к формированию организационной структуры проекта. На данном этапе определяются участники проекта и их роли, определяется их область ответственности. Также устанавливаются официальные коммуникации проекта.
Орг-структура проекта должна соответствовать целям и задачам проекта. Плохо организованные люди способны завалить даже самый простой проект.
Рисунок 6. Диаграмма A1.1.3 процесса «Спроектировать организационную структуру проекта»
Таблица 5. Потоки данных для А1.1.3
Когда все элементы каркаса собраны, еще раз оценивается его жизнеспособность и реализуемость проекта.
Разработка устава проекта — это подготовительный этап, от результата которого зависит успех проекта. Структуру устава проекта хорошо использовать как справочник и чек-лист для оценки возможности успешно завершить проект. А вопросы, которые будут возникать в ходе разработки устава, позволяют на раннем этапе выявить и устранить конфликты и даже своевременно принять решение о закрытии проекта, если станет очевидным, что цели проекта недостижимы в текущих условиях.
Отношение к уставу проекта, как к простой формальности, отражает непрофессиональный взгляд на процессы управления проектами и вскрывает непонимание процессов, которые стоят за разработкой данного документа.
В рассмотренной схеме процессов показаны информационные связи между процессами. Выполнение процессов без их учета, хотя и часто встречается на практике, приводит к несогласованным результатам. В таких случаях необходимо проводить дополнительные итерации согласования результатов каждого этапа.
Источник: http://reqcenter.pro/project_charter/
Как написать устав проекта?
Не спешите запускать проект, когда имеете лишь общее представление, что вас ждет впереди и как к этому двигаться. Потратьте время на создание документа, который станет и верным компасом, и бесценной шпаргалкой!
Этот документ не только содержит базовую информацию, но и отражает общее видение стейкхолдеров.
УП обычно создается на самой ранней стадии проекта, еще до формирования проектной команды (ПК). Обычно он составляется совместно с другими участниками проекта и передается на финальное рассмотрение стейкхолдерам. В большинстве случаев устав подписывается спонсорами.
Что такое устав проекта
Можно написать документ на несколько десятков страниц, наполнив его всевозможными деталями, однако вряд ли вы захотите потом это перечитывать. Поэтому лучше все вместить максимум в 3-5 страниц, идеально — 1-2 страницы.
Как пример, устав проекта может выглядеть как текстовый документ, Google-документ или презентация. Также он может выглядеть как задача с метками «Документы» и «Стратегическая» в программе управления проектами Worksection:
- Какой специалист становится проектным менеджером (ПМ) и какой его круг полномочий
- Цель проекта и его связь с деловыми показателями
- Кем одобрен проект и кто будет его финансировать
- Состав проектной команды, требования и ожидания от проекта, ответственность каждого из его участников
- Критерии успеха
Перед запуском проекта. В это же время с ним должны ознакомиться стейкхолдеры.
Разработкой УП обычно занимаются опытные ПМ. Документ одобряется спонсором проекта.
- Обзор и обоснование
- Требования и цели
- Имена ПМ, спонсоров, стейкхолдеров
- Состав ПК
- Информация о вовлеченных сторонах
- Риски, ограничения, сильные и слабые стороны, возможности и угрозы
- Ожидаемые показатели
- Распределение обязанностей между каждым участником
- Все доступные и требуемые ресурсы
- Методологии, которые будут использоваться
- Стратегии коммуникации
- Бюджет и сроки
- Расписание
- Ключевые показатели эффективность (KPI) для измерения успешности
Разработка устава проекта
Составьте список от 3 до 5 целей поменьше, которые нужно достигнуть в ходе проекта. Убедитесь, что они конкретные, измеримые, достижимые, актуальные и ограниченные во время — то есть соответствуют критериям SMART.
Проанализируйте, как проект может повлиять на бизнес-показатели организации.
Определите конечных пользователей, стейкхолдеров, спонсоров, проектного менеджера, участников проектного комитета и проектной команды. Теперь вы сможете создать организационную структуру для проекта.
В Worksection всех их можно внести учасниками или гостями (статус, удобный для заказчиков, спонсоров и стейкхолдеров) в проект.
Перечислите этапы и процессы во время жизненного цикла проекта. Отметьте ключевые точки и зависимости между процессами. Составьте список с необходимыми ресурсами: оборудованием, ПО, материалами.
Если они возникнут, вы уже будете готовы и будете знать, как минимизировать их влияние.
3 главные причины, почему без устава ваш проект рискует провалиться
8 вопросов для создания более эффективного УП
- Было ли потрачено достаточно времени и сил, чтобы понять необходимость запуска проекта? Иначе вы не определите ключевые элементы и цели при составлении УП.
- Имеется ли четкая связь со стратегическими целями компании? Проект принесет пользу, если он имеет логику в глобальной миссии организации.
- Какую ценность проект принесет для собственников и руководства? Как он вписывается в бизнес-цели компании?
- Было ли описание проекта понятно составлено? Когда есть точные показатели для бюджета, сроков, качества, то будет намного легче отобразить более развернутую картину для стейкхолдеров, спонсоров проекта и ПК.
- Цели реалистичные и досягаемые? В обратном случае нет смысла дарить ложные надежды стейкхолдерам и спонсорам.
- Каковы риски для организации, если не запускать проект? Если они минимальные, тогда нужно проанализировать, стоит ли реализовать новую идею. Либо существующие внутренние и внешние риски напротив подталкивают быстрее начать проект.
- Доступны ли требуемые ресурсы? Если нет, то планирование проекта было неудачным. Даже если необходимые ресурсы имеются у компании, нужно предусмотреть нежелательные ситуации при анализе рисков.
- Как реалистично измерить успешность проекта? KPI должны быть пересмотрены, если необъективно отражают прогресс проекта.
Как в Worksection создать устав?
Теперь создавайте задачи , которые соответствуют 3-5 целям вашего проекта, упомянутым в уставе. Выбирайте меню «Поставить новую задачу», добавьте ее подробное описание : к чему вы стремитесь, какие критерии успешности, есть ли привязка к другим целям.
Далее установите приоритет задачи, назначьте ответственного за выполнение, укажите сроки и затраты.
Определите круг подписчиков для каждой из задач — кого-то она касается прежде всего, а кого-то наоборот мало интересует. При необходимости прикрепляйте файлы и устанавливайте метки для отслеживания выполнения.
Чтобы завершить создание задачи, нажмите «Создать задачу». Если нужно разбить задачу на несколько подзадач, вы можете сразу добавить в режиме «Пакетного добавления задач».
Вы можете настраивать вид задач в Worksection, сортировать их по приоритетности, ответственным лицам, меткам и др. Также удобно отслеживать, как продвигается выполнение задач в целом и какую часть из запланированного бюджета уже потрачено.
Пример устава проекта
Зачем инициирован проект, какие возможности он откроет для компании?
Источник: https://worksection.com/blog/how-to-write-a-project-charter.html
3.3 Обоснование целесообразности реализации проекта. 3
3.4 Ожидаемые результаты проекта. 5
3.5 Продукт проекта и его структура. 5
3.6 Основные этапы и результаты реализации проекта. 6
3.7 Заинтересованные стороны проекта. 9
3.8 Ожидания заинтересованных сторон. 9
3.10 Допущения и ограничения. 11
3.11 Периодичность отчетности участников проекта. 12
4. Общие принципы выполнения работ. 12
4.1 Передача и утверждение результатов проекта. 12
4.2 Управление проектной документацией. 13
Формат Устава проекта
Устав проекта нацелен на создание эффективной системы управления проектом, которая позволит обеспечить выполнение необходимого объема работ определенными ресурсами в заданные сроки при обеспечении требуемого качества результатов, включая обеспечение команды проекта согласованной Заказчиком и Исполнителем непротиворечивой информацией, необходимой для управления проектом.
Цель Устава проекта – установление правил организации работ по проекту путем документирования терминологии, целей, стратегии, границ, организационной структуры, методологии ведения проекта, ролевых функций и планов проекта, необходимых для достижения бизнес-целей проекта и компании в целом.
Устав проекта может изменяться в ходе выполнения работ и является обязательным для выполнения всеми участниками проекта.
Устав проекта вступает в силу после его подписания полномочными представителями Заказчика и Исполнителя и действует вплоть до подписания протокола о завершении проекта или до принятия одной из сторон решения об одностороннем выходе из проекта.
Проект – уникальная деятельность, имеющая начало и конец во времени, направленная на достижение заранее определённого результата/цели, создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска.
Риск проекта – потенциальная, численно измеримая возможность неблагоприятных ситуаций и связанных с ними последствий в виде ущерба, убытков, неблагоприятного изменения основных управляемых параметров проекта.
Руководитель проекта – сотрудник, назначенный Приказом о запуске проекта для управления проектом и отвечающий за результаты проекта, исполнение бюджета, качество и сроки проекта.
Стейкхолдер – физическое или юридическое лицо, заинтересованное в финансовых и иных результатах проекта. Данным лицом может быть акционер, кредитор, член органа управления, сотрудник компании, клиент, орган государственной власти, общественная организация, а также другое лицо, заинтересованное в реализации/нереализации проекта.
Управление проблемами – это процедура выявления, регистрации и разрешения проблем, а также минимизации их влияния на цели и качество выполняемого проекта.
Управление проектом – методология организации, планирования, руководства, координации трудовых, финансовых и материально-технических ресурсов на протяжении жизненного цикла проекта, направленная на эффективное достижение его целей путем применения современных методов, техники и технологии управления для достижения определенных в проекте результатов по составу и объему работ, стоимости, времени, качеству и удовлетворению участников проекта.
Участники проекта — все сотрудники Заказчика и Исполнителя, работающие над проектом, включая органы управления проектом.
Результат заполнения данного поля оформляется в виде таблицы с полями:
Роль в проекте – ФИО — Функции, выполняемые в проекте – Примечание
В случае дальнейшего разбиения промежуточных результатов этапы могут разбиваться на подэтапы.
Если результат одного этапа необходим для реализации другого этапа, то такие этапы могут исполняться только последовательно. В противном случае этапы могут исполняться параллельно, независимо друг от друга.
Указываются как этапы проекта, так и их результаты, подлежащие приемке при его завершении (документы, организационные схемы, изделия, модели и др.).
Результат заполнения данного поля оформляется в виде таблицы с полями: № — Документы – Проектная роль 1 – Проектная Роль 2 — …
Общую ответственность за управление процессом решения проблем проекта несет руководитель проекта.
Принятые проблемы рассматриваются на совещаниях по проблемным вопросам.
Ответственный сотрудник разрабатывает план мероприятий по решению проблемы и согласовывает его с руководителями проекта.
Причины инициации проекта:
Ограничения проекта и допущения проекта:
Основные элементы устава проекта
Описание проекта — включает характеристики продукта, в том числе спе¬цификации, изменения или другие ключевые параметры.
• Стратегический план. В стратегическом плане представлена важ¬ная информация об основном направлении развития компании. Ме¬неджер проекта должен рассматривать эти данные с позиции своих не¬посредственных целей и задач. Например, если компания в течение следующего года планирует открытие новых офисов в трех городах Ев-
ропы, а проект направлен на модернизацию сети, общий план проекта составляется с учетом последствий возникновения новых представи¬тельств.
Стратегический план — описание долгосрочных целей и планов органи¬зации.
Устав проекта и концептуальная документация имеют много общего, но устав всегда составляется более подробно и детально. Все проектные доку¬менты содержат раздел «Общая информация», где указаны название проек¬та, номер, дата, имя автора, оставлено место для даты корректировки доку-мента или номера копии. Остальные разделы устава включают следующие информационные блоки.
• Требования — на данной стадии формулируются проектные требова¬ния первого порядка. Их можно рассматривать как более подробную характеристику промежуточных результатов проекта, так как они представляют конкретные данные по ожидаемым результатам. Деталь¬но эта тема будет рассмотрена в главе 4 «Определение целей проек¬та». В этом разделе необходимо перечислить требования и ожидания потребителей, куратора, заинтересованных сторон, а также возможно¬сти их удовлетворения.
• Коммерческое обоснование — в уставе полезно еще раз сформулиро¬вать коммерческое обоснование проекта, сопроводив его финансовым обоснованием, например данными о прибыли на инвестиции. Конфи¬денциальная документация не имеет официальных подписей заинтере¬сованных сторон, а устав заверяется всеми руководителями высшего звена (вскоре мы рассмотрим значение данного этапа работы), поэто¬му коммерческое обоснование, содержащееся в концептуальной до¬кументации, можно скопировать в устав проекта. Не забывайте, что в данном разделе излагается проблема или вопрос, которые должны быть решены посредством осуществления проекта, а также описание преимуществ инициации проекта и отрицательных последствий для организации в случае отказа от него. (Совет: скопируйте текст из Опи¬сания работ, приведенного в концептуальной документации.)
• Оценка затрат и ресурсов — если в вашем распоряжении имеется предварительная оценка затрат, включите ее в данный раздел. Здесь также приводятся сумма расходов на ТЭО (если оно подготовлено) и стоимость предлагаемых альтернатив. Разработкой детального бюд¬жета проекта и управлением ресурсами мы займемся позже, на этапе планирования.
• Функции и обязанности — раздел включает сводную таблицу функций и обязанностей, аналогичную табл. 3.3, с именами участников и указа¬нием их должностей. Помните: в проекте работают только один менед¬жер и один куратор, но существует множество позиций для функцио¬нальных менеджеров, поставщиков, потребителей и т. д. Именно этот раздел предоставляет вам официальные полномочия инициировать проект и обеспечивать проектные ресурсы.
• Подписи участников — это один из самых важных разделов устава. Здесь должны стоять подписи куратора, основных заинтересованных сторон, высшего руководства, потребителей, а также всех уполномо¬ченных лиц.
Если вы уже наметили некоторые промежуточные результаты проекта, перечислите их в соответствующем разделе, включив также предварительный график выполнения. Но, исходя из собственного опыта, хочу предупредить, что на данной стадии работы поэтапные планы не бывают точными и могут обратиться против вас, если заинтересованные стороны склонны проявлять особую дотошность. Скорее всего, вы услышите что-то вроде: «В проекте ука¬зана такая-то дата, и я хочу, чтобы вы соблюдали все оговоренные сроки». Тем не менее примите к сведению, что заинтересованные лица иногда требуют предоставить им предварительный график. Следовательно, список ожидае¬мых промежуточных результатов или «контрольных событий» первого поряд¬ка, относящихся к проекту, с указанием предположительных сроков выполне¬ния должен быть всегда наготове. Не забудьте особо отметить, что сроки являются предварительными, или ориентировочными, — называйте как хоти¬те. Главное, чтобы заинтересованные лица не потеряли дар речи от изумле¬ния, когда вы начнете менять эти сроки при планировании проекта.
Вполне возможно, что в концептуальной документации проект характеризу¬ется недостаточно, лишь в общих чертах. Менеджер проекта мог не прини¬мать участия в процессе отбора и/или не иметь отношения к составлению концептуальной документации. (Иногда подобные документы разрабатыва¬ются другим менеджером или заинтересованным лицом.) В таком случае он должен приложить дополнительные усилия, чтобы обеспечить наличие всей информации, необходимой для инициации проекта. Если этого не сделать, то впоследствии можно сильно пожалеть о своей небрежности.
Некоторая специфика подписания проекта
Устав проекта не может считаться завершенным без подписей уполномо¬ченных лиц, среди которых решающее значение имеют подписи куратора про¬екта, менеджера проекта, основных заинтересованных сторон, руководителей высшего звена, потребителей и других участников. При возникновении сомне¬ний в отношении состава подписантов следует посоветоваться с куратором.
Подписанию проекта придается такое значение потому, что подписи упол¬номоченных лиц являются гарантией того, что каждый из них ознакомился с уставом, понял цели и первостепенные задачи проекта. Подписи свидетель¬ствуют их одобрение и поддержку проекта. Это также означает, что вы можете рассчитывать на их содействие и участие в ключевых этапах работы.
Убедиться в том, что заинтересованные лица приняли устав и осознали значимость своих автографов, лучше всего путем проведения общего собра¬ния участников проекта. Если у них возникают вопросы или личные замыслы в отношении устава (проекта), сбор всех подписей может занять уйму време¬ни. Общее собрание дает возможность вам и всем участникам задавать любые вопросы, обсуждать планы, разрешать возникшие разногласия.
Без подписей куратора и основных заинтересованных лиц устав проекта не признается официальным документом. Подписи свидетельствуют согласие участников с данным документом и гарантируют их содействие в проектных мероприятиях.
Получив все необходимые подписи, нужно предоставить каждому подпи¬санту копию устава. Одновременно можно передать копии текста на рассмот¬рение оставшимся заинтересованным лицам, которые не подписывали доку¬мент. После раздачи копий текста начинается главное развлекательное мероприятие этапа инициации — организация и проведение установочного собрания. Но сначала рассмотрим образец устава, который пригодится для следующего проекта. Образец следует скорректировать с учетом потребно¬стей организации и вашей личной точки зрения. Да, и не забудьте: копия уста¬ва тоже хранится в папке журнала проекта. Если проектная документация представлена в интранете для всеобщего доступа, текст устава должен быть выложен и там.
Давайте соберем всю информацию в единый формат и посмотрим, как выглядит устав проекта. Как упоминалось выше, вы можете без каких-либо ограничений изменять этот шаблон в соответствии со своими задачами: на¬пример, вставить в верхний колонтитул логотип компании, использовать раз¬ные цвета или оттенки. Здесь представлен лишь остов документа, предназна¬ченный для того, чтобы дать представление об отчетной информации.
Пример Устава проекта
Привожу пример устава проекта, который явился результатом бесплатного экспресс-обследования. Он отличается по форме от рекомендуемого 1С. Но, для понимания того, что именно должно быть указано в этом документе – вполне достаточно. Как и для того, чтобы понять, стоит ли начинать такой проект.
Необходимо отметить, что удалённость разработчика систем ПП ХХХ затрудняет поддержку системы и в итоге делает невозможным получение из неё необходимой информации.
Данная ситуация приводит к несопоставимости данных в системах из-за влияния следующих факторов:
- Различные требования пользователей систем;
- Отличия в методологическом основании систем;
- Несовпадение нормативно-справочного наполнения систем;
- Ошибки при вводе данных и при составлении отчетности (человеческий фактор)
Это приводит к постоянной неопределенности при принятии управленческих решений менеджерами всех уровней.
Источник: https://topuch.ru/variant-oglavleniya-ustava-proekta/index.html