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

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

Существуют различные проблемы, которые могут отрицательно сказаться на исходе проекта. Ниже представлены самые актуальные из них:

1. Подготовка экономического обоснования проекта (бизнес-кейса) – это необходимость, а не просто возможная опция!

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

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

Потенциал проекта и его границы, как правило, определяются с помощью анализа данных (анализ потерь и добавленной ценности) или сопоставимых аналогов (бенчмарк-анализ), в зависимости от сценария проекта. «Необходимо четко определить пробел между текущим и желаемым будущим состоянием, а также причины пробела», — говорит Герт Хаар-Йоргенсен, «Лин Коучинг». — «Это покажет, чего нужно достичь и как, в установленные сроки». Он добавляет: «Важно отметить, что анализ проекта нельзя провести, сидя за столом или в кабинете. Необходимо идти и смотреть на процессы, подтверждать данные и разговаривать с вовлеченными людьми. Это именно то, что обеспечит обоснование паспорту проекта и запустит процесс вовлечения людей на ранней стадии».

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

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

• общие требования проекта (цель, бизнес-требования);

• конечные цели проекта по принципу SMART;

• краткая выкладка укрупненного графика работ с ключевыми этапами;

• организация проекта – список заинтересованных лиц, включая основного спонсора (спонсоров) и руководителя проекта с четкой ролью и ответственностью;

• механизм отчетности и инструменты визуального управления (структура совещаний, повестка встреч, входная информация и результат на выходе);

• процесс «эскалации» проблем;

• поведение команды.

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

Организации зачастую недооценивают важность внедрения четкого паспорта проекта. Большинство организаций не имеют соответствующей стандартной процедуры. Следовательно, распространенным результатом является:

• размытый документ, который сложно использовать в качестве справочного документа для планирования;

•  одинаковое содержание паспорта проекта для проектов различных масштабов (нет возможности варьирования масштабов);

• неконтролируемые проекты ввиду плохой организации и недостаточного уровня полномочий.

Проходя процесс от бизнес-кейса до паспорта проекта, необходимо сначала классифицировать проекты с точки зрения размера, а затем оценить их в соответствии с установленной «матрицей варьирования масштабов». Матрица варьирования масштабов определяет инструменты визуального управления, уровень организационной структуры и время, необходимое персоналу в проекте. «Такой метод устанавливает лин-стандарт для проектов (избежание потерь), в соответствии с их масштабами», — комментирует Герт Хаар-Йоргенсен и добавляет: «Это задает четкие ориентиры для разработки паспорта проекта и предварительного планирования».

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

3. Ключевые вехи проектов должны восприниматься со всей серьезностью

Фундаментальной целью проектов является визуализация проблем и их решение на старте – пока они все еще «на бумаге» и, следовательно, решить их дешевле и быстрее, чем на более поздних стадиях, когда проект уже идет. Тем не менее, скопление нерешенных проблем на соответствующих вехах является распространенной ситуацией. Проблемы решаются, только когда их стоимость и физическое проявление неизбежно принимают четкие очертания ближе к стадии передачи проекта (не самый оптимальный расклад). В худшем случае проблемы «всплывают» только через обратную связь заказчиков. «Этот «промах», как правило, случается в результате одного ли нескольких факторов: 1) недостаточная решительность / дисциплина; 2) недостаточные способности в управлении лин-проектами, например, отсутствие системы типа «андон» / остановки линии, чтобы сигнализировать о проблемах и принимать контрмеры по ним и/или 3) недостаточная прозрачность статуса проекта, достигаемая с помощью регулярной актуализации информации», — поясняет Герт Хаар-Йоргенсен, «Лин Коучинг».

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

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

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

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

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

5. Отсутствие комнаты «обея» = отсутствие визуализации + отсутствие ответственности = недостаточный контроль

Зачастую планы работ пишутся в программе управления проектами Microsoft Project и хранятся в электронном виде для проверки статуса, обновлений и корректировок.  Основная проблема здесь заключается в недостаточной визуализации и прозрачности такой системы для проекта. «Невозможно удерживать всю команду вовлеченной и информированной о прогрессе проекта, изменениях, проблемах и действиях, не имея комнаты обея» — говорит Герт Хаар-Йоргенсен. Комната обея, также известная как «штаб», — это то место, где отображаются планы 1го и 2го уровня и проходят регулярные обзоры, проводимые представителями основного функционала и руководителем проекта. Это обеспечивает визуализацию всех мероприятий, связанных общими целями проекта.  «В идеале, любой человек в организации должен понимать статус проекта за 30 секунд, а за 3 минуты – определять пробел, принятые контрмеры и дату ожидаемого устранения отставания», — поясняет Герт.

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

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

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

Подход «PDCA» не является полноценным без шага «размышление», также известного среди многих практиков как «вынесенные уроки». На этом шаге проектная команда должна определить и подумать над слабыми и сильными сторонами (в части управления, системности и функционала), которые повлияли на успех проекта. «Конечная цель этого процесса – зафиксировать и формализовать действия, необходимые для улучшения «самых оптимальных на сегодняшний день» стандартов в проекте», — объясняет Даниель Браун, «Лин Коучинг». Критически важной частью шага «размышление» является структурированное управление выявленными изменениями с учетом общего эффекта от них на другие мероприятия и подтверждение результата через обзоры показателей и «Генчи Генбутсу» (подход «иди и посмотри»). «Этот процесс называется «кешикоми» и применяется для эффективного управления изменениями, фокусируясь на повышении эффективности проекта», — продолжает Даниель.

Организации зачастую недооценивают процесс рефлексии. Зачастую компании в конце проектов фиксируют извлечённые уроки в документах просто как часть формального стандартного процесса, при этом не задумываясь о возможностях, которые предоставляет процесс рефлексии. «Когда происходит просто фиксация в документах, извлеченные уроки теряют свою силу и не могут эффективно помочь проекту, превращаясь в историю», — говорит Даниель. — «Если их не встроить в стандарты проекта, процесс не имеет «законной» силы».

Выводы

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

(1) Бэк-спайк – это наглядное отображение отставания задачи или вехи от плана.

(2) Матта, Н.Ф. и Ашкенас, Р.Н. (сентябрь, 2003 год). «Почему даже хорошие проекты терпят крах». Из журнала «Гарвард Бизнес Ревью». Ссылка на источник:http://hbr.org/2003/09/why-good-projects-fail-anyway/ar/1#disqus_thread