Согласно руководству к своду знаний по управлению проектами

________________________________________________________________________________________________

________________________________________________________________________________________________

Оглавление

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

Иллюстрация: May Gauthier / Unsplash / Pngegg / Annie для Skillbox Media

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

Больше 10 лет опыта в разработке крупных проектов и запуске цифровых продуктов для развития бизнеса (МТС, Х5, «Эльдорадо», «Авилон», «Русал»). Автор и преподаватель курса Skillbox «Управление проектами».

PMBoK (Project Management Body of Knowledge) — свод знаний по управлению проектами, в котором содержатся методики, подходы, инструменты и техники, необходимые для эффективного выполнения проекта.

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

PMBoK выпускает PMI — Институт управления проектами, одна из ведущих мировых организаций в области проектного управления. Кроме разработки единых стандартов управления проектами, PMI сертифицирует проектных менеджеров.

В статье для Skillbox Media разберёмся:

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

---

Как мы сказали выше, в PMBoK описаны различные методики, подходы, инструменты и техники управления проектами.

Если вы только начали знакомиться с управлением проектами, в Skillbox Media есть статья с базовой информацией об этом.

Первый PMBoK вышел в 1996 году. С того времени его регулярно обновляют и дополняют, поскольку появляется новый управленческий опыт, новые проблемы и их решения. Актуальное издание на январь 2023 года — PMBoK 7. Его выпустили в 2021 году.

С помощью PMBoK решают две основные задачи:

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

Стандарт от PMI — самый распространённый, но не единственный в области управления проектами. Есть и другие стандарты — например, PRINCE2, IPMA ICB, P2M, «ПМ Стандарт».

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

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

Современный PMBoK нельзя назвать самостоятельной методологией управления проектами — он объединяет рекомендации и лучшие практики из разных методик.

PMBoK включает в себя:

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

Основное содержание PMBoK поделено на десять областей знаний — фокусов внимания менеджеров проектов. Вот они:

• Управление содержанием проекта. Эта область знаний определяет, чего нужно достичь в рамках проекта и какие требования к результату необходимо учесть.
• Управление временем проекта. Включает в себя всё, что связано с расписанием и календарём проекта. Например, разработку графика, определение ключевых этапов и их последовательности, оценку длительности операций.
• Управление деньгами проекта. Включает в себя всё, что связано с финансовыми транзакциями: разработку бюджета, контроль затрат и платежей, управление прибылью.
• Управление качеством проекта. Включает в себя планирование качества, его обеспечение и контроль. На протяжении всего проекта важно отслеживать, чтобы всё, что было описано в рамках содержания проекта, выполнялось с заданным уровнем качества.
• Управление заинтересованными сторонами проекта. Подразумевает организацию общения между командой проекта и заинтересованными лицами — заказчиком, выгодоприобретателями, а также решение возникающих проблем.
• Управление коммуникациями проекта. Включает всё, что касается взаимодействий внутри команды проекта, а также связи с внешними командами, экспертами и подрядчиками. Управление коммуникациями необходимо для своевременного сбора, подготовки, передачи и использования данных о проекте.
• Управление ресурсами проекта. Подразумевает распределение командных ролей, а также управление ресурсами — например, серверами, программным обеспечением, недвижимым и движимым имуществом.
• Управление поставками проекта. Включает планирование закупок, выбор подрядчиков и поставщиков, подготовку и заключение контрактов с ними.
• Управление рисками проекта. К этой области знаний относят идентификацию рисков, их качественный и количественный анализ, планирование реагирования на риски, мониторинг рисков и действия по их нивелированию.
• Управление интеграцией проекта. Подразумевает объединение всех ресурсов и процессов проекта для его успешного проведения и завершения. Здесь описывают распределение ресурсов по проекту, возможные альтернативы выполнения проекта, поиск компромиссов между конфликтующими целями. Также эта область определяет связи между остальными областями знаний, описанными выше.

Согласно PMBoK, жизненный цикл любого проекта состоит из пяти этапов. Вот они:

• инициация;
• планирование;
• исполнение;
• мониторинг и контроль;
• завершение.

На каждом этапе возникают свои процессы, которые PMBoK подробно описывает.

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

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

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

Мониторинг и контроль. Процессы этой группы идут параллельно с процессами планирования и исполнения. Они предполагают непрерывную проверку соблюдения планов проекта — сроков, качества, стоимости.

Завершение. Эти процессы формализуют передачу результатов проекта и закрывают его. На этом этапе составляют финальные отчёты, передают результат заказчику, формируют окончательную документацию и распускают команду.

PMBoK наиболее эффективен в проектах двух видов:

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

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

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

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

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

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

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

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

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

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

• Купить и скачать PMBoK, а также узнать о его актуальных обновлениях можно на официальном сайте PMI. Версия для скачивания в формате PDF доступна на нескольких языках, включая русский.
• Проект — временное предприятие для создания уникального результата. В отдельном материале мы привели примеры проектов и разобрали, чем они отличаются от процессов.
• В проектном управлении много разных фреймворков и методик. Подробнее о них можно почитать в статьях Skillbox Media: в них разбирали Waterfall, Scrum, Agile, Kanban, метод критического пути.
• Чтобы управлять проектами, нужно уметь презентовать идеи, работать с бюджетом, мотивировать команду, планировать и распределять задачи. Всему этому можно научиться на курсе Skillbox «Профессия Менеджер проектов».

Научитесь: Профессия Менеджер проектов
Узнать больше

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

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

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

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

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

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

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

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

