#инструменты #обомне #истории #надежнаяорганизация #изменения #подкаст

Как я ставил проекты под контроль "с колес"

Всем привет!

Сегодня записал подкаст.
Про то как я в 2000х, на заре своей карьеры топа, впервые ставил под контроль операционную деятельность компании.

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

Приятного и полезного прослушивания!

Ставьте лайки👍, если понравилось - буду еще такие истории записывать.

Удачи вам в ваших проектах 🤝

#инструменты #сценарии #инициативы

Когда к вам приходит сотрудник с инициативой, а ... может лучше не приходил бы?

Вы сидите, мирно пьете кофе, как вдруг к вам подходит сотрудник и говорит:

«А давайте сделаем вот так! Это будет круто!»

Вы: 🤨
Внутри: «Что это? Зачем? Кому нужно? Кто это будет делать?..»
Но внешне: 😌 «Хорошо, расскажи подробнее…»

🎯 Почему даже опытные руководители теряются?
Потому что не всегда понятно:
- Как оценить инициативу?
- Нужна ли она вообще?
- Что делать, если она хороша, но не вписывается в текущие приоритеты?
- И главное — как сказать «нет», не убив мотивацию?

🔍 Шаг 1: Определите, проходная она или нет

Сначала задайте себе ключевой вопрос :
"Интересна ли эта инициатива заинтересованным сторонам?"

Проверьте:
- Соответствует ли она стратегическим целям команды / компании?
- Есть ли у нее потенциальные бенефициары внутри?
- Кто выиграет? Кто проиграет?
- Есть ли у нее шанс на реализацию?
📌 Совет: Посмотрите на инициативу глазами заинтересованных сторон, которых она затронет.

🤝 Шаг 2: Если инициатива проходная

Если инициатива проходная — у нее есть шанс быть реализованной:
- Поймите, с кем нужно согласовать
- Подумайте, кто будет реализовывать

📌 И не забывайте про того, кто её предложил .
Чаще всего инициатор — естественный кандидат на реализацию .
Можно сказать:
«Отличная идея! Давай вместе посмотрим, как это можно запустить. И, возможно, ты будешь вести эту инициативу.»

Так вы:
- Повышаете вовлеченность
- Даёте человеку пространство для роста
- Снимаете с себя часть нагрузки

🚫 Шаг 3: Что делать, если инициатива "не проходная"?

Да, иногда идея — отличная. Но время сейчас - не то, ресурсы заняты, приоритеты другие.

Тогда:
- Не отбрасывайте её сразу
- Объясните человеку причину отказа
- Если это имеет смысл - предложите вернуться к ней позже (или в другом контексте)
Скажите:
«Это хорошая идея, но сейчас мы не можем на неё сосредоточиться. Давай запомним ее и вернёмся, когда будет возможность.»
💡 Так вы не убиваете мотивацию, а переносите её в нужное русло .

🧠 Почему это важно?
- Инициативы — это топливо для развития .
- Даже если они не реализуются сразу — они показывают, где у команды интересы, где потенциал роста.
- Правильная реакция на инициативу формирует доверие .
- Люди видят, что их слышат. Даже если им говорят «нет».

📌 Инициативы — это не проблема, а возможность.
Главное — правильно их принимать.

Удачи, и чтобы к вам сотрудники приходили только с полезными инициативами 😊

#инструменты #сценарии #инициативы #надежнаяорганизация

💡 Как найти инициативы, если их никто не предлагает?
(А шеф сказал: «Сократите расходы на 10%»)

Представьте: приходите вы к себе в отдел, садитесь и думаете — «Куда копать?»
На самом деле ваши сотрудники знают это лучше вас.
Они видят лишнее, дублирование, перерасход.
Нужно просто это вытянуть.

👇 Вот как это работает:

🔹 1. Соберите команду

Поговорите честно. Не с приказом, а с объяснением.

🔥 2. Используйте управление изменениями по ADKAR

Проведите как минимум через 2 стадии ADKAR (осведомленность и желание), чтобы команда поняла неизбежность изменений и была готова активно в них участвовать.

Закончить можно в стиле "Если не мы - то кто за нас?"
"Если мы сами не выберем, где сократить — выберут за нас.
Финансисты? Шеф? Внешние консультанты?
…А они не знают вашу реальность."

🌀 После шока наступит осознание.
И тут начинается самое интересное.

🧠 3. Люди начнут предлагать

- Фиксируйте все инициативы !
- Не отсеивайте сразу просто записывайте.

⚠️ Но не бросайтесь реализовывать всё подряд .
Сначала — оценка:

📊

- Какой потенциал у каждой инициативы по сокращению затрат?
- Что нужно для выполнения?

🎯 4. Приоритизируйте и отберите ТОП инициатив

Выберите лучшие — с запасом .
Потому что при детальном анализе:
…обещанные 5% часто превращаются в 2%.
А то и меньше.
Никакие инициативы не выбрасывайте .
Они пригодятся, если не хватит объёма.

🚀 5. Действуйте

Короткие задачи — делайте быстро.
Длинных сразу много не запускайте. Лучше быстрее их закончить. Используйте "формы" процесс-тайчи.
Самые масштабные — запускайте как проекты по всем правилам проектного управления.

