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

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

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

Небольшое примечание: эта заметка не для стартапов. Это всё про большие компании, в которых время от времени какую-то часть работ пытаются организовать в виде проектной деятельности. Речь о так называемых внутренних корпоративных проектах, в которых заказчиком является какой-нибудь отдел (слишком инициативный сотрудник). Надо что-то поменять? – Отлично, объявляем новый проект по созданию светлого будущего!

Да, и еще: текст написан с известной долей иронии и самокритики (признаюсь, тяжко далось), поэтому комментарии типа «умник нашелся» не принимаются. Да, умник. Да, нашелся.

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

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

1. Это никакой не проект. Небольшая задача, группа работ, а то и вовсе процесс развития продукта, но не проект. В общепринятом понимании проект – это «временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов» (определение из PMBOK, но большинство других методологий говорит нам то же, только несколько другими словами). Не надо путать с процессом, с операционной деятельностью, рутинными задачами, решаемыми в рабочем порядке и т.д.
2. Проект в организации, где никто не понимает, что такое проект. В среде, в которой вся деятельность какая угодно, но только не проектная, где отродясь никто не организовывал работы проектным способом, особенно в строго функциональных организациях, очень сложно донести до руководства, что проект – это не просто список задач на листочке с подписью главбосса.
3. Управленческий хаос. Типично для компаний с несколькими слоями управления, например: функциональное, горизонтальное-продуктовое, горизонтальное-региональное и т.д. В теории это называется матричной организацией. На практике, начиная с какого-то момента, сотрудники прекращают понимать, какие работы приоритетны, а какие нет, из какой плоскости управления какие задачи выполнять, а какие отложить, кому отчитываться и зачем. Я работал однажды в такой компании. Два года работы в организации, где проектный менеджмент отсутствует как таковой, и, в то же время, амбиции топ-менеджеров выдают на-гора все новые и новые заказы отделу информационных технологий, в общем, отличнейший материал для статьи на тему «как не надо организовывать проектную деятельность»… Начиная с топ-менеджмента и заканчивая рядовыми сотрудниками никто не понимал толком, за что отвечают, какие задачи в данный момент важны, что будет через неделю. Планированием ресурсов каждый менеджер занимался отдельно, о централизованном управлении ресурсами и проектным портфелем никто даже и не заикался. Пригласили руководить большим проектом, а в действительности оказалось, что никаких проектов и близко нет, в организации попросту отсутствует проектная деятельность хоть в каком-то виде. Полный управленческий бардак: с какого-то момента матрица превратилась в бессистемное, постоянно меняющееся управленческое болото. (Здесь я немного рассуждаю на эту тему.)
4. Исполнительная дисциплина отсутствует (на всех уровнях). Без комментариев. Вы можете планировать что угодно и как угодно, всем плевать. «Вас не устраивает, как я работаю? Обещал сделать за неделю, прошло уже три, а воз и ныне там, так это потому, что меня отвлекали, потом я заболел, а затем ушел в отпуск. Я крутой программист, в  соседнем банке отличные вакансии, будете давить – завтра же заявление шефу на стол.»
5. Проект есть, ресурсов нет. Точнее,  вот так: есть сто пятьсот проектов и две-три проектные команды. Даже если ваши сотрудники будут работать по ночам и в выходные, у вас так и останется сто пятьсот проектов в очереди, а текущие проекты увязнут в мультизадачности. А ведь людям еще и операционной деятельностью заниматься, рутиной всякой там, отчетами функциональным менеджерам, и новых сотрудников учить надо, и время «на подумать» должно остаться… Работу делают люди; нет людей – не стройте иллюзии и не планируйте воздушные замки.
6. И вообще, поставленные условия невыполнимы. (Например, проектный треугольник редуцировался в линию, а то и в точку). Заведомо невыполнимая задача, но попытаться надо же, не сидеть же сложа руки!
7. Нет руководителя проекта. Задачи поставлены, цели ясны, отделы знают, что делать, но центрального пульта управления нет. Думаете, так не бывает? См. снова п.3 – мне довелось как-то поучаствовать в нескольких таких проектах, которыми никто не управлял, просто как-то само собой куда-то двигалось. Шли месяцы, плавно переваливавшие через годы, а проект (который на самом-то деле и не проект) длился и длился. Не смешно даже.
8. Руководитель есть. И еще один. И еще. Несколько руководителей отвечают за одну задачу. Ну-ну. Один проект и несколько (зачастую, меняющихся) руководителей. И ответственных, конечно же, тоже несколько. Кстати, чем сильнее горят сроки, тем больше шансов, что главным и единственным ответственным останетесь именно вы, остальные руководители с радостью займутся другими проектами. На мой взгляд, это недопустимо, но распространено сплошь и рядом. Наполеон говорил: «Один плохой главнокомандующий лучше двух хороших». Так и есть, будьте внимательны, не давайте руководить одной задачей более чем одному человеку, как бы им ни хотелось.
9. Не определены или не согласованы роли всех участников проекта (члены команды проекта, привлеченные эксперты, подрядчики, заказчик, пользователи создаваемого продукта и проч.) Каждый должен четко знать, понимать и подтвердить, за что он отвечает в проекте, чем занимается и что от него ждут другие. К примеру, программисты ожидают спецификацию требований от владельца продукта. Он-то знает об этом? Вообще, понимает, что он будет делать в проекте? А начальник отдела, заказавшего новую информационную систему, знает, что в рамках проекта его сотрудникам придется принимать участие в тестировании, в обучении и т.д.? Это все прописано в уставе проекта? Было ли согласовано в процессе инициации (см. ниже)? Или проект сюрпризом свалится на голову менеджерам?
10. У руководителя проекта нет полномочий. Ты должен руководить, но никто про это не знает. Никто и не шевелится что-то делать. Обычно это потому, что проект официально не инициирован (см. след. пункт).
11. Вам дали неутвержденный проект. Проект вроде как есть, но что это конкретно, зачем, кому это надо и какой у всего это приоритет, никто не знает. Соответственно, проекта как бы и нет. Соответственно, всем плевать, особенно тем, с кем вы торгуетесь за ресурсы. Ничего не знаем, впервые слышим, у самих дел невпроворот. Проект должен пройти стадию инициации, иначе вы – никто и деятельность ваша – ничто. Пропишите максимально все, что должно быть утверждено и согласовано, в хартии (меморандуме) проекта. Пусть с ней ознакомятся все, кто имеет отношение к проекту. И, разумеется, в самом конце документа должна стоять большая размашистая подпись самого главного чувака.
12. Проект не нужен. Нет сформулированной цели, задач и (это вообще общее место) нет обоснования. «Давайте просто чего-нибудь поделаем, потому что иначе зачем мы занимаем эту должность. Сколько стоит? Зачем будем тратить деньги? Что получим в итоге? Как это согласуется со стратегией развития компании? – Да какая разница!» Если нет целей и обоснования, не могут быть определены и приоритеты, соответственно, о планировании ресурсов не может быть и речи.
13. Никто не знает, что надо сделать и как. Сделай то, не знаю что. Вы не сможете эффективно планировать проект, если не определены рамки проекта, продукт проекта и содержание работ. Не знаете, что будете делать? Как будете делать? Это несерьезно, ребята. Пропишите в уставе WBS (структура работ), дайте критерии достижения целей и выполнения задач, опишите продукт и то, как вы его собираетесь строить. А, вижу, вижу, у фанатов скрама и канбана загорелись глаза, я посягнул на священную корову! Пожалуйста, не называйте agile-development проектом. Гибкая разработка – это или часть проекта (итеративная разработка технического решения) или обычный процесс непрерывного улучшения уже имеющегося программного продукта. Прекрасно понимаю, что подобный подход имеет место быть, но тогда и жизненный цикл управления проектом должен быть осознанно выбран соответствующим, см. последний пункт.
14. Решение не выбрано, но проект уже вовсю планируется. Ну-ну… Бывает и такое. Проект объявлен, высокое начальство дало добро, вот только никто не понимает, а что же мы все-таки создаем, своими ли силами, или может закупим готовое, как это все должно работать. Другими словами, не выбрали решение до инициации проекта. И что же мы планируем?
15. Продукт проекта в вакууме. Разработали систему, запустили, оказывается, решаемая с ее помощью задача уже решается в другой информационной систему. Более того, новая программа не может нормально работать, потому что никто не учел, что компания собирается сменить некоторые узлы инфраструктуры на более современные, которые не поддерживаются нашей программой! Создаваемое решение (техническое, организационное, бизнес-модель) должно быть согласовано со стратегией развития организации. Разрабатывая новый продукт или услугу, внедряя новые бизнес-процессы, технические решения, помните, что все, что вы делаете, происходит не на пустом месте, в вакууме. Вы зависите от других, как и другие от вас, ваших решений.
16. Жизненный цикл проекта не определен или выбран неправильно. Здесь все просто: в общем случае схема жизненного цикла управления проектом выбирается, основываясь на двух факторах: наши первоначальные знания о том, каким должен быть продукт проекта, и каким должен быть процесс создания продукта. То есть, в зависимости от того, можем ли мы определить заранее содержание работ, по-разному будут проходить процессы управления. Линейно, итеративно, адаптивно? Какие части продукта мы можем заранее специфицировать, а для каких будет необходима R&D фаза? Понимают ли все участники проекта, как будет происходить создание продукта?  В зависимости от выбранного жизненного цикла меняются способы и горизонты планирования работ; в курсе ли функциональные менеджеры, что вы запланировали адаптивную разработку программного обеспечения? Понимает и принимает ли это заказчик?..

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

Кстати, насчет истории, вот фото американской баллистической ракеты Polaris. В процессе создания этой ракеты в 1957 году придумали метод критического пути.