Проекты — для достижения результата, а не для освоения бюджета

Ссылки сюда (1) →

В журнале «Управление проектами» (№1/2016) опубликована статья Максима Цепкова, нашего главного архитектора дирекции развития решений, посвященная проблемам проектного управления. В чем разница между внешней и внутренней целью проекта? Почему важно предусмотреть фазу опытно-промышленной эксплуатации? Как правильно выстроить управление рисками и результативностью проекта? Об этом — в материале «Проекты — для достижения результата, а не для освоения бюджета» в издании.

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

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

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

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

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

Надо отметить, что данная проблема проявляется в виде разрыва и на уровне методологии. Согласно PMI (Project Management Institute), эффективное использование результатов проекта не входит в состав самого проекта (Project Management), а относится к управлению программами проектов (Program Management). Такой разрыв на уровне методологии, безусловно, способствует проявлению этой проблемы в конкретных проектах. С другой стороны, методология включает в состав проекта изменения, которые должны привести к использованию результатов проекта в уже существующих операционных организациях и подразделениях или созданию новых. С этой точки зрения разрыва на методологическом уровне нет.

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

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

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

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

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

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

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

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

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

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