Почему проекты терпят неудачу? – обзор причин и эффективных решений

“Это управление проектом – но не в том смысле, в каком вы его понимаете!”Thinking

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

Несколько исследований, посвященных успешному управлению проектами в различных отраслях промышленности, продемонстрировали одну общую проблему – процент проектов, которые провалились гораздо выше, чем процент успешных проектов. Исследование за исследованием показывает, что, пожалуй, половина проектов не достигает заявленных результатов в сроки, с тем уровнем качества, которое ожидалось и в пределах выделенного бюджета, по причине неэффективного управления проектом (1). Компании начинают осознавать, что необходимо уделять больше времени и прилагать больше усилий для улучшения текущих стандартов управления проектами. Лин философия предоставляет платформу для этих улучшений и, что более важно, подводит к осознанию важности развития соответствующей культуры (с использованием правильных моделей поведения) для поддержки этих улучшений.

Существует несколько проблем, которые могут негативно отразиться на результате проекта; ниже приведены наиболее существенные (и важные) из них:

1. Разработка Бизнес-Кейса (экономическая модель или обоснование) – это не один из возможных вариантов действия, а необходимость! 

Устав проекта – это результат бизнес анализа, который еще называют  бизнес кейсом (экономической моделью). Экономическая модель, как правило, прорабатывается, чтобы определить  позицию бизнеса, стоит ли проект тех инвестиций, которые требуются для его осуществления. В общем, экономическая модель включает в себя результаты бизнеса и анализ экономического эффекта инвестиций. Эти результаты помогут не только исполнителям в принятии решений, но и помогут установить границы проекта и его цели/задачи.

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

Потенциал и границы проекта, как правило, определяются посредством изучения данных (анализ убытков или анализ добавления ценности) или сравнительного анализа производительности (анализ относительно эталона – бенчмаркинг) в зависимости от сценария проекта. «Тот пробел между текущим и желаемым будущим состоянием должен быть четко определен, а также должны быть определены и причины», — говорит Мартин Холмс компания «Lean Coaching». «Это покажет Что и Как может быть достигнуто заранее, до того, как все будет зафиксировано». И последнее, «очень важно сказать, что анализ проекта не может быть выполнен сидя за столом в офисе, необходимо сходить и посмотреть на процессы, подтвердить полученные ранее данные и поговорить с людьми, выполняющими эти процессы. Это именно то, что дает вескость и обоснованность уставу проекта, и позволяет заручиться поддержкой руководства на раннем этапе»»

2.   Плохо разработанный устав проекта приводит к слабому плану управления проектом.

Устав проекта – это больше, чем просто документ разрешающий существование проекта, это также и документ, который задает направление движения, обозначает ожидания и границы проекта по средствам определения:

  • Укрупненных требований по проекту  (цель, требования бизнеса)
  • Целей проекта по принципу СМАРТ (конкретные, измеримые, достижимые, актуальные, с четко определенными сроками)
  • Краткой сводки контрольных точек по проекту
  • Организации проекта – список заинтересованных лиц, включая основного спонсора (-ов) и руководителя проекта, с четко прописанными ролями и ответственностями.
  • Механизма отчетов и инструментов визуального менеджмента (структура совещаний, повестка, необходимый вклад и ожидаемый результат)
  • Процесса эскалации
  • Поведения команд

Russian picture 1

Этот документ дает руководителю проекта право задействовать ресурсы организации для выполнения заданий и работ по проекту для создания основного графика/плана проекта. Четко определенный устав проекта дает достаточно информации для разработки плана первого уровня  (основной план проекта или краткий план внедрения) и плана второго уровня (функциональный план внедрения).

  • Организации зачастую недооценивают важность четко сформулированного устава проекта. У большинства организаций нет стандартной процедуры написания устава проекта. Именно поэтому очень часто можно увидеть:
  • Размытый документ, который сложно использовать при планировании
  • Одно и то же содержание устава для разных по размеру проектов (нет градации по масштабу)
  • Неконтролируемые проекты в связи с плохой организационной структурой проекта и низким уровнем полномочий членов проекта

От экономической модели до устава проекта, проекты должны быть, во-первых, классифицированы в зависимости от их размера и затем необходимо их сравнить относительно матрицы масштабности проектов. Эта матрица (масштабности проектов) в соответствии с размером проекта определяет инструменты визуального менеджмента, уровень орг. структуры проекта и время, которое потребуется от команды проекта. «Все это прорабатывается с целью установить «Лин» стандарт (т.е. избежать потерь) для проектов на основании их размера», — говорит Мартин Манчин компания «Lean Coaching». «Это служит руководством для разработки устава проекта и первоначального планирования проекта», — добавляет он.

