Что такое ограничения проекта

Что нужно сделать до старта проекта? Часть 3. Ограничения проекта

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

Для того чтобы перейти к подписанию документов, подтверждающих официальное признание проекта, нужно сделать еще один важный шаг – сформулировать ограничения по проекту.

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

Самую большую сложность представляет интерпретация ограничения по качеству. Качество чего имеется в вид у?

Применительно к проекту можно рассуждать о качестве проекта и о качестве результатов проекта. Определение качества, которое использую я, следующее:

Качество – это степень соответствия результата требованиям к нему.

Когда мы говорим о качестве результатов проекта, то его можно проверить, сравнив то, что получилось сделать по результатам проекта, с тем, что требовалось получить (грубо говоря, сравнив продукт проекта с требованиями к нему).

Таким образом, качество результатов проекта тесно связано с содержанием проекта, в котором описаны требования к результатам.

Логика формирования ограничений по проекту следующая:

Как работает проектный треугольник?

Так как неопределенность в проекте велика, то и наши расчеты имеют некоторую степень достоверности. Если мы при сборе требований не учли важные требования – это приведет к появлению новых работ в содержании проекта, сторона треугольника «Содержание» станет длиннее. Сбалансировать ее можно, либо увеличив сторону треугольника «бюджет», либо увеличив сторону «срок», либо увеличив обе эти стороны треугольника.

Таким образом, если меняется одна из сторон треугольника, руководителю проекта и заказчику приходится балансировать две другие стороны треугольника.

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

Многие из вас уже видели похожие картинки:

Если заказчик настаивает на том, что должны быть реализованы все цели проекта и при этом выполнены все требования к результатам, то желательно, чтобы к моменту старта проекта эти требования уже были собраны и утверждены заказчиком. Тогда руководитель проекта под требования может просчитать бюджет и срок. При этом заказчик проекта должен отдавать себе отчет в том, что если по ходу проекта он захочет изменить или добавить требования, то срок или бюджет проекта придется изменять (а может быть, и то, и другое).

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

Какие еще типы ограничений могут быть?

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

Какова логика встраивания рисков в ограничения? В PMBOK дается следующее объяснение: «Изменение требований к проекту или целей проекта может вызвать дополнительные риски». Риски, в свою очередь, могут повлиять на содержание проекта, сроки или бюджет проекта.

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

Стоит ли использовать подход PMBOK к ограничениям, определяя шесть типов ограничений, или достаточно определить три типа ограничений (содержание, срок и бюджет) – решать руководителю проекта. Я в большинстве проектов оперирую только тремя самыми важными ограничениями, которые описываю в документе Устав проекта.

Успешность проекта

По выполнению проекта в рамках его ограничений судят об успехе проекта.

Например, при достижении всех целей проекта в срок и в бюджет проект будет признан успешным. В PMBOK считается, что «успех проекта должен связываться с последними базовыми планами, одобренными уполномоченными заинтересованными сторонами». Это значит, что если базовые сроки или бюджет несколько раз по ходу проекта пересматривались и согласовывались заказчиком проекта, то измерение успешности проекта будет делаться относительно последнего согласованного заказчиком срока и бюджета.

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

Шаги по подготовке проекта к старту следующие:

Если у вас есть вопросы и комментарии по теме ограничений проекта, давайте обсуждать. И удачи вам в реализации проектов!

Источник

Разбираемся с проектными ограничениями

Всем давно известно, что любому проекту присущи ограничения: обычно вспоминают про сроки, бюджет и качество. Вы, конечно, помните заезженную байку из серии «выберите только два из трёх» — ограничения интересны в первую очередь тем, что они взаимосвязаны.

На деловой игре «Египет бросает вызов», которую я проводил в прошлую пятницу, этот вопрос мы немного обсуждали с группой, однако мне показалось, что обычное объяснение — «ограничения есть, они таковы и они взаимосвязаны» — слишком поверхностно. Признаюсь, особой глубины в данной теме я не вижу, однако некоторыми соображениями готов поделиться.

Соображение первое — сколько всего ограничений?

Разумеется, мы включим в список упомянутые выше сроки, бюджет и качество. Но полон ли такой список? Для проектов среднего и большого размера, думаю, нет: следует добавить в него ещё и охват, при этом я бы не стал объединять охват и качество в единую сущность, как предлагают некоторые методологии.

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

Но только ли охват следует добавить в список? Знатоки PMBoK, конечно же, вспомнят, что в данном талмуде источнике знаний рассматривается аж шесть ограничений, иллюстрируемых причудливой формой:

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

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

