Работает только то, во что веришь.

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

💡 На эту и другие темы говорили на вчерашнем эфире вместе с нашими клиентами – Ириной Козловской, членом правления коммерческого банка «Хлынов», и Анной Чернышевой, руководителем проектного офиса банка.

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

Когда руководство становится амбассадором новых инструментов, носителем новой технологии, вероятность провала её внедрения становится нулевой.

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

⭐️ Правлением банка проект признан успешным.

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

Смотрите видео на Youtube или в ВК видео.

Читайте все этапы и детали кейса по этой ссылке.

#вебинары #управление_проектами #кейсы

⚡️ Мгновенная карма: что изменится в компании, если счета за ошибки начнут приходить сразу

Недавно во время оформления авиабилета я допустил оплошность, которая обошлась мне в 150 евро (при стоимости билетов в 350 EUR). А именно: при вводе паспортных данных я написал свое имя не как указано в заграннике (Andrei), а с другим окончанием – Andrey.

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

Поэтому я через сайт направил запрос в службу поддержки авиакомпании, которая может сделать корректировку моего имени за 150 евро в обоих билетах. Кстати, после этого инцидента я решил поизучать, сколько стоит такое исправление в других авиакомпаниях – оказалось, что 150 евро это еще очень скромно. Заплатить 200-250 EUR за корректировку имени на билете в одну сторону более, чем реально.

Эта история о том, как одна микроскопическая ошибка моментально выставила мне счет.

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

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

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

Одно дело, когда ты не проверяешь паспортные данные перед оплатой билета и сразу получаешь счет на 150 евро – такая быстрая негативная обратная связь учит тебя на месте.

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

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

Отвечаю на вопрос в заголовке: мгновенное получение счета за каждую ошибку позволило бы компании внедрять изменения значительно быстрее 👍🏻

‼️ Коллеги, 7 ноября в 19:00 приглашаю вас на мой вебинар «8 шагов к гарантированному успеху проектов». Расскажу с кейсами, как адаптированная под компанию (кастомная) технология управления помогает исключать подобные оплошности несоблюдения важных требований.

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

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

#управление_проектами

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

Обычно деятельность компаний описывается в виде бизнес-процессов – логически связанных последовательных шагов. Типовой пример: размещение заказа на закупку, планирование производства, согласование договора… Понятные, последовательные шаги – основа в большинстве корпоративных информационных систем (ERP, CRM и т.д.)

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

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

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

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

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

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

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

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

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

Коллеги, на следующей неделе планирую поделиться с вами итогами года в PMLogix🚀 Киньте реакций, если интересно🔥

#кейсы #управление_проектами

У меня есть принцип – «не иметь дело с ненадежными людьми». А еще у нас в семье есть правило – «за столом без телефона». В чем же разница между правилами и принципами? Можно ли обойтись только принципами или наоборот – только правилами?

Принципы, они же ценности, — это моральные установки, ориентиры, которые помогают принимать решения в тех ситуациях, где нет чёткого алгоритма действий. Это своего рода «моральный компас». Например, в консалтинговой компании McKinsey есть принцип «клиент на первом месте (client first)». И он помогает сотруднику действовать в ситуации, когда запрос от клиента прилетел, например, ночью или перед выходными, чтобы понять, нужно ли соблюдать ожидаемые им сроки ценой отказа от сна и отдыха.

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

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

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

❗️ Но есть и подводные камни. Если действовать исключительно по правилам, можно столкнуться с так называемой итальянской забастовкой. Когда сотрудники начинают выполнять задачи формально, не задумываясь о цели или контексте, результата добиться не выйдет. Вот тут и вступают в игру принципы. 

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

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

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

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

Коллеги, а какие у вас принципы в работе или взаимодействии с другими людьми?

#управление_проектами #методология

Оно вам надо?

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

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

📌 Вопрос 1. Используется ли этот инструмент на самом деле?

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

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

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

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

📌 Вопрос 2. Добросовестно ли мы используем этот инструмент?

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

💡 Если вы используете эффективный по своей сути инструмент, но делаете это недобросовестно, его эффективность под большим вопросом.

📌 Вопрос 3. Насколько результат от использования инструмента окупает вложения?

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

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

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

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

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

#управление_проектами