✅ Инициатива - это не всегда гениальная идея.
Часто просто чья-то боль, которую наконец услышали.

А в пятницу - будет #подкаст про методику управления реализацией этих инициатив, которая:
- используется топовыми консалтинговыми фирмами
- может быть адаптирована под компанию любого размера

💡 Удачи в поиске инициатив!
Главное — начать. Остальное приложится.

#инструменты #сценарии #инициативы #надежнаяорганизация #подкаст

Воронка оптимизационных инициатив

Всем привет!

В прошлый раз мы рассматривали, как генерировать инициативы, когда вам шеф сказал "Порезать расходы на 10%".
Сегодня - посмотрим как управлять их реализацией.

Расскажу о практике, которую используют топовые консалтинговые компании и крупные корпорации.

Эта практика позволяет реализовать воронку оптимизационных инициатив, которая доводит портфель гипотез до необходимого результата.

Но на самом деле здесь нет никакого rocket science.
И эту методику можно адаптировать под компанию любого размера.

🛠 Кстати. Могу помочь вам и вашей команде:
🔹сформировать портфель инициатив
🔹организовать процесс управления ими, по методике описанной в подкасте
🔹пройти по этой воронке и довести эти инициативы до результата
Если интересно - пишите @CIO_Alexey - обсудим.

Приятного и полезного прослушивания 🤝

#отзыв #метод #кейсы

Вот, кстати и отзыв о диагностике

Всем привет!

Сегодня не обычный пятничный пост.

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

https://www.youtube.com/live/aBThQKw8U9w?si=qJrqIktx_DYOHKfW

#инструменты #сценарии #проектныйминимум

Всем привет!

Сегодня - новая тема и новый формат.

Начинаем рассматривать базовые инструменты
классического проектного управления,
которые я назвал #проектныйминимум.

Это легкий минимальный набор инструментов,
который позволяет спокойно и структурированно
вести проекты:
🔹применим и к самым маленьким проектам
🔹поможет структурировать и сложный проект
🔹требует минимум усилий и бюрократии.

И сегодня пробуем новый формат -
видеопрезентация.

За 5 минут дам обзор
"классической механики управления проектами".

А в следующих постах будем рассматривать
конкретные инструменты.

Оставайтесь, читайте, рекомендуйте!

Приятного и полезного просмотра! 🤝

#инструменты #сценарии #проектныйминимум

📄 Что такое Устав проекта? И зачем он нужен?

Сегодня поговорим об одном из самых первых инструментов проектного менеджмента, который используется для определения проекта.
Об Уставе проекта.

📌 Зачем нужен Устав?
- Чтобы чётко определить, что мы делаем, зачем и для кого.
- Чтобы все заинтересованные стороны понимали проект одинаково
- Чтобы с самого старта избежать недопонимания, "а я думал, это не входит", "а я думал, это мы не делаем".

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

1️⃣ Название и идентификаторы проекта
🔹 Название проекта
🔹 Код, номер, ID
🔹 Краткое описание (1–2 предложения)

Пример:
Проект "Оптимизация бюджетирования-2025", ID: BUDG-2025-01

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

2️⃣ Цели проекта
Что мы хотим достичь?
Цели должны быть измеримыми и чёткими.
Должно быть однозначно понятно - достигли мы цели или нет.

✅ Правильно:
Снизить операционные затраты на 15% к концу года за счёт автоматизации процессов.

❌ Не правильно:
Сделать всё лучше и дешевле.

3️⃣ Результаты проекта (выходы)
Что материальное или нематериальное мы получим в итоге?

⚠️ Не путать с целями!
- Цель: снизить затраты на .... к ...
- Результаты: новый регламент, настроенная система, обученная команда, ...

Примеры:
- Внедрённая система учёта расходов
- Обновлённый процесс бюджетирования
- Команда, прошедшая обучение по новым стандартам

4️⃣ Заинтересованные стороны (стейкхолдеры)
Кто влияет на проект и на кого он влияет?

📌 Важно:
— Кто принимает, согласовывает, готовит решения?
— Кто использует результат?
— Кто может заблокировать проект?

Пример:
- Финансовый директор (заказчик)
- IT-департамент (исполнители)
- Комитет по бюджету (утверждает)
- Бухгалтерия (конечный пользователь)

> 💬 С ними можно и нужно работать, договариваться, управлять ожиданиями

5️⃣ Факторы, влияющие на проект
Это внешние условия, на которые вы не можете повлиять, но которые влияют на вас.

📌 С ними нельзя договориться, но можно к ним подготовиться.

Примеры:
- Изменение законодательства
- Колебания курса валют

💡 Фактор ≠ стейкхолдер.
Действия правительства - фактор (с ними не поговоришь).
Зам генерального - стейкхолдер (можно договориться).

6️⃣ Границы проекта
Что входит и что не входит в проект?

Это главное оружие против scope creep ("а давайте ещё и это сделаем").

📌 Чётко пропишите:
✅ Что делаем:
- Автоматизация учёта расходов
- Обучение 50 сотрудников
- Интеграция с 1С

