Основные управленческие ошибки реализации крупных проектов

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

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

Просчеты, связанные с персоналом

Ошибка № 1: Проекту не хватает ресурсов и квалифицированных исполнителей.

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

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

«Существует масса организационных моделей, — отметил Ричард Скэннелл, один из основателей компании GlassHouse Technologies, предоставляющей консультационные услуги, связанные с построением ИТ-инфраструктуры. — Но я никогда еще не видел, чтобы хорошо работало абсолютно все. На вопросы, касающиеся распределения ресурсов, к сожалению, не существует простого ответа».

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

Скэннелл предлагает формировать «команды тигров», члены которых освобождаются от своих традиционных обязанностей на год или больше ради участия в конкретном проекте. Кен Чени, директор центра HP Software’s PPM Center, рекомендует распределять ресурсы на уровне проекта, не опускаясь до конкретных задач, поскольку сделать это гораздо труднее.

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

Ошибка № 2: Нехватка опытных руководителей проектов.

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

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

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

Процедурные ошибки

Ошибка № 3: Управление проектами осуществляется при отсутствии стандартных, повторяющихся процедур.

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

Решение: Методология управления проектами помогает вам осуществлять их эффективную реализацию и находиться в курсе всех мероприятий, сопряженных с выполнением проекта. «Наличие базиса, включающего стандарты и методологии, позволит избежать многих рисков, связанных с претворением ИТ-проектов в жизнь», — отметил Чени.

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

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

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

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

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

Ошибка № 5: Изменения не соответствуют содержанию и границам проекта.

Проявление: Бюджет проекта устойчиво растет. То же самое происходит и со сроками.

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

Ошибка № 6: Отсутствие актуальной информации о состоянии проектов.

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

Решение: Программное обеспечение.

Ошибка № 7: Игнорирование возникающих проблем.

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

Решение: «Если вы допустили ошибку, все дальнейшее будет зависеть от того, насколько хорошо вам удастся ее исправить, — заметил Скэннелл. — Многие начинают замечать, что что-то не так, и пытаются внести коррективы лишь через месяц. Необходимо как можно раньше понять, где была допущена ошибка, и постараться привлечь к ее устранению как можно больше заинтересованных лиц».

Планируемые недочеты

Ошибка № 8: Игнорирование необходимости определения содержания и границ проекта.

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

Решение: Неясные проекты — повод для обсуждения ситуации с представителями бизнеса и уточнения содержания планируемых задач и их ограничений.

Ошибка № 9: Отсутствие понимания зависимостей, существующих между проектами.

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

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

Ошибка № 10: Игнорирование законов Мерфи.

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

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

Решение: В рамках планирования проекта проведите оценку рисков. С помощью мозгового штурма, в котором должны участвовать члены вашей команды, постарайтесь выявить факторы, мешающие реализации проекта или замедляющие ее ход, заставляющие расширять рамки ранее определенного бюджета, а также препятствующие выполнению сформулированных требований. Затем продумайте способы снижения указанных рисков. «Остановившись на некоторое время и оценив существующие риски, можно составить весьма полезный список, — заметил Коппельман. — Это не займет много времени, но зато поможет получить представление о возможных подводных камнях, прежде чем они возникнут на вашем пути».

Ошибка № 11: Дефицит времени, выделяемого на управление изменениями.

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

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

Ошибка № 12: Незавершенность графика проектов.

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

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

Проблемы взаимодействия

Ошибка № 13: Нереальные сроки проекта, которые ИТ-специалисты не в состоянии изменить.

Проявление: ИТ-специалисты не справляются с поставленными задачами, за ними закрепляется репутация людей, не умеющих завершать проекты в установленные сроки.

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

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

Ошибка № 14: Недостатки взаимодействия со спонсорами проекта и заинтересованными в его реализации лицами.

Проявление: Предложенная техническая реализация не отвечает ожидаемым требованиям.

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

