1. Введение

Статья является результатом объединения практического опыта авторов в течение последних 11 лет. В исследование вошли 10 крупных и средних проектов, реализовывавшихся на территории РФ, которые вышли на траекторию провала или потерпели неудачу. Большинство менеджеров разного уровня, участвовавшие в этих проектах, настойчиво прикладывали усилия, чтобы задекларировать их успех. В условиях противоречивости данных аналитики по проекту, владельцы проектов и акционеры, как выяснилось, могут идентифицировать неудачу проекта, когда он окончательно вышел за рамки разумных пределов по срокам и бюджету. Поэтому два владельца проектов интересовались существующими методами ранней диагностики выхода проекта на траекторию провала, и подходами исправления этой траектории еще на ранних сроках, пока проект еще не стал «токсичным». Накопленный нами практический опыт теперь можно обобщить и предоставить научному сообществу выявленные закономерности, приводящие российские проекты к провалу.

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

Большинство проектов терпят неудачу из-за людей, принимающих решения в конкретное время и в конкретном месте на фоне накапливающихся проблем в управлении проектами, а не из-за технических проблем, неверной методологии разработки, отсутствия технологической платформы, программного обеспечения или иных инструментов. По мнению Д. Вайнберга, есть три причины любой неудачи: «Люди, люди, люди»[7].

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

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

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

2. Формулирование нового определения «провала проекта»

Согласно стандарту PMBoK [2], определение провала проекта сопряжено с недостижением хотя бы одного из трех общих критериев успеха, а именно:

• В соответствии с собранными требованиями и ожиданиями заинтересованных сторон;
• В рамках утвержденного бюджета;
• Завершение проекта в расчетные сроки.

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

Целесообразно общепринятые критерии дополнить пунктом: «Организация получает выгоды / преимущества или конечные результаты проекта, пригодные к использованию в операционной деятельности».

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

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

Jones C. [3] и Thomsett M. [5] отметили, что многие участники неосознанно «раздувают» бюджеты, вследствие возникновения незапланированной и неотслеживаемой работы в вечернее время и выходные дни. Наши наблюдения подтверждают данные выводы. В практике российских проектов, как правило, бюджеты могут превышаться на 50-100%, не только в результате незапланированных работ в вечернее время и выходные дни, но и за счет инициированных, но ранее незапланированных и/или дополнительных пакетов работ, которые не предусматривал бюджет проекта. Скрытое «раздувание» бюджета в 2-х проектах происходило по причине поставки одним лотом ключевого строительного материала, необходимого из расчета на весь период строительства, что вызвало потребность в организации хранения в специальных условиях, а замораживание денежных средств привело к увеличению размера кредита и расходов на его обслуживание. В 8 других проектах, мы обнаружили скрытые издержки, связанные с выпадением пакетов работ при планировании, в части сбора и анализа требований, перепланирования проекта в начале каждого этапа, пропуском пуско-наладочных работ, тестирования различных систем, работ с различной документацией, задач по подготовке и закрытию контрактов и многие другие выпавшие из графика задачи. Несмотря на соблюдение процессов по формальным признакам, а также учитывая зоны выпадения работ и скрытых издержек, 8 проектов сорвали сроки, и вышли за рамки бюджетов в ходе их реализации.

В ходе анализа проектов, мы обратили внимание на часто игнорируемое владельцами проектов обстоятельства, что во всех 10 проектах члены команд имели все признаки «профессионального выгорания» и были демотивированы. В 4-х проектах текучесть кадров в командах достигала 90% в течение одного года. Ключевые специалисты были недовольны управлением и реализацией проекта настолько, что часть из них «отключилась» и выполняла обязанности автоматически, не осмысливая решаемые задачи, другая часть уволилась из организаций. Полученный ими негативный опыт резко сократил их результативность. Скрытые долгосрочные издержки, связанные с реанимацией демотивированных специалистов, в том числе и на последующих проектах на которых они станут работать, редко обсуждаются при анализе рисков и сбоев в проектах, хотя имеют серьезные долгосрочные последствия.

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

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

Очевидно, что если эти критерии распространить на другие проекты, которые признаны успешными в России, то большинство из них будут квалифицированы, как провальные.

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