Итак, во многих случаях необходимым и достаточным будет список из четырёх пунктов. Соль и перец добавляем по вкусу.

Соображение второе — действительно ли ограничения жёстко взаимосвязаны?

Разумеется, мы можем привести друг другу массу примеров жёстких связей — дёргаешь за одно, меняются другие. Однако не следует забывать про такие понятия как производительность, эффективность и технологии. Одну и ту же работу/задачу можно выполнить разными способами, и вполне возможна ситуация, когда, скажем, сроки проекта резко сокращены, а в установленные деньги и качество попасть всё равно можно.

Соображение третье — что делать с ограничениями?

Источники знаний по управлению проектами зачастую не детализируют этот вопрос, рекомендуя менеджеру «держать руку на пульсе«, а также «контролировать ключевые параметры проекта«. Это прекрасно, но что конкретно нужно делать? По моему мнению, список действий менеджера проекта по работе с проектными ограничениями предельно прост. При выявлении выхода или угрозы выхода за установленные органичения менеджер должен:

Соображение четвёртое — «водопад» и Agile смотрят на ограничения по-разному

Многие из нас привыкли действовать следующим образом: заказчик ставит задачу, мы определяем способ её решения, формируем перечень работ, из него получаем оценку сроков и оценку бюджета. Далее согласовываем с заказчиком и приступаем к выполнению. Обратите внимание: мы изначально фиксируем два ограничения (охват и качество), а другие два (сроки и бюджет) являются производными.

Совершенно другая картина в гибких подходах. Получив задачу мы договариваемся о сроках и бюджете первой итерации (спринта), и только затем определяем чего именно получится достичь за выделенные сроки и деньги. То есть охват и качество являются следствием ограничений по календарю и финансам. Такой подход поддерживает общие идеи Agile вроде:

Получается, что прежде, чем планировать проект и работать с проектными ограничениями, следует определиться с подходом к выполнению проекта.

На фото: проектный офис игры, которая была в пятницу, готов к работе, но пока даже не догадывается, что его ожидает.

Источник

Все об ограничениях проекта

Ограничения проекта (Project Constraints, Project Restrictions) – это, наверное, одно из простейших понятий проектного менеджмента. И то ли именно поэтому, то ли вопреки этому – все его постоянно путают с чем-то другим.

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

Например, ограничением может быть «Заказчик недоступен для обсуждения и согласования вопросов проекта с 1 по 10 число каждого календарного месяца)», например, он руководитель какого-нибудь отдела финансов, у них в это время закрытие месяца, он работает 24 часа в сутки. Зная это на самом старте проекта, вы избежите неприятной ситуации, когда по счастливому совпадению в вашем календарном плане все согласования придутся именно на эти числа, и все расписание проекта поедет.

Пример ограничений проекта на нашем любимом примере с ремонтом в квартире:

Ограничения проекта обычно указываются в уставе проекта и впоследствии детализируются при планировании с учетом вводных от заинтересованных лиц.

В чем отличие допущений и ограничений проекта?

Ограничения – это условие, которое принимается за истину, и с учетом которого происходит планирование проекта (и управление им в целом). Т.е. ограничение – это свершившаяся реальность, мы не предполагаем, что ограничение может измениться. Допущения – это то, что вы считаете истиной на текущий момент, но допускаете, что это может истиной не оказаться и осознаете, что этим риском нужно управлять. Ограничения являются вводными для создания плана управления проекта, допущения – вводными для управления рисками проекта.

А в чем сходство? Конечно, также как и в случае с допущениями, велико искушение начать писать в список ограничений все, что придет в голову, но так лучше не делать. Помните, что устав – это документ, который будут читать и согласовывать Заказчик и Спонсор проекта и цель внесения их в устав проекта – скорее договориться на берегу, а не исключить все существующие риски.

Кстати, если вы хотите узнать больше о рисках и о том, как с ними работать – вы можете приобрести наш большой курс по управлению рисками. Шаблон реестра рисков проекта и чек-лист для идентификации рисков в подарок!

Источник

Основные элементы управления проектом, ограничения и условия его реализации

Управление проектом представляет собой открытую динамическую систему которая состоит из связанных между собой работ, взаимодействует с окружающей средой, получая от нее необходимые ресурсы и предоставляя ей полученные результаты, а также находится под воздействием различных факторов риска.

Можно выделить четыре основных элемента управления проектом:

