Анализ опасностей, которые могут возникнуть при выполнении составленного плана, — один из самых интересных и сложных этапов планирования проекта. От того, как проведен анализ, зависит, будет ли проект успешно завершен. В этом уроке вы научитесь определять риски с помощью MS Project, описывать их и разрабатывать стратегии их смягчения. Для проведения анализа мы задействуем все имеющиеся в нашем арсенале средства: настраиваемые поля, формулы, стандартные и настраиваемые фильтры, сортировки. Но и это не все — в конце урока мы освоим средства анализа проектных данных в Microsoft Excel и с их помощью проведем исследование нашего проекта.
План составлен, проект укладывается в сроки, бюджет соответствует ожиданиям и загрузка ресурсов не превышает их доступность. Самое время задуматься: а удастся ли выполнить этот план, если, например, заболеет сотрудник с уникальными навыками, которого никто не может заменить, или авторы не сдадут статьи в срок, или в типографию вовремя не привезут краску, или произойдет еще что-нибудь непредвиденное? Ответы на эти вопросы можно получить, анализируя риски проекта.
Анализ рисков состоит из нескольких этапов. Сначала нужно определить возможные риски. Затем для каждого из них нужно определить стратегию смягчения влияния риска на проект, то есть действия, предпринимаемые для предотвращения риска или в случае осуществления риска для того, чтобы проект был успешно завершен.
Определение рисков
Часто в процессе определения рисков невозможно детально проанализировать весь план проекта в разумное время (например, если план состоит из нескольких сотен задач). В таких случаях в первую очередь нужно анализировать риски у задач, которые находятся на критическом пути проекта или могут стать критическими. Чтобы определить, какие задачи могут стать критическими, можно воспользоваться оптимистической и пессимистической диаграммами Ганта, полученными в результате анализа методом PERT.
При определении рисков информацию нужно заносить в план проекта. Для этого нужно подготовить настраиваемые поля (файл 1.mpp). Мы переименовали поле для задач Text2 (Текст2) в Описание риска, а поле для задач Texts (ТекстЗ) — в Вероятность осуществления риска, причем для последнего мы создали список значений: Высокая, Средняя и Низкая, что позволит быстро заполнять это поле. Кроме того, на основании таблицы Entry (Ввод) для задач мы создали таблицу Ввод информации о рисках и оставили в ней лишь необходимый набор полей. И наконец, на базе таблицы мы создали два представления: Риски, в котором эта таблица находится рядом с диаграммой Ганта, и комбинированное представление Риски2, в верхней части которого находится представление Риски, а в нижней — Task Form (Форма задач). Теперь можно переходить к определению рисков.
Риски определяются для трех аспектов проекта: расписания, ресурсов и бюджета. Так выявляются события, осуществление которых может помешать завершить проект в срок или создать нехватку ресурсов или денег в определенный момент его выполнения. Если при определении риска становится ясно, как уменьшить его, то нужно сразу же вносить соответствующие изменения в план проекта.
Риски в расписании
Задача, стоящая перед руководителем проекта при анализе рисков расписания, заключается в том, чтобы уменьшить вероятность срыва сроков работ. Срыв сроков работ может произойти в том случае, если длительности задач в плане не будут соответствовать тому времени, которое потребуется ресурсам на их выполнение.
Несоответствие запланированных длительностей работ фактическим может произойти в двух случаях: если неточно составлен план проекта и если неожиданно окажется, что та или иная работа требует больше времени, чем ожидалось. Поскольку каждый проект уникален, то обязательно случится так, что какая-то из задач будет длиться дольше запланированного времени, но чем точнее и детальнее план, тем меньше будет таких задач. Ведь при неточном плане несоответствия возникают даже тогда, когда их могло бы и не быть.
Поэтому уменьшение рисков в расписании начинается с детализации плана работ. Затем нужно обнаружить задачи, у которых вероятность срыва наиболее велика. Эти задачи можно обнаружить по некоторым формальным критериям, рассматриваемым ниже.
Задачи с предварительными длительностями
Один из наибольших рисков представляют задачи, в выполнении которых у сотрудников нет опыта. Например, если бы в нашем проекте при предпечатной подготовке журнала использовалась новая для сотрудников технология, например печать серебром, или новое оборудование, то задача, подразумевающая использование нового оборудования или новых технологий, считалась бы рискованной.
Главная проблема в планировании таких задач заключается в том, что их длительность не известна заранее, поскольку нет опыта в их выполнении. Поэтому обычно при планировании длительность этих задач остается предварительной (estimated). Такие задачи можно обнаружить в плане проекта с помощью стандартного фильтра Tasks With Estimated Durations (Задачи с оценкой длительности).
В нашем плане таких задач нет, но если бы они обнаружились, то пришлось бы изменить план проекта таким образом, чтобы неожиданное увеличение их длительности не сказалось на сроках окончания проекта или на сроках исполнения важных задач (например, тех, у которых сроки исполнения регламентируются договором). Желательно увеличить планируемую длительность исполнения этих задач до пессимистичной и рассчитывать план с учетом этой длительности задач. Кроме того, можно добавить в план отдельную задачу по освоению нового оборудования или технологии раньше того, как начнется выполнение задачи, где это оборудование или технология будет использоваться.
Слишком короткие задачи
Часто при планировании проекта длительность задач определяется на основании оценки будущих исполнителей. Например, руководитель проекта просит сотрудника оценить, сколько времени ему потребуется на исполнение определенной задачи, а затем оценка сотрудника заносится в план. Сотрудники же часто дают слишком оптимистичные сроки, что приводит к тому, что запланированные работы не удается выполнить в срок или сотруднику приходится работать сверхурочно.
Другой источник задач со слишком короткими сроками — сами менеджеры, выделяющие на задачу столько, сколько считают нужным (исходя из ограничений по срокам проекта), не советуясь при этом с потенциальными исполнителями.
Чтобы избежать таких сдучаев, нужно проанализировать все задачи плана проекта длительностью меньше одного дня (кроме вех) и все задачи, у которых при анализе PERT ожидаемая длительность совпадала с оптимистичной. Для этого создадим новый фильтр и настроим его (рис. 16.1, файл 1.mpp). (О том, как создавать и настраивать фильтры см. раздел «Создание фильтра».)

