Типовой риск в консалтинговых проектах по ИБ, и как с ним бороться

Сергей Сугоняев, эксперт AKTIV.CОNSULTING, рассмотрел один из рисков в проектах по информационной безопасности — неготовность к изменениям в устоявшихся процессах со стороны команды заказчика.

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

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

Для консультанта это выглядит следующим образом. Представители заказчика:

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

Как бороться с данным риском:

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

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