Перечислим эти группы процессов:

1. Процессы инициирования проекта – принятие решения об авторизации проекта.

2. Процессы планирования – определение и фиксация целей, планирование действий, необходимых для достижения целей и содержания, ради которых был предпринят проект.

3. Процессы исполнения – объединение трудовых и других ресурсов для выполнения плана.

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

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

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

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

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

Рис. 3.1. Общий обзор взаимодействий между группами процессов (по [РМВОК, 2004])

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

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

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

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

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

Группа процессов планирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Группа процессов исполнения

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

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

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

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

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

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

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

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

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

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

Группа процессов мониторинга и управления

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

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

1. Мониторинг соответствия текущих операций проекта плану управления проектом и базовому плану исполнения проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любое предприятие — это проект. Если у него все складывается удачно: растет производство, увеличиваются продажи и прибыль, то проект начинает расширяться — добавляются новые товары и услуги, открываются филиалы. И тут у руководителя возникает закономерный вопрос: а как этим всем управлять?

Есть много разных методик управления проектами. И одна из них — стандарт PMI PMBoK. О том, что он из себя представляет, и почему так популярен во многих странах, мы и расскажем в нашей статье.

Немного теории об этом стандарте

Стандарт PMI PMBoK — классификатор процессов, который помогает менеджерам рационально управлять проектами. Это фреймворк (своеобразная энциклопедия менеджмента), его можно адаптировать под любую организацию.

Создатель фреймворка — американский Институт управления проектами (PMI). Стандарт представляет собой справочник, который должен помогать управленцам в их работе. Этот свод «живой»: он регулярно обновляется и его можно адаптировать к любым процессам. К тому же он учитывает «зрелость» компании: частью методологии могут воспользоваться молодые компании, а другая — подойдет тем, кто уже прочно стоит на ногах.

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

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

Примечание: этот фреймворк лежит в основе других стандартов, от ГОСТ Р 54869-2011 до ISO 21500.

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

Читайте также:
Как проводить корпоративное обучение внутри компании

Что такое проект

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

Например, получение сертификата на знание иностранного языка — проект, а вот само изучение этого языка — процесс. Или другой пример: написание книги — проект, а вот копирование — процесс.

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

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

Читайте также:
Как выбрать нишу и запустить успешный стартап

Из каких этапов состоит проект

Любой проект состоит из его старта, подготовки, самого процесса выполнения и контроля над этим, завершения:

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

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

Стандарт PMI PMBoK состоит из нескольких этапов

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

Подготовка

Если говорить просто — это стадия, на которой выясняют, что есть некая задача, и ее нужно начать выполнять. Внутри этого этапа 2 два основных процесса:

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

Также на этом этапе продумывают бюджет, разрабатывают смету, и просчитывают возможные риски.

Читайте также:
Какие сотрудники нужны для обслуживания интернет-магазина

Планирование

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

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

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

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

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

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

Если же этого не сделать, то есть вероятность сорвать работу: потерять деньги, репутацию, выгодного клиента.

То есть, главный результат этого этапа — создание подробного плана управления проектом (PMP). Он может состоять из процессов, предлагаемых стандартом, а может включать только нужные процессы, или, наоборот, дополняться. Это «живой» документ, который корректируется в процессе выполнения поставленных целей.

Выполнение

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

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

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

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

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

Простыми словами менеджеры на этом этапе должны лавировать в схеме «время — деньги — качество». Желание сократить время исполнения может привести к увеличению расходов или снижению качества.

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

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

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

Читайте также:
Как повысить вовлеченность сотрудников и мотивировать их на новые подвиги

Контроль

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

Контроль за выполнением проекта состоит из 12 процессов. Они помогают своевременно реагировать на любые форс-мажорные ситуации

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

Окончание

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

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

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

Читайте также:
Финансовый анализ интернет-магазина: какие задачи он решает и как его проводить

В чем плюсы и минусы этого фреймворка

Как и любая система управления проектами, PMI PMBoK имеет сильные и слабые стороны. В чем удобство этого фреймворка:

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

Что можно выделить как минусы:

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

PMI PMBoK — это объемное руководство по управлению проектами. Его можно использовать как готовую схему — она отлично вписывается в работу с большими проектами.

Что касается выполнения небольших проектов, то стандарт PMI PMBoK дает возможность адаптировать его под собственные нужды.

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

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

2.4. Оценка зрелости организаций в области управления проектами

IPMA-DELTA

Международная ассоциация управления проектами (IPMA) разработала модель оценки зрелости организаций в области управления проектами DELTA. В основу данной модели положена концепция организационной компетентности в области управления проектами, которая предполагает анализ не только индивидуальной компетентности сотрудников и руководителей компании в области управления проектами, но и анализ созданной в компании системы управления проектами, включая нематериальные активы и ценности. Модель DELTA состоит из трех модулей: I – «Индивидуумы», P – «Проекты», O – «Организация». Оценка организации на уровень зрелости в области управления проектами выполняется на основании оценок каждого из трех модулей и взаимосвязей между ними.

В основе модуля I лежит стандарт ICB 3.0, определяющий требования к компетентности персонала. Наличие в компании сертифицированных менеджеров проектов является важной составляющей уровня зрелости организации. Требования DELTA предполагают, что сотрудники компании (руководители и члены команд проектов) могут провести самооценку на основе разработанного вопросника.

