#проектноеуправление #надежнаяорганизация
🧩 Жизнь в матрице: как ломается матричная структура
Про матричную структуру в проектном управлении слышали многие.
Идея кажется логичной и красивой — но, как обычно, всё ломается в деталях.
Разберёмся, как она работает на самом деле и почему требования к людям в ней сильно выше, чем кажется.
⚠️ Где начинаются сложности
Матричная структура предъявляет очень высокие требования сразу ко всем:
🔹к руководителю проекта,
🔹к сотруднику,
🔹к руководителю функционального подразделения.
И чем более разнородна команда проекта -
тем больнее это проявляется.
Разбираемся как и почему.
🎯 Руководитель проекта: управление без полной власти
Для руководителя проекта сотрудник подчиняется не полностью,
а только:
- в рамках выделенного времени,
- в рамках проектных задач.
Руководитель проекта должен:
- спланировать работу сотрудника,
- связать её с целями проекта,
- контролировать выполнение.
Но влияние ограничено:
у сотрудника есть второй руководитель.
Отсюда возникают сложности:
❌ не хватает влияния на сотрудника без формальной власти,
❌ оценки сроков и трудозатрат превращаются в разговор слепого с глухим:
РП не глубоко понимает предмет, а сотрудник не умеет оценивать
❌ другие РП пытаются "отжать" ресурс сотрудника.
Но почему это не самое страшное?
👉 Потому что руководитель проекта обычно понимает, на что он идёт.
И это часть его роли и условия работы.
Самые неожиданные требования — к сотруднику
Гораздо более жесткие и неожиданные требования
матрица предъявляет к сотруднику.
По-хорошему он должен:
✅ самостоятельно получить задачу от руководителя проекта,
✅ понять, что нужно сделать,
✅ выполнить её сам,
✅ если надо - пойти к функциональному руководителю за консультацией «как делать»
Это означает очень высокий уровень самостоятельности.
Мало того, что это минимум 3ий уровень делегирования с функциональным руководителем и 4ый с руководителем проекта, так он еще должен понимать к кому с чем идти.
И таких сотрудников немного.
От младших, да и от части среднего уровня,
этого ожидать нельзя.
👥 Почему лучше работает мини-команда
Поэтому матрица лучше всего работает, когда в проекте:
не одиночные специалисты,
а мини-группы.
Например:
- проектировщики со своим руководителем группы
- программисты со своим руководителем группы
- инженеры по настройке оборудования со своим руководителем группы
Даже если есть 3-4 сотрудника одной специальности, то руководителю проекта проще "выпросить" у руководителя функционального подразделения кого-то опытного и "вменяемого" на роль руководителя группы😊.
Руководитель группы находится в двойном подчинении,
умеет с этим работать,
а сотрудники уже подчиняются ему:
- не требуются высокие уровни делегирования
- не путаются в начальниках.
Но в небольших проектах и компаниях так получается не всегда.
А случится он или нет зависит в очень большой степени не от тех, кто занимается управлением проектами.
А .... от функциональных/линейных руководителей подразделений.
Как и почему - разберем в следующем посте серии.
Выходите из матрицы и проведите отличные выходные. Удачи! 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
🧩 Жизнь в матрице: как ломается матричная структура
Про матричную структуру в проектном управлении слышали многие.
Идея кажется логичной и красивой — но, как обычно, всё ломается в деталях.
Разберёмся, как она работает на самом деле и почему требования к людям в ней сильно выше, чем кажется.
🔀 Что такое матричная структура
В матричной структуре у сотрудника два руководителя:
🔹линейный / функциональный — руководитель подразделения,
🔹руководитель проекта — в рамках проекта и выделенного времени.
На бумаге всё выглядит идеально:
- сотрудники «живут» в подразделениях,
- проекты используют их как ресурс,
- функциональные руководители развивают компетенции,
- руководители проектов отвечают за результат.
⚠️ Где начинаются сложности
Матричная структура предъявляет очень высокие требования сразу ко всем:
🔹к руководителю проекта,
🔹к сотруднику,
🔹к руководителю функционального подразделения.
И чем более разнородна команда проекта -
тем больнее это проявляется.
Разбираемся как и почему.
🎯 Руководитель проекта: управление без полной власти
Для руководителя проекта сотрудник подчиняется не полностью,
а только:
- в рамках выделенного времени,
- в рамках проектных задач.
Руководитель проекта должен:
- спланировать работу сотрудника,
- связать её с целями проекта,
- контролировать выполнение.
Но влияние ограничено:
у сотрудника есть второй руководитель.
Отсюда возникают сложности:
РП не глубоко понимает предмет, а сотрудник не умеет оценивать
Но почему это не самое страшное?
👉 Потому что руководитель проекта обычно понимает, на что он идёт.
И это часть его роли и условия работы.
Самые неожиданные требования — к сотруднику
Гораздо более жесткие и неожиданные требования
матрица предъявляет к сотруднику.
По-хорошему он должен:
Это означает очень высокий уровень самостоятельности.
Мало того, что это минимум 3ий уровень делегирования с функциональным руководителем и 4ый с руководителем проекта, так он еще должен понимать к кому с чем идти.
И таких сотрудников немного.
От младших, да и от части среднего уровня,
этого ожидать нельзя.
👥 Почему лучше работает мини-команда
Поэтому матрица лучше всего работает, когда в проекте:
не одиночные специалисты,
а мини-группы.
Например:
- проектировщики со своим руководителем группы
- программисты со своим руководителем группы
- инженеры по настройке оборудования со своим руководителем группы
Даже если есть 3-4 сотрудника одной специальности, то руководителю проекта проще "выпросить" у руководителя функционального подразделения кого-то опытного и "вменяемого" на роль руководителя группы😊.
Руководитель группы находится в двойном подчинении,
умеет с этим работать,
а сотрудники уже подчиняются ему:
- не требуются высокие уровни делегирования
- не путаются в начальниках.
Но в небольших проектах и компаниях так получается не всегда.
Переход от чисто проектной или чисто функциональной структуры к матричной - очень болезненный.
Но для некоторых компаний (например проектно-ориентированного бизнеса) растущих от малого к среднему масштабу и, соответственно, развивающих свою систему управления проектами, этот переход является условием их выживания и развития.
А случится он или нет зависит в очень большой степени не от тех, кто занимается управлением проектами.
А .... от функциональных/линейных руководителей подразделений.
Как и почему - разберем в следующем посте серии.
Выходите из матрицы и проведите отличные выходные. Удачи! 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍3💯3
#надежнаяорганизация #механизмыуправления
Крупный бизнес: стратегия, системы и осторожность с гипотезами
В прошлом посте серии разобрали как работает малый бизнес.
Сегодня разберём его антипода - крупный бизнес.
Здесь всё устроено принципиально иначе, чем в малом.
Есть конечно исключения, но мы будем говорить про основную массу.
1️⃣ Стратегическое мышление
Крупный бизнес мыслит от стратегии, а не от отдельных гипотез, проб, ошибок и результатов:
- есть понимание рынка
- иногда — даже на уровне отраслей
- работает количественный анализ.
То, что невозможно сделать для маленькой пекарни
(провести полноценный анализ рынка — слишком дорого, да и бесполезно - статистики мало),
в крупном бизнесе — нормальная практика.
Здесь закон больших чисел работает,
и средние показатели действительно имеют смысл.
2️⃣ Жёсткая операционная система доминирует
В крупном бизнесе обычно уже отстроена жёсткая часть операционной системы:
- есть процессы
- есть показатели
- есть оргструктура
- есть отчётность.
Людей здесь не удивить словами
«процессы», «метрики», «эффективность».
Это уже базовая гигиена.
⚠️ Но где возникает проблема?
Она в другом.
В гибкой части.
3️⃣ Гибкая часть операционной системы подавлена
Гибкая часть обычно:
- не простроена системно
- не имеет легального статуса и по сути находится "в тени"
На уровне деклараций все говорят:
«Мы пробуем, экспериментируем, проверяем гипотезы».
Но на практике:
- к гипотезам относятся очень осторожно ("кто возьмет ответственность, если не вышло?")
- риски обсуждаются, но не часто их можно явно заложить в бюджет ("вы что планировать не умеете?")
Поэтому для крупного бизнеса нужны специальные механизмы, которые позволяют:
- не разучиться экспериментировать,
- работать с рисками,
- внедрять простые управленческие инструменты
без разрушения системы
- легитимизировать гибкую часть операционной системы.
🧩 Средний бизнес: самая живая зона
А вот средний бизнес — очень интересная среда.
Он уже в чём-то похож на крупный:
- понимает процессы,
- понимает показатели
- начинает мыслить системно.
Но при этом:
- ещё остаётся пространство для экспериментов,
- не все формализовано и есть гибкость (пусть да- же "за ней надо ходить" на высокий уровень менеджмента)
- нет «единственно правильной» модели.
Здесь всё очень индивидуально —
какой именно микс инструментов использовать
и как их понимать.
🔄 Почему средний бизнес самый открытый
Средний бизнес часто
помнит, как был маленьким,
но уже хочет стать большим.
Поэтому он
открыт к инструментам из малого бизнеса,
и одновременно готов брать практики из крупного.
С этой точки зрения
средний бизнес — самый благодарный
для управленческих инструментов,
если они подобраны под условия конкретной компании.
🎯 Итог
Предлагайте соответствующие решения под контекст,
и тогда всё будет работать.
Удачи вам 👍
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Крупный бизнес: стратегия, системы и осторожность с гипотезами
В прошлом посте серии разобрали как работает малый бизнес.
Сегодня разберём его антипода - крупный бизнес.
Здесь всё устроено принципиально иначе, чем в малом.
Есть конечно исключения, но мы будем говорить про основную массу.
1️⃣ Стратегическое мышление
Крупный бизнес мыслит от стратегии, а не от отдельных гипотез, проб, ошибок и результатов:
- есть понимание рынка
- иногда — даже на уровне отраслей
- работает количественный анализ.
То, что невозможно сделать для маленькой пекарни
(провести полноценный анализ рынка — слишком дорого, да и бесполезно - статистики мало),
в крупном бизнесе — нормальная практика.
Здесь закон больших чисел работает,
и средние показатели действительно имеют смысл.
2️⃣ Жёсткая операционная система доминирует
В крупном бизнесе обычно уже отстроена жёсткая часть операционной системы:
- есть процессы
- есть показатели
- есть оргструктура
- есть отчётность.
Людей здесь не удивить словами
«процессы», «метрики», «эффективность».
Это уже базовая гигиена.
⚠️ Но где возникает проблема?
Она в другом.
В гибкой части.
3️⃣ Гибкая часть операционной системы подавлена
Гибкая часть обычно:
- не простроена системно
- не имеет легального статуса и по сути находится "в тени"
На уровне деклараций все говорят:
«Мы пробуем, экспериментируем, проверяем гипотезы».
Но на практике:
- к гипотезам относятся очень осторожно ("кто возьмет ответственность, если не вышло?")
- риски обсуждаются, но не часто их можно явно заложить в бюджет ("вы что планировать не умеете?")
Поэтому для крупного бизнеса нужны специальные механизмы, которые позволяют:
- не разучиться экспериментировать,
- работать с рисками,
- внедрять простые управленческие инструменты
без разрушения системы
- легитимизировать гибкую часть операционной системы.
Примером может быть подход к программам оптимизации, который увязывает требования к предсказуемости и корпоративный подход к принятию решений с поиском, гипотезами и экспериментами.
Или "процесс как контракт", который сразу надежно выстраивает и жесткую часть, вписывающуюся в корпоративную структуру и, одновременно, систематизирует и легитимизирует гибкую.
Или позволяет функционировать гибкой части операционной системы в рамках жесткой.
🧩 Средний бизнес: самая живая зона
А вот средний бизнес — очень интересная среда.
Он уже в чём-то похож на крупный:
- понимает процессы,
- понимает показатели
- начинает мыслить системно.
Но при этом:
- ещё остаётся пространство для экспериментов,
- не все формализовано и есть гибкость (пусть да- же "за ней надо ходить" на высокий уровень менеджмента)
- нет «единственно правильной» модели.
Здесь всё очень индивидуально —
какой именно микс инструментов использовать
и как их понимать.
🔄 Почему средний бизнес самый открытый
Средний бизнес часто
помнит, как был маленьким,
но уже хочет стать большим.
Поэтому он
открыт к инструментам из малого бизнеса,
и одновременно готов брать практики из крупного.
С этой точки зрения
средний бизнес — самый благодарный
для управленческих инструментов,
если они подобраны под условия конкретной компании.
🎯 Итог
Малый бизнес живёт гипотезами и быстрым эффектом.
Крупный бизнес — стратегией, системами и предсказуемостью.
Средний бизнес — балансирует между ними
и потому наиболее гибок.
Предлагайте соответствующие решения под контекст,
и тогда всё будет работать.
Удачи вам 👍
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
👍5❤3💯2
Audio
#проектноеуправление #надежнаяорганизация #подкаст
Как растет система управления проектами.
Этап 2: первое масштабирование
Всем привет!
Продолжаем тему роста СУП (системы управления проектами) вместе с ростом проектно-ориентированного бизнеса, который зарабатывает на выполнении контрактных проектов в интересах заказчиков.
Это может быть заказная разработка, проектирование зданий и инженерных систем, поставка, монтаж и наладка оборудования и многое другое.
В прошлый раз мы разобрали как появляется первая система управления проектами и как я ее обычно отстраиваю для таких компаний.
Сегодня - о первом масштабировании, когда количество руководителей проектов достигло 15-20 и первая система перестала справляться - начинает требоваться все больше ручного управления.
00:00 Сегодня 2я серия подкаста о росте системы управления проектами (СУП) с ростом проектно-ориентированного бизнеса. Краткое содержание 1ой серии.
00:32 Почему первая СУП сломается, когда руководителей проектов станет 15-20
01:27 Следующий шаг - масштабирование системы управления проектами. Как это происходит
02:36 Как создаем и внедряем и причем здесь "процесс как контракт" (а это подкаст с кейсом)
03:05 Что приходит на смену Excel и почему вряд ли одна систему
03:52 Как трансформируется проектный офис
04:57 На каком этапе роста система управления проектами сломается в следующий раз?
05:32 Небольшой спойлер - почему следующий этап последний
05:55 Что делать, если узнали свою компанию на этом уровне
Удачи и хороших выходных🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Как растет система управления проектами.
Этап 2: первое масштабирование
Всем привет!
Продолжаем тему роста СУП (системы управления проектами) вместе с ростом проектно-ориентированного бизнеса, который зарабатывает на выполнении контрактных проектов в интересах заказчиков.
Это может быть заказная разработка, проектирование зданий и инженерных систем, поставка, монтаж и наладка оборудования и многое другое.
В прошлый раз мы разобрали как появляется первая система управления проектами и как я ее обычно отстраиваю для таких компаний.
Сегодня - о первом масштабировании, когда количество руководителей проектов достигло 15-20 и первая система перестала справляться - начинает требоваться все больше ручного управления.
00:00 Сегодня 2я серия подкаста о росте системы управления проектами (СУП) с ростом проектно-ориентированного бизнеса. Краткое содержание 1ой серии.
00:32 Почему первая СУП сломается, когда руководителей проектов станет 15-20
01:27 Следующий шаг - масштабирование системы управления проектами. Как это происходит
02:36 Как создаем и внедряем и причем здесь "процесс как контракт" (а это подкаст с кейсом)
03:05 Что приходит на смену Excel и почему вряд ли одна систему
03:52 Как трансформируется проектный офис
04:57 На каком этапе роста система управления проектами сломается в следующий раз?
05:32 Небольшой спойлер - почему следующий этап последний
05:55 Что делать, если узнали свою компанию на этом уровне
Хотите план роста системы управления проектами в вашей компании?
Напишите в личку @CIO_Alexey и встретимся на бесплатной диагностике (1 час, Zoom).
Удачи и хороших выходных🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
❤4👍3🔥3👏1
ЭФИР 19.02 19:00 КАК ПРЕОДОЛЕТЬ "ЗАСТРЕВАНИЕ" В КАРЬЕРЕ РУКОВОДИТЕЛЯ?
Видели такое?
Это только одна из четырёх типовых ситуаций,
в которых руководители "застревают" в карьере.
Что происходит на самом деле
Снаружи — опытный руководитель.
Внутри — сомнение и синдром самозванца.
Ожидания от вас уже как от «готового управленца»:
- быстро войти в организацию
- закрепиться
- пройти испытательный срок
- показать результат
А внутри вопрос:
«А я вообще смогу это повторить в другой компании?»
Заполните анкету на Yandex.Forms и получите ссылку на эфир в Zoom.
#статьруководителем #роструководителя #убратьдискомфорт
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Видели такое?
Выросли из специалиста в руководителя.
5 лет в одной компании. Всё отстроили. Всё работает.
И вдруг:
⚠️ новый начальник,
⚠️ реструктуризация,
⚠️ компанию продали,
⚠️сокращение.
И нужно искать работу.
А уверенности, что вас возьмут руководителем, — нет.
В другой компании всё по-другому.
И вы даже не понимаете, с чего начинать.
Это только одна из четырёх типовых ситуаций,
в которых руководители "застревают" в карьере.
Что происходит на самом деле
Снаружи — опытный руководитель.
Внутри — сомнение и синдром самозванца.
Ожидания от вас уже как от «готового управленца»:
- быстро войти в организацию
- закрепиться
- пройти испытательный срок
- показать результат
А внутри вопрос:
«А я вообще смогу это повторить в другой компании?»
На эфире 19.02 разберём:
🔹4 точки застревания руководителя в карьере
🔹как понять, что вы в одной из них
🔹почему они возникают
🔹как их преодолеть
🔹с чего начать прямо сейчас
И если захотите - разберем вашу конкретную ситуацию.
Заполните анкету на Yandex.Forms и получите ссылку на эфир в Zoom.
#статьруководителем #роструководителя #убратьдискомфорт
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
🔥3❤1👍1
Management_as_a_Code | Алексей Субботин pinned «ЭФИР 19.02 19:00 КАК ПРЕОДОЛЕТЬ "ЗАСТРЕВАНИЕ" В КАРЬЕРЕ РУКОВОДИТЕЛЯ? Видели такое? Выросли из специалиста в руководителя. 5 лет в одной компании. Всё отстроили. Всё работает. И вдруг: ⚠️ новый начальник, ⚠️ реструктуризация, ⚠️ компанию продали, ⚠️сокращение.…»
#проектноеуправление #инструменты #надежнаяорганизация
Earned Value для руководителя проекта: костюм супермена или калькулятор?
В начале 2000-х образ идеального руководителя проекта выглядел примерно так:
Тем, кто реально сталкивался с проектным управлением,
это кажется слабо реалистичным.
Но хорошая новость в том, что это не магия.
Это методика.
Она называется Earned Value Management (EVM).
И да — её еще можно агрегировать по портфелю проектов и докладывать на самый верх так же красиво.
❓ Так почему же почти нигде так красиво не получилось? 🤔
Разбираемся.
🧮 База метода: 3 ключевых показателя
Чтобы посчитать всё остальное, нужны всего три величины:
1️⃣ AC — Actual Cost
Фактические затраты на текущий момент.
2️⃣ PV (BC) — Planned Value (Budgeted Cost)
Плановая стоимость работ на текущую дату.
Сколько по плану должно было быть выполнено в бюджетных ценах.
3️⃣ EV (или BCWP) — Earned Value
Освоенная стоимость.
Сколько работ реально выполнено, но в плановых (бюджетных) ценах.
📉 Показатели для анализа
На основе этих трёх величин считаются 4 ключевых индикатора.
🔹 1. Cost Variance (CV) — отклонение по стоимости
CV = EV − AC
CV > 0 → экономия
CV < 0 → перерасход
🔹 2. Schedule Variance (SV) — отклонение по срокам (в деньгах)
SV = EV − PV
SV > 0 → опережаем график
SV < 0 → отстаём
Важно: SV считается в денежных единицах, не в днях.
🔹 3. Cost Performance Index (CPI)
CPI = EV / AC
CPI > 1 → тратим меньше, чем планировали
CPI < 1 → перерасход
🔹 4. Schedule Performance Index (SPI)
SPI = EV / PV
SPI > 1 → идём быстрее плана
SPI < 1 → отстаём
📊 Как делать анализ
📌 1. Процент выполнения проекта
% выполнения = EV / BAC
где BAC — полный бюджет проекта.
📌 2. Прогноз итогового бюджета (EAC)
Самый простой вариант:
EAC = BAC / CPI
Если CPI < 1 — бюджет вырастет.
📌 3. Прогноз сроков
Если известна плановая длительность проекта (D),
то приблизительная оценка:
Прогноз длительности ≈ D / SPI
🏢 Агрегация по портфелю
Самое интересное:
эти показатели можно суммировать по портфелю проектов.
Вы можете увидеть:
- средний CPI по портфелю
- средний SPI
- суммарный перерасход
- среднее отставание
🤯 «Но там же куча математики!»
В следующем посте серии покажу как использовать эту модель для downstream пайплайна,
где нужно понимать:
- насколько мы отстаём
-где перерасход
- какие заказы тянут общий результат вниз.
Удачи вам и чтобы всегда SPI и CPI >1 😊🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Earned Value для руководителя проекта: костюм супермена или калькулятор?
В начале 2000-х образ идеального руководителя проекта выглядел примерно так:
Руководитель проекта выходит на проектный комитет и бодро докладывает:
🔹проект выполнен на 63%
🔹отстаём на 12 дней,
🔹перерасход бюджета 4%,
🔹прогноз окончания — такой-то,
🔹итоговый бюджет — такой-то.
Ну и дальше как превзойти ожидания стейкхолдеров 😊
Тем, кто реально сталкивался с проектным управлением,
это кажется слабо реалистичным.
Но хорошая новость в том, что это не магия.
Это методика.
Она называется Earned Value Management (EVM).
И да — её еще можно агрегировать по портфелю проектов и докладывать на самый верх так же красиво.
Если коротко - потому что всю математику надо было сложить "внутрь" метода.
А ее упорно вытаскивают "наружу".
Разбираемся.
🧮 База метода: 3 ключевых показателя
Чтобы посчитать всё остальное, нужны всего три величины:
1️⃣ AC — Actual Cost
Фактические затраты на текущий момент.
2️⃣ PV (BC) — Planned Value (Budgeted Cost)
Плановая стоимость работ на текущую дату.
Сколько по плану должно было быть выполнено в бюджетных ценах.
3️⃣ EV (или BCWP) — Earned Value
Освоенная стоимость.
Сколько работ реально выполнено, но в плановых (бюджетных) ценах.
Пример:
Оборудование по бюджету стоит 100 000 ₽.
Купили за 105 000 ₽.
AC = 105 000
EV = 100 000
📉 Показатели для анализа
На основе этих трёх величин считаются 4 ключевых индикатора.
🔹 1. Cost Variance (CV) — отклонение по стоимости
CV = EV − AC
CV > 0 → экономия
CV < 0 → перерасход
🔹 2. Schedule Variance (SV) — отклонение по срокам (в деньгах)
SV = EV − PV
SV > 0 → опережаем график
SV < 0 → отстаём
Важно: SV считается в денежных единицах, не в днях.
🔹 3. Cost Performance Index (CPI)
CPI = EV / AC
CPI > 1 → тратим меньше, чем планировали
CPI < 1 → перерасход
🔹 4. Schedule Performance Index (SPI)
SPI = EV / PV
SPI > 1 → идём быстрее плана
SPI < 1 → отстаём
📊 Как делать анализ
📌 1. Процент выполнения проекта
% выполнения = EV / BAC
где BAC — полный бюджет проекта.
📌 2. Прогноз итогового бюджета (EAC)
Самый простой вариант:
EAC = BAC / CPI
Если CPI < 1 — бюджет вырастет.
📌 3. Прогноз сроков
Если известна плановая длительность проекта (D),
то приблизительная оценка:
Прогноз длительности ≈ D / SPI
🏢 Агрегация по портфелю
Самое интересное:
эти показатели можно суммировать по портфелю проектов.
Вы можете увидеть:
- средний CPI по портфелю
- средний SPI
- суммарный перерасход
- среднее отставание
🤯 «Но там же куча математики!»
Да, под капотом математики много.
Но на практике в качестве входных данных достаточно:
- плановых бюджетов и фактических затрат по периодам (например месяцам)
- плановых и фактических сроков вех.
Я делал модели, которые на основе этих данных считают все показатели методики Earned Value автоматически.
И выдают формулировки в стиле
«идеального руководителя проекта».
Причём без LLM - это просто формулы.
В следующем посте серии покажу как использовать эту модель для downstream пайплайна,
где нужно понимать:
- насколько мы отстаём
-где перерасход
- какие заказы тянут общий результат вниз.
Если интересно внедрить такую систему у себя —
пишите @CIO_Alexey , созвонимся и разберём.
Удачи вам и чтобы всегда SPI и CPI >1 😊🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥3
#проектноеуправление #статьруководителем #надежнаяорганизация
Будет ли работать матрица - во многом зависит от функционального, а не проектного руководителя
В первом посте про матричную структуру мы разобрали условия при которых матрица работает.
И вот здесь начинается самое важное.
Работа матрицы сильнее зависит от функционального руководителя, чем от проектного.
Проектный использует готовые ресурсы сотрудников.
А вот функциональный должен их подготовить.
Чтобы они соответствовали условиям работы в матрице.
И главный вопрос здесь не что делать,
а как изменить роль.
🔺 Перевёрнутая пирамида
Я называю это перевёрнутой пирамидой.
В обычном подразделении
руководитель ставит задачи сотрудникам.
В матрице
сотрудники принимают задачи от руководителя проекта,
а к функциональному руководителю приходят за помощью и консультацией.
Роль функционального руководителя:
- объяснить
- помочь разобраться
- развить компетенции
и отпустить сотрудника обратно в проект.
Это тяжело:
и для руководителей, привыкших всё контролировать,
и для сотрудников.
❌ Что будет, если этого не сделать
Если функциональный руководитель
начнёт дублировать контроль проектных задач,
то станет «вторым руководителем проекта»
И система проектного управления сломается:
- удвоятся трудозатраты и стоимость для компании
- руководители начнут толкаться локтями
- сотрудники будут отчитываться дважды
- функциональный руководитель будет работать за них, утонет в проектах
и просто не выдержит нагрузки.
Перевёрнутая пирамида — единственный устойчивый способ
работы в матричной структуре.
И как к ней перейти?
Для этого функциональный руководитель должен:
- перестать быть «начальником задач»
- стать консультантом, ментором, наставником
- доверять сотрудникам,
- делегировать на 4 уровень —
когда сотрудник сам получает и выполняет задачи,
а за помощью приходит только при необходимости.
Это другой класс навыков.
Другое мышление.
Другое управление.
Да он может:
- помогать руководителю проекта поставить задачу (а не принимать ее и транслировать своим подчиненным)
- помогать сотрудникам понять задачу руководителя проектов (а не ставить ее за него)
- помогать сотрудникам решить, как ее сделать (а не делать за них и не давать исчерпывающих инструкций)
И еще объяснять руководителю проекта и всем остальным, почему все пока не так хорошо работает и сотрудники учатся.
🙈 А это страшно.
Потому что кажется, что
- ты отдаешь власть, теряешь статус и влияние
- становишься не руководителем, а помощником
- принимаешь ответственность и отдаешь полномочия
Но эффективность - именно в такой смене роли.
А для некоторых компаний матрица - это единственный путь к росту. Да и к выживанию.
Матричная структура — сложная.
Переход к ней тяжёлый.
Но без изменения роли функционального руководителя
она не работает.
Удачи вам в матрице 😉
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Будет ли работать матрица - во многом зависит от функционального, а не проектного руководителя
В первом посте про матричную структуру мы разобрали условия при которых матрица работает.
И вот здесь начинается самое важное.
Работа матрицы сильнее зависит от функционального руководителя, чем от проектного.
Проектный использует готовые ресурсы сотрудников.
А вот функциональный должен их подготовить.
Чтобы они соответствовали условиям работы в матрице.
Ключевая задача функционального руководителя —
сделать так, чтобы все сотрудники могли работать в матрице
на том же уровне, что он сам или самые сильные сотрудники.
И главный вопрос здесь не что делать,
а как изменить роль.
🔺 Перевёрнутая пирамида
Я называю это перевёрнутой пирамидой.
В обычном подразделении
руководитель ставит задачи сотрудникам.
В матрице
сотрудники принимают задачи от руководителя проекта,
а к функциональному руководителю приходят за помощью и консультацией.
Роль функционального руководителя:
- объяснить
- помочь разобраться
- развить компетенции
и отпустить сотрудника обратно в проект.
Это тяжело:
и для руководителей, привыкших всё контролировать,
и для сотрудников.
❌ Что будет, если этого не сделать
Если функциональный руководитель
начнёт дублировать контроль проектных задач,
то станет «вторым руководителем проекта»
И система проектного управления сломается:
- удвоятся трудозатраты и стоимость для компании
- руководители начнут толкаться локтями
- сотрудники будут отчитываться дважды
- функциональный руководитель будет работать за них, утонет в проектах
и просто не выдержит нагрузки.
Перевёрнутая пирамида — единственный устойчивый способ
работы в матричной структуре.
И как к ней перейти?
Для этого функциональный руководитель должен:
- перестать быть «начальником задач»
- стать консультантом, ментором, наставником
- доверять сотрудникам,
- делегировать на 4 уровень —
когда сотрудник сам получает и выполняет задачи,
а за помощью приходит только при необходимости.
Т.е. стать не "богом молотов", а "богом молний".
Как сказал Один Тору в известном блокбастере.
Это другой класс навыков.
Другое мышление.
Другое управление.
Да он может:
- помогать руководителю проекта поставить задачу (а не принимать ее и транслировать своим подчиненным)
- помогать сотрудникам понять задачу руководителя проектов (а не ставить ее за него)
- помогать сотрудникам решить, как ее сделать (а не делать за них и не давать исчерпывающих инструкций)
И еще объяснять руководителю проекта и всем остальным, почему все пока не так хорошо работает и сотрудники учатся.
🙈 А это страшно.
Потому что кажется, что
- ты отдаешь власть, теряешь статус и влияние
- становишься не руководителем, а помощником
- принимаешь ответственность и отдаешь полномочия
Но эффективность - именно в такой смене роли.
А для некоторых компаний матрица - это единственный путь к росту. Да и к выживанию.
Матричная структура — сложная.
Переход к ней тяжёлый.
Но без изменения роли функционального руководителя
она не работает.
Удачи вам в матрице 😉
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
❤4🔥3👻1
Management_as_a_Code | Алексей Субботин
ЭФИР 19.02 19:00 КАК ПРЕОДОЛЕТЬ "ЗАСТРЕВАНИЕ" В КАРЬЕРЕ РУКОВОДИТЕЛЯ? Видели такое? Выросли из специалиста в руководителя. 5 лет в одной компании. Всё отстроили. Всё работает. И вдруг: ⚠️ новый начальник, ⚠️ реструктуризация, ⚠️ компанию продали, ⚠️сокращение.…
Всем привет!
Через час в 19:00 мск начинаем эфир "КАК ПРЕОДОЛЕТЬ "ЗАСТРЕВАНИЕ" В КАРЬЕРЕ РУКОВОДИТЕЛЯ".
Чтобы получить ссылку на эфир в Zoom - заполните анкету на Yandex.Forms .
Присоединяйтесь!
Через час в 19:00 мск начинаем эфир "КАК ПРЕОДОЛЕТЬ "ЗАСТРЕВАНИЕ" В КАРЬЕРЕ РУКОВОДИТЕЛЯ".
Чтобы получить ссылку на эфир в Zoom - заполните анкету на Yandex.Forms .
Присоединяйтесь!
👌4
Audio
#проектноеуправление #надежнаяорганизация #подкаст
Как растет система управления проектами.
Этап 3: переход к масштабированию бизнес-единиц
00:00 Сегодня 3ий и последний подкаст серии про рост системы управления проектным бизнесом. Краткое содержание предыдущих серий
01:03 Сейчас поговорим о 3ем этапе роста системы управления проектами
01:32 Предыдущая конструкция уже перестает тянуть количество и масштаб проектов.
02:20 Почему она дает сбой? И причем тут программное управление
03:24 Этот масштаб уже требует не кардинального изменения системы управления проектами, а реструктуризации бизнеса
04:13 Здесь вопрос не в системе управления проектами, а в выделении бизнес-единиц. Для каждой из которых выделяется портфель и появляется новый уровень управления
04:54 Что с системами управления проектами?
05:31 На этом уровне критически важной становится адаптация. Ее надо встраивать в процессы
05:47 Проектный офис может оставаться единым, но ....
06:54 Что тут главное препятствие для роста?
07:21 И отсюда интересный вывод - почему дальше система управления проектами кардинально не меняется, а структура бизнеса - да
07:59 Итак мы рассмотрели все фазы роста. Что делать на каждой из них, если вы застряли.
Удачи и хороших выходных🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Как растет система управления проектами.
Этап 3: переход к масштабированию бизнес-единиц
00:00 Сегодня 3ий и последний подкаст серии про рост системы управления проектным бизнесом. Краткое содержание предыдущих серий
01:03 Сейчас поговорим о 3ем этапе роста системы управления проектами
01:32 Предыдущая конструкция уже перестает тянуть количество и масштаб проектов.
02:20 Почему она дает сбой? И причем тут программное управление
03:24 Этот масштаб уже требует не кардинального изменения системы управления проектами, а реструктуризации бизнеса
04:13 Здесь вопрос не в системе управления проектами, а в выделении бизнес-единиц. Для каждой из которых выделяется портфель и появляется новый уровень управления
04:54 Что с системами управления проектами?
05:31 На этом уровне критически важной становится адаптация. Ее надо встраивать в процессы
05:47 Проектный офис может оставаться единым, но ....
06:54 Что тут главное препятствие для роста?
07:21 И отсюда интересный вывод - почему дальше система управления проектами кардинально не меняется, а структура бизнеса - да
07:59 Итак мы рассмотрели все фазы роста. Что делать на каждой из них, если вы застряли.
Что делать если есть сложности с переходом на следующий уровень?
Напишите в личку @CIO_Alexey и встретимся на бесплатной диагностике (1 час, Zoom).
Удачи и хороших выходных🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
👍2🔥1
#статьруководителем #роструководителя #убратьдискомфорт
Итоги эфира КАК ПРЕОДОЛЕТЬ "ЗАСТРЕВАНИЕ" В КАРЬЕРЕ РУКОВОДИТЕЛЯ?
В итоге выяснили, что все 4 точки застревания имеют одну причину 👇
Чтобы это сделать, нужна пирамида навыков из 4х уровней (на картинке):
1️⃣ Надо войти в новую роль и сделать это быстро
2️⃣ Для этого надо перестроить работу
3️⃣ Для этого надо получить поддержку влиятельных сторонников
4️⃣ Для этого надо уметь убеждать людей даже в сложных разговорах
"Дыра" в навыках на любом уровне и пирамида рушится.
И не получается провести необходимые изменения или адаптироваться.
Дальше мы разобрали какие навыки и инструменты позволят укрепить или выстроить Вашу пирамиду.
Интересно?
Хорошей рабочей недели 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Итоги эфира КАК ПРЕОДОЛЕТЬ "ЗАСТРЕВАНИЕ" В КАРЬЕРЕ РУКОВОДИТЕЛЯ?
На эфире 19.02 разобрали:
🔹4 точки застревания руководителя в карьере
🔹как понять, что вы в одной из них
🔹почему они возникают
🔹как их преодолеть
🔹с чего начать прямо сейчас
И разобрали кейс одного из участников.
В итоге выяснили, что все 4 точки застревания имеют одну причину 👇
Нет готовности к проведению изменений или адаптации к ним.
А надо вписаться в новую роль, или адаптировать свою роль к изменившейся ситуации.
Чтобы это сделать, нужна пирамида навыков из 4х уровней (на картинке):
1️⃣ Надо войти в новую роль и сделать это быстро
2️⃣ Для этого надо перестроить работу
3️⃣ Для этого надо получить поддержку влиятельных сторонников
4️⃣ Для этого надо уметь убеждать людей даже в сложных разговорах
"Дыра" в навыках на любом уровне и пирамида рушится.
И не получается провести необходимые изменения или адаптироваться.
Дальше мы разобрали какие навыки и инструменты позволят укрепить или выстроить Вашу пирамиду.
Интересно?
Напишите мне на @CIO_Alexey слово "Презентация"
и я пришлю вам презентацию,
которую показывал во время эфира.
Хорошей рабочей недели 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
✍2🔥2
#проектноеуправление #статьруководителем #надежнаяорганизация
Гибкая операционная система: как измерять Downstream через Earned Value
Мы уже говорили, что:
- Upstream — это маркетинг и продажи
- Downstream — это исполнение обязательств.
И вот если upstream все привыкли мерить воронками и конверсиями,
то downstream часто живёт в формате «Ну вроде работаем…»
А на самом деле его можно измерять очень чётко.
Через Earned Value (EV).
🔁 Напомню структуру downstream
📊 Пример расчёта
Допустим, контракт — 10 млн ₽.
Разбили по этапам и спланировали стоимость:
Проектирование 1 млн
Закупка 3 млн
Производство 4 млн
Монтаж 2 млн
BAC (общий бюджет) = 10 млн ₽
📅 Ситуация на текущую дату
По плану (PV):
- проектирование — 100%
- закупка — 100%
- производство — 50%
- монтаж — 0%
Значит:
PV = 1 + 3 + 2 = 6 млн ₽
Фактически выполнено (EV):
- проектирование — 100%
- закупка — 100%
- производство — 30%
- монтаж — 0%
EV = 1 + 3 + 1,2 = 5,2 млн ₽
Фактические затраты (AC):
- проектирование — 1,1 млн
- закупка — 3,2 млн
- производство — 1,6 млн
AC = 5,9 млн ₽
🧮 Считаем показатели
🔹 CPI = EV / AC
5,2 / 5,9 = 0,88
→ перерасход.
🔹 SPI = EV / PV
5,2 / 6 = 0,87
→ отстаём по срокам.
🔹 CV = EV − AC
5,2 − 5,9 = –0,7 млн ₽
→ перерасход 700 тыс.
🔹 SV = EV − PV
5,2 − 6 = –0,8 млн ₽
→ отставание по графику.
🎯 Что это даёт для Downstream
Теперь вы можете сказать:
- контракт выполнен на 52%
- отставание ~13%
- перерасход ~12%
если тенденция сохранится,
сроки затянем на ...
бюджет превысим ...
Причём это не субъективное ощущение,
а расчёт.
📦 А теперь масштабируем на портфель
Представьте, что у вас 20 контрактов.
Вы суммируете:
- общий EV
- общий PV
- общий AC
И считаете портфельный CPI и SPI.
Вы сразу видите:
- системное ли это отставание
- какие проекты «тянут вниз»
- проблема в сроках или в бюджете
- где узкое место downstream-потока
если вы не измеряете downstream,
то:
- кассовые разрывы становятся сюрпризом
- сроки «вдруг» срываются
- маржа тает незаметно
EV позволяет видеть это раньше, чем станет больно.
Иногда "лишняя" математика отнюдь не лишняя.
Удачи! 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Гибкая операционная система: как измерять Downstream через Earned Value
Мы уже говорили, что:
- Upstream — это маркетинг и продажи
- Downstream — это исполнение обязательств.
И вот если upstream все привыкли мерить воронками и конверсиями,
то downstream часто живёт в формате «Ну вроде работаем…»
А на самом деле его можно измерять очень чётко.
Через Earned Value (EV).
🔁 Напомню структуру downstream
Пример: контракт на поставку и монтаж оборудования.
Этапы:
- Проектирование
- Закупка комплектующих
- Производство
- Отгрузка
- Монтаж
- Пусконаладка
У каждого этапа есть плановая стоимость в цене клиента.
📊 Пример расчёта
Допустим, контракт — 10 млн ₽.
Разбили по этапам и спланировали стоимость:
Проектирование 1 млн
Закупка 3 млн
Производство 4 млн
Монтаж 2 млн
BAC (общий бюджет) = 10 млн ₽
📅 Ситуация на текущую дату
По плану (PV):
- проектирование — 100%
- закупка — 100%
- производство — 50%
- монтаж — 0%
Значит:
PV = 1 + 3 + 2 = 6 млн ₽
Фактически выполнено (EV):
- проектирование — 100%
- закупка — 100%
- производство — 30%
- монтаж — 0%
EV = 1 + 3 + 1,2 = 5,2 млн ₽
Фактические затраты (AC):
- проектирование — 1,1 млн
- закупка — 3,2 млн
- производство — 1,6 млн
AC = 5,9 млн ₽
🧮 Считаем показатели
🔹 CPI = EV / AC
5,2 / 5,9 = 0,88
→ перерасход.
🔹 SPI = EV / PV
5,2 / 6 = 0,87
→ отстаём по срокам.
🔹 CV = EV − AC
5,2 − 5,9 = –0,7 млн ₽
→ перерасход 700 тыс.
🔹 SV = EV − PV
5,2 − 6 = –0,8 млн ₽
→ отставание по графику.
🎯 Что это даёт для Downstream
Теперь вы можете сказать:
- контракт выполнен на 52%
- отставание ~13%
- перерасход ~12%
если тенденция сохранится,
сроки затянем на ...
бюджет превысим ...
Причём это не субъективное ощущение,
а расчёт.
📦 А теперь масштабируем на портфель
Представьте, что у вас 20 контрактов.
Вы суммируете:
- общий EV
- общий PV
- общий AC
И считаете портфельный CPI и SPI.
Вы сразу видите:
- системное ли это отставание
- какие проекты «тянут вниз»
- проблема в сроках или в бюджете
- где узкое место downstream-потока
если вы не измеряете downstream,
то:
- кассовые разрывы становятся сюрпризом
- сроки «вдруг» срываются
- маржа тает незаметно
EV позволяет видеть это раньше, чем станет больно.
Иногда "лишняя" математика отнюдь не лишняя.
Удачи! 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
👍8✍2❤1
#кейс #заинтересованныестороны #изменения
Проект завершён. А заказчик не подписывает. Что происходит на самом деле?
Знакомо?
Разберём, что здесь реально происходит.
🔎 1️⃣ Это не проблема договора, распоряжения или каких-то формальных механизмов.
Это проблема управления стейкхолдерами.
Фраза из кейса ключевая:
«В одном месте лечим - в другом калечим».
А это значит, что:
✔️ формальный заказчик один
❗️ реальных стейкхолдеров — больше
И если их интересы не выровнены,
проект не будет считаться успешным —
даже если всё выполнено по ТЗ.
Проект закрывается не актом.
Проект закрывается достижением баланса интересов.
📊 Что произошло
С высокой вероятностью:
- оптимизировали один участок
- но пострадал смежный
Это нормально.
Но глобальная метрика цепочки не выросла.
Или заказчик просто так воспринимает.
А заказчик смотрит не на задачи.
Он смотрит на системный эффект.
Причем в своем субъективном восприятии.
🔄 2️⃣ Это незавершённое изменение (ADKAR)
В таких кейсах обычно:
✅ Awareness — есть
✅ Knowledge — есть
А вот:
❌ Desire — смежные функции не видят выгоды
❌ Ability — процессы не дообкатаны
❌ Reinforcement — нет подтверждения, что стало лучше
Технически проект завершён.
Организационно — нет.
⚠️ Почему заказчик не подписывает
Не потому что он «вредный».
А потому что:
- он чувствует риск
- он не хочет брать ответственность
- у него нет системной картины улучшения
И он не хочет быть тем, кто «подписал ухудшение».
Что делать в такой ситуации
1️⃣ Разделить уровни
📜 Закрытие этапа по договору
🔄 Продолжение изменений как новый этап
Формулировка может быть такая:
«Объём проекта выполнен.
Сейчас мы видим системные эффекты.
Предлагаю закрыть этап и зафиксировать следующий».
Подробнее о том что делать с остающимися проблемами - в этом посте
2️⃣ Перевести эмоции в метрики
Собрать:
- где стало лучше
- где стало хуже
- какие балансы улучшений/ухудшений достигнуты
- какая глобальная метрика системы
Если её нет — её нужно ввести.
3️⃣ Провести reconciliation стейкхолдеров
Собрать:
- владельцев процессов
- смежные функции
- заказчика
И задать три вопроса:
- Что стало лучше?
- Что стало хуже?
- Что считаем критичным?
Без обвинений. Только факты.
🎯 Главный вывод
Если:
- не сбалансированы интересы
- не пройден цикл изменений
проект не будет ощущаться завершённым.
Даже если он завершён по документам.
Удачи вам в проведении изменений 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Проект завершён. А заказчик не подписывает. Что происходит на самом деле?
Кейс из практики одного из наших подписчиков.
Проект формально выполнен:
- задачи закрыты
- объём по договору сделан
- внедрено ПО
- процессы изменены
Но заказчик говорит:
«Да, задачи выполнены.
Но в целом лучше не стало.
В одном месте лечим — в другом калечим.
Подписывать завершение не готов»
Знакомо?
Разберём, что здесь реально происходит.
🔎 1️⃣ Это не проблема договора, распоряжения или каких-то формальных механизмов.
Это проблема управления стейкхолдерами.
Фраза из кейса ключевая:
«В одном месте лечим - в другом калечим».
А это значит, что:
✔️ формальный заказчик один
❗️ реальных стейкхолдеров — больше
И если их интересы не выровнены,
проект не будет считаться успешным —
даже если всё выполнено по ТЗ.
Проект закрывается не актом.
Проект закрывается достижением баланса интересов.
📊 Что произошло
С высокой вероятностью:
- оптимизировали один участок
- но пострадал смежный
Это нормально.
Но глобальная метрика цепочки не выросла.
Или заказчик просто так воспринимает.
А заказчик смотрит не на задачи.
Он смотрит на системный эффект.
Причем в своем субъективном восприятии.
🔄 2️⃣ Это незавершённое изменение (ADKAR)
Напомню модель ADKAR:
Awareness — понимание зачем
Desire — желание участвовать
Knowledge — знание как
Ability — способность применять
Reinforcement — закрепление
В таких кейсах обычно:
А вот:
❌ Desire — смежные функции не видят выгоды
❌ Ability — процессы не дообкатаны
❌ Reinforcement — нет подтверждения, что стало лучше
Технически проект завершён.
Организационно — нет.
⚠️ Почему заказчик не подписывает
Не потому что он «вредный».
А потому что:
- он чувствует риск
- он не хочет брать ответственность
- у него нет системной картины улучшения
И он не хочет быть тем, кто «подписал ухудшение».
Что делать в такой ситуации
1️⃣ Разделить уровни
📜 Закрытие этапа по договору
🔄 Продолжение изменений как новый этап
Формулировка может быть такая:
«Объём проекта выполнен.
Сейчас мы видим системные эффекты.
Предлагаю закрыть этап и зафиксировать следующий».
Подробнее о том что делать с остающимися проблемами - в этом посте
2️⃣ Перевести эмоции в метрики
Собрать:
- где стало лучше
- где стало хуже
- какие балансы улучшений/ухудшений достигнуты
- какая глобальная метрика системы
Если её нет — её нужно ввести.
3️⃣ Провести reconciliation стейкхолдеров
Собрать:
- владельцев процессов
- смежные функции
- заказчика
И задать три вопроса:
- Что стало лучше?
- Что стало хуже?
- Что считаем критичным?
Без обвинений. Только факты.
🎯 Главный вывод
Если:
- не сбалансированы интересы
- не пройден цикл изменений
проект не будет ощущаться завершённым.
Даже если он завершён по документам.
Удачи вам в проведении изменений 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍1
#инструменты #роструководителя #надежнаяорганизация
10 стримов руководителя при выходе с должности
Мы много говорим про вход.
Но почти никто не говорит про выход.
Можно сказать, что это уже не мои проблемы.
Но рынок узкий.
А если вы перешли на новую должность в той же компании или группе компаний? То все вообще рядом.
Когда начнут выпадать скелеты из шкафа, вряд ли это положительно отразится на дальнейшей карьере.
Выход — это экзамен на зрелость.
Потому что:
👉 Войти красиво — сложно.
👉 Выйти красиво — сложнее.
Я несколько раз выходил:
- как топ
- как консультант
- после трансформаций
- после кризисных проектов
И понял, что нет «10 последних шагов».
Есть стримы, которые идут параллельно.
И если их не запустить —
организация начинает рассыпаться ещё до вашего ухода.
Итак, 10 выходных стримов руководителя.
1️⃣ Стрим 1: Мой руководитель
- проговорить причины ухода
- договориться о формате коммуникации
- согласовать финальный горизонт (дата, этапы)
- обсудить риски
Очень важно:
ваш босс не должен узнавать о рисках от третьих лиц.
2️⃣ Стрим 2: Ключевые стейкхолдеры
- кто зависит от вас напрямую
- кто почувствует вакуум
- кто может начать деструктив
С каждым — 1 на 1.
Не объясняем,
а снимаем тревогу,
и предотвращаем деструктив.
3️⃣ Стрим 3: Команда
Самая важная часть.
- объяснить, почему
- что будет дальше
- кто будет замещать
- что не изменится
И главное —
не обесценить то, что построено.
4️⃣ Стрим 4: Передача власти
Выход — это не передача задач.
Это передача полномочий.
Нужно:
- формально закрепить или хотя бы окончательно прояснить зоны ответственности
- убрать «серые зоны»
Иначе команда останется в подвешенном состоянии.
А приход нового руководителя усугубит это.
И вы услышите: "Ничего он на самом деле не отстроил".
5️⃣ Стрим 5: Документы и артефакты
Здесь нужно выложить "на бумагу", все что у вас в голове:
- планы и дорожные карты (иначе направление развития может быть потеряно)
- устные договоренности (иначе что-то забудется, а кто-то передоговорится)
- инструкции, руководства о том, как действовать в случаях где еще нет или в принципе не планируется письменный регламент или процедура (вы-то знали, а вот команда или новый руководитель - вряд ли)
Если что-то держится только «в голове» —
оно пропадет после вашего ухода
и развалит систему.
6️⃣ Стрим 6: Незавершённые конфликты
Очень опасная зона.
Перед выходом:
- закрыть конфликты
- или хотя бы довести их до понятной точки, или "передать"
Нельзя оставлять «мины замедленного действия».
7️⃣ Стрим 7: Обратная связь наверх
Это редкий, но важный шаг.
- что работает
- что не работает
- где риски
Без эмоций.
Без обид.
Факты.
Это уважение к системе.
Иногда я оставлял акционерам целое "завещание" на нескольких страницах.
8️⃣ Стрим 8: ADKAR на выходе
Да, при выходе тоже работает ADKAR.
Команда должна пройти все 5 стадий:
Awareness — почему вы уходите
Desire — принять новую реальность
Knowledge — кто и как будет работать
Ability — начать работать без вас
Reinforcement — закрепить это
Если этого не сделать —
организация регрессирует.
9️⃣ Стрим 9: Последнее делегирование
Всё, что было «на вас»,
должно быть делегировано.
То, что вы сможете передать это преемнику - иллюзия:
- он не в контексте
- у него куча других задач на входе
Нужен кто-то из команды, кто хотя бы ему напомнит как это сделать.
Иначе через месяц вам начнут звонить.
🔟 Стрим 10: Репутационный хвост
Очень важно:
- попрощаться корректно
- поблагодарить
- сохранить контакты
Мир управления маленький.
Красивый выход
часто ценится больше красивого входа.
Главное
Выход — это проверка:
построили ли вы систему
или вы были системой
Если после вашего ухода всё работает —
значит вы сделали свою работу.
Если без вас всё встало —
значит вы работали руками, а не строили организацию.
Хорошей недели вам 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
10 стримов руководителя при выходе с должности
Мы много говорим про вход.
Но почти никто не говорит про выход.
Можно сказать, что это уже не мои проблемы.
Но рынок узкий.
А если вы перешли на новую должность в той же компании или группе компаний? То все вообще рядом.
Когда начнут выпадать скелеты из шкафа, вряд ли это положительно отразится на дальнейшей карьере.
Выход — это экзамен на зрелость.
Потому что:
👉 Войти красиво — сложно.
👉 Выйти красиво — сложнее.
Я несколько раз выходил:
- как топ
- как консультант
- после трансформаций
- после кризисных проектов
И понял, что нет «10 последних шагов».
Есть стримы, которые идут параллельно.
И если их не запустить —
организация начинает рассыпаться ещё до вашего ухода.
Итак, 10 выходных стримов руководителя.
1️⃣ Стрим 1: Мой руководитель
- проговорить причины ухода
- договориться о формате коммуникации
- согласовать финальный горизонт (дата, этапы)
- обсудить риски
Очень важно:
ваш босс не должен узнавать о рисках от третьих лиц.
2️⃣ Стрим 2: Ключевые стейкхолдеры
- кто зависит от вас напрямую
- кто почувствует вакуум
- кто может начать деструктив
С каждым — 1 на 1.
Не объясняем,
а снимаем тревогу,
и предотвращаем деструктив.
3️⃣ Стрим 3: Команда
Самая важная часть.
- объяснить, почему
- что будет дальше
- кто будет замещать
- что не изменится
И главное —
не обесценить то, что построено.
4️⃣ Стрим 4: Передача власти
Выход — это не передача задач.
Это передача полномочий.
Нужно:
- формально закрепить или хотя бы окончательно прояснить зоны ответственности
- убрать «серые зоны»
Иначе команда останется в подвешенном состоянии.
А приход нового руководителя усугубит это.
И вы услышите: "Ничего он на самом деле не отстроил".
5️⃣ Стрим 5: Документы и артефакты
Здесь нужно выложить "на бумагу", все что у вас в голове:
- планы и дорожные карты (иначе направление развития может быть потеряно)
- устные договоренности (иначе что-то забудется, а кто-то передоговорится)
- инструкции, руководства о том, как действовать в случаях где еще нет или в принципе не планируется письменный регламент или процедура (вы-то знали, а вот команда или новый руководитель - вряд ли)
Если что-то держится только «в голове» —
оно пропадет после вашего ухода
и развалит систему.
6️⃣ Стрим 6: Незавершённые конфликты
Очень опасная зона.
Перед выходом:
- закрыть конфликты
- или хотя бы довести их до понятной точки, или "передать"
Нельзя оставлять «мины замедленного действия».
7️⃣ Стрим 7: Обратная связь наверх
Это редкий, но важный шаг.
- что работает
- что не работает
- где риски
Без эмоций.
Без обид.
Факты.
Это уважение к системе.
Иногда я оставлял акционерам целое "завещание" на нескольких страницах.
8️⃣ Стрим 8: ADKAR на выходе
Да, при выходе тоже работает ADKAR.
Команда должна пройти все 5 стадий:
Awareness — почему вы уходите
Desire — принять новую реальность
Knowledge — кто и как будет работать
Ability — начать работать без вас
Reinforcement — закрепить это
Если этого не сделать —
организация регрессирует.
9️⃣ Стрим 9: Последнее делегирование
Всё, что было «на вас»,
должно быть делегировано.
То, что вы сможете передать это преемнику - иллюзия:
- он не в контексте
- у него куча других задач на входе
Нужен кто-то из команды, кто хотя бы ему напомнит как это сделать.
Иначе через месяц вам начнут звонить.
🔟 Стрим 10: Репутационный хвост
Очень важно:
- попрощаться корректно
- поблагодарить
- сохранить контакты
Мир управления маленький.
Красивый выход
часто ценится больше красивого входа.
Главное
Выход — это проверка:
построили ли вы систему
или вы были системой
Если после вашего ухода всё работает —
значит вы сделали свою работу.
Если без вас всё встало —
значит вы работали руками, а не строили организацию.
Хорошей недели вам 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
🔥5❤3👍2
Что такое управление портфелем проектов на самом деле
Всем привет.
Начинаем разбирать управление портфелем проектов.
Управление одним проектом — понятно.
Есть цель, сроки, бюджет, результат.
А теперь представьте, что проектов много.
И тут появляется вопрос:
как они связаны с целями организации?
Портфель проектов - это механизм, который связывает ограниченные во времени проекты с "постоянно" существующей организацией.
Одна из самых сложных вещей - это увязка "горизонтов" этих двух взглядов:
- цели и показатели организации - на период, а у проектов - к определенному сроку, возможно за пределами периода
- бюджеты организации по периодам, по проектам - до завершения
- ресурсы на проектах временно, в организации - постоянно
- ....
И таких вещей еще много.
⚖️ Два принципиально разных типа портфеля
Есть два вида портфеля, которые кардинально отличаются.
1️⃣ Стратегический портфель (для себя)
Это портфель проектов,
которые организация делает для собственной стратегии развития.
Например:
- трансформация процессов
- внедрение систем
- новые продукты
- программы развития
Цели портфеля обычно формируются из целей компании.
Как им управляют?
Обычно 1-2 раза в год
- формируют цели
- генерируют инициативы
- оценивают их
- отбирают проекты
- балансируют портфель
Задача —
с минимальными ресурсами максимально приблизиться к целевым показателям.
Это классическая, плановая история.
2️⃣ Контрактный портфель (для клиентов)
А теперь другой случай.
Организация выполняет проекты за деньги в интересах заказчиков,
т.е. по сути достигает целей заказчика за деньги.
Здесь цели организации уже ограничены тем, что она получает за эти проекты и характеристиками операционной деятельности:
- маржинальность проектов
- объём проектов
- загрузка ресурсов
И цикл управления - совсем другой.
Проекты появляются не по вашему годовому плану.
Они — результат продаж.
Результат вашего upstream.
Вы не можете заранее точно спланировать,
когда и какие именно проекты придут.
🔄 Управление в реальном времени
И делать это приходится постоянно.
В реальном времени.
Разница по логике управления
Эти два типа портфеля отличаются примерно так же,
как:
плановый цикл (PDCA) и ситуационное управление (OODA)
В первом случае:
- фиксированный цикл
- годовое планирование
- балансировка по бюджету
Во втором:
- постоянная оценка
- гибкость
- быстрые решения
- реакция на рынок
⚙️ И это влияет на всё
- приоритизацию
- бюджетирование
- балансировку
- мониторинг
- управление рисками
В следующих постах разберём:
- как приоритизировать стратегический портфель
- как оценивать входящие проекты в контрактном портфеле
и как не смешивать эти два подхода.
Даже если у вас в организации есть оба этих портфеля.
Потому что именно смешивание обычно и ломает систему.
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
#проектноеуправление #надежнаяорганизация #инструменты
Всем привет.
Начинаем разбирать управление портфелем проектов.
Управление одним проектом — понятно.
Есть цель, сроки, бюджет, результат.
А теперь представьте, что проектов много.
И тут появляется вопрос:
как они связаны с целями организации?
📌 Портфель — это связка проектов с организацией
Портфель проектов - это механизм, который связывает ограниченные во времени проекты с "постоянно" существующей организацией.
Одна из самых сложных вещей - это увязка "горизонтов" этих двух взглядов:
- цели и показатели организации - на период, а у проектов - к определенному сроку, возможно за пределами периода
- бюджеты организации по периодам, по проектам - до завершения
- ресурсы на проектах временно, в организации - постоянно
- ....
И таких вещей еще много.
Портфель — это способ сделать так,
чтобы проекты действительно двигали организацию к ее целям,
и при этом соответствовали ее процессам, правилам, показателям, ...
⚖️ Два принципиально разных типа портфеля
Есть два вида портфеля, которые кардинально отличаются.
1️⃣ Стратегический портфель (для себя)
Это портфель проектов,
которые организация делает для собственной стратегии развития.
Например:
- трансформация процессов
- внедрение систем
- новые продукты
- программы развития
Цели портфеля обычно формируются из целей компании.
Как им управляют?
Обычно 1-2 раза в год
- формируют цели
- генерируют инициативы
- оценивают их
- отбирают проекты
- балансируют портфель
Задача —
с минимальными ресурсами максимально приблизиться к целевым показателям.
Это классическая, плановая история.
2️⃣ Контрактный портфель (для клиентов)
А теперь другой случай.
Организация выполняет проекты за деньги в интересах заказчиков,
т.е. по сути достигает целей заказчика за деньги.
Здесь цели организации уже ограничены тем, что она получает за эти проекты и характеристиками операционной деятельности:
- маржинальность проектов
- объём проектов
- загрузка ресурсов
И цикл управления - совсем другой.
Проекты появляются не по вашему годовому плану.
Они — результат продаж.
Результат вашего upstream.
Вы не можете заранее точно спланировать,
когда и какие именно проекты придут.
🔄 Управление в реальном времени
В стратегическом портфеле вы
сначала ставите цели, потом под них подбираете проекты.
В контрактном портфеле вы
смотрите на появившийся проект и решаете, станет ли портфель лучше с ним или без него.
И делать это приходится постоянно.
В реальном времени.
Разница по логике управления
Эти два типа портфеля отличаются примерно так же,
как:
плановый цикл (PDCA) и ситуационное управление (OODA)
В первом случае:
- фиксированный цикл
- годовое планирование
- балансировка по бюджету
Во втором:
- постоянная оценка
- гибкость
- быстрые решения
- реакция на рынок
⚙️ И это влияет на всё
- приоритизацию
- бюджетирование
- балансировку
- мониторинг
- управление рисками
В следующих постах разберём:
- как приоритизировать стратегический портфель
- как оценивать входящие проекты в контрактном портфеле
и как не смешивать эти два подхода.
Даже если у вас в организации есть оба этих портфеля.
Потому что именно смешивание обычно и ломает систему.
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
#проектноеуправление #надежнаяорганизация #инструменты
👍4❤3🔥1
Мотивация — это не KPI. Это совпадение «зачем».
Сегодня поговорим о мотивации.
Многие думают:
«Я в крупной компании. Система мотивации выстроена. Я ничего изменить не могу».
Ничего подобного.
Начнём с базы.
📌 Что такое мотивация на самом деле
Не KPI.
Не бонус.
Не формальная система.
А пересечение ответов на вопрос "зачем".
🎯 У сотрудников разные «зачем»
Это не только деньги.
Один приходит зарабатывать
Другой - получать опыт
Третий - за признанием
Четвёртый - за сильной командой
Пятый - за интересным продуктом
Конечно, деньги нужны всем.
Это база мотивации.
Но если вы хотите, чтобы люди не просто ходили на работу, а вкладывались в результат - надо отвечать и на другие "зачем".
Как понять мотивацию
Я обычно выясняю это еще на собеседовании двумя вопросами:
1️⃣ Назови 3-4 вещи (в порядке приоритета), которые для тебя важны в работе.
2️⃣ Что может спровоцировать твой уход?
Второй вопрос — санитарный.
Он сразу показывает реальные триггеры.
И вы начинаете понимать:
зачем этому человеку эта работа.
📌 А теперь вопрос к вам
Зачем вам этот сотрудник?
- Чтобы он просто закрывал свой участок и не создавал проблем?
- Чтобы поменял процессы?
- Чтобы сделал прорыв?
- Чтобы работал автономно и вы освободили своё время?
Пока вы этого не понимаете,
никакая система KPI не спасёт.
🔄 Где рождается настоящая мотивация
Примеры:
Человеку важна стабильность и рынок.
Вы: регулярно индексируете зарплату
Он спокойно закрывает зону ответственности.
Человеку важен рост:
Вы даёте сложный проект
потом продвигаете его.
Он: выполняет его не создавая вам проблем
Человеку важен опыт:
вы: даете ему задачи на которых он растет
он: работает в тяжёлых условиях.
Вот это и есть корневая мотивация.
⚙️ А формальная система?
KPI, премии, грейды —
это уже инструменты выполнения обязательств и условия игры.
Сначала совпадение интересов.
Потом — привязка к системе:
Если совпадения нет —
формальная система не работает.
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
#мотиваци #надежнаяорганизация
Сегодня поговорим о мотивации.
Многие думают:
«Я в крупной компании. Система мотивации выстроена. Я ничего изменить не могу».
Ничего подобного.
Начнём с базы.
📌 Что такое мотивация на самом деле
Мотивация — это когда:
👉 ваше «зачем» как руководителя
совпадает
👉 с «зачем» сотрудника.
Не KPI.
Не бонус.
Не формальная система.
А пересечение ответов на вопрос "зачем".
🎯 У сотрудников разные «зачем»
Это не только деньги.
Один приходит зарабатывать
Другой - получать опыт
Третий - за признанием
Четвёртый - за сильной командой
Пятый - за интересным продуктом
Конечно, деньги нужны всем.
Это база мотивации.
Но если вы хотите, чтобы люди не просто ходили на работу, а вкладывались в результат - надо отвечать и на другие "зачем".
Как понять мотивацию
Я обычно выясняю это еще на собеседовании двумя вопросами:
1️⃣ Назови 3-4 вещи (в порядке приоритета), которые для тебя важны в работе.
2️⃣ Что может спровоцировать твой уход?
Второй вопрос — санитарный.
Он сразу показывает реальные триггеры.
И вы начинаете понимать:
зачем этому человеку эта работа.
📌 А теперь вопрос к вам
Зачем вам этот сотрудник?
- Чтобы он просто закрывал свой участок и не создавал проблем?
- Чтобы поменял процессы?
- Чтобы сделал прорыв?
- Чтобы работал автономно и вы освободили своё время?
Пока вы этого не понимаете,
никакая система KPI не спасёт.
🔄 Где рождается настоящая мотивация
Мотивация возникает
👉 между его «зачем»
и
👉 вашим «зачем».
По сути - это сделка, которую вы заключаете.
А KPI, премии, повышения и другие формальные вещи - инструменты для реализации обязательств по этой сделки.
Примеры:
Человеку важна стабильность и рынок.
Вы: регулярно индексируете зарплату
Он спокойно закрывает зону ответственности.
Человеку важен рост:
Вы даёте сложный проект
потом продвигаете его.
Он: выполняет его не создавая вам проблем
Человеку важен опыт:
вы: даете ему задачи на которых он растет
он: работает в тяжёлых условиях.
Вот это и есть корневая мотивация.
⚙️ А формальная система?
KPI, премии, грейды —
это уже инструменты выполнения обязательств и условия игры.
Сначала совпадение интересов.
Потом — привязка к системе:
Если совпадения нет —
формальная система не работает.
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
#мотиваци #надежнаяорганизация
❤3👍3🔥3👏1
Всем привет!
Вышел подкаст, где мы с управляющим партнером ГК "Проектная ПРАКТИКА" Михаилом Козодаевым обсуждаем как люди влияют на эффективность проектов.
Обсудили несколько неожиданных факторов эффективности, которые не часто рассматривают.
Будет интересно, разговор получился живой.
Удачных проектов! 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
#проектноеуправление #подкаст
Вышел подкаст, где мы с управляющим партнером ГК "Проектная ПРАКТИКА" Михаилом Козодаевым обсуждаем как люди влияют на эффективность проектов.
Обсудили несколько неожиданных факторов эффективности, которые не часто рассматривают.
Будет интересно, разговор получился живой.
Удачных проектов! 🤝
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
#проектноеуправление #подкаст
👍2🔥2
Почему проекты “ломаются” не из-за процессов, а из-за людей
В управлении проектами мы привыкли говорить про методологии, сроки и бюджеты. Но на практике эффективность проекта чаще всего определяется совсем другим - людьми и их взаимодействием.
Из обсуждения с экспертами в области проектного управления с более чем 20-летним опытом - Михаилом Козодаевым (управляющий партнёр ГК «Проектная ПРАКТИКА») и Алексеем Субботиным (независимый эксперт) - прозвучало несколько важных мыслей:
• Hard skills недостаточно. У руководителя проекта могут быть идеальные знания методологий, но без навыков коммуникации, обратной связи и работы с людьми эффективность команды резко падает.
• РП не работает в вакууме. Его эффективность напрямую зависит от системы вокруг: полномочий, мотивации, процессов и поддержки со стороны компании.
• Смежные функции могут ускорить или убить проект. Финансы, закупки, юристы — если они не встроены в проектную логику, даже идеальный план не спасёт сроки.
• Эффективность ≠ успешность. Проект может уложиться в срок и бюджет, но всё равно считаться неуспешным, если ожидания ключевых стейкхолдеров не совпали с результатом.
И главный вывод:
Проекты - это не только управление задачами, сроками, ресурсами, бюджетами - это управление системой людей и интересов.
А как вы считаете - что сильнее всего влияет на эффективность проектов?
🔊Послушать выпуск
⚙️Канал эксперта-участника Алексея Субботина
#ПодкастПроектнаяПРАКТИКА
Мы в MAX
В управлении проектами мы привыкли говорить про методологии, сроки и бюджеты. Но на практике эффективность проекта чаще всего определяется совсем другим - людьми и их взаимодействием.
Из обсуждения с экспертами в области проектного управления с более чем 20-летним опытом - Михаилом Козодаевым (управляющий партнёр ГК «Проектная ПРАКТИКА») и Алексеем Субботиным (независимый эксперт) - прозвучало несколько важных мыслей:
• Hard skills недостаточно. У руководителя проекта могут быть идеальные знания методологий, но без навыков коммуникации, обратной связи и работы с людьми эффективность команды резко падает.
• РП не работает в вакууме. Его эффективность напрямую зависит от системы вокруг: полномочий, мотивации, процессов и поддержки со стороны компании.
• Смежные функции могут ускорить или убить проект. Финансы, закупки, юристы — если они не встроены в проектную логику, даже идеальный план не спасёт сроки.
• Эффективность ≠ успешность. Проект может уложиться в срок и бюджет, но всё равно считаться неуспешным, если ожидания ключевых стейкхолдеров не совпали с результатом.
И главный вывод:
Проекты - это не только управление задачами, сроками, ресурсами, бюджетами - это управление системой людей и интересов.
А как вы считаете - что сильнее всего влияет на эффективность проектов?
🔊Послушать выпуск
⚙️Канал эксперта-участника Алексея Субботина
#ПодкастПроектнаяПРАКТИКА
Мы в MAX
👍6🔥5🥴2
«Проект есть. Поддержка руководства есть. А ничего не работает.»
Ко мне регулярно приходят с одной и той же ситуацией.
Вы делаете проект или изменение.
Вроде всё правильно:
- руководство поддержало
- сделали презентации
- написали регламент
- согласовали приказ
А дальше начинается вот это:
- согласования идут через пень-колоду
- люди не хотят ничего менять
- документы подписываются месяцами
- приказ есть, а ничего не происходит
И самый частый вопрос:
«Почему это не работает?»
Ответ обычно неприятный.
Почему это происходит
В таких ситуациях почти всегда отсутствует триада управления изменениями.
Три вещи, которые должны работать вместе:
1️⃣ Управление стейкхолдерами
Вы понимаете:
- кто влияет на проект
- кто может его остановить
- кто может помочь
Но самого анализа стейкхолдеров недостаточно.
Он отвечает только на вопрос «кто важен».
2️⃣ Change Management (ADKAR)
Это уже про другое.
Мы ищем препятствия в голове человека.
Почему он:
- не поддерживает
- тормозит
- саботирует
- молчит на встречах
Важно:
эта методология не налаживает отношения.
Она только убирает барьеры в голове.
3️⃣ План коммуникаций
А вот здесь начинается самое интересное.
Нельзя просто пойти к генеральному и сказать:
«Все вокруг делают ерунду, надо менять».
Так не работает.
Нужно пройти upstream:
- союзники
- касания
- постепенное формирование поддержки
Это очень похоже на продажи.
А потом начинается downstream:
- коммуникация сверху вниз
- внедрение
- закрепление изменений
И здесь уже работает другая логика.
Проблема
Если выкинуть хотя бы один элемент:
- стейкхолдеры
- change management
- коммуникации
всё ломается.
И получается типичная ситуация:
«Проект вроде есть.
Но он никому не нужен.»
Я часто разбираю такие ситуации
И почти всегда причина находится за 20–30 минут диагностики.
Потому что:
- я уже много раз видел одинаковые паттерны
- и знаю где искать проблему
Мы разбираем:
- ваш проект
- ключевых стейкхолдеров
- где именно он буксует
- что нужно поменять
После этого вы понимаете:
- что происходит на самом деле
- где точка управления
и что делать дальше
Дальше есть два варианта
1️⃣ Индивидуальная работа
2️⃣ Небольшая группа (до 5 человек)
В группе мы:
- разбираем инструмент
- применяем его к вашей ситуации
- несколько раз возвращаемся к кейсу
- можно задавать любые вопросы
И вы прямо по ходу программы разворачиваете свою ситуацию.
Если узнали себя
Напишите мне в личку @CIO_Alexey
«Диагностика»
или просто "Привет".
Мы встретимся в Zoom на 1 час (это бесплатно).
Я посмотрю вашу ситуацию
и скажу честно,
можно ли её разрулить или нет.
И подберу оптимальную комбинацию с индивидуальной и групповой работой для вашей ситуации.
Такие проекты встречаются намного чаще, чем кажется.
И почти всегда проблема
совсем не там, где её ищут.
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
#инструменты #метод #изменения #проектноеуправление
Ко мне регулярно приходят с одной и той же ситуацией.
Вы делаете проект или изменение.
Вроде всё правильно:
- руководство поддержало
- сделали презентации
- написали регламент
- согласовали приказ
А дальше начинается вот это:
- согласования идут через пень-колоду
- люди не хотят ничего менять
- документы подписываются месяцами
- приказ есть, а ничего не происходит
И самый частый вопрос:
«Почему это не работает?»
Ответ обычно неприятный.
Потому что вы управляете работами.
А надо управлять людьми.
Почему это происходит
В таких ситуациях почти всегда отсутствует триада управления изменениями.
Три вещи, которые должны работать вместе:
1️⃣ Управление стейкхолдерами
Вы понимаете:
- кто влияет на проект
- кто может его остановить
- кто может помочь
Но самого анализа стейкхолдеров недостаточно.
Он отвечает только на вопрос «кто важен».
2️⃣ Change Management (ADKAR)
Это уже про другое.
Мы ищем препятствия в голове человека.
Почему он:
- не поддерживает
- тормозит
- саботирует
- молчит на встречах
Важно:
эта методология не налаживает отношения.
Она только убирает барьеры в голове.
3️⃣ План коммуникаций
А вот здесь начинается самое интересное.
Нельзя просто пойти к генеральному и сказать:
«Все вокруг делают ерунду, надо менять».
Так не работает.
Нужно пройти upstream:
- союзники
- касания
- постепенное формирование поддержки
Это очень похоже на продажи.
А потом начинается downstream:
- коммуникация сверху вниз
- внедрение
- закрепление изменений
И здесь уже работает другая логика.
Проблема
Если выкинуть хотя бы один элемент:
- стейкхолдеры
- change management
- коммуникации
всё ломается.
И получается типичная ситуация:
«Проект вроде есть.
Но он никому не нужен.»
Я часто разбираю такие ситуации
И почти всегда причина находится за 20–30 минут диагностики.
Потому что:
- я уже много раз видел одинаковые паттерны
- и знаю где искать проблему
Мы разбираем:
- ваш проект
- ключевых стейкхолдеров
- где именно он буксует
- что нужно поменять
После этого вы понимаете:
- что происходит на самом деле
- где точка управления
и что делать дальше
Дальше есть два варианта
1️⃣ Индивидуальная работа
2️⃣ Небольшая группа (до 5 человек)
В группе мы:
- разбираем инструмент
- применяем его к вашей ситуации
- несколько раз возвращаемся к кейсу
- можно задавать любые вопросы
И вы прямо по ходу программы разворачиваете свою ситуацию.
Если узнали себя
Напишите мне в личку @CIO_Alexey
«Диагностика»
или просто "Привет".
Мы встретимся в Zoom на 1 час (это бесплатно).
Я посмотрю вашу ситуацию
и скажу честно,
можно ли её разрулить или нет.
И подберу оптимальную комбинацию с индивидуальной и групповой работой для вашей ситуации.
Такие проекты встречаются намного чаще, чем кажется.
И почти всегда проблема
совсем не там, где её ищут.
Алексей @Management_as_a_Code
как руководителю отстроить эффективную работу и расти с комфортом
#инструменты #метод #изменения #проектноеуправление
👍6🔥6❤5
Channel name was changed to «Management_as_a_Code | Алексей Субботин»
