Комментарии по теме

«Деловой партнер»
Власта Венц:
курсы FSC010 Business Processes in Treasure & Risk Management (на английском) FSC110 Customizing in SAP Treasure &Risk Management (на английском)
«Внедряй! SP1»
Сергей Поздняков:
п.1. Залог успеха любого проекта - подготовка бизнес-выгод до начала проекта уровня первого лица или, например отдельно по направлению каждого вице-президента, тогда количество врагов можно...
«Деловой партнер»
Олег Точенюк:
А не? training.sap.com/course/wrubp----bp-and-cvi-issue-classroom-010-ru-ru ?#

База знаний

РП в поисках шампанского или опять про управление рисками!

1348

Оглавление

Вступление

Риск, как угроза достижению целей проекта

Принципы управления ожиданиями в проекте «Мы сделаем это с вами!»

Не превращайте управление требованиями в коллекцию проектных угроз

Проектное планирование, как препятствие достижению проектных целей!

План в наследство

Излишняя детализация проектных планов

Три срока выполнения работ

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

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

Формирование проектной команды

Агенты влияния

 Заключение Немного  ортодоксальной методологии

Вступление

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

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

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

Риск, как угроза достижению целей проекта

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

Принципы управления ожиданиями в проекте «Мы сделаем это с вами!»…

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

Не превращайте управление требованиями в коллекцию проектных угроз

Итак, в нашем проекте зафиксированы проектные требования, они согласованы с бизнес экспертами, архитекторами, заказчиком. Мы сформировали план работ, связали проектные задачи с достижением проектных целей и… Расслабились. Ну, не то что бы все расслабились. Консультанты, разработчики, специалисты по миграции, интеграции и прочие члены проектной команды принялись за работу. А руководители проекта из нирваны всеобщей согласованности свалились в многочисленные частные проблемы и пустили на самотек уточнение требований консультантами, договоренности по «замене одного на другое» и прочие факторы, в конечном итоге влияющие на проектные требования и цели. Как итог: разбалансированный список требований с многочисленными, не всегда формализованными или согласованными «заплатками». Латание «дыр» в методологии или скоротечное реагирование на форс-мажорные ситуации и, «вуаля»! Реестр требований превратился в коллекцию угроз своевременному завершению проекта, ну или, как минимум, в резкое усложнение процедуры согласования результатов проектных работ. Избежать данного риска не сложно. Как говорится, главное не расслабляться. После согласования реестра требований примите как должное, что он будет уточняться и, возможно, меняться. Опять же по разным, в т.ч. объективным причинам. Поставьте эти изменения на контроль. Ознакомьте с этой процедурой проектную команду. Формализуйте цепочку согласования изменений. И, наконец, увяжите регулярное рассмотрение плана реагирования на проектные угрозы-риски с процедурой управления требованиями!

Проектное планирование, как препятствие достижению проектных целей!

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

План в наследство

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

Ограниченный доступ

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


Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»