Модуль P позволяет оценить качество управления проектами компании и степень достижения результатов. Оценка по данному модулю базируется на модели оценки проектов IPMA Project Excellence.

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

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

ОРМЗ

Американский Институт управления проектами (PMI) также предлагает собственную модель оценки зрелости организации в области управления проектами OPM3 (Organizational Project Management Maturity Model). OPM3 включает базу знаний по «лучшим практикам» в области управления проектами и вопросник для оценки состояния организации с точки зрения применения данных практик. В основе базы знаний лежат стандарты PMI по управлению проектами, программами и портфелями проектов. На основании данной модели организация может провести самооценку и разработать план развития собственной системы управления проектами.

Резюме

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

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

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

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

• Международная ассоциация управления проектами IPMA (International Project Management Association).

• Институт управления проектами США PMI (Project Management Institute).

Россия уже более 20 лет является членом Международной ассоциации управления проектами. Россию в IPMA представляет Ассоциация управления проектами СОВНЕТ.

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

• сертификацию по стандартам IPMA;

• сертификацию по стандартам PMI.

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

Ключевые термины

Руководство проектной деятельностью (project governanace) – включает создание адекватной организационной структуры, принятые в организации процедуры и правила управления проектами, программами и портфелями проектов, административно-организационную поддержку реализации проектов и принятие решений по проектам на уровне высшего руководства.

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

Контрольные вопросы

1. Каковы основные тенденции развития дисциплины проектного менеджмента?

2. Каким образом расширяется сфера применения проектного менеджмента?

3. В чем заключается изменение роли менеджера проекта?

4. Какие профессиональные ассоциации в области управления проектами Вы знаете?

5. Каковы основные цели и задачи профессиональных ассоциаций в области управления проектами?

6. Какие существуют основные типы сертификаций в области управления проектами? В чем их различия?

7. Назовите основные модели оценки зрелости организаций в области управления проектами. Какие параметры оцениваются данными моделями?

Литература

1. Дополнительную информацию по деятельности IPMA можно получить на сайте IPMA: <www.ipma.ch>

2. Дополнительную информацию по деятельности Ассоциации управления проектами СОВНЕТ можно получить на сайте: <www.sovnet.ru>

3. Дополнительную информацию по деятельности PMI можно получить на сайте: <www.pmi.org>

4. Полковников А. В. Проектный менеджмент: базовые подходы и международные стандарты // Вестник технического регулирования. 2006. № 9. С. 4–14.

5. Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0). М.: ЗАО «Проектная ПРАКТИКА», 2010.

6. Crawford L., Hobbs J. B., Turner J. R. Project Categorization Systems and Their Use in Organizations: An Empirical Study, Innovations, Project Management Research, 2004. Newtown Square, Pennsylvania, USA: Project Management Institute. 2004. Р. 65–82.

7. Construction Extension to the PMBOK Guide. 3rd ed. Newtown Square, Pennsylvania, USA: Project Management Institute, 2007.

8. Government Extension to the PMBOK Guide. Newtown Square, Pennsylvania, USA: Project Management Institute, 2003.

9. Shenhar Aaron J., Dov Dvir. Project Management Evolution: Past History and Future Research Directions, Innovations, Project Management Research 2004, PMI.

Глава 3. Базовые понятия и определения управления проектами

Изучив материал данной главы, вы узнаете:

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

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

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

3.1. Определение проекта

В различных источниках (учебниках, статьях, стандартах) можно найти множество различных определений проекта, которые, впрочем, не противоречат, а, скорее, дополняют друг друга. Однако наиболее известным является следующее определение [PMBOK, 2004]:

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

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

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

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

Под объектами управления проектами понимаются проекты, программы и портфели проектов.

Субъектами управления проектами являются менеджеры проекта со стороны заказчика и исполнителя, а также команда управления проектом/ команда проекта.

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

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

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

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

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

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

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

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

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

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

Перечислим эти группы процессов:

1. Процессы инициирования проекта – принятие решения об авторизации проекта.

2. Процессы планирования – определение и фиксация целей, планирование действий, необходимых для достижения целей и содержания, ради которых был предпринят проект.

3. Процессы исполнения – объединение трудовых и других ресурсов для выполнения плана.

4.1 Основы проектного управления

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

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

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

Перед тем как верстать лекцию, прочтите, пожалуйста,

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

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

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

Основой современного проектного управления являются методы структуризации работ и сетевого планирования (метод критического пути Critical Path Method, CPM); система оценки и пересмотра планов проектов и программ (Program Evaluation and Review Technique, PERT), разработанные в конце 1950-х гг. в США. Впервые в полном объеме технология проектного управления свое практическое воплощение нашла в 1953–1954 гг. в подразделениях американских военно-воздушных сил. Одним из наиболее известных проектов, на котором были использованы методы моделирования и согласования комплекса работ, явился проект разработки ракетной системы «Поларис», начатый в 1957 г. Бурное развитие истории управления проектами в СССР началось в 1959 г. после появления американских публикаций о методах сетевого управления (CPM и PERT).

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

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

К двум наиболее популярным на сегодняшний день методологиям проектного управления (системам обучения и сертификации) относятся:

