Комментарии по теме

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«Ко­мпле­ксное решение для эле­ктро­нно­го до­ку­ме­нто­о­бо­ро­та на базе SAP ERP»
Иван Савчук:
Не хватает технической части. В остальном все очень подробно.
«Упра­вле­ние сложными ли­чно­стя­ми в проектной группе»
Татьяна Шаньгина:
Управление сложными личностями в проектной группе – тема интересная, актуальная, хотя и довольно амбивалентная. Практический опыт доказывает справедливость концепции Уильяма Зиска о...

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2014-2015) Дата проведения: 9 октября 2014 г. Все мероприятия

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

Предыдущая Следующая

Для скачивания материала, необходимо войти на сайт или зарегистрироваться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задача того, кто отвечает за контроль качества — контролировать не только качество конечных продуктов, но и корректность выполняемых процедур, формирования отчетности. Он должен будет следить как раз за тем, чтобы планам следовали, а допуски контролировались, и, может быть, даже риски обрабатывались. С высокой степенью вероятности он будет следить за качеством продуктов, за бюджетом, и очень вероятно, что за соблюдением сроков. Самый популярный вопрос, который управляющий совет задает своему «оку» в проектной команде, тому, кто здесь называется «quality assurance» (контроль качества, — это «Ну, как они, успевают?» Успевают. Что — не важно.

Бюрократия, то есть отчетность

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

Можно, наверное, сказать и так: наверное, убивает. Наверное, она замедляет ход действий. Наверное, это бюрократия, в которой можно потонуть. Но вот что интересно: в той же самой игре организаторы хотели в финале вручить призы. Тоже, своего рода, мотивация — «освоить бюджет, успеть в срок», все, как у всех. Поэтому они подошли ук бизнес-тренерам, проводившим игру, и сказали: «Нам нужно в каждой команде кому‑то вручить за вклад в работу команды приз. Приз нас есть — скажите, кому вручать». Тренеры немедленно перенаправили вопрос менеджерам проектов — их было 5 человек — и сказали: «Вы в своей команде, пожалуйста, определите человека, который внес наибольший вклад в общий результат. Себя нельзя». Четверо из пяти в качестве такого человека определили того сотрудника, который занимался отчетностью, project assistant: он не «добывал камни», ничего не перевозил, не строил никакую пирамиду, а собирал со всех данные, аккумулировал их и отдавал менеджеру проекта. Четверо из пяти сказали: «Это правая рука. Без него вообще все бы развалилось». Отчасти потому, что именно с его помощью они понимали, как обстоит дело с качеством, ценой и прочими параметрами проекта — хотя большую часть времени занимались тем, что сами участвовали в процессе и видели, как он продвигается. Возможно, они чувствовали этого человека наиболее близким к себе во всей проектной команде, как часть управляющего органа.

Сегодня есть два пути. Можно следовать той форме отчетности, которая предусмотрена разработчиками проекта. Тут, действительно, есть шанс потонуть в бюрократии. Но практика показывает, что более популярен другой путь. Так как от плана все равно отказываются, качество не контролируют, время физическое не зависит от времени проектного, то, в общем, и отчетность не нужна. Если говорить об игре, то есть группы, в которых не хватает бланков отчетности и приходится их чем‑нибудь заменять к концу дня, а есть группы, в которых остается пара пачек — именно у них мы берем нужные бланки для тех, которым не хватило. В реальной жизни нужно поэкспериментировать с отчетностью и найти золотую середину.

В той самой игре, где участвовало сразу пять команд, в какой‑то момент люди из управляющего комитета решили спуститься с Олимпа к народу. Одной из команд они предложили не строить малую пирамиду, а команда ответила: «Какую пирамиду?», потому что решение не строить ее команда приняла за много игровых лет до этого. Условно говоря, на 24‑м игровом году выяснилось, что где‑то на 8‑м году они отказались от этой идеи, а в 20‑м году управляющий комитет пришел к ним с эти предложением. Управляющий комитет пришел и сказал: «Можете не строить». «Спасибо, — сказали они. — Хорошо, не будем». И вроде все совпало: планы совпали, факт совпал — все сошлось. Чтобы таких ситуаций не возникало в реальной жизни — попробуйте организовать такую отчетность, которая будет полезна, которая не будет самоцелью, но обеспечит прозрачность работы команд на нужном уровне для каждого слоя управления: управляющий комитет или совет, менеджеры проектов и, собственно, менеджеры команд.

И еще один важный момент в заключение.

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

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