Руководство по управлению проектом свода законов - Instruktiruet.ru - инструкции по эксплуатации и многое другое

О подготовке свода законов Российской Федерации

Литягин Николай Николаевич — советник отдела Свода законов Управления анализа законодательства Главного государственно — правового управления Президента РФ, доцент.

В условиях осуществляемых в Российской Федерации коренных политических и социально — экономических преобразований, связанных с решением задач по становлению правового государства, особую значимость приобретает создание стройной системы нормативных правовых актов, обеспечивающей необходимую полноту правового регулирования, устранение их множественности и противоречивости. Достижению указанных целей должно способствовать издание Свода законов Российской Федерации, подготовка которого проводится в соответствии с Указом Президента Российской Федерации от 6 февраля 1995 года N 94 и предполагает осуществление ряда крупных мероприятий в области систематизации законодательства. Принципиальные подходы к решению этой задачи известны, имеется опыт создания сводов законов СССР и РСФСР, рекомендации в научной литературе <*>, а также предложения Института законодательства и сравнительного правоведения при Правительстве Российской Федерации, внесенные уже в процессе работы над данным Сводом.

<*> См.: Ветошин М. Кодификация союзного законодательства // Советское строительство, 1929. N 7; Законодательная техника / Под ред. проф. Д.А. Керимова. Л.: Изд-во Ленинградского университета, 1965. С. 129 — 136; Подготовка и издание систематических собраний действующего законодательства / Под ред. А.Н. Мишутина. М.: Юрид. лит., 1969; Казьмин И.Ф., Мицкевич А.В., Рахманина Т.Н. Кодификация и систематизация законодательства на современном

этапе // Советское законодательство: пути перестройки / Отв. ред-ры А.В. Мицкевич, А.С. Пиголкин. М.: Юрид. лит., 1989, и др.

Подготовка Свода законов включает в себя следующие этапы: определение вида актов, подлежащих помещению в Свод, и установление критериев их отбора; разработку схемы Свода законов; инвентаризацию правовых актов, их анализ и исключение из их состава актов, не подлежащих включению в Свод; обработку нормативных правовых актов, отвечающих установленным критериям отбора и включаемых в Свод, размещение их в соответствии со схемой Свода (распределение по разделам, подразделам и другим структурным частям Свода, формирование нормативного корпуса Свода законов); подготовку и внесение предложений о признании нормативных правовых актов, не подлежащих включению в Свод, утратившими силу <*>.

<*> Эта работа может не проводиться, если будет принято решение о том, что нормативно — правовые акты, не вошедшие в Свод, утрачивают силу. Как отмечается в статье И.Ф. Казьмина, А.В. Мицкевича, Т.Н. Рахманиной «Кодификация и систематизация законодательства на современном этапе» (см. предыдущую сноску), оптимальным решением было бы превращение Свода законов в единственный официальный систематический источник действующего законодательства, чтобы действующими считались только те акты, которые помещены в Свод (с. 132).

Остановимся на каждом из этапов работы подробнее.

Виды нормативных правовых актов, подлежащих помещению в Свод, определены проектом Федерального закона «О Своде законов Российской Федерации». Включению в Свод подлежат: Конституция Российской Федерации; федеральные конституционные законы; федеральные законы; нормативные правовые акты Президента Российской Федерации; постановления палат Федерального Собрания нормативного характера; нормативные правовые акты Правительства Российской Федерации; постановления Конституционного Суда Российской Федерации.

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

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

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

В основу структуры Свода законов Российской Федерации может быть положен общеправовой классификатор отраслей законодательства. Как отмечал в этой связи на совещании — семинаре по проблемам подготовки Свода законов Российской Федерации 30 октября 1997 года профессор А.В. Мицкевич, кроме схемы Свода законов, которая еще не утверждена, имеется общеправовой классификатор отраслей законодательства, являющийся официальным источником классификации законодательства. Он может служить рабочим инструментом и для подготовки предложений по Своду законов, хотя между схемой Свода и классификатором имеются существенные различия: схема Свода законов предусматривает классификацию только нормативных правовых актов, а общеправовой классификатор отраслей законодательства — всех правовых актов, включая и ненормативные, то есть является более широким по своему содержанию. Однако ввиду очевидной взаимосвязи между этими правовыми документами работа по совершенствованию общеправового классификатора должна проводиться синхронно с разработкой схемы Свода законов Российской Федерации.

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

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

Инвентаризация правовых актов заканчивается составлением хронологического перечня, в который включаются все акты, подлежащие оценке на предмет их помещения в Свод законов Российской Федерации.

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

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

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

<*> Вывод о признании актов фактически утратившими силу возможен на основе консультаций с заинтересованными федеральными органами исполнительной власти.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа по созданию Свода законов должна быть соответствующим образом организована. Указом Президента Российской Федерации от 6 февраля 1995 года N 94 для решения организационных вопросов была создана Временная комиссия по подготовке к изданию Свода законов Российской Федерации, являвшаяся рабочим органом при Президенте Российской Федерации.

В настоящее время Указ Президента Российской Федерации от 6 февраля 1995 года N 94 в части создания Временной комиссии признан утратившим силу, а организационные основы подготовки и издания Свода законов сформулированы в проекте Федерального закона «О Своде законов Российской Федерации». Для руководства и координации деятельности в этой сфере проектом предусмотрено создание Государственной комиссии по изданию Свода законов Российской Федерации во главе с Президентом Российской Федерации.

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

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

Проект предусматривает участие в подготовке Свода законов федеральных органов исполнительной власти, а также палат Федерального Собрания, Администрации Президента и Аппарата Правительства Российской Федерации, Конституционного Суда Российской Федерации. Существенная роль в организации работы отводится Министерству юстиции Российской Федерации. Вместе с Главным государственно — правовым управлением Президента Российской Федерации Минюст России координирует все формы деятельности федеральных органов исполнительной власти по подготовке Свода законов, осуществляет методическое руководство этой работой.

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

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

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

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

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

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

Для активизации начатой работы по подготовке Свода законов, повышения ее эффективности издан Указ Президента Российской Федерации от 14 февраля 1998 года N 170, которым Министерству юстиции Российской Федерации и Главному государственно — правовому управлению Президента Российской Федерации предложено приступить к формированию нормативного корпуса Свода законов, а федеральным органам исполнительной власти поручено подготовить и представить в Министерство юстиции Российской Федерации и Главное государственно — правовое управление Президента Российской Федерации предложения:

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

Кроме того, в Министерство юстиции Российской Федерации и Главное государственно — правовое управление Президента Российской Федерации поручено представить предложения:

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

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

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

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

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

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

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

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

Неупорядочено употребление таких терминов, как «исключить» и «признать утратившими силу». В некоторых актах используется термин «отменить». Иногда данные термины употребляются в одном и том же акте. Примечательным в этом отношении является Указ Президента Российской Федерации «О признании утратившими силу и об отмене решений Президента Российской Федерации в части предоставления таможенных льгот» от 6 марта 1995 года N 244 (Собрание законодательства Российской Федерации, 1995, N 11, ст. 967).

Смешение понятий допущено здесь не только в названии Указа, но и в названии приложений. Одно из них — приложение N 1 — названо «Акты Президента Российской Федерации, признанные утратившими силу», а другое — приложение N 2 «Отмененные акты Президента Российской Федерации». Этот Указ обращает на себя внимание и явным несоответствием названия и содержания приложений. Ни приложение N 1, ни приложение N 2 практически не содержат актов, признанных утратившими силу. Из 59 актов, указанных в этих приложениях, только три утратили силу, а 56 продолжают действовать (утратили силу лишь отдельные их пункты, подпункты, абзацы).

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

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

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

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

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

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

В настоящее время эта работа проводится на основании распоряжения Президента Российской Федерации от 5 июля 1994 года N 358-рп, которым предусмотрено, что проекты указов Президента Российской Федерации о признании утратившими силу, изменении и дополнении актов Президента в связи с принятием федеральных законов представляются соответствующими руководителями федеральных органов исполнительной власти или структурных подразделений Администрации Президента в месячный срок с момента вступления в силу федерального закона.

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

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

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

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

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

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

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

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

Поскольку признанию утратившими силу, изменению и дополнению подлежат нормативные правовые акты, в методических указаниях следует раскрыть понятие нормативно — правового акта. Для этих целей может быть использовано определение, воспроизведенное в п. 3 распоряжения Президента Российской Федерации от 5 февраля 1993 года N 85-рп, в соответствии с которым под нормативным правовым актом понимается акт, изданный управомоченным на то органом и содержащий правовые нормы, то есть предписания постоянного действия, рассчитанные на многократное применение.

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

В зависимости от вида включаемых в перечни актов составляются перечни актов: законодательных органов Российской Федерации и РСФСР; Президента Российской Федерации; Правительства Российской Федерации, Совета Министров РСФСР и СНК РСФСР; законодательных органов СССР; Совета Министров СССР и СНК СССР. В зависимости от характера предложений формируются: перечни актов, подлежащих признанию утратившими силу; перечни актов, подлежащих изменению и дополнению.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На неупорядоченность работы по официальному опубликованию нормативных правовых актов обратил внимание и Конституционный Суд Российской Федерации (Постановление Конституционного Суда Российской Федерации от 24 октября 1996 года N 17-П «По делу о проверке конституционности части первой статьи 2 Федерального закона от 7 марта 1996 года «О внесении изменений в Закон Российской Федерации «Об акцизах»).

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

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

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

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

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

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

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

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

Источник

Часть 1. Руководство к Своду Знаний по Управлению Проектом (Руководство PMBOK®)

1. Введение

1.1. Обзор и назначение настоящего руководства

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

♦ пирамиды в Гизе,

♦ Олимпийские игры,

♦ Великую китайскую стену,

♦ Тадж-Махал,

♦ издание книги для детей,

♦ Панамский канал,

♦ создание коммерческих реактивных самолетов,

♦ вакцину от полиомиелита,

♦ высадку человека на Луне,

♦ коммерческие компьютерные прикладные программы,

♦ портативные устройства для использования глобальной системы позиционирования (GPS),

♦ выведение международной космической станции на околоземную орбиту.

Практические достижения этих проектов стали результатом применения руководителями и управленцами в своей работе практик, принципов, процессов, инструментов и методов управления проектами. Руководители этих проектов использовали ряд ключевых навыков и применяли знания, необходимые для удовлетворения своих клиентов и других людей, занятых в осуществлении или испытывающих влияние проекта. К середине XX века руководители проектов начали работу с целью добиться признания управления проектами в качестве профессии. Одним из аспектов этой работы стало достижение соглашения в отношении содержания свода знаний (body of knowledge, BOK) под названием «управление проектом» (project management). ВОК становится известным как «Свод знаний по управлению проектом» (Project Management Body of Knowledge, PMBOK). Институт управления проектами (Project Management Institute, PMI) создал базовые схемы и глоссарии для PMBOK. Руководители проектов скоро пришли к пониманию, что PMBOK невозможно полностью уместить в одной книге. Поэтому PMI разработал и опубликовал «Руководство к Своду знаний по управлению проектом» (PMBOK® Guide).

Согласно данному институтом PMI определению, «свод знаний по управлению проектом» (PMBOK) – это понятие, которое описывает знания в области профессии управления проектом. Свод знаний по управлению проектом включает в себя зарекомендовавшие себя и широко используемые традиционные практики, а также недавно появившиеся инновационные практики.

Свод знаний (ВОК) включает как опубликованные, так и неопубликованные материалы. Этот свод знаний постоянно развивается. Настоящее Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектом, которая является общепризнанной хорошей практикой.

♦ Общепризнанные означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их ценности и пользы существует консенсус.

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

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

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

1.1.1. Стандарт управления проектом

В основу настоящего Руководства положен Стандарт управления проектом [1]. Стандарт – это документ, установленный уполномоченным органом, обычаем или по общему согласию в качестве модели или образца. Стандарт управления проектом был разработан как стандарт Американского национального института стандартов (American National Standards Institute, ANSI) с использованием процесса, основанного на принципах консенсуса, открытости, соблюдения процессуальных норм и сбалансированности. Стандарт управления проектом является основополагающим справочным материалом для программ PMI по профессиональному развитию и в практике управления проектом. Поскольку существует необходимость адаптации управления проектом с целью обеспечить соответствие потребностям конкретного проекта, в основу как Стандарта, так и Руководства положены описательные, а не директивные практики. В силу этого настоящий Стандарт определяет процессы, которые являются хорошими практиками при осуществлении большинства проектов в большинстве случаев. Данный Стандарт также определяет входы и выходы, которые обычно связаны с этими процессами. Стандарт не содержит требований об обязательном исполнении тех или иных конкретных процессов или практик. Стандарт управления проектом входит в состав части II Руководства к Своду знаний по управлению проектом (Руководство PMBOK®).

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

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

♦ Стандарт управления портфелем [2], и

♦ Стандарт управления программой [3].

1.1.2. Общий словарь

Общий словарь является существенным элементом любой профессиональной дисциплины. Лексикон терминов управления проектами PMI (PMI Lexicon of Project Management Terms)[1] представляет собой основной словарь профессиональной терминологии, который могут единообразно использовать организации, руководители проектов, программ и портфелей и другие заинтересованные стороны проектов. Лексикон с течением времени будет развиваться. Глоссарий настоящего Руководства включает в себя словарь входящих в Лексикон (Lexicon) терминов, а также дополнительные определения. В проектах могут использоваться другие принятые в конкретных отраслях термины, определение которых дано в отраслевой литературе.

1.1.3. Кодекс профессиональной этики и поведения

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

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

1.2. Основополагающие элементы

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

1.2.1. Проекты

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

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

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

• уникальный продукт, который может быть либо компонентом другого продукта, либо улучшением или исправлением какого-то продукта, либо сам по себе новым конечным продуктом (например, устранением дефекта в конечном продукте);