• базовый стандарт Project Management Base of Knowledge (Руководство к своду знаний по управлению проектами PMBoK) Института Управления Проектами (Project Management Institute, PMI) по управлению отдельными проектами, программами и портфелями проектов на основе описания 4 основных групп процессов – процессов по всестороннему планированию проекта; процессов по реализации проекта; процессами мониторинга и управления; процессами по завершению проекта (сдача продукта и передача ответственности и полномочий; закрытие проекта и связанных с ним контрактов) (американский подход);
• стандарт International Competence Baseline, ICB (Version 3.0) Международной Ассоциации Управления Проектами (International Project Management Association, IPMA), описывающий требования к компетенциям, необходимым менеджерам проектов и членам проектных команд для управления проектами, программами и портфелем проектов (европейский подход).

В силу специфических особенностей особую важность в проектном управлении приобрела концепция «жизненного цикла проекта», демонстрирующая смену фаз в течение срока реализации проекта. «Жизненный цикл проекта» (от англ. Project Life Cycle) – модель развития во времени, представленная в виде набора логически последовательно сменяющих друг друга фаз (этапов, стадий), количество и состав которых задается потребностями управления конкретным проектом. В общем виде принято выделять 4 фазы (жизненные циклы проектов в различных областях деятельности могут существенно различаться):

• концептуальная фаза (Concept Phase) – инициация проекта (анализ проблемы и потребности в проекте, сбор исходных данных, разработка концепции, рассмотрение альтернатив), разработка паспорта проекта и плана действий, определение целей и задач, выявление осуществимости проекта (технико-экономическое обоснование), формирование команды проекта и т.д.;
• фаза разработки проекта (Development Phase) – определение структуры работ, формирование бюджета проекта, разработка проектно-сметной документации (календарные планы выполнения работ), ресурсное обеспечение проекта, заключение контрактов с подрядчиками и поставщиками, др. сопутствующие работы;
• фаза выполнения проекта (Execution Phase) – реализация проекта (организация закупок и поставок, материальных и финансовых потоков, осуществление основных производственных процессов, информационное обеспечение, контроль жизнедеятельности проекта, управление изменениями) и т.д.;
• фаза завершения проекта (Termination Phase) – приемочные испытания, пробная эксплуатация, сдача объекта, анализ накопленной информации.

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

Согласно Руководству к своду знаний по управлению проектами (PMBoK), группы процессов управления проектом являются пересекающимися действиями, происходящими на протяжении всего проекта – выход одного процесса, как правило, становится входом для др. процесса или является результатом проекта. (рис.4.5).

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

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

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

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

4.2 Метод проектов в образовательном процессе в условиях реализации Федерального государственного образовательного стандарта (ФГОС)

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

Поскольку традиционный (классно-урочный) подход к обучению не позволяет создавать реальные условия для качественного решения указанной задачи, то вовлечение обучающихся в активную познавательную деятельность должно быть обеспечено привлечением новых образовательных средств (методик, педагогических технологий^{1Термин «педагогическая технология» (Education Technology), согласно экспертов ЮНЕСКО, системный метод создания, применения и определения всего процесса преподавания и усвоения знаний с учетом технических и человеческих ресурсов и их взаимодействия, ставящий своей задачей оптимизацию форм образования.}), способствующих раскрытию учениками своей личности, креативного отношения к возможностям собственного познания.

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

Метод проблем (метод проектов), предложенный еще в начале XX в. Дж. Дьюи, У.Х. Килпатриком, Э. Коллинзом, В.А. Лаем, Э. Торндайком и др. американскими учеными, был ориентирован на активную индивидуальную (парную, групповую) целесообразную деятельность учащихся с учетом их личных интересов и потребностей. Основой метода проблем, четко оформившегося в США к 1919 г., явились идеи гуманистической направленности, согласно которым образование следует рассматривать как процесс накопления и реконструкции уже имеющегося знания с целью углубления его содержания в ходе исследования учеником проблемной обучающей среды, изготовления различных макетов, схем, проведения экспериментов и опытов. Таким образом, метод проблем опирался на собственный путь ученика по преодолению затруднений в ходе выполнения конкретных практических заданий.

Примерно в те же годы идеи проектного обучения были подхвачены и стали развиваться в СССР. Так, в 1920-е гг. усилиями М.В. Крупениной, Б.В. Игнатьева, И.Я. Лернера, М.И. Махмутова, С.Т.Шацкого, В.Н. Шульгина и др. в советскую практику преподавания стал активно внедряться «метод проектов» как один из вариантов заимствованного из американской педагогики метода проблем и альтернативы классно-урочной системе. Однако недостаточная продуманность и отсутствие должной заинтересованности педагогов не способствовали формированию на основе метода проектов глубоких теоретических знаний учащимися, что, в конечном счете, привело к тому, что постановлением ЦК ВКП (б) 1931 г. «О начальной и средней школе» метод проектов как образовательная технология был запрещен для использования в отечественной школьной педагогике, а предметная система преподавания и классно-урочная система обучения провозглашены как единственно правильные. До середины 1980-х гг. к проблематике метода проектов не возвращались. Таким образом, первая, предпринятая в начале XX в. попытка внедрения проектного обучения, оказалась неудачной.

Во второй половине ХХ в. во многих странах (США, Великобритания, Канада, Франция, Германия и др.) значительно возрос интерес к методу проектов. Так, в рамках альтернативного образования в США (Б. Шлезингер) и Германии (И. Бей, Й. Шнайдер, К. Фрей) на базе метода проектов возникло новое направление в образовании – продуктивное обучение, стимулировавшее интерес детей к обучению через организацию их самостоятельной деятельности путем постановки перед ними целей и проблем, решение которых вызывает появление новых знаний и умений. Так, К. Фрей в своей книге «Проектный метод» выделил 17 отличительных черт метода проектов, среди которых: «участники проекта подхватывают проектную инициативу из жизни; участники проекта договариваются друг с другом о форме обучения; участники проекта развивают проектную инициативу, доводят ее до сведения всех; участники проекта организуют себя на дело; участники проекта информируют друг друга о ходе работы; участники проекта вступают в дискуссии». Согласно современной немецкой школы, использование метода проектов способствует приобретению учащимися:

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

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

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

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