3. Общие причины провала проекта

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

Наиболее распространенные точки зрения причин провала проекта связывают с применением неадекватных технологий, несоответствующих методологий, стратегий разработки, недостатком навыков, отсутствием программного обеспечения и т.д. Мы же склонны считать, что ситуация, когда организация позволяет инициировать проект без выявления и устранения ограничений и барьеров, является ошибкой управления. Современный подход к управлению проектами, Thomsett R. обращает внимание [6], предусматривает участие высшего руководства, участие заинтересованных сторон или клиентов / пользователей, в управлении рисками и планировании качества в составе интегрированных компонентов управления проектами еще до инициации.

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

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

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

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

3.1 Факторы уровня 1 – Пациент умер, не приходя в сознание.

Отсутствие надежного спонсора проекта или владельца

В своем знаменитом труде Хаммер М. и Чампи Д. [1] наглядно демонстрируют, что причины высокой частоты провалов проектов реинжиниринга бизнес-процессов напрямую связаны с отсутствием приверженности высшего руководства. По мнению Thomsett М. [4], современная роль спонсоров проекта и членов руководящего комитета выходит далеко за рамки традиционных пассивных ролей. Крайне важно, чтобы руководители высшего звена, которые инициировали подготовку проекта, активно принимали участие в качестве исполнительных руководителей, оказывая различную помощь руководителю проекта в следующих областях:

• участие заинтересованных сторон, принятие обязательств ими и разрешение конфликтов;
• планирование и реализация преимуществ;
• планирование требований к качеству;
• управление рисками;
• управление изменениями проекта.

Эти области дополняют традиционные роли утверждения, финансирования и укомплектования персоналом проекта.

В российских проектах типична ситуация, когда руководитель проекта несет полную ответственность, но в тоже время не имеет необходимых полномочий и уровня организационной и финансовой власти для достижения поставленной цели. Jones C. считает [3], что отсутствие необходимого уровня власти руководителя проекта не является существенным фактором. Наши наблюдения позволяют сделать иной вывод. В 10 проектах, отсутствие власти руководителя проекта и поддержки высшим руководством запустило цепь событий, которые выражались в регулярных запросах со стороны руководителей высшего звена на изменения содержания проекта, отзыв и отвлечение специалистов с проекта, требований приведения обоснований по выделению финансовых средств и т.д. Распространенная ситуация для руководителя проекта, когда один из руководителей высшего звена требует внести дополнения с корректировкой целей. Без надежного спонсора у руководителя проекта нет иного выбора, как принять запросы в работу, даже если это повлечет срыв сроков и увеличение бюджета. Другая типичная ситуация, когда на ранних этапах один из руководителей высшего звена обещает выделить ключевые компетенции, но впоследствии меняет приоритеты, делая ресурсы недоступными для руководителя проекта. В тоже время, другие топ-менеджеры, не взирая на существующие ограничения, требуют от руководителя проекта сократить сроки реализации проекта или работ, не предоставляя ему время, необходимое для проведения должного анализа модели графика проекта.

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

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

В каждом из 10 исследованных проектов отсутствовал надежный спонсор. Один из руководителей проектов сказал: «Управлять проектом без надежного спонсора - это увидеть ад на Земле».

Отсутствие участия заинтересованных сторон

Заинтересованные стороны проекта - это люди, которые не входят в сферу контроля над проектом и являются поставщиками услуг, такие как эксперты и консультанты, которые определяют требования, и / или получатели конечного результата проекта. По мнению Thomsett М. [4], эти люди имеют решающее значение для достижения успеха проекта. Если менеджер проекта не может получить их компетенции и поддержку этих сторон, то такие процессы, как определение содержания и рамок проекта, идентификация и управление рисками, выгодами и их реализация, определение требований к качеству и контроль над изменениями, не будут внушать доверия.

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

Отсутствие внешней поддержки знаниями

