В предыдущей заметке мы рассказали о возможных сценариях управления отклонениями и рассмотрели один из видов отклонений - риски. Эта заметка посвящена двум другим видам отклонений - проблемам и изменениям...

Александр Самуилович Товб, руководитель проектов компании IBS, A_Tovb@ibs.ru Григорий Львович Ципес, ведущий системный аналитик компании IBS, GTsipes@ibs.ru

В предыдущей заметке мы рассказали о возможных сценариях управления отклонениями и рассмотрели один из видов отклонений — риски. Эта заметка посвящена двум другим видам отклонений — проблемам и изменениям.

Управление проблемами

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

В ходе реальной работы по созданию и внедрению стандарта управления проектами на предприятии авторам пришлось столкнуться с тем, что словосочетание «управление проблемами» вызывает недоумение у коллег, не имевших опыта знакомства с англоязычными стандартами управления проектами. Многим кажутся более привычными укоренившиеся в русскоязычной литературе термины «решение» или «разрешение проблем», которые соответствуют определениям problem solving или problem resolution, принятым в упоминавшихся в наших заметках так называемых «рамочных» стандартах (см. нашу заметку в ДИС № 1 за август 2001 г.).

Авторы в этом вопросе предпочитают следовать духу и букве таких стандартов управления проектами, как MITP/PMM/WISDDM корпорации IBM, в которых этот процесс называется problems/issues management, что в русском переводе лучше всего, на наш взгляд, выглядит именно как «управление проблемами».

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

Обычно проблемы делят на две категории:

1) локальные проблемы, которые могут быть решены в месте возникновения, то есть на уровне управления проектом, — их и называют problems,
2) эскалируемые проблемы — их называют issues, для разрешения которых требуется подняться на верхние уровни управления, в том числе внешние по отношению к проекту.

В стандарте должна быть отражена формальная сторона управления проблемами:

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

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

Включая процесс управления проблемами в стандарт управления проектами предприятия, следует иметь в виду, что хотя управление проблемами требуется для любых проектов, но степень использования формальных процедур должна соответствовать специфике проекта, и прежде всего его масштабу и сложности (см. нашу заметку в ДИС № 2 за сентябрь 2001 г., посвященную классификации проектов). Для малых проектов издержки от полномасштабного использования этого процесса могут быть непомерно велики.

Управление изменениями

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

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

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

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

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

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

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

Часто стратегия изменений определяется тем, что по крайней мере по одной из осей изменения не должны приводить к выходу из области плановых потерь. А это означает необходимость смещения в одном или сразу в двух других измерениях. Так, если известно, что заказчик ориентирован прежде всего на соблюдение запланированного уровня качества продукта, то должны быть предусмотрены варианты изменений, связанных с манипулированием ресурсами и/или сроками (стратегия «Упрямый заказчик»).

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

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

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

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