В системе отечественного школьного образования метод проектов (вторая попытка внедрения проектного обучения) возродился в начале 1990-х гг., что было связано с развитием информационных технологий. Типология проектов и особенности технологии применения метода проектов в школьном образовании были представлены Е.С. Полат^{2Е.С. Полат: «Метод проектов – это одна из технологий обучения, основанная на модели-ровании взаимодействия в малой группе в ходе учебного процесса, где учащиеся принимают на себя различные социальные роли: организатора, исполнителя, лидера».} в учебном пособии «Новые педагогические и информационные технологии в системе образования». Со временем идея метода проектов претерпела некоторую эволюцию, но суть ее осталась прежней – стимулировать интерес учащихся к определенным проблемам, предполагающим владение конкретной суммой знаний, и через проектную деятельность, предусматривающую решение одной или целого ряда проблем, показать практическое применение полученных знаний.

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

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

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

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

• наличие значимой в исследовательском, творческом плане конкретной, социально значимой, исследовательской, информационной, практической проблемы/задачи, требующей интегрированного знания, исследовательского поиска для ее решения;
• практическая, теоретическая, познавательная значимость предполагаемых результатов (например, доклад в соответствующие службы о демографическом состоянии региона, факторах, влияющих на это состояние, тенденциях, прослеживающихся в развитии данной проблемы; совместный выпуск газеты, альманаха с репортажами с места событий; план мероприятий по охране леса в разных местностях, совместное сочинение нескольких учащихся и т.д.);
• самостоятельная (индивидуальная, парная, групповая) деятельность учащихся;
• определение конечных целей совместных/индивидуальных проектов;
• определение базовых знаний из различных областей, необходимых для работы над проектом;
• структурирование содержательной части проекта (с указанием поэтапных результатов) (планирование действий по разрешению проблемы; поиск информации; представление продукта заказчику – презентация продукта и защита самого проекта; проект – это «5 П» — проблема – планирование (проектирование) – поиск – продукт – презентация; шестое П – портфолио, папка в которой собраны все рабочие материалы (черновики, дневные планы, отчеты и др.));
• использование исследовательских методов (определение проблемы, вытекающих из нее задач исследования; выдвижение гипотезы их решения, обсуждение методов исследования; оформление конечных результатов; анализ полученных данных; подведение итогов, корректировка, выводы; использование в ходе совместного исследования метода «мозговой атаки^{3Мозговая атака– коллективный метод поиска новых технических идей и решений. Цель мозговой атаки – получение большого количества различных идей и предложений в ограниченное время (обычно 20-40 мин).}«, «круглого стола», статистических методов, творческих отчетов, просмотров, т.д.).

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

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

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

На рис.4.8 представлены типологические признаки метода проектов.

Метод проектов^{4Строгого общепринятого определения термина «метод проектов» на настоящий момент не выработано. Анализ специальной литературы показывает, что на данный момент не раскрыта психолого-педагогическая сущность проектной деятельности, дидактические возможности и функции метода, нет целостной модели проектной деятельности, не разработана система, включающая различные виды постепенно усложняющихся проектов, отсутствуют необходимые учебные пособия и разработки В рамках Лекции под «методом проектов» понимается самостоятельная исследовательская деятельность обучающихся в рамках совокупности в определенной последовательности приемов и действий (комплекса поисковых, исследовательских, расчетных, графических и др. видов работ) для достижения поставленной задачи – решения некоторой значимой проблемы в виде конкретного конечного осязаемого результата и его оформления.} в настоящее время переживает свое «второе рождение», что связано с его соответствием идеям модернизации в целом и модульно-компетентностному подходу в частности, позволяя в сочетании с информационными технологиями придать массовому обучению индивидуальный характер. Именно поэтому метод проектов, использующий умение адаптироваться к стремительно изменяющимся условиям жизни человека постиндустриального общества, относят к технологиям XXI в.

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

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

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

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

Деятельность обучающихся по методике учебного проектирования с применением информационных технологий основана на следующих этапах проведения (технологической цепочке действий^{6Необходимо отметить отсутствие в научной литературе единства в количестве и названиях этапов проведение проектной деятельности.}) :

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

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

Литература