Продуманный устав проекта помогает в разработке хорошего плана проекта. «Через задачи, устав проекта задает основные контрольные точки проекта», — говорит Мартин. «Эти контрольные точки помогут не только вести прогресс, но и оказывают давление и заставляют решать проблемы на раннем этапе проекта».

3. У любого проекта есть контрольные точки, но к ним не относятся с должной серьезностью.

Наша основная цель для проектов – сделать проблемы видимыми и решать их  на самом начальном этапе, пока они все еще «на бумаге», и, следовательно, их можно решить быстрее и дешевле, чем на более поздних этапах проекта. Но, тем не менее, очень часто можно увидеть скопление нерешенных проблем к моменту достижения очередной контрольной точки проекта, и эти проблемы решаются (условно оптимально), когда расходы или физическое их проявление становятся неминуемо очевидными к моменту передачи дел. В худшем случае, проблемы выходят на свет из отзывов покупателей/клиентов. «Такой «промах» обычно происходит из-за одного или нескольких следующих факторов: 1) недостаток решений/дисциплины, 2)недостаток возможностей в Лин управлении проектом, например, нет системы Андон, т.е. процесса остановки линии для обозначения проблемы и принятия контрмер по ней, и/или 3) недостаток прозрачности статуса проекта», — говорит Герт Хаар-Йоргенсен, основатель компании «Lean Coaching».Russian picture 2.jpg

Следовательно, цели и задачи определенные уставом проекта должны быть переведены в конкретные контрольные точки на плане/графике проекта, и обзор прогресса проекта должен проводиться часто, статус должен быть визуализирован и отслеживаться через ключевые показатели эффективности (KPI), при этом необходимо использовать цикл PDCA-R (Планируй-Делай-Проверяй-Действуй-Учитывай). «Отставания (2) от плана и плановых показателей/целей по ключевым показателям эффективности запускают процесс решения проблем», — говорит Мартин. «Использование мини-PDCA (Планируй-Делай-Проверяй-Действуй) на протяжении всего проекта помогает обнаружить отклонения на раннем этапе и устранить корень проблем, влияющих на достижение целей и реализацию ожидаемого бизнес-потенциала»

4. Роль руководителя проекта зачастую выходит за рамки его полномочий – Он/она не единственный виноватый!

Сегодня во многих компаниях, должность руководителя проекта больше не расценивается как желаемая. Как правило, руководителям приписывается ответственность  за гораздо большее, чем они на самом деле ответственны; они ведут проект, и вскоре их перегружают обязанностями, которые в идеале должны быть поделены между членами команды проекта, с которыми это условие изначально обуславливается. Подобная ситуация не только способствует неверным ожиданиям со стороны заинтересованных лиц (в особенности со стороны спонсоров проекта), но и создает ненужный стресс и идеальные условия для того, чтобы руководитель проекта провалился и вместе с ним, соответственно, и весь проект.

Несмотря на то, что руководитель проекта несет общую ответственность за проект, он не может один отвечать за успех или провал проекта. Руководитель проекта управляет проектом от имени и в интересах спонсоров, которые зачастую представлены Руководящим Комитетом. Руководитель проекта отвечает за координацию проекта, его исполнение и прозрачность – общее направление работ по проекту, синхронизацию и выравнивание мероприятий проводимых основными и вспомогательными службами/подразделениями, за периодические отчеты по статусу проекта и эскалацию соответствующих проблем до уровня Руководящего Комитета.  Следовательно, руководитель проекта несет ответственность за проект вместе с Руководящим Комитетом путем управления командой проекта и осуществляемыми ими мероприятиями. «Спонсоры, через руководителей проектов, передают полномочия подразделениям компании (так называемым «представителям»), за которые те отвечают, и таким образом теперь уже они (представители) отвечают за выполнение плана и задач своего подразделения.  Они делят ответственность с руководителем проекта за результаты», — говорит Дэвид Хёрст, компания «Lean Coaching».

Помимо плохо определенной роли руководителя проекта, организационная структура проекта должна быть проработана (и задокументирована в Уставе Проекта). Определение организационной структуры проекта основывается на размере и охвате проекта; тем не менее, состав участников/структура, как правило, определяется Руководящим Комитетом, руководителем проекта, основными службами/подразделениями (ответственными за достижение ожидаемых результатов проекта) и вспомогательными службами (службы, помогающие основным службам). Индивидуально у каждой из этих служб есть свои обязанности по проекту, которые помогают достигать каждую контрольную точку и основные цели.

5. Нет оперативного центра = нет визуальности + нет ответственности = отсутствие контроля