Рис. 16.1. Настраиваем фильтр для отбора коротких задач
Фильтр отбирает задачи, у которых длительность меньше либо равна одному Дню или значение настраиваемого поля Durationl (Длительность!) равно значению настраиваемого поля Duration2 (Длительность2). (Эти настраиваемые поля используются при анализе по методу PERT для хранения информации об оптимистической и ожидаемой длительности.) Среди задач, отобранных по одному из этих критериев, фильтр отбирает те задачи, у которых значение поля Milestone (Веха) равно No (Нет), то есть задачи, не являющиеся вехами. Результат применения фильтра в нашем проекте представлен на рис. 16.2 (файл 1.mpp). Коротких задач оказалось только три, из них две Редколлегии, на которые отведено по 3 часа, и Окончательная сборка журнала, на которую отведено 2 дня. Кроме того, оптимистическая и ожидаемая длительности совпали у (разы Редактирование материалов)

Рис. 16.2. Просматриваем короткие задачи с помощью фильтра
После того как короткие задачи отобраны, определим реалистичность отведенного на них времени. В нашем случае 3 часа на редколлегию — это вполне нормально. Два дня на сборку журнала — срок оптимистичный, но учитывая, что работать будут двое, справиться вполне можно. К тому же, они задействованы на 25% (то есть за 2 дня отработают всего 6 часов), значит, если они не будут укладываться в срок, то будет возможность увеличить загрузку и успеть завершить задачу вовремя.
Если мы обнаруживаем в плане задачи, имеющие неоправданно короткие сроки, то длительность таких задач нужно дополнительно обсудить с будущими исполнителями. При этом желательно запросить у них все три возможных срока исполнения задачи, чтобы внести их в таблицу для анализа PERT и рассчитать длительность задачи.
Слишком длинные задачи и задачи с большим числом ресурсов
Мы уже говорили о том, что при составлении плана стоит избегать слишком длинных задач. Как правило, без детализации работ очень сложно точно оценить трудозатраты для таких задач и возможную загрузку ресурсов, поэтому, включая их в план, вы повышаете вероятность того, что он окажется неточным.
Обнаружить в плане задачи с большой длительностью очень просто. Достаточно воспользоваться автофильтром и отфильтровать задачи по столбцу Duration (Длительность), отобрав задачи с длительностью, превышающей, например, 5 пли 10 дней (об использовании автофильтра см. раздел «Автофильтр» ).
Оптимистическая длительность может совпадать с ожидаемой не точцо, а с определенным допущением, например различаться на 1 или 2 часа. Чтобы такие задачи тоже можно было обнаружить, в этом же файле мы создали фильтр Слишком короткие задачи — 2, в котором можно внести это допущение.
А вот автоматически отобрать задачи с большим числом ресурсов нельзя, поскольку в MS Project нет специального столбца «внутренней» таблицы, в котором было бы указано число ресурсов, назначенных на задачу. Поэтому нам, как обычно, придется воспользоваться настраиваемым полем (файл 2.mрр). Переименуем поле задач Number2 (Число2) в Число ресурсов и поместим в него формулу Len ([Resource Names]) (Len ([Названия ресурсов])) (рис. 16.3).

Рис. 16.3. Настраиваем формулу для определения числа ресурсов
Функция Len определяет длину текстовой строки, переданной ей в качестве параметра. В нашем случае этой строкой является значение поля Resource Names (Названия ресурсов). Чем больше ресурсов назначено на задачу, тем длиннее строка и тем больше будет значение поля Число ресурсов.
Этот метод сравнения задач довольно груб, поскольку не гарантирует точного сравнения числа ресурсов. Точно определить число назначенных на задачу ресурсов можно лишь с помощью макроса (функции этого не позволяют).
После завершения настройки поля отсортируем задачи по этому полю. Для этого с помощью команды меню Project к Sort > Sort by (Проект > Сортировка > Сортировать по) откроем диалоговое окно сортировки и выберем созданное поле в качестве критерия. Сортировать задачи будем по убыванию, чтобы задачи с наибольшим числом ресурсов оказались в верхней части списка, и сбросим флажок Keep outline structure (Сохранить структуру), чтобы сортировка осуществлялась в рамках всего проекта, а не в рамках отдельных фаз (рис. 16.4, файл 2.mрр).
На рис. 16.5 (файл 2.mрр) задачи в верхней части представления отсортированы по числу ресурсов. В задачах в начале списка задействовано по 4-5 сотрудников, в задачах чуть ниже — по 2-3 человека. В нижней части представления отображена Форма задач (Task Details Form), в которой можно просмотреть детальную информацию о задаче, выбранной в верхней части представления.
Определив задачи с большими длительностями или большим числом назначенных ресурсов, нужно разбить их на серию более коротких задач или превратить в фазы, поскольку, как правило, в рамках длинной задачи решается несколько коротких. Еще одно подтверждение тому — много назначений на задачу: как правило, над решением одной задачи работает не больше двух человек, а если их назначено больше, то это значит, что задача может быть разделена на несколько составляющих.

Рис. 16.4. Сортируем задачи по созданному полю