❌ Что НЕ делаем:
- Не меняем учётную политику
- Не трогаем систему мотивации
- Не апгрейдим сервера

Так вы избегаете споров вида:
"А почему вы не сделали X? Это же логично!"

7️⃣ Предположения
Что мы считаем данным, планируя проект?

📌 Это то, что *пока* верно, но может измениться.

Примеры:
- Ключевые сотрудники будут доступны 80% времени
- Система-источник данных будет готова к интеграции в Q3
- Бюджет будет утверждён до старта
- Не планируется реорганизация

Если предположение не сработает - это риск, которым надо управлять.

8️⃣ Ограничения
Что нельзя делать или в чём мы ограничены?

Примеры:
- Нельзя останавливать старую систему до полного перехода
- Бюджет — не более 5 млн руб.
- Срок — не позже 30 ноября
- Только внутренние ресурсы (без привлечения подрядчиков)

9️⃣ Особенности управления проектом
Как устроен процесс управления?

- Роли: кто руководитель, кто спонсор, кто команда
- Процедуры: как принимаются решения, кто утверждает план
- Документы: какие отчёты, планы выпускаются
- Совещания: еженедельный статус, комитет по проектам
- Коммуникации: как и с кем обмениваемся информацией

Это особенно важно, если в компании нет стандартов проектного управления

🛠 Чем чётче Устав — тем меньше споров, тем выше шанс на успех.

#истории #обомне #проектныйминимум

Как классика проектного управления помогла мне стать топом.

Это был 2003 год.
К тому времени я уже лет 6-7 занимался проектным управлением
и наизусть знал тогдашний PMBoK
(свод знаний по управлению проектами).

И когда мне предложили должность COO (исполнительного директора) в строительной компании,
я с одной стороны был очень рад, с другой - готовой системы у меня в голове не было.

Моя ответственность - маржа по всем контрактам,
Но найти что-то про Operations Management или что-то подобное на тот момент не вышло.

И я решил, что раз там в основном проекты -
начнем с процессов проектного менеджмента.

И это сработало.
Я выстроил свою первую "операционку" в крупной компании.

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

У меня того издания не осталось,
поэтому терминология по памяти 😁

1️⃣ Управление содержанием

Отсюда я взял ее величество WBS
(Work Breakdown Structure,
иерархическая структура работ).

Понимал или не понимал я содержание,
я просил его структурировать в таком виде.

На эту иерархическую структуру потом навешивалось все - сроки, стоимость, ресурсы, ответственные, ...

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

Уже одно это дало мне большую прозрачность,
чем моим предшественникам

2️⃣ Управление сроками

Я был "королем сетевых графиков" 😂,
мог делать их практически со слов.

И после таких мастер классов по критичным проектам
руководители проектов стали учиться их делать.
Я получил прозрачность сроков, которой не было.

3️⃣ Управление стоимостью и ресурсами
Бюджеты стали оцениваться через ресурсы и в разрезе WBS.
У меня появилась возможность задавать кучу вопросов,
не понимая даже всей техники.

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

4️⃣ Управление рисками

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

И когда в какой-то момент пришли финансы с запросом о расчете резервов,
я выдал им их за 5 минут.
Потому, что они всегда были посчитаны.

5️⃣ Заинтересованные стороны
Я просто структурировал все "знание заказчика" и "статус теркинга",
который вели мои руководители проектов
и всегда был в курсе и видел общую картину.

6️⃣ Управление коммуникациями
Там просто были таблицы - коммуникационные планы.
И я прекрасно знал по какому проекту,
кому, кто когда пишет письма,
какие совещания проводятся и встречи.

7️⃣ Управление закупками
Хе, на тот момент в PMBoK зарисовали
лучшие практики конкурентных закупок.

Которые понятное дело в РФ в начале 2000х были редкостью.

У меня был реестр субподрядчиков, процедуры выбора
и цены я стал получать на 10-20% ниже чем ожидалось.

Не знал на тот момент как это делалось в бизнесе,
а не в стандартах по управлению проектами, но сработало.

Как то раз даже игру на конкурентные торги проводил
на семинаре в Российской Ассоциации управления проектами.

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

Удачи вам в ваших проектах 🤝

#обомне #метод #кейсы #подкаст

Привет!

Сегодня - день открытых дверей 😊.

Покажу, как организована индивидуальная работа.

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

Результат - не просто «понять»,
а научиться делать
и сделать.

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

И с моей поддержкой достигли своих целей.

👉 Работа строится по модулям — каждый дает вам конкретный результат:
- решаете конкретную проблему в вашей работе
- получаете и отрабатываете набор навыков для решения задачи

Каждый модуль включает:
🔹 3–6 часов личных консультаций со мной, где мы тренируемся, разбираем вашу ситуацию, вопросы, результаты и то, что негде прочитать
🔹 Инструменты, готовые для применения (шаблоны, чек-листы, инструкции, ...)
🔹 12 -80 часов самостоятельной практики для получения навыков и решения ваших задач. Вы применяете инструменты в работе, с реальными людьми, в реальных ситуациях.
🔹 Ответы на вопросы и поддержка в чате
🔹 Материалы для самостоятельного изучения (то что можете прочитать сами)

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

