Стандарты управления проектами

Классификация по масштабности проекта позволяет специализировать разделы Организационная структура , Управление отклонениями, Обеспечение качества . Для построения этой классификации могут использоваться различные основания - территориальная разбросанность, как это принято в Enron Corp., или стоимость проекта (IBM), может быть, какие-то другие основания и их комбинации.

Классификация по форме оплаты и, следовательно, учета работ позволяет  специализировать Контроль и отчетность, Управление проектной документацией  на основании таких форм контрактов как "Время и материалы" и "Фиксированная  цена".

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

Рассмотренные выше примеры  классификаций проектов специально подобраны нами для иллюстрации  возможности сборки шаблона из относительно независимых стандартных фрагментов. Однако в реальной жизни встречаются  и другие ситуации. Например, в IBM принята  классификация проектов по сложности (комплексности). В соответствии с  этой классификацией проекты делятся  на обычный бизнес (Business as Usual - BaU), стандартные  проекты системной интеграции и  сложные проекты системной интеграции. Причем именно эта классификация  является определяющей для структуры  и содержания Плана управления проектом. При этом другие классификации сохраняют  свое значение для формирования отдельных  разделов Плана.

2.2 План управления проектом  и рамочные стандарты 

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

Проиллюстрируем это на примере  не самого сложного раздела плана "Организационная  структура проекта". В PMBoK необходимая  информация разбросана по нескольким разделам (2.2.; 2.3.; 2;4.; 4.1.3.; 9), а в ISO 10006:1997(Е) - разделе 5.8. Но и в том и в  другом случае для создания специализированного  шаблона этой информации не достаточно!

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

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

 

3. Проектные отклонения. Риски, проблемы, изменения

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

Однако, уже планируя проект, мы предполагаем, что не все получится  именно так, как запланировано. И  реальное исполнение проекта, как правило, подтверждает эти опасения. Возникающие  несовпадения первоначального согласованного и зафиксированного представления  о проекте (project baseline) и того, что  получается в действительности, и  называются обычно отклонениями. Понимаемый в этом смысле термин "отклонения" эквивалентен термину "deviations", используемому  в англоязычной литературе.

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

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

Отметим, что соображения, представленные в этом разделе, не являются какими-то отвлеченными рассуждениями  и основаны на материалах действующего стандарта управления проектами  компании IBS. Мы благодарны компании за предоставленную возможность использования  этих материалов, и коллективу разработчиков (Илья Виноградов, Мария Чукова) за возможность  использования этих материалов.

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

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

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

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

3.1 Управление рисками

Самое простое, и вместе с  тем необходимое, что должно быть отражено в стандарте - формальная сторона  управления рисками, а именно:

Процедуры, регламентирующие основные этапы работы с рисками - идентификация рисков, мониторинг и анализ рисков, разработка планирование и реализация мероприятий по противодействию  рискам.

Шаблоны документов, отражающих процесс работы с рисками - карточка риска, журнал рисков проекта и т.д.

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

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

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

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

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

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

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

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

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

Шаблоны документов, отражающих процесс работы с проблемами - карточка проблемы, журнал проблем проекта  и т.д.

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

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

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

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

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

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

Плановые потери (учтены в плане управления проектом).

Допустимые потери (незначительные незапланированные затраты).

Нежелательные потери (значительные незапланированные затраты).

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

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

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

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

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

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

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