7.1. Организация управления рисками в команде проекта
Люди – один из факторов успеха любого проекта, поэтому в ИТ-проектах «человеческий фактор» играет важнейшую роль как в процессе выбора и внедрения информационной системы или решения, так и в процессе их последующей эксплуатации и использования всеми сотрудниками компании.
С организационной точки зрения, сложность ИТ-проекта заключается в большом количестве участников (заказчики, спонсоры, консультанты, члены проектной команды, ИТ-служба заказчика, представители функциональных подразделений, эксперты и др.). Основные организационные проблемы, с которыми сталкивается ИТ-проект, происходят из-за того, что в проекте не до конца определены роли и ответственность, не прописаны санкции за несвоевременное или некачественное выполнение задач, отсутствует система развития, обучения и мотивации сотрудников.
Еще одна сложность состоит в том, что процесс внедрения, занимающий достаточно много времени, протекает одновременно с выполнением сотрудниками своих повседневных обязанностей. Несмотря на то что сотрудники вынуждены выполнять дополнительные функции и отчитываться перед проектным менеджментом, требования со стороны их непосредственного руководства не уменьшаются.
Рассмотрим основные риски, связанные с организацией проекта внедрения ИТ.
Недостаточная квалификация персонала. Низкая компьютерная грамотность в производственных подразделениях, недостаточные знания общих функций и назначения информационной системы в ИТ-структуре.
Сопротивление персонала проекту. В проекте всегда находятся люди, которым этот проект экономически не выгоден, люди, которые боятся внедрения новой системы либо не хотят никаких изменений.
Недостаток мотивации персонала. Отсутствует лидерство, либо спонсор проекта и менеджмент компании не обеспечили условия, когда все участники заинтересованы в успешном завершении.
Нечетко определенные цели проекта, несоответствие потребностям бизнеса. Неточное определение целей и масштаба проекта приводит к значительным финансовым затратам на доработку системы в соответствии с бизнес-требованиями и потребностями пользователей.
Неоптимальная организационная структура. Типовая структура предприятия предназначена для решения повседневных задач и не приспособлена для реализации проектов, что негативно влияет на четкое распределение ответственности, коммуникации, контроль результатов.
Недоступность ресурсов для проектных работ. Как правило, «лучшие специалисты» уже заняты.
Снижение рисков провала внедрения системы из-за недостаточной квалификации персонала предприятия достигается двумя способами – на основе создания дружественного интерфейса и путем создания эффективной системы обучения. Интерфейс внедряемой системы должен позволять объединить на одном экране пользователя все выходы в формы, необходимые для выполнения его функций. Иначе говоря, пользователь не должен знать, как устроена система, а просто использовать дружественный интерфейс для выполнений своих функций. Простое в использовании построение интерфейса позволяет качественно снизить требования, предъявляемые к квалификации персонала. Система обучения предполагает формирование сертифицированных специалистов по внедрению и обучению определенным модулям, а также закрепление их за соответствующими функциональными отделами. Такой подход дает возможность полностью исключить риск недостаточной квалификации персонала, то есть сделать внедрение системы исключительно функцией четкой организационной работы.
Очень часто, несмотря на полезность и удобство системы, пользователи системы не желают использовать новые возможности. Это происходит из-за низкого уровня компьютерной грамотности пользователей и сложившейся привычки использования устаревших систем. Люди не любят перемен, что вызывает нежелание переходить на новые технологии, которые позволят руководству лучше контролировать деятельность сотрудников.
Сопротивление изменениям может быть также вызвано боязнью сотрудника потери контроля над своими функциями и доступной информацией, избытком неопределенности. Зачастую с возникновением новых технологий появляются новые должностные обязанности по использованию системы, освоению новых функций, созданию отчетов для руководства. Возможность дополнительного контроля со стороны руководства является еще одним поводом для беспокойства сотрудников.
Для снижения рисков сопротивления персонала и более комфортного перехода пользователей на новую систему руководство может инициировать создание эффективной программы переподготовки пользователей. Для этого необходимо обеспечить административную поддержку перехода на новые технологии, разработать программу мотивации наиболее инициативных пользователей системы, обеспечивать сотрудников полной информацией о целях использования системы, ее преимуществах. Обеспечение поддержки предлагаемых изменений руководством выполняется посредством разработки схемы коммуникаций в проекте, в некоторых случаях используется внутренний и внешний PR проекта.
Для успешного функционирования новой информационной системы крайне важны обеспечение информацией и обучение персонала. Это позволит полностью или частично устранить риски мотивации персонала. Участники проекта должны информировать руководство о ходе выполнения планов, команда управления проектом должна информировать весь персонал о ходе проекта. Переход на новую систему не возможен без внутренней коммуникации о преимуществах и возможностях нового решения для целей и задач каждой из групп пользователей и разработки и предоставления пользователям детальных руководств по использованию системы.
Также руководство должно открыто выявлять и разрешать конфликты, связанные с использованием системы, признавать, поддерживать, вознаграждать усилия по работе с новой системой. Команда управления проектом и команда по управлению персоналом должны разработать и внедрить систему стимулов за использование новой системы.
Чтобы сделать процесс перехода управляемым, желательно с начального этапа внедрения системы активно вовлекать в процесс будущих пользователей. Это позволит уменьшить риски несогласованности проектных целей и риски создания системы, не соответствующей требованиям пользователей. Определение общей перспективы достигается за счет концептуального планирования проекта на уровне команды управления проектом, в состав которой входят руководители функциональных подразделений. Возможна передача полномочий по детальному планированию на уровень руководителей команд, менеджеров проектов на предприятиях.
Риски, связанные с неоптимальной организационной структурой и совмещением основных обязанностей с проектной деятельностью, достаточно сложно устранить. Сложность вызвана тем, что руководители функциональных подразделений и менеджеры проекта редко согласовывают требования к сотрудникам и срокам исполнения работ. Оказавшись в такой ситуации, сотрудник не в состоянии самостоятельно расставить приоритеты, поскольку не понимает, что является важнее в настоящий момент. Снижение рисков может быть достигнуто путем проведения регулярных встреч всех функциональных руководителей и менеджера проекта либо перехода на проектную/матричную организацию работ.
В применении к ИТ-проекту проектная структура означает привлечение внешних ИТ-специалистов для решения определенных задач развития, выбора и внедрения информационных систем. После завершения проекта эти специалисты покидают компанию или принимают участие в новых проектах. Альтернативой проектного подхода является матричная схема организации, которая предполагает наличие функциональных подразделений, из сотрудников которых периодически формируются проектные команды с возможным привлечением внешних специалистов. Такая организация является эффективным способом использования всех имеющихся компетенций сотрудников для достижения поставленных задач развития ИТ-инфраструктуры при наличии четкой регламентации взаимодействий между участниками проектной команды и линейными сотрудниками для избежания конфликтов. Также необходимым условием успешного использования матричной структуры являются высокая квалификация менеджеров проектов и эффективные схемы мотивации сотрудников к выполнению проектов в области ИТ. Формируя команду, руководитель проекта должен знать и использовать особенности различных организационных структур.
7.2. Как подобрать компетентную команду ИТ-проекта
Информационные системы часто охватывают практически всю деятельность предприятия, поэтому при внедрении ERP-системы большое значение приобретают задачи коммуникаций и совместной работы представителей различных и часто конкурирующих подразделений предприятия. Грамотно подобранная команда обеспечит большую часть успеха проекта.
Команда проекта – это общность людей, которые регулярно взаимодействуют друг с другом для достижения определенной цели проекта, считают себя целым, отличным от других групп и отдельных работников.
Одна из распространенных ошибок заключается в том, что команда проекта рассматривается как набор отдельных специалистов, на которых лежит основная часть работ по проекту, в первую очередь это разработчики и консультанты. Узкое понимание команды проекта ведет к проблемам коммуникации и ставит под угрозу процесс принятия и исполнения согласованных решений.
Подбор команды проекта предполагает, что для работы назначаются требуемые люди или группы. Поскольку лучшие ресурсы, как правило, уже заняты, необходимо добиться того, чтобы выбрать из доступных ресурсов наиболее подходящие. Исходными данными для подбора персонала является описание возможностей специалистов, включающее предыдущий опыт работы, личные интересы, личностные характеристики, доступность в требуемое проектом время.
Как правило, внедрение системы осуществляет команда, в которую входят управляющий (координационный комитет), руководитель группы внедрения или менеджер проекта и команда внедрения. Координационный комитет согласовывает свои действия с заказчиком и спонсором проекта, а также заинтересованными лицами.
Одна из важнейших стратегических целей управления проектом внедрения состоит в том, чтобы усилия всех активных участников проекта были направлены на достижение единой цели и при этом удовлетворялись интересы участников и заинтересованных лиц. Если собственные интересы отдельных участников превалируют над целями проекта, такая ситуация может вылиться в череду конфликтов и привести к неэффективным проектным решениям.
Для правильного определения целей участников проекта и заинтересованных сторон желательно ответить на следующие вопросы:
• Кто является участником проекта?
• Имеет ли каждый участник проекта ясное представление о масштабах и целях проекта?
• Существует ли четкое распределение ответственности между участниками проекта?
• Кто в проекте является заинтересованными лицами?
• Каковы скрытые цели заинтересованных лиц?
• Как участники проекта могут способствовать достижению этих целей?
Активное вовлечение всех заинтересованных представителей заказчика в команду проекта значительно повышает шансы его успешного завершения. В качестве заинтересованных лиц может выступать заказчик, в интересах которого осуществляется проект внедрения и для которого необходимо определять критерии успешного завершения ИТ-проекта. Если заказчик самостоятельно не финансирует ИТ, желательно обратить внимание на интересы спонсора проекта, как правило, это общее состояние проекта и выполнение критериев эффективности. Спонсор проекта имеет наибольшее влияние на принятие важных стратегических решений по проекту наряду с заказчиком.
Основные люди, заинтересованные в успехе проекта и имеющие значительное влияние в компании, входят в управляющий комитет по проекту. Управляющий комитет обеспечивает поддержку проекта и является внешней контролирующей инстанцией. Управляющий комитет должен собираться минимум раз в месяц для обсуждения хода проекта, будущих этапов и результатов выполненных работ. Отсутствие или нерегулярные совещания управляющего комитета могут привести к значительным рискам и непредвиденным изменениям в конце проекта.
Ответственность за успешное выполнение ИТ-проекта лежит на руководителе/менеджере проекта. Уровень ответственности должен сопровождаться соответствующими полномочиями и возможностью самостоятельно принимать решения в рамках проекта внедрения. Руководитель проекта может быть представителем одного из подразделений предприятия, однако в зависимости от того, насколько руководитель проекта вовлечен в процесс, зависит успех внедрения ИТ. Совмещение этой деятельности с выполнением других обязанностей в значительной степени повышает риск неудачи проекта.
Руководитель проекта должен обеспечить четкое видение проекта у команды внедрения, контролировать ход работ и вести диалог с членами группы в областях их ответственности, координировать разрешение внутренних и внешних конфликтов, обеспечивать взаимодействие между группой внедрения и остальными подразделениями, владеть методологической базой и лидерскими качествами. Некомпетентность или ограниченное участие менеджера проекта ведет к серьезным рискам успешного завершения работ по проекту и принятия результатов заказчиком.
Руководитель проекта отвечает за подбор команды внедрения, которой предстоит выполнить все работы по проекту. В ее задачи входят обследование предприятия, проектирование и оптимизация бизнес-процессов с помощью внедряемой системы, разработка и тестирование отдельных модулей, внедрение и интеграция в общую ИТ-инфраструктуру. Команда внедрения проекта может состоять из представителей заказчика и сторонних консультантов, представителей подрядчика. В ее состав могут входить аналитики, проектировщики, разработчики (программисты), тестировщики, отладчики, технические писатели, риск-менеджеры, руководители функциональных подразделений, ключевые пользователи, эксперты и другие специалисты. Экспертами являются опытные руководители и ключевые сотрудники заказчика, знающие бизнес компании и готовые передавать знания и опыт другим членам команды проекта. Эксперты часто способны заранее предвидеть последствия тех или иных решений, поэтому нужно стремиться к ситуации, когда для принимаемых решений, особенно на стадии концептуального дизайна системы, этими людьми производится формальная или неформальная экспертная оценка.
Для крупных ИТ-проектов может быть полезно участие аудитора, который позволяет выполнить независимую оценку реального состояния управления проектом, оценить адекватность затрат и соблюдение формальной методологии ведения проекта.
В проектах внедрения велика доля подрядчика или поставщика ИТ-услуг, что обусловлено сложностью и масштабами проектов внедрения. Интересы субподрядчиков в таких случаях не распространяются на успешность проекта в целом. Поэтому руководитель и команда управления проектом должны уделять особое внимание качеству поставляемых товаров и услуг.
В программной инженерии многие руководители отдают предпочтение самоуправляемым и самоорганизующимся рабочим командам. Эффективность команд в новых экономических условиях одними из первых оценили такие гиганты, как Procter & Gamble и Boeing. Принципы командного менеджмента предполагают ясность общих ценностей и целей, самоорганизацию и самоуправление совместной деятельностью, взаимный контроль, взаимопомощь и взаимозаменяемость, коллективную ответственность за результаты труда, всемерное развитие и использование индивидуального и группового потенциалов.
Компания Microsoft выделяет следующие основные принципы построения команды.
1. Команда равных с четкой ответственностью за область деятельности, общей ответственностью за результат и с открытым информационным обменом. Каждая роль отвечает за конкретную цель качества в общем решении.
2. Представление интересов всех участвующих сторон, которые необходимы для успешной разработки ПО. Представление всех аспектов для управления и балансировки проекта в целях предотвращения неполноты, ошибок и однобоких решений.
3. Адаптация для соответствия характеру/масштабу проекта. Масштабируемость команд от небольших групп до сложных оргструктур.
Преимущества модели команды MSF заключаются в высокой производительности, поскольку непроизводительные трудозатраты на поддержание формальных и субординационных связей сведены к минимуму. Также характерна сравнительно легкая масштабируемость, где каждый элемент в схеме команды может быть, в свою очередь, циклом. К преимуществам еще можно отнести сильную положительную мотивацию труда и равно высокую заинтересованность всех участников в конечном успехе. К недостаткам можно отнести тот факт, что для формирования команды MSF нужны равно квалифицированные и равно заинтересованные участники. Критическое значение имеют коммуникабельность, умение и готовность работать в коллективе, поскольку демократичная модель команды MSF плохо сопрягается с жесткой иерархической моделью подразделения.
Для эффективной организации работ по проекту необходимо точно определить, кто за что отвечает и кто что делает. Для этого используется матрица распределения ответственности, строкам которой назначены все работы проекта (взятые, например, из структуры декомпозиции работ), а столбцам – все роли, используемые в проекте. Если в проекте есть несколько сотрудников, играющих одну и ту же роль, то заводится несколько столбцов. Другими словами, в матрице распределения ответственности столько строк, сколько всего работ в проекте, и столько столбцов, сколько всего исполнителей в проекте. Если какой-то сотрудник, играющий определенную роль, назначен ответственным за выполнение определенной работы, то на пересечении соответствующих строки и столбца делается отметка.
Матрица распределения ответственности является удобным инструментом управления. Она позволяет быстро и в наглядной форме ответить на важные для менеджера вопросы, такие, например, как: кто отвечает за данную работу, есть ли работы, за которые никто не отвечает или за которые отвечают несколько исполнителей.
Помимо матрицы ответственности, существует матрица совмещения ролей, позволяющая отследить нарушения в совмещении ролей одним и тем же сотрудником. Так, например, руководитель проекта может принимать участие в тестировании или анализе бизнеса, но при этом крайне не рекомендуется его участие в разработке информационной системы (рис. 24).
Рис. 24. Матрица совмещения ролей для ИТ-проекта согласно PMbOK
Из профессиональных программистов получаются отличные тестировщики. Однако наихудшим сочетанием ролей считается «разработчик-тестировщик», поскольку разработчик проводит тестирование по остаточному принципу и не может найти неожиданные ошибки. Хороший разработчик убежден, что он пишет программы правильно, и ему психологически тяжело допустить, что где-то в его коде может быть ошибка. Поэтому подобное совмещение ролей приводит к низкому качеству тестирования, способствует появлению рисков и большого количества ошибок при интеграционном тестировании. Повышается вероятность пропуска или ненахождения критических дефектов, тестирование не является процессом с заданными входными и выходными данными и критериями завершения.
Определить, насколько качественно подобрана команда проекта внедрения, помогут показатели эффективной деятельности команды, а именно:
• ясное понимание цели проекта и нацеленность на конечный результат всеми участниками проекта;
• четкое распределение функций и ответственности в команде;
• наличие плана развития команды;
• командная солидарность;
• взаимопонимание и бесконфликтность;
• посещаемость рабочих совещаний и активное участие в решении проблем.
Проекты, связанные с внедрением и тиражированием информационных систем, расширением ИТ-инфраструктуры, внедрением новых ИТ-решений, их тиражированием на региональные подразделения и прочие проекты, отличаются сложностью реализации и требуют увеличения ресурсов. Найти квалифицированных ИТ-специалистов бывает непросто и дорого, поэтому достаточно распространена модель аутсорсинга персонала (аутстаффинг), которая предполагает привлечение квалифицированных сотрудников без юридического оформления через специализированные агентства.
Набор персонала и формирование команды под ИТ-проект – частая ситуация в российском бизнесе. При развитии нового направления можно перераспределить существующие обязанности сотрудников, как менеджеров, так и рядовых исполнителей. Поэтому аутсорсинг специалистов, которые будут развивать проект до достижения определенных результатов, а потом передадут все проектные работы и материалы сформированной команде, – разумная альтернатива для быстрого старта проекта.
Подобный подход снижает риски, возникающие при назначении на роль менеджера проекта сотрудника компании, поскольку привлекаемые специалисты обладают необходимыми знаниями и опытом и имеют несколько успешно реализованных проектов по аналогичному направлению.
Таким образом, разумное использование аутсорсинга персонала в ИТ-проектах может привести к следующим долгосрочным эффектам для бизнеса:
• открытие новых проектов в кратчайшие сроки;
• контроль затрат на персонал и создаваемой добавочной стоимости;
• увеличение эффективности работы компании;
• сокращение затрат на фонд оплаты труда;
• сосредоточенность на основном бизнесе компании;
• снижение рисков.
7.3. Характеристики риск-менеджера
Как уже было описано выше, особенность проектов автоматизации – это наличие подрядчика по внедрению. Действия двух организаций на одном проекте всегда являются источником риска, которым следует грамотно управлять.
При выборе риск-менеджера всегда встает вопрос: внешнего или внутреннего риск-менеджера лучше привлечь? С одной стороны, выбрав риск-менеджера из специалистов функциональных подразделений либо ИТ-службы, можно надеяться на большую лояльность и качество оценки рисков. Но это не всегда так, поскольку риск-менеджер должен обладать существенным опытом и специфичными знаниями, а также методологической базой для качественного управления рисками.
Внешний риск-менеджер может не обладать всеми знаниями специфики отрасли или внутреннего бизнеса компании, однако его преимущества по сравнению с внутренним сотрудником очевидны. Во-первых, внешний риск-менеджер не связан обязательствами с подрядчиком, поскольку не является заказчиком услуг. Он более независим, чем внутренний сотрудник заказчика, и проще работает с «непопулярными» решениями. К тому же риск-менеджер не осуществляет текущего управления проектной командой, поэтому озабочен будущими вопросами, работает «на перспективу», обладает большим специализированным опытом, чем представитель заказчика. Конечно, смысл привлекать внешнего риск-менеджера, который будет заниматься только управлением рисками (без совмещения функций), имеет только при крупном проекте внедрения.
В зависимости от размера организации и объема работы, связанной с оценкой всевозможных рисков, функции риск-менеджера могут быть возложены на одного специалиста или на отдельное подразделение. В случаях, когда, например, в компании одновременно ведутся несколько проектов внедрения, создается специализированное подразделение управления рисками. Оно обеспечивает централизацию и координацию управления рисками, внедрение интегрированного подхода к процессу управления рисками, улучшение информированности руководства о рисках в области ИТ. При небольшом проекте можно совмещать функции управления рисками с разработкой и ведением отчетности, функциями проектного офиса и другими областями. При этом требования к идентификации, оценке и мониторингу рисков остаются в рамках компетенции сотрудника, отвечающего за управление рисками.
Многие полагают, что вопрос управления рисками, связанными с функционированием ИТ-инфраструктуры, приложений, находится в зоне ответственности ИТ-подразделения, но это не верно. Обязанности управления рисками не входят в прямые компетенции ИТ-подразделения.
Конечно, сбои в ИТ-инфраструктуре нарушают непрерывность бизнес-процессов и влекут за собой финансовые потери. Но величина этих потерь несоизмерима с уровнем финансовой ответственности специалистов ИТ-служб.
Для управления ИТ-рисками необходимо владеть знаниями и методологией, в то время как ИТ-специалисты имеют техническое образование и не обладают соответствующими компетенциями и знаниями для организации процесса управления рисками.
Сотрудники и руководители служб и подразделений ИТ на предприятии должны быть профессионалами в области информационных технологий и иметь знания информационных технологий и перспектив их развития, базовые навыки в управлении проектами, понимание места и роли ИТ на предприятии, передовых принципов организации и управления ИТ. Это люди, обладающие знаниями и квалификацией, необходимыми для управления проектами и операциями в области ИТ, но не владеющие специальными навыками в области управления рисками.
Рассмотрим более подробно функции и обязанности риск-менеджера. В первую очередь риск-менеджер выполняет экономическую оценку рисков, возникающих во время проекта, занимается снижением рисков, используя современные финансовые методики и инструменты, информирует руководство о наличии непокрытых рисков, а также их стоимости. Немаловажной функцией менеджера, занимающегося расчетами рисков, является проверка наличия и выполнения процедур управления – уменьшения, избежания, переноса рисков. Кроме того, профессиональный риск-менеджер учитывает особенности психологической реакции на риск.
В задачи риск-менеджера входит постоянное наблюдение за организацией работы ИТ-проекта. Риск-менеджер идентифицирует рабочие процессы, устанавливает последовательность и взаимодействие, определяет критерии оценки и методы контроля деятельности, анализирует ход работ и проектные документы в целях идентификации рисков.
Основные функции управления рисками риск-менеджера (подразделения УР):
• разработка политики по управлению рисками;
• разработка, тестирование методов и моделей оценки рисков;
• разработка и/или выбор методологии;
• координация процесса управления рисками;
• взаимодействие с внутренними службами;
• управление портфелем рисков и оценка совокупного риска ИТ;
• создание и ведение базы данных и информационное обеспечение;
• доведение результатов оценки и управления рисками до высшего руководства компании.
Для риск-менеджера важно быть хорошим аналитиком, уметь быстро и правильно разобраться в ситуации, доверять своей интуиции и брать на себя ответственность за предложенное решение или действие.
Наличие риск-менеджера не исключает участия всех участников проекта в управлении рисками. Фактически каждый участник ИТ-проекта управляет рисками, связанными с ИТ. Риск-менеджер координирует и объединяет их усилия.
Так, руководство (управляющий комитет) обеспечивает создание контрольной среды и регулярную проверку статуса работ, осуществляет постановку целей, задание контрольных параметров, выполняет контроль наиболее важных рисков и общий контроль за эффективностью системы управления рисками. Усилия функциональных подразделений в процессе риск-менеджмента направлены на управление бизнес-рисками в своей области и следование общей методологии. Основные компетенции участников ИТ-проекта в области управления рисками – это реализация поставленных руководством целей, поддержание рисков в заданных рамках, участие в организации системы управления рисками, обеспечение руководства и заинтересованных лиц информацией по проекту. Внутренний аудитор выполняет оценку эффективности системы и формирует важные рекомендации по усовершенствованию системы.
На специалиста в области управления рисками возлагается ответственность за каждодневную реализацию программы управления рисками и повышение уровня осознания важности вопросов риск-менеджмента внутри проекта. Он должен осуществлять не только ежедневный мониторинг состояния дел, но и обмениваться опытом и суждением с другими структурными подразделениями.
Наиболее важными квалификационными составляющими для занятия должности риск-менеджера в ИТ-проекте являются такие качества, как способность управлять большим объемом информации, умение формализовать и структурировать данные, знание финансовых инструментов, математики и статистики, образование в области риск-менеджмента, аналитические способности, знание предметной области и связанных с ИТ рисков. К ключевым личным характеристикам можно отнести коммуникабельность, инициативность, уверенность в себе, умение убеждать, ясно выражать свои мысли, активность, энергичность, умение общаться, вести посредничество, объединять усилия, широкий кругозор, способность к обобщению, способность выявлять проблемы и принимать решения.
При выборе риск-менеджера нужно понимать, что управление рисками в ИТ несильно отличается от управления рисками в любой другой отрасли, поскольку законы менеджмента универсальны. Однако управление рисками в ИТ требует некоторых специфичных для ИТ знаний, навыков и опыта, без которых эффективное руководство и управление рисками невозможно, даже при наличии грамотного менеджера проекта, отлично владеющего ИТ-областью.
Если компания сделала свой выбор в пользу внутреннего риск-менеджера, можно посоветовать ориентироваться на международные стандарты и сборники методик в области управления рисками, на международные сертификационные программы, использовать их с учетом потребностей и возможностей.