Сегодня я хотел бы поделиться с уважаемыми читателями Хаброхабра своим опытом кризис-менеджмента, который произошёл совсем недавно (в самом начале 2012 года, если быть точным). Надеюсь, что описание этого опыта будет полезным всем прочитавшим, и каждый найдёт в нём что-либо полезное для себя. Ну и обсуждение в комментариях тех или иных аспектов, невыраженных умолчаний и прочего подобного всегда приветствуется — я постараюсь рассказать всё, что знаю.
На текущий момент я подвизался руководителем Проектного офиса в организации, выполняющей заказную разработку и консультационные услуги для банков и финансовых организаций. В области моей ответственности — развитие методов проектного управления в организации, оптимизация и повышение эффективности рабочих процессов, повышение уровня зрелости организации. Но иногда меня лично просят взять под своё управление какой-нибудь проект, который валится в тартарары, поскольку руководитель проекта не сдюжил. И мне приходится заниматься антикризисным управлением.
С одним из таких опытов я как раз и хочу познакомить своих читателей. Речь пойдёт о простейшем проекте тестирования третьей стороной внедряемого в одном из крупнейших международных банков модуле взимания платежей.
Исходная информация
В самом начале проекта имело место:
- Был вполне определённый объём работ, который надо было выполнить — проведение независимого тестирования продукта и сопровождение сотрудников заказчика на UAT. Имелся чёткий план работ, были расставлены ключевые точки, определены все сроки. Основная проблема здесь была в том, что этот план был составлен представителями заказчика, которые вложили в него своё видение, вернее даже желание получить готовый продукт к такой-то дате. Дата вполне понятная — 01.01.2012.
- С нашей стороны имелось два специалиста по тестированию и руководитель проекта, который должен был сопровождать проект как «надзирающий», поскольку основным руководителем проекта был менеджер со стороны ИТ-службы банка.
- Наши расчёты показывали, что если мы уложимся в сроки и трудозатраты, прописанные в имеющемся плане работ, то мы ещё и получим неплохую маржинальную прибыль.
- Со стороны банка к нам было самое доброжелательное отношение, в том числе и со стороны бизнес-заказчика, то есть бухгалтерии.
Что я получил в момент принятия на себя роли антикризисного управляющего:
- На 01.01.2012 продукт не был установлен даже на предпродукционной среде, он не был доработан до конца, планы тестирования были сорваны не менее, чем на три месяца.
- Руководитель проекта бросал на тушение пожара всё больше и больше людей, бессмысленные трудозатраты росли, к моему приходу проект еле-еле выходил на уровень себестоимости. Мой приход на проект должен был обрушить его в глубокую отрицательную зону.
- Бизнес-заказчик раздул требования по функциональности и количеству тест-кейсов, но это была вполне предугадываемая «стандартная» ситуация.
- У проектной команды сложились какие-то нерабочие взаимоотношения с руководителем проекта от ИТ-службы банка, причём наш руководитель проекта от этого аспекта полностью самоустранился. Как итог — наши сотрудники не могли работать, а если их заставляли, то начинались какие-то истерики на грани кликушества (оба специалиста по тестированию были женщинами).
- Реноме нашей компании опустилось куда-то в эпсилон-окрестность нуля с тенденцией зайти в отрицательную область, при этом на носу у нас маячили гигантские денежные проекты, а с таким реноме их было не взять (резон — «они с каким-то модулем взимания платежей разобраться не могут, как им можно доверить построение КХД»).
В этой ситуации CEO компании принимает решение срочно гасить пожар, снимает руководителя проекта и отдаёт бразды правления мне.
Первые шаги на пепелище
Это было именно пепелище. Проектная команда была полностью деморализована, оперативного проектного плана не было в принципе, никто не знал, что и как надо делать, в том числе и руководитель проекта со стороны ИТ-службы заказчика. Некоторые бегали, сломя голову, а некоторые положили на стол заявление об увольнении ПСЖ. Проект стоял. Вернее даже, тонул. Единственная приятная информация, если что-то могло вообще быть приятным в этом вопросе, заключалась в том, что этот проект имел довольно низкий приоритет у руководства банка, и за ним не следил никто, кроме непосредственных бизнес-заказчиков.
CEO ставит лишь одну цель — должно быть спасено реноме компании перед лицом заказчика. Для достижения этой цели могут быть затрачены любые средства и применены любые инструменты (всё в рамках закона, конечно). На бюджет никто не будет смотреть, проектная команда была полностью отдана в моё распоряжение. Главная цель — реноме, а для этого надо было просто взять, выровнять проект, показать бизнес-заказчику, что мы — профессионалы своего дела и можем довести начатое до конца, несмотря ни на какие трудности и проблемы.
Что делать? Как быть? Первое, что должен сделать любой руководитель, когда приходит в незнакомую область, — так это полностью погрузиться в проблему и выяснить все самые тонкие нюансы всех возможных аспектов. Договорные обязательства, рабочие процессы, межличностные отношения в расширенной проектной команде (включает в себя всех стейкхолдеров) и т. д., и т. п. Для этих целей резонно воспользоваться интеллект-картой. В первый же день я собираю максимум информации, структурирую её в виде интеллект-карты. В итоге получается мой основной рабочий инструмент на первый период. Одна из промежуточный версий этой интеллект-карты выглядела как-то так:
Прошу моих читателей простить меня — я нарочито сделал изображение за гранью читаемости, поскольку не хотел бы разглашать личную информацию людей из проектной команды, которая на этой диаграмме имеется. Здесь же важное — понять принцип.
Второй шаг — работа с проектной командой. Я сразу же принимаю решение абсолютно полностью сменить её состав, поскольку решать вопросы нерабочих межличностных отношений мне совершенно не хотелось. Вместе с тем я понимаю, что мне надо задержать во что бы то ни стало именно ту сотрудницу, которая уже положила заявление на стол, поскольку она являлась ключевым хранителем всей экспертизы. Задерживать её я собирался, само собой разумеется, для передачи знаний новым сотрудникам. Это было достигнуто путём банальных переговоров в самой что ни на есть деловой манере — никаких эмоций, никаких угроз, соплей или истерик. Всё чётко — ты остаёшься до такого-то числа, получаешь свою зарплату, передаёшь знания тому, кого я найду, и уходишь. Если я к тому времени никого не найду на замену, то это мой риск.
Условия приняты, начались поиски. Не скажу, что рынок труда просто ломился от предложений. Но тут удача мне подмигнула, и буквально в течение недели я нашёл человека, который был готов выйти в любое время, при этом обладал мощнейшим опытом тестирования именно в банковской тематике, знал всё, что нужно, умел общаться с банковскими служащими на их языке. Единственная проблема — он хотел быть руководителем. Так что ему были предложены условия примерно такие: ты выходишь и работаешь некоторое время руками, сам занимаешься приёмом экспертизы по проекту и тестированием. В это время я ищу тебе специалиста, который продолжит, а ты становишься руководителем направления тестирования в компании, если покажешь хорошие результаты на этом проекте. Ударили по рукам.
Специалиста искать было уже негде и некогда. Осталась буквально неделя до ухода ключевого человека из проектной команды. Это сподвигло меня на резкий обзвон всех своих старых контрагентов, занятых в области аутсорсинга ИТ-услуг. Первый же звонок дал прекрасный результат — на следующий день у меня был специалист по тестированию, причём по достаточно разумной ставке. Но, правда, на ценовой модели T&M, в то время как проект в банке был по ценовой модели FC, при этом, как я сказал, мы уже стояли на грани себестоимости. А, как известно, T&M всегда заборет FC при неограниченном увеличении времени. Но, поскольку по бюджету мне дали полный картбланш, я пошёл на это, закрыв глаза на финансовые показатели проекта. Ведь главным было реноме.
Итак, остаётся неделя, у меня есть два специалиста для проведения работ. Соответственно, пришло время для третьего шага. Но перед ним надо отметить, что за это время, пока я искал новых людей на проект, я, естественно, общался с представителями заказчика. Перед ними я держал марку — я позиционировал себя как жёсткого и прагматичного руководителя, который ставит задачу, организует работы и строго спрашивает с исполнителя. В таком обличье я подошёл к руководителю проекта со стороны ИТ-службы банка и предложил срочно сделать две вещи:
- Составить оперативный план работ, который состоял бы из буквально атомарных пунктов, для каждого из которых были бы указаны конкретный исполнитель и сроки. Этот план должен был распространяться на всю расширенную проектную команду — в том числе и двух исполнителей со стороны (других подрядчиков банка), а также на всех сотрудников задействованных в работе подразделений банка. Я настоял на том, что контролировать исполнение задач буду я, причём буду делать это жёстко и беспрекословно — если кто-то подписался под датой, то он должен будет выполнить работу во что бы то ни стало. Этот последний штрих вызвал некоторое негодование в среде сотрудников банка, но я был неумолим.
- Составить и утвердить у директора ИТ-департамента схему рабочего процесса по независимому тестированию, на которой показать регламентные сроки и ответственность всех сторон, задействованных в проекте. К этой схеме прилагалась бы матрица ответственности. Схема была нарисована и действительно утверждена у ДИТ (это прошло довольно легко, поскольку тот — экспат, понимающий толк в формализованных процессах). Отступлением хотя бы на шаг влево или вправо от этой схемы я пообещал считать провокацией с немедленным докладом ДИТ.
На том и порешили. Оба артефакта были составлены в кратчайшие сроки, и тут я не могу не отметить рьяность руководителя проекта со стороны ИТ-службы банка — он тоже хотел завершить проект (его реноме тоже страдало), и он увидел во мне не соперника или какого-то там диктатора, а того, кто реально может спасти проект. Мы начали работать рука об руку.
А вот и схема процесса:
Как видно — ничего особенного, никакой специальной науки, вроде теории категорий. Всё обыденно и просто. Суть в том, что такого формализма на проекте просто не было, что приводило к разброду и шатанию в расширенной проектной команде. Каждый пытался спихнуть на соседа любую работу. В итоге всё делали наши специалисты по тестированию, поскольку были самыми бесправными существами, а наш руководитель проекта давно махнул на эту ситуацию рукой. Получив этот инструмент, я и руководитель проекта со стороны ИТ-служба банка могли уже диктовать условия всем задействованным сторонам.
Итак, первоначальный пожар был более или менее потушен, обновлённая проектная команда начала свою работу. Для меня наконец, наступило время для стратегической оценки проекта. Мне надо было оценить принципиальную возможность завершения проекта в какие-либо сроки, а также хоть как-то рассчитать эти сроки. Для этих целей я взял описанную мной ранее методику управления рисками, которая была разработана у меня в Проектном офисе буквально к началу моего задействования на описываемом проекте.
Думаю, что здесь нет смысла перечислять все риски, которые были обнаружены на проекте, а также описывать процесс расчёта на основании реестра рисков вероятностей тех или иных дат. О методе расчёта каждый сможет ознакомиться здесь. А у нас в реестре значилось 14 рисков и проблем, причём уже наличествующие проблемы давали сдвиг сроков на 68 календарных дней от срока, поставленного ДИТ после начала антикризисных мер.
Получив эту диаграмму и стопроцентную вероятность завершения проекта через 77 календарных дней от поставленного срока, я собираю Управляющий комитет и жёстко ставлю на нём вопрос о предоставлении мне хлыста, которым я мог бы стегать провинившихся в срыве сроков сотрудников банка (а все риски и проблемы были связаны только с ними). Хлыста мне не дели, но ДИТ выстроил все задействованные в работе подразделения и наделил их хорошей мотивацией. Её хватило на пару месяцев, за которые мы продвинулись в работах больше, чем за всё предыдущее время.
Возвращаемся к рутине
Проект был выровнен, из глубокого пике он стал вполне обыденным, рутинным проектом. Я отдал бразды правления руководителю проекта со стороны банка, оставив за собой лишь функцию общего надзора и наделения пинками тех, кто внезапно позабыл про необходимость эффективной работы.
Принятый мной на работу специалист по тестированию в настоящее время является руководителем направления тестирования в нашей организации. Специалист-аутсорсер продолжает работы, выполнив всё необходимое, получив экспертизу, и теперь просто выполняя те тестовые сценарии, которые были ранее разработаны и, главное, утверждены у бизнес-заказчика банка. Последний тоже счастлив — перед ним обрисовалась чёткая перспектива и понимание, когда продукт будет внедрён, а также уверенность в том, что тестирование третьей стороной было проведено качественно.
Реноме компании было спасено.
Краткое заключение
Итак, кратко подвожу итоги того, что было сделано, какие шаги были предприняты для тушения пожала, в каких условиях выполнялись эти шаги. Вот сводка:
- Резкое и глубокое погружение в проблему проекта. Кризисному управляющему необходимо в кратчайшие сроки узнать все нюансы, формальные и неформальные, влияющие на все аспекты проекта. Для этих целей лучше всего, по моему опыту, пользоваться техникой интеллект-карт.
- Работа с проектной командой. Необходимо выявить слабые и сильные стороны проектной команды. От слабых избавиться без сантиментов, сильные усилить ещё больше, в том числе и жёсткими административными мерами — путём наделения чрезвычайными полномочиями.
- Создание инструментов оперативного управления проектом — оперативного плана работ с атомарными ответственностями и сроками и формализованного описания процесса. Утверждение этих инструментов на самом верхнем уровне, до которого только можно дотянуться.
- Создание инструментов стратегического управления проектом — реестра рисков и проблем, на основании которого оценивать саму возможность реализации проекта и вероятность тех или иных сроков. Использовать этот инструмент для «устрашения» лиц, принимающих решения.
- Выстраивание формальных рабочих отношений между всеми сотрудниками расширенной проектной команды.
Всё это надо делать максимально жёстко и беспрекословно. Когда проект горит и вот-вот превратится в невесомый пепел, не до слюней с эмоциями. Кто не может совладать с эмоциями — есть много другой работы на других проектах или на обеспечивающей деятельности. Только авторитарная диктатура спасёт проект от провала. Когда же проект выравнивается и выходит на рутинную деятельность, узду можно (и нужно, конечно) ослабить и дать возможность людям немного перевести дух.
Ну а если осталась возможность наградить тех, кто испытал на себе все прелести антикризисного управления, то после окончания проекта хорошо бы поощрить всех выдержавших эту гонку сотрудников проектных команд. Своим премии по итогам работы на проекте, аутсорсерам — благодарственное письмо и рекомендации руководству о поощрении, представителям заказчика — фуршет, банкет и тимбилдинг.
P. S.: Ну и, кстати, другой моей заслугой на этом проекте было проведение успешных переговоров о переводе проекта с модели FC на модель T&M. Заказчик воспринял это положительно и с пониманием.
Всех читателей благодарю за силы и время, потраченные на эту статью. Ну а за конструктивные комментарии с предложениями, замечаниями и критикой как всегда низкий поклон.
Если вам или вашей организации интересна методика антикризисного управления или управления рисками, то вы всегда можете связаться со мной на предмет проведения мастер-класса, презентации, семинара и прочих подобных мероприятий в интересах вашей компании.
Если вы хотите дополнительно отблагодарить автора, но не знаете как, то вам сюда.
Мои предыдущие статьи по теме управления проектами на Хаброхабре:
- Методика управления рисками — обобщение моего опыта работы над проектами
- Апробация методики управления рисками: пять главных национальных рисков России
- Алгоритм построения графика распределения вероятности для объектов воздействия рисков
Автор: Darkus
