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

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

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

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

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

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

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

triple_constraint

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

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

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

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

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

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

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

  1. Понять можно ли устранить отклонение, не затрагивая остальные ключевые параметры проекта. Если возможно — найти способ и устранить, скорректировав проект.
  2. Понять влияет ли данное отклонение на другие ограничения, и если да, то как именно. Установить, выходят ли они за установленные пределы, можно ли и как минимизировать выход.
  3. В случае существенных отклонений — идти информировать заказчика и договариваться с ним о новых условиях. В этот момент меняется исходная точка, и проектным ограничениям устанавливаются новые значения.

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

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

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

  • "неплохо бы стоять к клиенту лицом"
  • "правильная приоритизация не повредит"
  • "выдаём как можно скорее результат, который можно использовать"
  • "корректируем ожидаемый конечный результат по мере продвижения проекта и накопления опыта"

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

project_office

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

 

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

GamingWorks Деловые игры на серьёзные темы:

  • Apollo-13 — ITSM на практике
  • Grab@Pizza — ИТ и основной бизнес
  • The Challenge of Egypt — управление проектами
  • 2020 — организационные изменения
  • Проект Феникс — DevOps на практике

 
Узнайте больше!

Комментарии и мнения

  1. Дмитрий Исайченко

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

    0
    0
  2. Андрей

    под охватом скорее всего понимается SCOPE? 

    Все чаще в последнее время слышится про гибкие методики, интересно как ими пользоваться в крупных проектах где планирование занимает 60% от всего выполнения проекта. Напрашивается новая игра (тренинг) в которой можно будет увидеть и потрогать 2 подхода на групных проектах и понять их +/- .

    Если когда нибудь такой тренинг появится, то жду бесплатного приглашения за подаренную идею)

    0
    0
    1. Олег Скрынник Автор

      под охватом скорее всего понимается SCOPE?

      Совершенно верно.

      Напрашивается новая игра (тренинг) в которой можно будет увидеть и потрогать 2 подхода на групных проектах и понять их +/-

      Андрей, такая игра уже существует. "The Challenge of Egypt" можно проводить для стандартного управления проектами ("водопад"), а можно для Agile. Надо сказать, что спрос на Agile-версию сильно меньше.

       

      0
      0

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)