Для России «проектный менеджмент» – относительно молодая прикладная дисциплина, и ожидать высших моделей зрелости еще рано. Так из 10 проектов, реализуемых в 8 организациях, можно идентифицировать первую модель зрелости управления проектами только в 1. Остальные проекты реализовывались в среде с «нулевым» уровнем зрелости. Особенность выхода на 1-ый уровень зрелости заключается в создании внутри организации пространства с «единой терминологией проектного менеджмента». При полном отсутствии знаний проектного менеджмента в организации, компетенции необходимо заимствовать, и активно их развивать, накапливая знания в внутри организации. В условиях высокой текучести кадров, накопление знаний становится невозможным.

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

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

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

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

Факторы уровня 2 – Давление на команду становиться жестким.

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

Планирование и реализация преимуществ / выгод

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

Планирование требований к качеству

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

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

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

Управление изменениями проекта

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

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

Управление коммуникациями

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

4. Типовой путь провала проекта

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

Этап 1 –Приходите завтра

Проект инициирован и утвержден в качестве инструмента развития как самостоятельная единица или часть программы, при этом команда приступает к сбору общих требований и планирует включить в проект, например, функции A, B, C и D. Вскоре команде становится очевидным, что оценки сроков и стоимости ошибочны. Кроме того, один из топ-менеджеров вносит изменение в проект, добавляя функцию E, и требуя от команды обязательного включения ее в рамки проекта, даже несмотря на то, что даже функцию D команда не в силах охватить в данной конфигурации. В условиях отсутствия спонсора проекта, поддерживающих заинтересованных сторон и внешней поддержки знаниями, руководитель проекта с командой без какого-либо одобрения собственника, вынуждены запустить цикл разработки проекта с «нуля». Фактически, они в одностороннем порядке деактивируют проект, и продолжают работать над функциями A, B, C и D с функцией Е, которая должна быть внесена в проект и реализовываться позднее. На этом этапе процесс планирования начинает разрушаться, а первоначальный бизнес-кейс, отведенные сроки и утвержденный бюджет остаются неизменными.

Этап 2 - Нужно больше людей

Первый этап запускает цепную реакцию совершения руководителем проекта дальнейших неизбежных ошибок в проекте. Риски множатся в геометрической прогрессии, захватывая и проникая во все сферы проекта. Даже при их снятии, перед командой остается главная угроза, ведь она реализует функции A, B, C и E, а собственник ожидает наличие функции D. На этом этапе руководитель проекта начинает требовать дополнительных людей и ресурсов, т.к. члены команды загружены задачами, и не могут быть отвлечены для выполнения функции D. На фоне загруженности команды и разрушения планирования проекта, появляются несанкционированные запросы о предоставлении информации от функциональных подразделений. На этом этапе планирование проекта становится неофициальным и реактивным, присутствует риск ведения скрытой параллельной разработки вне графика проекта. Фактически, график проекта становится формальностью, и часто делегируется одному из членов команды, чтобы освободить остальных. Таким образом, происходит запуск «игр в график», что означает подачу собственнику отчетов,  оторванных от реального положения дел.

Этап 3 – Кто-нибудь не работает в эти выходные?

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

Этап 4 - Все сошли с ума!

Наконец, проект деградирует из «полуорганизованной толпы» с быстроменяющимися и применяющими грязные подходы участниками в причудливую форму группы, которую можно назвать триггером «лемминги». На этом этапе все члены команды, включая руководителя проекта, фактически потеряли контроль над проектом. Достигнутый когнитивный диссонанс приводит к полному отрицанию ими отчаянного состояния проекта. Члены команды часто работают по 7 дней в неделю и, в некоторых случаях, более 10 часов в день. Графика проекта уже не существует, и вся работа распределяется устно, с помощью распоряжений. Интересно, что многие сотрудники материнской организации считают проект нереальным: можно наблюдать феномен группового мышления «Залив Пигса» - все знают, но молчат. Например, в одном проекте все члены команды и руководитель проекта считали, что проект можно реализовать за 3 месяца, и что работа консультантов была пустой тратой времени. В итоге мы определили, что проект отстает на 12 месяцев от графика и будет поставлен, в лучшем случае, через 15 месяцев, а не 3! Наши выводы оказались неточными - проект был поставлен через 18 месяцев. На этом этапе проект полностью выходит из-под контроля и может оставаться в этом состоянии бесконечно долго. По существу, команда больше не понимает цели или имеющиеся проблемы управления проектами - например, лемминги - они слепо переходят к крайнему сроку без анализа пути достижения и имеющихся барьеров, поскольку это все, что имеет для них значение.

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