«Возможна также ситуация, при которой одна из сторон в процессе взаимодействия изъясняется на языке, совершенно непонятном другой стороне, — заметила Кондо. — В конце концов раздосадованные ИТ-специалисты восклицают: “Но ведь мы обо всем этом говорили. Почему же полученный результат не удовлетворяет конечного пользователя?”»

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

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

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

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

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

Meridith Levinson. The 14 Most Common Project Management Mistakes. CIO.com. 07/23/2008

Илья Едигарьев, руководитель Департамента внедрения компании «Адванта Консалтинг»

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

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

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

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

А почему нет?

• Для начала сформулируйте, какие именно проблемы вы хотите решить. Что исправить? Действительно ли вопрос в управлении вашими проектами и задачами? Убедитесь – с нашей помощью или самостоятельно – что приобретаемый продукт на самом деле вам подходит, что он способен решить ваш круг проблем. Не стоит покупать систему только потому, что у вашего конкурента или партнера она уже есть (и у него, условно, все хорошо).
• Никакая информационная система в ближайшем будущем не заменит компетентного руководителя – она будет только предоставлять данные для принятия решений, а принимать решения предстоит вам, и никому другому. Увы, нужно признать, что иная картина пока остается в области научной фантастики.
• Если вы все это осознаете, важно принять еще один факт: момент приобретения системы – только начало большого пути. Даже если вы сотрудничаете с нами (или другими консультантами – ну, это навряд ли), не стоит забывать, что это только ваша компания и ваши процессы. А если уж совсем честно – то это ваше внедрение. Консультант ведь потому так и называется, что только помогает и советует. Успех зависит только от вас.

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

Часто автор составляет требования к системе, основываясь не на реально работающем процессе в своей компании, а на некоем идеальном представлении о нем. Кажется, так и должно быть? Идея верная, но у вас есть шанс получить список требований, под который вы не сможете найти продукт.

Как же быть?

• Для начала сверьтесь со списком целей и проблем, который мы с вами подготовили в первом пункте. Все требования должны быть нацелены на решение этих проблем. Что не нацелено – отметайте.
• Без крайней необходимости не закладывайте ничего на перспективу: сейчас функция не нужна, но вдруг что-то поменяется? Давайте отметем это «вдруг» и будем помнить, что жизненный цикл любой автоматизированной системы управления в компании редко превышает 5 лет. Как бы это ни было грустно для производителей.
• Аккумулируйте лучшие практики, но берите из них только необходимый минимум. Помните, что тот же самый PMBoK – это свод знаний, а не буквальное руководство к действию. Блеснуть знаниями у вас, наверняка, еще будет повод.
• Постарайтесь спроектировать такую систему, которую вы сможете запустить в реальные короткие сроки. Снова вспомним предыдущий пункт: внедрять – вам.

3. Объять необъятное: заказчик хочет всего и сразу. В знаниях об управлении проектами несколько областей: управление сроками, стоимостью, качеством и так далее. Точно также любая внедряемая система имеет модули или функциональные блоки, близкие по смыслу. С чего начать? Заказчик знакомится с возможностями системы, ему нравится все, ограничить рамки крайне трудно.

Как расставить приоритеты?

• Обязательно двигайтесь поступательно: определите пилотную зону и очередность внедрения функциональных блоков. Не пренебрегайте этапами тестирования и опытной эксплуатации, даже если внедряете простые функции.
• Начните с максимально упрощенного процесса – так будет легче работать с пользователями. Ведь даже при их высокой лояльности избежать сопротивления не удастся.
• При внедрении системы Advanta мы выделяем так называемые «Базовые процессы УП»: это управление проектами по контрольным точкам с отдельными функциями управления коммуникациями и проектным документооборотом. Только после того, как эти процессы у заказчика настроены и запущены, мы считаем возможным расширять контур: управлять бюджетом проекта, усложнять сетевые графики, детально планировать ресурсы и т.п.

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