1. Деренская Я.Н. Классификация проектов в проектном менеджменте [Электронный ресурс].URL: http://www.finanalis.ru/litra/328/2895.html.
2. Балашов А.И. Управление проектами: учебник для бакалавров / А.И. Балашов, Е.М. Рогова, М.В. Тихонова, Е.А. Ткаченко; под ред. Е.М. Роговой. — М.: Издательство Юрай, 2013. — 383 с.
3. Проектный менеджмент в вузе. Учебные кейсы, под ред. Ф.А. Казина, Н.Р. Тойвонена — СПб: НИУ ИТМО, 2012. — 182 с.
4. Мир Управления проектами. Под редакцией Х.Решке, Х.Шелле. Пер. с английского. — М.: АЛАНС, 1993.
5. Путеводитель в мир управления проектами: Пер. с англ. – Екатеринбург: УГТУ,1998. – 191с.
6. Гейзлер П.С., Завьялова О.В. Управление проектами. Учебное пособие. – Мн.: БГЭУ, 2005.
7. Гонтарева И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами . – М.: Либроком, 2013. – 384 с.
8. Ивасенко А.Г., Никонова Я.И., Каркавин М.В. Управление проектами. – Ростов н/Д: Феникс, 2009. – 336 с.
9. Ильина О. Управление проектами: ориентация на устойчивое развитие // Проблемы теории и практики управления. – 2012. – N1. – С.106-109.
10. Юрьева Т.В. Управление проектами и приоритетными программами // Экономический анализ: теория и практика. – 2012. – N36. С.23-29.
11. Постановление ЦК ВКП (б) 1931 г. «О начальной и средней школе» // Педология. – 1931. – N4 (16). – С.3-8.
12. Дьюи Дж. Психология и педагогика мышления (Как мы мыслим) / Пер. с англ. Н.М. Никольской; редакция Ю.С. Рассказова. – М.: Издательство «Лабиринт», 1999. – 192 с.
13. Дьюи Дж. Введение в философию воспитания. – М.: Работник просвещения, 1921. – 63 с.
14. Дьюи Дж. Моя педагогическая вера / Демократизация образовательного процесса в школе : хрестоматия для учителя / Ред.-сост. Г.Б. Корнетов. – М., 2007. – С. 223-232.
15. Дьюи Дж. Школа и общество. – М.: Работник просвещения, 1922. – 174 с.
16. Фрей К. Проектный метод. – Берлин: Бельц, 1997. – 349с.
17. Полат Е.С. Метод проектов на уроках иностранного языка // Иностранные языки в школе 2000. – N 2, 3.
18. Полат Е.С. Метод проектов: типология и структура// Лицейское и гимназическое образование. – 2002. – N 9.
19. Новые педагогические и информационные технологии в системе образования / Под ред. Е.С. Полат: Уч. пособие. – М.: Издательский центр «Академия», 2005. – 272 с.
20. Романовская М.Б. Метод проектов в учебном процессе. Методическое пособие. – М.: Центр «Педагогический поиск», 2006. – 160 с.
21. Сергеев И.С. Как организовать проектную деятельность учащихся: Практическое пособие для работников общеобразовательных учреждений. – М.: АРКТИ, 2003. – 80 с.
22. Шкель В.Ф. Проектные технологии в образовательном учреждении. Учебно- методическое пособие. – Саратов: Изд-во «Научная книга», 2007. – 37 с.
23. Гоппе Н.Н. О переходе к проектной технологии // Педагогическое обозрение. – 2000. – N4. – С.110-115.
24. Сергеев И.С. Как организовать проектную деятельность учащихся.- М.: АРКТИ, 2008. – 80 с
25. Гузеев В.В., Романовская М.Б. Современные технологии профессионального образования: интегрированное проектное обучение / Приложение к журналу №Профессиональное образование». – М.: Издательский центр НОУ ИСОМ, 2006. — Часть 1. – N6. – 48 с.
26. Чечель И. Метод проектов: субъективная и объективная оценка результатов // Директор школы. – 1998. – N4. – С. 7-12.
27. Ступницкая М.А. Что такое учебный проект? – М.: Первое сентября, 2010.

A Guide to the Project Management Body of Knowledge (далее PMBoK) — руководство к своду знаний по управлению проектами представляет собой совокупность профессиональных знаний по управлению проектами, признанных в качестве стандарта.

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

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

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

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

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

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

Институт управления проектами PMI (Project Management Institute) использует данный стандарт в качестве основного справочного материала по управлению проектами для своих программ профессионального развития и сертификации.

История Project Management Body of Knowledge

Первое издание PMBoK, было выпущено Институтом управления проектами (PMI — Project Management Institute) еще в 1986 году. Это была революционная методология, которую изначально ориентировали на помощь членам института в рамках подготовки к экзамену PMP (Project Management Professional), а так же данная методология по управлению проектами должна была оказать влияние на подход к управлению проектами в будущем.

Методология получила название «A guide to the Project Management Body of Knowledge» или PMBoK. Уже в 1991 году методологию PMBoK признают национальным стандартом ANSI (American National Standards Institute). Первую редакцию такого стандарта по управлению проектами опубликовали в 1994 году. Через два года была выпущена вторая редакция PMBoK, это произошло из-за быстрого роста членов PMI.

В скором будущем появилась третья редакция и называлась она — PMBoK Guide 2000. В 2004 году PMI выпускает своё очередное творение — PMBoK Guide Third Edition, которое получило самое большое распространение свода знаний по управлению проектами PMI.

31 декабря в 2008 году вышла в свет новая версия методологии — PMBoK Fourth Edition, которая, как и свой предшественник претерпела значительные изменения и стала по сути таким же революционным изданием. В этой версии были изменены сами методики PMI. В стандарт включили дополнительные методики: ведения аналитических работ, прототипирование, итеративность и применение систем искусственного интеллекта с целью построения прогноза реализации и завершения проекта в части сроков и бюджета.

В настоящее время выпущена еще одна версия — PMBoK Guide Fifth Edition, которая включает в себя уже 10 областей знаний и 5 дополнительных процессов (количество процессов всегда менялось от версии к версии, но вот дополнительная область знаний по управлению проектами, добавили впервые).

