В последнее время все чаще при решении сложных, уникальных задач компании прибегают к проектному управлению. Инструменты управления проектами начали появляться еще в 50-е годы прошлого века. С тех пор накоплен немалый опыт управления проектами, однако статистика успеха выполненных в мире проектов остается неутешительной – примерно в 20% случаев проекты закрываются без достижения какого-либо результата. Поэтому тема антикризисного управления проектами сегодня актуальна как никогда. Как определить, что в проект нужно вмешаться, чтобы спасти его? Как производить спасение? Об этом и пойдет речь в статье.
В наше время с помощью проектного управления компании решают такие непростые задачи, как реализация стратегических задач, актуализация бизнес-модели, вывод на рынок новых продуктов, услуг и т.п. В некоторых отраслях управление проектами является прямым инструментом зарабатывания денег – например, строительство и IT-индустрия. Но даже и в этих сферах доля успешно выполненных проектов невысока. Судите сами. Как показало исследование PwC 2013 года, в предшествующие опросу 12 месяцев 78% инфраструктурных мегапроектов в странах Центральной и Восточной Европы и СНГ не были реализованы в срок, 52% – превысили запланированные бюджетом суммы. В IT-сфере, по данным The Standish Group, в 2012 году были успешно реализованы только 39% проектов, потерпели неудачу – 18%, имели некоторые проблемы – 43%. В Беларуси подобной статистики нет, но можно предположить, что она еще печальнее. Как показывает мой опыт, белорусские компании редко применяют в своей работе современные методы и инструменты управления проектами.
Доля провальных проектов, действительно, очень высока. Однако многие из них при условии своевременного профессионального вмешательства можно было спасти. Сразу оговорюсь: есть и такие проекты, в которые уже при «рождении» закладывается такой «генетический код», который практически не дает шанса на выживание. Я имею в виду факторы, которые приводят к снижению вероятности успеха проекта. По мнению исследователей PwC, основными из них являются:
- Некорректная оценка объемов работ, бюджета и сроков проекта;
- Отсутствие реального заказчика проекта;
- Плохо сформулированные цели проекта;
- Изменения в содержании проекта после прохождения половины срока;
- Недостаток ресурсов;
- Неразвитые коммуникации;
- Отсутствие подходящих решений для достижения целей.
Но оставим проекты с «плохими генами» и рассмотрим те, судьба которых вполне могла сложиться благополучно, однако по каким-то причинам они все же попали в разряд проблемных.
Известный эксперт в области управления проектами Рикардо Варгас предлагает считать проблемным тот проект, в котором отклонения от плановых ограничений (бюджета, сроков, целей) превышают приемлемый уровень допуска, но при этом есть неплохие шансы на реанимацию. Проблемные проекты стоит отличать от провальных проектов, в которых цели уже не могут быть достигнуты.
Рикардо Варгас предлагает рассмотреть ряд индикаторов, позволяющих определить, что проект потенциально становится проблемным (см. рис. 1).
На мой взгляд, предложенный список индикаторов можно взять за основу и добавить в него еще несколько. Например, участники команды проекта жалуются на перегрузки, недостаточно точный учет выполненного и оставшегося объема работ, сроков и бюджета. Индикаторы помогают обнаружить проблемность проекта на ранней стадии. А чем раньше мы это сделаем, тем больше шансов спасти проект.
Однако прежде чем спасать проект, нам нужно ответить на вопрос: а стоит ли это делать? Возможно, проект уже потерял свою былую привлекательность для заказчика. Или же усилия, которые будут потрачены на его спасение, несопоставимы с теми выгодами для бизнеса, которые можно в результате получить.
При принятии решения о том, стоит ли спасать проект, предлагаю ответить на ряд вопросов.
- Есть ли у проекта заказчик, который готов тратить достаточно времени на уточнение требований, приемку промежуточных результатов проекта и приоритезацию оставшихся требований?
- Изменились ли требования к продуктам проекта и если да, то насколько существенно?
- Стоит ли продолжать работу над продуктом проекта на существующих технологиях, если появились новые технологии?
- Появились ли новые заинтересованные стороны в проекте? Кто из них заинтересован в остановке проекта и насколько они влиятельны?
Получение ответов на эти вопросы поможет организации принять решение, стоит ли заниматься реанимацией проекта или правильнее будет его закрыть.
В моей практике был случай, когда меня в составе группы экспертов привлекли к анализу ситуации в проблемном проекте, связанном с созданием новой для компании бизнес-модели. На момент привлечения аудиторов в проект уже были вложены сотни тысяч долларов, и у собственников бизнеса сложилось ощущение, что проект находится в глубоком кризисе. Мы провели аудит проекта и выяснили следующее: у проекта практически не было документации, описывающей цели проекта, продукты и требования к ним, не было плана проекта, отчетов о ходе проекта и т.п. В общем, с документацией по проекту нам удалось ознакомиться всего за несколько часов. Интервью с ключевыми участниками показало, что программный продукт был создан на устаревшей технологии (причем с большим количеством ошибок), которую поддерживала одна компания в стране. Несмотря на все это, для работы с продуктом уже было создано подразделение, которое, естественно, получало заработную плату, но не могло выполнять свои функции, используя «сырой» продукт. Анализ рисков проекта показал, что оставлять продукт на старой технологии слишком рискованно, а развитие этого продукта на существующей технологии – крайне дорого. Аудиторы предложили инвесторам непростой выбор: переписать программный продукт на новых технологиях либо закрыть его и запустить новый. После презентации результатов аудита инвесторами было принято решение закрыть проект. Насколько я знаю историю этой компании, она так и не воплотила этот проект в жизнь. Однако его закрытие позволило компании остановить инвестиционный поток и направить его на реализацию более перспективных проектов. Можно ли было спасти тот проект? Думаю, да, но для этого аудит надо было провести гораздо раньше.
Вернемся к теме спасения проекта. Предлагаю простой алгоритм из пяти шагов для рассмотрения проблемного проекта.
Первый шаг – признание того, что проект стал проблемным. Признать этот факт должны заказчик (тот, кто принимает результаты) и команда проекта. Однако этого недостаточно – заказчик проекта должен согласиться с тем, что выполнить проект в рамках запланированных сроков и бюджета, с выполнением всех поставленных целей, уже невозможно. И для спасения проекта придется пожертвовать либо частью содержания проекта, либо бюджетом и (или)сроками.
Второй шаг – поиск проблем в проекте. Согласитесь, что прежде чем начинать лечение, нам нужно поставить правильный диагноз, иначе мы можем потратить свои усилия напрасно. Для поиска проблем в проекте мы можем использовать такие подходы, как анализ документации проекта, интервьюирование ключевых участников проекта, использование чек-листов. Можно использовать и более сложные инструменты, такие как ТРИЗ (теория решения изобретательских задач) и TOC (theory of constraints, теория ограничений).
Список типовых проблем проектов я уже привел в начале статьи, к ним можно добавить следующие.
- Отсутствие методологии управления проектом, что приводит к многочисленным рискам.
- Отсутствие экономического обоснования проекта (непонятно, сколько компания собиралась заработать на проекте и в какие сроки).
- Недостаточная мотивация участников проекта.
Но этот список не покрывает всех возможных проблем проекта, их можно выявить в ходе интервью и анализа документации.
После того как проблемы сформулированы, их нужно обсудить с заказчиком проекта. В моей практике встречались ситуации, когда то, что команда проекта считала проблемой, заказчик таковой не считал. Помочь здесь могут только навыки коммуникаций и убеждения. Но если заказчик все же не признает существование обнаруженных проблем, остаются два варианта: махнуть рукой на проект и дать ему утонуть или решить обнаруженные проблемы, взяв на себя ответственность за риск.
Третий шаг, как вы, возможно, уже догадались, – поиск решений. Причем некоторые проблемы будут иметь уже известное решение, а для других потребуется сформулировать противоречие и затем найти его решение. На этом этапе нам также может помочь ТРИЗ, в котором используются около 40 приемов для решения противоречий.
Итак, после того как проблемы проекта обнаружены и найдены пути их решения, нам нужно сделать четвертый шаг и выбрать одну из стратегий спасения проекта, связанных с изменением известного в управлении проектами «тройного ограничения»: любой проект ограничен определенным содержанием работ, сроками и бюджетом.
Стратегии изменения ограничений выглядят таким образом, как приведено ниже.
1. Изменить содержание проекта, при этом сохранив плановые сроки и бюджет. Для реализации этой стратегии необходимо будет провести ранжирование требований к продуктам проекта и разделить их на три группы: «должно быть» (без реализации этих требований продукт проекта неинтересен заказчику), «хорошо, если будет» (эти требования сделают продукт проекта более привлекательным для заказчика и пользователей, однако их отсутствие не помешает использовать продукт) и «не нужно» (от реализации этих требований стоит отказаться). Для ранжирования требований к продукту проекта можно использовать экспертный подход, метод Дельфи или методику QFD (Quality Function Deployment).
2. Увеличить плановый срок реализации проекта при сохранении запланированного содержания и бюджета проекта. Данная стратегия оправданна в случае если срок реализации проекта можно перенести, а вот дополнительное финансирование приведет к потере инвестиционной привлекательности. Выбор этой стратегии предполагает выполнение оценки оставшихся объемов работ по проекту и разработку нового прогнозного расписания по завершению проекта. Для выполнения оценки оставшихся объемов работ можно использовать такие подходы, как метод PERT, метод аналогов и экспертная оценка. При подготовке нового расписания проекта стоит обратить внимание на такие подходы, как метод критического пути (МКП) и метод критической цепочки (МКЦ). Второй подход был придуман в рамках теории ограничений, основан на методе критического пути, но при этом он позволяет решить те проблемы, которые есть в МКП. Стоит отметить, что внедрение подхода МКЦ требует изменения некоторых правил в мотивации персонала и подходов к оценке продолжительности работ проекта.
3. Увеличить плановый бюджет проекта при сохранении запланированного содержания и срока проекта. Данная стратегия интересна в ситуации, когда увеличение сроков проекта невозможно (как, например, при подготовке к Олимпийским играм) либо увеличение сроков приведет к большим потерям, нежели дополнительное инвестирование в проект.
4. Увеличить и бюджет, и срок проекта для сохранения запланированного содержания проекта. Эта стратегия, на первый взгляд, самая непривлекательная для заказчика проекта. Но я почти уверен, что в некоторых ситуациях она будет оправданна, т.к. небольшое увеличение сроков и бюджета может оказаться выгоднее, чем, например, серьезное увеличение сроков, которое может привести к большим «упущенным выгодам».
5. Создать новую конфигурацию «тройного ограничения», пересмотрев срок, содержание и бюджет проекта, по возможности сохранив часть первоначальных планов. Эта стратегия уместна в том случае, когда содержание проекта сильно отличается от описанного в первоначальном плане.
Выбор стратегии спасения зависит от выявленных проблем и решений. Например, если обнаружены проблемы с содержанием, то выбор стратегии будет связан с изменением содержания проекта.
Пятый шаг – реализация выбранной стратегии спасения проекта, которая должна включать в себя мероприятия по решению проблем, предложенные на шаге 3. При реализации стратегии необходимо сканировать индикаторы проблем, предложенные выше, и максимально быстро выявлять и решать новые проблемы, от которых не застрахован план по спасению проекта.
ПОДВЕДЕМ ИТОГИ
- Ни один план проекта не застрахован от проблем.
- Проблемы в проекте лучше обнаружить как можно раньше (для этого нужны индикаторы проблем), тогда у нас будет больше времени на спасение проекта.
- Причины проблем зачастую нетривиальны, и их выявление может потребовать от команды по спасению проекта знании и умении по использованию подходов к формулированию проблем (таких как ТРИЗ и теория ограничений).
- Для решения найденных проблем команда по спасению должна иметь навыки использования специальных инструментов (те же ТРИЗ и теория ограничений).
- Варианты решения проблем нужно обсудить с заказчиком проекта и выбрать одну из стратегий спасения проекта от провала.
- При реализации выбранной стратегии команде спасения проекта необходимо проводить мониторинг проекта по индикаторам проблемности и в случае возникновения проблем делать шаги по их формулированию и поиску решений.
Источник: Журнал "Генеральный директор"
Компания: Бизнес-школа «Здесь и Сейчас»
Тренер: Якубович Максим