Например, если нужно понять,
как вы общаетесь с подчинёнными,
мы разыгрываем проблемную ситуацию, где:
Я — сотрудник, Вы — руководитель.
Потом разбираем: что сработало, что нет.

А в подкасте рассказал про один кейс: какого результата мы достигли за один модуль.

Стоимость фиксируется за модуль.
Будем работать сколько надо, пока не получим запланированный результат.
Обычно при темпе встреч 3-4 в месяц модуль занимает от 3 до 8 недель

Хотите узнать, как это поможет достичь ваших целей? 👇

1️⃣ Заполните анкету https://forms.yandex.ru/u/689337cc90fa7b31ce601a00
2️⃣ Я свяжусь с Вами и мы договоримся о встрече
3️⃣ Мы с Вами проведем диагностику (1 ч, Zoom, бесплатно).
4️⃣ По итогам Вы получите
- план достижения ваших целей
- содержание первого модуля, который даст первый значимый результат на этом пути

После этого сможем начать работу.

Остались вопросы?
Пишите в личку @CIO_Alexey

Хороших выходных, на связи 🤝

#инструменты #сценарии #проектныйминимум

🗺 План по вехам: как не делать всё «в одну ночь»

Вы когда-нибудь видели, как в конце проекта вся команда впадает в состояние подвига?
- Спят по 3 часа.
- Правят документы в 5 утра.
- Сдают результат, который месяц не могли собраться сдать.

Кажется, это национальная особенность, как минимум в российской практике управления проектами.
Но есть способ избежать этого хаоса.
И зовётся он — План по вехам.

🔧 Что такое план по вехам?

Это простой, но мощный инструмент управления сроками.
Он работает и для простых проектов, и для сложных.

💡 Главное его преимущество:
Он показывает лес, даже если за календарными графиками не видно деревьев.

Когда детальные графики (типа Gantt) перегружены задачами,
вехи помогают увидеть суть — ключевые точки, где что-то действительно важное происходит.

🎯 Зачем он нужен?

1. Разбивает «финальный подвиг» на серию маленьких побед
Вместо одного рывка в конце — последовательные дедлайны,
каждый из которых можно контролировать.

2. Даёт чёткие ориентиры
Не «вроде что-то делаем», а «на этой неделе — решение утверждено, на следующей — система протестирована».

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

4. Снижает риски
Если веха проседает — видно сразу, а не за день до дедлайна проекта.

📋 Из чего состоит план по вехам?

Каждая строка — это веха (она же контрольная точка, milestone).
И у каждой — чёткая структура:

🔹 Идентификатор вехи
Особенно важно в больших проектах.
Пример: M1, VH-03

🔹 Название вехи
Коротко и ясно. Лучше — в формате достижения:
- ✅ *Проект утверждён*
- ✅ *Система внедрена*
- ✅ *Обучение завершено*
- ❌ *Работа над системой* — это не веха, это процесс.

🔹 Описание
Что конкретно считается выполненным на этой вехе?
- Какие результаты получены?
- Какие решения приняты?
- Кто их утвердил?

Примеры:
Внедрена система учёта затрат.
Подписано решение комитета по ИТ.
Обучены 20 пользователей из финансового блока.

🔹Критерии достижения
Чёткий чек-лист: что должно быть сделано, чтобы веха считалась пройденной.

Пример:
[ ] Отчёт с результатами тестирования утверждён директором ИТ
[ ] Подписан акт приёмки от заказчика
[ ] Документация передана службе поддержке

💡 Этот список — живой. Его нужно обновлять и регулярно проверять.

🔹Ответственный
Кто гарантирует достижение вехи?

Чаще всего - один человек.
Если ответственных несколько - возможно, веху стоит заменить на несколько.

🔹Срок
Дата, к которой веха должна быть достигнута.

⬆️ Уровни вех

Можно ввести уровни:
- Вехи 1 уровня — стратегические, контролируются и изменяются топ-менеджментом (например, гендиректором), заказчиком или комитетом
- Вехи 2 уровня — тактические, контролируются, отслеживаются и изменяются руководителем проекта

Пример:
VH-1 (уровень 1): Проект запущен, бюджет утверждён
VH-2 (уровень 2): Техническое задание согласовано
VH-3 (уровень 2): Пилот внедрён в одном подразделении

✅ Почему это работает?

План по вехам:
- Не перегружает деталями
- Фокусируется на результатах, а не на процессах
- Позволяет управлять ритмом, а не только гореть в финале
- Делает прогресс видимым — для команды, для заказчика, для

🧩 Итог
План по вехам — это мини-карта проекта.
Он не заменяет детальный график, но акцентирует внимание на самом важном.
А в некоторых проектах детальный график и не нужен - достаточно плана по вехам.

📌 Совет: Начните с 5–7 ключевых вех.
Потом можно детализировать.
Главное — двигаться от точки к точке, а не лететь вслепую к финалу.

#обомне #метод #кейсы #отзыв

С какими запросами ко мне приходят
руководители и те кто ими хочет стать?🤔


Разброс очень большой.
Каждый видит свою ситуацию по-разному.

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

Вот примеры:

🔹"Хочу занять более высокую руководящую должность,
но боюсь не справлюсь"