Дополнительная область знания — Управление заинтересованными лицами (разделили область знаний Communication Management на две: Communication Management и Stakeholders Management). Дополнительные процессы следующие — Plan Scope Management, Plan Schedule Management, Plan Cost Management, Plan Stakeholder Management, а также Control Stakeholder Engagement. Обновление программ сертификации произойдет с 1 июля 2013 года. Дата выпуска PMBoK Guide 6th Edition еще не известна, но PMI уже определились с годом — 2016 год.

Описание методологии PMBoK

Области знаний PMBoK

Руководство PMBoK описывает десять областей знаний, которыми должен обладать руководитель проекта (project manager). В стандарте рассматривается каждая область знаний в отдельности, описываются её процессы входов и выходов.

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

Управление интеграцией проекта (Project Integration Management)

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

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

Управление содержанием проекта (Project Scope Management)

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

Управление содержанием проекта напрямую связано с определением и контролем того (содержания), что будет включено и что не будет включено в проект. Описываются схемы процессов Сбора требований, Определения содержания проекта, создания Иерархической структуры работ — ИСР (Work Breakdown Structure, WBS), Подтверждения содержания и Управления содержанием.

Управление сроками проекта (Project Time Management)

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

Управление стоимостью проекта (Project Cost Management)

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

Управление качеством проекта (Project Quality Management)

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

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

Управление человеческими ресурсами проекта (Project Human Resource Management)

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

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

Схема процессов управления человеческими ресурсами включает в себя: Разработку плана управления человеческими ресурсами, Набор команды проекта, Развитие команды проекта и Управление командой проекта.

Управление коммуникациями проекта (Project Communications Management)

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

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

Схема  процессов управления коммуникациями проекта включает в себя: Определение заинтересованных сторон проекта, Планирование коммуникаций, Распространение информации, Управление ожиданиями заинтересованных сторон проекта (начиная с пятой версии — PMBoK Fifth Edition, данные процессы вынесли в отдельную область знаний — Управление аинтересованными сторонами проекта Project Stakeholder Management), Отчеты об исполнении.

Управление рисками проекта (Project Risk Management)

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

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

Управление поставками проекта (Project Procurement Management)

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

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

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

Управление заинтересованными сторонами проекта (Project Stakeholder Management)

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

Группы процессов PMBoK

Все процессы в руководстве PMBoK разделяются на следующие группы:

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

Группа процессов инициации состоит из процессов, способствующих формальной авторизации начала нового проекта.

• Разработка Устава проекта (Develop Project Charter)
• Определение заинтересованных сторон (Identity Stakeholders)

Группа процессов планирования

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

• Разработка плана управления проектом (Develop Project Management Plan)
• План управления содержанием (Plan Scope Management)
• Сбор требований (Collect Requirements)
• Определение содержания (Define Scope)
• Создание иерархической структуры работ — ИСР (Create Work Breakdown Structure — WBS)
• Разработка плана управления расписанием (Develop Schedule Management Plan)
• Определение операций (Define Activities)
• Определение последовательности операций (Sequence Activities)
• Оценка ресурсов операций (Estimate Activity Resources)
• Оценка длительности операций (Estimate Activity Durations)
• Разработка расписания (Develop Schedule)
• Разработка плана управления стоимостью (Develop Cost Management Plan)
• Оценка стоимости (Estimate Costs)
• Определение бюджета (Determine Budget)
• Планирование качества (Plan Quality)
• Разработка плана управления человеческими ресурсами (Develop Human Resource Plan)
• Планирование коммуникаций (Plan Communications)
• Планирование управления рисками (Plan Risk Management)
• Идентификация рисков (Identify Risks)
• Качественный анализ рисков (Perform Qualitative Risk Analysis)
• Количественный анализ рисков (Perform Quantitative Risk Analysis)
• Планирование реагирования на риски (Plan Risk Responses)
• Планирование закупок (Plan Procurements)
• Разработка плана управления заинтересованными сторонами (Develop Stakeholder Management Plan)

Группа процессов исполнения

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

• Руководство и управление исполнением проекта (Direct and Manage Project Execution)
• Ообеспечение качества (Perform Quality Assurance)
• Набор команды проекта (Acquire Project Team)
• Развитие команды проекта (Develop Project Team)
• Управление командой проекта (Manage Project Team)
• Управление коммуникациями (Manage Communications)
• Осуществление закупок (Conduct Procurements)
• Управление вовлеченностью заинтересованных сторон (Manage Stakeholder Engagement)

Группа процессов мониторинга и управления

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

• Мониторинг и управление работами проекта (Monitor and Control Project Work)
• Общее управление изменениямиОбщий контроль изменений (Perform Integrated Change Control)
• Подтверждение содержания (Validate Scope)
• Контроль содержанияУправление содержанием (Control Scope)
• Контроль расписанияУправление расписанием (Control Schedule)
• Контроль стоимостиУправление стоимостью (Control Costs)
• Процесс контроля качества (Perform Quality Control)
• Мониторинг и контроль коммуникаций (Monitor and Control Communications)
• Мониторинг и контроль рисков (Monitor and Control Risks)
• Контроль закупокконтрактов (Control Procurement)
• Контроль вовлеченности заинтересованных сторон (Control Stakeholder Engagement)

Группа завершающих процессов

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

• Закрытие проекта или фазы (Close Project or Phase)
• Закрытие контрактов (Close Procurement)

Жизненный цикл по PMBoK

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

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

Инструменты и методы PMBoK

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

