для чего нужен устав проекта
Управление интеграцией проекта. Управление содержанием проекта
Устав проекта
Устав проекта ( Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика.
Исходными документами для разработки Устава проекта внедрения ИС являются контракт и результаты предпроектного обследования, определяющие содержание работ по проекту. Результаты предпроектного обследования оформляются в виде отчета, включая описание бизнес-процессов верхнего уровня.
Устав проекта содержит следующую информацию:
1. Название проекта.
2. Бизнес-цели компании или причины возникновения проекта.
Формулировка причины фактически дает ответ на вопрос » Зачем выполняется данный проект?».
Цели проекта определяют, что должно быть выполнено, и описывают конечный результат проекта. В Уставе проекта приводится цель проекта как результат, ожидаемый Заказчиком и полезный для него. Цель формулируется совместно Заказчиком и Исполнителем.
При формулировании цели руководитель проекта должен контролировать ее соответствие контракту, в рамках которого будут выполняться работы по проекту.
Формулировка целей должна соответствовать следующим критериям ( SMART- Specific, Measurable, Achievable, Relevant, Time-bound ):
Результаты проекта должны соотноситься со спецификацией контракта, в рамках которого будут выполняться работы по проекту.
Примеры формулировок целей:
Границы проекта определяют в целом то, что включается в проект. Необходимо явно указывать, что не включается в проект (таблица 4.2), чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект.
Указываются территориально удаленные объекты, подлежащие автоматизации.
| Раздел функциональности | Процессы, не подлежащие реализации |
|---|---|
| Организационный менеджмент | Формирование фонда заработной платы по специфичным методикам. Система оповещения по функциям Управления персоналом в целом. Ведение аттестации рабочих мест, вредных условий труда |
| Администрирование персонала | Ведение параллельных данных на английском языке |
| Учет рабочего времени | Фактический учет рабочего времени (будет использоваться негативный учет). Учет рабочего времени по заказам/объектам. Учет работы во вредных условиях |
| Расчет зарплаты | Сдельная система оплаты труда |
5. Содержание проекта (задачи проекта).
Содержание проекта отвечает на вопрос «Какую конкретную работу нужно выполнить для достижения поставленных целей?» или «Какие задачи необходимо решить для достижения поставленных целей?». Содержание может быть получено от Заказчика в качестве составляющей тендерной документации.
Пример описания содержания (задач) проекта
Требования к бизнес-процессам должны включать:
Чудо-бумажка, или зачем нужен устав проекта и как его написать
Устав проекта (Project Charter) – это документ, который обычно готовит руководитель проекта после получения вводных о проекте.
Зачем нужен устав проекта
Устав содержит основные характеристики проекта и согласуется основными заинтересованными лицами (как минимум – Заказчиком и Спонсором проекта). Как правило, разработка и подписание Устава несет в себе 3 основные функции:
Иногда устав проекта используется для оценки выгод от его реализации и принятия решения о запуске. Хотя это не соответствует классической методологии, по которой устав готовится только для уже оцененного и утвержденного к реализации проекта.
Важно! Начинать работу по проекту без подписанного устава – это самая плохая услуга, которую можно оказать самому себе как руководителю проекта. Не определив и не согласовав цели и содержание того, что вы будете делать, вы рискуете очень быстро оказаться в ситуации, когда сроки прошли, бюджета закончился, сделано «не то и не там», а ваша карьера РМа в этой Компании бесславно закончилась. Более того, подписание устава у заинтересованных сторон – это отличный индикатор того, действительно ли они заинтересованные или просто делают вид. В случае, если проект спущен «сверху», Спонсор назначен, а Заказчик и сам не понимает, зачем ему это нужно – лучше постараться с этого проекта ноги унести, а если не получится – по крайней мере осознать, как не остаться в результате единственным виноватым за неуспех (об этом мы еще поговорим).
Как написать устав проекта
Содержание устава проекта часто зависит от специфики Компании. В качестве примера можно привести следующий набор разделов устава:
Пример из жизни! Давайте сделаем очень короткий устав проекта «Ремонт в квартире», как образец, а то теория – это хорошо, но не всегда понятно:
Ну и напоследок. Меня часто спрашивают, насколько детальным должен быть устав проекта? Точного рецепта здесь нет, но в общем случае – детализация устава проекта должна быть такой, чтобы в случае какого-то серьезного запроса на изменение в проекте вы могли обратиться к уставу как к истине в последней инстанции и сказать «нет, мы это не делает, т.к. это не приближает нас к цели проекта или противоречит характеристикам результата». По большому счету, если проект дошел до такого состояния, что запросы на изменение с уставом уже не «бьются» – похоже, ваш проект закончился неудачей и его лучше закрыть, требования и ограничения пересмотреть и начать новый.
Мораль: устав даже на 1 страничке А4, подписанный заинтересованными лицами, лучше чем неподписанный на 5 страничках. И требование подписать его до начала работ со стороны РМа полностью законно в любой компании, более того – это прибавляет вам профессионального веса, позволяет понять «а чего же мы все-таки делаем» и получить хоть какие-то полномочия. Если управление проектами в компании отсутствует как класс, то даже неподписанный устав лучше чем его отсутствие, вы хотя бы разберетесь, что делать, и настроитесь на правильный лад с самого начала проекта (да простит меня РМВОК).
Конечно, в уставе проекта могут быть и другие пункты в зависимости от специфики проекта, в посте перечислен “кандидатский минимум”, сам документ можно и нужно переделывать под себя.
Всего за 99 руб вы можете скачать готовый детальный шаблон устава ИТ-проекта в docx. В готовом примере устава проекта вы найдете все необходимые пункты – от содержания проекта и описания ролей и обязанностей участников проекта до перечня типовых рисков. После оплаты на почту вы получите архив с шаблоном. Сэкономьте свое время, оно стоит намного дороже!
Скачайте готовый пример устава проекта и начните работать прямо сейчас вместо траты нескольких часов на поиск и написание типовых разделов.
Купить готовый шаблон Устава за 99 руб.
Рекомендуем! Также з а 249 руб вы можете скачать набор из трех разных готовых шаблонов уставов ИТ-проектов в docx, в том числе – два расширенных примера готовых уставов проектов (для работы с подрядчиком/заказчиком) и один сокращенный пример готового устава проекта (для внутренних проектов). Набор примеров уставов поможет вам создать на их основе именно тот устав вашего проекта, который нужен именно вам!
Управление интеграцией проекта. Управление содержанием проекта
Устав проекта
Устав проекта ( Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика.
Исходными документами для разработки Устава проекта внедрения ИС являются контракт и результаты предпроектного обследования, определяющие содержание работ по проекту. Результаты предпроектного обследования оформляются в виде отчета, включая описание бизнес-процессов верхнего уровня.
Устав проекта содержит следующую информацию:
1. Название проекта.
2. Бизнес-цели компании или причины возникновения проекта.
Формулировка причины фактически дает ответ на вопрос » Зачем выполняется данный проект?».
Цели проекта определяют, что должно быть выполнено, и описывают конечный результат проекта. В Уставе проекта приводится цель проекта как результат, ожидаемый Заказчиком и полезный для него. Цель формулируется совместно Заказчиком и Исполнителем.
При формулировании цели руководитель проекта должен контролировать ее соответствие контракту, в рамках которого будут выполняться работы по проекту.
Формулировка целей должна соответствовать следующим критериям ( SMART- Specific, Measurable, Achievable, Relevant, Time-bound ):
Результаты проекта должны соотноситься со спецификацией контракта, в рамках которого будут выполняться работы по проекту.
Примеры формулировок целей:
Границы проекта определяют в целом то, что включается в проект. Необходимо явно указывать, что не включается в проект (таблица 4.2), чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект.
Указываются территориально удаленные объекты, подлежащие автоматизации.
| Раздел функциональности | Процессы, не подлежащие реализации |
|---|---|
| Организационный менеджмент | Формирование фонда заработной платы по специфичным методикам. Система оповещения по функциям Управления персоналом в целом. Ведение аттестации рабочих мест, вредных условий труда |
| Администрирование персонала | Ведение параллельных данных на английском языке |
| Учет рабочего времени | Фактический учет рабочего времени (будет использоваться негативный учет). Учет рабочего времени по заказам/объектам. Учет работы во вредных условиях |
| Расчет зарплаты | Сдельная система оплаты труда |
5. Содержание проекта (задачи проекта).
Содержание проекта отвечает на вопрос «Какую конкретную работу нужно выполнить для достижения поставленных целей?» или «Какие задачи необходимо решить для достижения поставленных целей?». Содержание может быть получено от Заказчика в качестве составляющей тендерной документации.
Пример описания содержания (задач) проекта
Требования к бизнес-процессам должны включать:
Новый взгляд на устав проекта
Участие в подготовках уставов проектов натолкнуло на мысль, что классическое его содержание мало способствует успешной реализации.
На мой взгляд к уставу проекта стоит подходить как документу, описывающему будущую проектную деятельность. Устав должен определять принципы работ. По аналогии с уставом воинской службы необходимо определять права и обязанности участников проекта, а также правила внутреннего порядка.
Целями проекта являются не только создание продуктов и получение прибыли. Многие компании стремятся извлечь и накопить опыт, который позволит ускорить и упростить реализацию последующих проектов. Поэтому в уставе важно закреплять принципы, по которым будут накапливаться и ошибки, и правильные решения.
Возвращаясь к участникам проекта, помимо прав и обязанностей важно определить и условия ответственности. К примеру спонсор проекта отвечает за своевременное финансирование. В случае нарушения сроков оплат какие предусмотрены санкции и в чем они будут выражаться? В деньгах или в днях? Тоже касается и менеджера проекта перед спонсором. В чем заключается его ответственность и в чем она выражается? Ответственность нужно разделить и внутри команды, последовательно отвечая на вопросы: «кто? за что? чем и перед кем отвечает?» © В. Жандаров
Правила внутреннего порядка должны содержать принятые в команде нормы этики и принципы совместной работы. Нормы этики — это не только про уважение и справедливость, но и про честность. Правду говорят только тому, кому можно говорить. К принципам совместной работы относится принцип результата: «Смысл любой деятельности не в процессе, а в конечном результате», принцип ответственности «Объяснения и оправдания никому не нужны, отвечай за свои действия и за свое бездействиеJ» © А. Макаров
К аспектам успешной деятельности помимо социальной направленности и получения прибыли еще относится и экологичность. Забота о поддержании природной гармонии и стремление ничего не нарушить должно быть одним из главных приоритетов проекта.
Сложно сходу представить содержание и объем подобного устава. Стоит начинать с логической схемы, которую приведу чуть позже. «Правильное предварительное планирование предотвращает плохие показатели». Разработка устава, описывающего не только проект, но и проектную деятельность, относится на 100% к правильному планированию😀
Разработка устава проекта. Методическое пособие
Искусство управления проектом заключается в том, чтобы неведомое сделать предсказуемым. И чем раньше выявятся подводные камни – тем больше шансов не нахлебаться воды.
Устав проекта – это документ, который формализует ключевые договоренности по всем измерениям проекта между его участниками. Он разрабатывается в ходе инициации проекта – до решения о его начале.
Устав проекта определяет каркас проекта в 5 измерениях:
- ЦЕЛИ и ТРЕБОВАНИЯ ЗАДАЧИ РИСКИ УЧАСТНИКИ ПРАВИЛА
Также может добавляться еще шестое измерение – РЕСУРСЫ (бюджет и иные).
И хотя на этапе инициации проекта, пока не выполнено детальное планирование, точно определить потребность в ресурсах довольно сложно, вполне возможно выявить ограничения по ресурсам, которые придется учитывать при планировании.
Чтобы определить каркас проекта в этих измерениях необходимо:
На практике результаты выполнения этих задач могут фиксироваться в разных документах, таких как: договор, устав проекта, план управления рисками, техническое задание. Структура и объем каждого документа, а также распределение по ним этих данных определяется спецификой каждой компании и зависит от выбранной методологии и технологии управления проектами. При использовании современных технологий управления проектами эти документы не разрабатываются самостоятельно, а генерируются как отчеты на основе единой проектной базы, содержащей трассируемые данные по всем измерениям проекта.
Устав проекта может быть как внутренним документом, так и документом, согласуемым с внешними сторонами проекта, фактически выполняя роль контракта между заказчиком и исполнителем. Последний подход чаще используется зарубежом.
Успешной команде нужна разработка устава проекта — «прощупать» проект, пока корабль еще не укомплектован и не отошел от берега. И важен не сам документ, а те задачи, которые придется решить, чтобы наполнить его смыслом.
Рассмотрим подробнее эти задачи.
Для описания задач воспользуемся методологией функционального моделирования IDEF0.
Модель процесса разработки устава проекта
Цель моделирования: показать основные этапы, необходимые для начала проекта, их взаимосвязь и результаты, приводящие к формированию отчетного документа «Устав проекта», а также определить основные требования к процессу разработки устава проекта и требования к содержанию устава проекта.
Точка зрения: Руководитель проекта.
Контекст: Для того, чтобы показать место процесса по разработке устава проекта и самого устава проекта в жизненном цикле проекта, контекстная диаграмма А0 соответствует процессу выполнения проекта в целом и затем детализируется на отдельные этапы. Данная модель не противоречит PMBOK 4, но обладает большей детализацией с точки зрения процесса разработки устава проекта.
Допущения: Процесс подготовки и выполнения проекта итеративен и многие задачи часто выполняются в параллель, поэтому приведенное в модели разбиение на этапы отражает информационные зависимости между процессами, но не означает, что процессы всегда выполняются в такой последовательности.
На диаграммах А0-А1 (рисунок 1 и 2) отражен контекст интересующего нас процесса.
Предполагается, что в организации есть корпоративный стандарт управления проектами, в котором определены основные правила ведения проектов. В этом случае в уставе проекта вводятся ссылки на данный стандарт и указываются только те данные, которые являются специфичными для выполняемого проекта. Если такого стандарта нет, это означает, что такие правила нужно определять каждый раз индивидуально для каждого проекта.
Обычно работы по проекту начинаются с получения каких-то исходных данных, будь-то брошенная вскользь идея заказчика или формализованное ТЗ на 200 страниц. С этих исходных данных и предстоит начать «разматывать клубок» в ходе разработки устава проекта.
Рисунок 1. Контекстная диаграмма А0
Разработка устава проекта (см. рис 2) является подготовительным этапом и по его результатам принимается решение об инициации проекта. Важность этого этапа сложно переоценить, т.к. от него зависит «быть или не быть» проекту. Кстати, те, кто пропускают этот этап в начале проекта, в итоге вынуждено возвращаются к этому вопросу позже, уже израсходовав некоторую часть ресурсов двух организаций.
Если проект инициирован, то собранные в ходе разработки устава проекта высокоуровневые данные по всем 5(6) измерениям проекта должны быть детализированы на следующих этапах. Устав проекта является руководящим документом для последующих этапов, что и отражено на диаграмме А1 на рисунке 2.
Рисунок 2. Диаграмма А1 «Выполнить проект»
При этом стоит помнить, что изменение ключевых ограничений проекта, отраженных в уставе, может существенно изменить картину по всем измерениям – начиная от требований, заканчивая сроками и бюджетом. Это может испугать неопытных руководителей и увести от проведения измений в явном виде. Однако суть от этого, конечно, не переменится – если изменения есть, их лучше зафиксировать и довести до участников проекта.
Введенные на первых двух диаграммах потоки, определены в таблице ниже.
Таблица 1. Потоки данных для А0-А1
| Имя потока | Определение потока |
| Данные проекта | * данные, дополнительные к исходным данным, которые были получены в ходе разработки устава проекта * |
| Исходные данные проекта | * любые исходные данные, полученные до организации проекта. Это могут быть требования заказчика, данные о предметной области проекта и др. * |
| Корпоративный стандарт УП | * стандарт предприятия, определяющий требования к процессам управления проектами. Может включать правила выполнения, детальное описание процессов, шаблоны документов. Степень детализации определяется в рамках каждого предприятия. Данный стандарт может являться частью стандартов СМК * |
| Корректировки | * предложения по изменению проекта * |
| План проекта | * оперативный план проекта с назначенными ресурсами, на основании которого выполняются работы * |
| Проектная база или редактор | * инструмент для разработки проекта, в зависимости от выбранной технологии управления проектом – документоориентированной или ориентированной на данные * |
| Результаты проекта | * все результаты, полученные в ходе выполнения проекта * |
| Руководитель проекта | * лицо со стороны исполнителя проекта, отвечающее за координацию и исполнение проекта * |
Далее нас интересует детализация процесса «Разработать устав проекта»:
Рисунок 3. Диаграмма А1.1. «Разработать устав проекта»
Прежде чем разбирать сам процесс необходимо познакомиться с определениями потоков данных:
Таблица 2. Потоки данных для А1.1
| Имя потока | Определение потока |
| Заинтересованные стороны | * стороны и лица, которые принимают решения или оказывают влияние на лиц, принимающих решения относительно хода проекта. Под сторонами подразумеваются организационные структуры, участвующие в проекте, под лицами — конкретные персоны, принадлежащие или нет данным организационным структурам. * |
| Критерии SMART | * требования к формулированию целей * |
| Критерии отсева проектов | * правила определения проектов, которые не должны браться в работу * |
| Орг-структура проекта | * организационная структура проекта * |
| Система целей проекта | * согласованная система целей проекта и ожиданий заинтересованных лиц, включающая измеряемые показатели и критерии достижения целей * |
| Стратегический план проекта | * включает основные этапы и результаты проекта, методы контроля хода проекта, риски проекта * |
| Правила детализации СП | * корпоративные правила детализации (декомпозиции) задач и результатов стратегического плана * |
| Правила взаимодействия | * корпоративные правила организации взаимодействия с заказчиком и внутри проекта, например, время отклика на запрос * |
| Правила оформления УП | * корпоративные правила оформления отчетного документа «Устав проекта» * |
Первоочередная задача подготовки и оценки проекта – понять и определить систему целей. Все цели проекта должны быть взаимоувязаны, даже те, которые невозможно зафиксировать в явной форме. Выявление и согласование целей – сложная задача, результаты которой определяют его успех или провал [1]. Чаще всего она не решается «с наскока», а некоторые важные цели мимолетно всплывают и тонут в несущественных деталях, подменяясь на составляющие их подцели. Задача руководителя проекта – держать в фокусе максимально полную картину, начиная с самого верхнего уровня.
На диаграмме процесса A.1.1.1, раскрывающей процесс «Выявить и проработать систему целей проекта» показано, что выявление целей проекта начинается с определения их источников — сторон и лиц, оказывающих влияние на ход проекта: кто принимает решения о проекте, кто принимает решение о приемке продукта, кто оказывает на него хоть какое либо влияние, пусть даже косвенное. Система целей проекта должна быть согласована с их ожиданиями. Противоречия целей проекта и ожиданий заинтересованных сторон неизбежно приводят к конфликтам как в ходе проекта, так и на этапе его сдачи. Поэтому за процессом разработки иерархии целей проекта стоит важная задача согласования целей проекта и ожиданий заинтересованных сторон. Этот процесс необходимо будет продолжить при подборе команды проекта (процесс «Спроектировать организационную структуру проекта»), которая также определяет ход проекта.
Рисунок 4. Диаграмма процесса A.1.1.1 «Выявить и проработать систему целей проекта»
Обычно цели проекта организуются в одну или несколько иерархий. Это означает, что для каждой цели верхнего уровня должны быть определены конкретные задачи, за счет выполнения которых предполагается достигнуть цели проекта. Например, если цель верхнего уровня — снизить затраты на изготовление продукции, то она может быть достигнута различными путями — снижением заработной платы, накладных расходов, автоматизацией производства и т.п., но это не значит, что в проекте будут использованы все способы, поэтому необходимо указать конкретные способы достижения цели, выбранные для данного проекта. Этот процесс также помогает оценить достижимость выбранной цели.
Эта сложная задача часто игнорируется, что приводит к неуспешным проектам и отражено в известной статистике ИТ- отрасли [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
| Имя потока | Определение потока |
| Офиц. коммуникации проекта | * признанные каналы (e-mail, телефон, личная встреча, автоматизированная система) и формы передачи (форма сообщения, необходимость подписей) официально подтверждаемой информации. * |
| Роли и области ответственности | * роль описывается набором функций, выполняемых ролью, а также процессами, за успешное выполнение которых она отвечает * |
| Участники проекта и их роли | * список участников проекта, в котором для каждого участника указывается его роль в проекте * |
| Орг. структура проекта | * организационная структура проекта * |
Когда все элементы каркаса собраны, еще раз оценивается его жизнеспособность и реализуемость проекта.
Заключение
Разработка устава проекта — это подготовительный этап, от результата которого зависит успех проекта. Структуру устава проекта хорошо использовать как справочник и чек-лист для оценки возможности успешно завершить проект. А вопросы, которые будут возникать в ходе разработки устава, позволяют на раннем этапе выявить и устранить конфликты и даже своевременно принять решение о закрытии проекта, если станет очевидным, что цели проекта недостижимы в текущих условиях.
Отношение к уставу проекта, как к простой формальности, отражает непрофессиональный взгляд на процессы управления проектами и вскрывает непонимание процессов, которые стоят за разработкой данного документа.
В рассмотренной схеме процессов показаны информационные связи между процессами. Выполнение процессов без их учета, хотя и часто встречается на практике, приводит к несогласованным результатам. В таких случаях необходимо проводить дополнительные итерации согласования результатов каждого этапа.