на проект действуют такие ограничения как
Разбираемся с проектными ограничениями
Всем давно известно, что любому проекту присущи ограничения: обычно вспоминают про сроки, бюджет и качество. Вы, конечно, помните заезженную байку из серии «выберите только два из трёх» — ограничения интересны в первую очередь тем, что они взаимосвязаны.
На деловой игре «Египет бросает вызов», которую я проводил в прошлую пятницу, этот вопрос мы немного обсуждали с группой, однако мне показалось, что обычное объяснение — «ограничения есть, они таковы и они взаимосвязаны» — слишком поверхностно. Признаюсь, особой глубины в данной теме я не вижу, однако некоторыми соображениями готов поделиться.
Соображение первое — сколько всего ограничений?
Разумеется, мы включим в список упомянутые выше сроки, бюджет и качество. Но полон ли такой список? Для проектов среднего и большого размера, думаю, нет: следует добавить в него ещё и охват, при этом я бы не стал объединять охват и качество в единую сущность, как предлагают некоторые методологии.
Поясню на примере той самой деловой игры: изначально фараон хочет пирамиду, и он готов сформулировать требования к этому конечному продукту. Выявленные и задокументированные требования ложатся в основу критериев качества, нарушать которые (то есть выходить за ограничения) проектная команда просто так не должна. В то же время по ходу проекта от заказчика прилетают новые идеи и инициативы, вплоть до дополнительных продуктов проекта. Охват проекта меняется, становясь отдельным ограничением, связанным с остальными и находящимся под управлением проектной группы. Можно, к примеру, успеть в те же сроки и те же деньги сделать пирамиду поменьше, зато добавить к ней пристройку (другой охват взамен ранее согласованного качества).
Но только ли охват следует добавить в список? Знатоки PMBoK, конечно же, вспомнят, что в данном талмуде источнике знаний рассматривается аж шесть ограничений, иллюстрируемых причудливой формой:
На мой взгляд, прежде чем придумывать дополнительные ограничения следует разобраться с их природой. К примеру, ресурсы зачастую выступают ограничением, так как бывают не в том количестве или не того качества (компетенций), как требуется, несмотря на наличие денег для их приобретения или привлечения. Но важно помнить, что ресурсы — внутреннее дело проекта, а не проблема заказчика. Да, менеджеру проекта приходится озадачиваться вопросами ресурсного обеспечения, но выносить их решение или даже обсуждение на клиента можно далеко не в каждом случае. В отличие от сроков, бюджета, качества и охвата — слов, понятных заказчику.
Не менее запутанная ситуация и с рисками. Мне кажется, что управление рисками не следует смешивать с управлением ограничениями проекта.
Итак, во многих случаях необходимым и достаточным будет список из четырёх пунктов. Соль и перец добавляем по вкусу.
Соображение второе — действительно ли ограничения жёстко взаимосвязаны?
Разумеется, мы можем привести друг другу массу примеров жёстких связей — дёргаешь за одно, меняются другие. Однако не следует забывать про такие понятия как производительность, эффективность и технологии. Одну и ту же работу/задачу можно выполнить разными способами, и вполне возможна ситуация, когда, скажем, сроки проекта резко сокращены, а в установленные деньги и качество попасть всё равно можно.
Соображение третье — что делать с ограничениями?
Источники знаний по управлению проектами зачастую не детализируют этот вопрос, рекомендуя менеджеру «держать руку на пульсе«, а также «контролировать ключевые параметры проекта«. Это прекрасно, но что конкретно нужно делать? По моему мнению, список действий менеджера проекта по работе с проектными ограничениями предельно прост. При выявлении выхода или угрозы выхода за установленные органичения менеджер должен:
Соображение четвёртое — «водопад» и Agile смотрят на ограничения по-разному
Многие из нас привыкли действовать следующим образом: заказчик ставит задачу, мы определяем способ её решения, формируем перечень работ, из него получаем оценку сроков и оценку бюджета. Далее согласовываем с заказчиком и приступаем к выполнению. Обратите внимание: мы изначально фиксируем два ограничения (охват и качество), а другие два (сроки и бюджет) являются производными.
Совершенно другая картина в гибких подходах. Получив задачу мы договариваемся о сроках и бюджете первой итерации (спринта), и только затем определяем чего именно получится достичь за выделенные сроки и деньги. То есть охват и качество являются следствием ограничений по календарю и финансам. Такой подход поддерживает общие идеи Agile вроде:
Получается, что прежде, чем планировать проект и работать с проектными ограничениями, следует определиться с подходом к выполнению проекта.
На фото: проектный офис игры, которая была в пятницу, готов к работе, но пока даже не догадывается, что его ожидает.
Что нужно сделать до старта проекта. Часть 3
Что важно предусмотреть и учесть до начала проекта, чтобы он прошел успешно, продолжает рассказывать наш эксперт Максим Якубович.
– В первой статье этого цикла речь шла о формулировании целей проекта, результатов проекта и сбору требований к ним (необходимый шаг для снижения неопределенности проекта). Вторая статья была посвящена определению допущений по проекту и переходу от них – к рискам проекта. Это важно при планировании сроков и бюджета проекта.
Чтобы перейти к подписанию документов, официально утверждающих проект, нужно сделать еще один важный шаг – сформулировать ограничения по проекту. Расскажу об этом подробнее.
В управлении проектами используется термин «проектный треугольник» (употребляют еще понятие «тройное ограничение проекта»). Проектный треугольник описывает взаимодействие ключевых ограничений:
1. Содержание проекта. В простейшем случае оно может выглядеть как список работ по проекту, которые нужно реализовать, чтобы достигнуть целей и получить запланированные результаты. Для некоторых проектов содержание описывают в виде совокупности документов, например:
Чем точнее описано содержание проекта, тем проще спрогнозировать сроки и бюджет проекта.
2. Время реализации. Это ограничения по продолжительности проекта, включающие дату, к которой нужно получить ожидаемые результаты
3. Бюджет. Ограничение по стоимости проекта.
4. Качество. Ограничение, связанное с тем, в какой степени выполняются требования к результатам. Например, заказчика может устроить, что будут реализованы лишь самые важные требования проекта.
Самую большую сложность представляет интерпретация ограничения по качеству. Качество чего имеется в виду? Можно рассуждать о качестве и самого проекта и его результатов. Определение качества, которое использую я, следующее:
Качество – это степень соответствия результата и требованиям к нему. Качество результатов можно проверить, сравнив то, что получилось – с тем, что требовалось получить. Грубо говоря, сравнив итоговый продукт проекта с требованиями к нему.
Таким образом, качество проекта тесно связано с его содержанием. В нем и описаны требования к этим результатам.
Логика формирования ограничений по проекту следующая:
1. Уточнить содержание проекта, определив цели. Понимая это, можно определить результаты и требования к ним.
2. Понимая требования к результатам проекта, определить список работ по проекту.
3. Понимая список работ по проекту, определить сроки и бюджет.
4. Зафиксировать договоренности о содержании, сроках, бюджете и качестве проекта как ограничения проекта.
Как работает проектный треугольник
Так как неопределенность в проекте велика, то и наши расчеты имеют некоторую степень достоверности. Если не учтены важные требования во время их сбора – это приведет к появлению новых работ в содержании проекта. Сторона треугольника «Содержание» станет длиннее. Сбалансировать ее можно, либо увеличив сторону треугольника «Бюджет», либо увеличив сторону «Срок». Либо увеличив обе.
Таким образом, если меняется одна из сторон треугольника, руководителю проекта и заказчику приходится балансировать две другие. Понимая, как работает проектный треугольник, руководитель проекта и заказчик могут договориться, что важнее для проекта – срок, содержание, качество или бюджет?
Многие из вас уже видели похожие картинки, которые помогают расставить приоритеты.
Если заказчик настаивает, что должны быть реализованы все цели проекта и при этом выполнены все требования к результатам – желательно, чтобы к моменту старта эти требования уже были собраны и утверждены. Тогда руководитель проекта под эти требования может просчитать бюджет и срок.
При этом заказчик проекта должен отдавать себе отчет в том, что если по ходу проекта он захочет изменить или добавить требования – срок и/или бюджет проекта придется изменять.
Если заказчик пытается на старте проекта зафиксировать все три параметра проектного треугольника – это значит, он пытается передать руководителю проекта все риски, связанные с изменениями. Как реагирует на такое поведение заказчика мудрый руководитель проекта? Он закладывает резервы времени и денег на изменения (иногда резервы могут быть очень существенными, например равными 100% от расчетных значений сроков или бюджета).
Какие еще типы ограничений могут быть
В PMBOK содержится мнение, что к четырем ограничениям, описанным в проектном треугольнике, нужно еще добавлять ограничения по ресурсам и рискам. В результате получается шестигранник ограничений:
Ограничения по ресурсам оказывают самое сильное влияние на сроки выполнения работ, но могут повлиять и на бюджет проекта.
Какова логика встраивания рисков в ограничения? В Своде знаний по управлению проектами PMBOK есть следующее объяснение: «Изменение требований к проекту или целей проекта может вызвать дополнительные риски». Они в свою очередь могут повлиять на содержание проекта, сроки или бюджет.
Стоит ли использовать шесть типов ограничений или достаточно определить три (содержание, срок и бюджет) – решать руководителю проекта. Я в большинстве проектов оперирую только тремя самыми важными ограничениями, которые описываю в документе Устав проекта.
Успешность проекта
Об успехе проекта судят по его выполнению в рамках ограничений.
Например, при достижении всех целей проекта в срок и в бюджет проект будет признан успешным. В PMBOK считается что «успех проекта должен связываться с последними базовыми планами, одобренными уполномоченными заинтересованными сторонами». Это значит, что если сроки или бюджет несколько раз по ходу проекта пересматривались и согласовывались, то измерение успешности проекта будет делаться относительно последних согласованных с заказчиком параметров.
Итак, типовые критерии успешности проекта обычно следующие.
Проект реализовал все запланированные результаты, причем был выполнен в срок и в бюджет.
Шаги по подготовке проекта к старту выглядят так:
1. Согласовать цели проекта с заказчиком.
2. Описать результаты проекта.
3. Согласовать требования к результатам проекта.
4. Определить допущения проекта.
5. Определить ограничения проекта и критерии успешности проекта.
Этот документ становится гарантом, что руководитель проекта и заказчик одинаково понимают все важные аспекты.
Содержание Устава проекта может быть разным в различных компаниях. Но важность этого документа нельзя недооценивать.
Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».
Опыт работы в сфере управления проектами – более 10 лет.
20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.
Опыт преподавания – 8 лет. Около 2000 студентов, прошедших обучение на его семинарах.
Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.
Ведущий блога по управлению проектами.
Что нужно сделать до старта проекта? Часть 3. Ограничения проекта
В первой статье этого цикла речь шла о формулировании целей проекта, результатов проекта и сбору требований к ним, как необходимому шагу для снижения неопределенности проекта. Вторая статья цикла посвящена формулированию допущений по проекту и переходу от допущений к рискам, которые надо будет учесть при планировании сроков и бюджета проекта.
Для того чтобы перейти к подписанию документов, подтверждающих официальное признание проекта, нужно сделать еще один важный шаг – сформулировать ограничения по проекту.
В управлении проектами используется термин «проектный треугольник», для которого используют также название «тройное ограничение проекта». Проектный треугольник описывает взаимодействие ключевых ограничений проекта:
Самую большую сложность представляет интерпретация ограничения по качеству. Качество чего имеется в вид у?
Применительно к проекту можно рассуждать о качестве проекта и о качестве результатов проекта. Определение качества, которое использую я, следующее:
Качество – это степень соответствия результата требованиям к нему.
Когда мы говорим о качестве результатов проекта, то его можно проверить, сравнив то, что получилось сделать по результатам проекта, с тем, что требовалось получить (грубо говоря, сравнив продукт проекта с требованиями к нему).
Таким образом, качество результатов проекта тесно связано с содержанием проекта, в котором описаны требования к результатам.
Логика формирования ограничений по проекту следующая:
Как работает проектный треугольник?
Так как неопределенность в проекте велика, то и наши расчеты имеют некоторую степень достоверности. Если мы при сборе требований не учли важные требования – это приведет к появлению новых работ в содержании проекта, сторона треугольника «Содержание» станет длиннее. Сбалансировать ее можно, либо увеличив сторону треугольника «бюджет», либо увеличив сторону «срок», либо увеличив обе эти стороны треугольника.
Таким образом, если меняется одна из сторон треугольника, руководителю проекта и заказчику приходится балансировать две другие стороны треугольника.
Понимая, как работает проектный треугольник, руководитель проекта и заказчик могут договориться о приоритетах: что важнее для проекта – срок, содержание, качество или бюджет.
Многие из вас уже видели похожие картинки:
Если заказчик настаивает на том, что должны быть реализованы все цели проекта и при этом выполнены все требования к результатам, то желательно, чтобы к моменту старта проекта эти требования уже были собраны и утверждены заказчиком. Тогда руководитель проекта под требования может просчитать бюджет и срок. При этом заказчик проекта должен отдавать себе отчет в том, что если по ходу проекта он захочет изменить или добавить требования, то срок или бюджет проекта придется изменять (а может быть, и то, и другое).
Если заказчик пытается на старте проекта зафиксировать все три параметра проектного треугольника, то он пытается передать руководителю проекта все риски, связанные с изменениями в проекте. Как реагирует на такое поведение заказчика мудрый руководитель проекта? Он закладывает резервы времени и денег на изменения (иногда резервы могут быть очень существенными, например, равными 100% от расчетных значений сроков или бюджета).
Какие еще типы ограничений могут быть?
В PMBOK содержится мнение, что к четырем ограничениям, описанным в проектном треугольнике, нужно еще добавлять ограничения по ресурсам и рискам. В результате получается шестигранник ограничений:
Какова логика встраивания рисков в ограничения? В PMBOK дается следующее объяснение: «Изменение требований к проекту или целей проекта может вызвать дополнительные риски». Риски, в свою очередь, могут повлиять на содержание проекта, сроки или бюджет проекта.
Ограничения по ресурсам оказывают самое сильное влияние на сроки выполнения работ, но могут повлиять и на бюджет проекта.
Стоит ли использовать подход PMBOK к ограничениям, определяя шесть типов ограничений, или достаточно определить три типа ограничений (содержание, срок и бюджет) – решать руководителю проекта. Я в большинстве проектов оперирую только тремя самыми важными ограничениями, которые описываю в документе Устав проекта.
Успешность проекта
По выполнению проекта в рамках его ограничений судят об успехе проекта.
Например, при достижении всех целей проекта в срок и в бюджет проект будет признан успешным. В PMBOK считается, что «успех проекта должен связываться с последними базовыми планами, одобренными уполномоченными заинтересованными сторонами». Это значит, что если базовые сроки или бюджет несколько раз по ходу проекта пересматривались и согласовывались заказчиком проекта, то измерение успешности проекта будет делаться относительно последнего согласованного заказчиком срока и бюджета.
Итак, критерием успешности проекта является реализация всех запланированных результатов проекта, причем в срок и в бюджет.
Шаги по подготовке проекта к старту следующие:
Если у вас есть вопросы и комментарии по теме ограничений проекта, давайте обсуждать. И удачи вам в реализации проектов!
Все об ограничениях проекта
Ограничения проекта (Project Constraints, Project Restrictions) – это, наверное, одно из простейших понятий проектного менеджмента. И то ли именно поэтому, то ли вопреки этому – все его постоянно путают с чем-то другим.
Как понятно из названия, ограничения проекта – это некие факторы, которые ограничивают наши возможности по реализации проекта. Т.е. при их отсутствии мы бы, наверное, смогли сделать быстрее, дешевле и лучше, но они есть и от этого никуда не деться.
Например, ограничением может быть «Заказчик недоступен для обсуждения и согласования вопросов проекта с 1 по 10 число каждого календарного месяца)», например, он руководитель какого-нибудь отдела финансов, у них в это время закрытие месяца, он работает 24 часа в сутки. Зная это на самом старте проекта, вы избежите неприятной ситуации, когда по счастливому совпадению в вашем календарном плане все согласования придутся именно на эти числа, и все расписание проекта поедет.
Пример ограничений проекта на нашем любимом примере с ремонтом в квартире:
Ограничения проекта обычно указываются в уставе проекта и впоследствии детализируются при планировании с учетом вводных от заинтересованных лиц.
В чем отличие допущений и ограничений проекта?
Ограничения – это условие, которое принимается за истину, и с учетом которого происходит планирование проекта (и управление им в целом). Т.е. ограничение – это свершившаяся реальность, мы не предполагаем, что ограничение может измениться. Допущения – это то, что вы считаете истиной на текущий момент, но допускаете, что это может истиной не оказаться и осознаете, что этим риском нужно управлять. Ограничения являются вводными для создания плана управления проекта, допущения – вводными для управления рисками проекта.
А в чем сходство? Конечно, также как и в случае с допущениями, велико искушение начать писать в список ограничений все, что придет в голову, но так лучше не делать. Помните, что устав – это документ, который будут читать и согласовывать Заказчик и Спонсор проекта и цель внесения их в устав проекта – скорее договориться на берегу, а не исключить все существующие риски.
Кстати, если вы хотите узнать больше о рисках и о том, как с ними работать – вы можете приобрести наш большой курс по управлению рисками. Шаблон реестра рисков проекта и чек-лист для идентификации рисков в подарок!
Система управления
Календарное планирование
Целевые программы
Управление проектами
Система управления предприятием
 |
| |||||||
| | | | ||||
 | |||||||
 | | PMProfy » Статьи » Теория управления проектами |  | ||||
| |||||||
| |||||||