• уникальная услуга или способность предоставлять услугу (например, бизнес-подразделение, поддерживающее производство или дистрибуцию);

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

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

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

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

В качестве примеров проекта можно привести, среди прочего:

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

• расширение экскурсионных туристических услуг;

• слияние двух организаций;

• совершенствование бизнес-процесса в организации;

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

• разведка нефтяных месторождений в регионе;

• модификация компьютерной программы, используемой в организации;

• проведение исследований для разработки нового производственного процесса;

• строительство здания.

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

• достигнуты цели проекта;

• цели не будут или не могут быть достигнуты;

• финансирование на осуществление проекта исчерпано или больше не может быть выделено;

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

• исчерпаны человеческие или материальные ресурсы;

• проект прекращается по юридическим причинам или соображениям целесообразности.

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

♦ Проекты служат движущей силой изменений. Проекты служат движущей силой изменений в организациях. С точки зрения бизнеса, цель проекта состоит в переходе организации из одного состояния в другое для достижения конкретной цели (см. рис. 1–1). Обычно считается, что до начала проекта организация находится в исходном состоянии. А желаемый результат изменения в ходе осуществления проекта описывается как будущее состояние.

Некоторые проекты могут предполагать создание переходного состояния, когда выполняется несколько вытекающих один из другого шагов для достижения будущего состояния. Результатом успешного завершения проекта является переход организации к будущему состоянию и достижение конкретной цели. Дополнительную информацию по управлению проектом и изменениями смотрите в документе «Управление изменениями в организациях: практическое руководство» (Governance of Portfolios, Programs, and Projects: A Practice Guide) [6].

Рис. 1–1. Переход организации к новому состоянию с помощью проекта

♦ Проекты позволяют создавать бизнес-ценность. PMI определяет бизнес-ценность как чистую, количественно определяемую выгоду, получаемую от бизнес-предприятия. Выгода может быть материальной, нематериальной или и той, и другой. В бизнес-анализе бизнес-ценностью считается полученная выгода в таких формах, как время, деньги, товары или нематериальные активы, в обмен на какое-то вложение. См. «Бизнес-анализ для специалистов-практиков: практическое руководство» (Business Analysis for Practitioners: A Practice Guide, стр. 185)[7].

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

В качестве примеров материальных элементов можно назвать:

• денежные средства,

• акционерный капитал,

• инженерные сети,

• основные средства,

• инструменты,

• долю рынка.

В качестве примеров нематериальных элементов можно назвать:

• гудвилл (деловая репутация и коммерческий опыт),

• узнаваемость марки,

• общественное благо,

• товарные знаки,

• соответствие стратегии,

• репутацию.

♦ Контекст инициации проекта. Руководители организаций инициируют проекты в ответ на факторы, влияющие на состояние дел в их организациях. Существует четыре основных категории данных факторов, которые позволяют лучше понять контекст проекта (см. рис. 1–2):

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

• удовлетворение запросов или потребностей заинтересованных сторон;

• реализация или изменение бизнес- или технологических стратегий;

• создание, совершенствование или исправление продуктов, процессов или услуг.

Рис. 1–2. Контекст инициации проекта.

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

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

Таблица 1–1. Примеры факторов, которые вызывают необходимость в создании проекта.

1.2.2. Важность управления проектом

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

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

♦ достигать бизнес-целей;

♦ удовлетворять ожидания заинтересованных сторон;

♦ быть более предсказуемыми;

♦ повышать вероятность успеха;

♦ поставлять нужный продукт в нужное время;

♦ разрешать проблемы и вопросы;

♦ своевременно реагировать на риски;

♦ оптимизировать использование ресурсов организации;

♦ выявлять, возобновлять или прекращать неудачные проекты;

♦ управлять ограничениями (например, содержанием, качеством, расписанием, стоимостью, ресурсами);

♦ балансировать влияние ограничений на проект (например, увеличение содержания может потребовать увеличения стоимости или сроков);

♦ лучше управлять изменениями.

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

♦ нарушению установленных сроков,

♦ превышению стоимости,

♦ плохому качеству,

♦ доработкам,

♦ бесконтрольному расширению проекта,

♦ репутационным потерям организации,

♦ неудовлетворенности заинтересованных сторон,

♦ неспособности достичь целей, ради которых проект был организован.

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

Результативное и эффективное управление проектом следует считать стратегической компетенцией в организации. Оно позволяет организации:

♦ увязывать результаты проекта с бизнес-целями,

♦ более успешно конкурировать на своих рынках,

♦ добиваться устойчивости своей организации,

♦ реагировать на воздействия изменений бизнес-среды на проекты с помощью надлежащей корректировки планов управления проектами (см. раздел 4.2).

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

1.2.3.1. Общие сведения

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

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

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

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

Рис. 1–3. Портфель, программы, проекты и операционная деятельность

Представление об управлении проектом, программой и портфелем с точки зрения организации:

♦ в центре управления программой и проектом стоит задача осуществления программ и проектов «правильным» образом,

♦ основная задача управления портфелем состоит в осуществлении «правильных» программ и проектов.

В таблице 1–2 представлен сравнительный обзор портфелей, программ и проектов.

Таблица 1–2. Сравнительный обзор управления проектом, программой и портфелем

1.2.3.2. Управление программой

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

♦ приведение в соответствие с организационным или стратегическим направлением, затрагивающим цели и задачи программы и проекта;

♦ распределение содержания программы по ее компонентам;

♦ управление взаимозависимостями между компонентами программы с целью наилучшего удовлетворения потребностей программы;

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

♦ разрешение ограничений и конфликтов, затрагивающих несколько проектов в рамках одной программы;

♦ разрешение проблем между проектами-компонентами и уровнем программы;

♦ управление запросами на изменения в рамках общей структуры руководства;

♦ распределение бюджетных средств на разные проекты в составе программы;

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

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

Дополнительную информацию об управлении программой смотрите в документе «Стандарт по управлению программой» (The Standard for Program Management) [3].

1.2.3.3. Управление портфелем

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

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

Целью управления портфелями является:

♦ выработка решений по инвестициям в организации;

♦ выбор оптимального сочетания программ и проектов для достижения стратегических целей;

♦ обеспечение прозрачности процесса принятия решений;

♦ приоритизация распределения человеческих и материальных ресурсов;

♦ повышение вероятности осуществления желаемой окупаемости инвестиций;

♦ централизация управления совокупным профилем рисков от всех компонентов.

Управление портфелем призвано также соблюсти соответствие портфеля стратегическим задачам организации и согласование с ними.

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

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

Дополнительную информацию об управлении портфелем смотрите в документе «Стандарт по управлению портфелем» (The Standard for Portfolio Management) [2].

1.2.3.4. Управление операционной деятельностью

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

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

1.2.3.5. Управление операционной деятельностью и управление проектом

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

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

♦ в случае разработки нового продукта, усовершенствования продукта или расширения выпуска продукции,

♦ при улучшении операционной деятельности или процесса разработки продукта,

♦ в конце жизненного цикла продукта,

♦ в каждой завершающей фазе.

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

1.2.3.6. Организационное управление проектами (OPM) и стратегии организации

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

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

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

♦ Управление проектом обеспечивает достижение целей и решение задач организации.

Проекты, входящие в состав программ или портфелей, являются средством достижения целей и решения задач организации. Это часто осуществляется в связи со стратегическим планом, который является главным фактором регулирования инвестиций в проекты. Согласованность со стратегическими бизнес-целями организации может быть достигнута в результате систематического управления портфелями, программами и проектами путем применения организационного управления проектами (organizational project management, OPM). По определению, OPM – это модель, в рамках которой осуществляется интеграция управления портфелями, программами и проектами с организационными инструментами реализации в целях достижения стратегических целей.

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

Дополнительную информацию по OPM смотрите в документе «Реализация организационного управления проектами: практическое руководство» (Implementing Organizational Project Management: A Practice Guide) [8].

Рис. 1–4. Организационное управление проектом

1.2.4. Компоненты руководства

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

Краткое описание ключевых компонентов приведено в таблице 1–3. Эти компоненты более полно объясняются в разделах, которые следуют после таблицы.

Таблица 1–3. Описание ключевых компонентов Руководства PMBOK®

Рис. 1–5. Взаимодействие ключевых компонентов Руководства PMBOK® в рамках проекта

1.2.4.1. Жизненный цикл проекта и жизненный цикл развития

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

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

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

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

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

♦ Адаптивные жизненные циклы являются гибкими (agile), итеративными или инкрементными. Подробное содержание определяется и одобряется перед началом каждой итерации. Адаптивные жизненные циклы называют также «гибкими» (agile) или жизненными циклами, управляемыми изменениями. См. Приложение X3.

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

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

♦ определения процесса или процессов, осуществление которых необходимо в каждой фазе;

♦ осуществления процесса или процессов, определенных для каждой фазы;

♦ корректировки различных качеств фазы (например, название, длительность, критерии выхода и критерии входа).

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

1.2.4.2. Фаза проекта

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

♦ название (например, «Фаза А», «Фаза В», «Фаза 1», «Фаза 2», «Фаза подготовки предложения»);

♦ количество (например, три фазы в проекте, пять фаз в проекте);

♦ длительность (например, 1 неделя, 1 месяц, 1 квартал);

♦ требования к ресурсам (например, человеческие ресурсы, сооружения, оборудование);

♦ критерии входа для проекта, чтобы перейти в данную фазу (например, необходимые одобрения задокументированы, необходимые документы разработаны);

♦ критерии выхода для проекта, чтобы завершить данную фазу (например, одобрения задокументированы, документы разработаны, поставляемые результаты завершены).

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

♦ разработка концепции,

♦ анализ целесообразности,

♦ требования заказчика,

♦ разработка решения,

♦ проектирование,

♦ прототипирование,

♦ строительство,

♦ испытания,

♦ передача,

♦ ввод в эксплуатацию,

♦ анализ контрольных событий,

♦ извлеченные уроки.

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

♦ потребности управления;

♦ характер проекта;

♦ уникальные характеристики организации, отрасли или технологии;

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

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

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

1.2.4.3. Ворота фазы

«Ворота фазы» проводятся в конце фазы. Исполнение и прогресс проекта сверяются с документами проекта и бизнес-документами, включая, помимо прочего:

♦ бизнес-кейс проекта (см. раздел 1.2.6.1),

♦ устав проекта (см. раздел 4.1),

♦ план управления проектом (см. раздел 4.2),

♦ план управления выгодами (см. раздел 1.2.6.2).

Решение (например, продолжать или прекратить проект) принимается по результатам данной сверки с целью принятия решения:

♦ перейти к следующей фазе,

♦ перейти к следующей фазе с изменениями,

♦ прекратить проект,

♦ остаться в данной фазе,

♦ повторить фазу или некоторые ее элементы.

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

1.2.4.4. Процессы управления проектом

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

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

♦ либо вход в другой процесс,

♦ либо поставляемый результат проекта или фазы проекта.

На рис. 1–6 показан пример того, как входы, инструменты и методы, а также выходы соотносятся друг с другом в рамках одного процесса и с другими процессами.

Рис. 1–6. Пример процесса: входы, инструменты и методы, выходы

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

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

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

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

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

1.2.4.5. Группы процессов управления проектом

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

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

♦ Группа процессов планирования. Процессы, требуемые для установления содержания работ, уточнения целей и определения направления действий, требуемых для достижения целей проекта.

♦ Группа процессов исполнения. Процессы, выполняемые для исполнения работ, указанных в плане управления проектом, с целью соответствия требованиям проекта.

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

♦ Группа процессов закрытия. Это процессы, выполняемые для формального завершения или закрытия проекта, фазы или договора.

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

1.2.4.6. Области знаний по управлению проектом

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

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

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

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

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

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

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

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

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

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

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

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

Потребности конкретного проекта могут требовать дополнительно одну или несколько областей знаний; например, в строительстве могут потребоваться знания в области финансового управления или управления техникой безопасности и охраной здоровья. В таблице 1–4 сопоставлены группы процессов управления проектом и области знаний. В разделах с 4 по 13 приводятся подробные сведения о каждой области знаний. Таблица ниже содержит обзор основных процессов, описанных в разделах с 4 по 13.

Таблица 1–4. Сопоставление групп процессов управления проектом и областей знаний

1.2.4.7. Данные и информация управления проектом

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

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

♦ Данные об исполнении работ. Необработанные наблюдения и измерения, выявленные во время операций, предпринимаемых для выполнения работ проекта. Примером могут служить: процентные данные о физически выполненной работе, показатели качества и показатели технического исполнения, даты старта и финиша операций по расписанию, количество запросов на изменения, количество дефектов, фактическая стоимость, фактическая длительность и т. д. Данные проекта обычно регистрируются в информационной системе управления проектами (Project Management Information System, PMIS; см. раздел 4.3.2.2) и в документах проекта.

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

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

На рис. 1–7 показан поток информации проекта в рамках различных процессов, используемых для управления проектом.

Рис. 1–7. Поток данных, информации и отчетов проекта

1.2.5. Адаптация

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

Настоящее Руководство и Стандарт управления проектом [1] предлагаются в качестве справочных материалов для дальнейшей адаптации, поскольку данные нормативные документы содержат подмножество свода знаний по управлению проектом, который получил общее признание как хорошая практика. «Хорошая практика» не означает, что описанные знания всегда должны единообразно применяться во всех проектах. Конкретные методологические рекомендации не входят в содержание настоящего Руководства.

Методологии управления проектом могут быть:

♦ разработаны собственными экспертами организации,

♦ приобретены у поставщиков,

♦ получены от профессиональных ассоциаций,

♦ получены от государственных ведомств.

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

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

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

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

1.2.6. Бизнес-документы управления проектом

Руководителю проекта необходимо сделать так, чтобы подход к управлению проектом учитывал предназначение бизнес-документов. Определение этих документов приводится в таблице 1–5. Эти два документа зависят друг от друга, разрабатываются итеративно и ведутся на всем протяжении жизненного цикла проекта.

Таблица 1–5. Бизнес-документы проекта

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

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

Рис. 1–8. Взаимосвязи оценки потребностей и наиболее важных документов проекта/бизнес-документов

1.2.6.1. Бизнес-кейс проекта

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

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

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

♦ Бизнес-потребности:

• определение причин необходимости действий;

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

• идентификация заинтересованных сторон, на которых будет оказано влияние;

• определение содержания.

♦ Анализ ситуации:

• определение стратегий, целей и задач организации;

• определение основных причин проблемы или главных источников благоприятной возможности;

• анализ необходимых для проекта возможностей в сравнении с существующими возможностями организации;

• идентификация известных рисков;

• идентификация критически важных факторов успеха;

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

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

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

• Желательные. Это критерии, исполнение которых желательно для решения проблемы или использования благоприятной возможности.

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

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

• Ничего не делать. Этот вариант действий называют также «бизнес как обычно». Выбор этого варианта действий ведет к отказу в авторизации проекта.

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

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

♦ Выработка рекомендаций:

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

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

• результаты анализа возможных вариантов действий;

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

• показатели успеха (см. раздел 1.2.6.4);

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

• контрольные события,

• зависимости,

• роли и сферы ответственности.

♦ Оценка:

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

Документ бизнес-кейса дает основу для количественной оценки успеха проекта и хода его исполнения в течение всего жизненного цикла проекта путем сравнения результатов с целями и определенными критериями успеха. См. документ «Бизнес-анализ для специалистов-практиков: практическое руководство» (Business Analysis for Practitioners: A Practice Guide) [7].

1.2.6.2. План управления выгодами проекта

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

♦ Целевые выгоды (например, ожидаемые материальные и нематериальные ценности, которые предполагается получить в результате реализации проекта; финансовая ценность выражается в чистой приведенной стоимости).

♦ Приведение в соответствие со стратегией (например, насколько выгоды от проекта согласуются с бизнес-стратегиями организации).

♦ Сроки реализации выгод (например, выгоды по фазам, в долгосрочной и краткосрочной перспективе, текущие выгоды).

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

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

♦ Допущения (например, факторы, которые, как ожидается, должны быть в наличии или наблюдаться).

♦ Риски (например, риски для реализации выгод).

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

Разработка и ведение плана управления выгодами проекта является итеративной деятельностью. Данный документ дополняет бизнес-кейс, устав проекта и план управления проектом. Руководитель проекта ведет работу со спонсором, цель которой заключается в том, чтобы устав проекта, план управления проектом и план управления выгодами оставались согласованными друг с другом на всем протяжении жизненного цикла проекта. См. документы «Бизнес-анализ для специалистов-практиков: практическое руководство» (Business Analysis for Practitioners: A Practice Guide) [7], «Стандарт управления программой» (The Standard for Program Management) [3] и «Стандарт управления портфелем» (The Standard for Portfolio Management) [2].

1.2.6.3. Устав проекта и план управления проектом

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

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

Дополнительную информацию об уставе проекта и плане управления проектом смотрите в разделе 4, посвященном управлению интеграцией проекта.

1.2.6.4. Показатели успеха проекта

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

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

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

♦ Как выглядит успех для данного проекта?

♦ Как будет измеряться успех?

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

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

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

♦ исполнение плана управления выгодами проекта;

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

• чистую приведенную стоимость (net present value, NPV);

• окупаемость инвестиций (return on investment, ROI);

• внутреннюю норму доходности (internal rate of return, IRR);

• период окупаемости инвестиций (payback period, PBP);

• отношение выгод к затратам (beneft-cost ratio, BCR);

♦ достижение нефинансовых целей бизнес-кейса;

♦ совершение перехода организации из исходного состояния к будущему состоянию;

♦ исполнение условий и положений договора;

♦ исполнение стратегий, целей и задач организации;

♦ обеспечение удовлетворенности заинтересованных сторон;

♦ удовлетворительная приемка заказчиком/конечным пользователем;

♦ интеграция поставляемых результатов в операционную среду организации;

♦ обеспечение согласованного качества поставляемого продукта;

♦ исполнение критериев руководства;

♦ достижение других согласованных показателей или критериев успеха (например, производительность процесса).

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

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

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

2. Среда, в которой осуществляется проект

2.1. Общие сведения

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

Источником ФСП является внешняя по отношению к проекту и часто внешняя по отношению к предприятию среда. ФСП могут оказывать воздействие на уровне организации, портфеля, программы или проекта. Дополнительную информацию по ФСП смотрите в разделе 2.2.

АПО являются внутренними по отношению к организации. Их источником может быть сама организация, портфель, программа, другой проект или их сочетание. На рис. 2–1 показана разбивка влияний проекта на ФСП и АПО. Дополнительную информацию по АПО смотрите в разделе 2.3.

Рис. 2–1. Влияния проекта

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

2.2. Факторы среды предприятия

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

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

2.2.1. ФСП, внутренние для организации

Описанные ниже ФСП являются для организации внутренними:

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

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

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

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

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

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

2.2.2. ФСП, внутренние для организации

Описанные ниже ФСП являются для организации внешними:

♦ Ситуация на рынке. Примерами могут служить: конкуренты, доля рынка, узнаваемость бренда и товарные знаки.

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

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

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

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

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

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

♦ Материальные элементы среды. Примерами могут служить: производственные условия, погодные условия и ограничения.

2.3. Активы процессов организации

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

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

♦ процессы, политики и процедуры,

♦ базы знаний организации.

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

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

2.3.1. Процессы, политики и процедуры

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

♦ Инициация и планирование:

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

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

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

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

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

♦ Исполнение, мониторинг и контроль:

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

• матрицы отслеживания;

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

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

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

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

• процедуры приоритизации, одобрения и авторизации работ;

• шаблоны (например, реестр рисков, журнал проблем и журнал изменений);

• типовые руководящие указания, рабочие инструкции, критерии оценки предложений и критерии измерения исполнения;

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

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

2.3.2. Репозитории знаний организации

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

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

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

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

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

♦ репозитории данных по метрикам, используемым для сбора и обеспечения доступа к данным измерений по процессам и продуктам;

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

2.4. Организационные системы

2.4.1. Общие сведения

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

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

♦ элементы управления,

♦ модель руководства,

♦ типы организационной структуры.

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

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

♦ системы являются динамическими;

♦ системы можно оптимизировать;

♦ компоненты системы можно оптимизировать;

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

♦ реакция системы не является прямолинейной (изменение на входе в систему не производит прогнозируемого изменения на выходе из нее).

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

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

2.4.2. Модели руководства организации

Недавнее исследование PMI показывает, что понятие «руководство» означает организационное или структурное устройство организации на всех ее уровнях, цель которого определять и влиять на поведение членов организации [9]. Из указанного исследования следует вывод, что концепция руководства является многоплановой и:

♦ включает в себя соображения о людях, функциях, структурах и политиках;

♦ требует обеспечения указаний и надзора на основе данных и обратной связи.

2.4.2.1. Модель руководства

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

♦ правила,

♦ политики,

♦ процедуры,

♦ нормы,

♦ отношения,

♦ системы,

♦ процессы.

Данная модель оказывает влияние на то, как:

♦ устанавливаются и достигаются цели организации,

♦ осуществляется мониторинг и оценка рисков,

♦ осуществляется оптимизация исполнения.

2.4.2.2. Руководство портфелями, программами и проектами

В документе «Руководство портфелями, программами и проектами: практическое руководство» (Governance of Portfolios, Programs, and Projects: A Practice Guide) [10] описывается наиболее распространенная модель руководства, согласующая организационное управление проектами (OPM) с управлением портфелями, программами и проектами. В данном практическом руководстве описаны четыре области руководства: приведение в соответствие, риск, исполнение и коммуникации. Каждая из указанных областей имеет следующие функции: надзор, контроль, интеграция и принятие решений. Каждая из этих функций обеспечивается вспомогательными процессами и действиями для самостоятельных проектов или проектов, осуществляемых в средах портфелей или программ.

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

Дополнительную информацию в отношении руководства проектами, включая его реализацию, см. в документе «Руководство портфелями, программами и проектами: практическое руководство» (Governance of Portfolios, Programs, and Projects: A Practice Guide) [10].

2.4.3. Элементы управления

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

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

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

♦ полномочия, предоставленные для производства работ;

♦ ответственность за производство работ распределяется надлежащим образом с учетом таких качеств, как профессиональные навыки и опыт;

♦ дисциплина поведения (например, уважение к власти, людям и правилам);

♦ единоначалие (то есть только один человек отдает приказы на совершение любых операций или действий другому лицу);

♦ единство руководства (то есть существует только один план и один руководитель для группы мероприятий, имеющих общую цель);

♦ общие цели организации имеют приоритет над индивидуальными;

♦ справедливая оплата за выполненную работу;

♦ оптимальное использование ресурсов;

♦ четкие каналы коммуникации;

♦ правильные материалы для правильного лица для правильной работы в правильное время;

♦ справедливое и равноправное отношение к людям на рабочем месте;

♦ гарантия сохранения должности;

♦ безопасность людей на рабочих местах;

♦ открытый вклад каждого человека в планирование и исполнение;

♦ оптимальный моральный климат.

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

2.4.4. Типы организационных структур

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

2.4.4.1. Типы организационных структур

Организационные структуры имеют много форм или типов. В таблице 2–1 приведено сравнение типов организационных структур и их влияния на проекты.

2.4.4.2. Факторы выбора организационной структуры

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

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

♦ степень согласованности с целями организации,

♦ возможности специализации,

♦ уровень эффективности и результативности контроля,

♦ четкий путь эскалации для принятия решений,

♦ четкие границы и содержание полномочий,

♦ возможности делегирования,

♦ назначение подотчетности,

♦ назначение ответственности,

♦ возможность адаптации структуры,

♦ простота структуры,

♦ эффективность работы,

♦ учет затрат,

♦ физическое местонахождение (например, совместное, региональное или виртуальное расположение),

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

Таблица 2–1. Влияние организационных структур на проекты

* ОУП – это офис или организация управления портфелем, программой или проектом.

2.4.4.3. Офис управления проектом

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

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

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

♦ Контролирующий. Контролирующие ОУП предоставляют поддержку и требуют соответствия требованиям с помощью различных средств. Степень контроля со стороны ОУП средняя. Обеспечение соответствия может потребовать:

• адаптация моделей или методологий управления проектом;

• использования особых шаблонов, форм и инструментов;

• обеспечения соответствия моделям руководства.

♦ Руководящий. Руководящие ОУП контролируют проекты путем непосредственного управления данными проектами. Руководители проекта назначаются ОУП и подотчетны ему. Степень контроля со стороны ОУП высокая.

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

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

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

♦ давать рекомендации,

♦ руководить передачей знаний,

♦ прекращать проекты,

♦ совершать по мере необходимости другие операции.

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

♦ управление общими ресурсами всех проектов, администрируемых ОУП;

♦ определение и разработка методологии, лучших практик и стандартов управления проектом;

♦ коучинг, наставничество, обучение и надзор;

♦ мониторинг соответствия стандартам, политикам, процедурам и шаблонам управления проектом посредством аудитов проектов;

♦ разработка и управление политиками, процедурами, шаблонами проекта и другой общей документацией (активами процессов организации);

♦ координация коммуникаций между проектами.

3. Роль руководителя проекта

3.1. Общие сведения

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

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

♦ Состав и роли. В составе участников большого проекта и оркестра имеется много членов, каждый из которых играет свою особую роль. В большом оркестре под управлением дирижера может играть более 100 музыкантов. Эти музыканты могут использовать 25 разных типов инструментов, разбитых на основные группы, такие как струнные, деревянные и медные духовые, а также ударные инструменты. Таким же образом, в работе над крупным проектом под управлением руководителя проекта может находиться более 100 участников проекта. Члены команды проекта могут выполнять разные функции, такие как проектирование, изготовление и управление средствами производства. Как и основные группы оркестра, они представляют различные бизнес-подразделения или группы в организации. Музыканты и члены проекта составляют команду каждого из руководителей.

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

♦ Знания и навыки.

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

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

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

3.2. Определение руководителя проекта

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

3.3. Сфера влияния руководителя проекта

3.3.1. Общие сведения

Руководители проектов выполняют многочисленные роли в своей сфере влияния. Эти роли отражают возможности руководителя проекта и показывают ценность и вклад профессии управления проектом. В данном разделе освещаются роли руководителя проекта в различных сферах влияния, которые показаны на рис. 3–1.

Рис. 3–1. Примеры сфер влияния руководителя проекта

3.3.2. Проект

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

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

Исследования показывают, что успешные руководители проекта последовательно и результативно используют некоторые фундаментальные навыки. Исследования позволяют прийти к выводу, что отличительной чертой лучших 2 % руководителей проектов, согласно отзывам их начальников и членов команд, является наличие у них превосходных навыков формирования личных отношений и общения с людьми при одновременной демонстрации позитивного отношения [12].

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

♦ выработку отточенных навыков с использованием различных способов (например, вербальных, письменных и невербальных);

♦ создание, ведение и соблюдение планов и расписаний коммуникаций;

♦ осуществление коммуникаций предсказуемо и последовательно;

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

♦ способность сделать способы коммуникаций краткими, ясными, полными, простыми, релевантными и адаптированными;

♦ включение важных позитивных и негативных новостей;

♦ включение в систему коммуникаций каналов обратной связи;

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

3.3.3. Организация

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

♦ спрос на одни и те же ресурсы,

♦ приоритеты финансирования,

♦ получение или распределение поставляемых результатов,

♦ согласование целей и задач проекта с целями и задачами организации.

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

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

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

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

♦ укреплять признание управления проектом в организации;

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

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

3.3.4. Отрасль

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

♦ развитие продуктов и технологий;

♦ новые и меняющиеся ниши на рынке;

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

♦ инструменты технической поддержки;

