PMO решил серьёзно обновить подход к управлению проектами. За год был сделан новый инструмент для ведения портфеля, выполнен переход на обновлённые шаблоны и создан новый процесс согласования изменений.
Каждое из этих нововведений было обосновано, согласовано с руководством и запущено в работу. Коммуникации сотрудникам тоже были запланированы и выполнены своевременно. Разослали письма, провели несколько обучающих сессий.
Через полгода картина следующая. Новый инструмент используют 30% команд, остальные ведут проекты по-старому. Шаблоны формально приняты, но большинство руководителей проектов просто адаптируют старые файлы под новую структуру. Процесс согласования изменений фактически не используется. Люди не понимают, зачем это нужно именно им, и стараются его обойти.
PMO считает, что дело в недисциплинированности и усиливает контроль.
❓ В чём здесь ошибка?
Версии в опросе ниже
#ошибкаPMO
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1🔥1
Правильный ответ: 3. Изменения внедрялись без управления изменениями.
В чём суть ошибки
Письмо с анонсом и обучающая сессия не являются управлением изменениями. Это просто информирование. Разница принципиальная.
Управление изменениями начинается с вопроса: "Почему люди будут сопротивляться?" У каждой группы свои причины. Руководитель проекта не хочет переходить на новый инструмент, потому что уже умеет работать в старом, и переход приведет к его личным потерям времени и комфорта. Функциональный руководитель не видит ценности нового процесса, потому что для него это дополнительное согласование, а не контроль.
Если PMO не разобрался в этих причинах до запуска, обучение и контроль ничего не изменят. Люди будут делать ровно столько, сколько нужно, чтобы не получить замечание.
Как правило, особенно на крупных программах, всегда выделяется отдельный трек управления изменениями, в рамках которого проводится аналитика сопротивления, адресные коммуникации для разных групп стейкхолдеров и явными ответами на вопрос «что это даёт лично мне». Без этих действий даже хорошо спроектированные изменения зависают на полпути.
Вариант 1 про количество изменений, скорее, тактический вопрос, не корневая проблема. Можно запускать несколько изменений одновременно, если каждым из них управлять правильно.
Как исправить
В общем, изменение, которое не сопровождается должным управление изменениями, с высокой вероятностью не будет внедрено и останется намерением.
#ошибкаPMO
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍3❤2
Ко мне наконец доехали книги.
Издательство сильно затянуло по срокам. Тираж должен был выйти в конце марта - начале апреля, но доехал только сейчас.
С задержкой, но от этого не менее волнительно держать в руках свое первое печатное издание.
Ниже кружок с распаковкой😎
Издательство сильно затянуло по срокам. Тираж должен был выйти в конце марта - начале апреля, но доехал только сейчас.
С задержкой, но от этого не менее волнительно держать в руках свое первое печатное издание.
Ниже кружок с распаковкой
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥5🆒2
This media is not supported in your browser
VIEW IN TELEGRAM
🔥8❤1👍1
🎤 Итоги конференции 'Проектное Управление 2026'
На прошлой неделе 24-26 июня прошла конференция «Проектное Управление 2026». Три дня насыщенные докладами, дискуссиями и общением с коллегами.
Мои ключевые выводы и наблюдения из тех сессий, в которых участвовал сам:
1️⃣ В дискуссии «ИИ в деле: практика использования в управлении проектами» обсудили с участниками, какие практики применения ИИ в проектом управлении складываются:
🔘 в основном автоматизируются рутинные задачи (транскрибация встреч, подведение итогов, формулировка задач, обработка почты);
🔘 постепенно начинают появляться виртуальные сотрудники-агенты;
🔘 крупные компании внимательно относятся к утечке информации и предпочитают изолировать модели во внутреннем контуре.
2️⃣ В своем докладе, о котором писал выше, я как раз подробно рассказал о создании безопасного ИИ в контуре организации. Запись доклада уже можно посмотреть здесь.
3️⃣ На финальной сессии мозгового штурма с коллегами жарко обсудили, у кого какие ожидания и потребности от гибридных методов управления:
🔘 такие подходы становятся все более востребованными;
🔘 при этом нужно гибко подходить к выбору метода реализации конкретного проекта, one-fits-all подход уже не работает;
🔘 гибрид у каждого свой: где-то итеративная разработка в рамках вотерфольного проекта, а где-то проекты предназначены для реализации изменений в продуктах.
Конференция прошла, остались впечатления, новые знания и полезные контакты. Ждем следующую!
#пропроекты #развитие
На прошлой неделе 24-26 июня прошла конференция «Проектное Управление 2026». Три дня насыщенные докладами, дискуссиями и общением с коллегами.
Мои ключевые выводы и наблюдения из тех сессий, в которых участвовал сам:
1️⃣ В дискуссии «ИИ в деле: практика использования в управлении проектами» обсудили с участниками, какие практики применения ИИ в проектом управлении складываются:
2️⃣ В своем докладе, о котором писал выше, я как раз подробно рассказал о создании безопасного ИИ в контуре организации. Запись доклада уже можно посмотреть здесь.
3️⃣ На финальной сессии мозгового штурма с коллегами жарко обсудили, у кого какие ожидания и потребности от гибридных методов управления:
Конференция прошла, остались впечатления, новые знания и полезные контакты. Ждем следующую!
#пропроекты #развитие
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍5❤1
Продолжаем серию разборов отчётов по теме Agentic AI. На этот раз рассмотрим совместное исследование MIT Sloan Management Review и BCG "The Emerging Agentic Enterprise", вышедшее в ноябре 2025. В выборку попали 2102 руководителя, 21 отрасль, 116 стран. Впечатляет.
Главный тезис, который меня зацепил: 76% опрошенных воспринимают Agentic AI скорее как коллегу, чем как инструмент.
Это не метафора, скорее, это становится управленческим вызовом. Инструмент настраивают и эксплуатируют. Коллегу нанимают, обучают, ставят задачи, оценивают, увольняют. Агентный AI требует и того, и другого одновременно. При этом никакой существующий управленческий фреймворк для этого не приспособлен.
Авторы выделяют четыре ключевых напряжения, с которыми сталкиваются организации:
Несколько цифр, которые говорят об организационных последствиях:
Вывод авторов: конкурентное преимущество будет не у тех, кто внедрил AI быстрее, а у тех, кто лучше перестроил организацию вокруг него.
Для PMO это серьезная задача: не ждать, пока вопрос «как работать с агентами» решат команды сами, а выстраивать для этого процессы, роли и управление заранее.
С полной версией отчёта можно ознакомиться здесь. Также выложу документ в комментариях к этому посту.
#пропроекты #технологии #ИИ
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍6❤1🔥1
Новый директор PMO приходит в компанию с обширным опытом. До этого он несколько лет строил проектный офис в другой организации, и там всё получилось. Логика простая: модель уже проверена, зачем изобретать заново.
Он воспроизводит ту же структуру, те же роли, тот же состав комитетов, тот же цикл отчётности, даже названия документов совпадают. Презентация для руководства почти один в один повторяет ту, что сработала на предыдущем месте.
Проходит полгода. Комитеты собираются, но решения на них не принимаются. На новом месте другая культура управления, здесь привыкли решать вопросы иначе. Роли, которые отлично работали в прежней компании, здесь дублируют функции, которые уже выполняет другое подразделение. Отчётность воспринимается как лишняя бюрократия, потому что не учитывает то, как реально принимаются решения именно в этой организации.
Директор PMO уверен, что модель рабочая, просто нужно больше времени, чтобы люди привыкли.
❓ В чём здесь ошибка?
Версии в опросе ниже
#ошибкаPMO
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1💯1
В чём главная ошибка?
Anonymous Quiz
0%
1. Директор PMO выбрал слишком сложную модель для новой организации
0%
2. Команда PMO недостаточно объяснила ценность модели новым коллегам
0%
3. Модель была рабочей, но нужно было внедрять её быстрее, не растягивая процесс
100%
4. Модель скопирована без адаптации к контексту компании
Вопрос в этот раз оказался неожиданно очевидным и наблюдается удивительное единодушие в итогах голосования. Всем спасибо за активность! Разбираем.
Правильный ответ в этом кейсе: 4. Модель скопирована без адаптации к контексту компании.
В чём суть ошибки
Модель PMO - это не набор ролей и документов сам по себе. Ее необходимо адаптировать к контексту конкретной организации с учетом культуры принятия решений, зрелости управления, структуры власти, исторически сложившемся процессам. Успех модели в одной компании доказывает, что она подошла тому контексту, но ничего не говорит о том, подойдёт ли она в другом месте.
Когда модель переносится без адаптации, она начинает конфликтовать с тем, что уже есть в окружении компании. Комитет дублирует орган, который решает те же вопросы немного иначе. Отчётность не совпадает с тем, как реально движется информация в организации. Роли пересекаются с уже существующими функциями. В результате происходит не отторжение идеи PMO как таковой, а отторжение конкретной, плохо подогнанной конструкции.
Именно поэтому в исследованиях по внедрению PMO прямо звучит принцип: «адаптация, а не копирование». Даже проверенный зарубежный или чужой корпоративный опыт нужно перерабатывать под специфику конкретной организации, а не переносить буквально.
Как исправить
В общем, чужой успешный опыт - это ценный источник идей, но проектное управление имеет дело с конкретными организациями, а не с их идеальным образом. Модель либо подогнана под контекст, либо не работает, независимо от того, насколько хороша она была в другом месте.
#ошибкаPMO
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6💯1
🌍 Как управлять тысячей людей в 11 странах и не сдохнуть потерять нить
Следующий кейс из списка, по которому голосовали, самый масштабный из четырёх. И, пожалуй, самый показательный с точки зрения того, как устроено управление на пределе сложности.
2015 год. Ericsson выигрывает глобальный тендер на реализацию крупнейшей в индустрии программы BSS-трансформации для группы VEON. Тогда это был Vimpelcom International с дочерними операторами по всему миру. Задача стояла амбициозная: унифицировать ИТ и внедрить цифровой стек для автоматизации систем поддержки бизнеса сразу для 10 операторов группы, а затем продолжить его эксплуатацию силами Ericsson. Бюджет на все веселье $1 млрд. Команда программы со стороны Ericsson в итоге составила около тысячи человек из более чем 20 стран.
Я участвовал с самого начала, с этапа тендера. Когда его объявили, в Москву на подготовку тендерной заявки и документации очень быстро стали съезжаться эксперты со всего мира. Поскольку компания международная, их и до этого было много, но тут просто весь офис заполнился новыми людьми.
Для Ericsson это была знаковая программа, поскольку сделали ставку на внедрение совершенно новых систем, которые ещё предстояло написать. Из-за этого в команду собирали лучших из лучших по всему миру. В Европу стали возвращаться ребята, которые годами жили в Штатах, работая на крупных программах для американских операторов. Было непонятно, возьмут ли в команду кого-то из России. А поучаствовать в такой уникальной движухе очень хотелось.
В итоге, взяли и за три года я последовательно возглавлял сначала подпрограмму Евразия (7 стран), затем подпрограмму Россия, а потом перешёл в проектный офис всей программы глобально. То есть видел эту историю изнутри с разных уровней.
Почему это было важно для VEON стратегически? Группа ставила на эту программу серьезную ставку на снижение IT-затрат в масштабе всего бизнеса глобально. Если бы это не получилось, пришлось бы пересматривать финансовые показатели группы и, возможно, саму стратегию ее развития. Ставки были максимальными.
Теперь про сложность. Представьте, в нашей команде тысяча человек из двадцати с лишним стран. У каждого оператора со стороны заказчика свой стек IT-систем, своё законодательство в каждой стране, свои уникальные процессы, локальные люди, которые в большинстве своем совершенно не горят желанием что-то менять. Плюс разные часовые пояса, языки и культуры. И при этом нужно внедрять одну платформу везде одинаково. При таком количестве вовлеченных людей и заинтересованных сторон можете представить, какая неразбериха зачастую творилась в коммуникациях.
Без чёткой структуры управления такая конструкция рассыпается сама собой, даже без значительного внешнего воздействия. Каждая страна начинает тянуть реализацию общего решения в свою сторону, локальные команды оптимизируют процессы под себя, а не под общую цель. В итоге вместо единой платформы получаешь 10 немного разных решений и весь глобальный смысл программы теряется.
Мы выстроили трёхуровневую модель управления. Во главе всего стояло центральное руководство программы. Были созданы общие команды, которые реализовывали решение по принципу «сделай один раз, разверни везде». Далее все подхватывали локальные команды внедрения в каждой стране. Прежде чем разворачивать решение на 10 операторов, сделали пилот в Грузии: небольшой оператор (по сравнению с другими странами), управляемые риски, возможность отработать модель внедрения и эксплуатации в реальных условиях.
Пилот прошёл успешно. Модель управления подтвердила жизнеспособность. Дальше началось масштабирование, которое, конечно, проходило не столь гладко, как хотелось бы. Программу в итоге завершили для большинства операторов группы. Часть из них вышла из скоупа, но это отдельная история.
Из этого кейса я вынес урок: в таких программах главная задача не управлять людьми, а создавать операционную моделью системы, в которой эти люди работают. Если модель правильная, вся команда движется в одну сторону. Если нет, никакое ручное управление не поможет.
Предыдущий кейс: MTS Hybrid TV
#пропроекты #свойопыт
Следующий кейс из списка, по которому голосовали, самый масштабный из четырёх. И, пожалуй, самый показательный с точки зрения того, как устроено управление на пределе сложности.
2015 год. Ericsson выигрывает глобальный тендер на реализацию крупнейшей в индустрии программы BSS-трансформации для группы VEON. Тогда это был Vimpelcom International с дочерними операторами по всему миру. Задача стояла амбициозная: унифицировать ИТ и внедрить цифровой стек для автоматизации систем поддержки бизнеса сразу для 10 операторов группы, а затем продолжить его эксплуатацию силами Ericsson. Бюджет на все веселье $1 млрд. Команда программы со стороны Ericsson в итоге составила около тысячи человек из более чем 20 стран.
Я участвовал с самого начала, с этапа тендера. Когда его объявили, в Москву на подготовку тендерной заявки и документации очень быстро стали съезжаться эксперты со всего мира. Поскольку компания международная, их и до этого было много, но тут просто весь офис заполнился новыми людьми.
Для Ericsson это была знаковая программа, поскольку сделали ставку на внедрение совершенно новых систем, которые ещё предстояло написать. Из-за этого в команду собирали лучших из лучших по всему миру. В Европу стали возвращаться ребята, которые годами жили в Штатах, работая на крупных программах для американских операторов. Было непонятно, возьмут ли в команду кого-то из России. А поучаствовать в такой уникальной движухе очень хотелось.
В итоге, взяли и за три года я последовательно возглавлял сначала подпрограмму Евразия (7 стран), затем подпрограмму Россия, а потом перешёл в проектный офис всей программы глобально. То есть видел эту историю изнутри с разных уровней.
Почему это было важно для VEON стратегически? Группа ставила на эту программу серьезную ставку на снижение IT-затрат в масштабе всего бизнеса глобально. Если бы это не получилось, пришлось бы пересматривать финансовые показатели группы и, возможно, саму стратегию ее развития. Ставки были максимальными.
Теперь про сложность. Представьте, в нашей команде тысяча человек из двадцати с лишним стран. У каждого оператора со стороны заказчика свой стек IT-систем, своё законодательство в каждой стране, свои уникальные процессы, локальные люди, которые в большинстве своем совершенно не горят желанием что-то менять. Плюс разные часовые пояса, языки и культуры. И при этом нужно внедрять одну платформу везде одинаково. При таком количестве вовлеченных людей и заинтересованных сторон можете представить, какая неразбериха зачастую творилась в коммуникациях.
Без чёткой структуры управления такая конструкция рассыпается сама собой, даже без значительного внешнего воздействия. Каждая страна начинает тянуть реализацию общего решения в свою сторону, локальные команды оптимизируют процессы под себя, а не под общую цель. В итоге вместо единой платформы получаешь 10 немного разных решений и весь глобальный смысл программы теряется.
Мы выстроили трёхуровневую модель управления. Во главе всего стояло центральное руководство программы. Были созданы общие команды, которые реализовывали решение по принципу «сделай один раз, разверни везде». Далее все подхватывали локальные команды внедрения в каждой стране. Прежде чем разворачивать решение на 10 операторов, сделали пилот в Грузии: небольшой оператор (по сравнению с другими странами), управляемые риски, возможность отработать модель внедрения и эксплуатации в реальных условиях.
Пилот прошёл успешно. Модель управления подтвердила жизнеспособность. Дальше началось масштабирование, которое, конечно, проходило не столь гладко, как хотелось бы. Программу в итоге завершили для большинства операторов группы. Часть из них вышла из скоупа, но это отдельная история.
Из этого кейса я вынес урок: в таких программах главная задача не управлять людьми, а создавать операционную моделью системы, в которой эти люди работают. Если модель правильная, вся команда движется в одну сторону. Если нет, никакое ручное управление не поможет.
Предыдущий кейс: MTS Hybrid TV
#пропроекты #свойопыт
🔥7👍6❤1
Ура! 🎉
Спешу поделиться радостной новостью и достижением. Наконец пройден новый этап и вчера я получил сертификат IPMA Level A в домене управления программами.
Этот путь неожиданно занял почти год и потребовал заметных усилий по подготовке и формированию комплекта документации, особенно отчета. Но все было не зря и цель достигнута. Теперь к моему набору PMI PMP, PgMP, PfMP добавился еще один топовый сертификат😎
Если интересно, как это было, ставьте реакции. Наберем 20+ лайков и огоньков, расскажу подробнее👍
📲 MAX | 📱 LinkedIn
#сертификация #развитие
Спешу поделиться радостной новостью и достижением. Наконец пройден новый этап и вчера я получил сертификат IPMA Level A в домене управления программами.
Этот путь неожиданно занял почти год и потребовал заметных усилий по подготовке и формированию комплекта документации, особенно отчета. Но все было не зря и цель достигнута. Теперь к моему набору PMI PMP, PgMP, PfMP добавился еще один топовый сертификат
Если интересно, как это было, ставьте реакции. Наберем 20+ лайков и огоньков, расскажу подробнее
Кстати, у кого-то ещё есть такой набор сертификатов от PMI и IPMA? Или знаете таких людей? Было бы интересно познакомиться. Напишите в комментариях👇
#сертификация #развитие
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥24👍13❤1
Друзья, моя статья в недавно вышедшем сборнике ‘ПРО Команду’ посвящена обзору методов управления командами ИИ-агентов и гибридными командами.
Мне интересно понять, в каком направлении дальше развивать эту тему. Поэтому буду признателен за идеи. Пишите в комментариях ваши мысли и предложения по этому поводу.
Авторам трех наиболее интересных предложений отправлю в подарок экземпляр книги с автографом и пожеланиями✍️
Жду ваши комментарии!👇
#развитие
Мне интересно понять, в каком направлении дальше развивать эту тему. Поэтому буду признателен за идеи. Пишите в комментариях ваши мысли и предложения по этому поводу.
Авторам трех наиболее интересных предложений отправлю в подарок экземпляр книги с автографом и пожеланиями
Жду ваши комментарии!
#развитие
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍6❤2👌2