Восемь проектов из 10 исследованных нами деградировали до этапа 4, а остальные 2 были на этапе 3.

5. Признаки провала проекта

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

Ранние признаки

1. Отсутствие плана проекта и обновленного бизнес-кейса

Как уже обсуждалось Thomsett М., Jones С. и другими, большинство проектов имеют риск внесения изменений в содержание проекта, и в результате первоначальный бизнес-кейс и связанные с ним планы проектов должны быть подвергнуты четким и управляемым изменениям. Отсутствие серии изменений, одобренных Спонсором, Руководящим комитетом и заинтересованными сторонами, является потенциальным признаком деградации коммуникаций между руководителем проекта и спонсором.

2. Отсутствие поддержки консультантов и экспертов

Как отмечал Thomsett M. [4] в хорошо управляемом проекте, консультанты и привлеченные эксперты участвуют в планировании проекта и регулярно информируются о ходе проекта. Отсутствие связи с ними на регулярной основе является потенциальным признаком неудачи.

3. Преждевременная инициация проекта

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

4. Отсутствие участия внешней стороны, проверяющей качество

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

Смертельные признаки

1. Чрезмерно напряженная работа

Команды, которые мотивированы, часто работают долгие часы. Однако при выходе на траекторию провала работа в вечернее время и выходные дни не является добровольной, но становится нормой. В целом, команда, работающая более 60 часов в неделю в течение длительного периода, испытывает серьезные проблемы.

2. Высокая текучесть кадров в проекте

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

3. Агрессивное и защитное поведение команды

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

4. Команда в отчаянии

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

6. Рекомендации или метод проверки управляемости проекта

Существует ясный и простой тест для проверки состояния проекта: попробуйте его остановить.

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

«Мы не можем остановить проект для планирования / перепланирования. Нам некогда, у нас есть крайний срок. Необходимо действовать, а не планировать!»

Если вы получили аналогичный ответ, то срочно останавливайте проект и проводите перепланирование. Проект уже в беде!

1. Хаммер М., Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. [Электронный ресурс]. - М.: Манн, Иванов и Фербер, 2011. - 288 с. Url: http://reflecthinking.ru/wp-content/uploads/2013/04/Reinginiring-Corporacii.pdf (дата обращения: 30.04.2019);

2. A guide to the project management body of knowledge (PMBOK guide) / Sixth edition. [Электронный ресурс] Newtown Square, PA: Project Management Institute, USA, 2017. - 976 p. Url: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok (дата обращения: 19.02.2019);

3. Jones C. Assessment and control of software risks. [Электронный ресурс] / Yourdon Press in Englewood Cliffs, N.J., USA, 1994. - 619 p. Url: https://openlibrary.org/books/OL1425786M/Assessment_and_control_of_software_risks (дата обращения: 24.03.2019).

4. Thomsett Michael C. Getting started in options / Michael C. Thomsett. [Электронный ресурс] - 7th ed. Published by John Wiley & Sons, Inc., Hoboken, New Jersey 2007. - 256 p. Url: https://www.r-5.org/files/books/trading/schoolbooks/Michael_C_Thomsett-Getting_Started_in_Options-EN.pdf (дата обращения: 27.04.2019);

5. Thomsett Michael C. Getting Started in Real Estate Investing. 3rd ed. / Published by John Wiley & Sons, Inc., Hoboken, New Jersey, 2009. - 266 p.;

6. Thomsett Rob. Radical project management. Upper Saddle River, N. J.: Prentice Hall PTR, 2002. - 291 c.;

7. Weinberg G. An Introduction to General Systems Thinking (Silver Anniversary Edition) [Электронный ресурс].- Dorset House Publishing Co Inc., U.S., April 2001- 279 p. Url: https://openlibrary.org/works/OL1958813W/An_introduction_to_general_systems_thinking (дата обращения: 25.04.2019);