Работы– это трудовые процессы, направленные на достижение результатов и требующие необходимых затрат времени и ресурсов.

К работам следует относить деятельность по созданию материальных объектов (производственные работы), интеллектуально-информационной продукции (научно-исследовательские работы), деятельность по выработке и передаче управляющих воздействий и обратной связи (решения и отчеты), деятельность по перемещению материальных объектов, например ресурсов (поставки).

Под ресурсамиследует понимать совокупность объектов, необходимых для выполнения работ.

Существуют три основные группы ресурсов, используемых в управлении проектом:

1) человеческие ресурсы– субъекты деятельности, объединенные в системы взаимодействия друг с другом и другими ресурсами. По отношению друг к другу человеческие ресурсы могут являться и объектами деятельности. С экономической точки зрения человеческие ресурсы переносят свою стоимость на результаты труда постепенно, создавая при этом добавленную стоимость.

К человеческим ресурсам относят руководителей и работников;

2) материальные ресурсы – средства и предметы деятельности, используемые для выполнения работ. Средства деятельности переносят свою стоимость на результаты в ходе выполнения работ постепенно. Предметы деятельности полностью переносят свою стоимость на результаты работ, как правило, изменяя свою натуральную форму и материально присутствуя в результатах работ.

К средствам деятельности относят машины и механизмы (активные основные средства), здания и сооружения (пассивные основные средства).

К предметам деятельности относят материалы и комплектующие (оборотные средства);

3) информационные ресурсы – управляющие воздействия, направляемые субъектами деятельности на объекты деятельности, определяющие цели и результаты работ. Информационные ресурсы выступают одновременно и как средства, и как предметы управленческой деятельности.

К информационным ресурсам следует отнести проектные решения, модели, управляющие команды (приказы, распоряжения, задания), отчетную документацию и т.п.

Результаты – это продукты деятельности (работ), воплощающие в себе ранее поставленные цели.

Результаты могут быть:

— материальные (продукция, изделия) и нематериальные (информационные – документы, социальный эффект);

— прямые и косвенные;

— промежуточные и окончательные.

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

Потенциальные последствия этих воздействий можно обобщенно определить как риски (т.е. совокупность вероятностных взаимодействий проекта с независимыми факторами окружающей и внутренней среды). Управление рисками представляет собой деятельность по управлению взаимодействием проекта и факторов риска, имеющую своей целью минимизировать отклонения от ранее принятых решений.

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

Рассмотрим проблему неопределенности при разработке и реализации проектов.

Любой проект в силу своей природы осуществляется в условиях неопределенности. Менеджер проекта не имеет полной и достоверной информации обо всех аспектах реализации проекта. Неопределенность является следствием уникальности проекта и, соответственно, может быть связана как с результатами и содержанием работ самого проекта, так и с условиями его реализации.

Проекты могут в значительной степени различаться по уровню неопределенности.

Если целью проекта является создание уникального продукта или системы (либо в ходе проекта проводятся уникальные исследования), то в начале проекта присутствует значительная неопределенность, связанная с конечным продуктом и результатами проекта. Требования к конечным результатам проекта могут уточняться в ходе реализации проекта на основании достигнутых промежуточных результатов.

Если компания внедряет новую версию существующей информационной системы, которая базируется на обновленном программном обеспечении или оборудовании, то уникальность проекта в основном связана с применением новых технологий и существует неопределенность, связанная с работами по наладке нового оборудования и программного обеспечения. Реальная сложность и сроки выполнения этих работ могут значительно отличаться от прогнозируемых.

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

Даже типичный проект (например, строительство типового коттеджа), реализуемый в незнакомом регионе, с привлечением новых поставщиков и подрядчиков, обладает некоторой степенью уникальности и неопределенности.

Часто в одном проекте присутствуют одновременно различные источники неопределенности. Менеджеру проекта важно с самого начала понимать уровень уникальности собственного проекта и области неопределенности.

Чем более уникальным является проект, тем выше неопределенность и сложнее управление проектом.

Системы управления для проектов с различным уровнем уникальности должны различаться.

Например, если вы являетесь менеджером типового проекта с минимальным уровнем неопределенности, то проще выстроить формальную систему взаимоотношений со всеми участниками проекта, которая базируется на едином календарном плане, контрактах и штрафных санкциях за отклонения от плановых показателей. Такие проекты иногда называют «закрытыми», поскольку одна из основных задач менеджера проекта – свести к минимуму отклонения от планов и вносимые в проект изменения.

