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

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

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

На рис. 5 можно рассмотреть классификацию рисков.

Рис. 5. Виды рисков

В стандарте необходимо указать формальную сторону управления рисками:

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

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

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

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

В стандартах управления проектам выделяются:

1. Стратегии реагирования на негативные риски (угрозы);

2. Стратегии реагирования на позитивные риски (благоприятные возможности);

3. Общие стратегии реагирования на риски;

4. Стратегии реагирования на непредвиденные обстоятельства.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общий вывод по главе

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

4. Преимущества внедрения стандарта

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

Стандарт не заменит всей литературы, его функция заключается в целенаправленном обучении персонала компании. Здесь, на наш взгляд, будет уместен следующий пример. В части процессов УП стандарт предприятия специализирует и детализирует требования рамочных стандартов (таких как ISO 10006 или PMBOK PMI). Точно также в части квалификации управленческого персонала стандарт предприятия специализирует и детализирует требования нормативных документов рамочного характера в этой области (таких как ICB или НТК).

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

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

Стандарт управления проектами и уровень зрелости процессов управления.

Сам факт использования стандарта управления проектами свидетельствует о том, что на предприятии достигнут определенный уровень зрелости процессов управления. Для того чтобы измерить этот уровень и определить направления дальнейшего развития могут применяться различные способы. Одним из популярных подходов является использование моделей зрелости, широко известна модель Capability Maturity Model (CMM), применяемая для оценки зрелости организаций, разрабатывающих программное обеспечение.

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

В качестве другого примера приведем пятиуровневую модель (PM) – Project Management Process Maturity Model.

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

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

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

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