🔹"Руководил командами, хочу продолжить карьеру
менеджером центрального аппарата
[очень большой компании].
Какие навыки будут нужны, как там работать и расти?"

🔹"Предлагают должность руководителя,
но боюсь не справлюсь"

🔹"Я топ-менеджер.
Акционеры видят мою работу по-разному.
Как мне работать в такой ситуации?"

🔹"Управляю проектами слаботочных систем 15 лет.
Хочу управлять ИТ-проектами.
Надо развить для этого свои навыки"

🔹"Пришел новый руководитель,
как мне выстроить с ним отношения?"

🔹"Меня назначили ответственным за внедрение системы,
но никто не хочет переходить со старой.
От руководства поддержки нет. Что мне делать?"

🔹"Я делаю свою работу быстрее и лучше многих.
А руководитель отмечает их, а не меня"

🔹"Хочу научиться выстраивать процессы,
чтобы перестать рулить своим бизнесом в ручном режиме"

Узнали свою ситуацию?

Заполните форму и приходите на диагностику (1ч, Zoom, бесплатно).

Уйдете с планом разрешения Вашей ситуации.

А если захотите - реализуем его вместе.

Остались вопросы? Напишите мне @CIO_Alexey, жду 🤝

#инструменты #сценарии #проектныйминимум

🧩 Матрица ответственности: кто что делает в проекте?

Сегодня — ещё один важный инструмент из проектного минимума:
Матрица распределения ответственности.

Она помогает ответить на главные вопросы:
- Кто принимает решения?
- Кто согласовывает?
- Кто выполняет?
- Кто должен знать, что происходит?
- Кто что делает?

Когда процессы и процедуры
не прописаны на каждый случай
(а в проектах почти всегда так),
эта матрица становится основой порядка.

По сути она позволяет фиксировать
правила применения 2х механизмов взаимодействия:
- взаимное согласование
- прямое руководство

📌 Самая популярная — матрица RACI

Каждая буква — роль :
R (Responsible / Исполнитель) | Тот, кто делает работу | Выполняет задачу
A (Accountable / Ответственный) | Тот, кто несёт финальную ответственность | Утверждает результат, один на задачу, «подписывает»
C (Consulted / Консультирующий) | Кто согласовывает или дает вводные | Эксперт, чьё мнение важно перед решением
I (Informed / Информируемый) | Кто должен быть в курсе | Получает информацию после решения или действия, но не участвует

✅ Пример:
Утверждение технического задания
R ведущий аналитик (составляет ТЗ)
A руководитель проекта (утверждает)
C ИТ-архитектор (согласует по технической части)
I специалист закупок (узнаёт, когда ТЗ готово)

🔄 А бывает ли не RACI?

Конечно! RACI — самый известный, но не единственный формат.

DACI
Полностью другая логика — заточена под принятие решений, а не выполнение задач.

D — Driver (Инициатор) | Запускает процесс, ведёт к решению
A — Approver (Утверждающий) | Единственный, кто может сказать «да»
C — Contributor (Участник, согласующий) | Даёт данные, мнение, расчёты
I — Informed (Информируемый) | Узнаёт после решения

📌 Где полезно:
— Стратегические решения
— Комитеты, советы директоров
— Когда важно не кто делает, а как принимается решение

Пример: выбор поставщика
D — руководитель проекта
A — финансовый директор
C — закупки, юристы, технический отдел
I — смежные подразделения

😄 А были ли креативы?

Были!
Один раз видел матрицу «ПУСИ» на русском:
П — Предлагает
У — Утверждает
С — Согласовывает
И — Информируется

Юмористично, но работает, если все понимают значения.

💡 Главное — не буквы, а смысл

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

✅ Вывод

Матрица ответственности — это не бюрократия, а инструмент ясности.

Особенно важна в проектах, где:
- Много людей
- Нет чётких процессов
- Участники из разных подразделений

Включайте её в устав (в раздел Особенности управления проектом)
и будет больше порядка.

#советы #сценарии #коммуникации

🚫 Лучшее совещание — это предотвращенное совещание

Всем привет!

Сегодня перерыв в теме проектного менеджмента
— поговорим о совещаниях.

А точнее - как их не проводить.
Ну и в каких крайних случаях - можно 😊

Потому что, если честно, то мое мнение:
Лучшее совещание — это предотвращённое совещание.

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

А забитый совещаниями график выматывает многих.

Особенно если эти совещания - пустая трата времени.

🧼 Мой подход: 4 фильтра-вопроса

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

Если на любой из них ответ «нет» —
совещание либо не нужно,
либо его нужно срочно переосмыслить.

1️⃣ Зачем это совещание?
👉 Кто инициировал — может ли чётко объяснить цель?

Если инициатор говорит:
«Ну, надо просто пообщаться»
«Соберёмся, посмотрим»
— скорее всего, совещание не нужно.

Цель должна быть:
✅ Принять решение
✅ Согласовать позиции
✅ Запустить действие
✅ Разрешить конфликт

Без цели — это не совещание. Это слив времени в никуда.

2️⃣ Зачем Я на этом совещании?
👉 Могу ли я внести вклад в цель?

