Регистрация   E-Mail     Пароль   
Портал «Профессионал управления проектами»

123

Абрамов В.И.
24 сентября 2015 г., 11:40

Один из слушателей задал мне такой вопрос. Вот что я ответил.

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

Ограничение - это фактор, влияющий на ход исполнения портфеля, программы, проекта или процесса.

Требование – это условие или характеристика, которому должен соответствовать или которую должен иметь продукт, услуга или результат в соответствии с договором или другой формально предписанной спецификацией.

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

Можно, конечно, эту «двухходовку» прокрутить в голове. Для явных и простых ситуаций это допустимо. Но PMBoK «накрывает» все возможные ситуации, в том числе и не однозначные, и сложные, и (в начале проекта) невидимые и невзаимосвязанные.

Поэтому и предлагается более подробный подход.
То есть, ограничения должны быть выявлены как можно раньше и зафиксированы сначала в Уставе проекта, а затем в документе «Описании содержания». Там в отдельном разделе перечисляются и описываются конкретные ограничения проекта, связанные с его содержанием, ограничивающие возможности команды, например, предопределенный бюджет, любые установленные даты или контрольные события расписания, которые определены заказчиком или исполняющей организацией. Это могут быть ограничения по технологиям (нельзя применять что-то), ограничения по объемам (не более… , не менее…, не реже…, не чаще…) и др. Когда проект выполняется по Контракту, положения Контракта, как правило, являются ограничениями. Информация об ограничениях может быть указана в описании содержания проекта или в отдельном журнале.

Затем переходим к требованиям. Они, как правило, отражаются в документах: Устав проекта, План управления требованиями, Матрица отслеживания требований, Документация по требованиям.

Например, возьмем Устав проекта.
В нем можно отразить и требования к продукту, и ограничения (в том числе и по содержанию).
Если сформулировано ограничение, которое может повлиять на содержание продукта, его нужно отразить. Например, Система должна быть сдана в эксплуатацию не позднее…
Если уже сформулировано требование к продукту, то можно зафиксировать и его. Однако, на уровне Устава обычно фиксируют ограничения.

Согласны ли Вы с такой трактовкой?

Уважением, В. Абрамов

Р Дума
5 октября 2015 г., 16:06
я бы упростил
Я бы сказал так: суть в том, что ограничения больше применимы к проекту и его планированию, а требования - к продукту и его проверке. К сожалению, в PMBOK на эту тему все немного размыто и более того, на мой взгляд не совсем корректно.

Например, ограничениями по содержанию являются:
- миграция 10 информационных систем (при том что всего их 1000)
- интеграция с внешними ИС не является предметом настоящего проекта.

Перечисленные примеры не будут проверяться на этапах acceptance testing и не будут содержать критериев приемки, однако они крайне существенно влияют на содержание и далее на все характеристики проекта.
Абрамов В.И.
28 декабря 2015 г., 12:11
Какие ограничения описываете в проектах Вы?

Коллеги!


Согласен с коллегой: в PMBoK этот вопрос не прояснен. Приходится догадываться или спрашивать у более опытных специалистов.


Не всегда в проектах РП описывает ограничения и работает с ними. И эти забытые ограничения могут напортить ему в самое неподходящее время. Но требования ему приходится и формулировать и выполнять.


Как же грамотнее связать ограничения по содержанию и требования? Какие ограничения в проектах описываете Вы как с ними работаете?



С уважением, В. Абрамов



Пожалуйста, авторизуйтесь или зарегистрируйтесь для добавления сообщений в этот форум.
Rambler's Top100 Рейтинг@Mail.ru