Звоните! 
 (926)274-88-54 
 Бесплатная доставка. 
 Бесплатная сборка. 
Ассортимент тканей

График работы:
Ежедневно. С 8-00 до 20-00.
Почта: soft_hous@mail.ru
Читальный зал -->  Международные стандарты управление проектами 

1 2 3 4 5 6 7 8 9 10 11 12 [ 13 ] 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

Таблица 4.1. Матрица степени угрозы риска

Влияние на проект

Вероятность события

Низкая менее 20%

Средняя от 20 до 60%

Высокая более 60%

Слабое

Возможно появление вопросов или проблем в проекте, но вряд ли приведет к нарушению календарного графика, бюджета или ухудшению качества продукта

Низкая

Средняя

Средняя

Среднее

Возможно нарушение графика, увеличение стоимости или ухудшение качества продукта

Низкая

Высокая

Высокая

Сильное

Возможно значительное нарушение графика, увеличение стоимости или ухудшение качества продукта

Средняя

Высокая

Критическая

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

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

По каким сценариям будет развиваться управление отклонениями в проекте, во многом определяется принятыми стратегиями работы с рисками. Мы можем делать все для избежания риска, и тогда наиболее вероятным является второй сценарий (см. рис. 4.1). Мы можем, наоборот, принять риск и не противодействовать ему, допуская развитие событий по первому или по третьему сценарию. Можно также снижать риск, и тогда при благоприятном развитии событий реализуется самый желанный сценарий, когда рисковое событие не наступает.

В качестве типовых стратегий работы с рисками в компании могут быть приняты, например:

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

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

снижение риска - две подстратегии:

♦ снижение вероятности - мероприятия, направленные на уменьшение вероятности наступления рисковых событий;

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

Типовые риски, связанные с ними угрозы и возможные мероприятия по снижению этих рисков показаны в табл. 4.2 на примере ИТ-проектов. Таблица 4.3 представляет собой возможный шаблон документа, предназначенного для описания и ведения риска (одна карточка на один риск).

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

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

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

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

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



Таблица 4.2. Риски и угрозы в ИТ-проектах

Факторы риска

Угрозы

Мероприятия по снижению рисков

Организационные риски

Недостаточная поддержка проекта со стороны высшего руководства заказчик

Увеличение сроков исполнения {Ибот вплоть до их приостановки

Выделение ответственного лица со стороны высшего руководства зазчика, контролирующего сроки и качество работ по проекту

Нарушение баланса интересов участников

Скрытый или явный саботаж со стороны отдельных участников

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

Рассогласование мнения участников по содержательным вопросам

Сложность приемки результатов рабогт и проектной документации

Определение регламентов взаимодействия, п( в, обязанностей и ответственности участников проекта и органов управления

Недооценка сложности проекта

Снижение качества результата работ при попытке уложиться в заданные сроки и бюджет

Определение необходимого уровня детализации планирования

Планирование и использование резервов

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

Позднее выявление ошибок, простои персонала проекта, срыв сроков

Раннее выявление взаимосвязей работ за счет экспертизы проектных решений и привлечения экспертов в смежных областях

Фиксация взаимосвязей в сетевом графике

Риски человеческого фактора

Нежелание части персонала осваивать новые технологии

Снижение эффективности внедрения, возникновение напряженности в коллективе

Разработка системы мотивации персонала

Сложность освоения новых технологий

Высокие требования к квалификации персонала

Разработка вьюококачест-венной пользовательской документации

Организация постоянно действующих курсов подготовки персонала

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

Невозможность успешного внедрения готовой системы

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

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

Таблица 4.2 (окончание)

Факторы риска

Угрозы

Мероприятия по снижению рисков

Технические риски

Неочевидность технических решений, отсутствие аналогов, ориентация на тупиковые технологии

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

Организация процедур внутренней и внешней экспертизы

Неполнота и неточность исходной информации (в том числе отсутствие формализованного описания бизнес-процессов)

Несоответствие результатов проекта ожиданиям заказчика

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

Ошибочный выбор прог{гаммной и/или технической платформы

Высогая стоимость владения

Проведение выбор платформ на тендерной основе, сравнение платформ и обоснование выбор с позиций стоимости владения

Финансовые риски

Недостаточное финансирование

Невозможность завершения проекта

Ранжирование задач по степени важности и поэтапная разработка и внедрение

Несвоевременное финансирование

Потеря первоначальных инвестиций

Корректное формирование бюджета проекта, планирование финансовых резервов

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

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

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

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



Табли14а 4.3. Шаблон документа Карточка риска

Название проекта

Текстовое поле. Название вводится (или выбирается из справочника) из системы регистрации проектов

Код проекта

в поле вводится код проекта из системы регистрации проектов (или выбирается из справочника проектов)

Номер(а) договора(ов)

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

Тип проекта

Коммерческий

Маркетинговый Внутренний

Заказчик

Название выбирается из справочника

Руководитель проекта

Ф. И. О.

Описание риска

Краткая формулировка

DD/MM/YY

Степень угрозы

Критическая О Высокая О Средняя П Низкая О

Статус

Открыт / Анализируется / В работе / Закрыт

DD/MM/YY

Подробное описание риска и план работы с ним

Анализ проведен:

Исполнитель (ФИО)

Дата начала

Дата окончания

Подробное описание риска

Вероятность

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

Влияние

Предлагаемая стратегия работы с риском (привести обоснование выбора)

Стратегия

Варианты действий

Описание предлагаемых мероприятий

Влияние планируемых действий на проект (план, ресурсы и стоимость работ):

Описание предлагаемых мероприятий

Влияние планируемых действий на проект (план, ресурсы и стоимость работ):

Резолюция (решение, сроки исполнения решения)

Исполнитель (ФИО)

Резолюция утверждена

Дата

Ф. И О.

Отчет о результатах выполнения

Дата получения результата: Описание результата:

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

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

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

4.4. Управление изменениями Модели изменений

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

Таблица 4.4. Матрица приоритетов решения проблем

Влияние на проект

Срочность

Несрочная

Первоочередная

Неотложная

Слабое

Вряд ли приведет к нарушению календарного плана, бюджета или ухудшению качества продукта

Несущественная

Незначительная

Важная

Среднее

Возможно нарушение календарного плана, увеличение стоимости или ухудшение качества продукта

Незначительная

Важная

Особо важная

Сильное

Возможно значительное нарушение календарного плана, увеличение стоимости или ухудшение качества продукта

Важная

Особо важная

Особо важная

Особо важные проблемы - требуют немедленного решения с привлечением всех необходимых ресурсов.

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

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



1 2 3 4 5 6 7 8 9 10 11 12 [ 13 ] 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38



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



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.


Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы
.