Иерархическая структура ограничений

Ограничение (Constraint) – ограничивающий фактор, влияющий на ход исполнения проекта, программы, портфеля или процесса.
©2013 Project Management Institute
Руководство к Своду знаний по управлению проектами PMBOK® – 5 издание

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

1. 

   Рис. 2-9. Воздействие переменной в зависимости от срока проекта.
   ©2013 Project Management Institute. Руководство к Cводу знаний по управлению проектами (Руководство PMBOK®) — Пятое издание

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

2. Одной из основных задач команды управления проектами является уравновешивание конкурентных ограничений проекта. Поэтому и знать эти ограничения нужно как можно раньше, и управлять ограничениями с самого начала, а не тогда когда уже “вышли за флажки и вытоптали весь газон”.

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

Как выявить ограничения?

Берём 6 классических типов ограничений, среди которых: содержание, качество, расписание, бюджет, ресурсы и риски, и строим на основе них Иерархическую структуру ограничений. Этой структурой должны пользоваться руководители проектов при разработке документа “Описание содержания проекта”, а вернее раздела “Ограничения проекта”. Это конечно не гарантирует 100% выявление всех-всех-всех ограничений, но резко снижает вероятность что-то забыть. Более того, появляется однотипный подход к выявлению, классификации и управлению ограничениями. Получаем следующую структуру:

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

Как зафиксировать ограничения?

Тут не стоит городить огород и просто взять классический Журнал допущений, который представляет из себя таблицу:

Где:

• Тип – тип ограничения проекта из нашей Иерархической структуры ресурсов.
• Ограничение – собственно краткое описание самого ограничения, т.е. состояния, качества или понимания сдерживающих факторов, влияющих на определенный образ действия или бездействия, применимых условий (внутренних или внешних), влияющих на ход исполнения проекта или процесса.
• Элемент ИСР – элемент иерархической структуры работ (WBS), к которому относится данное ограничение. Если оно относится к нескольким элементам, то ставиться элемент более верхнего уровня вплоть до самого проекта.
• Источник – Ф.И.О. и контактные данные заинтересованной стороны проекта, определяющей конкретное ограничение. Заинтересованные стороны проекта – это лица или организации (например, заказчики, спонсоры, исполняющая организация или общественность), которые активно участвуют в проекте или интересы которых могут быть затронуты как положительно, так и отрицательно в ходе исполнения или в результате завершения проекта.
• Ответственный – Ф.И.О. и контактные данные лица, несущего ответственность за управление ограничением, в процессе уравновешивания конкурирующих ограничений проекта.
• Состояние – ограничения изменятся по сути, как только станет доступной новая информация.

Могут ли меняться ограничения в ходе проекта?

Для того чтоб ответить на этот вопрос, давайте посмотрим на наиболее прогрессивное определение успеха проекта: “Успех проекта измеряется соответствием результатов проекта последним базовым планам, одобренным уполномоченными заинтересованными сторонами”.

Бывают ситуации, когда руководитель проекта типа “Педант” чётко прописал все ограничения в Устав проекта, согласовал его с заказчиком, заламинировал, повесил на стенку, а потом выполнил проект в строгом соответствии с этим Уставом. Но проект является не успешным, поскольку за время реализации проекта у заказчика поменялись условия существования его бизнеса, что в наше динамичное время случается довольно часто, и результат проекта ему уже не нужен.

А бывает и наоборот, руководитель проекта типа “Разгильдяй” зафиксировал в Уставе только основные ограничения, а потом в два раза превысил бюджет, в полтора раза сроки, да и выполнил не совсем то, что планировалось изначально. Но при этом проект успешен, потому что в проект постоянно “втягивался” заказчик, который регулярно давал новые вводные, а руководитель умело двигал и пересогласовывал ограничения, в т.ч. бюджет и сроки. И результат проекта получился такой, какой нужен заказчику именно на момент окончания проекта, хотя и несколько дороже.

Поэтому ответ – ДА. Менять ограничения в ходе проекта не только можно, но и нужно. Для этого и существует в проекта разумная бюрократия в виде процесса Общего управления изменениями.

Чем помогают и чем мешают ограничения в проектах?

Можем условно разбить ограничения на “плохие” и “хорошие”. Плохие – это те, что мешают команде проекта “размазаться мыслью по древу”, а хорошие – это те, что ограждают команду от чрезмерного давления со стороны заказчика. Но и те, и другие “плохи” и “хороши” лишь условно.

Вот например, условно-плохое ограничение – “Команда обязана формировать регулярный отчёт по проекту не позднее 15:00 каждой пятницы“. Казалось бы, лишняя волокита… но как структурирует знания всех заинтересованных сторон о проекте, как вовлекает заказчика в проект и даёт ему “топливо” для контроля команды, в ведь опытному любому ПМ-у известно – чем больнее контроль процесса, тем проще сдавать результат. Ну, а самое главное регулярность отчётов – это тактовый генератор проекта. Все участники быстро привыкают и начинают синхронно выдавать на гора “план по валу”.

Или вот пример условно-хорошего ограничения – ограничение числа проверок конструкторских чертежей. С одной стороны – это дисциплинирует заказчика и он ответственнее относится к каждой отдельной проверке. Более того, это может снизить и стоимость проекта в целом, но при этом может привести к повышению затрат на эксплуатацию полученного продукта.

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

Как согласовывать ограничения с заказчиком и другими заинтересованными сторонами?

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

В отличие от продавца, руководитель проекта работает минимум с шестью ограничениями. Поэтому и работаем мы не с “треугольником противоречий”, а с “шестигранником ограничений”.

Я на тренингах привожу слушателям занятную демонстрацию. Надуваю воздушный шарик на половину и рисую с разных сторон 6 ограничений: объёмы работ, требования к качеству, сроки, бюджет, доступные ресурсы и риски. Потом пытаюсь шарик сдавить, но ничего не происходит, лишь выпячиваются противоположные ограничения. Потом я надуваю шарик до предела и первая же попытка его сдавить…

Можете взять на вооружение эту демонстрацию. Ведь “перекачанный” по ограничениям проект долго не протянет…

Как правильно отразить ограничения в документах проекта?

Всё зависит от масштаба проекта. Если проект небольшой – достаточно отобразить пару-тройку ограничений в Уставе проекта. Если проект по-больше – используется раздел “Ограничения проекта” в документе “Описание содержания проекта”. Если проект сложный и комплексный – используют отдельный документ “Журнал ограничений” и желательно не в виде файла MS Excel, а в виде электронного лога или реестра в информационной системе управления проектами. Ну, и сама ИСУП позволяет ввозить ограничения непосредственно в расписании проекта. Например, тот же MS Project позволяет вводить визуальные и физические ограничения на сроки, ресурсы и бюджеты.

Шаблоны указанных документов можно получить здесь:

• Устав проекта
• Описание содержания проекта

Автор: Анатолий Савин, PMP