Часто планы проекта выполняются в «MS Project» и хранятся в электронном виде для ознакомления со статусом, внесением обновлений и изменений. Основная проблема в том, что вместе с этим идет недостаточная визуализация и прозрачность. «Невозможно держать всю команду включенными в работу, и в курсе дел относительно прогресса проекта, изменений, вопросов и проводимых действий не имея оперативного центра», — говорит Мартин. Оперативный центр, он же пункт слежения за оперативной обстановкой, это помещение, где находятся планы 1 и 2 уровней, и где на регулярной основе проходят обзоры, проводимые представителями основных служб и руководителем проекта. Это позволяет видеть связь между всеми проводимыми мероприятиями и основными целями проекта. «В идеале, любой сотрудник компании должен суметь понять статус проекта в течение 30 секунд  и в течение 3 минут определить отставание факта от планового показателя, предпринятые по этому вопросу контрмеры, и когда ожидается возврат к графику/плану», — говорит Мартин.

Russian picture 4

Во время Лин проектов, планы 1 и 2 уровней создаются в формате Тактического Плана Внедрения (TIP), и в электронной форме, но после завершения их разработки, они распечатываются, и обновление статуса производится вручную на регулярной основе. «Процесс обзора, проводимый в ручном режиме, создает чувство ответственности  и визуализирует имеющиеся проблемы при помощи «красных пик», — говорит Дэвид Хёрст, использующий этот подход на протяжении более 20 лет, со времен, когда он занимал должность «генерального управляющего по работе с отставаниями от плана» в Toyota. «красные пики/галочки показывают все отставания от плана и призывают к действию, прежде, чем их будет уже не исправить».

Регулярные структурированные обзоры на всех уровнях (в оперативном центре) вызывают необходимое чувство контроля проекта. Частота проведения обзоров определяется исходя из размеров и важности проекта. Как правило, обзоры больших проектов проводятся еженедельно руководителем проекта и представителями, ежемесячно руководителем проекта и Руководящим Комитетом, и ежеквартально спонсорами, руководителем проекта и советом директоров (участвуют при проведении больших проектов). «Подобные частые обзоры создают чувство ответственности за выполнение задач по проекту, и оказывает необходимое давление, способствуя применению корректирующих мер», — говорит Дэвид. «Это помогает избежать «синдрома студента», т.е. когда выполнение работы/задания откладывается на самый последний момент». Эти обзоры также используются для обозначения критериев эскалации, т.е. чтобы расставить приоритеты по соответствующим вопросам/проблемам.

6. Извлеченные из проектов уроки не должны быть просто зафиксированы на бумаге

Подход PDCA (Планируй-Делай-Проверяй-Действуй) не будет полным без шага под названием «Учитывай», его еще зачастую называют «извлечение уроков». На этом этапе цикла команда проекта должна определить и поразмышлять о слабых и сильных сторонах (управленческого, системного и функционального характера), которые повлияли на успешность проекта. «Конечная цель этого процесса – собрать и документально закрепить последующие действия, направленные на улучшение «лучшей сегодняшней практики» проекта» — говорит Даниель Браун, компания  «Lean Coaching». Самая важная часть шага под названием «Учитывать» — это управление изменениями структурированным образом, с учетом их влияния на другие действия/мероприятия и проверяя результат этих изменений посредством обзора KPI (Ключевых Показателей Эффективности) и Genchi Genbutsu (Идти-Смотреть-Увидеть). «Этот процесс называется Keshikomi и используется для эффективного управления изменениями с фокусом на улучшение хода выполнения проекта, а не на его ухудшение», — говорит Даниэль. Keshikomi является частью стандартов компании для индивидуальных типов проектов», — добавляет она.

Процесс «извлечения уроков» зачастую недооценивается компаниями. Многие из них просто документируют в конце проекта извлеченные уроки просто как часть формального стандартного процесса, не реализуя те возможности, которые им предоставляются. «Когда извлеченные уроки просто фиксируются на бумаге, они теряют свою силу содействовать ходу выполнения проекта и становятся просто  историей», — говорит Даниэль. «Не  встраивая их обратно в стандарты проекта, процесс не имеет никакой силы».

 

Russian picture 5

Краткие выводы

Успешность проекта зависит от детализации и дисциплинированности проведения нескольких мероприятий до, во время и после завершения проекта. Чтобы достичь успеха, эти мероприятия должны проходить в гармонии; плохая реализация этих мероприятий подвергает весь проект риску стать неудачным. Лин образ мышления предоставляет образцовый подход (и структуру) ведения проектов, где внимание уделяется не только фундаментальным инструментам и методам, но и необходимым моделям поведения, благодаря которым и достигается успешность проекта и его максимальная эффективность. Подход PDCA-R (Планируй-Делай-Проверяй-Действуй-Учитывай) помогает структурировать проекты за счет использования стандартов, сильной культуры решения проблем и непрерывного улучшения. Эти основные принципы приносят пользу не только настоящим, но и будущим проектам, непрерывно улучшая мероприятия, проводимые в рамках проектов, общую эффективность, и стабильно достигая  предполагаемые бизнес результаты.

 

 

Posted in Podcasts.