Управление изменениями: когда заказчик настаивает, а договор с фикс. ценой
Ни один проект не выполняется без изменений. Это нормально. Но что делать, когда договор с фиксированной ценой, а заказчик приходит с «маленькой доработкой», которая на деле переворачивает логику системы?
1. Проверьте договор.
Прежде чем соглашаться или отказывать, задайте вопрос: этот запрос соответствует какой-либо задаче в утвержденном перечне работ или нет? Если в договоре или приложения к нему нет четкого перечня задач и критериев приёмки — спор превращается в «я думал, что это включено» против «а я думал, что нет».
Вывод 1. Внимательно отнеситесь к составлению договора. Все разночтения будут против вас.
2. Нет запроса = нет изменения.
Каждое изменение — через формальный запрос. Даже самое «маленькое». Особенно «маленькое». Недокументированные изменения — самый быстрый путь к неконтролируемому размытию границ проекта.
Вывод 2. Запустить на проекте формальный процесс «Управление изменениями» с самого старта.
3. Если бюджет нельзя изменить — измените что-то другое.
Классическая ловушка: «Сделайте, но денег на это нет». В контракте с фиксированной стоимостью это означает одно — вы забираете бюджет у другой задачи. Варианты: заменить низкоприоритетную фичу, упростить решение.
Вывод 3. Все задачи должны иметь приоритеты. Нужно понимать, чем можно пожертвовать.
4. Зафиксируйте компромисс письменно.
Если заказчик настаивает, а бюджет фиксирован — это не «просто сделаем». Это управленческое решение с последствиями. Оформите его как согласованный обмен: «Мы делаем X, но Y отменяем». Без бумаги это останется вашей личной проблемой.
Вывод 4. Всё что не задокументировано – будет забыто.
5. Не бойтесь эскалации.
Если заказчик требует изменений, не готов платить и не готов жертвовать объёмом — это уже не проектный вопрос. Эскалируйте этот вопрос спонсору. Пусть решают на уровне, где есть полномочия менять контракт.
Вывод 5. Возможно наверху договорятся и будет дополнительное соглашение на новый объем работ.
Главное: фиксированная цена — это не «всё включено». Это фиксированный объём, срок и стоимость.
#УправлениеПроектами #УправлениеИзменениями #FixedPrice #PMO #ChangeControl
Ни один проект не выполняется без изменений. Это нормально. Но что делать, когда договор с фиксированной ценой, а заказчик приходит с «маленькой доработкой», которая на деле переворачивает логику системы?
1. Проверьте договор.
Прежде чем соглашаться или отказывать, задайте вопрос: этот запрос соответствует какой-либо задаче в утвержденном перечне работ или нет? Если в договоре или приложения к нему нет четкого перечня задач и критериев приёмки — спор превращается в «я думал, что это включено» против «а я думал, что нет».
Вывод 1. Внимательно отнеситесь к составлению договора. Все разночтения будут против вас.
2. Нет запроса = нет изменения.
Каждое изменение — через формальный запрос. Даже самое «маленькое». Особенно «маленькое». Недокументированные изменения — самый быстрый путь к неконтролируемому размытию границ проекта.
Вывод 2. Запустить на проекте формальный процесс «Управление изменениями» с самого старта.
3. Если бюджет нельзя изменить — измените что-то другое.
Классическая ловушка: «Сделайте, но денег на это нет». В контракте с фиксированной стоимостью это означает одно — вы забираете бюджет у другой задачи. Варианты: заменить низкоприоритетную фичу, упростить решение.
Вывод 3. Все задачи должны иметь приоритеты. Нужно понимать, чем можно пожертвовать.
4. Зафиксируйте компромисс письменно.
Если заказчик настаивает, а бюджет фиксирован — это не «просто сделаем». Это управленческое решение с последствиями. Оформите его как согласованный обмен: «Мы делаем X, но Y отменяем». Без бумаги это останется вашей личной проблемой.
Вывод 4. Всё что не задокументировано – будет забыто.
5. Не бойтесь эскалации.
Если заказчик требует изменений, не готов платить и не готов жертвовать объёмом — это уже не проектный вопрос. Эскалируйте этот вопрос спонсору. Пусть решают на уровне, где есть полномочия менять контракт.
Вывод 5. Возможно наверху договорятся и будет дополнительное соглашение на новый объем работ.
Главное: фиксированная цена — это не «всё включено». Это фиксированный объём, срок и стоимость.
#УправлениеПроектами #УправлениеИзменениями #FixedPrice #PMO #ChangeControl
👍1
Проект и продукт: в чём разница и почему все путают
«Мы запустили проект по продукту», «продуктовая команда ведёт проект». Знакомо? Проект и продукт, часто эти два слова используют как синонимы. А потом выясняется, что получили "бесконечный" проект.
В чем разница?
Проект — временное предприятие, создающее уникальный результат. Есть цель, сроки, бюджет, начало и конец. «Разработать CRM для заказчика», «построить дом», «провести конференцию». Проект заканчивается, когда результат передан заказчику и подписан акт.
Продукт — это результат, который живёт долго и развивается. У него есть жизненный цикл: идея, создание, рост, зрелость, упадок. «CRM-система, которую мы продаём», «мобильное приложение», «автомобиль». Продукт не заканчивается — он эволюционирует. Им управляет product manager, а не project manager.
Ключевые различия:
Цель. Проект направлен на создание уникального результата — конкретного продукта, услуги или иного артефакта, который должен быть получен по завершении. Продукт же нацелен на развитие и принесение ценности на протяжении всего своего существования, он не ограничивается однократным созданием, а постоянно адаптируется и улучшается.
Время. Проект всегда временный: у него есть чёткое начало и финиш, после достижения цели он завершается. Продукт, напротив, существует длительно, проходя через жизненный цикл — от идеи и создания до роста, зрелости и eventual снятия с поддержки; он не имеет фиксированной даты окончания.
Управление. Проектом управляет Project Manager, который отвечает за достижение целей в рамках ограничений по срокам, бюджету и качеству. Продуктом управляет Product Manager, чья задача — определять, что именно нужно рынку, и обеспечивать долгосрочное развитие продукта.
Фокус. В проекте основной фокус — «сделать в срок и в бюджет», то есть эффективное выполнение запланированных работ. В продукте фокус смещён на «делать то, что нужно рынку» — на удовлетворение потребностей и создание ценности, даже если это требует изменения первоначальных планов.
Метрики. Успех проекта измеряется сроками, бюджетом и качеством выполнения работ. Успех продукта оценивается рыночными показателями: выручкой, удержанием пользователей, лояльностью потребителей (например, NPS) и другими метриками, отражающими ценность для клиента.
Окончание. Проект считается завершённым, когда подписан акт выполненных работ и результат передан заказчику. Продукт же не заканчивается подписанием акта — он живёт до тех пор, пока не будет снят с поддержки, что может произойти через годы или даже десятилетия после его создания.
Почему происходит подмена понятий?
Тренд на "product mindset". Все хотят быть «продуктовыми». Даже если делают уникальный проект для одного заказчика. Полагают что считаться «продуктовой командой» престижнее, чем «проектной».
Пересечение ролей. В agile-командах product owner часто выполняет административные функции, что сродни project manager. Отсюда путаница.
Незнание терминологии. Люди не читали ни стандартов по управлению проектами, ни стандартов по управлению продуктом. Им кажется, что «продукт» на данный момент звучит солиднее.
Организационные причины. Нет чёткого разделения ролей и зон ответственности. Один человек может быть и PM, и product manager.
Последствия?
Product manager пытается управлять проектом, но не умеет строить календарный план.
Метрики смешиваются: проект закрыли «в срок», а продукт не взлетел.
Ресурсы распределяются неэффективно: продуктовая команда тратит время на проектные задачи.
Проект и продукт — разные сущности. Проект создаёт продукт. Продукт живёт дальше. Если вы не уверены — задайте вопрос: «У этого есть финиш?»
#УправлениеПроектами #PMO #Продукт #Проект #ProductManagement
«Мы запустили проект по продукту», «продуктовая команда ведёт проект». Знакомо? Проект и продукт, часто эти два слова используют как синонимы. А потом выясняется, что получили "бесконечный" проект.
В чем разница?
Проект — временное предприятие, создающее уникальный результат. Есть цель, сроки, бюджет, начало и конец. «Разработать CRM для заказчика», «построить дом», «провести конференцию». Проект заканчивается, когда результат передан заказчику и подписан акт.
Продукт — это результат, который живёт долго и развивается. У него есть жизненный цикл: идея, создание, рост, зрелость, упадок. «CRM-система, которую мы продаём», «мобильное приложение», «автомобиль». Продукт не заканчивается — он эволюционирует. Им управляет product manager, а не project manager.
Ключевые различия:
Цель. Проект направлен на создание уникального результата — конкретного продукта, услуги или иного артефакта, который должен быть получен по завершении. Продукт же нацелен на развитие и принесение ценности на протяжении всего своего существования, он не ограничивается однократным созданием, а постоянно адаптируется и улучшается.
Время. Проект всегда временный: у него есть чёткое начало и финиш, после достижения цели он завершается. Продукт, напротив, существует длительно, проходя через жизненный цикл — от идеи и создания до роста, зрелости и eventual снятия с поддержки; он не имеет фиксированной даты окончания.
Управление. Проектом управляет Project Manager, который отвечает за достижение целей в рамках ограничений по срокам, бюджету и качеству. Продуктом управляет Product Manager, чья задача — определять, что именно нужно рынку, и обеспечивать долгосрочное развитие продукта.
Фокус. В проекте основной фокус — «сделать в срок и в бюджет», то есть эффективное выполнение запланированных работ. В продукте фокус смещён на «делать то, что нужно рынку» — на удовлетворение потребностей и создание ценности, даже если это требует изменения первоначальных планов.
Метрики. Успех проекта измеряется сроками, бюджетом и качеством выполнения работ. Успех продукта оценивается рыночными показателями: выручкой, удержанием пользователей, лояльностью потребителей (например, NPS) и другими метриками, отражающими ценность для клиента.
Окончание. Проект считается завершённым, когда подписан акт выполненных работ и результат передан заказчику. Продукт же не заканчивается подписанием акта — он живёт до тех пор, пока не будет снят с поддержки, что может произойти через годы или даже десятилетия после его создания.
Почему происходит подмена понятий?
Тренд на "product mindset". Все хотят быть «продуктовыми». Даже если делают уникальный проект для одного заказчика. Полагают что считаться «продуктовой командой» престижнее, чем «проектной».
Пересечение ролей. В agile-командах product owner часто выполняет административные функции, что сродни project manager. Отсюда путаница.
Незнание терминологии. Люди не читали ни стандартов по управлению проектами, ни стандартов по управлению продуктом. Им кажется, что «продукт» на данный момент звучит солиднее.
Организационные причины. Нет чёткого разделения ролей и зон ответственности. Один человек может быть и PM, и product manager.
Последствия?
Product manager пытается управлять проектом, но не умеет строить календарный план.
Метрики смешиваются: проект закрыли «в срок», а продукт не взлетел.
Ресурсы распределяются неэффективно: продуктовая команда тратит время на проектные задачи.
Проект и продукт — разные сущности. Проект создаёт продукт. Продукт живёт дальше. Если вы не уверены — задайте вопрос: «У этого есть финиш?»
#УправлениеПроектами #PMO #Продукт #Проект #ProductManagement