Кто не рискует, тот не катается в акье*.
Народная мудрость альпинистского лагеря «Безенги
(*Акья - спасательные сани, предназначенные для транспортировки пострадавших и погибших в условиях пересеченной местности)
Энное время назад, когда я внедряла проектное управление в конторе, работавшей с гос.заказом, к нам очень усиленно докапывались наши заказчики, выясняя, а как у нас выстроено управление рисками??? Настойчивость их (как я понимаю, проявлявшаяся по отношению ко всем их подрядчикам), очень соблазняла ответить какими-то отписками, но я воспользовалась этими вопросами как поводом для того, чтобы собрать совещание с руководством и еще раз объяснить важность управления рисками в целом. Поскольку в теории все говорят про риски, а на практике чего с ними делать - понимают не очень. А ведь, как это ни банально звучит, но в литературе по управлению проектами совершенно правильно указано, что эффективность проектного управления повышается, когда мы планируя какие-то общие вещи (расписание, бюджет, загрузку сотрудников и т. п.) принимаем во внимание результаты процессов управления рисками. Чем мои разговоры с руководством о внедрении риск-менеджмента кончились на практике? Увы, открывая этим тему про косяки и ошибки, которую я обещала поднять в предыдущей статье, не могу похвастаться головокружительными успехами в этой сфере. Руководство пожало плечами и ответило, что не видит смысла выявлять риски и учитывать их в планах, если действительность такова, что принятые и утвержденные на высшем уровне планы очевидно невыполнимы уже в момент их принятия и утверждения, и заявлять об этом категорически бессмысленно - ибо отказаться от проекта невозможно по политическим мотивам, и привести планы в соответствие с реальностью - тоже. Давно известен ответ на вопрос, что получится, если изо всех сил пнуть слона?... Получишь исключительно синяк на ноге. Примерно такой же эффект будет, если пытаться с налету развернуть бюрократизированную систему. Так что в той организации мы, сочинив бравый ответ заказчику, увы, продолжили управлять рисками по принципу "пока гром не грянет, мужик не перекрестится", то есть реализую подход, противоположный управлению рисками - стресс-менеджмент. В чем между ними разница? Стресс-менеджмент - когда мы решаем проблемы по мере возникновения. Управление рисками - когда мы задумываемся о возможных проблемах ДО того, как они возникли, и предпринимаем меры, уменьшающие вероятность и/или последствия, если эти проблемы все-таки возникнут. Подход, честно скажем, не всегда привычный, но чаще всего окупающий себя при здравом применении.
Впрочем, вода камень точит, и давайте мы с вами не будем чересчур категоричны. Управление рисками, осуществляемое здраво, разумно, уместно и не для галочки, полезно для любого проекта.
Какие базовые рекомендации по управлению рисками я могу здесь дать?
Совет №1. Избегайте ситуаций, когда отказаться нельзя
Ты сильный, ты справишься! – Нет, я умный, я даже не возьмусь!..
Я вообще всегда настороженно воспринимаю ситуации, когда РП мне с полной уверенностью заявляет что «отмена проекта в принципе невозможна – проект должен быть реализован во что бы то ни стало!». Мы такую ситуацию разбирали на вебинаре, посвященному управлению рисками на примере провала проекта автоматизации 5-ого терминала аэропорта Хитроу. Там как раз явно была ситуация из серии «не все тесты пройдены, в работе не всех систем мы уверены – но на торжественное открытие приглашена сама королева, перенос сроков внедрения категорически невозможен»… В результате - сбой пропускной системы и системы автоматической сортировки багажа - отмены множества рейсов, тысячи единиц потерянного багажа... Если вспоминать более безобидные истории – то мне в моей практике возникали ситуации, когда принималось решение по переходу на новую систему до конца года «любой ценой» - что на практике выливалось в то, что на систему, конечно, переходили, но бухгалтерия со страшным воем отчетность еще целый квартал чуть ли не на счетах сводила, потому что все работало ужасно криво… Но избежать такой ситуации, отложив переход в условиях "всё не готово" было по каким-либо причинам невозможно.
Еще один источник, который говорит про похожие вещи – это, как это ни странно звучит, Кодекс строителей коммунизма, ой, то есть, прошу прощения Кодекс этики института проектного управления PMI. Здесь прежде чем я перейду к делу, будет небольшое лирическое отступление. Я регулярно готовлю руководителей проектов к сертификации Project Management Professional - она является довольно широко признанной в России – скажем, даже 1С позволяют использовать ее для сертификации 1С:Руководитель проекта не сдавая их собственный экзамен по управлению проектами. (Кстати, спойлер - осенью буду такой онлайн-курс проводить на Инфостарте, присоединяйтесь, кому актуально!). Если вы задумали подавать документы на эту сертификацию, вам, в частности, предлагается знать и применять тот самый вышеупомянутый Кодекс этики руководителя проектов. Надо сказать, что кодекс американский, и наряду с здравыми и не вызывающими вопросов тезисами, там есть немало мыслей, вызывающих оторопь у российских менеджеров. Ну, например, как вы думаете, должен поступить уважающий себя РП, если он узнает, что его коллега, имеющий статус PMP, дает взятки, и не внимает вашим увещеванием, что это не хорошо? Вы думаете, правильный ответ – его пожурить, и объяснить, что он не прав? Вовсе нет, выше же уже указано, что это не помогает – правильный ответ – вы обязаны сообщить об этом в институт PMI, чтобы его с позором изгнали из рядов Профессионалов в проектном управлении и лишили статуса PMP! Не буду никак обсуждать эти мысли в кодексе, оставлю их на совести авторов и исполнители, а упомянуть хочу другой пункт. Где говорится про то, что я, как профессионал, не возьмусь за работу, для которой у меня недостаточно компетенций, а честно предупрежу об этом заказчика и работодателя. Этот пункт тоже зачастую вызывает удивление. Вот, представьте себе, хотят нанять вашу фирму на проект внедрения – и какой дурак на этом месте будет говорить «ой, мы, честно говоря, пока таких проектов никогда не делали, поэтому не уверены, что мы возьмемся»… Конечно же, все скажут «Да не вопрос, значит, экзамен по-китайскому уже сегодня? Методичка есть – пошли сдавать (С)».
Так вот, коллеги, я здесь понимаю обе позиции. Я понимаю тех, кто берется за все задачи, которые на него сваливают заказчики или руководство – потому что не хочется отказываться от вкусного заказа или страшно разочаровывать начальство. Но с большим уважением, и с большим доверием, как заказчик, я отношусь все-таки к тем, кто честно берется за те проекты, которые готов сделать – и отказывается от остальных. То есть выбирая между подрядчиками, которые «готовы на всё» и теми, кто честно говорит «это мы сделаем, а вот это – нет», я стараюсь выбирать последних. Потому что выше шансы, что то, за что они возьмутся – они правда умеют и сделают на совесть.
Если смотреть на ситуацию глазами подрядчика – то да, честно скажем, что решение отказаться от того, в чем сильно не уверен (или хотя бы признаться честно с оговоркой, что проектов таких масштабов пока не делали, но готовы рискнуть, если заказчик не против) – не всегда самое выгодное. И это логично, потому что этичное решение – не всегда самое выгодное, на то оно и этичное. Но на длительной дистанции, для длительного сотрудничества такое решение – правильное.
Совет №2. Предсказывайте риски до того, как пациент умрет, а не после
Есть такая штука, называется туннельное зрение. Применительно к проектному управлению – это когда зрение работает в формате «вижу цель, не замечаю препятствий». Особенно такое виденье свойственно собственникам бизнеса – так как для успеха в любом бизнесе нужен изрядный градус упорства, органичным дополнением к нему оказывается и некоторый градус упрямства (кстати, а где проходит граница между упорством и упрямством? Я бы определила так: упорство – когда ты настаиваешь на своем в ситуации, когда это осмысленно, а упрямство – это когда ты продолжаешь и после того, как в этом уже нет никакого смысла. В теории всё просто и логично, а на практике границу часто расставляют пост-фактум под лозунгом «победителей не судят»). В результате вера в светлое будущее заставляет не видеть совершенно очевидных (разумеется, задним числом) возможных проблем, которые позволят всему проекту накрыться медным тазом. Как можно с этим бороться? Для этого придумана совершенно шикарная техника PreMortem, что можно перевести с латыни как «До того, как умрет». Эту технику рекомендуют применять в противовес применяемой нами чаще всего на практике технике PostMortem, то есть «После того, как умрет». Да-да, и вы тоже, наверняка применяете технику PostMortem, даже если об этом и не подозреваете.
Как она выглядит? Вот у нас идет проект. Сначала с ним всё хорошо и радостно, он плавно движется обещая нам успех, счастливых пользователей и хорошие премиальные. Но в какой-то момент что-то идет не так, и весь проект катится в тартарары. Бюджет кончается на середине внедрения, пользователи саботируют новую систему, выбранное прикладное решение категорически не решает поставленные бизнесом проблемы… Список можно продолжать бесконечно. Итог, увы, печален – мы вынуждены констатировать, что проект с треском провалился. Можем ли мы объяснить, почему это произошло? Скорее всего, да. Потому что задним числом нам наглядно видны те проблемы и сложности, которые мы краем сознания замечали, но закрывали на них глаза благодаря тому самому туннельному зрению, чтобы скорее двигаться к успеху – отсутствие поддержки высшего руководства, плохо организованный сбор требований, незаинтересованная в переходе бухгалтерия, отсутствие изначального понимание целей автоматизации и т.д. и т. п. – на самом деле, универсальные причины встречаются нечасто, чаще всего каждая ситуация индивидуальна. После того, как мы проанализируем ошибки провального проекта внедрения, мы возьмемся за следующий. Будет ли он успешным? Неизвестно. Но шансы на успех, с учетом горького прошлого опыта – уже будут заметно выше.
Так вот, техника PreMortem – это как раз попытка избежать вот этого этого «первого провала», а переход сразу к фазе «следующего проекта». (Одна моя знакомая многодетная мать любит говорить, что рожать лучше сразу пятого ребенка – вот я примерно об этом же говорю). Каким образом это работает?
Представьте себе, что сегодня – 18 июня 2021 года. (см. дату написания статьи). И вы знаете, что тот проект, который вы в реальной жизни начинаете вот прямо сейчас и полны энтузиазма и радужных ожиданий в его адрес – увы и ах, с треском провалился. Представьте себе в красках эту ситуацию (нет, заявление об уходе писать не надо, и петлю намыливать тоже – не настолько в красках). Как вы думаете, почему это могло произойти?
Попытка осознанно выйти из вот этого состояния «вижу цель, не замечаю препятствий» (которое, на самом деле, полезно для движения к цели – потому что помогает нам к нему двигаться) может позволить увидеть те самые проблемы, на которые мы в обычном состоянии закрываем глаза. И подумать, что же мы с этой ситуацией можем сделать?..
Совет №3. За одного битого двух небитых дают
Только дураки совершают одни и те же ошибки. А умные люди каждый раз придумывают новые!
Проблемы прошлых проектов – это входные данные в процессы управления рисками проектов будущих. Фиксируйте извлеченные уроки, привлекайте сторонних экспертов, в том числе экспертов по управлению (чтобы они видели не только технические риски, но и организационные), желательно уже имеющих опыт подобных проектов.
Напоследок я скажу еще простую вещь, честно скажу, довольно-таки очевидную.
В момент, когда мы заканчиваем проект нам кажется, что мы никогда не забудем все сложности, нюансы, детали нашей работы. И теперь-то мы знаем, как в следующий раз грамотнее собирать требования, выстраивать общение с бизнес-заказчиком, делать прототипы и так далее. Но проходят недели, месяцы и годы, частично меняется команда – и мы с неудовольствием обнаруживаем, что на новом проекте вновь наступили на те же грабли, которые были нами благополучно забыты за прошедшее с прошлого проекта время… А еще обиднее смотреть на наших коллег, которые наступают на наши излюбленные грабли, потому что им не пришло в голову спросить, что у нас получилось не так. К чему я это? К тому, что надо, во-первых, фиксировать свой опыт и свои наработки. Шаблоны, опросники, просто орг.выводы и наблюдения. А во-вторых, чем более вдумчиво мы подойдем к выявлению и анализу рисков в начале проектов, тем больше шансы у нас избежать хотя бы знакомых и любимых граблей – и здесь особенно важно, кого мы привлекаем, и с кем мы консультируемся при запуске новых проектов. Потому что наивное предположение, что всё будет складываться идеальным образом (и составленные исходя из этого предположения расписание и бюджет - поделитесь, у кого в практике такое было? - в моем окружении, увы, нередко), конечно, выглядит, привлекательным, но чудеса, увы, бывают довольно редко.
Так что удачи нам в нашем непростом деле!... И поделитесь - у кого как организовано управление рисками, и насколько оно помогает избежать любимых граблей?
(Продолжение следует)
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
