Группа процессов инициации проекта. Устав проекта требования к уставу проекта

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

Инициация проекта начинается с зарождения идеи до принятия решения о его реализации. Инициация проекта — это:

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

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

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

  • 1) two minute lift rule (правило двух минут в лифте). Разработчику идеи требуется представить, что он находится в лифте с инвестором и попытаться сформулировать то, что должно убедить инвестора вложить свои средства, располагая двумя минутами;
  • 2) one pint rule (правило одной пинты). Разработчику идеи требуется попытаться убедить инвестора в сжатый срок.
  • Инициирование проекта по существу — выбор и обоснование его необходимости. Проекты инициируются в силу разных причин, например, возникновения потребностей, которые нужно удовлетворить, или необходимости решить проблемы организации.

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

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

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

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

    Устав проекта — это:

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

    В уставе проекта указываются:

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

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

      В данной статье разберем такой важный документ для проектного управления, как Устав проекта. Рассмотрим, что это за документ. Кто и для чего его создает? На каких проектах он необходим? А на каких можно без него обойтись?

      1. Запуск нового проекта. Что такое устав проекта и для чего он нужен

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

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

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

      Руководство PMBOK разъясняет, что процесс реализации проектов начинается с создания Устава. В данном документе дано четкое определение начала проекта и границ проекта, создание формальной записи о проекте и прямой способ для высшего руководства формально принять проект и приступить к нему. В российских условиях к Уставу проекта прилагается Приказ о начале проекта, который формально его запускает в работу.

      Разработка и утверждение документа

      Устав проекта могут разрабатывать: менеджер проекта или команда проекта; инициатор проекта; спонсор проекта; представитель внешней стороны (подрядчик проекта).

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

      2. 1С Проектное управление: из чего состоит устав проекта

      Краткое содержание Устава проекта

      Типовой устав проекта содержит следующие пункты:

      · Термины и определения

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

      · Краткое резюме проекта: наименование и участники проекта, ответственность сторон, сроки начала и окончания проекта

      · Содержание проекта: цели, задачи и результат проекта

      · Заинтересованные стороны проекта

      · Параметры проекта: оценка стоимости и сроков

      · Допущения и ограничения: функциональный, организационный и методологический объем проекта

      · Организационная структура проекта: орг. структура, роли и обязанности сторон; выделение ресурсов (сотрудников) на проект

      · Управление качеством: процедура рецензирования документов; процедура утверждения результатов проекта

      · Ключевые документы проекта: план-график работ по проекту; формат протокола интервью (встречи); протокол сдачи-приемки результатов работ; статус-отчет о проекте

      · Условия выполнения проекта

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

      3. Когда для реализации проекта необходимо создавать Устав

      В каких случаях не нужен Устав проекта

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

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

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

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

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

      Нет смысла готовить Устав проекта, если у компании-заказчика имеется единственный внешний исполнитель, он же подрядчик и сотрудники компании заказчика слабо задействованы в данном проекте. В этом случае все значимые моменты, указанные в пункте Содержание Устава проекта (см. выше) находят отражение в договорных документах, подписываемых с Подрядчиком.

      В каких случаях нужен Устав проекта

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

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

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

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

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

      · У менеджера проекта достаточно полномочий, а проекта — ресурсов;

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

      · Четко описаны цели и задачи проекта, с учетом долгосрочных целей компании.

      Подводя итоги, нужно отметить, что Устав, как отдельный документ, нужен для проектов:

      · Длительных (от 2-3 месяцев) – вероятность наступления рисковых событий становится более 50%. В этом случае нужно описать риски проекта, а также процедуры управления риском.

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

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

      · Сложных по содержанию (как правило многие IT-проекты), значительно меняющих бизнес-процессы компании-заказчика – возникают особые требования к контролю качества работ (получаемых результатов), соответственно есть необходимость в описании данных процедур, что не всегда можно сделать в рамках договора (если он вообще есть).

      · Дорогих по стоимости (критерий субъективный) – нужна оценка стоимости и сроков проекта, а также прозрачные процедуры управления изменениями и урегулирования спорных моментов. Чтобы компания не понесла убытков от проекта или вовремя его прекратила.

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

      4. Комментарии по содержанию Устава проекта

      Обычно есть прямое указание, что данный документ является обязательным к использованию в рамках данного проекта, и имеет более высокий приоритет, чем другие внутренние нормативные документы предприятия — «исполнение положений Устава обязательно всеми членами Рабочей группы Заказчика и рабочей группы Исполнителя».

      «Изменения в документ вносятся в соответствии с процедурой управления изменениями». «Изменения могут быть вызваны изменением целей, масштаба проекта, методики работы, организационной структуры проекта…».

      Краткое резюме проекта

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

      · основания для привлечения сторонних подрядчиков – юридических лиц (ссылка на договора подряда/оказания услуг).

      Также в этом пункте подробно расписывается ответственность Заказчика, Исполнителя и других выделенных участников проекта – «Заказчик отвечает за …», «Исполнитель отвечает за . »

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

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

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

      «Заинтересованная сторона — лицо, группа или организация, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта».

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

      Под заинтересованными сторонами обычно подразумеваются сотрудники со стороны Заказчика, Исполнителя. Информация обычно представляется в таблице (см. Таблица 1)

      Таблица 1 — Заинтересованные стороны проекта

      Параметры проекта: оценка стоимости и сроков

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

      Оценка по срокам (см. Таблица 2) указывается на основании календарно-ресурсного плана проекта, который может быть оформлен в виде приложения к договору оказания услуг. Важно для целей проекта указать – вехи проекта

      Таблица 2 — Пример оценки по срокам

      Допущения и ограничения: функциональный, организационный и методологический объем проекта

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

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

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

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

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

      В данном пункте стороны описывают процедуры:

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

      2. Обеспечения качества (по ходу проекта) – процедуры проверки соблюдения требований к качеству для обеспечения использования соответствующих стандартов качества.

      3. Контроль качества (по ходу проекта) – «мониторинг и документирования результатов действий в области качества для оценки исполнения и вынесения рекомендаций относительно необходимых изменений».

      Проектные процедуры: организационные процедуры; процедура управления изменениями; процедура управления рисками; процедура урегулирования спорных вопросов

      Данные пункты Устава проекта важны, т.к. позволяют значительно снизить риски неуспешного завершения проекта из-за изменений:

      · Состава работ, либо перечня услуг;

      · Сроков Проекта, отраженных в Договоре;

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

      Устав проекта — это «скорлупа яйца». Курс по управлению проектами, часть 5

      Продолжение моего учебного курса по проектному управлению. Предыдущие материалы:

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

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

      Представьте, что вы с мальчишками после школы решили поиграть в футбол. Сидите и ждете, когда прозвенит звонок с последнего урока, чтобы выйти на школьный двор и погонять мяч. Допустим, мяч у вас есть, звонок прозвучал, вы собираете поиграть. Вы разбились на команды, у вас есть мячик, поле. Чего не хватает? Ворот, конечно. Но поскольку это школьный футбол, то ворота обычно делают из двух портфелей. Все, можно играть. И обычно игра начинается сразу, как только принесли мячик и сделали ворота. Чего ждать-то? Уроки закончились, давно хочется начать игру. А дальше, как это часто бывает, каждые полторы минуты мяч улетает в соседний двор. И двое ребят – по одному из каждой команды – убегают за мячом и долго гоняют по соседнему двору, продолжая бороться за мяч. Потом через несколько минут усталые и довольные возвращаются, а все остальные в это время стоят и ждут. Мячик отсутствует всего несколько минут, но эти минуты очень сильно портят игру всем остальным. Потому что, когда несколько минут ты играешь в футбол, время быстро пролетает, а когда ты ждешь, то кажется, что время идет очень долго. И такая борьба двух мальчишек за пределами импровизированного поля всех раздражает.

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

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

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

      Что пишут в правилах? Это очень лаконичный документ, в котором половину занимают наглядные картинки, а вторая половина посвящена описанию игры.

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

      Что не пишут в правилах и уставе, соответственно? Подробные установки на игру. Например, не описывают, что ты пойдешь на третьей минуте на середину поля, на 3,5 минуте дашь пас к воротам, потом вернешься, а на 4-ой минуте снова отправишься на середину поля. Таких деталей в уставе быть не должно.

      Еще раз: устав – это документ, в котором фиксируют только неизменные аспекты. Установки для команды в нем не описаны, только правила игры.

      Кто формирует устав проекта? Чаще всего это менеджер проекта и спонсор, потому что у них договор о реализации проекта. Причем, формирует, пишет устав менеджер, а спонсор, скорее, его утверждает. А как участвует заказчик? В PMBoK предлагается, чтобы заказчик тоже участвовал в этом процессе, но есть оговорки.

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

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

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

      Если спонсор указал конкретные сроки, менеджеру ничего придумывать не надо. Задача менеджера проекта — услышать, чего хочет спонсор.

      2. Деньги. Как и сроки, этот раздел не подлежит изменению после начала проекта. По правилам классического проектного управления, если возникла необходимость внести изменения в любой раздел Устава, то надо перезапускать проект. Если вы разрешите футболистам играть с мячом руками, это уже не совсем футбол. Надо остановить игру, и начать новый матч, по новым правилам. Устав меняться не может, поэтому и сроки, и деньги описывают очень коротко и в терминах «не позже чем», «не больше чем». Например, строим 9-этажный дом в течение года. Тогда срок записывается так: «не больше чем 12 месяцев». А бюджет – «не больше 1 млн долларов». То есть это какие-то рамки, за которые ни в коем случае нельзя выйти, иначе проект теряет смысл.

      3. Цель. Очень часто в уставах пишут плохие цели. Например, проект по созданию и внедрению IT-системы. Цель – “создать и внедрить IT-систему”. Жуть. Самосбывающаяся цель. Нельзя копать яму, с целью копать яму. КОпать яму для чего-то. Чтобы что-то произошло. Цель создания и внедрения ИТ-системы не “создать и внедрить”, а в чем-то еще. Проверяйте свои цели внимательно (среди них часто попадаются очень слабые).

      4. Содержание. Записывает очень коротко, буквально в пяти абзацах. Больше – вряд ли найдется. Содержание описывается в терминах «что делаем» (продукт проекта), «что не делаем» (исключено из проекта). Допустим, 9-этажный дом строим, но придомовую территорию не облагораживаем.

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

      И еще: объем устава не зависит от размера проекта. Не важно, строите вы газопровод или делаете IT-систему. Все равно ключевых неизменных аспектов мало.

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

      6. Команда, ресурсы. У вас ресурсы могут быть выражены в деньгах, которые позволят нанять людей и закупить нужные вещи. А могут быть выражены в конкретных людях. То есть вам могут выделить на проект конкретное количество людей.

      Если у вас ресурсы в людях, то в уставе, как в неизменном документе, необходимо указать только тех людей, без которых проект невозможен. Если уход специалиста не критичен, его фамилию можно не записывать в уставе. Но общее количество людей все равно надо указать, например, для проекта необходимо 5 электриков I разряда или 6 программистов определенного уровня. И когда есть договоренность со спонсором о количестве специалистов конкретного уровня, не обязательно перечислять какие-то фамилии.

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

      Теперь разберемся, как устав фиксировать: в электронном виде или на бумаге с подписью и печатями, в нескольких экземплярах?

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

      Почему не надо ставить печать на уставе? Представьте, что начальник обещал выделить ресурсы на проект, но не предоставил их. Вы пойдете жаловаться в Гаагский трибунал? Нет, конечно. Потому что устав – это внутренний документ, который за пределы компании никогда не выйдет. Он помогает не забыть, о чем договорились стороны.

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

      Обратите внимание. Если менеджер борется за реализацию проекта в рамках треугольника (время, деньги, содержание работ), то спонсор ходит по периметру треугольника, снаружи. И в приличном обществе он должен отгонять всех от проекта, в том числе самого себя. Что это значит? Это значит, что если он обещал команду в 15 человек, то пусть 15 и даст. 15, а не 12 или 14. Если в уставе были прописаны какие-то особые люди со сверхъестественной квалификацией — пусть спонсор даст именно их. Или пусть перезапускает проект, меняя сроки и содержание (да, нужен будет новый устав). Потому что если обещали 1 миллион долларов, а дали только полмиллиона, то построить такой же дом уже не получится. Так и с людьми. Ключевой аргумент российского менеджмента – «очень надо». Например, у вас команда из 10 человек, приходит спонсор и говорит, что ему очень нужны 3 из них. Резонно спросить: мы вообще делаем проект или нет. Если делаем – оставь команду в покое. Если тебе нужны люди, давай этот проект свернем и сделаем другой – поменьше.

      А теперь попробуем разобраться, в каких ситуациях нельзя показывать устав проекта заказчику. Ответ – в содержании устава, его разделах. Что может смутить заказчика?

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

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

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

      После того, как подписали устав, вышли из условного кабинета спонсора проекта и закрыли за собой дверь — вы теперь “главный”. Спонсор теперь ждет, когда появится результат проекта. Он свое дело сделал: задачу поставил, и ему не очень интересно, что дальше, он не будет бегать за вами. А дальше ваше дело, какие планы вы будете строить, как вы будете их строить. Вам решать как лучше планировать. Как мотивировать команду. Как проверять контрольные точки и так далее. Главное — попадите в устав, в треугольник, достигните цели и удовлетворенности ключевых заинтересованных сторон.

      Методологи придумали некий алгоритм. Они считают — если использовать его, то вероятность попасть в треугольник и удовлетворить ключевые ожидания повышается. Но никто, и даже PMI не считает это алгоритм “догматичным” и обязательным. Если нужно — переделывайте. “Допиливайте” под себя, дорабатывайте напильником. Нет идей как “допиливать” — попробуйте использовать в чистом виде. 🙂

      И первое, что начинает делать менеджер, – начинает работать с содержанием. Но об этом мы поговорим в следующих статьях.

      Данная статья написана на основании видео учебного курса по управлению проектами.

      Управленческое Документирование

      ISO21500-1INI3 «Устав проекта»

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

      Шаблон входит в состав комплекта документов для управления проектами и построения корпоративных стандартов УП на основе международного стандарта УП ISO 21500:2012 «Guidance on project management».

      В шаблоне ISO21500-1INI3 «Устав проекта»:

      1. Общие положения
      2. Нормативные ссылки
      3. Термины, обозначения, сокращения
      4. Назначение или обоснование проекта
      5. Цели и критерии успеха проекта
      6. Требования высокого уровня
      7. Описание проекта высокого уровня
      8. Риски высокого уровня
      9. Сводное расписание контрольных событий
      10. Сводный бюджет
      11. Требования к одобрению проекта
      12. Руководитель проекта
      13. Приложения

      Отзывов пока нет.

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

      Возможно Вас также заинтересует…

      ПМБОК12.2.1.4 «Предложения продавцов»

      ПМБОК12.1.3.3 «Закупочная документация»

      ISO21500-4RSR4 «Организационная диаграмма проекта»

      ПМБОК12.2.3.2 «Соглашение»

      Пн Вт Ср Чт Пт Сб Вс

      it.Projects — Курс управления IT-проектами

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

      03.06.2019 — 05.06.2019 @
      Navchal?nyy Tsentr Muk, Lobanovskyi Ave, 4Г, Kyiv, Ukraine, 02000

      pm.Startup — Управление Стартап Проектами

      06.06.2019 — 07.06.2019 @
      Aktsent Profi, Mykoly Shpaka St, 3, Kyiv, Ukraine, 03113

      У вас есть классная идея, которая изменит весь мир к лучшему – Это отлично! Вам повезло!
      Но нет денег на реализацию идеи… Беда! Ещё хуже, если вы убедили инвестора дать вам денег, и теперь нужно работать на возврат инвестиций, а не на развитие идеи и изменение мира…
      На самом деле, деньги для Стартап Проекта — это всего лишь один из ресурсов, и на первых этапах этот ресурс не самый важный. Главное – научиться привлекать те ресурсы, которые требуются для каждого этапа развития.

      Данный тренинг имеет второе название — «Ресурсы для стартапа». Используя технологии бутстрепа, бережливого стартапа и проектного менеджмента, участники тренинга пройдут от своей идеи до чёткого понимания — Как привлекать всё больше ресурсов для реализации идеи, используя лишь существующие ресурсы? Как управлять стартап проектом? Как создать свою технологию гарантированного успеха?

      Вселенная полна ресурсов! На тренинге вы научитесь добывать их. Подробнее >>>

      Agile в будівництві

      09.06.2019 @ 09:00 — 18:00
      Kharkivs’ke Hwy, 201/203, Kyiv, Ukraine, 02000

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

      pm.ISO21500 — Курс прикладного управления проектами

      Курс основан на международном стандарте ISO 21500:2012 «Guidance to Project Management». Тренинг расширяет ваши возможности реализовывать проекты и предоставляет инструменты, идеи и подходы, как выполнять проекты успешнее.
      На тренинге, в ходе индивидуальных и групповых упражнений, участники прорабатывают выбранный ими проект; применяют инструменты, техники и методы запуска, планирования, выполнения, контроля и завершения проектов, разбираясь в сущности этих инструментов и принципах их самостоятельного применения на практике.
      Подробная программа >>>

      10.06.2019 — 12.06.2019 @
      Navchal?nyy Tsentr Muk, Lobanovskyi Ave, 4Г, Kyiv, Ukraine, 02000

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

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

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

      Бизнес-причина возникновения проекта

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

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

      Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта

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

      Расписание основных контрольных событий

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

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

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

      Допущения относительно организации и окружения, а также внешние допущения

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

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

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

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

      Ограничения относительно организации и окружения, а также внешние ограничения

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

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

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

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

      Объем денежных средств, выделенных на достижение бизнес-цели

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

      Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор

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

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

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

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

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

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

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

      Что такое проект? Управление проектами?

      Назовите основные факторы, влияющие на проект?

      Что такое бизнес-цель проекта? Устав проекта?

      Назовите основных участников проекта и их полномочия?

      Перечислите требования, предъявляемые к уставу проекта?

      Смотрите еще:  Изменение Уголовно-процессуального кодекса с 8 января 2019 года. Полномочия следователя согласно упк рф