Пять проверенных способов провалить проект. От древнего Египта до наших дней

Докладчик: Роман Журавлёв, компания Cleverics

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

Ручное управление

Первый способ провалить проект — просто начать работать в режиме ручного управления: чтобы не с чем было сверяться, чтобы не от чего было отступать. В какой‑то момент планы, разработанные другими людьми, не вызывают доверия, и у участников проекта возникает соблазн создать собственные планы, собственные правила игры. Эта деятельность практически никогда не доводится до конца. Механика понятна: камни добываются, камни перевозятся, из камней строятся пирамиды — и именно этим сегодня мы и будем заниматься.

Зачем планировать? При подходе «важен результат» работу так или иначе примут, даже если вокруг условной «пирамиды» окажется еще три горы добытых, но не использованных материалов или, наоборот, на ее вершине не хватит последнего, завершающего камушка. В основном же все построено, бюджет освоен.

Если же мы пытаемся следовать планам, но возникает необходимость от них отступить, то, как правило, вернуться к исходному плану не удается уже никогда. Более того: способа контролировать отклонения от изначальной задумки просто нет. Но если в игре все происходит в рамках одного игрового стола и «менеджер» может видеть всю картину, в реальной жизни это намного сложнее. К сожалению, проектная практика в самых разных областях, в самых разных компаниях, от компании масштаба «Сбербанка» до малого предприятия из трех человек, показывает, что одни и те же закономерности реализуются и в реальной проектной практике, и в игре по коллективному созданию пирамиды из конструктора «Lego». Не любим мы планировать — все равно все изменится. Вот основной постулат, из которого проистекает соблазн перейти к ручному управлению и жить «одним днем».

Отсутствие эскалации

Вторая полезная для провала проекта практика — отсутствие эскалации. В тех планах, которые мы договорились игнорировать, как правило, устанавливается не просто некая реперная точка, в которую надо прийти, но и допуски по запланированным времени, качеству, охвату. Предполагается, что можно закончить на 2 дня позже или на один день раньше. Можно потратить на 300 рублей больше или на 100 рублей меньше. Можно соответствовать критериям качества продукта на 99 %, а не на 100.

В методиках управления проектами предполашается, что если на своем уровне управления мы видим, что в следующем шаге выйдем за пределы этих допусков, то мы должны эскалировать данную ситуацию на следующий уровень управления, и там наверху примут решение. Кто так делает в реальной жизни? Действительно ли сотрудники, ответственные за контроль этих допусков, вовремя сообщают о рисках выхода за их рамки? И не по факту выхода или через 2 недели после («ой, мы вышли и, кажется, не смогли поправиться»), а о том, что возрастает вероятность такого выхода, что есть риск по срокам, по бюджету, по качеству? К сожалению, такой подход встречается крайне редко.

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

Управление рисками

Этой практикой в жизни, как правило, пренебрегают. До того, как люди начинают «строить пирамиду», они проводят анализ рисков, выбирают контрмеры, которыми будут эти риски преодолевать. И, как правило, эти контрмеры в итоге не используются. Если сравнивать с работой пожарной инспекции — по всем необходимым местам развешаны огнетушители, пожарный инспектор удовлетворен проверкой, но мы надеемся, что эти огнетушители никогда не придется снимать со стен. Огнетушители висят? Висят. Какие‑то контрольные мероприятия проведены? Проведены. Когда случается пожар, и мы эти огнетушители применяем — выясняется, что они просрочены, что никто не знает, как ими пользоваться, что они прикручены к стене большими болтами и поэтому не отрываются, и к тому же не предназначены для тушения тех пожаров, которые происходят.

В операционной деятельности такие вещи более или менее вылечиваются после первых пожаров. В проектной деятельности всегда остается надежда, что за время проекта предусмотренных рисков не случится. Систематической деятельности по обновлению реестра рисков или хотя бы по применению уже признанных корректными и нужными контрмер в проекте, как правило, не происходит. На вопрос: «А кто у вас отвечает за управление рисками?» или «А кто у вас должен такое‑то событие отработать с помощью этих контрмер?», не будет ответа. Часто, если кому‑то рядом повезло пробегать во время, когда совпало событие и контрмера, которая для него предусмотрена — окей, хорошо, не повезло пробегать — ну, ничего, понесем соответствующие потери.

Контроль качества

В каждой команде