А как должно быть?

• Снова обратимся к выводам в нашем первом пункте. Дорогие заказчики! Это ваша компания и ваше внедрение. Несмотря на юридически закрепленные обязательства и самые добрые намерения консультантов – мы уйдем, а вы останетесь.
• Мало написать устав и приказ о начале проекта внедрения и назначить в нем роли – нужно всерьез озаботиться тем, чтобы назначенные на эти роли сотрудники (заказчик, РП, аналитики, администраторы, эксперты) смогли участвовать в проекте и считали эту деятельность хотя бы не менее важной, чем привычная операционная.
• Подумайте о мотивации. Любой сотрудник должен понимать, за что он отвечает в проекте, и что – негативное лично для него – произойдет в том случае, если результат не будет достигнут.

5. Неизвестно, чего ждет от проекта реальный заказчик, как он будет оценивать результаты. На проекте нас встречает РП клиента, часто он же инициатор и эксперт в проектном управлении. На просьбу встретиться с директором по развитию или генеральным РП отвечает нам: «Все вопросы – ко мне. Я здесь отвечаю за проекты, и Петр Семенович во всем меня поддержит. Не будем его беспокоить, человек занятой». Проходят месяцы внедрения, на этапе финальной приемки неожиданно появляется Петр Семенович и говорит: «Э, ребята, что-то не то».

Как же так вышло?

• Вполне возможно, что неопрошенный вами топ – действительно не эксперт, и именно в этом проблема. Но вы должны узнать об этом на старте проекта, а не при его завершении. Совсем необязательно безропотно следовать его указаниям: вы всегда можете скорректировать ожидания и договориться о критериях приемки, которые устроят всех. Главное – явно это озвучить и закрепить на старте.
• Очень важно услышать требования, проговоренные самим заказчиком. Даже если у вас подписана тысяча документов, а двух трактовок требований может не быть. Свойство многих руководителей – не принимать никаких результатов без критики. А критиковать свои собственные решения будет уже сложнее.
• Еще одна важная роль высокопоставленного заказчика – поддержка проекта авторитетом. Только он может встать на стартовом совещании и решительно сказать: проекту быть. Пресечь возражения. Регулярно интересоваться результатами проекта. Требовать от сотрудников выполнения обновленных регламентов и процессов даже тогда, когда они не очень значительно влияют на его работу и его решения. Для всего этого заказчик также нужен вам лично. Чем более высокую должность при этом он будет занимать, тем лучше.

Продолжение – во второй части публикации

Четыре основные стадии развития команды описаны в модели командной динамики Брюса Такмена: 

• этап формирования (forming), 
• шторма (storming), 
• нормализации (norming),
• деятельности (performing).

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

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

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

В классификации Такмена иногда выделяют и пятый этап — распад команды (reforming). Когда команда выполнила миссию, очень важно это «зафиналить», то есть принять результат и сказать слова благодарности. «Спасибо вам за отличную работу» — вжух, и команда как бы рассыпалась. Сотрудники остаются взаимодействовать на уровне функций, но команда перестает существовать. Почему? Потому что достигнута цель, вокруг которой они объединились и, собственно, для чего и были командой. 

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

Ошибка №1. Отсутствие работы с идеологией 

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

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

Ошибка №2. Дефицит личного мотива у сотрудников

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

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

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

Ошибка №3. Недостаток внимания к контексту командной ценности

Далеко не все руководители работают с контекстом важности команды и демонстрируют достаточную ценность в глазах ее участников. 

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

Ошибка №4. Не сформировано целевое видение 

В этом случае лидер не придает достаточного значения установке целевого видения — того, к чему команда должна в результате прийти (или не создает единое понятийное поле). Если команда состоит из зрелых, опытных специалистов, то, естественно, у каждого из них свое представление о том, что нужно сделать, чтобы реализовать задачу руководителя. А если в команде таких экспертов 15? 

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