♦ экономические силы, которые оказывают влияние на текущий проект;

♦ влияния, воздействующие на дисциплину управления проектом;

♦ стратегии совершенствования процессов и устойчивости.

3.3.5. Профессиональная дисциплина

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

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

♦ участие в обучении, непрерывное образование и развитие:

• в профессии управления проектом (например, университеты, PMI);

• в смежной профессии (например, системная инженерия, управление конфигурацией);

• в других профессиях (например, информационные технологии, авиакосмическая отрасль).

3.3.6. В других дисциплинах

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

3.4. Компетенции руководителя проекта

3.4.1. Общие сведения

В недавних исследованиях PMI к навыкам, необходимым руководителям проектов, была применена «Модель развития компетенций менеджера проекта» (Project Manager Competency Development (PMCD) Framework) через «треугольник талантов PMI®» (PMI Talent Triangle®), который изображен на рис. 3–2. Треугольник талантов описывает три ключевые группы навыков, а именно:

♦ Техническое управление проектами. Знания, навыки и типы поведения, относящиеся к конкретным областям управления проектом, программой и портфелем. Технические аспекты исполнения порученной роли.

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

♦ Стратегическое управление и управление бизнесом. Знания, профессиональная квалификация и опыт работы в отрасли и организации, которые улучшают исполнение и дают более высокие бизнес-результаты.

Рис. 3–2. Треугольник талантов PMI® [11]

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

3.4.2. Навыки технического управления проектами

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

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

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

• наиболее важные факторы успеха для данного проекта,

• расписание,

• определенные финансовые отчеты,

• журнал проблем.

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

♦ Найти время для тщательного планирования и приоритизации задач самым добросовестным образом.

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

3.4.3. Навыки стратегического управления и управления бизнесом

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

♦ объяснить другим важнейшие аспекты бизнеса, связанные с проектом;

♦ вести работу со спонсором, командой и экспертами предметной области по данному проекту с целью разработки соответствующей стратегии реализации проекта;

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

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

♦ стратегию;

♦ миссию;

♦ цели и задачи;

♦ продукты и услуги;

♦ операционную деятельность (например, месторасположение, тип, технологию);

♦ рынок и положение на рынке, например, заказчиков, состояние рынка (то есть рост или спад) и факторы времени выпуска продукта на рынок и т. п.;

♦ конкуренцию (т. е. что, кто, положение на рынке).

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

♦ стратегии;

♦ миссии;

♦ целей и задач;

♦ приоритетов;

♦ тактики;

♦ продуктов или услуг (например, поставляемых результатов).

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

♦ риски и проблемы;

♦ финансовые последствия;

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

♦ бизнес-ценность;

♦ ожидания и стратегии реализации выгод;

♦ содержание, бюджет, расписание и качество.

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

3.4.4. Навыки лидерства

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

3.4.4.1. Работа с людьми

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

3.4.4.2. Качества и навыки лидера

Исследования показывают, что качества и навыки лидера включают в себя, среди прочего:

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

♦ оптимистический и позитивный настрой;

♦ способность к сотрудничеству;

♦ управление отношениями и конфликтами путем:

• построения доверительных отношений;

• разрешения волнующих других людей вопросов;

• стремления к достижению соглашения;

• умения сбалансировать конфликтующие и противоположные цели;

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

• развития и постоянного расширения личных и профессиональных сетей общения;

• принятия точки зрения, что отношения не менее важны, чем сам проект;

• постоянного развития и использования на практике политической дальновидности.

♦ коммуникации путем:

• выделения достаточного времени для коммуникаций (исследования показывают, что лучшие руководители проектов тратят около 90 % своего рабочего времени по проекту на коммуникации);

• управления ожиданиями;

• принятия обратной связи с признательностью;

• предоставления обратной связи в конструктивном ключе;

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

♦ уважительное отношение (помощь другим сохранять свою самостоятельность), вежливость, дружелюбие, доброта, честность, доверительность, лояльность и соблюдение этических норм;

♦ демонстрация высоких моральных качеств, умение учитывать культурные особенности, смелость, умение решать проблемы и принимать решения;

♦ отдавать должное другим людям, когда необходимо;

♦ учеба на протяжении всей жизни с ориентацией на результат и действие;

♦ фокус на важных вещах, в том числе:

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

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

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

• постоянное внимание к основным ограничениям проекта;

• сохранение гибкости в отношении тактических приоритетов;

• способность обрабатывать большие массивы информации для получения наиболее важной информации.

♦ наличие целостного и систематического представления о проекте; учет в равной мере внутренних и внешних факторов;

♦ способность применять критическое мышление (например, аналитических методов для принятия решений) и осознавать себя как источник перемен;

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

3.4.4.3. Политика, власть и получение результата

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

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

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

♦ должностная (иногда ее называют «формальной», «авторитарной», «законной») (например, в силу официальной должности, занимаемой в организации или команде);

♦ информационная (например, контроль за сбором и распределением информации);

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

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

♦ личностная или харизматическая (например, в силу личной привлекательности или обаяния);

♦ основанная на связях (например, участие в социальных сетях, связях и объединениях);

♦ экспертная (например, благодаря навыкам, владению информацией, опыту, профессиональной подготовке, образованию, сертификации);

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

♦ карательная или принудительная (например, способность наложить дисциплинарное взыскание или причинить другие нежелательные последствия);

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

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

♦ основанная на чувстве вины (например, наложение обязательств или привитие чувства долга);

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

♦ основанная на уклонении (например, отказ от участия).

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

3.4.5. Сравнение лидерства и управления

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

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

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

Таблица 3–1. Сравнение управления командой с лидерством в команде

3.4.5.1. Стили лидерства

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

♦ характеристики лидера (например, позиции, настроения, потребности, ценности, этические убеждения);

♦ характеристики членов команды (например, позиции, настроения, потребности, ценности, этические убеждения);

♦ характеристики организации (например, ее назначение, структура и вид производимых работ);

♦ характеристики окружающей среды (например, социальная обстановка, экономическая ситуация и политические элементы).

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

♦ либеральный (например, разрешение членам команды свободно принимать собственные решения и самостоятельно определять цели; называется также «анархическим» стилем);

♦ транзакционный (например, при распределении вознаграждений основное внимание уделяется целям, отдаче и достижениям; то же, что «управление по отклонениям»);

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

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

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

♦ интерактивный (например, комбинация транзакционного, трансформационного и харизматического стилей).

3.4.5.2. Индивидуальность

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

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

♦ вежливость (например, способность правильно вести себя и применять нормы этикета);

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

♦ культурные особенности (например, определенная мера чуткости к другим культурам, включая их ценности, нормы и убеждения);

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

♦ интеллектуальность (например, мера человеческого интеллекта по различным сферам его применения);

♦ управленческие качества (например, определенная мера управленческой практики и управленческого потенциала);

♦ политические способности (например, оценка политического интеллекта и способность добиваться достижения целей);

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

♦ социальность (например, способность понимать людей и управлять ими);

♦ способность к систематизации (например, способность понимать и создавать системы).

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

3.5. Осуществление интеграции

Роль руководителя проекта при осуществлении интеграции проекта является двойственной.

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

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

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

3.5.1. Осуществление интеграции на уровне процессов

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

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

3.5.2. Интеграция на когнитивном уровне

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

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

3.5.3. Интеграция на контекстном уровне

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

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

3.5.4. Интеграция и сложность

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

Сложность в проектах является результатом поведения системы организации, поведения людей и неопределенности, существующей в организации или в окружающей среде. В документе «Работа в сложных условиях: практическое руководство» (Navigating Complexity: A Practice Guide) [13], эти три измерения сложности определены следующим образом:

♦ Поведение системы. Факторы взаимозависимости компонентов и систем.

♦ Поведение человека. Взаимодействие между разными людьми и группами.

♦ Неопределенность. Неопределенность возникающих проблем и отсутствие понимания или путаница.

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

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

♦ содержащий множество частей;

♦ имеющий ряд связей между частями;

♦ демонстрирующий динамические взаимодействия между частями;

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

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

4. Управление интеграцией проекта

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

♦ распределения ресурсов,

♦ нахождения баланса конкурирующих требований,

♦ изучения альтернативных подходов,

♦ адаптации процессов для достижения целей проекта,

♦ управления взаимозависимостями между областями знаний по управлению проектом.

Управление интеграцией проекта включает следующие процессы:

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

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

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

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

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

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

4.7. Закрытие проекта или фазы – это процесс завершения всех операций по проекту, фазе или договору.

На рис. 4–1 представлена общая схема процессов управления интеграцией проекта. Процессы управления интеграцией проекта представляются в виде дискретных процессов с определенными границами, хотя на практике они накладываются и взаимодействуют такими способами, которые не могут быть в полной мере детализированы в Руководстве PMBOK®.

Рис. 4–1. Общая схема управления интеграцией проекта

КЛЮЧЕВЫЕ КОНЦЕПЦИИ УПРАВЛЕНИЯ ИНТЕГРАЦИЕЙ ПРОЕКТА

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

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

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

В задачи управления интеграцией проекта входит:

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

♦ предоставление плана управления проектом для достижения целей проекта;

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

♦ управление ходом работ и изменениями операций, предусмотренных планом управления проектом;

♦ принятие интегрированных решений в отношении ключевых изменений, влияющих на проект;

♦ измерение и мониторинг прогресса проекта, а также выполнение необходимых действий для достижения целей проекта;

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

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

♦ управление переходом от фазы к фазе по мере необходимости.

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

ТЕНДЕНЦИИ И ВНОВЬ ПОЯВЛЯЮЩИЕСЯ ПРАКТИКИ В ОБЛАСТИ УПРАВЛЕНИЯ ИНТЕГРАЦИЕЙ ПРОЕКТА

Область знаний «управление интеграцией проекта» требует объединения результатов, полученных во всех других областях знаний. Развивающиеся тенденции в процессах интеграции включают в себя, среди прочего:

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

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

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

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

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

СООБРАЖЕНИЯ ПО АДАПТАЦИИ

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

♦ Жизненный цикл проекта. Что такое целесообразный жизненный цикл проекта? Какие фазы должен включать жизненный цикл проекта?

♦ Жизненный цикл разработки. Какой жизненный цикл разработки и подход к ней являются целесообразными для данного продукта, услуги или результата? Какой подход является целесообразным – предиктивный или адаптивный? Если адаптивный, то как следует разрабатывать продукт – инкриментно или итеративно? Или лучше использовать гибридный подход?

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

♦ Управление знаниями. Как будет осуществляться управление знаниями в целях поощрения формирования совместной рабочей среды?

♦ Изменение. Как будет осуществляться управление изменениями в проекте?

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

♦ Извлеченные уроки. Какую информацию следует собирать в ходе реализации и по завершении проекта? Как историческая информация и извлеченные уроки будут доводиться до персонала будущих проектов?

♦ Выгоды. Когда и как предоставляется отчетность о выгодах – в конце проекта или по окончании каждой итерации или фазы?

СООБРАЖЕНИЯ ДЛЯ ГИБКИХ/АДАПТИВНЫХ СРЕД

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

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

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

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

Рис. 4–2. Разработка устава проекта: входы, инструменты и методы, выходы

Рис. 4–3. Разработка устава проекта: диаграмма потоков данных

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

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

4.1.1. Разработка устава проекта: входы

4.1.1.1. Бизнес-документы

Источниками информации о целях проекта и его вкладе в достижение бизнес-целей являются бизнес-кейс (см. описание в разделе 1.2.6.1) и план управления выгодами (см. описание в разделе 1.2.6.2). Хотя разработка бизнес-документов производится до начала осуществления проекта, они время от времени пересматриваются.

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

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

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

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

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

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

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

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

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

4.1.1.2. Соглашения

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

4.1.1.3. Факторы среды предприятия

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

♦ государственные или промышленные стандарты (например, стандарты на продукты, стандарты качества, правила техники безопасности и производственные стандарты);

♦ юридические или регуляторные требования и/или ограничения;

♦ ситуацию на рынке;

♦ культуру организации и политический климат;

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

♦ ожидания заинтересованных сторон и пороги риска.

4.1.1.4. Активы процессов организации

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

♦ стандартные политики, процессы и процедуры организации;

♦ модель руководства портфелем, программой и проектом (функции руководства и процессы для обеспечения управления и принятия решений);

♦ методы мониторинга и отчетности;

♦ шаблоны (например, шаблон устава проекта);

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

4.1.2. Разработка устава проекта: инструменты и методы

4.1.2.1. Экспертная оценка

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

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

♦ стратегия организации,

♦ управление выгодами,

♦ отраслевые технические знания и главная область проекта,

♦ оценка длительности и бюджета,

♦ идентификация рисков.

4.1.2.2. Сбор данных

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

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

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

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

4.1.2.3. Навыки межличностных отношений и работы с командой

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

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

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

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

4.1.2.4. Совещания

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

4.1.3. Разработка устава проекта: выходы

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

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

♦ назначение проекта;

♦ измеримые цели проекта и соответствующие критерии успеха;

Источник

Текущая страница: 1 (всего у книги 60 страниц) [доступный отрывок для чтения: 12 страниц]

Руководство к Своду знаний по управлению проектами (Руководство PMBOK)

Библиографическая запись Библиотеки Конгресса США

Названия: Институт управления проектами (Project Management Institute, PMI), издатель.