Рис. 16.5. План проекта после сортировки задач по числу ресурсов
Список всех предшественниц задачи приведен в поле Predecessors (Предшественники), причем номера задач-предшественниц разделены точками с запятой (см. раздел «Редактирование связей в таблице»). И если в этом поле встречается хотя бы одна точка с запятой, значит, у задачи есть как минимум две предшественницы. Поэтому наш фильтр будет отбирать те задачи, у которых в поле Predecessors (Предшественники) содержится точка с запятой.
В результате работы фильтра важно не только обнаружить задачи с несколькими предшественницами, но и понять, как эта задача связана с другими задачами в плане проекта. Поэтому созданный фильтр удобнее всего применять в режиме подсветки, чтобы задачи с несколькими зависимостями лишь подсвечивались среди всех остальных (о фильтрации в режиме подсветки см. в разделе «Фильтры» ).
Например, на рис. 16.8 (файл 4.mрр) мы применили новый фильтр в представлениях Gantt Chart (Диаграмма Ганта) и Network Diagram (Сетевой график) и совместили окна с этими представлениями в одном окне. В верхнем окне в таблице строки с задачами, подсвеченными фильтром, выделены голубым шрифтом (14, 42, 43), а в нижнем цветом выделены блоки, обозначающие задачи (на рисунке виден только блок 14).

Рис. 16.8. Новый фильтр применен в двух разных представлениях
После того как задачи с несколькими зависимостями обнаружены, нужно определить, как можно уменьшить риск их задержки. Уменьшить риск можно, увеличив длительности одной или нескольких задач-предшественниц за счет более раннего их начала (если это возможно). Кроме того, можно увеличить запланированную длительность задачи, если ограничения по длительности проекта позволяют это сделать.
Иногда одна из двух задач начинается намного позже другой, и тогда она создает временной резерв другим. Например, на рис. 16.9 (файл 5.mpp) у задачи Верстка обложки две предшественницы, одна из которых, Фотосъемка модели, завершается за неделю до планируемого начала верстки обложки. В этой ситуации риск задержки верстки из-за фотосъемки минимален, потому что у последней есть очень большой временной резерв.

Рис. 16.9. Анализ зависимостей у задачи Верстка обложки
Создавать такие резервы можно, когда дата начала одной из задач-предшественниц связана с другой задачей или имеет ограничение, а у другой задачи такого ограничения нет. Если перенести задачу, дату начала которой ничто не ограничивает, на более ранний срок, то это создаст ей временной резерв.
Задачи с внешними зависимостями
Иногда задачи зависят от внешних по отношению к проекту событий, не задей-ствующих проектные ресурсы и не поддающихся планированию. Например, если организация выполняет два взаимосвязанных проекта, то в качестве предшественника задачи может выступать задача из другого проекта.
Определить такие задачи с помощью фильтра можно лишь в том случае, если в качестве предшественников выступают задачи, хранящиеся в других файлах проектов. В таком случае для обнаружения этих задач нужно настроить фильтр, созданный нами для определения задач с несколькими предшественницами (см. рис. 16.7), заменив символ «;» на «\».
Бывает и так, что у задачи нет предшественниц в других файлах проектов, но, тем не менее, внешние зависимости у нее есть. Обычно такие задачи может определить лишь менеджер при анализе плана вручную.
Чтобы эти задачи можно было определить на формальной основе, при создании списка задач можно добавить настраиваемое поле типа Flag (Флаг) и изменять его значение для задач с внешними зависимостями.
В нашем проекте такой задачей является Статьи поступили в редакцию, поскольку срок ее выполнения зависит от скорости работы авторов, что является внешней (то есть непроектной) зависимостью. Риск того, что авторы сдадут статьи позже срока, довольно велик. Поскольку сразу уменьшить этот риск мы не можем, просто зафиксируем его (рис. 16.10, файл б.mрр), заполнив соответствующие поля таблицы, чтобы вернуться к нему чуть позже, когда будем разрабатывать стратегию смягчения влияния рисков на проект.

Рис. 16.10. Заносим информацию о риске в план проекта
Ресурсные риски
Цель анализа ресурсных рисков заключается в том, чтобы определить ресурсы и назначения, увеличивающие вероятность срыва проекта. Например, рискованно привлечение недавно принятого на работу сотрудника, поскольку у нас нет опыта работы с ним и мы не знаем, сможет ли он справиться с поставленными задачами. Другой риск — использование одного сотрудника в слишком многих задачах, поскольку проект становится зависимым от одного сотрудника, и если он станет недоступным, то проект может провалиться.
Использование неопытных сотрудников
Часто случается так, что для проектных работ привлекаются сотрудники, недавно вступившие в организацию. Поскольку еще нет опыта использования этих сотрудников в проектах, это представляет определенный риск. Нужно определить задачи, где задействованы эти сотрудники, и описать риск их использования. При разработке стратегии смягчения рисков эти риски нужно будет проанализировать и определить, как их уменьшить.
Чтобы выделить сотрудников без опыта работы, настроим столбец FlagZ (Флаг2), назвав его Опыт есть, и определим отображение красного индикатора для тех случаев, когда значением поля является No (Нет), и зеленого — когда значением является Yes (Да). Добавим настроенное поле в представление Resource Sheet (Лист ресурсов) и установим в нем значение No (Нет) для тех ресурсов, у которых нет опыта работы. В нашем случае в проекте задействованы только два ресурса без опыта: Тарасова и Жуков (рис. 16.11).
Теперь разделим окно, отобразим в нижней части представление Task Usage (Использование задач) и откроем таблицу Ввод информации о рисках. Для того чтобы в ней отобразились только те задачи, в которых задействованы неопытные сотрудники, выделим этих сотрудников в списке в верхнем представлении, щелкнув на их фамилиях при нажатой клавише Ctrl (рис. 16.12).
На рис. 16.12 видно, что в двух задачах из трех неопытные сотрудники работают вместе с более опытными, поэтому вероятность осуществления риска в этих случаях мы определили как среднюю. И лишь у той задачи, где задействован один Жуков, риск был оценен как высокий.

Рис. 16.11. Ресурсы без опыта отмечены красными индикаторами

Рис. 16.12. Вводим информацию о рисках для задач, где задействованы сотрудники без опыта работы
Ресурсы с большим объемом работы
Иногда загрузка между участниками проекта распределяется неравномерно, и некоторые из членоп команды делают больший объем работы, чем другие. Если не проконтролировать распределение работы, то может оказаться, что некоторые сотрудники отвечают за исполнение слишком большого числа задач. Слишком высокая ответственность отдельных сотрудников опасна тем, что в случае болезни такого «ключевого» сотрудника или недоступности его по другой причине выполнить все задачи в срок будет невозможно.
Определить ресурсы с большим числом назначений можно с помощью представления Resource Usage (Использование ресурсов). Откроем в этом представлении таблицу Work (Трудозатраты) и отберем для отображения только человеческие ресурсы, воспользовавшись фильтром Resources — Work (Ресурсы — трудовые). Затем отсортируем ресурсы по убыванию по колонке Work (Трудозатраты). Теперь участники проекта с наибольшей загрузкой отображаются в начале списка.
Для того чтобы просмотреть, какое место в плане проекта занимают назначения наиболее занятых сотрудников, разделим окно и в нижнем представлении отобразим диаграмму Ганта. Теперь при выборе ресурса в верхнем представлении в нижнем отображаются все его назначения, как в таблице, так и на диаграмме (рис. 16.13, файл 7.mрр, Представление 1).

Рис. 16.13. Просматриваем задачи, в которых задействованы наиболее загруженные ресурсы
Критические задачи выделены красным, и чем в большем числе критических задач задействован ресурс, тем выше опасность срыва сроков проекта, если этот ресурс вдруг перестанет быть доступным. Поскольку в этом случае риск, связанный с задействованностью ресурса, распространяется на все задачи, в которых он участвует, то нет смысла заполнять поля с описанием риска для задач — удобнее создать аналогичные настраиваемые поля для ресурсов и вводить информацию в них.
Чтобы внести в план информацию о ресурсных рисках и использовать ее в дальнейшем при разработке стратегии смягчения рисков, изменим настраиваемые поля для ресурсов Text2 (Текст2) и Texts (ТекстЗ). Переименуем их в Описание риска и Вероятность осуществления риска. Поскольку во втором поле можно использовать список значений, уже составленный нами в аналогичном поле для задач, импортируем его с помощью кнопки Import Custom Field (Импорт настраиваемого поля).
В поле Text2 (Текст2) могут вводиться одинаковые риски для разных ресурсов, поэтому настроим список значений таким образом, чтобы при вводе можно было указывать значения, не входящие в список, и они автоматически добавлялись бы в него для дальнейшего использования (о настройке списка значений поля см. раздел «Создание настраиваемых полей со списком значений»). Создадим новую таблицу на базе ресурсной таблицы Entry (Ввод), назовем ее Ввод информации о рисках ресурсов и добавим в нее настроенные поля. Теперь откроем ее в верхнем представлении и заполним ее данными для ресурсов, выполняющих большой объем работы (рис. 16.14, файл 7.mрр, Представление 2).

Рис. 16.14. Вводим информацию о ресурсных рисках
Наиболее «рискованными» ресурсами проекта являются Иванов, Петров и Сидоров, задействованные в самом большом числе задач, большинство из которых лежит на критическом пути. Соответственно, в поле Описание риска введем Срыв работ из-за недоступности ресурса, а в поле Вероятность осуществления выберем значение Высокая.
Ресурсы со сверхурочной работой
Сотрудники, загруженные сверхурочной работой, из-за усталости могут начать работать медленнее, чем обычно. Поэтому при планировании стоит избегать использования сверхурочной загрузки. Если же при составлении плана вам пришлось запланировать сверхурочную работу, то при анализе рисков стоит предусмотреть ее возможные последствия.
Для анализа мы будем использовать то же представление, что и в предыдущем примере, но на диаграмме использования ресурсов отобразим детальные данные о превышении нагрузки и сверхурочных (об отображении подробных данных на диаграмме см. в разделе «Выбор типа отображаемой на графике информации и ее форматирование» ). Пролистывая эту диаграмму, можно быстро обнаружить ресурсы со сверхурочной нагрузкой (рис. 16.15, файл 5.mpp).

Рис. 16.15. Обнаруживаем в проекте ресурсы со сверхурочной загрузкой. На диаграмме в верхней правой части экрана отображаются данные о сверхурочной работе (Ovt. Work) и превышении доступности ресурсов (Overalloc)
В нашем примере сверхурочная загрузка есть у Буркова, и поэтому укажем в описании риска Срыв работ из-за усталости ресурса. Но поскольку объем сверхурочной работы небольшой, то вероятность осуществления риска оценим как среднюю.
Сотрудники с уникальными навыками и материалы с единственными поставщиками
Проект может оказаться под угрозой срыва, если неожиданно станет недоступен сотрудник, обладающий особыми знаниями или навыками, поскольку только он может выполнить определенные задачи проекта. Кроме того, риск провала проекта из-за несвоевременной поставки материалов повышается, если материалы могут быть получены только от одного поставщика, поскольку в этом случае выполнение проекта становится зависимым от качества его работы.
Чтобы определить такие ресурсы и внести в план информацию о рисках, связанных с их использованием, откроем представление Resource Sheet (Лист ресурсов) и отобразим в нем таблицу Ввод информации о рисках ресурсов. Затем нужно определить риски с уникальными знаниями и ввести в таблицу описание рисков и вероятность их осуществления.
На рис. 16.16 видно, как мы заполнили эту таблицу в файле 9.mрр. Поскольку Краска для вывода пленок и Бумага для типографии поставляются нам единственной компанией, то использование этих ресурсов мы считаем рискованным. Но так как с компанией-поставщиком мы работаем уже давно и срывов в поставках никогда не было, вероятность осуществления риска оценим как низкую.

Рис. 16.16. Вводим в план проекта описание рисков для сотрудников с уникальными знаниями и материалов с единственным поставщиком
Среди сотрудников только Лимонов обладает уникальными знаниями, и его отсутствие может сказаться на сроках исполнения работ. Поэтому и для него мы укажем соответствующий риск, оценив степень вероятности его осуществления как среднюю.
В нашем проекте задействовано не так много ресурсов, и поэтому просмотреть весь список и внести информацию о рисках можно довольно быстро. Если же проект, в котором вы оцениваете ресурсные риски, содержит большое число ресурсов, то при их анализе стоит воспользоваться стандартными фильтрами Resources — Material (Ресурсы — материальные) и Resources — Work (Ресурсы — трудовые), с помощью которых можно отобрать для анализа только сотрудников или только материалы.

Бюджетные риски
В результате осуществления рисков возможно увеличение объема работы по проекту, что приведет к росту затрат на него. Риск увеличения бюджета проекта стоит рассматривать тогда, когда проект имеет ограниченные бюджетные рамки.
Например, в нашем проекте задействованы в основном штатные сотрудники организации, регулярно получающие зарплату, и бюджет проекта не имеет большого значения. Бывают и другие случаи: например, проект может выполняться на заказ, и заказчик может выделять на выполнение работ определенную сумму, которую нельзя превысить.
В тех случаях, когда затраты на проект ограничены, важно предусмотреть риск увеличения бюджета в результате тех или иных обстоятельств. Для оценки возможного увеличения бюджета можно применять различные методики. Мы продемонстрируем здесь оценку возможного изменения стоимости проекта на основании данных, полученных в ходе анализа PERT.
Наш анализ исходит из предположения, что при увеличении длительности задачи объем работ всех назначенных ресурсов и, соответственно, цена возрастают пропорционально. Например, если задача длится 2 дня и стоит $100, то при увеличении длительности до 4 дней стоимость возрастет до $200. Этот метод оценки не очень точен, но он и не претендует на точность. Ведь при планировании рисков сложно предсказать, как именно будут задействованы ресурсы при увеличении длительности назначения. Задача анализа — определить возможный бюджет проекта при неблагоприятном развитии событий и задачи, цена которых сильно увеличится при осуществлении рисков.
Переименуем таблицу PA_PERT Entry (Ввод PA_PERT) в Бюджетные риски. Затем на основе фильтра Milestones (Вехи) создадим фильтр Not Milestones, изменив условие в исходном фильтре на противоположное. После его применения на плане не будут отображаться задачи с нулевой длительностью.
При анализе PERT программа автоматически помещает значения оптимистической, ожидаемой и пессимистической длительности в поля Durationl-З (Длительность1-3). Если разделить длительность каждого из типов на длительность, внесенную в план проекта (поле Duration (Длительность)), то в результате мы получим коэффициент, который можно использовать для расчета стоимости. Например, если длительность задачи в плане составляет 2 дня, а пессимистическая длительность составляет 4 дня, то коэффициент будет равняться 2. Соответственно, пессимистическая стоимость задачи будет равняться стоимости, умноженной на этот коэффициент, и в случае неблагоприятного развития событий будет в два раза больше запланированной.
Настроим три поля типа Cost (Затраты) для расчета стоимости каждого из типов по этой формуле. На рис. 16.17 (файл 10.mрр) представлена формула для поля Cost3 (ЗатратыЗ), переименованного в Opt. Cost. В формуле используется поле Durationl (Длительность!), хранящее оптимистическую длительность задач.
После настройки всех трех полей таблица примет вид, представленный на рис. 16.18 (файл 10.mрр). Видно, что в случае неблагоприятного развития событий стоимость проекта может увеличиться более чем на $15 000 (вычитаем из пессимистической стоимости планируемую стоимость), что составляет лишь 15,5% от общей стоимости проекта. Но у отдельных задач или фаз отклонение цены может быть значительным, и нужно проанализировать план, чтобы понять, у каких задач в случае осуществления риска стоимость может существенно измениться. Для этого рассчитаем для каждой задачи процент отклонения пессимистической стоимости от запланированной.

Рис. 16.17. Настройка поля для расчета оптимистической стоимости проекта

Рис. 16.18. Варианты стоимости проекта при разных вариантах развития событий
Переименуем поле Numbers (ЧислоЗ) в Разница стоимости (файл 11.mpp) и введем в него формулу, представленную на рис. 16.19. Сначала определяется разница между пессимистической ценой и запланированной, для чего из поля Cost5 (Затраты5), где хранится пессимистическая стоимость, рассчитанная в предыдущем примере, вычитается планируемая стоимость, хранящаяся в поле Cost (Затраты). Затем мы определяем, какой процент от запланированной стоимости составляет полученная разность. Для этого полученное в результате вычитания число делится на запланированную стоимость и результат умножается на 100.
Чтобы полученный результат было легче обрабатывать, настроим отображение индикаторов для поля (рис. 16.20). Те задачи, у которых отклонение при неблагоприятном развитии событий составит более 50%, пометим красным индикатором. Задачи с отклонением больше 25% пометим желтым, а с отклонением больше или равным 10% — зеленым. Задачи с отклонением менее 10% пометим флажком (эта настройка не видна на рис. 16.20, файл 11.mpp). Установим флажок Show data values in ToolTips (Показывать значения данных во всплывающих подсказках), и тогда значение поля будет отображаться при наведении курсора на индикатор.

Рис. 16.19. Формула для определения процента отклонения стоимости при пессимистическом сценарии

Рис. 16.20. Настройка графических индикаторов для отображения данных об отклонении стоимости
Определение количественных характеристик отклонений (чтобы решить, какое отклонение считать слишком высоким, а какое приемлемым) зависит от принятых в организации стандартов. В нашем случае будем считать отклонение менее 10% приемлемым, а более 50% — слишком высоким и нуждающимся в коррекции.
На рис. 16.21 (файл 11.mpp) представлена таблица Бюджетные риски после того. как настройка поля завершена. К таблице применен фильтр Not Milestones для отбора всех задач, кроме вех. Задачи плана, помеченные красным индикатором, нуждаются в коррекции: нужно или уменьшить пессимистическую оценку стоимости для них, или увеличить планируемую стоимость.

Рис. 16.21. Анализируем отклонение по стоимости при помощи индикаторов
После завершения коррекции нужно определить пессимистическую стоимость проекта, согласовать ее с руководством и учитывать при планировании финансирования проекта. Если события будут развиваться по неблагоприятному сценарию, организация должна быть готова к выплате необходимого проекту бюджета. Пессимистическая стоимость проекта указана в колонке Pes. Cost в строке суммарной задачи проекта (первая строка на рис. 16.21).
Разработка стратегии смягчения рисков
После того как мы выявили проектные риски, нужно определить меры, смягчающие их влияние на проект. Это можно сделать двумя путями: разработать план их сдерживания или план реакции на них.
План сдерживания рисков (mitigation plan) состоит из работ, которые включаются в план проекта и, будучи выполненными, существенно снижают вероятность осуществления риска. План реакции на риски (contingency plan) определяется в плане проекта, но не оформляется в виде задач до осуществления риска. Если риск осуществляется, нужные задачи добавляются в план проекта.
Определяя стратегию смягчения рисков, следует всегда сравнивать затраты на предотвращение риска с затратами, которые будут понесены, если риск осуществится. Например, если в случае осуществления риска бюджет возрастет на $100, то стоимость работ по сдерживанию не должна превышать этой цифры. Когда важнее сроки проекта, следует сравнивать длительность плана в случае осуществления риска с длительностью плана, учитывающей задачи на его смягчение.
План сдерживания рисков
Для сдерживания рисков в план нужно включить работы, выполнение которых понизит вероятность осуществления риска. Например, у задачи Статьи поступили в редакцию есть высокий риск задержки из-за того, что авторы сдадут статьи позже срока. Чтобы снизить его, добавим в план задачу Проверка состояния статей, выполняя которую редакторы разделов свяжутся с авторами и напомнят им о сроках сдачи текстов (рис. 16.22, файл 13.mpp). При этом длительность проекта не увеличилась.

Рис. 16.22. Добавляем задачу для обеспечения своевременной поставки текстов
Аналогично можно предотвратить и ресурсные риски. Например, чтобы избежать риска срыва работ из-за несвоевременной поставки материалов, добавим в план работ задачу Оформить предварительный заказ материалов для типографии, которая должна быть выполнена за три дня до завершения верстки журнала (рис. 16.23, файл 15.mpp). Добавление этой задачи тоже не повлияло на длительность проекта.

Рис. 16.23. Добавляем задачу для обеспечения своевременной поставки материалов
Обычно большинство рисков можно предотвратить, проведя соответствующие работы, но иногда это не получается или же считается нецелесообразным. Для таких задач нужно разработать план реакции на риски.
План реакции на риски
Многие риски часто имеют очень низкую или неизвестную вероятность осуществления. Кроме того, для некоторых рисков нельзя определить момент их наступления. Например, есть риск, связанный с использованием Лимонова, поскольку тот обладает уникальными знаниями, и все четыре задачи, где он задействован, не могут быть выполнены без его участия. Но точно определить момент наступления риска нельзя, поскольку он не связан с календарем проекта. В подобных случаях нужно разработать план реакции на риск, который будет применен в тот момент, когда риск осуществится.
План реакции на риски хранится в плане проекта в виде текстовой информации, связанной с определенными задачами или ресурсами. Для хранения информации о реакции на ресурсные риски настроим ресурсное поле Text4 (Текст4), переименовав его в План реакции на риски (файл 14.mрр). Пример заполнения его данными представлен на рис. 16.24.

Рис. 16.24. Составляем план реакции на риски
Даже после того, как план проекта проанализирован, многие риски выявлены и разработана стратегия смягчения их влияния на проект, все равно сохраняется вероятность, что в ходе выполнения проекта может произойти нечто непредвиденное. Иными словами, вполне возможно, что какие-то риски не были выявлены либо их существование нельзя предположить на нынешнем этапе планирования проекта. Поэтому в план нужно заложить временной и финансовый буфер, позволяющий отреагировать на возникающие риски и снизить вероятность увеличения длительности проекта.
Финансовый буфер можно создать простым увеличением стоимости проекта на коэффициент, который принято использовать в вашей организации в таких случаях. Например, если бюджет проекта составляет $100 000, а пессимистический бюджет — $120 000, то с учетом буфера бюджет проекта может равняться $130 000. Формирование временного буфера рассмотрим более подробно.
Формирование временного буфера
В хороший план проекта должна быть заложена определенная степень устойчивости к возникающим рискам. Так как риски приводят к задержкам в исполнении работ, то устойчивость к рискам подразумевает в первую очередь возможность начать исполнение некоторых задач позже даты, указанной в плане, и при этом закончить проект в срок.
Если у задачи можно перенести дату начала на более поздний срок или увеличить длительность, значит, она не является критической. Поэтому чем меньше в плане проекта критических задач, тем больше он подготовлен к возникающим рискам. Если план состоит только из критических задач, то он вряд ли будет выполнен в срок, поскольку в таком плане любая задержка приводит к смещению даты окончания проекта. В зависимости от стандартов планирования, принятых в организации, в плане проекта должен быть определенный процент некритических задач.
Для анализа существующего в плане временного резерва удобно воспользоваться представлением Gantt Chart (Диаграмма Ганга) и таблицей Schedule (Календарный план), в которой отображается информация о существующем временном запасе. Для того чтобы эта же информация отображалась и на диаграмме, настроим ее с помощью мастера Gantt Chart Wizard (Мастер диаграмм Ганта).
На первом шаге мастера (определение типа информации для отображения на диаграмме) выберем переключатель Custom Gantt Chart (Настроить диаграмму Ганта). На следующем шаге выберем переключатель Yes ( Да) для отображения информации о критических и обычных задачах разными способами. После этого пропустим все диалоговые окна с настройками цветов отрезков и дойдем до пятого, в котором определяются типы дополнительных отрезков, отображаемых па диаграмме (рис. 16.25, файл 15.mpp).

Рис. 16.25. Выбираем дополнительные отрезки для отображения на диаграмме Ганга
В этом диалоговом окне выберем переключатель Total slack (Общий временной резерв). Данные о существующем у задач резерве будут отображаться в виде тонких отрезков. На образце в области предварительного просмотра видно, что временной резерв может быть только у обычных задач (они более темные), поскольку у критических его не бывает. Теперь самые важные настройки завершены и можно нажать кнопку Finish (Готово) прямо в этом диалоговом окне. Представление настроено, и можно начать работу с временным буфером (рис. 16.26, файл 15.mpp).

Рис. 16.26. Данные о временном резерве отображаются в таблице и на диаграмме
Таблица Schedule (Календарный план) содержит несколько колонок, с помощью которых можно определить степень устойчивости к рискам как расписания проекта в целом, так и его отдельных задач. В колонке Total Slack (Общий временной резерв) содержится информация о времени, на которое исполнение задачи можно отложить, чтобы длительность проекта не изменилась. Колонка Free Slack (Свободный временной резерв) содержит информацию о времени, на которое можно отложить исполнение задачи, чтобы не задерживать последующие задачи. A в колонках Late Start (Позднее начало) и Late Finish (Позднее окончание) содержатся самые поздние даты, когда можно начать и окончить задачу, чтобы не изменить дату окончания проекта.
ВНИМАНИЕ
Поле свободного временного резерва или общего резерва обычно содержит значение от нуля и больше. Если общий временной резерв задачи равен нулю,то она является критической (Если не изменены стандартные настройки (см. раздел «Анализ критического пути проекта»). Однако при расчете временного резерва учитываются крайние сроки задачи и ограничения (см. пример ниже), поэтому если окончание задачи запланировано позже крайнего срока, то ее временной резерв будет отрицательным. Это значит, что ее не только нельзя отложить, а наоборот, надо ускорить. Если хотя бы у одной задачи проекта временной резерв меньше нуля, то временной резерв всего проекта (суммарной задачи проекта) также будет меньше нуля.
На диаграмме информация об общем временном резерве задачи (Total Slack) отображается с помощью тонких отрезков. Например, у задачи 21 на рис. 16.26 (файл 15.mpp) значение поля Total Slack (Общий временной резерв) составляет 31,87 дня, и рядом с отрезком, обозначающим задачу, расположен тонкий отрезок такой же длительности.
MS Project рассчитывает общий и свободный временной резерв задачи, исходя из ее ограничений и положения в плане проекта. В нашем примере, исходя из положения задачи Проверка состояния статей в плане проекта, временной резерв составил больше 30 дней, хотя на самом деле эта задача должна быть выполнена за несколько дней до начала задачи Статьи поступили в редакцию, начинающейся 21.02.02. Поскольку мы не указали такое ограничение, программа рассчитала резерв неправильно. В файле 16.mрр мы указали в качестве крайнего срока окончания задачи Проверка состояния статей дату 18.02.02, и временной резерв сразу уменьшился до 1,87 дня.
После того как вы просмотрите файл проекта и убедитесь, что временной резерв у каждой задачи соответствует действительности, нужно попытаться найти в проекте несбалансированности. Например, может оказаться, что у одной пз фаз слишком большой резерв, а у другой его нет или он вовсе отрицательный. В таком случае стоит перенести часть задач из фаз с маленьким резервом в те, где он значительно больше.
В плане не должно быть задач или фаз с отрицательным резервом, потому что наличие таких задач свидетельствует об ошибках в плане проекта. Отрицательный временной резерв может образоваться, если задача заканчивается после крайнего срока или если нарушены даты ограничений у соседних с ней задач. Чтобы быстро найти задачи с отрицательным резервом, можно отсортировать таблицу по убыванию по полю Total Slack (Общий временной резерв).
Если задачи с ограничениями имеют предшественниц, заканчивающихся слишком поздно для того, чтобы ограничение было удовлетворено, у последующих задач образуется отрицательный резерв. Чтобы задачи с ограничением и с отрицательным резервом помещались в расписании в соответствии со связями, а не с датами ограничений, в диалоговом окне Options (Параметры) на вкладке Schedule (Планирование) нужно сбросить флажок Tasks will always honor their constraint dates (Для задач всегда соблюдаются заданные для них даты).
Добавить резерв на задачи критического пути можно, увеличив их длительность или вставив задачи-буферы. Тогда при выполнении проекта длительность буферов нужно будет уменьшать, и после завершения проекта их длительность будет равна нулю.
Если резерв задач можно огранизовать с помощью таблицы, то временной резерв проекта можно определить с дополнительных индикаторов. Например, можно запланировать закончить проект раньше реально нужного срока. Или же, как мы сделали, добавить крайний срок на последнюю задачу плана. В таком случае время между окончанием задачи и ее крайним сроком и будет временным резервом проекта.
Анализ распределения трудозатрат
Когда план проекта готов и в него заложены буферы и временной резерв, следует проанализировать распределение трудозатрат в проекте. Эта информация часто оказывается полезной: например, можно заметить, что в определенные периоды в проекте наступает перерыв, который можно заполнить работами. Кроме того, руководитель проекта сможет оценить, в какие периоды его ожидает более интенсивная работа, а в какие нагрузка будет спадать.
Анализ распределения трудозатрат выполняется в MS Project специальным мастером, вызываемым с помощью кнопки Analyze Timescaled Data in Excel (Анализ повременных данных в Excel), расположенной на панели инструментов Analysis (Анализ). Кстати, с помощью другой кнопки этой панели (рис. 16.27), PERT Analysis (Анализ PERT), можно отображать и убирать панель анализа методом PERT.

Рис. 16.27. Панель анализа данных
После щелчка на кнопке Analyze Timescaled Data in Excel (Анализ повременных данных в Excel) появляется окно мастера анализа данных в Excel. На первом шаге нужно выбрать, анализировать ли весь проект или только выбранные задачи (если мастер запускается, когда открыто представление для просмотра ресурсов, то нужно выбрать, все ресурсы анализируются или только выбранные). На втором шаге выбираются поля «внутренней» таблицы, которые будут проанализированы (рис. 16.28, файл 16.mрр).

Рис. 16.28. Выбор полей для анализа
Чтобы выбрать поле для анализа, нужно выделить его курсором в списке полей (слева) и нажать кнопку Add» (Добавить»). Удаление поля из списка анализируемых осуществляется с помощью кнопки «Remove («Удалить). В нашем примере для анализа выбрано поле Work (Трудозатраты).
Выбрав поля для анализа, нужно определить временной диапазон, в рамках которого будет осуществляться анализ. Этот диапазон определяется на третьем шаге мастера, и по умолчанию поля From (С) и То (По) заполнены датами начала и окончания проекта (рис. 16.29, файл 16.mрр). Под полями для выбора границ временного диапазона в раскрывающемся списке Units (Единицы) выбираются единицы измерения времени, используемые при анализе. Можно выбрать любую из единиц измерения шкалы времени MS Project (см. раздел «Форматирование шкалы времени» ).

Рис. 16.29. Определяем диапазон дат и единицы измерения времени
На следующем шаге мастера нужно определить, будет ли в Excel строиться график по выбранным данным, и на последнем шаге — нажать кнопку Export Data (Экспорт данных), чтобы процесс импорта начался. После этого в Excel будет создан файл, в котором на одном листе будут помещены данные, аналогично тому, как они представлены на диаграмме использования задач или ресурсов, а на втором листе будет создан график по этим данным.
Например, на рис. 16.30 представлен график распределения трудозатрат по проекту в файле 1б.mрр(график находится в файле wrk.xls) (Чтобы получить график, отображенный на рисунке, мы изменили формат диаграммы, которую MS Project создает u Excel автоматически, с объемной на обычную.). Как мы видим, в середине проекта есть провал (в это время статьи находятся в работе у авторов), а ближе к завершению проекта еще один спад среди двух пиков. Кроме того, распределение трудозатрат в нашем плане отличается от классического тем, что в конце проекта наблюдается небольшое возрастание объема, тогда как правильным считается последовательное уменьшение объема работ к концу проекта.

Рис. 16.30. График распределения трудозатрат по проекту
Чем меньше выбранные единицы измерения, тем более неровным будет график распределения трудозатрат во время исполнения проекта. Иногда это полезно, а иногда не нужно. Например, для анализа распределения трудозатрат пи длительности всего проекта в качестве единицы измерения стоит выбрать педелю или месяц, и тогда график примет необходимую «обтекаемость» (понедельные и помесячные графики распределения работ по проекту хранятся в файлах wrk2.xls и wrk3.xls). А для сравнения загрузки ресурсов наиболее подходящим может оказаться именно ежедневный график.
На рис. 16.31 представлен другой пример анализа плана проекта. Мы выбрали три ресурса — Иванов, Петров и Сидоров — и проанализировали их загрузку (поле Percent Allocation (Процент загрузки)), чтобы выяснить, возможна ли замена одного из них другим, если кто-то заболеет. Как видно на рисунке, графики загрузки этих ресурсов почти полностью совпадают, лишь в конце проекта Сидоров загружен немного больше других (файл exc.xls1). Так что'взаимные замены вряд ли будут возможны.

Рис. 16.31. Анализируем загрузку ресурсов в Excel
Анализ загрузки ресурсов в Excel помогает определить, насколько равномерно она распределена. Такой анализ можно провести и в MS Project в представлении Resource Graph (График ресурсов), но в нем не так удобно сравнивать загрузку, просматривая ее для нескольких ресурсов сразу, потому что у графика нет объемного вида. В нашем примере видно, что почти весь февраль ресурсы простаивают, и их можно занять дополнительной работой в этом или другом проекте.
Чтобы получить график, отображенный на рисунке, мы изменили файл, полученный в результате автоматического экспорта данных в Excel. При автоматическом экспорте па графике отображаются суммарные данные о проценте загрузки для всех выбранных ресурсов. Мы удалили ее с графика и добавили на него отдельные ряды с данными каждого из ресурсов.