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

Небольшая ремарка. Да, я был свидетелем "ванильных" проектов. Это те проекты, где есть полная поддержка со стороны руководства, есть четки рамки проекта, есть хороший "полу-резиновый" бюджет. А также есть внятная команда исполнителей-профессионалов и таких же внятных и заинтересованных Заказчиков. Где все работают "как одна команда". Где есть четкие требования (и Заказчик их действительно детально понимает). Где есть профессиональные разработчики и подрядчики (работающие не первый год и способные с полуслова понять, что от них хотят). Где нет "препонов" и препятствий в вопросах согласования с информационной безопасностью и в вопросах передачу в эксплуатацию и техподдержку. Где у руководителя проекта есть "реальный" рычаг управления в виде полномочий воздействовать (заставлять, требовать, эскалировать и штрафовать) на всех без исключения участников проекта. Да-да. Такие проекты тоже есть. Это идеальный мир "по-PMBOOK". Это розовый мир "веселых пони и бабочек". Про такой мир написано много книг и статей. Так вот, в этой статье мы будем говорить не о них. И не о тех руководителях проектов, которым посчастливилось запускать такие проекты (да они собственно и не поймут о чем я).

Итак, пойдем по порядку, так сказать с самого начала ...

Дзен №1: "Пойми кому из руководства компании нужен этот проект и готов ли он дать тебе волшебную палочку Гарри Поттера"

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

И речь тут идет не о формальном ответе "конечно нужен". Вопросы нужно ставить шире и конкретнее:

• Насколько сильно и для чего лично руководитель компании хочет запустить этот проект?

• Готов ли он лично включаться в решение проблем проекта и не раздражаться от ваших бесконечных эскалаций?

• Готов ли он увеличивать бюджет проекта, если вдруг в середине вы поймете, что забыли про какие-то важные требования?

• Какие последствия будут для руководителя и для компании, если проект не будет запущен?

• Какие полномочия воздействия на команду он готов дать лично вам, т.е. какой силой наделить?

• Готов ли он поддерживать вас в ситуации, когда ваши профессиональные доводы расходятся доводами его подчиненных?

Постарайтесь всеми правдами и неправдами получить ответы на эти вопросы до того, как возьметесь за проект. Это будет тот самый "рычаг воздействия", который вы будете применять на проекте.

Заинтересованность и реальная поддержка руководства - это половина успеха. А ваши полномочия - это та самая "магическая палочка Гарри Поттера", которая позволит вам воздействовать на "дементоров" и защищать своих единорогов. Ваш рычаг воздействия должен позволять применять как минимум два заклинания: атаковать ("Авада Кедабра") и защищаться ("Экспекто Патроннус").

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

Дзен №2: "Не торопись браться за проект, если тебе не дали реальных рычагов управления. Осмотрись, погрузись в его детали, выиграй время на оценку, прежде чем согласиться."

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

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

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

Дзен №3: "Самым успешным всегда является проект, которым не будут пользоваться"

Другими словами, надо выяснить кто будет пользоваться результатами этого проекта. Иногда оказывается, что проекты "для галочки" делаются для 2-3 пользователей. Если это так, то тебе повезло - лови свою удачу за хвост. Начинай активно общаться с ними и погружайся в требования лично и глубоко. Согласись, что пообщаться с парой человек намного проще, чем организовывать сложные процессы сбора требований среди десятка разных департаментов. Смело берись за этот проект, но адекватно оценивай его риски, сроки, объем и ресурсы. Далее все по классике.

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

Но представим, что этот вариант тоже не сработал и "ванильного" сценария опять не случилось. Не паникуй и не предпринимай скоропалительных решений. Прежде чем браться за такой проект постарайся максимально разобраться в нем, откуда он возник, кто его продвигает, кому он нужен, с кем придется работать, насколько профессиональна команда со стороны Заказчика, насколько профессиональна команда со стороны Исполнителя и т.д. Собери максимум информации. Ты можешь справедливо сказать, что "мне нужно собрать больше информации". Зачем это нужно? Выиграть время, чтобы подготовиться и предложить свои условия.

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

