Устав проекта, пожалуй, является самым важным документом проекта. Как правило, проект считается открытым именно после утверждения устава проекта. Поэтому процесс «Разработка устава проекта» крайне важен для успешной реализации проекта. К подготовке устава проекта необходимо привлекать команду управления проектом во главе с . Большинство методологий, включая , сходятся на том, что работы, связанные с подготовкой устава проекта, не должны включаться в проект и выполняются за рамками проекта.
Устав проекта устанавливает партнерство между исполняющей организацией и организацией-заказчиком. Для внешних проектов предпочтительным способом заключения соглашения является формальный договор. В данном случае команда проекта является продавцом, реагирующим на условия предложения о покупке у внешней организации. Устав проекта в этом случае используется для заключения внутренних соглашений в рамках организации для обеспечения надлежащего поставляемого результата согласно договору. Одобренный устав проекта формально инициирует проект.
Менеджер проекта определяется или назначается сразу, как только это становится возможным, предпочтительно во время разработки устава проекта и обязательно до начала планирования. Устав проекта должен быть составлен спонсирующей стороной. Устав проекта наделяет руководителя проекта полномочиями в отношении планирования и исполнения проекта.
Рекомендуется, чтобы руководитель проекта участвовал в разработка устава проекта, чтобы полностью понимать требования проекта. Подобное понимание способствует эффективному распределению ресурсов для выполнения операций проекта
Давайте рассмотрим процесс «Разработка устава проекта» подробнее. На диаграмме ниже изображены входы, инструменты и методы и выходы этого процесса.
Входы процесса «Разработка устава проекта»
Описание работ проекта - это словесное описание продуктов, услуг или результатов, которые должен произвести проект. Для внутренних проектов инициатор или спонсор проекта предоставляет описание работ на основании бизнес-потребностей, требований к продукту или услуге. Для внешних проектов описание работ может быть получено от заказчика как часть документации по предложениям или как часть договора. Описание работ проекта отражает:
- Бизнес-потребность . Бизнес-потребность организации может быть основана на рыночном спросе, технологическом прогрессе, правовых требованиях, постановлениях правительства или соображениях, касающихся защиты окружающей среды. Обычно бизнес-потребность и сравнительный анализ затрат и выгод включены в бизнес-кейс для обоснования проекта.
- Описание содержания продукта . Описание содержания продукта включает характеристики продукта, услуги или результатов, для создания которых предпринимается проект. Описание должно также отражать взаимосвязь между создаваемыми продуктами, услугами или результатами и бизнес-потребностью, которую должен удовлетворить проект.
- Стратегический план . Стратегический план включает стратегическое видение, цели и задачи организации, а также высокоуровневое описание миссии. Все проекты должны соответствовать стратегическому плану организации. Соответствие стратегическому плану позволяет каждому проекту способствовать общим целям организации.
Бизнес-кейс или подобный документ предоставляет необходимую с точки зрения бизнеса информацию, позволяющую определить, стоит ли проект требуемых инвестиций. Он обычно используется вышестоящими по отношению к проекту руководителями для принятия решений. Как правило, в бизнес-кейсе содержится бизнес-потребность и сравнительный анализ затрат и выгод для обоснования проекта и определения его границ, и обычно подобный анализ выполняет бизнес-аналитик, используя различную информацию, полученную от заинтересованных сторон. Спонсор должен согласовать содержание и ограничения бизнес-кейса. Бизнес-кейс создается как результат действия одного или нескольких из следующих факторов:
- требование рынка (например, автомобилестроительная компания авторизует проект по изготовлению более экономичных автомобилей в ответ на дефицит бензина);
- потребность организации (например, в связи с высокими накладными расходами компания может объединить функции персонала и оптимизировать процессы для сокращения затрат);
- требование заказчика (например, электрическая компания авторизует проект по строительству новой подстанции для электроснабжения нового промышленного района);
- технологический прогресс (например, авиакомпания авторизует новый проект по разработке электронных билетов для замещения билетов, отпечатанных на бумаге, основываясь на технологических достижениях);
- юридическое требование (например, производитель красок авторизует проект для разработки руководящих указаний по обращению с токсичными материалами);
- экологические воздействия (например, компания авторизует проект для уменьшения своего воздействия на окружающую среду);
- социальная потребность (например, неправительственная организация в развивающейся стране авторизует проект по предоставлению систем питьевого водоснабжения, туалетов и санитарного просвещения сообществам, страдающим от высокого уровня случаев заболеваний холерой).
Соглашения используются для определения первоначальных намерений в отношении проекта. Соглашения могут принимать форму договора, меморандума о взаимопонимании, соглашения об уровне услуг, письма-соглашения, письма о намерениях, устных договоренностей, электронного сообщения или других письменных соглашений. Обычно договор используется, если проект выполняется для внешнего заказчика.
Факторы среды предприятия
- организационную культуру, структуру и руководство;
- географическое распределение оборудования и ресурсов;
- государственные и промышленные стандарты (например, предписания контролирующих органов, кодексы поведения, стандарты на продукцию, стандарты качества, стандарты изготовления);
- инфраструктуру (например, существующие сооружения и основное оборудование);
- имеющиеся человеческие ресурсы (например, навыки, знания, специализации, такие как проектирование, разработка, юридические вопросы, заключение договоров и закупки);
- управление персоналом (например, руководящие указания по приему на работу и увольнению, анализ эффективности и результативности работы и записи об обучении персонала, политика вознаграждений и сверхурочной работы, а также учет рабочего времени);
- корпоративная система авторизации работ;
- ситуация на рынке;
- толерантность к риску заинтересованных сторон;
- политический климат;
- каналы коммуникаций, принятые в организации;
- коммерческие базы данных (например, стандартизированные сметные данные, данные изучения промышленных рисков и базы данных рисков);
- информационная система управления проектами (например, автоматизированные системы, такие как программное обеспечение для управления расписанием, система управления конфигурацией, система сбора и распределения информации или веб-интерфейсы к другим автоматизированным системам, работающим в режиме онлайн);
- государственные и промышленные стандарты или предписания (например, кодексы поведения, стандарты качества или стандарты по защите трудящихся);
- организационную культуру и структуру;
- ситуацию на рынке.
Активы процессов организации , которые могут оказывать влияние на процесс разработки устава проекта, включают в себя, среди прочего:
- стандартные процессы организации, политики и описания процессов;
- шаблоны (например, шаблон устава проекта);
- историческую информацию и базу накопленных знаний (например, проекты, записи и документы, всю информацию и документацию по закрытию проекта, информацию о результатах решений по отбору предыдущих проектов наряду с информацией об исполнении предыдущих проектов, а также информацию об операциях по управлению рисками).
Инструменты и методы процесса «Разработка устава проекта»
Экспертная оценка часто используется для оценивания входов, применяемых для разработки устава проекта. Экспертная оценка применяется в отношении всех технических и управленческих деталей в течение этого процесса. Такая экспертиза предоставляется любым лицом или группой лиц, обладающими специальными знаниями или подготовкой, и доступна из множества источников, включая следующие:
- другие подразделения в рамках организации;
- консультанты;
- заинтересованные стороны, в том числе заказчики или спонсоры;
- профессиональные и технические ассоциации;
- отраслевые объединения;
- эксперты по предметной области;
- проектный офис.
Методы организации групповой работы имеют широкое применение в рамках процессов управления проектом и способствуют созданию устава проекта. Примеры основных методов включают , разрешение конфликтов, решение проблем и управление совещаниями. Модераторы используют эти методы, чтобы помочь командам и отдельным лицам выполнять операции проекта.
Выходы процесса «Разработка устава проекта»
Это документ, выпускаемый инициатором или спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта. Он документирует бизнес-потребности, допущения, ограничения, понимание потребностей заказчика, высокоуровневые требования, а также новый продукт, услугу или результат, который планируется создать, например:
- назначение или обоснование проекта;
- измеримые цели проекта и соответствующие критерии успеха;
- высокоуровневые требования;
- допущения и ограничения;
- высокоуровневые описание и границы проекта;
- высокоуровневые риски;
- укрупненное расписание контрольных событий;
- укрупненный бюджет;
- список заинтересованных сторон;
- требования к одобрению проекта (т. е. что именно составляет успех проекта, кто решает, что проект оказался успешным, и кто подписывает проект);
- назначенный руководитель проекта, сфера ответственности и уровень полномочий;
- ФИО и полномочия спонсора или другого лица (лиц), авторизующего (авторизующих) устав проекта.
Дмитрий Халдин,
руководитель департамента управления проектами PM Invest Group
Просмотры: 14 258
В соответствии с предлагаемым подходом бизнес-выгоды можно классифицировать по двум факторам: (1) характеру воздействия на бизнес и (2) степени определенности. Таким образом, каждая выгода по проекту размещается "на пересечении" соответствующих значений двух обозначенных факторов.
Использование матрицы структурирования выгод начинается с определения характера воздействия на бизнес каждой из них. Определены три типа воздействия.
- Создание новых возможностей : функциональность информационной системы, ранее не доступная компании, ее контрагентам или иным заинтересованным сторонам.
- :функциональность новой информационной системы позволяет выполнять существовавшие до нее операции гораздо более эффективно.
- Отказ от операций :информационная система позволяет отказаться от выполнения операций, утративших свою актуальность для бизнеса компании в связи с изменением бизнес-процессов.
| ХАРАКТЕР ВОЗДЕЙСТВИЯ НА БИЗНЕС | ||||
|---|---|---|---|---|
| Создание новых возможностей | Повышение эффективности операций | Отказ от операций | ||
| СТЕПЕНЬ ОПРЕДЕЛЕННОСТИ | Финансовые | |||
| Количественные | ||||
| Измеримые | ||||
| Качественные | ||||
После определения характера воздействия необходимо классифицировать каждую бизнес-выгоду по степени определенности (от менее определенных к более определенным): наблюдаемые (качественные), измеримые, количественные, финансовые.
- Качественные : выгоды, которые могут быть зафиксированы на уровне экспертного мнения или суждения. В то время как данный тип выгод вполне допустим, необходимо всегда предупреждать ситуацию, когда без четкого значения выгоды на этапе планирования очень сложно определить степень ее реализации на момент принятия результатов проекта. В связи с этим рекомендуется разрабатывать четкие критерии реализации качественных выгод в самом начале проекта и, по возможности, собирать дополнительную информацию для "переноса" качественных выгод в более объективные категории.
- Измеримые :выгоды данного типа поддаются измерению. В распоряжении аналитика есть инструменты и техники, например, ключевые показатели эффективности, позволяющие измерить их значение до внедрения. Для данного типа бизнес-выгод характерна невозможность оценить значение соответствующего показателя после внедрения.
- Количественные :аналогично измеримым, количественные выгоды характеризуются наличием показателей, позволяющих измерить их значение до выполнения проекта. Но, в отличие от измеримых, значение показателей количественных бизнес-выгод на момент окончания проекта можно оценить с высокой степенью точности.
- Финансовые :это тип бизнес-выгод, которые могут быть выражены в терминах финансовых показателей. Отнесение бизнес-выгоды к данной категории должно производиться только в том случае, если в распоряжении аналитика имеется достаточно достоверная информация о финансовой оценке соответствующих показателей. Очевидно, финансовые выгоды есть результат "обогащения" количественных бизнес-выгод финансовыми данными. Агрегированные финансовые выгоды проекта образуют базу для построения финансовой модели проекта (ROI-модель) и расчета инвестиционных показателей: NPV, IRR , периода окупаемости.
Выбор той или иной категории для конкретной бизнес-выгоды производится на основе доступной информации о ней до момента реализации инвестиций. Каждая бизнес-выгода на момент ее идентификации относится к наименее определенной категории - наблюдаемая. По ходу анализа необходимо максимальное количество бизнес-выгод перенести в финансовую категорию для построения экономической модели окупаемости проекта, кроме доходной части, в которой должна быть отражена и расходная. В качестве инструмента оценки стоимости проекта и системы авторы рекомендуют использовать модель совокупной стоимости владения системы ( TCO ), рассмотрение которой будет произведено в разделе, посвященном управлению стоимостью проекта.
Формирование бизнес-цели проекта
Бизнес-цель - это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится "просто выдать продукт", а не достичь какой-либо тактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта ).
Так, например, бизнес-целью проекта по приобретению и установке нового производственного оборудования является не покупка и установка оборудования, а устранение узкого места в производственном процессе и обеспечение надлежащих объемов выпуска, гарантирующих удовлетворение спроса и завоевание определенной доли рынка. Аналогично, проект внедрения информационной системы имеет своей бизнес-целью не разворачивание технических средств, а создание информационно-технологического фундамента для поддержки принятия руководством компании своевременных управленческих решений, направленных на обеспечение ее развития и роста.
Бизнес-цель должна быть достаточно веской, чтобы организация решилась перейти к разработке устава проекта, документа, в соответствии с лучшими практиками инициирующего выполнение проекта. В качестве инструмента, позволяющего определить необходимость реализации проекта, может быть использовано ТЭО , или бизнес-кейс, проекта.
Разработка устава проекта
Устав проекта - это инструмент, который формально авторизует проект и является звеном, соединяющим предстоящий проект с текущей работой организации. Данный документ обычно отражает ситуацию со стороны организации-заказчика, выпускается руководителем, внешним по отношению к проекту, и назначает менеджера проекта, наделяя его полномочиями на использование в проекте ресурсов организации. Это особенно актуально в функционально-ориентированных и матричных организациях , т.е. в тех компаниях, где менеджеры не имеют непосредственной власти над членами проектной команды и другими ресурсами, но несут ответственность за выполнение проекта. Для того чтобы устав имел силу в подобной ситуации, издающий его руководитель, или спонсор проекта , должен находиться на том уровне, который подразумевает наличие контроля над ресурсами. Часто датой начала проекта считается день, следующий за подписанием устава.
Процесс разработки устава проекта уже подразумевает, что компания заинтересована в достижении какой-то цели или решении имеющейся проблемы и готова выделять под это ресурсы. Следовательно, со стороны организации-заказчика есть мотив инвестировать средства и ресурсы в генерацию такой информации, которая позволит разработать корректный устав проекта . К информации, имеющей ключевое значение для составления устава, относятся:
- стратегические и тактические цели организации-заказчика;
- формулировка требований организации-заказчика;
- ТЭО ;
- контракт;
- внутрикорпоративная методология управления проектами и соответствующие политики.
Решение о выполнении проекта - итог процесса отбора проектов, основанного на информации, которая изложена в вышеуказанных документах. Таким образом, крайне важно давать прямую ссылку в соответствующих разделах устава на них с тем, чтобы придать уставу больший вес .
В табл. 1.5 приведены требования к уставу проекта - перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению.
| № | Раздел | Пояснения |
|---|---|---|
| 1 . | Название проекта | Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания |
| 2 . | Бизнес-причина возникновения проекта | Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте |
| 3 . | Бизнес-цель | Сформулирована заказчиком, исходя из стратегических и тактических целей компании, см. раздел "Формирование бизнес-цели проекта " |
| 4 . | Требования , удовлетворяющие потребности , пожелания и ожидания заказчика , спонсора и других участников проекта | Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта |
| 5 . | Расписание основных контрольных событий | На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта , принципиальные для организации-заказчика. Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий - это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств |
| 6 . | Участники проекта | Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него. Подробнее об участниках проекта см. раздел "Идентификация участников проекта" |
| 7 . | Окружение проекта | Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика - к использованию его результатов. Далее (см. рис. 1.2) будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов, действующих в окружении проекта ; они заносятся в соответствующий сектор. Затем выделяются наиболее критичные из них (прямоугольники - участники, овалы - факторы окружения) |
| 8 . | Допущения относительно организации и окружения, а также внешние допущения | Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:
|
| 9 . | Ограничения относительно организации и окружения, а также внешние ограничения | Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ . Пример ограничений проекта:
|
| 10 . | Объем денежных средств, выделенных на достижение бизнес-цели | На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта . Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от ~ -20% до +100% |
| 11 . | Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП , спонсор , координатор | Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта - объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта [ , ].
Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект 2Авторы рекомендуют включать в проект руководителей и двух спонсоров проекта
- по одному от заказчика и исполнителя.
.
Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например:
|
Искусство управления проектом заключается в том, чтобы неведомое сделать предсказуемым. И чем раньше выявятся подводные камни – тем больше шансов не нахлебаться воды.
Устав проекта – это документ, который формализует ключевые договоренности по всем измерениям проекта между его участниками. Он разрабатывается в ходе инициации проекта – до решения о его начале.
Устав проекта определяет каркас проекта в 5 измерениях:
- ЦЕЛИ и ТРЕБОВАНИЯ
- ЗАДАЧИ
- РИСКИ
- УЧАСТНИКИ
- ПРАВИЛА
Также может добавляться еще шестое измерение – РЕСУРСЫ (бюджет и иные).
И хотя на этапе инициации проекта, пока не выполнено детальное планирование, точно определить потребность в ресурсах довольно сложно, вполне возможно выявить ограничения по ресурсам, которые придется учитывать при планировании.
Чтобы определить каркас проекта в этих измерениях необходимо:
- выявить и проработать систему целей проекта;
- определить границы проекта и требования к его результатам;
- выявить предположения и риски;
- разработать стратегический план проекта;
- спроектировать организационную структуру и правила взаимодействия.
На практике результаты выполнения этих задач могут фиксироваться в разных документах, таких как: договор, устав проекта, план управления рисками, техническое задание. Структура и объем каждого документа, а также распределение по ним этих данных определяется спецификой каждой компании и зависит от выбранной методологии и технологии управления проектами. При использовании современных технологий управления проектами эти документы не разрабатываются самостоятельно, а генерируются как отчеты на основе единой проектной базы, содержащей трассируемые данные по всем измерениям проекта.
Устав проекта может быть как внутренним документом, так и документом, согласуемым с внешними сторонами проекта, фактически выполняя роль контракта между заказчиком и исполнителем. Последний подход чаще используется зарубежом.
Успешной команде нужна разработка устава проекта — «прощупать» проект, пока корабль еще не укомплектован и не отошел от берега. И важен не сам документ, а те задачи, которые придется решить, чтобы наполнить его смыслом.
Рассмотрим подробнее эти задачи.
Для описания задач воспользуемся методологией функционального моделирования IDEF0.
Модель процесса разработки устава проекта
Цель моделирования: показать основные этапы, необходимые для начала проекта, их взаимосвязь и результаты, приводящие к формированию отчетного документа «Устав проекта», а также определить основные требования к процессу разработки устава проекта и требования к содержанию устава проекта.
Точка зрения: Руководитель проекта.
Контекст: Для того, чтобы показать место процесса по разработке устава проекта и самого устава проекта в жизненном цикле проекта, контекстная диаграмма А0 соответствует процессу выполнения проекта в целом и затем детализируется на отдельные этапы. Данная модель не противоречит PMBOK 4, но обладает большей детализацией с точки зрения процесса разработки устава проекта.
Допущения: Процесс подготовки и выполнения проекта итеративен и многие задачи часто выполняются в параллель, поэтому приведенное в модели разбиение на этапы отражает информационные зависимости между процессами, но не означает, что процессы всегда выполняются в такой последовательности.
На диаграммах А0-А1 (рисунок 1 и 2) отражен контекст интересующего нас процесса.
Предполагается, что в организации есть корпоративный стандарт управления проектами, в котором определены основные правила ведения проектов. В этом случае в уставе проекта вводятся ссылки на данный стандарт и указываются только те данные, которые являются специфичными для выполняемого проекта. Если такого стандарта нет, это означает, что такие правила нужно определять каждый раз индивидуально для каждого проекта.
Обычно работы по проекту начинаются с получения каких-то исходных данных, будь-то брошенная вскользь идея заказчика или формализованное ТЗ на 200 страниц. С этих исходных данных и предстоит начать «разматывать клубок» в ходе разработки устава проекта.
Разработка устава проекта (см. рис 2) является подготовительным этапом и по его результатам принимается решение об инициации проекта. Важность этого этапа сложно переоценить, т.к. от него зависит «быть или не быть» проекту. Кстати, те, кто пропускают этот этап в начале проекта, в итоге вынуждено возвращаются к этому вопросу позже, уже израсходовав некоторую часть ресурсов двух организаций.
Если проект инициирован, то собранные в ходе разработки устава проекта высокоуровневые данные по всем 5(6) измерениям проекта должны быть детализированы на следующих этапах. Устав проекта является руководящим документом для последующих этапов, что и отражено на диаграмме А1 на рисунке 2.
Хотя на диаграмме А1 не отражена обратная связь между блоком А1.4 Анализировать проект и А1.1 Разработать устав проекта , нельзя забывать, что и устав проекта не является его «догмой» и может быть пересмотрен в любой момент для лучшего соответствия актуальным целям проекта и ситуации. Например, в ходе выполнения проекта выяснилось, что появляется несколько ключевых пользователей разрабатываемой системы, они безусловно должны быть включены в проект и его систему коммуникации, а их ожидания учтены и соотнесены с целями проекта.
При этом стоит помнить, что изменение ключевых ограничений проекта, отраженных в уставе, может существенно изменить картину по всем измерениям – начиная от требований, заканчивая сроками и бюджетом. Это может испугать неопытных руководителей и увести от проведения измений в явном виде. Однако суть от этого, конечно, не переменится – если изменения есть, их лучше зафиксировать и довести до участников проекта.
Введенные на первых двух диаграммах потоки, определены в таблице ниже.
Таблица 1. Потоки данных для А0-А1
| Имя потока | Определение потока |
| Данные проекта | * данные, дополнительные к исходным данным, которые были получены в ходе разработки устава проекта * |
| Исходные данные проекта | * любые исходные данные, полученные до организации проекта. Это могут быть требования заказчика, данные о предметной области проекта и др. * |
| Корпоративный стандарт УП | * стандарт предприятия, определяющий требования к процессам управления проектами. Может включать правила выполнения, детальное описание процессов, шаблоны документов. Степень детализации определяется в рамках каждого предприятия. Данный стандарт может являться частью стандартов СМК * |
| Корректировки | * предложения по изменению проекта * |
| План проекта | * оперативный план проекта с назначенными ресурсами, на основании которого выполняются работы * |
| Проектная база или редактор | * инструмент для разработки проекта, в зависимости от выбранной технологии управления проектом – документоориентированной или ориентированной на данные * |
| Результаты проекта | * все результаты, полученные в ходе выполнения проекта * |
| Руководитель проекта | * лицо со стороны исполнителя проекта, отвечающее за координацию и исполнение проекта * |
Прежде чем разбирать сам процесс необходимо познакомиться с определениями потоков данных:
Таблица 2. Потоки данных для А1.1
| Имя потока | Определение потока |
| Заинтересованные стороны | * стороны и лица, которые принимают решения или оказывают влияние на лиц, принимающих решения относительно хода проекта. Под сторонами подразумеваются организационные структуры, участвующие в проекте, под лицами — конкретные персоны, принадлежащие или нет данным организационным структурам. * |
| Критерии SMART | * требования к формулированию целей * |
| Критерии отсева проектов | * правила определения проектов, которые не должны браться в работу * |
| Орг-структура проекта | * организационная структура проекта * |
| Система целей проекта | * согласованная система целей проекта и ожиданий заинтересованных лиц, включающая измеряемые показатели и критерии достижения целей * |
| Стратегический план проекта | * включает основные этапы и результаты проекта, методы контроля хода проекта, риски проекта * |
| Правила детализации СП | * корпоративные правила детализации (декомпозиции) задач и результатов стратегического плана * |
| Правила взаимодействия | * корпоративные правила организации взаимодействия с заказчиком и внутри проекта, например, время отклика на запрос * |
| Правила оформления УП | * корпоративные правила оформления отчетного документа «Устав проекта» * |
Первоочередная задача подготовки и оценки проекта – понять и определить систему целей. Все цели проекта должны быть взаимоувязаны, даже те, которые невозможно зафиксировать в явной форме . Выявление и согласование целей – сложная задача, результаты которой определяют его успех или провал . Чаще всего она не решается «с наскока», а некоторые важные цели мимолетно всплывают и тонут в несущественных деталях, подменяясь на составляющие их подцели. Задача руководителя проекта – держать в фокусе максимально полную картину, начиная с самого верхнего уровня.
На диаграмме процесса A.1.1.1, раскрывающей процесс «Выявить и проработать систему целей проекта» показано, что выявление целей проекта начинается с определения их источников — сторон и лиц, оказывающих влияние на ход проекта: кто принимает решения о проекте, кто принимает решение о приемке продукта, кто оказывает на него хоть какое либо влияние, пусть даже косвенное. Система целей проекта должна быть согласована с их ожиданиями. Противоречия целей проекта и ожиданий заинтересованных сторон неизбежно приводят к конфликтам как в ходе проекта, так и на этапе его сдачи. Поэтому за процессом разработки иерархии целей проекта стоит важная задача согласования целей проекта и ожиданий заинтересованных сторон. Этот процесс необходимо будет продолжить при подборе команды проекта (процесс «Спроектировать организационную структуру проекта»), которая также определяет ход проекта.
Обычно цели проекта организуются в одну или несколько иерархий. Это означает, что для каждой цели верхнего уровня должны быть определены конкретные задачи, за счет выполнения которых предполагается достигнуть цели проекта. Например, если цель верхнего уровня — снизить затраты на изготовление продукции, то она может быть достигнута различными путями — снижением заработной платы, накладных расходов, автоматизацией производства и т.п., но это не значит, что в проекте будут использованы все способы, поэтому необходимо указать конкретные способы достижения цели, выбранные для данного проекта. Этот процесс также помогает оценить достижимость выбранной цели.
Хорошая практика формулирования целей заложена в принципах SMART . Чтобы можно было добежать до цели, а не только согреться, необходимо указать критерии достижения целей проекта (блок A1.1.1.3) , т.е. показатели, которые возможно измерить, а также их значения. Это позволяет снять целых комплекс конфликтов и рисков неуспешного завершения проекта. Представьте, что вы руководитель проекта, вы выполнили проект в срок, уложились в бюджет, достигли сформулированной цели проекта — снизили затраты на изготовление продукции. А заказчик считает проект неуспешным, отказывается принимать результаты и соответственно делать выплаты. В чем же дело? Дело в том, что вы снизили затраты на 3% за 1 год, а заказчик считал, что они должны быть снижены на 10% за полгода, тогда проект для него считается успешным .
Эта сложная задача часто игнорируется, что приводит к неуспешным проектам и отражено в известной статистике ИТ- отрасли .
Таблица 3. Потоки данных для А1.1.1
Расширенный материал по формированию системы целей с иллюстрациями приведен в статье ?
После разработки системы целей возможно приступить к более детальному планированию, хотя на данном уровне оно все равно остается в рамках стратегического — описываются основные этапы проекта и их результаты. Фактически, это продолжение разработки иерархии целей. Теперь определяются конкретные задачи и их результаты, которые помогут их достичь. (см рис. 5)
Кроме этого необходимо определить события, которые могут воспрепятствовать достижению целей — риски проекта, а также методы, которые позволят отслеживать ход выполнения проекта, т.е. понимать, насколько мы близки к цели.
Риски проекта сильно влияют на его план и ресурсы, т.к. в нем[плане] должны быть предусмотрены меры по их предотвращению или хотя бы по снижению негативных последствий.
Еще один прием, позволяющийболее точно определить каркас проекта — это описание его границ. Границы описываются за счет указания целей и задач, которые не входят в проект. Таким образом, более точно определяется развитие проекта, которое будет считаться успешным.
Таблица 4. Потоки данных для А1.1.2
| Имя потока | Определение потока |
| Границы проекта | * цели, требования и задачи, не входящие в проект * |
| Задачи по предупреждению рисков | * задачи, которые необходимо учесть в плане работ, чтобы предупредить риски* |
| Методы контроля хода проекта | * процедуры определения состояния (хода) проекта, в т.ч. периоды отчетности, формы отчетности * |
| Риски проекта | * событие, наступление которого может привести к нарушению обязательств по проекту. Риск проекта описывается по следующей схеме: 1. Название — кратко отражает причину возникновения риска 2. Причина — полное описание причины возникновения риска 3. Возможное событие — событие, наступление которого возможно в следствие данной причины и которое может привести к нарушению обязательств по проекту 4. Результат — последствия наступления события для проекта 5. Предотвращение — меры по предотвращению причины события или самого события 6. Смягчение — меры по смягчению последствий наступления события Также необходимо указать статус и тип обработки. * |
| Этапы и результаты | * список или иерархия основных этапов проекта, а также результаты, которые должны быть получены на каждом этапе * |
После того, как стратегический план проекта разработан, можно переходить к формированию организационной структуры проекта. На данном этапе определяются участники проекта и их роли, определяется их область ответственности. Также устанавливаются официальные коммуникации проекта.
Орг-структура проекта должна соответствовать целям и задачам проекта. Плохо организованные люди способны завалить даже самый простой проект.
Таблица 5. Потоки данных для А1.1.3
Когда все элементы каркаса собраны, еще раз оценивается его жизнеспособность и реализуемость проекта.
Заключение
Разработка устава проекта — это подготовительный этап, от результата которого зависит успех проекта. Структуру устава проекта хорошо использовать как справочник и чек-лист для оценки возможности успешно завершить проект. А вопросы, которые будут возникать в ходе разработки устава, позволяют на раннем этапе выявить и устранить конфликты и даже своевременно принять решение о закрытии проекта, если станет очевидным, что цели проекта недостижимы в текущих условиях.
Отношение к уставу проекта, как к простой формальности, отражает непрофессиональный взгляд на процессы управления проектами и вскрывает непонимание процессов, которые стоят за разработкой данного документа.
В рассмотренной схеме процессов показаны информационные связи между процессами. Выполнение процессов без их учета, хотя и часто встречается на практике, приводит к несогласованным результатам. В таких случаях необходимо проводить дополнительные итерации согласования результатов каждого этапа.
Мадорская Ю.М. Разработка устава проекта. Методическое пособие. //Практика проектирования систем.-2017.. - Загл. с экрана
Литература
- Тимофеев А.Н. Почему падают ИТ-проекты? //Практика проектирования систем.-2017.. - Загл. с экрана
- Duncan Haughey. Smart Goals //Project Smart.-2017. [электронный ресурс] — Режим доступа:https://www.projectsmart.co.uk/smart-goals.php, свободный. - Загл. с экрана
В продолжение первой публикации “Как разработать корпоративную методологию управления проектами”- в данном материале мы рассмотрим основной документ выше упомянутой методологии – Положение «О корпоративной системе управления проектами» или Корпоративный стандарт по управлению проектами, а также шаблоны следующих рабочих документов проекта, рекомендованных PMI к разработке при управлении проектом:
- Устав проекта (project charter);
- Документ, определяющий содержание проекта (project scope statement (preliminary and detailed);
- План управления проектом (project management plan).
КОРПОРАТИВНЫЙ СТАНДАРТ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ
Мы предлагаем рассматривать Положение о КСУП или корпоративный стандарт по управлению проектами (далее – корпоративный стандарт) как документ верхнего уровня в структуре внутренней нормативной документации, регламентирующей управление проектами в компании.
Следует заметить, что в практике встречаются и другие трактовки корпоративного стандарта по управлению проектами.
В некоторых компаниях под корпоративным стандартом понимают совокупность документов, регламентирующих и обеспечивающих управление проектами.
В других – для управления проектами разрабатывают несколько корпоративных стандартов одного уровня, регламентирующих различные аспекты управления проектами. Такой подход, к примеру, был принят в отношении инвестиционных проектов в управляющей компании одной из известных финансово-промышленных групп.
Подходы, описанные во втором и третьем случае, по нашему мнению, имеют определенные недостатки.
Под корпоративным стандартом обычно понимается один документ. Поэтому подобное название для совокупности документов представляется не вполне корректным и может дезориентировать тех, кто занимается разработкой корпоративной методологии управления проектами.
Разработка нескольких корпоративных стандартов одного уровня для управления теми же инвестиционными проектами может привести к созданию фрагментарной методологии. В этом случае определенные процессы и процедуры управления проектами могут быть пропущены или описаны и регламентированы в разных форматах, разными средствами в соответствие с опытом и субъективными представлениями об управлении проектами, имеющимися о разработчиков документов. Интегрировать несколько разных стандартов в единую методологию будет весьма затруднительно.
Разработке корпоративного стандарта может предшествовать создание концепции управления проектами в компании.
Создавать концепцию целесообразно по той причине, что для успешной разработки и внедрения корпоративной методологии управления проектами необходимо, чтобы собственники и руководители высшего уровня договорились между собой и согласовали свое видение и свои требования и ожидания относительно КСУП. Концепция как раз и создает хорошую основу для согласования позиций и достижения принципиальных договоренностей между лицами, принимающими ключевые решения по управлению проектами в компании.
Предназначение корпоративного стандарта по управлению проекта, по нашему мнению, заключается в том, чтобы описать саму КСУП, принципы ее построения, основные элементы, а также подход к управлению проектами, принятый в компании.
В корпоративный стандарт целесообразно включать следующие разделы:
- Назначение и область применения стандарта
- Нормативные ссылки
- Определения терминов, обозначения и сокращения
- Принципы организации системы управления проектами в компании
- Классификация проектов компании
- Процессы управления проектами в компании
- Организационная структура управления проектами
- Распределение функций, полномочий и ответственности в рамках системы управления проектами компании (уровни портфеля, программ, проектов)
- Нормативная база управления портфелем, программами и проектами
- Ведение реестра проектов
- Назначение приоритетов проектов
- Документирование и архивирование проектов
- Информационная система управления проектами
- Порядок внесения изменений в стандарт
- Приложения (шаблоны основных рабочих документов).
УСТАВ ПРОЕКТА (PROJECT CHARTER)
Устав проекта (рroject charter) – один из самых «мифологизированных» рабочих документов проекта. Краткость описания этого документа в основном стандарте PMI – PMBOK в редакциях 2000 и 1996 года, с лихвой окупается богатством интерпретаций предназначения и содержания данного документа как российскими, так и зарубежными экспертами в области управления проектами.
Если обобщить существующие в проектной практике точки зрения, то получится, что под Уставом проекта разные специалисты, в т.ч. ориентирующиеся на PMBOK, понимают:
- заявку на открытие проекта;
- приказ на открытие проекта;
- некий аналог положения о подразделении (цели, организационная структура управления проектом, распределение ролей и ответственности среди членов проектной команды);
- техническое задание менеджеру проекта от руководства или заказчика;
- обоснование проекта;
- аналог плана управления проектом;
- если по проекту заключается контракт с внешним заказчиком/исполнителем, то он полностью заменяет Устав.
Наиболее удачная трактовка Устава проекта, по нашему мнению, дана в новой редакции PMBOK от 2004 года. В отличие предыдущих трактовок данный документ, действие данного документа не ограничивается фазой инициации проекта. Изменение предназначения Устава заключается в том, что он должен обеспечивать интеграцию проекта, т.е. согласованность действий всех участников на всех этапах проекта.
Предназначение, содержание и порядок разработки и изменений Устава проекта в соответствие с новой редакции PMBOK от 2004 года описаны ниже. Примеры структур Уставов проектов из практики разных компаний приведены в Приложении к статье.
Предназначение документа: Устав проекта предназначен для определения проекта. На фазе инициализации, он включает в себя:
- документирование бизнес-потребностей (проблем, возможностей) и общее описание продуктов или услуг, удовлетворяющих данные потребности;
- связи проекта с текущей (операционной) деятельностью организации.
Когда разрабатывается документ: после заключения контракта (если заключается контракт с внешним контрагентом)
Кто разрабатывает документ: Устав проекта могут разрабатывать:
- инициатор проекта;
- спонсор проекта;
Кто утверждает документ: Устав проекта может утверждать:
- инициатор проекта;
- спонсор проекта;
- представитель внешней стороны, связанной с проектом.
Лицо, утверждающее Устав проекта, должно иметь полномочия по принятию основных решений по проекту, включая его финансирование.
- контракт;
- Бизнес-потребности или требования к продукту, который будет создан в рамках проекта;
- Цель проекта или основание для разработки проекта (justification);
- Потребности и ожидания заинтересованных лиц (stakeholders);
- Укрупненное расписание контрольных событий;
- Влияние заинтересованных лиц на проект;
- Распределение функций (functional organizations);
- Предположения, связанные с внешним окружением и внутренней организационной средой;
- Ограничения, связанные с внешним окружением и внутренней организационной средой;
- Бизнес-обоснование проекта, включающее возврат на инвестиции (ROI);
- Укрупненный бюджет.
Порядок изменений документа: Команда проекта поддерживает Устав проекта в актуальном состоянии, получает обратную связь от участников проекта о необходимых улучшениях документа, контролирует изменения и выпускает релизы утвержденного документа.
ДОКУМЕНТ, ОПРЕДЕЛЯЮЩИЙ СОДЕРЖАНИЕ ПРОЕКТА (PROJECT SCOPE STATEMENT (preliminary and detailed)
Ниже описано предназначение, содержание и порядок разработки и изменений Документа, определяющего содержание проекта, в соответствие с новой редакции PMBOK от 2004 года. В этом и в следующих разделах статьи использованы оригинальные английские термины, т.к. использование их русских аналогов, как заметил один из моих коллег, «очень часто ведет в дебри».
Предназначение документа: PROJECT SCOPE STATEMENT (preliminary или предварительный) необходим для высокоуровневого определения проекта (что должно быть сделано) и включает в себя:
- Характеристики и рамки проекта;
- Требования к продуктам и услугам, связанным с проектом.
Когда разрабатывается документ: После утверждения Устава проекта.
Кто разрабатывает документ: PROJECT SCOPE STATEMENT (preliminary) могут разрабатывать:
- менеджер проекта или команда проекта;
- представители внешней стороны, связанной с проектом, на основе информации, предоставленной инициатором или спонсором проекта.
Кто утверждает документ: PROJECT SCOPE STATEMENT (preliminary) может утверждать:
- спонсор проекта;
- представитель внешней стороны, связанной с проектом.
Входы (исходные данные) для разработки документа:
- Устав проекта;
- документ определения работ (Statement of work);
- факторы внешнего окружения и организационной среды;
- организационные активы (Organizational process assets).
- Цели проекта и цели предметной области проекта;
- Требования и характеристики продукта или услуги;
- Рамки проекта;
- Проектные решения (deliverables);
- Критерии приемки продукта;
- Проектные ограничения;
- Проектные предположения;
- Организация проекта на начальной стадии;
- Идентификация рисков на начальной стадии;
- Расписание контрольных событий;
- Предварительный расчет стоимости (Order of magnitude cost estimate);
- Требования к управлению конфигурацией проекта;
- Согласованные требования (Approval requirements).
Порядок изменений документа: Команда проекта осуществляет дальнейшую разработку PROJECT SCOPE STATEMENT (preliminary), на этапе определения содержания проекта прорабатывает данный документ более детально (статус PROJECT SCOPE STATEMENT изменяется с preliminary на detailed), а также осуществляет контроль изменений документа.
ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ (PROJECT MANAGEMENT PLAN)
Ниже описаны предназначение, содержание и порядок разработки и изменений Плана управления проектом, в соответствие с новой редакции PMBOK от 2004 года.
Предназначение документа: На базе Плана управления проектом обеспечивается определение, интеграция и координация всех составных планов проекта. План управления проектом – основное средство о том, как должен выполняться, отслеживаться и контролироваться.
Когда разрабатывается документ: План управления проекта разрабатывается после утверждения Устава проекта и PROJECT SCOPE STATEMENT (preliminary). Если последние два документа не разрабатываются, то после сбора или приобретения соответствующей информации.
Кто разрабатывает документ: менеджер проекта или команда проекта с участием других заинтересованных лиц.
Кто утверждает документ: План управления проектом может утверждать:
- спонсор проекта;
- представитель внешней стороны, связанной с проектом.
Входы (исходные данные) для разработки документа:
- Устав проекта;
- Project Scope Statement (preliminary);
- Процессы управления проектом;
- Прогнозы
- Факторы внешнего окружения и организационной среды;
- Организационные активы (Organizational process assets);
- Информация о выполнении работ.
- Процессы, выбранные командой управления проектом;
- Уровень внедрения каждого выбранного процесса, определенный командой управления проектом;
- Описание средств и техник, используемых для выполнения этих процессов;
- Выбранный жизненный цикл проекта и связанные с ним фазы проекта;
- Как выбранные процессы будут использованы для управления конкретным проектом. Включение зависимостей и взаимодействий между этими процессами и необходимых входов и выходов;
- Как будет организовано выполнение работы для достижения целей проекта;
- Как будут осуществляться мониторинг и контроль изменений;
- Как будет осуществляться управление конфигурацией;
- Как будет обеспечиваться интеграция исходных планов (baselines) проекта;
- Потребности в информации и техники коммуникаций между заинтересованными лицами;
- Ключевые управленческие обзоры по содержанию, масштабу, выбору сроков проекта, обращенные к открытым вопросам и предстоящим решениям по проекту.
План управления проектом может суммировать/объединять все отдельные планы проекта или некоторые из них:
- План управления содержанием;
- План управления расписанием;
- План управления стоимостью;
- План управления качеством;
- План улучшений;
- План управления персоналом;
- План управления коммуникациями;
- План управления рисками;
- План управления поставками.
Порядок изменений документа: Изменения Плана управления проекта проходят через процесс Интегрированного управления изменениями и могут быть связаны с модификациями, дополнениями и ревизиями проекта. При этом статус Плана меняется на обновленный (updated).
Ниже приведена схема формирования рассмотренных рабочих документов проекта на разных этапах его жизненного цикла. Все использованные английские термины были раскрыты ранее, за исключением одного – Subsidiary Plans. Под этим термином понимаются отдельные планы, которые могут обобщаться или объединяться в Плане управления проектом (СМ. предыдущий раздел).
А.Ю.Сооляттэ, партнер ИП «Finexpert.ru», адрес электронной почты – [email protected] .
Приложение
ПРИМЕРЫ УСТАВОВ ПРОЕКТОВ КОМПАНИЙ
Пример 1. УСТАВ ПРОЕКТА (международная компания, занимающаяся производством компьтерной техники, разработкой программного обеспечения и проектами в сфере системного интеграции).
Примечание: В материалах данной компании специально подчеркивается, что данный документ не является Планом проекта, хотя включает в себя даты, к которым нужно стремиться в рамках проекта.
Данный документ – Устав проекта – уточняется/изменяется и утверждается заново на каждой из стадий: на стадии предложения, на стадии исполнения (после подписания контракта).
СОДЕРЖАНИЕ:
1. Обзор Устава проекта
2. Организация проекта
2.1. Менеджер Проекта по интегрированию систем
2.2. Привлеченная команда по системному интегрированию
2.3. Роли и обязанности
2.4. Полномочный орган по финансированию Проекта
2.5. Комитет спонсоров Проекта
2.6. Комитет директоров Проекта
3. Краткое изложение требований по системному интегрированию
3.1. Обзор системного интегрирования
3.2. Определение потребности в системном интегрировании
3.3. Содержание и цели системного интегрирования
3.4. Факторы и риски, влияющие на системное интегрирование
4. Краткие сведения по Проекту
4.1. Описание
4.2. Процессы Проекта
5. Деятельность по интегрированию системы и поставляемые позиции
5.1.1. Работы Этапа I
5.1.2. Поставляемые позиции Этапа I
5.1.3. Работы Этапа II
5.1.4. Поставляемые позиции Этапа II
5.1.5.Работы этапа III
5.1.6. Поставляемые позиции Этапа III
5.1.7. Работы Этапа IV
5.1.8. Поставляемые позиции Этапа IV
5.1.9. Работы Этапа V
5.1.10. Поставляемые позиции Этапа V
6. Графики хода процессов
7. Документация
Пример 2. УСТАВ ПРОЕКТА (международная компания, занимающаяся разработкой и внедрением информационных систем)
СОДЕРЖАНИЕ:
1 ВВЕДЕНИЕ
1.1 НАЗНАЧЕНИЕ ДАННОГО ДОКУМЕНТА
1.2 ИЗМЕНЕНИЯ ДАННОГО ДОКУМЕНТА
2 ОПРЕДЕЛЕНИЕ ПРОЕКТА
2.1 НАЗНАЧЕНИЕ ПРОЕКТА
2.2 ЦЕЛИ ПРОЕКТА
2.3 НЕОБХОДИМЫЕ УСЛОВИЯ ДЛЯ ДОСТИЖЕНИЯ ПОСТАВЛЕННЫХ ЦЕЛЕЙ
3 РАМКИ ПРОЕКТА
3.1 ЛОГИЧЕСКИЕ РАМКИ ПРОЕКТА НА МОМЕНТ ЕГО НАЧАЛА
3.2 ВРЕМЕННЫЕ РАМКИ ПРОЕКТА
4 ОРГАНИЗАЦИЯ И УПРАВЛЕНИЕ ПРОЕКТОМ
4.1 ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2 РАСПРЕДЕЛЕНИЕ РОЛЕЙ УЧАСТНИКОВ ПРОЕКТА
4.2.1 Спонсор Проекта
4.2.2 Управляющий Совет
4.2.3 Председатель Управляющего Совета
4.2.4 Руководители Проекта
4.2.5 Группа внедрения
4.2.6 Состав группы внедрения
4.3 ДОКУМЕНТООБОРОТ ПРОЕКТА
4.3.1 Общие документы
4.3.2 Отчетные документы
4.3.3 Рабочие документы
4.3.4 Периодичность подготовки отчетной документации
4.4 ПРОЦЕДУРА РЕШЕНИЯ ПРОБЛЕМ
4.5 ПОДХОД К УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ РАМОК ПРОЕКТА
5 ЗАВЕРШЕНИЕ ПРОЕКТА
ПРИЛОЖЕНИЕ 1 – ДЕКЛАРАЦИЯ ЦЕЛЕЙ ВНЕДРЕНИЯ ИИСУ НА ОАО «ХХХ»
ПРИЛОЖЕНИЕ 2 – СПИСОК ФУНКЦИЙ АВТОМАТИЗИРУЕМЫХ ПОДРАЗДЕЛЕНИЙ.
ПРИЛОЖЕНИЕ 3 – ФОРМА РЕГИСТРАЦИИ ПРОБЛЕМЫ
ПРИЛОЖЕНИЕ 4 – ЖУРНАЛ РЕГИСТРАЦИИ ПРОБЛЕМ
ПРИЛОЖЕНИЕ 5 – ИНДИВИДУАЛЬНЫЙ ОТЧЕТ О ПРОРАБОТАННОМ ВРЕМЕНИ
ПРИЛОЖЕНИЕ 6 – ОТЧЕТ РУКОВОДИТЕЛЯ ПРОЕКТА
ПРИЛОЖЕНИЕ 7 – РЕГУЛЯРНЫЙ ОТЧЕТ О СОСТОЯНИИ ПРОЕКТА
ПРИЛОЖЕНИЕ 8 – ОТЧЕТ О РЕЗУЛЬТАТАХ ЭТАПА.
Пример 3. УСТАВ ПРОЕКТА (Российская компания – системный интегратор)
СОДЕРЖАНИЕ
1. ПРОФИЛЬ КОМПАНИИ
1.1. СФЕРА ДЕЯТЕЛЬНОСТИ
1.2. АДРЕС КОМПАНИИ
1.3. КОНТАКТНЫЕ ЛИЦА
1.4. СОТРУДНИКИ
2. ЦЕЛИ И ОПРЕДЕЛЕНИЕ ПРОЕКТА
3. ПЛАН ПРОЕКТА
4. СТРУКТУРА ПРОЕКТА
4.1. ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2. КЛЮЧЕВЫЕ РОЛИ И ОТВЕТСТВЕННОСТЬ
4.3. ПРОЦЕДУРЫ ВСТРЕЧ И ПОДГОТОВКИ ОТЧЕТОВ О СОСТОЯНИИ ПРОЕКТА
5. РИСКИ ПРОЕКТА
6. ПЛАН ОБУЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
7. КОНТРОЛЬ ИЗМЕНЕНИЙ И ПРОЦЕДУРЫ ПРИЁМКИ РАБОТ
7.1. УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
7.2. ПРОЦЕДУРЫ ТЕСТИРОВАНИЯ И ПРИЕМКИ РАБОТ
7.3. СТАТУС И СОСТАВ ПРИЕМОЧНОЙ КОМИССИИ
7.4. ПЕРЕДАЧА В ОПЫТНУЮ ЭКСПЛУАТАЦИЮ
8. ЛИСТ СОГЛАСОВАНИЙ
ПРИЛОЖЕНИЯ
Данная статья предназначена для новичков в управлении проектами. Если вы знаете что именно из себя представляет устав проекта, то можете смело пропускать данную статью.
В настоящее время, большинство руководителей проектов знают (по крайней мере, приблизительно) что такое устав проекта. Попробуем разобраться, что же это такое в точности и зачем оно нужно.
Если вы работаете в консалтинговой компании то, скорее всего, вы не сталкиваетесь с необходимостью формирования устава проекта. Наиболее вероятно, что у вас в компании инициация проекта происходит следующим образом:
1. Вы, как руководитель проектов, получили некое сообщение о том, что есть возможность выполнить проект. Это может быть RFP (запрос на предложение), которое вам передали из отдела продаж с просьбой помочь в подготовке коммерческого предложения, а может быть приглашение, пришедшее от вашего руководителя, с назначением на новый проект. В любом случае, вы знаете, что проект начинается.
2. Подготавливается контракт на проект. Вы, проработав примерный список работ и прикинув стоимость, совместно с руководителем заключаете контракт с Заказчиком.
3. Вы начинаете работу.
В данном случае, роль устава проекта выполняет контракт. Он наделяет вас полномочиями, и он же диктует вам рамки проекта. Согласно контракту вы выполняете и оцениваете работу.
В случае, если проект внутренний, необходимо писать устав проекта. Для чего? Причин множество.
Первая и самая простая - устав является формальным объявлением начала проекта. Как вы сможете оценить, сколько длится проект, если вы не знаете, когда именно он начался? С даты подписания устава отсчитывается длительность проекта.
Вторая цель - закрепление полномочий за руководителем проекта. Проект может стартовать, но как вы будете руководить им, если у вас нет полномочий? Обычно, внутри компании, устав проекта подписывается значимым лицом (генеральным директором или его заместителем). Таким образом, получив устав проекта, менеджер проекта формально объявляет, что данный проект это не его личная прихоть, за ним стоит руководитель организации, который считает необходимым выполнить этот проект и для достижения этой цели предоставляет руководителю проекта определенные полномочия.
Третья цель устава проекта - зафиксировать первоначальные цели проекта. Ведь в процессе выполнения проекта, его цели могут меняться, в связи с чем, будут изменяться и сроки. В этом случае, руководитель проекта имеет возможность показать взаимосвязь между изменением целей и изменением сроков.
Четвертая цель устава проекта озвучить руководству в общих чертах риски, связанные с возникновением проекта и с работами на проекте. Когда запускается новый проект, возникают риски с ним связанные. Эти риски опасны не только для самого проекта, но могут быть опасны и для организации в целом. Соответственно, все начальные риски, которые вы идентифицировали, помещаются в устав проекта и озвучиваются руководству.
Часто, в устав проекта добавляют положение о создании управляющего комитета, но это уже индивидуально. Если положение об управляющем комитете не добавлено в устав, его можно включить в другой документ.
Часто устав проекта называют контрактом для внутренних проектов. Это неверно, т.к. устав проекта не служит для фиксирования каких либо договоренностей между сторонами проекта. Он служит только для тех целей, которые я озвучил выше. Не нужно стараться сделать из устава проекта что-то большее - он для этого не предназначен. Попытки напихать в устав проекта как можно больше информации обычно приводят лишь к увеличению сроков согласования устава и противоречиям в документах.
Составляется устав проекта, обычно руководителем проекта, а утверждается Спонсором проекта и Заказчиком проекта.
Успешных вам проектов!