Заголовок: Руководство к своду знаний по управлению проектом (Руководство PMBOK) (A guide to the project management body of knowledge (PMBOK guide) / Институт управления проектами.

Другие заголовки: Руководство PMBOK

Описание: Шестое издание | Newtown Square, PA: Project Management Institute, 2017. | Серия: Руководство PMBOK |

Включает библиографические ссылки и указатель

Идентификаторы: LCCN 2017032505 (print) | LCCN 2017035597 (ebook) | ISBN 9781628253900 (ePUP) |

ISBN 9781628253917 (kindle) | ISBN 9781628253924 (Web PDF) | ISBN 9781628251845 (paperback)

Тематика: LCSH: Управление проектом (Project management). | BISAC: БИЗНЕС И ЭКОНОМИКА / Управление проектом (BUSINESS & ECONOMICS / Project Management).

Классификация: LCC HD69.P75 (ebook) | LCC HD69.P75 G845 2017 (print) | DDC 658.4/04-dc23

Запись LC доступна на веб-сайте https://lccn.loc.gov/2017032505

ISBN: 978-1-62825-193-7

Опубликовано:

Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, Pennsylvania 19073-3299 США

Телефон: +1 610-356-4600

Факс: +1 610-356-4647

Эл. почта: [email protected]

Веб-сайт: https://www.PMI.org

Материалы Project Management Institute, Inc. охраняются авторским правом в соответствии с законом США об интеллектуальной собственности, который признан в большинстве стран. Для переиздания или воспроизведения материалов PMI вам необходимо получить наше разрешение. Для получения более подробной информации посетите http://www.pmi.org/permissions_for_details.

Для размещения торгового заказа или получения информации о расценках обратитесь в Independent Publishers Group:

Independent Publishers Group

Order Department

814 North Franklin Street

Chicago, IL 60610 США

Телефон: +1 800-888-4741

Факс: +1 312-337-5985

Эл. почта: [email protected] (только для заказов)

По всем остальным вопросам обращайтесь в PMI Book Service Center.

PMI Book Service Center

P.O. Box 932683, Atlanta, GA 31193-2683 USA

Телефон: 1-866-276-4764 (в США или Канаде) или +1-770-280-4129 (по всему миру)

Факс: +1-770-280-4113

Эл. почта: [email protected]

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

PMI, логотип PMI, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSION и девиз MAKING PROJECT MANAGEMENT INDISPENSABLE FOR BUSINESS RESULTS. являются товарными знаками Project Management Institute, Inc. Для получения полного списка товарных знаков PMI обратитесь в юридический отдел PMI. Все остальные товарные марки, знаки обслуживания, торговые наименования, торговое оформление, названия продуктов и логотипы, появляющиеся в данном документе, являются собственностью их соответствующих владельцев. Любые права, не переданные в явной форме в настоящем документе, принадлежат владельцу авторского права.

Уведомление

Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах.

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

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

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

Часть 1. Руководство к Своду Знаний по Управлению Проектом (Руководство PMBOK®)

1. Введение

1.1 Обзор и назначение настоящего руководства

♦ пирамиды в Гизе,

♦ Олимпийские игры,

♦ Великую китайскую стену,

♦ Тадж-Махал,

♦ издание книги для детей,

♦ Панамский канал,

♦ создание коммерческих реактивных самолетов,

♦ вакцину от полиомиелита,

♦ высадку человека на Луне,

♦ коммерческие компьютерные прикладные программы,

♦ портативные устройства для использования глобальной системы позиционирования (GPS),

♦ выведение международной космической станции на околоземную орбиту.

1.1.1 Стандарт управления проектом

♦ Стандарт управления портфелем [2], и

♦ Стандарт управления программой [3].

1.1.2 Общий словарь

Общий словарь является существенным элементом любой профессиональной дисциплины. Лексикон терминов управления проектами PMI (PMI Lexicon of Project Management Terms) [4] представляет собой основной словарь профессиональной терминологии, который могут единообразно использовать организации, руководители проектов, программ и портфелей и другие заинтересованные стороны проектов. Лексикон с течением времени будет развиваться. Глоссарий настоящего Руководства включает в себя словарь входящих в Лексикон (Lexicon) терминов, а также дополнительные определения. В проектах могут использоваться другие принятые в конкретных отраслях термины, определение которых дано в отраслевой литературе.

1.1.3 Кодекс профессиональной этики и поведения

1.2 Основополагающие элементы

1.2.1 Проекты

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

В качестве примеров проекта можно привести, среди прочего:

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

• расширение экскурсионных туристических услуг;

• слияние двух организаций;

• совершенствование бизнес-процесса в организации;

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

• разведка нефтяных месторождений в регионе;

• модификация компьютерной программы, используемой в организации;

• проведение исследований для разработки нового производственного процесса;

• строительство здания.

• достигнуты цели проекта;

• цели не будут или не могут быть достигнуты;

• финансирование на осуществление проекта исчерпано или больше не может быть выделено;

• исчерпаны человеческие или материальные ресурсы;

• проект прекращается по юридическим причинам или соображениям целесообразности.

Рис. 1–1. Переход организации к новому состоянию с помощью проекта

В качестве примеров материальных элементов можно назвать:

• денежные средства,

• акционерный капитал,

• инженерные сети,

• основные средства,

• инструменты,

• долю рынка.

В качестве примеров нематериальных элементов можно назвать:

• гудвилл (деловая репутация и коммерческий опыт),

• узнаваемость марки,

• общественное благо,

• товарные знаки,

• соответствие стратегии,

• репутацию.

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

• удовлетворение запросов или потребностей заинтересованных сторон;

• реализация или изменение бизнес– или технологических стратегий;

• создание, совершенствование или исправление продуктов, процессов или услуг.

Рис. 1–2. Контекст инициации проекта.

Таблица 1–1. Примеры факторов, которые вызывают необходимость в создании проекта.

Источник

________________________________________________________________________________________________

Оглавление

1. ВВЕДЕНИЕ

2. ВЛИЯНИЕ ОРГАНИЗАЦИИ И ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА

3. ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТОМ

4. УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА

5. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА

6. УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА

7. УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА

8. УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОЕКТА

9. УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ ПРОЕКТА

10. УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ ПРОЕКТА

11. УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА

12. УПРАВЛЕНИЕ ЗАКУПКАМИ ПРОЕКТА

13. УПРАВЛЕНИЕ ЗАИНТЕРЕСОВАННЫМИ СТОРОНАМИ ПРОЕКТА

1. ВВЕДЕНИЕ

Проект — это
временное предприятие, направленное на создание уникального продукта, услуги
или результата.

Проект может создать:

·
продукт,
представляющий собой компонент другого изделия, улучшение изделия или конечное
изделие;

·
услугу
или способность предоставлять услугу (например, бизнес-функция, поддерживающая
производство или дистрибуцию);

·
улучшение
существующей линейки продуктов или услуг (например, проект по методике «шести
сигм» (Six Sigma), предпринятый для уменьшения дефектов);

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

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

Эти 5 групп процессов следующие:

·
инициация,

·
планирование,

·
исполнение,

·
мониторинг
и контроль,

·
закрытие.

Ограничений проекта:

·
содержание,

·
качество,

·
расписание,

·
бюджет,

·
ресурсы,

·
риски.

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

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

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

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

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

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

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

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

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

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

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

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

·
Руководящий.
Руководящие ОУП контролируют проекты путем непосредственного управления данными
проектами. Степень контроля со стороны ОУП высокая.

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

·
управление общими ресурсами всех проектов,
администрируемых ОУП;

·
определение и разработка методологии, лучших
практик и стандартов управления проектами;

·
коучинг,
наставничество, обучение и надзор;

·
мониторинг соответствия стандартам, политикам,
процедурам и шаблонам управления проектами посредством аудитов проектов;

·
разработка и управление политиками, процедурами,
шаблонами проекта и другой общей документацией (активами процессов
организации);

·
координация коммуникаций между проектами.

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

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

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

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

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

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

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

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

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

Компетенции РП:

·
Компетенции в знаниях — то, что
руководитель знает об управлении проектом.

·
Компетенции в исполнении — то, что руководитель
проекта способен сделать или достичь, применяя свои знания об управлении
проектом.

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

Навыки РП:

·
лидерство,

·
укрепление командой,

·
мотивация,

·
коммуникация,

·
влияние,

·
принятие решений,

·
политическая и культурная осведомленность,

·
переговоры,

·
построение доверительных отношений,

·
урегулирование конфликтов,

·
коучинг.

2. ВЛИЯНИЕ
ОРГАНИЗАЦИИ И ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА

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

·
процессы и процедуры

·
корпоративная база знаний

Факторы среды
предприятия широко различаются по типу или характеру. Факторы среды
предприятия включают в себя, среди прочего:

·
организационную культуру, структуру и
руководство;

·
географическое распределение оборудования и
ресурсов;

·
государственные и промышленные стандарты
(например, предписания контролирующих органов, кодексы поведения, стандарты на
продукцию, стандарты качества, стандарты изготовления);

·
инфраструктуру (например, существующие
сооружения и основное оборудование);

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

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

·
корпоративная система авторизации работ;

·
ситуация на рынке;

·
толерантность к риску заинтересованных сторон;

·
политический климат;

·
каналы коммуникаций, принятые в организации;

·
коммерческие базы данных (например,
стандартизированные сметные данные, данные изучения промышленных рисков и базы
данных рисков);

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

Члены команды проекта выполняют следующие роли:

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

·
Персонал
проекта. Члены команды, которые выполняют работу по созданию поставляемых
результатов проекта.

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

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

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

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

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

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

Все проекты могут иметь следующую структуру жизненного
цикла:

·
начало проекта;

·
организация и подготовка;

·
выполнение работ проекта;

·
завершение проекта.

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

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

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

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

3. ПРОЦЕССЫ
УПРАВЛЕНИЯ ПРОЕКТОМ

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

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

Процессы проекта можно разделить на две основные категории:

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

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

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

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

·
Группа
процессов планирования. Процессы, требуемые для установления содержания
работ, уточнения целей и определения направления действий, требуемых для
достижения целей проекта.

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

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

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

Группы процессов не
являются фазами жизненного цикла проекта!

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

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

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

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

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

Описанные в Руководстве PMBOK 47 процессов управления
проектом разбиты на 10 отдельных областей знаний. Область знаний является
всеобъемлющей системой понятий, терминов и действий, составляющих
профессиональную область, область управления проектами или область
деятельности. Эти 10 областей знаний практически постоянно используются в
большинстве проектов. Команды проектов должны по мере необходимости
использовать эти 10 областей знаний и другие области знаний для своего
конкретного проекта. Области знаний включают в себя:

·
управление интеграцией проекта,

·
управление содержанием проекта,

·
управление сроками проекта,

·
управление стоимостью проекта,

·
управление качеством проекта,

·
управление человеческими ресурсами проекта,

·
управление коммуникациями проекта,

·
управление рисками проекта,

·
управление закупками проекта,

·
управление заинтересованными сторонами проекта.

4. УПРАВЛЕНИЕ
ИНТЕГРАЦИЕЙ ПРОЕКТА

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

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

·
назначение
или обоснование проекта;

·
измеримые
цели проекта и соответствующие критерии успеха;

·
высокоуровневые
требования;

·
допущения
и ограничения;

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

·
высокоуровневые
риски;

·
укрупненное
расписание контрольных событий;

·
укрупненный
бюджет;

·
список
заинтересованных сторон;

·
требования
к одобрению проекта (т. е. что именно составляет успех проекта, кто решает, что
проект оказался успешным, и кто подписывает проект);

·
назначенный
руководитель проекта, сфера ответственности и уровень полномочий;

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

Описание работ
(statement of work, SOW) проекта — это словесное описание продуктов, услуг или
результатов, которые должен произвести проект.

SOW отражает:

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

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

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

Бизнес-кейс

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

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

·
потребность организации (например, в связи с
высокими накладными расходами компания может объединить функции персонала и
оптимизировать процессы для сокращения затрат);

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

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

·
юридическое требование (например, производитель
красок авторизует проект для разработки руководящих указаний по обращению с
токсичными материалами);

·
экологические воздействия (например, компания
авторизует проект для уменьшения своего воздействия на окружающую среду);

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

Соглашения

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

Факторы среды
предприятия

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

·
государственные и промышленные стандарты или
предписания (например, кодексы поведения, стандарты качества или стандарты по
защите трудящихся);

·
организационную культуру и структуру;

·
ситуацию на рынке.

Активы процессов
организации

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

·
стандартные процессы организации, политики и
описания процессов;

·
шаблоны (например, шаблон устава проекта);

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

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

Базовые планы проекта включают в себя, среди прочего:

·
базовый план по содержанию;

·
базовое расписание;

·
базовый план по стоимости.

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

·
план управления содержанием;

·
план управления требованиями;

·
план управления расписанием;

·
план управления стоимостью;

·
план управления качеством;

·
план совершенствования процессов;

·
план управления человеческими ресурсами;

·
план управления коммуникациями;

·
план управления рисками;

·
план управления закупками;

·
план управления заинтересованными сторонами.

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

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

·
детали решений по адаптации, вынесенных командой
управления проектом, а именно:

o
процессы управления проектом, выбранные командой
управления проектом;

o
уровень реализации каждого выбранного процесса;

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

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

·
порядок выполнения работ для достижения целей
проекта;

·
план управления изменениями, документирующий
порядок мониторинга и контроля изменений;

·
план управления конфигурацией, документирующий
порядок управления конфигурацией;

·
описание порядка поддержания целостности базовых
планов;

·
требования и методы коммуникации между
заинтересованными сторонами;

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

Прогнозы в отношении
расписания

Прогнозы в отношении расписания составляются с учетом
прогресса относительно базового расписания и расчетного времени прогноза до
завершения (ПДЗ). Они обычно выражаются в виде отклонения по срокам (ОСР) и
индекса выполнения сроков (ИВСР). Для проектов, которые не используют
управление освоенным объемом, указываются отклонения от запланированных и
прогнозируемых дат финиша.

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

Прогнозы в отношении
стоимости

Прогнозы в отношении стоимости составляются с учетом
прогресса относительно базового плана по стоимости и расчетного прогноза до
завершения (ПДЗ). Они обычно выражаются в виде отклонения по стоимости (ОСТ) и
индекса выполнения стоимости (ИВСТ). Прогноз по завершении (ППЗ) можно сравнить
с бюджетом по завершении (БПЗ), чтобы определить, находится ли проект в области
допустимых значений, или необходимо составление запросов на изменения. Для
проектов, которые не используют управление освоенным объемом, указываются
отклонения от запланированных и фактических расходов, а также прогнозируемая
окончательная стоимость.

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

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

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

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

5. УПРАВЛЕНИЕ
СОДЕРЖАНИЕМ ПРОЕКТА

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

В контексте проекта
термин «содержание» может обозначать:

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

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

Классы требований:

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

·
Требования
заинтересованных сторон, описывающие потребности заинтересованной стороны
или группы заинтересованных сторон.

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

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

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

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

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

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

6. УПРАВЛЕНИЕ
СРОКАМИ ПРОЕКТА

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

Типы зависимости
операций:

·
Финиш-старт (finish-start, FS). Логическая
связь, при которой старт последующей операции зависит от финиша предшествующей
операции. Пример: церемония награждения (последующая операция) не может быть
начата, пока не закончится гонка предшествующая операция).

·
Финиш-финиш (finish-finish, FF). Логическая
связь, при которой финиш последующей операции зависит от финиша предшествующей
операции. Пример: создание документа (предшествующая операция) должно быть закончено
до завершения его правки (последующая операция).

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

·
Старт-финиш (start-finish, SF). Логическая
связь, при которой финиш последующей операции зависит от старта предшествующей
операции. Пример: первая смена службы охраны (последующая операция) не может закончиться,
пока не начнется вторая смена службы охраны (предшествующая операция).

Оценка по трем точкам

Точность оценок
длительности операций по одной точке может быть улучшена путем рассмотрения неопределенностей
оценок и рисков. Данная концепция происходит из метода оценки и анализа
программ (program evaluation and review technique, PERT). Для определения
приблизительного диапазона длительности операции PERT использует три оценки:

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

·
Оптимистичная
(tO). Длительность операции основывается на анализе наиболее благоприятного
сценария для операции.

·
Пессимистичная
(tP). Длительность операции основывается на анализе наиболее
неблагоприятного сценария для операции.

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

Формулы:

·
Треугольное
распределение. tE = (tO + tM + tP) / 3

·
Бета-распределение
(из традиционного метода PERT). tE = (tO + 4tM + tP) / 6

Метод критического пути

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

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

Метод критической цепи

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

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

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

7. УПРАВЛЕНИЕ
СТОИМОСТЬЮ ПРОЕКТА

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

Управление освоенным
объемом

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

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

·
Плановый объем. Плановый объем (ПО) —
авторизованный бюджет, выделенный на запланированные работы. Это авторизованный
бюджет, выделенный для работы, которую необходимо выполнить в рамках операции
или компонента иерархической структуры работ, за исключением управленческого
резерва. Данный бюджет распределяется по фазам в жизненном цикле проекта, но в
определенный момент запланированный объем определяет физическую работу, которая
должна была быть выполнена. Совокупный ПО иногда называется базовым планом
исполнения (performance measurement baseline, PMB). Общая величина
планового объема проекта также известна как бюджет по завершении (БПЗ).

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

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

Также осуществляется мониторинг отклонений от
одобренного базового плана:

·
Отклонение по срокам. Отклонение по
срокам (ОСР) — показатель исполнения расписания, выражаемый как разница между
освоенным объемом и плановым объемом. Количество времени, на которое проект
отстает от запланированной даты поставки или опережает ее в определенный момент
времени. Это измерение исполнения расписания проекта. Значение его равно
освоенному объему (ОО) за вычетом планового объема (ПО). Отклонение по срокам в
методе EVM представляет собой метрику, полезную тем, что она
демонстрирует, когда проект отстает по срокам от своего базового плана или
когда он опережает его. Отклонение по срокам в EVM в конечном итоге будет
равно нулю при завершении проекта, так как все плановые объемы к тому времени
должны быть освоены. Отклонение по срокам лучше всего использовать вместе с
составлением расписания по методу критического пути (CPM) и управлением
рисками. Формула: ОСР = ОО – ПО

·
Отклонение по стоимости. Отклонение по
стоимости (ОСТ) — сумма дефицита или излишка бюджета в определенный момент
времени, выражаемая как разница между освоенным объемом и фактической стоимостью.
Это измерение эффективности выполнения проекта по стоимости. Оно равно
освоенному объему (ОО) за вычетом фактической стоимости (ФС). Отклонение по
стоимости в конце проекта будет равно разнице между бюджетом по завершении
(БПЗ) и фактически израсходованной суммой. ОСТ чрезвычайно важно, так как оно
демонстрирует связь между физическим исполнением и израсходованными средствами.
Отрицательное ОСТ зачастую невозместимо для проекта. Формула: ОСТ = ОО –
ФС.

Значения ОСР и ОСТ могут быть преобразованы в
показатели эффективности для отражения выполнения стоимости и сроков любого
проекта по сравнению со всеми другими проектами или в рамках портфеля проектов.
Отклонения полезны для определения статуса проекта.

·
Индекс выполнения сроков. Индекс
выполнения сроков (ИВСР) — показатель эффективности расписания, выражаемый как
соотношение освоенного объема к плановому объему. С помощью него измеряется,
насколько эффективно команда проекта использует свое время. Иногда он
используется вместе с индексом выполнения стоимости (ИВСТ) для прогнозирования
окончательных оценок завершения проекта. Значение ИВСР меньше 1,0 указывает на
то, что выполнено меньше работ, чем было запланировано. Значение ИВСР больше
1,0 указывает на то, что выполнено больше работ, чем было запланировано. Так
как ИВСР измеряет все работы проекта, также необходимо проанализировать
исполнение на критическом пути, чтобы определить, будет проект завершен до или
после своей плановой даты финиша. ИВСР равен отношению ОО к ПО. Формула:
ИВСР = ОО/ПО

·
Индекс выполнения стоимости. Индекс
выполнения стоимости (ИВСТ) — показатель эффективности ресурсов, включенных в
бюджет, по стоимости, выражаемый как соотношение освоенного объема к
фактической стоимости. Он считается наиболее важной метрикой EVM и
измеряет стоимостную эффективность выполненной работы. Значение ИВСТ меньше 1,0
указывает на перерасход средств для выполненной работы. Значение ИВСТ больше
1,0 указывает на недоосвоение средств при исполнении на конкретную дату. ИВСР
равен отношению ОО к ФС. Индексы полезны для определения статуса проекта, а
также предоставляют основу для оценки итоговых сроков и стоимости проекта. Формула:
ИВСТ = ОО/ФС

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

Прогнозирование

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

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

ППЗ обычно рассчитываются как фактическая стоимость,
учтенная для завершенных работ, плюс прогноз до завершения (ПДЗ) оставшихся
работ. На команду проекта возложена обязанность прогнозировать, с чем она может
столкнуться во время выполнения ПДЗ, на основании имеющегося в данный момент
опыта. Метод EVM хорошо работает вместе с прогнозами требуемого ППЗ,
разработанными вручную. Наиболее широко используемым подходом прогнозирования ППЗ
является ручное суммирование «снизу вверх», проводимое руководителем проекта и
командой проекта.

Метод ППЗ «снизу вверх», используемый руководителем
проекта, основан на учтенной фактической стоимости и опыте, полученном на
выполненных работах, и требует построения нового прогноза до завершения в
отношении оставшихся работ проекта. Формула: ППЗ = ФС + ПДЗ «снизу вверх».

ППЗ, разработанный вручную руководителем проекта,
быстро сопоставляется с рядом рассчитанных ППЗ, представляющих разнообразные
сценарии рисков. При расчете значений ППЗ, как правило, используются
кумулятивные значения ИВСТ и ИВСР. Хотя данные EVM позволяют быстро получить
множество статистических ППЗ, ниже описаны только три наиболее распространенных
метода:

·
ППЗ для
работ ПДЗ, выполненных по заложенным в бюджет ставкам. Данный метод ППЗ
использует фактическое исполнение проекта на конкретную дату (благоприятное или
неблагоприятное), представленное фактической стоимостью, и предсказывает, что
все будущие работы ПДЗ будут выполнены по заложенным в бюджет ставкам. В тех
случаях, когда фактическое исполнение неблагоприятно, допущение, что будущее исполнение
улучшится, должно быть принято только в том случае, если это подтверждается
анализом рисков проекта. Формула: ППЗ = ФС + (БПЗ – ОО)

·
ППЗ для работ
ПДЗ, выполненных с текущим ИВСТ. Этот метод допускает, что проект
продолжится в будущем так же, как он протекал до этого момента. Допускается,
что работы ПДЗ будут выполняться на том же уровне кумулятивного индекса
выполнения стоимости (ИВСТ), какой был достигнут в проекте к этому моменту. Формула:
ППЗ = БПЗ/ИВСТ

·
ППЗ для
работ ПДЗ с учетом обоих факторов ИВСР и ИВСТ. В данном прогнозе работы ПДЗ
будут выполняться с эффективностью, которая учитывает индексы выполнения как
стоимости, так и сроков. Данный метод наиболее полезен в случае, когда одним из
факторов, влияющих на ПДЗ, является расписание проекта. Вариации данного метода
рассматривают ИВСТ и ИВСР в различных соотношениях (например, 80/20, 50/50 или
в других пропорциях), в соответствии с мнением руководителя проекта. Формула:
ППЗ = ФС + [(БПЗ – ОО)/(ИВСТ x ИВСР)]

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

Индекс
производительности до завершения (ИПДЗ)

Индекс производительности до завершения (ИПДЗ) —
расчетный показатель эффективности выполнения проекта по стоимости, который
необходимо достичь с оставшимися ресурсами, чтобы добиться установленного
управленческого показателя, выражаемого в виде отношения стоимости выполнения
оставшейся части работ к оставшемуся бюджету. ИПДЗ представляет собой
вычисляемый индекс выполнения стоимости, который необходимо обеспечить на
оставшихся работах для достижения определенной управленческой цели, такой как
БПЗ или ППЗ. Если становится очевидным, что БПЗ больше не является
реалистичным, руководитель проекта должен рассмотреть ППЗ. После одобрения ППЗ
может заменить БПЗ при расчете ИПДЗ. Формула для ИПДЗ, основанного на БПЗ: (БПЗ
– ОО)/(БПЗ – ФС). ИПДЗ концептуально представлен на рисунке ниже. Формула для
ИПДЗ показана в левом нижнем углу — оставшаяся работа (определена как БПЗ минус
ОО), деленная на оставшиеся средства (которые могут рассчитываться либо как БПЗ
минус ФС, либо как ППЗ минус ФС).

Если кумулятивный ИВСТ ниже базового плана (как
показано на рисунке ниже), все будущие работы по проекту немедленно должны
выполняться в соответствии с ИПДЗ (БПЗ) (что отражено в верхней линии рисунке
ниже), чтобы оставаться в рамках авторизованного БПЗ. Суждение о том, является
ли данный уровень исполнения достижимым, принимается на основе ряда соображений,
включая риски, расписание и техническое исполнение. Этот уровень исполнения
изображен в виде линии ИПДЗ (ППЗ). Формула для ИПДЗ, основанного на ППЗ: (БПЗ –
ОО)/(ППЗ – ФС). Формулы EVM представлены в таблице ниже.

Анализ
исполнения

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

·
Анализ
отклонений. Анализ отклонений при использовании в EVM — это разъяснение
(причина, влияние и корректирующие воздействия) отклонений для стоимости (ОСТ =
ОО – ФС), расписания (ОСР = ОО – ПО) и отклонения по завершении (ОПЗ = БПЗ –
ППЗ). Наиболее часто анализируются отклонения по стоимости и по срокам. Для
проектов, в которых не применяется управление освоенным объемом, может быть
выполнен аналогичный анализ отклонений путем сравнения запланированной
стоимости операции с фактической стоимостью операции для определения отклонений
фактического исполнения проекта от базового плана по стоимости. Дальнейший
анализ может быть выполнен для определения причины и степени отклонения от базового
расписания и необходимых корректирующих воздействий или предупреждающих
действий. Измерения выполнения стоимости используются для оценки величины
отклонения от первоначального базового плана по стоимости. Важные аспекты
управления стоимостью проекта включают в себя определение причины и степени отклонения
относительно базового плана по стоимости и принятие решений о необходимости корректирующих
воздействий или предупреждающих действий. По мере выполнения все большего
объема работ процентный диапазон допустимых отклонений будет иметь тенденцию к
уменьшению.

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

·
Исполнение
освоенного объема. Исполнение освоенного объема предусматривает сравнение
базового плана исполнения с фактическим выполнением сроков и стоимости. Если
EVM не используется, то для сравнения выполнения стоимости используется анализ
базового плана по стоимости относительно фактической стоимости выполненных
работ.

8. УПРАВЛЕНИЕ
КАЧЕСТВОМ ПРОЕКТА

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

Качество и сорт — это концептуально различные
понятия. Качество как поставляемый выход или результат — это «степень
соответствия совокупности присущих характеристик требованиям» (ISO 9000) [10].
Сорт как конструктивный замысел — это категория, присваиваемая поставляемым
результатам, имеющим одно и то же функциональное назначение, но различные
технические характеристики. Руководитель проекта и команда управления проектом
отвечают за достижение компромиссных решений в отношении обеспечения требуемых
уровней как качества, так и сорта. Уровень качества, который не отвечает требованиям к качеству, — это всегда
проблема, а низкий сорт может не быть проблемой.

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

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

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

·
Постоянное
совершенствование. Цикл «планирование-выполнение-проверка-действие»
(plan-do-check-act, PDCA) — модель, описанная Шухартом и усовершенствованная
Демингом, — является основой для улучшения качества. Кроме того, инициативы по
улучшению качества, такие как всеобщее управление качеством (Total Quality
Management, TQM), методика «шести сигм» и совместное применение методики «шести
сигм» и бережливого производства (Lean Six Sigma), могут улучшить качество
управления проектом, а также качество продукта проекта. Среди моделей
совершенствования процессов можно привести модель качества Малкольма Болдриджа,
модель зрелости организационного управления проектами (Organizational Project
Management Maturity Model, OPM3®) и комплексную модель производительности и
зрелости (Capability Maturity Model Integrated, CMMI®).

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