Дзен №4: "Пойми ради чего ты берешься за проект, который может испортить твою карму"

Этот очень просто на первый взгляд совет кроет в себе глубокий смысл. Представьте себе, что проект оказался "В ОГНЕ !!!" Сдать в срок не успеваем, Заказчик подливает масла в огонь, Руководство недовольно, требует "реалистичные сроки", а ты (Руководитель Проектов - РП) не понимаешь сколько еще нужно сделать и хватит ли бюджета. Знакомая картина? Да-да - это типичный проект, у которого закончился "конфетно-букетный период" и началась "бытовуха, убивающая любовь".

Прошли все эти ванильные встречи из разряда: старт проекта, формирование команды, сбор первоначальных требований, согласование устава со спонсором, создание плана-проекта, kick-off и т.д. И началась "махровая бытовуха": дедлайны, несоблюдение сроков, отсутствие ресурсов, превышение бюджета, претензии Заказчика в отсутствии контроля, претензии Руководства\Начальства (нужное зачеркнуть) в плохом планировании проекта, претензии Спонсора в плохом планировании бюджета, претензии Управляющего Комитета в плохом управлении рисками и требованиями. Короче, предсвадебные обещания "буду всю жизнь на руках носить" не оправдались и все летит в ....., озаряясь ярким пламенем кипящих котлов преисподней.

И вот тогда все пропускают мимо один простой вопрос:
"А в чем мотивация РП продолжать гореть в этом адском пламени и вопреки всему тащить проект к успеху?" Будь готов к такому варианту, как самурай, который всегда готов к смерти.

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

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

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

Дзен №5: "Согласовывай размер и правила расчет своей будущей проектной премии "на берегу", пока ты еще не вошел в лодку, переплывающую реку Стикс"

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

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

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

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

Дзен №6: "Врага надо знать в лицо: выяви всех возможных блокираторов твоего проекта до старта проекта".

О чем я говорю? О том, что БЛОКИРАТОРАМИ могут быть не только Заказчики.

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

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

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

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

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

Теперь настало время браться за проект. Ты уже многое выяснил и многое знаешь. Все ждут от тебя заявления, что ты берешься за этот проект (ну еще бы, ведь ты 2 раза брал время "проанализировать данные и принять решение"). Как это сделать правильно?

Дзен №7: "Зафиксируй все цели, ограничения, полномочия, рычаги воздействия, требования, участников, риски и договоренности в Уставе Проекта. Только после этого объявляй о том, что готов к его запуску".

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

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

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

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

Чем чаще ты будешь апеллировать к Уставу проекта, тем лучше. Делай это каждый день при любом удобном случае. И даже в случае провала проекта (а мы все надеемся конечно на лучшее) у тебя будет очень крутой козырь в рукаве.

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

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

P.S. Прошу не критиковать за возможные грамматические ошибки, пишу во внерабочее время и без редактора. Стараюсь делать все качественно, но все мы люди. Главное мысль и содержание.

Зачем я это делаю? Я не гонюсь за рейтингом (кто-то набирает его хейтерской критикой - так быстрее конечно, но это не мое). Я искренне надеюсь помочь тем, кому предстоит ступить на этот непростой путь. А еще я хочу собрать обратную связь от тех, кому довелось столкнуться с похожими проблемами. Или они видят, что вот-вот столкнутся с ними и хотят знать где еще "подстелить соломку".

Если какие-то идеи "зацепили" или показались интересным в процессе прочтения, то напишите об этом в комментариях. А еще лучше, если вы подкинете свои мысли, какие еще проблемы могли "подкосить" проект или привели к особенно жестокой схватке. Я их постараюсь разобрать и описать в следующих постах. Или просто поделитесь этой статьей со своими знакомыми - кто знает, может именно это сделает их будущими героями моих статей (мир тесен) :) Dnjhf

Вторая часть уже доступна по ссылке: