Мифическое существо полезный аудит

Не так давно, на RISSPA была оживленная дискуссия на тему "бывают ли полезными аудиты ИБ?". Речь, безусловно, шла не об аудитах, а скорее независимой оценке ИБ, но речь сейчас не об юридических терминах. Назовем его аудитом или консалтингом, а вопрос остается один - есть ли польза?
В дискуссии обсуждали понятность отчетов, четкость поставленной задачи, прозрачность методологии, качество самих аудиторов. В общем, обсудили много полезных вещей, обеспечивающих "полезность" аудитов и других консалтинговых проектов. Вроде бы как все просто. Почему же тогда существование в природе  такого рода полезных проектов ставится под сомнение? По всей видимости, секрет в формулировке полезный для компании. Абстрактная сущность компания часто не может оценить полезность проектов, по той простой причине, что состоит из разных индивидуумов, у каждого из которых свое понимание полезности. Хотя нет. Стоп. Оценка - это уже в конце. А в начале - постановка задачи. Критический фактор успеха будущего проекта. Ибо, будь хоть все консультанты семи пядей во лбу, а если попросить у них не то, то и сделают они не то. В свою прошлую бытность консультантом, по результатам  переговоров с клиентом о предмете и цели услуги, в большинстве случаев складывалась вот такая картина (упрощено для улучшения восприятия, в реальности все значительно хуже):

Разберем фрагменты картинки по отдельности:

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

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

Что хочет менеджер проекта. На определённом уровне, и, как правило, обладающие печальным опытом, консультанты перестают делать предложения компаниям, руководствуясь сугубо техническим заданием. Поэтому они, прочитав ТЗ, едут встречаться с менеджером проекта для уточнения правильности своего понимания. Тут их ждет сюрприз (или не ждет, в зависимости от того, на сколько они изначально верили в правильность ТЗ). Менеджер проекта со стороны заказчика озвучивает что-то, совершенно отличающееся от того, что написано в техническом задании. И то, что в ТЗ написано другое, менеджера проекта не смущает. Он флегматично поживает плечами и рассказывает любопытным консультантам, что на самом деле нужно сделать вот это и вот это.
Обуславливается это двумя факторами. Первым фактором является то, как менеджер проекта понял, что нужно сделать в рамках проекта и какой у него есть опыт по решению подобных проблем. И, поскольку спрос в перспективе с него, он будет делать проект как понял и как считает правильным.

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

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

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

анализа исходных данных, выяснялось, что то, что запрошено компанией в ТЗ или озвучено менеджером проекта - совсем не то, что реально нужно компании. Что корень проблемы лежит в другой области. Просто никто не копал до этого корня. Описали симптомы, а причину болезни установили не правильно. В этих случаях приходилось идти на риск и предлагать компании не то, что она хотела изначально. И в результате, коммерческое предложение, не смотря на то, что содержало очень мало общего с ТЗ, выигрывало тендер. С комментариями от представителей компании: "Вы лучше всех поняли, что мы хотели".
Бывает и так, что то, что хочет компания ей попросту не нужно, поскольку в перспективе затраты превысят выгоды от проекта. Встречаемся как-то с представителем компании. Хотят в перспективе получить сертификат по ISO 27001. Спрашиваю - зачем? - Хотим, что бы была надежной информационная безопасность. Говорю - прекрасно, а сертификат вам зачем? Он вам нужен для укрепления имиджа компании? - Нет. - Контрагенты/поставщики/регуляторы требуют? - Нет. В результате короткой дискуссии выяснилось, что сертификат компании не нужен.

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