Реестр предположений - это репозитарий и предположений, и ограничений. Он заводится в момент создания Устава проекта. Предположения и ограничения сначала определяются на высоком уровне в предпосылках проекта и уставе. Далее им уделяется внимание по мере прогресса проекта. Реестр предположений это вход во многие процессы проекта. Его нужно апдейтить достаточно часто.
Предположения. Важная часть коммуникаций заключается в понимании того, что ваш менеджмент и заинтересованные стороны считают справедливым относительно проекта. Это и есть предположения. Предположения сравнимы с ожиданиями, поскольку они могут быть не целиком основаны на фактах. Заинтересовнные стороны могут и не понимать, что у них есть какие-то предположения, так что не ждите, что они расскажут вам о них в разговоре о требованиях! Некорректные предположения несут риски для проекта, поэтому РМ должен их выявить и управлять ими. Реестр предположений часто бывает входной точкой для процесса планирования, а апдейты реестра предположений - это выходы многих процессов планирования и контроля.
Ограничения. Ограничения идентифицируются проще, чем предположения, поскольку, как правило, их явно обозначает менеджмент или спонсор проекта. Ограничения лимитируют варианты развития событий начиная с планирования и далее. Менеджер проекта жонглирует многими сущностями, в том числе такими ограничениями, как расписание, стоимость, риски, содержание, качество, ресурсы, удовлетворение клиента, и иные факторы, ограничивающие варианты. Например, ключевая дата, когда должен быть поставлен продукт, это крайняя дата завершения проекта! Максимально допустимый риск проекта должен учитывать все ограничения. Управление проектом в условиях ограничений может быть реальным челленджем!
Менеджмент прямо или косвенно накладывает условия на ограничения. Эта приоритезация далее используется для планирования проекта, оценки влияния изменений, и обеспечения успешного исполнения проекта.
Важно понимать, что устранив одно ограничение, можно получить другое. В двух словах, вряд ли получится сократить срок проекта, без негативного влияния на стоимость, риски, и т.д. Это превращается в игру при планировании проекта, и при управлениями изменениями. Например, какая-то доп.работа может занять один день, но стоимость ее будет такой, что проект уйдет с критического пути. Риск добавления доп.работ, или отказа от них, также должен оцениваться. Изменения плана проекта также часть встречают множественные ограничения. РМ и команда могут и вытянуть эти изменения, но все запросы на изменения, которые могут повлиять на план проекта, должны пройти интегрированный контроль изменений.
Предположения. Важная часть коммуникаций заключается в понимании того, что ваш менеджмент и заинтересованные стороны считают справедливым относительно проекта. Это и есть предположения. Предположения сравнимы с ожиданиями, поскольку они могут быть не целиком основаны на фактах. Заинтересовнные стороны могут и не понимать, что у них есть какие-то предположения, так что не ждите, что они расскажут вам о них в разговоре о требованиях! Некорректные предположения несут риски для проекта, поэтому РМ должен их выявить и управлять ими. Реестр предположений часто бывает входной точкой для процесса планирования, а апдейты реестра предположений - это выходы многих процессов планирования и контроля.
Ограничения. Ограничения идентифицируются проще, чем предположения, поскольку, как правило, их явно обозначает менеджмент или спонсор проекта. Ограничения лимитируют варианты развития событий начиная с планирования и далее. Менеджер проекта жонглирует многими сущностями, в том числе такими ограничениями, как расписание, стоимость, риски, содержание, качество, ресурсы, удовлетворение клиента, и иные факторы, ограничивающие варианты. Например, ключевая дата, когда должен быть поставлен продукт, это крайняя дата завершения проекта! Максимально допустимый риск проекта должен учитывать все ограничения. Управление проектом в условиях ограничений может быть реальным челленджем!
Менеджмент прямо или косвенно накладывает условия на ограничения. Эта приоритезация далее используется для планирования проекта, оценки влияния изменений, и обеспечения успешного исполнения проекта.
Важно понимать, что устранив одно ограничение, можно получить другое. В двух словах, вряд ли получится сократить срок проекта, без негативного влияния на стоимость, риски, и т.д. Это превращается в игру при планировании проекта, и при управлениями изменениями. Например, какая-то доп.работа может занять один день, но стоимость ее будет такой, что проект уйдет с критического пути. Риск добавления доп.работ, или отказа от них, также должен оцениваться. Изменения плана проекта также часть встречают множественные ограничения. РМ и команда могут и вытянуть эти изменения, но все запросы на изменения, которые могут повлиять на план проекта, должны пройти интегрированный контроль изменений.
Комментариев нет:
Отправить комментарий