Файл: Особенности стандартов управления проектами.pdf

Следует отметить, что вряд ли возможно построить единую древовидную классификацию корпоративных проектов. Скорее всего, это будет несколько классификаций по различным признакам, связанным с определенными разделами Плана. Давайте рассмотрим некоторые из них^[12]:

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

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

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

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

План управления проектом и рамочные стандарты^[14]

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

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

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

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


 

ГЛАВА 2. РАСЧЕТНЫЕ ОТКЛОНЕНИЯ. РИСКИ, ПРОБЛЕМЫ, ИЗМЕНЕНИЯ

Прежде всего, мы объясняем термин «отклонения», это необходимо, поскольку в литературе по управлению проектами это трактуется по-разному.

План управления проектом является «точкой опоры» или отправной точкой для всего последующего развития проекта. Однако, уже планируя проект, мы предполагаем, что не все получится именно так, как планировалось. И фактическое выполнение проекта, как правило, подтверждает эти опасения. Несоответствия первоначальной согласованной и фиксированной идеи проекта (базовой линии проекта) и того, что получается в действительности, обычно называют отклонениями^[15].

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

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

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

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

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

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

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

Самым простым и в то же время необходимым, который должен быть отражен в стандарте, является формальная сторона управления рисками, а именно^[18]:

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

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

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

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

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

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

Как правило, проблемы делятся на две категории - проблемы, которые могут быть решены на месте возникновения, то есть на уровне управления проектом - проблемы и обостренные проблемы - проблемы, которые необходимо поднять на более высокие уровни управления, включая внешние. отношение к проекту^[20].

Стандарт должен отражать формальную сторону управления проблемами^[21]:

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

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

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

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

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

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

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

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

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

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

Рис. 3. Области потерь

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

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

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

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

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



Рис. 4. Стратегии изменений в проекте