Если я не принимаю решение,
не эксперт по теме, не исполнитель —
возможно, я просто пассивный зритель.

А это:
- Теряю своё время
- Мешаю своими комментариями

📌 Правило:
Если не влияешь на результат — не приходи.

3️⃣ Могу ли я внести свой вклад без участия в совещании?
👉 Смогу ли я дать обратную связь, согласовать, предложить — по почте, в чате, в коротком звонке?

Часто ответ — да.
И тогда:
✉️ Напиши письмо
💬 Отправь комментарий
📞 Позвони инициатору

4️⃣ Как это будет происходить?
👉 Есть ли дизайн совещания?

Если нет чёткой структуры — будет хаотичный разговор, который:
- Ни к чему не приведёт
- Потребует ещё одно совещание
- А потом ещё одно… и ещё…

Минимальный дизайн — это:
- Чёткая цель (да, снова)
- Образ результата (с чем уйдем)
- Сценарий получения результата
- Тайминг прохождения сценария


✅ Когда совещание действительно нужно?

Когда:
- Не получается договориться в переписке
- Не решается один на один
- Нужно синхронизировать несколько позиций
- Есть конфликт, неопределённость, необходимость быстрого решения

Но даже в этом случае — обязателен дизайн.
Без него — не совещание, а потраченное время.

💡 Итог

Прежде чем идти на встречу — задай себе 4 вопроса:
1. Зачем это совещание?
2. Зачем Я на нём?
3. Могу ли внести вклад без участия?
4. Как это будет происходить? Есть ли дизайн?

Если на все «да» - встреча имеет право на жизнь.
Если нет - отмени, не приходи, попроси уточнить ответы на эти вопросы.

Поменьше вам совещаний🤝

#инструменты #сценарии #проектныйминимум

🔁 Интегрированное управление отклонениями:
риск → проблема → изменение

Вы когда-нибудь видели, как в больших проектах одновременно летают:
- Риски
- Проблемы
- Запросы на изменения

…и все они про одно и то же, но ведутся в разных реестрах, с разными карточками, разными процессами?

Команда путается:
«Это риск? А, нет — это уже проблема… А, стоп, а мы уже изменили срок? И где искать историю?»

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

Ведь мы рассматриваем "проектный минимум",
а не максимально сложные инструменты 😊.

🧩 Главная идея

Риск, проблема, изменение — это не три разные сущности.
Это три состояния одного и того же объекта — отклонения.

Представьте: отклонение "путешествует" по временной оси.
И по мере развития ситуации меняет своё состояние:
Риск → Проблема→ Изменение

1️⃣ Риск
🔸 Событие ещё не произошло
🔸 Вероятность < 100%
🔸 Можно предотвратить или смягчить

🎯 Пример:
«Возможна задержка поставки оборудования — вероятность 40%, сроки сдвинутся на 30 дней»

📌 Это потенциальное отклонение. Мы его видим в будущем и готовимся.

2️⃣ Проблема
🔸 Событие уже произошло
🔸 Но последствия — ещё нет
🔸 Можно что-то сделать!

🎯 Пример:
Поставщик подтвердил: оборудование не успевает. Но можно ли сократить задержку?

📌 Это активная борьба. Вы:
- Звоните поставщику
- Ищете альтернативные маршруты
- Пересматриваете график

Цель — предотвратить или минимизировать последствия.

3️⃣ Изменение
🔸 Последствия наступили
🔸 Вероятность = 100%
🔸 Ничего изменить нельзя — только адаптироваться

🎯 Пример:
Оборудование приедет с опозданием на 5 дней. Сроки проекта сдвигаются.

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

🔁 Почему это удобно?

Вместо трёх отдельных процессов — один жизненный цикл отклонения:

Идентифицирован риск - Он реализовался - Стал проблемой - Не удалось смягчить последствия - Зафиксировали изменение.

✅ Все данные — в одном месте
✅ Чёткая логика перехода между статусами
✅ Нет дублирования и путаницы

📈 Как меняется "вероятность последствий"?

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

И эта вероятность меняется по ходу:

- Был риск → вероятность последствий: 40%
- Реализовался → стало проблемой → вероятность: 80%
- Нашли обходной путь → вероятность: 30%
- Закрыли проблему → вероятность: 0%
- Или приняли изменение → вероятность: 100%

🎯 Так вы видите динамику угрозы — от предположения до финала.

💡 Когда это особенно полезно?
Да как и все в рубрике "проектный минимум" 😊

- На начальных этапах внедрения проектного управления — проще использовать
- В небольших проектах — нет смысла грузить сложными системами

✅ Вывод

Интегрированное управление отклонениями — это не только про инструменты.
Это про мышление.

Когда вы видите:
«У нас проблема со сроками»
вы понимаете, что это стадия развития отклонения,
а не отдельная катастрофа.

И можете спокойно сказать:
«Ок, это была инициирована риском X. Сейчас мы в статусе "проблема". Цель — снизить вероятность последствий до 0. Если не получится — фиксируем изменение и идём дальше».

Управляемых рисков вам.
И чтобы они не становились проблемами🤝

Всем привет!