Ошибка №5. Неумение и нежелание обсуждать проблемы 

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

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

Ошибка №6. Не задан или нарушен стандарт командного взаимодействия

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

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

Поверьте: «Детей воспитывать бесполезно, они все равно будут такими, как родители». 

Ошибка №7. Отсутствие четкой дорожной карты 

Руководитель ставит цель, формирует видение и… отправляет команду в свободное плавание — дает им максимальный карт-бланш на действия. 

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

Ошибка №8. Не сформирован единый план реализации проекта в сознании участников

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

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

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

Ошибка №9. Отсутствие нематериальной благодарности сотрудникам

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

Ошибка №10. Непразднование побед 

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

Очень важно на этой стадии остановить рабочую рутину, выдохнуть и сказать сотрудникам: «Ребята, стоп, финал! Сегодня мы празднуем!». Это может быть совместный выезд куда-то, визит в ресторан либо просто бокал шампанского в офисе — не так важно, как, главное — что вы празднуете вместе с командой завершение масштабного проекта и закрепляете удовлетворенность и чувство командной принадлежности. Даже если эти люди с понедельника начнут движение к новой цели, нужно красиво зафиналить реализованный проект. 

---

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

Фото на обложке: Aerial-motion / Shutterstock

Опыт менеджеров Redmadrobot.

Мы, электрические, запускаем проекты с 2009 года, и за 11 лет сформировали сильную команду робоменеджеров. Прокачивать железных помогают боевые задачи и одна из самых сложных — управлять проектом.

Ситуации, при которых появляется необходимость взять на себя обязанности PM (project manager), бывают разные: в маркетинге — при создании сайта, в HR — при организации мероприятий. Мы вспомнили десятки подобных случаев и подготовили список ошибок, которые допускают новоиспеченные руководители проектов.

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

На самом старте

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

Ошибка № 1: отсутствие фиксации договорённостей со стейкхолдерами

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

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

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

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

После формирования документа синхронизируйте его с командой (наверняка вам подкинут ещё пару-тройку идей) и смело отправляйте стейкхолдерам, чтобы финально согласовать все моменты.

Вариант посложнее: железная команда аналитиков и дизайнеров Redmadrobot на этапе старта проекта всегда собирает паспорт продукта — документ с описанием характеристик и основных целей.

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

После этого итоги согласования нужно зафиксировать для всех — разослать письма, выложить документ в облако или создать борд в Miro.

Ошибка № 2: бездумное формулирование целей и задач в команде

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

На выходе мы имеем старое доброе «ничего», а прикрываемся «внешними факторами», «незапланированными активностями» и «кто-то виноват, а мы не подозревали».

Простое решение: вариант для самостоятельного использования — воспользуйтесь одной из проверенных временем методологий постановки задач, например, SMART. Мы часто используем в работе подходы DoD и DoR .

Но проект — дело командное, поэтому, если есть возможность планировать и думать над реализацией всем вместе, её нужно обязательно использовать.

Вариант посложнее: изучите вместе с коллегами одну из методологий постановки задач и грамотно её внедрите. Для этого разделите планирование результатов на несколько итераций, после чего сделайте deep dive (погружение в проект) всей команды по методологии постановки задач.

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

Ошибка № 3: перекладывание ответственности

Здесь всё просто: ответственность и распределение ролей в команде должны быть понятны всем участникам. В какой-то момент (а он точно может наступить, поверьте) придётся разбираться, почему что-то пошло не так и кто-то не выполнил важную задачу.

А в том случае, если в проекте что-то пойдёт не по плану, менеджер должен чётко понимать, в какой его части произошёл сбой. Иначе PM рискует поставить под угрозу результаты работы и деморализовать всю команду.

Одно из лучших решений для создания «прозрачности» — использовать матрицу ответственности. Её можно выбрать исходя из сложности проекта, размера команды и предпочтений.

Простое решение, если не хотите заморачиваться и у вас небольшой проект:

Главное — договоритесь о том, как планируете взаимодействовать в команде и зафиксируйте это любым удобным способом: текстом, в Miro или, например, набросайте mind map — как вам удобно.

Вариант посложнее: для крупных проектов можно сделать ролевую модель проекта в виде карты и добавить описание функций каждой роли (это можно сделать, например, в Miro).

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

По ходу реализации: про реализацию

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

Ошибка № 4: отсутствие инструментов для командной работы

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

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

Простое решение: не гонитесь за модой — используйте доступные и универсальные инструменты, такие как Trello или Google-таблицы.

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

Задача эффективного инструмента — упростить жизнь команде. Trello и Google-таблицы хорошо с этим справляются. Но независимо от ваших предпочтений, есть типы инструментов, которые понадобятся вам в любом проекте: делегирование, встречи или «синки», риск-менеджмент, каналы коммуникации и взаимодействия.

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

Ошибка № 5: отсутствие чётких приоритетов

В ситуации, когда приоритетно всё — на самом деле никаких приоритетов не существует. Если работа кипит и проект развивается, то это ещё не значит, что команда идёт к нужному результату.

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

Простое решение: если у вас небольшой проект, то используйте методологию MоSCоW — она хорошо подходит для определения приоритезации. Также обратите внимание на методологии RICE и ICE.

Вариант посложнее: в крупном проекте поможет формирование собственной системы приоритезации входящих задач. Её можно построить на базе Google-таблиц или Trello.

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

Ошибка № 6: отсутствие контрольных точек и оценки результата

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

Решение:

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

По ходу реализации: про взаимодействие

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

Ошибка № 7: неинформирование команды

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

Решение:

Ошибка № 8: отсутствие реакции на изменения или критичные ситуации

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

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

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

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

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

И в конце

Проект всегда имеет конечные точки и финал. Соберитесь силами и не допустите в них последних двух ошибок.

Ошибки № 9 и № 10: отсутствие рефлексии и подведения итогов

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

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

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

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

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

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

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

У нас получился не самый полный список ошибок, но если вы сможете не совершать хотя бы их, то сделаете работу над проектом проще и эффективнее. Мы, роботы, убеждены, что совершение ошибок — это путь к совершенству, ведь мы постоянно на них учимся. Поэтому, советуем вам не бояться рисковать. А ещё, не забывайте прислушиваться не только к коллегам, но и к самому себе. Согласны?

Проблемы как источники и внутренние элементы проектов

Свежие публикации автора:

Содержание

• 1 Из-за каких проблем возникают проекты?
• 2 Ошибки реализации проектов и сопутствующие проблемы

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

Из-за каких проблем возникают проекты?

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

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

Модель основного отличия корректируемого отклонения от проблемы

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

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

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

Ошибки реализации проектов и сопутствующие проблемы

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

Обратите внимание: ни недостаток выделяемых финансовых ресурсов, ни уровень технологического развития не обозначены источниками ключевых затруднений. Акцент именно на несовершенстве управления. В принципе, вся проблематика, которую можно выявить в крупных проектах, хоть и в меньших масштабах, может быть перенесена на простые задачи. Интересны также исследования, которые были проведены PM Network в 1998 г., повторены в 2005 г. и в более позднее время. Они свидетельствуют, что 46-48% проектов имеют проблемы и чуть менее 28% не доводятся до результата вообще по тем же причинам.

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

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

Состав причин неудач проектов по данным исследований Metagroup («Why Operation Projects Fail?»), 2002 год

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

1. Упущения, связанные с объектом управления. Менеджер берется за проектную задачу, не до конца понимая, в чем состоит его объект (цели, результаты, границы, планы и т.д.).
2. Просчеты, относящиеся к субъекту управления (ошибки в учете интересов участников, в организационной структуре и т.п.).
3. Ошибки, связанные с процессами проекта (оценка рисков, недоработки в коммуникациях и т.д.).

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