Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

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

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

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

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

triple_constraint

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

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

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

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

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

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

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

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

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

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

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

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

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

project_office

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

 

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

Комментариев: 6

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

  • Андрей

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

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

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

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

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

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

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

       

  • slava

    Как красиво Олег ушел от "бесплатного приглашения"… 😉
    МАСТЕР!!!


Добавить комментарий для АндрейОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM