В большинстве проектов менеджер не имеет возможности заниматься вопросами повышения квалификации персонала, психологической совместимости и т. п., поскольку проект – это временное мероприятие и, в отличие от функционального подразделения, после завершения проекта команда будет расформирована. Существует достаточно ограниченный круг проектов, в которых могут применяться принципы командообразования, в частности в проектах, требующих значительных творческих усилий. (Пример такого проекта будет приведен в гл. 9, п. 9.4.)
При назначении персонала необходимо иметь ввиду следующее, и об этом нам напоминает стандарт PMI:
1) не допускать неопределенности по поводу дальнейшего использования сотрудника после завершения им работы проекта. С этим трудно не согласиться: сотрудник должен знать свое будущее и планировать свои действия;
2) не пытаться загрузить сотрудника какой-либо работой, чтобы удержать работника в целях его дальнейшего использования. С этим требованием можно согласиться далеко не всегда. Хороших специалистов не так много. Если он уйдет, в дальнейшем при появлении нового проекта организация может столкнуться с проблемами и в итоге потерять в разы больше, чем затратила бы на удержание специалиста.
При формировании подхода к управлению персоналом руководитель проекта должен сформировать свое видение этой проблемы. Например, если мобильность персонала невысока, могут возникнуть трудности с привлечением сотрудника из другого региона. Именно поэтому специалиста приходится загружать какой-либо работой, не связанной с его основной деятельностью, чтобы удержать его в рамках организации.
Управление взаимодействием (коммуникациями)
Управление взаимодействиями и информационными связями, или коммуникациями, проекта заключается в разработке, организации и контроле процесса информационного обмена с помощью разнообразных средств для удовлетворения потребностей участников проекта. Включает процессы сбора, передачи, переработки, сортировки, отображения, интерпретации информации, необходимой и достаточной для всех участников проекта и его окружения.
В терминах управления проектами проектное взаимодействие означает эффективное распространение и сбор текущих проектных данных, а также связанной корпоративной информации, т. е. таких данных, как сообщения о совещаниях в компании, проверках и т. д.
При планировании взаимодействия важно определить потоки информации и способы взаимодействия, необходимые для участников проекта. Технология взаимодействия может быть самой разнообразной: инструкции, заседания, печатные документы, компьютерные графики, базы данных. Требуется разработать структуру сбора информации (кто и какую информацию получает, от кого и какими методами), структуру распределения информации (кому и какая информация направляется), описание формы, содержания, степени детализации, условных обозначений, сроки представления информации.
Взаимодействие является важной функцией управления. В реальной жизни слабое взаимодействие часто приводит к неудачам: непонятое или неправильно понятое распоряжение может привести к тому, что выполняемые исполнителем действия объективно будут направлены не на успех проекта, а во вред ему. Чтобы этого избежать, существуют простые правила. Так, в армии после получения приказания принято отвечать: "Есть!" Это означает: приказ понят и принят к исполнению. На флоте же требуется повторить любое приказание ("Право руля!" – "Есть право руля!"). Связано это с тем, что ошибка в понимании отданного распоряжения, да еще в условиях шторма, чревата тяжелыми последствиями.
Хороший пример организованного взаимодействия приведен в фильме "Экипаж" режиссера А. Митты. По сценарию самолет во время извержения вулкана забирает людей. Посадка закончилась, когда лава подступила к аэродрому. Казалось бы, надо срочно взлетать: самолет вот-вот сгорит. Вместо этого экипаж читает предполетную карту – перечень действий, которые необходимо выполнить для безопасного взлета. Все это время перед глазами светится табло "К взлету не готов". И только когда все требуемые действия выполнены, загорается другое табло: "К взлету готов", после чего командир отдает долгожданную команду: "Экипаж, взлетаем!" Подобное организованное взаимодействие чрезвычайно полезно не только в технических системах, но и в социотехнических, каковыми и являются большинство проектов.
Подсистема управления взаимодействиями – одна из важнейших подсистем управления проектом. Значение этой подсистемы видно из следующего примера. Крупная корпорация открыла новое направление, связанное с реализацией технологических проектов. Предполагалось поставить клиенту некую технологию вместе с оборудованием, которая позволила бы компании клиента выйти на новый уровень. Однако реализация проекта по непонятным причинам существенно тормозилась. В проекте был выделен ряд последовательных этапов, каждым из которых руководил отдельный менеджер, что обусловливалось спецификой каждого этапа.
Для выяснения причин сбоев проекта проведен детальный анализ двух потоков информации: той, которую должен был поставить руководитель первого этапа для реализации второго этапа, и той, которую ожидал руководитель второго этапа. Выяснилось, что расхождение в составе информационных потоков было более 40 %, и это при том, что никто не ограничивал менеджеров одной компании в обмене информацией.
Таким образом, можно сделать вывод о том, что обмен информацией в проекте должен быть специально организован.
Управление рисками
Важным элементом системы управления проектом является подсистема управления рисками проекта. Под риском проекта понимается событие или условие, которое в случае возникновения оказывает негативное воздействие на одну из целей проекта, например на сроки или стоимость. Надо заметить, что в стандарте PM BOK упоминается, что риски могут оказывать и положительное влияние на проект, однако в рамках данной книги подобные рисковые события рассматриваться не будут.
Управление рисками – это искусство и формальные методы определения, анализа, оценки, предупреждения возникновения, принятия мер по снижению степени риска на протяжении жизни проекта и распределения возможного ущерба от риска между участниками проекта.
Управление рисками является одной из сложнейших сфер деятельности менеджера. Обратим внимание на слова "искусство и формальные методы". Роль искусства, опыта, интуиции в управлении рисками чрезвычайно велика. По этой причине ведущие специалисты в области управления проектами рекомендуют выносить значительную часть подсистемы управления рисками за пределы проекта. Связано это с тем фактом, что не всегда квалификация менеджера достаточна для самостоятельного и эффективного управления рисками в рамках проекта. Для части этой подсистемы приходится привлекать внешних специалистов или менеджеров более высокого ранга и квалификации.
Система управления рисками отвечает за определение (идентификацию), оценку тем или иным способом степени угрозы от рискового события и разработку методов реагирования, т. е. защитных мер, способных предотвратить угрозу или уменьшить последствия ее наступления.
Управление рисками в реальном проекте отличается от методов, применяемых, например, в проектном анализе, в первую очередь тем, что менеджеру необходимо устранять или уменьшать результаты вредного воздействия рисков и тем самым влиять на успех проекта. По этой причине в реальном управлении не так важна оценка рисков на основе формально-математических методов. Чаще используются оценки рисков, основанные на опыте и здравом смысле менеджера проекта. Формализации поддается лишь часть процесса идентификации рисков.
Риску подвержены в той или иной мере все проекты и большинство аспектов проекта: финансовый, технический, организационный (нарушение сроков), социально-политический и т. п.
Умение предвидеть риски проекта (прогнозировать "возможные неприятности") в значительной степени зависит от опыта менеджера. Особенно это касается сложных многоплановых проектов типа НИОКР со значительной начальной неопределенностью многих параметров проекта. Эта неопределенность может относиться к результатам отдельных этапов, стоимости работ, эффективности тех или иных решений, выбору технологий и т. п. В этой ситуации в полной мере оправдывается наставление медиков – болезнь легче предотвратить, чем лечить. В управлении проектом это означает, что проще предвидеть неприятность (угрозу), чем потом из нее "выкарабкиваться".
Грамотное управление рисками позволяет руководителю проекта заранее увидеть возможные опасности и вовремя на них среагировать. Образно говоря, менеджер проекта, профессионально умеющий учитывать возможные риски и своевременно разрабатывать меры по минимизации их негативных воздействий, подобен капитану судна, у которого есть на борту хороший локатор и поэтому он уверенно и безопасно управляет судном в узком проливе и в туман, и ночью, и в условиях интенсивного движения.
Итак, руководитель проекта должен выработать в себе привычку в процессе реализации проекта постоянно прогнозировать возможные неприятности и своевременно готовиться к их устранению. Необходимо предвидеть наступление рисковых событий, а для снижения степени рисков создать систему реагирования на рисковые события, т. е. управлять рисками. Однако часто неопытные менеджеры для управления рисками используют методы, разработанные для оценки рисков и степени их угрозы в рамках проектного анализа, т. е. до начала исполнения проектов.
В проектном анализе (т. е. до начала проекта, например при разработке бизнес-плана) риск проекта характеризуется тремя факторами: событиями, оказывающими негативное воздействие на проект, вероятностью появления этих событий и оценкой возможного ущерба в результате наступления этих событий. Это позволяет определить возможные угрозы проекту и оценить величину потери в случае наступления этих нежелательных событий.
Методики определения числовых значений этих факторов широко используются на стадии предпроектных исследований. На этой стадии оценка рисков позволяет на основе некоторых критериев сравнивать проекты по такой их характеристике, как степень "опасности" для инвестора. Высокая оценка риска проекта служит сигналом опасности для инвестора. Конечно, низкая оценка риска проекта не гарантирует его 100 %-ную реализацию. Это означает лишь, что в проекте не предвидится больших или почти неотвратимых угроз.
Рассмотрим пример простого проекта, слабо привязанного к предметной области, что позволит нам понять суть отличия методологии управления рисками от анализа рисков на предпроектной стадии. Предположим, перед нами поставлена задача: закупить и доставить к месту монтажа какое-либо оборудование или продукцию (цель проекта). Для достижения этой цели выделены необходимые финансовые и иные ресурсы. Эти ресурсы, как и сроки, естественно, ограниченны.
По всем признакам это самый настоящий проект (или часть проекта), который, кстати, можно выполнять по-разному (выбрать подрядчика, у которого продукция дешевле или качественнее либо устраивают условия поставки и т. п.). В этом проекте, как и в любом другом, присутствуют различные риски, среди которых – срыв поставок, или поставка не в полном объеме, с ненадлежащим качеством, или плохие погодные условия, помешавшие поставке в срок.
Попытка в этой ситуации использовать подход к управлению рисками из проектного анализа обречена на неудачу. В самом деле, если определить возможные события риска вполне удастся, то дальше возникает неясность. Как определить вероятность того, что предполагаемый поставщик сорвет контракт? Чему будет равен ущерб? Как оценить вероятность плохой погоды? Как это отразится на проекте?
В реальном процессе управления для большинства проектов не столь уж важны численные значения вероятности и размера ущерба от наступления рискового события. Гораздо важнее выработать системную процедуру, позволяющую руководителю проекта реально воздействовать на успех проекта. Опытному руководителю проекта достаточно знать, что такое событие может наступить и ущерб от него может оказаться значительным. При этом отсутствие численных характеристик этих факторов отнюдь не означает невозможности или бесполезности реагирования на риски. Например, осторожный водитель в гололед не оценивает вероятность наступления рискового события (аварии) и величину ущерба, а минимизирует вероятность его наступления: ставит зимнюю резину, при езде по опасному участку снижает скорость и т. п.
Надо иметь в виду, что, если проект реализуется на чрезвычайно рисковом поле, система реагирования на рисковые события становится по затратам достаточно весомой, поэтому руководитель проекта должен реагировать не на все риски, а лишь на те из них, которые представляют наибольшую угрозу проекту. Вот для такого случая могут оказаться полезными модели, которые с приемлемой точностью позволяют оценить вероятность наступления нежелательного события и возможный ущерб от него. Кроме того, оценка вероятности риска в ряде случаев может помочь определить величину смещения сроков реализации проекта или оценить размер средств, которые будут использованы на компенсацию рискового события. Например, в описанном выше проекте "Перевод" оцененная экспертами максимальная доля ненадежных переводчиков, т. е. тех, кто может сорвать работу, вынуждает руководителя проекта пропорционально увеличить количество дополнительно привлеченных переводчиков (а значит, и увеличить бюджет проекта) или же согласиться с продлением срока завершения работы в случае невозможности привлечения дополнительных ресурсов.
Если же возникает необходимость не только оценивать величину смещения сроков проекта или размер дополнительных ресурсов, но и оперативно управлять рисками, следует использовать несколько иной подход.
В реальном проекте механизм управления рисками заключается в их идентификации, оценке угрозы, разработке защитных мер и реализации этих мер в случае наступления рискового события. Таким образом, система управления рисками включает в себя следующие основные процессы:
• идентификацию рисков;
• оценку рисков;
• разработку реагирования;
• управление реагированием.
Процесс идентификации рисков позволяет определить события риска, которые могут повлиять на проект. Далее следует оценка рисков, в результате которой риски разделяются на две группы: риски, требующие реагирования, и риски, не требующие реагирования. Вторая группа рисков не должна исчезать из поля зрения менеджера: может так случиться, что риски из второй группы перейдут в первую. Третий процесс – разработка реагирования, в результате которого вырабатываются меры по обеспечению противодействия рискам. Эти три процесса относятся к группе процессов планирования, и их использование подробнее рассматривается в гл. 4, п. 4.11.
Процесс "Управление реагированием" осуществляется на стадии управления проектом и включается в тот момент, когда обнаружено наступление соответствующего рискового события.
Управление поставками проекта
Эта система управления отвечает за весь спектр работ с поставщиками и подрядчиками. Можно выделить две группы процессов: первая группа связана с организацией поиска и отбора подрядчиков, включая организацию тендеров, вторая – с управлением контрактами. Стандарт PMI определяет следующие основные процессы этой подсистемы управления:
• планирование закупок и приобретений;
• запрос информации у продавцов;
• выбор продавцов;
• планирование контрактов;
• администрирование контрактов;
• закрытие контрактов.
Процессы, связанные с поиском и наймом подрядчиков, позволяют унифицировать эту процедуру, снизить влияние личностных предпочтений (включая угрозу так называемых откатов), уменьшить количество ошибок.
Процессы управления контрактами обеспечивают все действия по контрактам: выбор типа контракта, условий поставок, контроль документов, закрытие этапов и проекта и т. п.
2.4
Группы процессов проекта
В управлении проектами выделяют пять групп процессов управления, которые существуют в любом проекте, т. е. не зависят от предметной области проекта: процессы инициации, планирования, исполнения, анализа и завершения (рис. 2.4). Все процессы управления, входящие в группы процессов, связаны своими входами и выходами, т. е. результат одного процесса является входом для другого.