Последние 14 лет я работаю в крупных корпорациях. Так случилось, что за это время сменил много ролей, должностей и даже локаций. И на каждой позиции я в той или иной мере вовлекался, участвовал или полностью управлял проектами. Причем проекты были самого разного характера: от тестирования новых материалов или запуска аналитической системы в диджитал-медиа до полноценной реструктуризации организации на 300+ человек.
Казалось бы, логично будет рассказать о кейсах успешных запусков, побед и какие инструменты мне пригодились (об этом я, кстати, писал). Но правда заключается в том, что любой, даже самый успешный проект делал мне, как проджект-менеджеру, больно. Несмотря на весь опыт, инструментарий, сильные команды находились слабые места, в которые злобный проект бил точно, сильно и с максимально разрушительными последствиями.
В этой статье я напишу о 5 способах проекта треснуть тебе так, что будет очень сложно подняться, и попробую рассказать, как этой боли избежать. Всем тем, кто ни разу не ошибался и всегда исключительно успешен и превращает в золото все, до чего дотрагивается, — статья будет нерелевантна, так что не тратьте нервы и силы. Для остальных — смотрим, от чего бывает особенно больно.
Наличие логики, цифр, денег и здравого смысла — этого недостаточно. Любая идея может быть зарезана… просто потому что
Возможно, это станет поводом для возражений типа: «Надо нормально готовиться, считать, продавать, рассказывать и т. д.» Очевидно, что до того, как вступить на героическую тропу реализации проекта, его концепцию, бюджет, команду надо согласовать и получить благословение от тех, кто принимает решения.
Для того чтобы не изобретать велосипед, имеет смысл использовать формат project charter как документа, суммирующего всю предварительную работу, оценку команды, расчет денег. Понятно, что комплексная подготовка и правильное структурирование всей документации в понятный формат — это базовое ожидание. Без этого всего ты не то что согласование не получишь, а скорее просто «получишь» от топ-менеджмента, чье время ты бездарно занял. Но даже после того, как ты подготовленный, уверенный в себе, причесанный и полностью готовый ко всему приходишь защищаться, то получаешь «нет».
Из жизни. Пару лет назад мы пытались изменить цепочку поставок на ряд материалов и поменять перевозчиков, чтобы сократить время в транзите, объем разового заказа и, главное, сэкономить сумму с большим количеством нулей. Под это все нарисовали план и прикинули, кто из разных команд что должен делать. При этом ребята-исполнители из смежных команд, кому делать физическое внедрение, подтвердили, что вообще не вопрос и сделают без проблем. Мы пошли с этим к одному из топов, который формально должен был сказать «ОК». Казалось бы, что может пойти не так? Нас разворачивали 5 раз! Аргументы варьировались от «непонятно, как посчитано» до «это сейчас не приоритет и нет ресурсов». И сколько бы мы ни присылали расчетов, ни рассказывали, что вот, ребята готовы это сделать, — эффект был нулевой.
Почему такое происходит? Да полно причин: нежелание вникать или принимать решение, загадочные личностные мотиваторы (которые приходится раскапывать), режим «не хочу я к своим подчиненным ходить и говорить про допработу», мысли заняты чем-то еще… Короче, много всего, что к реальному бизнесу не имеет никакого отношения. Все это вызывает шок проджект-менеджера и начисто убивает мотивацию.
Можно ли с этим что-то делать? Есть способы такие, чтобы проект сдвинуть и чтобы себя с ума не свести. Например, можно попробовать вовлечь более высокий уровень принимающего решение. Моя история, кстати, со счастливым концом. Я в итоге продал этот проект вице-президенту, а он одним звонком «смотивировал» до этого не желавшего принимать решение подчиненного. Да, ситуация «рука-лицо» и выглядит как пожаловаться маме, но срабатывает.
Вариант, который нельзя сбрасывать, — продолжать делать заходы. Вода камень точит. Только не надо таскать одни и те же аргументы, ожидая новый эффект. Старайся понять и адресовать то (пусть даже кажется бредом), что останавливает человека от принятия решения. И планомерно капай на мозги.
Ну и чтобы не свести себя с ума. Прими факт того, что не все объясняется логикой. Получил вопросы / аргументы, от которых хочется биться головой об стену? Спокойно и понимающе покивай, даже запиши, скажи, что классный вопрос. Проработай и вернись. Или сделай вид, что ушел работать над этим. Людям нужно время и понимание того, что их мнение капец какое важное. Будешь спорить — усложнишь жизнь проекту, а себе нервы истреплешь.
Денег всегда или слишком много, или слишком мало. Финансы — это тонкая материя
Помню, в самом начале карьеры я с максимальной ответственностью относился к просчетам финансов проекта, чтобы не заложить лишнего и все было прям как надо. Ну а что, это же компанейские ресурсы? Тогда умудренные опытом проджекты смотрели на меня с сочувствием, ибо знали, на что я нарвусь. Вот два незыблемых постулата, на которых все строится.
Первый: на этапе согласования проекта ты всегда получишь challenge по бюджету. У менеджмента такая работа — дать дополнительный… стимул подумать и найти возможности для улучшения. Поэтому первым делом, чтобы не вступать в бесконечные споры, тебе придется искать, что и где можно подрезать. А нужны ли все эти командировки? А можно поменьше людей? А точно нужно все тесты проводить? И так далее. В итоге будь уверен: ты не уйдешь с заявленным бюджетом.
Второй: в ходе проекта, даже если ты божественно все распланировал, что-то пойдет не так. И чаще всего это самое «что-то» может находиться вне зоны твоего прямого влияния. На моей памяти были срывы поставок запчастей, внезапное увольнение сотрудников, потерянные документы в недрах различных проверяющих органов, много чего. И чтобы проект не сошел с рельсов, приходится в срочном порядке проявлять гимнастическую гибкость и либо искать с нуля, либо (если заранее продумал) активировать запасной план.
Проблема в том, что практически всегда План Б дороже или запарнее, иначе бы он был бы Планом А. Поэтому приходится платить. Ну и в целом, все склонны ошибаться и забывать, а потом это «что-то» окажется критичным для проекта — и придется искать деньги.
Так, бывали случаи, когда при проектировании установок (у одного из партнеров) инженеры вроде все сделали правильно, но не до конца точно указали тип фильтров. В итоге приехали прекрасные запчасти, но, к сожалению, не подходящие для нашего проекта. В срочном порядке пришлось переделывать, а это повлекло доп. затраты, за которые по голове никто не гладит. Не самое приятное мероприятие для проджекта — приходить под конец проекта и просить еще немножко денег.
Можно ли с этим бороться? Везде соломку не подложишь, но есть метод, когда ты закладываешь немного contingency (запаса прочности, если по-русски). Обычно это 15–20% в зависимости от сложности и непонятности проекта. И под это очень желательно иметь хорошие аргументы.Такой буфер дает проектной команде некую свободу маневра и снижает страх быть казненной за перетрату рубля, но и держит в тонусе, так как запас денег лимитирован и просить больше будет уже совсем плохо. Ну и бонусом: если все пойдет по плану, проджект сможет радостно продемонстрировать экономию в ходе проекта, что всегда приятно.
Единственное, планируя буфер, не надо пытаться положить туда 50%+. Одобритель, если он с трепетом относится к финансам, скорее всего, разнесет вас как человека, который очень плох в планировании.
У меня идеальный план проекта, я учел все. А вот и нет. Точно что-то забыли, причем скорее всего что-то из юридического
Был потрясающий случай, когда из-за требований к типу здания (а вернее из-за того, что требования не учли), которое являлось частью проекта, все сдвинулось на 9 месяцев. Я помню потерянные лица участников проекта, которые до конца не могли поверить, что, несмотря на 90% готовность, вся их работа встала колом. Это случай из практики одного моего приятеля, который еще долго оправлялся от такого удара и долго вопрошал: «Да как же так? Мы же все проверяли».
Было ли что-то подобное у меня? Безусловно. Люди забывали, забивали, не знали про критичные действия, которые потом в лучшем случае требовали денежного вмешательства, а в худшем — сдвигали проект.
Я не буду писать про все факторы, но два моих любимых — «Не подумал» и «И так сойдет». Да, постфактум можно (и часто нужно) применить карательные меры, но кому от этого легче в разрезе релиза проекта? Вообще никому, а особенно проджекту, который является основной точкой контакта со стороны менеджмента.
Поэтому я для себя, чтобы минимизировать риск таких неприятностей, взял 2 правила.
Первое — задавай вопросы, чтобы понять суть действия. Вот человек мне говорит: «Надо провести тесты материалов. Займет 3 месяца». Есть соблазн просто занести в план и потом надеяться, что все ок. А можно начать открывать этот ящик Пандоры и задавать вопросы: «ОК, а какие в процессе этапы?» или «А кто конкретно и что будет делать?». Практически всегда, когда закапывался в детали, я мог найти что-то, про что забыли, или возможности для сокращения сроков.
Второе — делай проверку на «вменяемость» плана. Да, если ты грамотно собрал группу, то скорее всего она обладает нужными компетенциями. Но иногда очень здорово получить третье мнение. В моем случае помогало показать план более опытному проджекту или, если речь идет о спецзнаниях, в которых я полный профан, вовлечь людей более высокого уровня с нужной экспертизой. Они просто за счет того, что переживали что-то подобное, могут за один взгляд на твой план отловить то, обо что вся команда потом споткнется.
И вот не надо думать, что лишние вопросы заденут чьи-то чувства, подвергнув сомнению экспертность. Это работа проджекта — сделать так, чтобы проект дошел до финальной точки в нужные сроки при вменяемом бюджете.
А почему ты раньше не озвучивал эти риски? Надо было нас вовлекать, а сейчас мы не можем помочь
Коротко про последние два пинка, которые я просто обожаю. Никто не любит плохие новости, и когда ты вынужденно их приносишь и просишь помощи, то можешь наткнуться на контрреакцию. Она может быть временная, а может быть постоянной с подтекстом: «Сам виноват, ты нам ничего заранее не говорил, вот теперь решай. А у меня лапки». И очень часто твои аргументы о том, что ты что-то когда-то кому-то говорил, будут просто отброшены, в том числе когда ты придешь на суд менеджмента.
Так вот, чтобы у человека не было возможности сказать «Я не видел, я не помню, ничего не докажете», во-первых, на этапе формирования проектного чартера подсвети риски. Если вся команда ее видела и подписалась — твоя позиция будет сильнее.
Во-вторых, провел совещание, встречу, дискуссию — напиши резюме встречи и высылай участникам (особенно если были договоренности). Сейчас еще и всякие ИИ помогут тебе, если ты не мастер эпистолярного жанра. Зато потом, если включится режим обнуления, в рукаве будет козырь, который можно будет использовать во внутренних переговорах. Политика — бе! Но что делать…
Месяц до запуска. Наш план работает. Что может пойти не так
Много чего: глюки систем, поломки на пуско-наладке, транспорт окажется не тот или те там в последний момент. Из последних своих проектов я видел, что последние две недели перед непосредственным стартом, а потом еще месяц «гиперопеки» могут поставить все с ног на голову.
Многие проджект-менеджеры, видя финишную черту, перестают париться и начинают биться обо все мыслимые и немыслимые препятствия. Причем причиной проблемы будет какая-то операционная мелочь, которую ты починишь сегодня, но которая может появиться завтра в новом обличии.
Я наблюдал проект по тестированию материалов, который из-за совершенной ошибки планирования заказов сместился на полтора месяца. Причина была только в том, что кто-то не выполнил маленькое, но очень важное системное действие именно в нужный день. Ну и естественно, менеджмент будет сидеть у вас на шее и очень настойчиво задавать вопросы: «А когда запуск?»
Как метод защиты от таких ударов, я советую переходить в формат ежедневного плана. Он по количеству действий может обогнать сам большой проектный план, так как ты начинаешь следить за всем, что делается.
И каждый день команда собирается на 15 минут (можно даже 2 раза в день), чтобы поставить задачи на ближайшие часы и понять, что произошло с момента прошлой встречи. Фактически, начинаются планерки, которые многие не любят, но которые помогают взять хаос запуска под контроль и не облажаться под самый конец
Очень короткое заключение
Менеджмент проектов — это одна из самых крутых, напряженных и динамичных работ в моей практике. И да, она часто бьет сильно и больно того, кто стоит у руля.
И понятно, что есть еще 101 способ получить жесткий урок в ходе работ над проектом, но те, что я описал, сильно запомнились именно мне и помогли придумать, как сделать так, чтобы это повторялось по возможности реже.
Спасибо за прочтение. Если понравилась статья, то поддержите плюсиком и отправьте друзьям, знакомым и всем заинтересованным.Если Вам интересен бизнес контент и читать про крутые менеджерские кейсы в формате short read, то приходите на мой канал в ТГ
