УПРАВЛЕНИЕ ПРОЕКТАМИ

Самоучители ♦ Справочники по стандартам УП ♦ Имитатор экзамена PMP ♦ Обучение

Анализ и мониторинг рисков проекта: 6
Сергей Вратенков. Управление рисками проекта
First Prev 1 2 3 4 5 6 Next Last

Проблемы проекта

Теперь мы разберемся с крайне важным вопросом, тесно связанным с рисками – с проблемами проекта. Определение проблемы такое же, как и у риска:

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

Вы спросите: как же так? Если разницы нет, то к чему еще один термин? Отвечаю: разница есть. Но она не в самом объекте управления, а в способе управления. Риск – это предвиденная проблема. И проанализированная. Когда случается риск, то проблемы все равно возникают. Но для таких проблем в рамках проведенного ранее анализа рисков мы имеем необходимые оценки и даже готовые планы реагирования. Если же случается «чистая» проблема, непредвиденная, то мы должны ее сначала проанализировать, чтобы определить адекватный план реагирования. Мы можем дать более практичное определение проблем:

Проблема – либо непредвиденное событие, которое при наступлении оказывает влияние на проект, либо результат наступления риска

То, что я скажу далее, может показаться очередным парадоксом, которых в этой книге немало, но сказать я должен: в реальной практике управляют не рисками, а проблемами. Почему? – спросите Вы. Я, конечно же, объясню, почему. В конце концов, основная задача этой книги – ответы на почему!

Итак, объясняю. Проблемами управлять надо в любом случае – управляем мы рисками или не управляем, верно? А раз так, то у нас два варианта управления рисками – либо вести параллельное управление, то есть отдельно управляем проблемами, отдельно - рисками, либо для наступивших рисков использовать систему управления проблемами. Вы, надеюсь, не удивитесь, что на практике используется одна система управления, а не две? Особенно учитывая, что разница между рисками и проблемами только в одном – риски анализируются ДО наступления, а проблемы – ПОСЛЕ. И все! Никакой другой разницы нет. Далее все одинаково и для рисков, и для проблем - надо реагировать, значит – исполнять некую последовательность действий. Действия реагирования вставляются в текущий план работ проекта, на работы реагирования назначаются исполнители и эти работы становятся обычными работами проекта. Однако, эти работы все же не совсем обычны – они не были запланированы в утвержденном плане проекта, и чтобы они не затерялись в общей массе работ, для этих работ назначается ответственный, который следит за их исполнением.

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

Пример: Журнал проблем проекта

Проблема

Дата открытия

Дата закрытия

Ответственный

Риск

План

Факт

Срыв поставки 3

02.03.12

12.03.12

 

Иванов

015

Болезнь программиста

08.04.12

09.04.12

09.04.12

Петров

 

Брак материалов в поставке 4

09.04.12

12.04.12

13.04.12

Сидоров

025

 

 

 

 

 

 

Думаю, все понятно из названий столбцов. Даю только необходимые пояснения по сути. Главная графа таблицы – «Дата закрытия, Факт». Если поле этой графы заполнено, то соответствующая проблема уже закрыта, и ее для нас больше нет. Если же поле не заполнено (как у первой проблемы в примере) и, не дай бог, текущая дата больше плановой даты закрытия, то сроки истекли. А значит, есть повод для разборок! И не сомневайтесь, разборки будут, потому что заинтересованных лиц всегда достаточно – это не только менеджер проекта, но и куратор, заказчик, …, далее везде и обычно по нарастающей.

Для тех проблем, которые являются результатом рисков, в графе «Риск» указывается идентификатор риска из Реестра рисков.

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

Пример: Журнал проблем проекта

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

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

Я решил, что раз уж в моих проектах основной проблемой является вал проблем, то я буду вести тотальный учет всех проблем в проекте. Этого нет в PMBOK`е, но есть в жизни!

Завел простую табличку в Excel, назвал ее «Журнал проблем» и на первом же собрании команды проекта всем сообщил, что отныне и впредь никакие стоны и жалобы о внезапно и совершенно неожиданно возникших затруднениях, никакие «а помнишь, я тебе говорил в курилке?», никакие «да это просто невозможно в такие сроки!», никакие все прочие оправдалки больше не работают. Работать будет только то, что занесено в Журнал проблем. По простой причине – мой мозг не способен вместить все проблемы, которые вы создаете! Поэтому будем регистрировать.

Опускаю сложности переходного периода. Сразу перехожу к эффекту.

Начну с самого неожиданного – проектные собрания стали совсем другими. Раньше сначала выступали бригадиры (руководители направлений) и кратко, в рамках 30-минутного регламента, рассказывали сказки о великих победах над всегда более великими катастрофами. Затем начинался контролируемый (1 час по регламенту собрания) всеобщий хай по той же основной теме – все плохо. Одного часа никогда не хватало, иногда собрание как то само собой перерастало в: «а может, по пивку?». Теперь - никаких выступлений и пивков, теперь все просто и быстро! Полчаса, максимум час в тяжелых случаях! Потому, что теперь – конкретные разборки ТОЛЬКО по открытым проблемам в Журнале и, что очень полезно, с совершенно конкретными ответственными. С одним конкретным вопросом – почему не закрыта и что надо сделать, чтобы закрыть.

Не менее неожиданным, и очень полезным лично для меня, как основного мальчика для битья, оказалось аналогичное изменение характера встреч со своим куратором и с куратором от Заказчика. С одной стороны, сказок о героическом преодолении трудностей я больше не рассказываю. С другой стороны, на любую их претензию я теперь не ищу лихорадочно никаких оправданий, нет, конечно. Я солидно лезу в Журнал и совершенно четко сообщаю что-нибудь типа: «Так, это проблема номер такой-то, открыта тогда-то, должна быть закрыта тогда-то, ответственный такой-то, …». Основная закавыка в том, что некоторые проблемы могут быть разрешены только извне проекта, и для таких проблем в графе «Ответственный» указана фамилия не кого-то из команды проекта, а внешнего к проекту сотрудника нашей или их организации. В этом случае я совершенно обоснованно уже сам предъявляю претензию и могу даже эскалировать проблему путем подачи Запроса на изменение сроков или стоимости. Это очень сильный ход потому, что он может привести к пересмотру контракта, причем по вине не проекта, а той организации, чей сотрудник указан ответственным в Журнале. Если же я не нахожу обсуждаемой проблемы в Журнале, то я не менее солидно сообщаю: «Так, такой проблемы нет. Будем открывать?». Далее мы либо открываем ее с полным осознанием всеми сторонами ответственности и последствий, либо она решается вне проекта.

Вот так работает вполне себе банальный Журнал проблем.

На этом обсуждение схемы управления рисками и проблемами проекта закрываем.

 

First Prev 1 2 3 4 5 6 Next Last