·
Стоимость
качества (cost of quality, COQ). Стоимость качества — это общая стоимость
работы над соответствием и работы над несоответствием требованиям, которая
должна быть выполнена в качестве компенсационного усилия, поскольку при первой
попытке выполнения этой работы существует потенциальная возможность, что
какая-то часть требуемого объема работ может быть выполнена или была выполнена
неправильно. Затраты на выполнение работ по обеспечению качества могут
возникать на протяжении всего жизненного цикла поставляемого результата.
Например, решения, принятые командой проекта, могут повлиять на операционные
затраты, связанные с использованием выполненного поставляемого результата.
Затраты, связанные с обеспечением качества после закрытия проекта, могут
возникать в результате возвратов продуктов, претензий по гарантии и кампаний по
отзыву продукции. Таким образом, вследствие временного характера проекта и
потенциальной выгоды, которая может быть получена в результате снижения
послепроектной стоимости качества, спонсирующие организации могут принять
решение об инвестировании средств в улучшение качества продукта. Данные
инвестиции, как правило, делаются в области работы над соответствием
требованиям с целью предотвращения дефектов или снижения стоимости дефектов
путем инспекции несоответствующих требованиям единиц продукции. Более того,
вопросы, связанные с постпроектной COQ, должны решаться в процессе управления
программой и управления портфелем, например офисы управления проектами,
программами и портфелями должны применять соответствующие методы анализа,
шаблоны и способы выделения финансовых средств для этой цели.

Семь основных
инструментов качества

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

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

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

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

·
Диаграммы
Парето представляют собой вертикальные столбчатые диаграммы особой формы и
используются для определения нескольких наиболее важных источников, вызывающих
большинство эффектов проблемы. Категории, показанные на горизонтальной оси,
представляют собой существующее распределение вероятностей, учитывающее 100 %
возможных наблюдений. Значение соответствующей частоты возникновения каждой обозначенной
причины, показанной на горизонтальной оси, уменьшается вплоть до достижения
источника по умолчанию, называемого «другое», который отвечает за
неустановленные причины. Как правило, диаграмма Парето организована по
категориям, измеряющим либо частоту возникновения, либо последствия.

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

·
Контрольные
карты используются для определения того, является ли процесс стабильным или
нет и характеризуется ли он предсказуемым исполнением. Нижние и верхние
границы, заданные спецификацией, основаны на требованиях, закрепленных в
соглашении. Они отражают максимальные и минимальные допустимые значения. Могут
налагаться штрафы, связанные с выходом значений за границы, заданные спецификацией.
Верхняя и нижняя контрольные границы отличаются от границ, заданных
спецификацией. Контрольные границы устанавливаются с использованием стандартных
статистических расчетов и принципов с целью окончательного определения
естественной возможности стабилизации процесса. Руководитель проекта и
соответствующие заинтересованные стороны могут использовать статистически
рассчитанные контрольные границы для определения точек, в которых будут
предприниматься корректирующие воздействия с целью предотвращения
неестественного исполнения. Целью корректирующего воздействия, как правило,
является сохранение естественной устойчивости стабильного и действенного процесса.
Для повторяющихся процессов контрольные границы обычно составляют ± 3 сигмы от
среднего значения процесса, которое было установлено на 0. Процесс считается
вышедшим из-под контроля в том случае, если: (1) точка данных находится вне
контрольных границ; (2) семь последовательных точек находятся выше средней
линии; или (3) семь последовательных точек находятся ниже средней линии.
Контрольные карты могут быть использованы для контроля различных типов выходных
переменных. Хотя наиболее часто контрольные карты используются для отслеживания
повторяющихся операций, требуемых для производства промышленных изделий, они
также могут использоваться для контроля отклонений по стоимости и расписанию,
объема и частоты изменений содержания или иных управленческих результатов, что
помогает определить, находятся ли процессы управления проектом под контролем.

·
Диаграммы
разброса — это нанесенные на график упорядоченные пары (X, Y), иногда
называемые графиками корреляций, поскольку они используются для объяснения
изменения в зависимой переменной, Y, относительно изменения, наблюдаемого в
независимой переменной, X. Направление корреляции может быть пропорциональным
(положительная корреляция), обратным (отрицательная корреляция), либо
корреляционной модели может не существовать (нулевая корреляция). Если
корреляция может быть установлена, можно определить линию регрессии и
использовать ее для оценки того, каким образом изменение независимой переменной
изменит значение зависимой переменной.

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

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

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

·
Диаграммы
процесса осуществления программы (process decision program charts, PDPC).
Используются для понимания цели относительно действий, предпринимаемых для
достижения цели. PDPC — полезный метод для планирования с учетом возможных
потерь, так как он помогает командам предвидеть промежуточные шаги, которые
могут препятствовать достижению цели.

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

·
Древовидные
диаграммы. Также известные как систематические диаграммы, которые могут
использоваться для отображения декомпозиции иерархий, таких как ИСР,
иерархическая структура рисков (risk breakdown structure, RBS) и организационная структура работ (organizational breakdown structure,
OBS). В процессе
управления проектом древовидные диаграммы полезны для визуализации отношений
типа «родитель – потомок» в любой иерархии декомпозиции, которая использует
систематический набор правил для определения отношений подчиненности.
Древовидные диаграммы могут быть горизонтальными (например, иерархическая
структура рисков) или вертикальными (например, иерархия команды или OBS).
Поскольку древовидные диаграммы делают возможным создание вложенных
ответвлений, которые заканчиваются в одной точке принятия решения, они полезны
в качестве деревьев решений для определения ожидаемой ценности ограниченного
числа родственных отношений, систематически представляемых в виде диаграммы.

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

·
Диаграммы
сети операций. Ранее известные как стрелочные диаграммы. Они включают в
себя такие форматы диаграммы сети, как операции на дугах (activity on arrow,
AOA) и наиболее часто используемый формат операции в узлах (activity on node, AON). Диаграммы сети операций
используются с методами составления расписания проекта, такими как метод оценки
и анализа программ (PERT), метод критического пути (CPM) и метод диаграмм
предшествования (PDM).

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

9. УПРАВЛЕНИЕ
ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ ПРОЕКТА

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

Организационные
диаграммы и должностные инструкции

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

План управления
человеческими ресурсами включает в себя, среди прочего:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одна из моделей, используемых для описания развития команды
— это Tuckman ladder (Tuckman, 1965; Tuckman & Jensen, 1977), которая
включает пять стадий развития, через которые должны пройти команды. Обычно эти
стадии наступают по порядку, но нередко команда может «застрять» на
определенной стадии или вернуться на более раннюю. В проектах, члены команд
которых ранее работали вместе, определенные стадии могут быть пропущены.

·
Формирование.
На данной стадии команда собирается вместе и узнает о проекте и о своих
формальных ролях и сферах ответственности в нем. Члены команды на данной фазе,
как правило, независимы друг от друга и не особенно открыты.

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

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

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

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

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

Существует пять основных методов, используемых для
разрешения конфликтов.

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

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

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

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

·
Принуждение/указания.
Лоббирование чьей-либо точки зрения за счет других, предлагая только решения
«один выиграл — все проиграли», обычно со стороны позиции власти, чтобы
разрешить критическую ситуацию.

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

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

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

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

o
способность убедительно и четко излагать точку
зрения и позицию;

o
высокий уровень навыков активного и
результативного выслушивания;

o
понимание и рассмотрение различных перспектив в
любой ситуации;

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

·
Результативное
принятие решений. Это подразумевает способность проведения переговоров и
оказания влияния на организацию и команду управления проектом. Ниже
представлены некоторые из рекомендаций в отношении принятия решений:

o
необходимо сосредоточиться на целях, которые
предстоит достичь;

o
необходимо придерживаться процедуры принятия
решений;

o
необходимо изучать факторы среды;

o
необходимо анализировать имеющуюся информацию;

o
необходимо развивать личностные качества членов
команды;

o
необходимо стимулировать творческий подход
команды к работе;

o
необходимо управлять рисками.

10. УПРАВЛЕНИЕ
КОММУНИКАЦИЯМИ ПРОЕКТА

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

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

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

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

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

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

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

Базовая коммуникационная модель имеет следующую
последовательность шагов:

·
Кодирование.
Преобразование (кодирование) мыслей или идей в кодовый язык отправителем.

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

·
Декодирование.
Сообщение переводится получателем обратно в значимые мысли и идеи.

·
Подтверждение.
После получения сообщения получатель может послать сигнал (подтверждение) о
получении сообщения, но это не обязательно означает согласие с сообщением или
понимание сообщения.

·
Обратная
связь/ответ. Когда полученное сообщение декодировано и понято, получатель
преобразует (кодирует) мысли и идеи в сообщение и передает данное сообщение
оригинальному отправителю.

Для распространения информации между заинтересованными
сторонами проекта используется несколько методов коммуникации.

Данные методы
могут быть разделены на следующие большие группы:

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

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

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

Методы и аспекты эффективного управления коммуникациями
включают среди прочего:

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

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

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

·
Методы
управления совещаниями. Подготовка повестки и работа с конфликтами.

·
Методы
презентаций. Осведомленность о воздействии языка тела и разработка
визуальных средств.

·
Методы
организации групповой работы. Достижение консенсуса и преодоление
препятствий.

·
Методы
слушания. Активное слушание (подтверждение, уточнение и проверка понимания)
и устранение барьеров, которые могут исказить понимание.

11. УПРАВЛЕНИЕ
РИСКАМИ ПРОЕКТА

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

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

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

·
Методология.
Определение подходов, инструментов и источников данных, которые будут
использоваться для управления рисками в данном проекте.

·
Роли и
сферы ответственности. Определение руководящих членов команды,
поддерживающих членов команды, а также членов команды, отвечающих за управление
рисками, для каждого вида действий, включенных в план управления рисками, и
разъяснение их сфер ответственности.

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

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

·
Категории
рисков. Предоставляют средства для распределения потенциальных источников
риска по группам. Могут быть использованы несколько подходов, например,
структура, основанная на целях проекта по категориям. Иерархическая структура
рисков (RBS) помогает команде проекта рассмотреть множество источников, из
которых могут проистекать риски проекта, во время выполнения процедуры
идентификации рисков. Различным типам проектов соответствуют различные
структуры RBS. Организация может использовать разработанную заранее схему категоризации
рисков, которая может принимать форму простого списка категорий или оформляться
в виде RBS. RBS — это иерархическое представление рисков согласно категориям
рисков.

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

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

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

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

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

Методы диаграмм

К методам диаграмм рисков относятся:

·
Диаграммы
причинно-следственных связей. Эти диаграммы, также известные как диаграммы
Исикавы или диаграммы «рыбий скелет», используются для определения причин
возникновения рисков.

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

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

Анализ SWOT

Данный метод позволяет провести анализ проекта с точки
зрения каждого из аспектов: сильных и слабых сторон, благоприятных возможностей
и угроз (strengths, weaknesses, opportunities, and threats, SWOT), что делает
идентификацию рисков более полной, учитывая риски внутри проекта. При
использовании данного метода начинают с определения сильных и слабых сторон
организации, уделяя особое внимание либо проекту, либо организации, либо
области бизнеса в целом. Затем в процессе анализа SWOT идентифицируют любые
благоприятные возможности проекта, обусловленные сильными сторонами
организации, а также любые угрозы, появляющиеся вследствие ее слабых сторон.
При помощи данного анализа также исследуют, насколько сильные стороны
организации компенсируют угрозы, и идентифицируют лагоприятные возможности,
которые можно использовать для преодоления слабых сторон.

Реестр рисков

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

·
Список
идентифицированных рисков. Идентифицированные риски описываются с
достаточной степенью детализации. В данном списке может использоваться
определенная структура для описания рисков, например: может произойти СОБЫТИЕ,
которое окажет ВОЗДЕЙСТВИЕ, или если существует ПРИЧИНА, то может произойти
СОБЫТИЕ, которое будет иметь ПОСЛЕДСТВИЕ. Кроме того, при построении списка идентифицированных
рисков могут стать более очевидными первопричины данных рисков. Это
фундаментальные условия или события, которые способны вызвать наступление
одного или нескольких идентифицированных рисков. Они должны регистрироваться и
использоваться для поддержки идентификации рисков в будущем в рамках данного и
других проектов.

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

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

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

Методы сбора и
представления информации

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

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

Методы
количественного анализа и моделирования рисков

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

·
Анализ
чувствительности. Анализ чувствительности помогает определить риски с
наибольшим возможным воздействием на проект. Он помогает понять, каким образом
вариации в целях проекта коррелируют с вариациями в различных
неопределенностях. С другой стороны, он устанавливает, в какой степени
неопределенность каждого элемента проекта влияет на изучаемую цель, в то время
как все другие неопределенные элементы находятся в своих базовых значениях.
Одним из типичных способов отображения анализа чувствительности является
диаграмма «торнадо» (рис. ниже), которая полезна при сравнении относительной
важности и воздействия переменных, обладающих высокой степенью
неопределенности, с другими, более стабильными переменными. Диаграмма «торнадо»
также полезна при анализе сценариев принятия рисков, применяемых при
определенных рисках, количественный анализ которых указывает на то, что
возможные выгоды больше, чем соответствующие идентифицированные отрицательные
воздействия. Диаграмма «торнадо» — особый вид линейчатой диаграммы,
используемый в анализе чувствительности для сравнения относительной важности
переменных. В диаграмме «торнадо» на оси Y располагается каждый тип неопределенности
в базовых значениях, а на оси X — разброс или корреляция неопределенности в
отношении изучаемого выхода. На этом рисунке каждая неопределенность содержит
горизонтальную полосу (линию), а по вертикали показаны неопределенности с
уменьшающимся разбросом от базовых значений