А накидайте пожалуйста в комментарии идей, о чем вы хотели бы почитать?🙏
Если будет много - устроим голосование, и 2-3 топовых постараюсь в сентябре раскрыть.

@pchelyakov_petr спасибо за идею🤝

#инструменты #проектныйминимум

WBS — не дерево. Это основа порядка в проекте.

Продолжаем рубрику "проектный минимум".

Сегодня об инструменте,
без которого нет
настоящего проектного управления.

Знакомьтесь:
Ее Величество WBS (Work Breakdown Structure),
она же - ИСР = Иерархическая структура работ,
она же - СДР = Структурная декомпозиция работ.

🔹 WBS — это основа порядка
Представьте: в проекте куча задач, людей, денег, рисков, документов…
Без структуры — это хаос.

А WBS даёт структуру.
Она разбивает проект на логические части — от крупного к мелкому.
И именно она становится единой системой координат для всего проекта.

🔹Это не дерево. Это многомерный классификатор

Обычно WBS рисуют как дерево:
например "проект → подсистемы → работы".

Но я смотрю на это иначе.

👉 WBS - это не обязательно древовидная структура.
Это - многомерный классификатор.

Каждый элемент можно описать по разным осям:
- Объект (здание, этаж, линия)
- Система (локальная сеть, электроснабжение, пожарная сигнализация, .... )
- Вид деятельности (проектирование, монтаж, пусконаладка)
- Стадия жизненного цикла (подготовка, строительство, сдача)

И любой элемент проекта:
задача, ресурс, документ, риск, акт, платеж, дефект, поручение, ...
привязывается к этой структуре,
т.е. имеет все эти классификационные признаки

🔹На эту структуру «навешивается» всё
- Сроки (календарный план)
- Стоимость (бюджет, фактические затраты)
- Ресурсы (люди, оборудование)
- Ответственные
- Риски, документы, дефекты, изменения, ...

👉 И тогда, тыкнув в элемент,
например, «монтаж щита электроснабжения на 3-м этаже»
а точнее, найдя строчку:
Вид деятельности = Монтаж
Система = Электроснабжение
Объект = 3 этаж
Стадия = Строительство

ты видишь всё:
- кто работает,
- сколько потрачено,
- какие риски,
- есть ли замечания,
- какие документы пришли.

Единый источник правды.

🔹 Контраст с ее отсутствием - кардинальный
Без нее:
- Планы были в одном разрезе (по времени),
- Бюджеты — в другом (по статьям расходов),
- Ресурсы — в третьем (по подразделениям),

А свести всё вместе — никто не может.

👉 А когда просто построил WBS и привязал всё к ней.

Уже одно это дает прозрачность,
которой не было до этого.

Видишь, сколько стоит
конкретная работа
на конкретном объекте,
кто и сколько времени на неё тратит.
где риски, где отставания.

🔹 Можно «выкрутить» под любой взгляд

Одно и то же все хотят видеть по-разному:
- Заказчик — хочет видеть прогресс по продуктам и результатам
- Функциональный руководитель — интересуется, что делают его инженеры
- Руководитель объекта — следит за всем, что происходит на его площадке

👉 А ты просто меняешь «представление».

Простейший вариант в Excel:
сводная таблица по объектам, по видам работ, по стадиям…

И каждый видит то, что ему нужно.
Не говоря уже о специальных инструментах.

И вот именно это достигается,
когда смотришь на WBS
не как на дерево,
а как на многомерный классификатор.

💡 Почему это важно?

Потому что:
WBS — это не просто структура.
Это каркас всего проектного управления.

Без неё:
- Нет прозрачности
- Нет контроля
- Нет целостности данных
- Собрать новое представление - челлендж
(я еще помню как люди чемоданы бумаг с объектов возили)

С ней:
- Любой артефакт — на своём месте
- Любой запрос — за секунды
- Любой отчёт — по кнопке (ну или почти)

Вывод простой

Если у тебя нет WBS — у тебя нет проекта.
Только активность.

А управление — начинается со структуры.

А есть понятная структура -
места для стресса и волнений становится меньше,
а эффективность тихо приходит на их место.

Структурности вам в проектах, которая приведет к успеху!🤝

@Management_as_a_Code
канал про эффективное и комфортное управление

#инструменты #советы #надежнаяорганизация

10 стримов руководителя при входе

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

Как руководителю войти в новую организацию
эффективно и комфортно?

Был период, когда мне
приходилось делать это очень часто.
И как топу, и как консультанту с функциями топа.

Меня давно просят написать
про "10 первых шагов руководителя".

Но их нет.
Есть стримы, которые работают параллельно.
Причем что-то делается за неделю,
а что-то продолжается до
полной отстройки системной работы.

Но все они могут начаться сразу.

И первый день может определить
ваш "вход".

👉"Вот он вошел и стало ясно,
кто эксклюзивный дистрибьютор"

Хотите также заходить
на новую должность?
в новую компанию?

Тогда - поехали ...

Итак, 10 входных стримов руководителя.

1️⃣ Стрим 1: Мой руководитель
- что надо сделать, какие итоги через год
- кто заинтересованные стороны:
заказчики, ключевые подрядчики, коллеги, минус один, акционеры

