Что делать, когда нельзя но хочется?

Критическая цепь говорит "Если хочешь выполнять все проекты вовремя, то сделай чтобы у тебя не было плохой многозадачности".

Это конечно хорошее правило, но что делать когда:
1. Компания сервисная (проекты под заказ, типа: Проектирование, ИТ)
2. Сроки диктует Заказчик.
3. Мы берем все контракты которые можем взять.
4. Присутствует сезонность,то есть "то густо то пусто".

Таким образом получается что: Мы должны взять заказ, но выполнить его в те сроки когда НАМ удобно. То есть "сроки проекта по договору" это не тоже самое что "производственные сроки проекта".

Варианты действий:

1. Технология "Плата за выбор", (Почти тоже самое что быструю езду) - можно на 2-3 месяца двинуть, но необходимо просчитать негативные последствия

2. Затягивание сроков заключения договора по юридическим особенностям - сдвиг на 1-2 месяца

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

4. Дисконт за сдвижку сроков в то место где удобно выполнить.

5. Явно прописать санкции (в увеличении времени) за любое нарушение условий любых согласований..

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


Коллеги, а какие ещё варианты сдвижки сроков в нужные производственные даты вы видите?

И какие из предложенных вариантов применяли?

Плохой, Хороший и Отличный Руководитель проекта

В книге я в прологе написал о Дао Управления:

Когда познаешь Дао Управления,
ты перестанешь нуждаться в Управлении.
Все будет работать именно так, как нужно.
(А как не нужно, работать не будет)

А тут вопрос по этой теме пришёл: "А как Метод рекомендует действовать, когда ситуация постоянно меняется?"

Поэтому исходя из базовой посылки о Дао Управления, даю определения:

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

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

Хороший руководитель проекта умеет уложить проект в график даже если есть проблемы на проекте.

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

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

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

#метод

В Журнале Управление проектами вышла моя статья "Планирование реализации стратегии".

ТОС определяет термин "Стратегия"

- Ответ на вопрос: "Зачем?"; цель тактики.
Стратегия любого предлагаемого изменения --- это просто цель этого предлагаемого изменения в дереве стратегии и тактики.

Поэтому "Планирование реализации" - это разработка пошагового плана "Как достигнуть Цели" с точки зрения Постоянно процветающей компании.

#новости

Что-то редко стал писать, новостей мало. Но тут нашел интересное, если вы делаете стартап или новый продукт.

Обычно при разработке новых (ИТ-) продуктов есть анализ альтернатив:
- конкуренты
- решения-заместители (см. JTBD)

С точки зрения реального бизнеса, если нет сильного ИТ-отдела, то часто выбор стоит между "Покупать у поставщика А или покупать у поставщика Б".

Но сейчас с развитием нейронок появился третий выбор:
- Сделать с ИИ-агентом.

То есть компании "без ИТ" и "с ИТ" сравнялись в выборе:
- делать свое , или
- покупать

А значит при запуске нового ИТ-продукта, нужно задать первый вопрос: Почему клиенты будут У НАС покупать, а не создать своё с нейронкой?