{"id":13586,"url":"\/distributions\/13586\/click?bit=1&hash=d51248b864fc2536881ecff329f016f361fa84fdd76d6e9aaa5b17f1b9fefbb0","title":"\u0417\u0432\u043e\u043d\u0438\u0442\u044c \u0438\u0437 \u041a\u0430\u043b\u0438\u043d\u0438\u043d\u0433\u0440\u0430\u0434\u0430 \u0432 \u042f\u043a\u0443\u0442\u0438\u044e \u043f\u043e \u0432\u0438\u0434\u0435\u043e \u0431\u0435\u0437 \u0437\u0430\u0434\u0435\u0440\u0436\u0435\u043a","buttonText":"\u0410\u043b\u043b\u043e!","imageUuid":"bc8e606b-9a50-5550-a16e-3fed09971ed5","isPaidAndBannersEnabled":false}
Андрей Малахов

Что сделать, чтобы рамки проекта не расширялись?

Еще больше актуальной информации про полезные методы и инструменты проектного менеджмента, внедрения организационных изменений и ИТ-решений ищите в нашем Телеграм-канале: Уж&Ёж. Управление проектами. PMLogic

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

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

В первом случае затраты времени на проект стали превышать ожидания подрядчика, а также из-за возникающих новых правок подрядчик стал уже явно демонстрировать свое раздражение.

Во втором - проект ушел по срокам с 5 прогнозных на 9 месяцев.

В первом случае, основная причина - нечетко прописанные рамки в договоре (сделать сайт), отсутствие согласованных реперных точек, в которых осуществляется приемка.

Во втором - множество причин. Затрону лишь те, что связаны с рамками.

Руководитель проекта:

  • Не вел жесткий трекинг того, что нужно по договору,
  • Согласовал требования в договоре, хотя позже посчитал их туманными,
  • Выполнял требования, непредусмотренные договором, потому-что сделать быстрее, чем согласовывать (в итоге много накопилось и оказалось в разы сложнее чем оценивал)
  • Не зафиксировал процедуру принятия и фиксации решений, процедуры приемки.

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

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

Итого мои краткие рекомендации:

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

Где найти баланс? Это искусство, похоже.

Еще больше актуальной информации про полезные методы и инструменты проектного менеджмента, внедрения организационных изменений и ИТ-решений ищите в нашем Телеграм-канале: Уж&Ёж. Управление проектами. PMLogic

0
Комментарии
Читать все 0 комментариев
null