2️⃣ Стрим 2: Знакомство со своей командой
- представиться
- зачем пришел - что хотим сделать
- если людей немного - можно попросить представиться
- встречи 1 на 1 обязательно

3️⃣ Стрим 3: Знакомство с командой в которой я
(команда моего босса)
- представиться
- встречи 1 на 1 обязательно (отношения формируются 1 на 1): знакомимся с человеком, ищем кто будет нашим "проводником" при адаптации в компании

4️⃣ Стрим 4: Знакомство с заинтересованными сторонами
- встречи 1 на 1 - выясняем все про них

5️⃣ Стрим 5: Знакомство с матчастью
- стратегии
- отчетность
- данные
- системы
- продукты
- процессы, регламенты, правила, ....
- учебники, курсы по тому что не знаешь
- гембы

6️⃣ Стрим 6: Постановка под контроль
- понять самые важные точки - платежи, документы, КПЭ, премии
- замкнуть на себя (возможно первое время что-то лишнее наберем)

7️⃣ Стрим 7: Выяснение как работают правила
и каковы реальные приоритеты
- насколько практика соответствует написанному
- что на самом деле важно
- как работает
- наблюдение, чтобы отделить
сиюминутные горящие вопросы,
про которые все забудут через неделю
от действительно важных вещей

8️⃣ Стрим 8: Планирование будущего
- разработка видения, стратегии
- обкатка с командой
- обкатка с коллегами
- обсуждение элементов с руководителем
- обкатка с заинтересованными сторонами
- представление самому-большому-боссу

9️⃣ Стрим 9. Создание системы
- правила взаимодействия, процессы - их целевое состояние, план перехода
- подготовка и проведение изменений по ADKAR
- перевод системы управления в целевое состояние

🔟 Стрим 10: Делегирование в рамках системы управления
- подготовка подчиненных к приему функций и полномочий
- то что перехватили на контроль делегируем, но уже в рамках построенной системы


Хотите, запишу подкаст,
где расскажу подробнее?

Ставьте лайки, чтобы
я понял, что интересно!

Удачи вам на входе 🤝

@Management_as_a_Code
канал про эффективное и комфортное управление

#инструменты #проектныйминимум

Минималистический подход к системе управления проектом
Простой способ сэкономить время и силы

Многие мечтают об "идеальной" системе управления проектами:
- Планы детализированы до трудозатрат каждого сотрудника
- Все риски, документы, задачи и изменения связаны между собой
- Всё автоматизировано, всё на виду

Звучит круто.
Но на практике такая система стоит дорого
и не только в деньгах, но и в усилиях на поддержку.

А еще и сбоит, если не все участники идеальны.

А что, если можно получить почти те же преимущества,
но с меньшими затратами?

👉 Идея проста:
Вместо того чтобы вязать каждый документ, риск и задачу в единую сеть, объединим их по группам — по элементам структуры работ (WBS).
По нижнему уровню WBS, привязывая к тому самому элементу, имеющему все коды.
Его будем называть (как это принято) "пакетом работ".

То есть:
не “задача → документ → риск → человек”,
а “всё это — к пакету работ X.Y.Z”.

И детализируем не сразу,
а по мере необходимости.

👉То есть не связи между задачами, рисками, документами ...
А просто все что относится к пакету работ
- привязано к нему:
10 документов, 20 задач, пара рисков...
Вполне можно разобраться "глазками" минут за 5.


Пример из практики: системный интегратор в энергетике
У нас были планы по:
- Объекту (здание, площадка)
- Системе (КРУЭ, видеонаблюдение, АСУ ТП)
- Виду работ (монтаж, пусконаладка, проектирование)

Но! Нужно было управлять загрузкой своих инженеров — с точностью до человеко-дней.

Вариант 1: детализировать планы до каждой задачи каждого сотрудника
- громоздко, долго, дорого в поддержке

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

Что получили?
✅ Гибкость: детализируем только там, где нужно
✅ Статистику по трудозатратам для оценки по аналогу
✅ Ответы на ключевые вопросы: кто чем занят, сколько потрачено, какая загрузка
✅ Связь данных через единые коды проекта и пакета работ

⚠️ Да, часть анализа — ручная. Но сопоставить 10 строк из плана и 20 назначений - 5 минут, а не часы на обновление детализированного графика.

И самое приятное:
🔹 Внешние заказчики думали, что у нас супер-детализация
🔹 Мы экономили кучу времени и ресурсов

А что с рисками, изменениями, документами?
То же самое:
— Все реестры (риски, дефекты, письма, финансовые документы) — с кодами проекта и пакета работ
— При проблеме — быстро выгружаем всё по нужному пакету и видим полную картину

📊 В Excel — легко строим стоимостные отчёты по проектам и даже по отдельным работам.

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

Вы можете:
- Начать с высокого уровня (объекты-системы)
- Постепенно детализировать (до отдельных задач)
- Менять уровень детализации гибко, под задачу

Главное — единая система кодировки и простые правила.

💡 Это не отказ от управления.
Это умный баланс между точностью и реальными затратами.

Простота дает эффективность и комфорт в управлении.

Удачи в упрощении! 🤝

@Management_as_a_Code
канал про эффективное и комфортное управление