·
Анализ
ожидаемого денежного значения. Анализ ожидаемого денежного значения
(expected monetary value, EMV) — это статистический метод, с помощью которого
вычисляется средний результат, когда в будущем имеются сценарии, которые могут
произойти или не произойти (т. е. анализ в условиях неопределенности). EMV
благоприятных возможностей, как правило, выражается в положительных величинах,
а угроз — в отрицательных. Для EMV требуется нейтральное по отношению к рискам
допущение — ни склонное к чрезмерному риску, ни, наоборот, полностью его
отвергающее. Чтобы рассчитать EMV для проекта, необходимо умножить значение
каждого возможного результата на вероятность его наступления, а затем сложить
вместе полученные значения. Обычно данный тип анализа используется в виде анализа
дерева решений.

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

Стратегии
реагирования на отрицательные риски (угрозы)

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

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

·
Снижение.
Снижение риска — стратегия реагирования на риск, при которой команда проекта
действует с целью уменьшения вероятности возникновения или воздействия риска.
Она предполагает уменьшение вероятности и/или воздействия неблагоприятного
риска до приемлемых пороговых уровней. Предпринятые ранние действия по уменьшению
вероятности наступления риска и/или его воздействия в ходе проекта часто
оказываются более результативными, нежели попытки возмещения ущерба,
предпринимаемые после наступления риска. В качестве примеров действий по
снижению рисков можно привести внедрение менее сложных процессов, проведение большего
числа тестов или выбор более надежного поставщика. Также для снижения может
потребоваться разработка прототипа для уменьшения риска разрастания масштабов
процесса или продукта по сравнению со стендовой моделью. Если невозможно
уменьшить вероятность, действия по снижению риска должны быть направлены на
воздействие риска, а именно на те связи, которые определяют серьезность
воздействия. Например, проектирование резервирования системы может уменьшить
тяжесть последствий отказа исходного элемента.

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

Стратегии
реагирования на положительные риски (благоприятные возможности)

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

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

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

·
Принятие.
Принятие благоприятной возможности — это желание воспользоваться преимуществом благоприятной
возможности в случае ее наступления без активного ее преследования.

12. УПРАВЛЕНИЕ
ЗАКУПКАМИ ПРОЕКТА

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

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

Типы договоров

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

o
Договоры с
твердой фиксированной ценой (Firm Fixed Price Contracts, FFP). Наиболее
широко используемым типом договоров является FFP. Большинство
организаций-покупателей предпочитает именно этот тип договора, так как цена
товаров устанавливается в самом начале и не подвержена изменениям, если не
меняется содержание работ. Любое увеличение стоимости, вызванное негативным
исполнением, является ответственностью продавца, который обязан закончить
работу. В соответствии с FFP покупатель обязан точно определить приобретаемый
продукт или услуги, а любые изменения закупочной спецификации могут увеличить
затраты покупателя.

o
Договоры с
фиксированной ценой и поощрительным вознаграждением (Fixed Price Incentive
Fee Contracts,FPIF). Данное соглашение с фиксированной ценой предоставляет
покупателю и продавцу некоторую гибкость, поскольку допускает отклонение от
исполнения и предусматривает финансовое поощрение за достижение оговоренных
метрик. Как правило, такие финансовые поощрения связаны с выполнением
стоимости, расписания или с техническим исполнением со стороны продавца.
Целевые значения показателей исполнения устанавливаются в начале, а конечная
цена договора определяется после завершения всех работ в зависимости от их
исполнения продавцом. В рамках FPIF устанавливается потолок цен, и
ответственность за все затраты выше потолка цен возлагается на продавца, который
обязан завершить работу.

o
Договоры с
фиксированной ценой и оговоркой о возможной корректировке цены (Fixed Price
with Economics Price Adjustment Contracts,
FP-EPA). Данный тип договора используется в
том случае, если исполнение договора продавцом растягивается на значительный
период времени, к чему обычно стремятся при долгосрочных отношениях. Договор с
фиксированной ценой, но со специальным положением, позволяющим вносить
предопределенные окончательные корректировки в стоимость договора в связи с
изменившимися условиями, такими как инфляция или повышение (понижение) цен
определенных товаров. Оговорка о корректировке цены должна быть привязана к
достоверному финансовому индексу, используемому для точной корректировки
конечной цены. FP-EPA призван защищать как покупателя, так и продавца от
внешних условий, которые они не могут контролировать.

·
Договоры
с возмещением затрат. Этот тип договора подразумевает оплату (возмещение)
продавцу всех законных фактических затрат, понесенных в результате исполнения
работы, плюс вознаграждение, составляющее его прибыль. В договоры с возмещением
затрат часто включаются пункты, предусматривающие поощрительные вознаграждения
за превышение или улучшение запланированных показателей проекта (например,
стоимости, расписания или технического исполнения). Тремя наиболее
распространенными типами договоров с возмещением затрат являются: договор с
возмещением затрат плюс фиксированное вознаграждение (Cost Plus Fixed Fee
Contract, CPFF), договор с возмещением затрат плюс поощрительное вознаграждение
(Cost Plus Incentive Fee Contract, CPIF), договор с возмещением затрат плюс
премиальное вознаграждение (Cost Plus Award Fee Contract, CPAF). Договор с
возмещением затрат обеспечивает гибкость проекта, позволяя изменять указания
для продавца в том случае, если содержание работ не может быть точно описано в
начале и нуждается в корректировке или существуют высокие риски во время
выполнения работ.

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

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

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

·
Договоры «время и материалы» (Time and Material
Contracts, T&M). Договоры «время и материалы» являются смешанным
типом договорных соглашений, содержащим положения как договоров с возмещением затрат,
так и договоров с фиксированной ценой. Они часто используются при
дополнительном наборе персонала (staff augmentation), привлечении экспертов и
для любой сторонней поддержки в тех случаях, когда невозможно быстро создать
точное описание работ. Данные типы договоров напоминают договоры с возмещением
затрат тем, что они допускают поправки и увеличение стоимости для покупателя. В
момент заключения договора покупатель может не указывать общую стоимость по
договору и точное количество предметов, которые необходимо поставить. Таким
образом, стоимость договоров T&M может увеличиваться, как и в договорах с
возмещением затрат. Для предотвращения неограниченного роста стоимости многие
организации требуют включения во все договоры T&M предельных значений цены
и сроков. C другой стороны, договоры T&M также могут напоминать соглашения
с фиксированной ценой, когда в договоре указываются определенные параметры. Ставки
оплаты рабочих часов или стоимость материалов, в том числе прибыль продавца,
могут быть заранее установлены покупателем и продавцом, если обе стороны
достигли соглашения по поводу стоимости определенных категорий ресурсов,
например определенной ставки почасовой оплаты труда главных инженеров или
определенной цены за единицу материала.

13. УПРАВЛЕНИЕ
ЗАИНТЕРЕСОВАННЫМИ СТОРОНАМИ ПРОЕКТА

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

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

·
матрица
власти/интересов, группирующая заинтересованные стороны на основе их уровня
полномочий («власть») и уровня заинтересованности («интерес») в отношении
результатов проекта;

·
матрица
власти/влияния, группирующая заинтересованные стороны на основе их уровня
полномочий («власть») и активного вовлечения («влияние») в проект;

·
матрица
влияния/воздействия, группирующая заинтересованные стороны на основе их
активного вовлечения («влияние») в проект и их возможности приводить к
изменениям в планировании или исполнении проекта («воздействие»);

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

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

·
Неосведомленный. Заинтересованная сторона
не осведомлена о проекте и потенциальных воздействиях.

·
Сопротивляющийся. Заинтересованная
сторона осведомлена о проекте и потенциальных воздействиях и сопротивляется
изменениям.

·
Нейтральный. Заинтересованная сторона
осведомлена о проекте, но не поддерживает изменения и не сопротивляется им.

·
Поддерживающий. Заинтересованная сторона
осведомлена о проекте, потенциальных воздействиях и поддерживает изменения.

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

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

·
Идентификационную
информацию: Ф.И.О., должность в организации, местоположение, роль в
проекте, контактная информация.

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

·
Классификацию
заинтересованной стороны: внутренняя/внешняя,
поддерживает/нейтральна/сопротивляется и т. д.

В дополнение к данным из реестра заинтересованных сторон
план управления заинтересованными сторонами зачастую также содержит:

·
желаемый и текущий уровень вовлечения ключевых
заинтересованных сторон;

·
объем и воздействие изменения на
заинтересованные стороны;

·
выявленные взаимосвязи и потенциальное
пересечение заинтересованных сторон;

·
требования заинтересованных сторон к
коммуникациям на текущей фазе проекта;

·
сведения о распространяемой среди
заинтересованных сторон информации, включая язык, формат, содержание и степень
детализации;

·
причину распространения данной информации и
ожидаемое влияние на уровень вовлечения заинтересованных сторон;

·
время и периодичность распространения требуемой
информации заинтересованным сторонам;

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

Автор: PM Angel

Источник

Библиографическая запись Библиотеки Конгресса США

Названия: Институт управления проектами (Project Management Institute, PMI), издатель.

Другие заголовки: Руководство PMBOK

Описание: Шестое издание | Newtown Square, PA: Project Management Institute, 2017. | Серия: Руководство PMBOK |

Включает библиографические ссылки и указатель

Идентификаторы: LCCN 2017032505 (print) | LCCN 2017035597 (ebook) | ISBN 9781628253900 (ePUP) |

ISBN 9781628253917 (kindle) | ISBN 9781628253924 (Web PDF) | ISBN 9781628251845 (paperback)

Классификация: LCC HD69.P75 (ebook) | LCC HD69.P75 G845 2017 (print) | DDC 658.4/04-dc23

Запись LC доступна на веб-сайте https://lccn.loc.gov/2017032505

ISBN: 978-1-62825-193-7

Опубликовано:

Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, Pennsylvania 19073-3299 США

Телефон: +1 610-356-4600

Факс: +1 610-356-4647

Эл. почта: customercare@pmi.org

Веб-сайт: https://www.PMI.org

Для размещения торгового заказа или получения информации о расценках обратитесь в Independent Publishers Group:

Independent Publishers Group

Order Department

814 North Franklin Street

Chicago, IL 60610 США

Телефон: +1 800-888-4741

Факс: +1 312-337-5985

Эл. почта: orders@ipgbook.com (только для заказов)

По всем остальным вопросам обращайтесь в PMI Book Service Center.

PMI Book Service Center

P.O. Box 932683, Atlanta, GA 31193-2683 USA

Телефон: 1-866-276-4764 (в США или Канаде) или +1-770-280-4129 (по всему миру)

Факс: +1-770-280-4113

Эл. почта: info@bookorders.pmi.org

ISBN 9781628251845

Руководство к Своду знаний по управлению проектами (Руководство PMBOK)

Уведомление

Часть 1. Руководство к Своду Знаний по Управлению Проектом (Руководство PMBOK®)

1. Введение

1.1. Обзор и назначение настоящего руководства

♦ пирамиды в Гизе,

♦ Олимпийские игры,

♦ Великую китайскую стену,

♦ Тадж-Махал,

♦ издание книги для детей,

♦ Панамский канал,

♦ создание коммерческих реактивных самолетов,

♦ вакцину от полиомиелита,

♦ высадку человека на Луне,

♦ коммерческие компьютерные прикладные программы,

♦ портативные устройства для использования глобальной системы позиционирования (GPS),

♦ выведение международной космической станции на околоземную орбиту.

1.1.1. Стандарт управления проектом

♦ Стандарт управления портфелем [2], и

♦ Стандарт управления программой [3].

1.1.2. Общий словарь

Общий словарь является существенным элементом любой профессиональной дисциплины. Лексикон терминов управления проектами PMI (PMI Lexicon of Project Management Terms)^[1] представляет собой основной словарь профессиональной терминологии, который могут единообразно использовать организации, руководители проектов, программ и портфелей и другие заинтересованные стороны проектов. Лексикон с течением времени будет развиваться. Глоссарий настоящего Руководства включает в себя словарь входящих в Лексикон (Lexicon) терминов, а также дополнительные определения. В проектах могут использоваться другие принятые в конкретных отраслях термины, определение которых дано в отраслевой литературе.

1.1.3. Кодекс профессиональной этики и поведения

1.2. Основополагающие элементы

1.2.1. Проекты

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

В качестве примеров проекта можно привести, среди прочего:

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

• расширение экскурсионных туристических услуг;

• слияние двух организаций;

• совершенствование бизнес-процесса в организации;

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

• разведка нефтяных месторождений в регионе;

• модификация компьютерной программы, используемой в организации;

• проведение исследований для разработки нового производственного процесса;

• строительство здания.

• достигнуты цели проекта;

• цели не будут или не могут быть достигнуты;

• финансирование на осуществление проекта исчерпано или больше не может быть выделено;

• исчерпаны человеческие или материальные ресурсы;

• проект прекращается по юридическим причинам или соображениям целесообразности.

Рис. 1–1. Переход организации к новому состоянию с помощью проекта

В качестве примеров материальных элементов можно назвать:

• денежные средства,

• акционерный капитал,

• инженерные сети,

• основные средства,

• инструменты,

• долю рынка.

В качестве примеров нематериальных элементов можно назвать:

• гудвилл (деловая репутация и коммерческий опыт),

• узнаваемость марки,

• общественное благо,

• товарные знаки,

• соответствие стратегии,

• репутацию.

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

• удовлетворение запросов или потребностей заинтересованных сторон;

• реализация или изменение бизнес- или технологических стратегий;

• создание, совершенствование или исправление продуктов, процессов или услуг.

Рис. 1–2. Контекст инициации проекта.

Таблица 1–1. Примеры факторов, которые вызывают необходимость в создании проекта.

Project Management Institute. 2016 г. Лексикон терминов управления проектами PMI. Можно найти на веб-сайте http://www.pmi.org/Lexiconterms.

Источник