2.3 Функции и подсистемы управления проектом

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

• планирование;

• контроль;

• анализ;

• принятие решений;

• составление и сопровождение бюджета проекта;

• организация осуществления;

• мониторинг;

• оценка;

• отчетность;

• экспертиза;

• проверка и приемка;

• бухгалтерский учет;

• администрирование.

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

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

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

Управление интеграционными процессами

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

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

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

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

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

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

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

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

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

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

• рассмотрение и одобрение запрошенных изменений;

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

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

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

• контроль качества проекта по стандартам на основе отчетов о качестве.

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

Закрытие проекта – интеграционный процесс, обеспечивающий завершение всех операций проекта.

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

Управление содержанием

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

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

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

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

Управление сроками

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

Управление сроками включает в себя:

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

• минимизацию (оптимизацию) временных характеристик;

• разработку расписания;

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

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

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

• принятие решений по ликвидации нежелательных временных отклонений;

• оценку продолжительностей;

• календарное планирование.

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

ПРИМЕР. Иностранная компания S нуждалась в переводе на английский язык 85 патентов (примерно 1000 страниц текста с формулами). Если бы этот объем работы был запланирован на год, вряд ли возникла необходимость использования каких-либо специфических методов управления проектами при выполнении этой работы: можно выдавать одному-двум переводчикам по 5–10 страниц в день и вести учет. При этом какие-либо риски отсутствуют. В данном случае сроки были жестче: перевод патентов необходимо было выполнить за полтора месяца. Компания S обратилась в консалтинговую компанию М-С с просьбой помочь ей решить эту проблему. Важным требованием являлось выполнение работы точно в срок. Материалы необходимо было отправить самолетом не позднее заранее известной даты: если опоздал, то работа теряла смысл, а значит, исполнитель не получил бы оплату за выполненную работу. Сотрудники М-С проанализировали свои возможности и согласились выполнить работу. Были определены: стоимость работы, количество необходимых переводчиков, срок работы. Однако заказчику показалась завышенной названная стоимость работы, и было решено поручить ее специализированному переводческому бюро. Сотрудники инофирмы начали переговоры с несколькими переводческими бюро по условиям выполнения работы. Однако переводческие бюро одно за другим отказывались от этой работы: в самом деле, сложный технический текст, отсутствие переводчиков, понимающих терминологию данной предметной области, а полтора месяца – очень жесткий срок. Шло время. Когда до требуемого срока оставалось семь дней (!), иностранная компания снова обратилась в М-С с просьбой организовать перевод патентов. Совершенно ясно, что риски проекта возросли многократно, как и сложность работы. Если при отсутствии ограничений по времени проблем с выполнением работ не возникало, как и с организацией работы, то при таком жесточайшем сроке завершения проекта было не обойтись без специфических методов управления.

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

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

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

Рисунок. Подсистема управления временем проекта (прогноз времени завершения)

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

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

Еще один пример, в котором использовалась та же самая система прогноза времени завершения работы. Строительная компания «АВС-строй» осуществляла строительство важного объекта. Большой объем работ составляли работы по фигурной укладке кирпича, примерно 1000 кв. м (цифры условные). Эта работа должна выполняться каменщиками высокой квалификации, обученными вести фигурную кладку. Если бы сроки, как это часто бывает, были заданы не очень жестко, никаких проблем с выполнением этого объема работы не возникло бы. Вряд ли появилась бы и необходимость каких-либо специфических методов выполнения этой работы: можно ежедневно выдавать задания имеющемуся составу рабочих и вести учет. В этом случае какие-либо риски отсутствуют. В описываемом примере сроки были заданы гораздо жестче: кладку необходимо было завершить в течение месяца – к началу октября. Руководитель проекта (прораб) считал, что он успевает закончить работы в срок. Однако руководители компании опасались, что проект может быть выполнен с опозданием, поскольку приходилось перебрасывать рабочих на другие объекты и было трудно оценить дату завершения.

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

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

Используя эту информацию, специалисты ежедневно рассчитывали предполагаемую дату завершения проекта, допуская, что с текущей даты количество рабочих не будет меняться. Для прогноза времени завершения Тпрi на i-й день использовалась формула Тпрi = 1000 – Vi/Ккi ? P, где Ккi – количество каменщиков, вышедших на работу в i-й день.

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

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

Управление стоимостью

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

Эта подсистема включает в себя:

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

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

• планирование денежных потоков;

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

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

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

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

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

Управление качеством содержит:

• технические аспекты (контроль качества);

• управленческие аспекты (обеспечение качества);

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

Управление качеством распространяется на весь жизненный цикл, все стороны и элементы проекта:

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

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

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

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

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

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

Управление персоналом (человеческими ресурсами)

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

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

• поиск и отбор кандидатур;

• оформление приема на работу и увольнения;

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

• организацию обучения и повышения квалификации;

• определение ответственности;

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

• предупреждение и разрешение возникающих конфликтов;

• оплату труда.

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

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

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

При назначении персонала необходимо иметь ввиду следующее, и об этом нам напоминает стандарт PMI:

1) не допускать неопределенности по поводу дальнейшего использования сотрудника после завершения им работы проекта. С этим трудно не согласиться: сотрудник должен знать свое будущее и планировать свои действия;

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

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

Управление взаимодействием (коммуникациями)

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

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

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

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

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

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

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

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

Управление рисками

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• идентификацию рисков;

• оценку рисков;

• разработку реагирования;

• управление реагированием.

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

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

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

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

• планирование закупок и приобретений;

• запрос информации у продавцов;

• выбор продавцов;

• планирование контрактов;

• администрирование контрактов;

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

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

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