Данные инструменты и техники существуют сами по себе и уже давно применяются в различных направления деятельности человека. В процессах PMBoK существуют входы, выходы и методы. Именно при реализации методов определенных процессов и подразумевается применение руководителем проекта (Project Manager) тех или иных инструментов и техник. Ниже приведен список основных методов, инструментов и техник применимых к определенным процессам:

Методы

• Анализ дерева решений (Decision Tree Analysis).
• Анализ допущений (Assumptions Analysis).
• Анализ ожидаемого денежного значения (Expected Monetary Value (EMV) Analysis).
• Анализ отклонений (Variance Analysis).
• Анализ сети (Schedule Network Analysis или Network Analysis).
• Анализ сильных и слабых сторон, возможностей и угроз (Strengths, Weaknesses, Opportunities, and Threats Analysis, или SWOT Analysis).
• Анализ характера и последствий отказов (Failure Mode and Effect Analysis, FMEA).
• Aнализ чувствительности (Sensitivity Analysis).
• Быстрый проход (Fast Tracking).
• Выравнивание ресурсов (Resource Leveling).
• Декомпозиция (Decomposition).
• Метод «операции в узлах» (метод диаграмм предшествования) (Precedence Diagramming Method, PDM).
• Метод Дельфи (дельфийский метод) (Delphi Technique).
• Метод критического пути (Critical Path Methodology, CPM).
• Метод критической цепи (Critical Chain Method).
• Метод Монте-Карло (Monte Carlo Analysis).
• Метод освоенного объема (Earned Value Technique, EVT).
• Метод оценки и анализа программ (Program Evaluation and Review Technique, PERT).
• Мозговой штурм (Brainstorming).
• Оценка «снизу вверх» (Bottom-up Estimating).
• Планирование методом набегающей волны (Rolling Wave Planning).
• Управление освоенным объемом (Earned Value Management, EVM).

Инструменты

• Диаграмма Ганта (Gantt Chart).
• Диаграмма Парето (Pareto Chart).
• Иерархическая структура рисков (Risk Breakdown Structure, RBS).
• Информационная система управления проектами (Project Management Information System, PMIS).
• Матрица вероятности и воздействия (Probability and Impact Matrix).
• Матрица ответственности (Responsibility Assignment Matrix, RAM).
• Расписание контрольных событий (Milestone Schedule).
• Сетевая модель (Schedule Model).
• Система санкционирования выполнения работ (Work Authorization System).
• Система управления изменениями (Change Control System).
• Система управления конфигурацией (Configuration Management System).

Экзамены, сертификация и обучение

На данный момент в мире насчитывается более 470,000 менеджеров и специалистов по управлению проектами, имеющих сертификацию PMP – Project Management Professional. Степень по управлению проектами PMP, может получить каждый специалист из любой отрасли. PMP позволяет войти в ряды самого большого и престижного сообщества специалистов по управлению проектами.

Для получения степени PMP,  необходимо соответствовать определенным требованиям к образованию и опыту работы. Также необходимо пройти экзамен в виде теста на компьютере в специализированных аккредитованных центрах по всему миру (Registered Education Provider). Данный тест разработан для объективной оценки компетенций претендента в части управления проектами.

Требования к кандидату

Необходимо соответствовать первой или второй категории. Первая категория — высшее образование (не ниже бакалавра), 4,500 часов (36 непересекающихся месяцев за последние 6 лет) работы в области управления проектами (по пяти группам процессов) до подачи заявки. Также на момент подачи заявки, кандидат должен иметь 35 часов обучения (PDU).

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

1. Сведетельство о высшем образовании.
2. Форма подтверждения опыта
3. Перечень обучающих программ, пройденых кандидатом (35 PDU)

Посредством теста на степень PMP оцениваются применение знаний и навыков, использование инструментов и методов применяемых на практике при управлении проектами. Еще в 1997 году были разработаны требования к экзамену. Претенденту необходимо выбрать один правильный ответ из 4 вариантов по каждому из 200 вопросов. Сам тест состоит из 175 вопросов, остальные 25 вопросов определяются, как претестовые и в зачет не идут. Все вопросы в тесте разрабатываются комиссией, состоящей из специалистов со степенью PMP. Вопросы входящие в тест, ежегодно проверяются на соответствие экзаменационным требованиям. Для успешного прохождения теста, претенденту, за 4 часа, необходимо положительно ответить на 106 вопросов из 175. Получается, что проходной балл по экзамену составляет 61%.

Подготовка к экзамену PMP

Из множества учебников и материалов для подготовки к экзамену на степень PMP основным конечно же является сам свод знаний по управлению проектами — PMBoK Guide. Данный стандарт на двух языках (английский и русский) и множество дополнительных материалов (книг и учебников) по управлению проектами можно приобрести в специализированных on-line магазинах PMI.

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

Содержание экзамена PMP

Далее в процентном соотношении представлена разбивка вопросов экзамена по группам процессов:

• Инициация проекта (Project Initiating) – 13 % вопросов
• Планирование проекта (Project Planning) – 24 % вопросов
• Исполнение проекта (Project Executing) — 30 % вопросов
• Контроль проекта (Project Control) – 25 % вопросов
• Завершение проекта (Project Closing) – 8 % вопросов

В свое время, PMI провело исследование по описанию ролей (The Role Delineation Study), которое в последствии легло в основу Кодекса Профессиональной Этики (PMP Examination Specification). Данное исследование описывает экзаменационные вопросы, и как следствие служит отличным материалом для подготовки к экзамену.

Просмотры: 32 393