Про стандарты управления проектами: разница есть, но не там, где вы думаете
Есть устойчивое мнение, что выбор стандарта управления проектами — это чуть ли не стратегическое решение. PMI или ISO? IPMA или APM?

Что лучше?

Правда в том, что разница в эффективности проекта при использовании разных стандартов — на уровне статистической погрешности. Исследования это подтверждают уже не первый год.
Если вы просто берёте PMBOK (6 или 8 версию), или ISO 21502:2020, или любой другой признанный подход и добросовестно его изучаете, адаптируете, применяете — результат будет примерно одинаковым. Потому что все они основаны на здравом смысле и десятилетиях практики.
Другое дело — «свой изобретённый велосипед». Вот тут начинается самое интересное. Доморощенная методика, написанная «под себя» и не проверенная ни на одном проекте, кроме текущего. Назовите ее «Наш Agile» или «Уникальный путь в проектах нашей компании». И вот она-то как раз и даёт разброс результатов — от «случайно сработало» до «мы всё сломали».
Вывод простой: прежде чем писать музыку — надо изучить ноты. Освойте документы PMI, ISO, IPMA или другие признанные стандарты. Поймите, почему они работают. А потом уже разрабатывайте внутреннюю методологию — но не с нуля, а на прочном фундаменте.
Иначе есть риск изобрести велосипед с квадратными колёсами и удивляться, почему он не едет.
#УправлениеПроектами #PMI #ISO21500 #PMO #Методология

Управление изменениями: когда заказчик настаивает, а договор с фикс. ценой

Ни один проект не выполняется без изменений. Это нормально. Но что делать, когда договор с фиксированной ценой, а заказчик приходит с «маленькой доработкой», которая на деле переворачивает логику системы?

1. Проверьте договор.
Прежде чем соглашаться или отказывать, задайте вопрос: этот запрос  соответствует какой-либо задаче в утвержденном перечне работ или нет? Если в договоре или приложения к нему нет четкого перечня задач и критериев приёмки — спор превращается в «я думал, что это включено» против «а я думал, что нет».
Вывод 1. Внимательно отнеситесь к составлению договора. Все разночтения будут против вас.

2. Нет запроса = нет изменения.
Каждое изменение — через формальный запрос. Даже самое «маленькое». Особенно «маленькое». Недокументированные изменения — самый быстрый путь к неконтролируемому размытию границ проекта.
Вывод 2. Запустить на проекте формальный процесс «Управление изменениями» с самого старта.

3. Если бюджет нельзя изменить — измените что-то другое.
Классическая ловушка: «Сделайте, но денег на это нет». В контракте с фиксированной стоимостью это означает одно — вы забираете бюджет у другой задачи. Варианты: заменить низкоприоритетную фичу, упростить решение.
Вывод 3. Все задачи должны иметь приоритеты. Нужно понимать, чем можно пожертвовать.

4. Зафиксируйте компромисс письменно.
Если заказчик настаивает, а бюджет фиксирован — это не «просто сделаем». Это управленческое решение с последствиями. Оформите его как согласованный обмен: «Мы делаем X, но Y отменяем». Без бумаги это останется вашей личной проблемой.
Вывод 4. Всё что не задокументировано – будет забыто.

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

Главное: фиксированная цена — это не «всё включено». Это фиксированный объём, срок и стоимость.
#УправлениеПроектами #УправлениеИзменениями #FixedPrice #PMO #ChangeControl