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

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

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

Для начала, поясним термин «отклонения", поскольку литература по управлению проектами трактует по-разному.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 4. Организационные структуры в проектах

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

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

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

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

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

дивизиональная форма организации управления (разновидность функциональной структуры, сформированная по региональному, продуктовому или технологическому признакам;

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

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

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

Глава 5. Тактика и стратегия внедрения стандарта управления проектами

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