Если же вы являетесь менеджером уникального проекта с многочисленными областями неопределенности (такие проекты называют «открытыми»), то внесение изменений в содержание и планы проекта неизбежно. В таком проекте нужно выстроить систему управления, позволяющую вносить своевременные изменения в проекте наименьшими затратами.

Система будет базироваться на жизненном цикле проекта, специальным образом спроектированном для определения моментов пересмотра проекта и внесения в него изменений. На основе жизненного цикла проекта строится «карта реализации проекта» (project roadmap), позволяющая привязать к жизненному циклу процедуры подготовки и принятия управляющих решений. Кроме того, для такого типа проектов более важную роль играют процессы управления рисками и коммуникациями.

Риск и неопределенность – связанные понятия. Неопределенность является причиной возникновения рисков. Чем выше неопределенность проекта, тем выше его риск.

Для управления рисками важно понимать причины неопределенности.

Наиболее часто причинами неопределенности могут выступать:

1) недостаток информации об условиях реализации проекта (например, из-за уникальности или ограниченного времени на этапе планирования и сложности получения информации);

2) наличие элемента случайности в условиях реализации проекта (например, состояние погоды в конкретный день);

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

При планировании и организации уникального проекта менеджер проекта часто вынужден принимать решения, базируясь на предположениях и допущениях, которые рекомендуется протоколировать, и анализировать связанные с ними риски. Более подробно процессы управления рисками будут рассмотрены далее.

Следует также сказать об ограничениях и условиях реализации проекта.

Проекты всегда реализуются в условиях различных ограничений. Кроме требований к результатам проекта заказчик определяет требования к реализации проекта, которые и являются для проекта ограничениями.

Менеджер проекта должен тщательно проанализировать существующие ограничения и различные условия внешней среды, которые могут повлиять на реализацию проекта.

Основные ограничения проекта

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

Менеджер проекта должен тщательно проанализировать сбалансированность требований заказчика к содержанию и качеству результатов проекта с ограничениями по времени и по затратам.

Можно ли реализовать проект в рамках определенных заказчиком ограничений? Явный дисбаланс требований и ограничений делает проект нереализуемым. Такой проект либо будет закрыт позже, когда заказчик уяснит реальную стоимость проекта, либо потребует серьезной переработки.

Для определения реальных сроков и обоснования выделения ресурсов, необходимых для реализации проекта, менеджер проекта должен разработать и согласовать с заказчиком план проекта. Если часть ограничений имеет жесткий характер, то менеджер проекта должен разработать план проекта с учетом данных ограничений.

Считается, что ограничения часто взаимосвязаны. Например, за счет увеличения затрат и выделения дополнительных ресурсов можно добиться сокращения сроков реализации проекта. Но это возможно не всегда.

Проекты связаны с рисками, что может привести к необходимости внесения изменений в проект, которые повлияют на один или несколько параметров проекта. Если что-то идет не по плану, обычно проект продлевается, стоимость увеличивается, может ухудшаться качество результатов. Чтобы принять правильное решение, менеджер проекта должен определить и согласовать с заказчиком приоритеты по изменениям параметров проекта при перепланировании. Можно ли вносить изменения в сроки, стоимость или качество?

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

1. Определите абсолютные границы для времени, стоимости или качества.

— Существует ли стоимость, при которой реализация проекта теряет смысл, или максимальный объем доступных средств?

— Существует ли какая-то дата реализации проекта, превышение которой делает проект бессмысленным?

— Каковы минимальные требования к содержанию и качеству результатов, допускаемые заказчиком?

2. Определите основные предпочтения относительно гибкости.

— Если бы у вас не было другого выбора, вы бы предпочли изменить стоимость, время или качество проекта?

— Попробуйте определить предпочтительный выбор: например, вы лучше увеличили бы стоимость на 5% или время на 10%?

3. Определите правила принятия решений по изменениям трех областей.

— Насколько могут изменяться время, стоимость и качество по воле менеджера проекта?

— Каковы границы изменений, для прохождения которых важно получить одобрение заказчика?

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

В частности, ограничения проекта могут включать следующие:

— ограничения на выбор подрядчиков;

— ограничения на доступ и распространение информации;

— ограничения на последовательность выполнения этапов и работ проекта и т.п.

Указанные ограничения должны быть зафиксированы и учтены при разработке системы управления и планов проекта.

Дата добавления: 2017-03-29 ; просмотров: 9196 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Источник