Самоучитель по Microsoft Project - часть 27

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

случае.

Рис. 15.20. Редактируем формулу, чтобы определить, сколько процентов 

составляют сверхурочные затраты от общих затрат

Обновив формулу, посмотрим на данные в таблице. На рис. 15.21 (файл 15.

mpp) видно, что доля сверхурочных трудозатрат составляет 2,08% от затрат на 

задачу, где требуются сверхурочные, и 0,22% от затрат на фазу, включающую 

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

значение поля % от общей стоимости в строке суммарной задачи равно нулю.

Рис. 15.21. Анализ распределения затрат между обычными работами и 

сверхурочными

Распределение затрат на ресурсы разных типов

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

теми же приемами, что и при анализе распределения ресурсов по типам задач. 

Для группировки ресурсов нам понадобится настраиваемый ресурсный код 

структуры Код отдела, уже созданный ранее в файле СН13\19.mрр (см. раздел

 

«Ввод значений настраиваемого кода структуры и его 
использование»

). С помощью Организатора перенесем его в наш файл 16.

mрр, добавим его в список отображаемых в таблице и заполним данными (рис. 

15.22).

Рис. 15.22. Заполняем данными настраиваемый код структуры для ресурсов

Когда коды отделов у ресурсов расставлены, нужно создать поле для хранения 

информации об общей стоимости проекта и для расчета процента стоимости 

ресурса от общей стоимости. Все эти настройки аналогичны тем, что мы делали 

для расчета соотношения затрат на различные фазы проекта (см. раздел 

«Распределение затрат по фазам проекта»), но теперь мы будем использовать 

настраиваемые поля ресурсов, а не задач.

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

данные по полю Код отдела. Теперь (рис. 15.23, файл 17.mрр) напротив 

названия каждой из групп ресурсов указаны суммарные затраты на ресурсы 

этой группы (в колонке Cost (Затраты)) и доля этих затрат от общей стоимости 

проекта (в колонке % от общей стоимости). В группе No Value (Нет значения) 

перечислены ресурсы, у которых нет значения в колонке Код отдела — 

материальные ресурсы.

Рис. 15.23. Анализ затрат по типам ресурсов

При работе с полями в Организаторе не забудьте о переключении между 

настраиваемыми полями ресурсов и задач. В этом примере нам нужно 

настраиваемое поле для ресурсов.

Но анализ показывает, что затраты на внештатных сотрудников включают 

затраты на фотомодель, но не учитывают затраты на авторов (на написание 

статей). Это произошло потому, что на задачу Статьи поступили в редакцию, 

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

стоимость статей была занесена в план как фиксированная стоимость этой 

задачи. Соответственно, эти затраты не отнесены ни к одному из ресурсов 

проекта.

Чтобы исправить эту ситуацию, добавим ресурс Авторы и в поле Cost Per Use 

(Затраты на использование) укажем $1000, то есть стоимость всех статей 

номера. Затем удалим фиксированную стоимость у задачи Статьи поступили в 

редакцию и выделим на нее созданный ресурс. Стоимость назначения будет 

определена в $1000, и соответственно, стоимость задачи снова будет такой же, 

как и при использовании фиксированной стоимости. Теперь определим для 

ресурса Авторы значение поля Код отдела, введем стоимость проекта в поле 

Общая стоимость и посмотрим, как изменились данные в нашей таблице (рис. 

15.24, файл 16.mpp). В список внештатных сотрудников добавились Авторы и 

затраты на них, а общие затраты на внештатных сотрудников возросли с 0,11% 

до 0,65%, то есть почти в 5 раз.

Рис. 15.24. Анализ затрат проекта с учетом затрат на авторов

Кроме того, на рис. 15.24 видно, что группировка позволяет просматривать 

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

отделов. Это дает возможности для более точного анализа и корректной 

оптимизации стоимости.

Мы рассмотрели несколько способов анализа стоимости проекта. Возможно, в 

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

вы знаете общие принципы определения соотношения затрат между задачами 

или ресурсами, сгруппированными по тем или иным признакам.

Оптимизация стоимости проекта

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

оптимизации плана. Если общая стоимость проекта и распределение затрат 

соответствуют ожиданиям, то оптимизация может не потребоваться, но так 

случается нечасто. Как правило, приходится оптимизировать план: сокращать 

или увеличивать затраты на задачи или ресурсы определенного типа. Иногда 

приходится выполнять одновременно обе операции, например, сохраняя 

общую стоимость проекта, уменьшить затраты на программирование и 

увеличить затраты на тестирование. Рассмотрим приемы уменьшений и 

увеличения затрат на проект или его составляющие.

Уменьшение затрат

Затраты определяются ставками ресурсов, трудозатратами и фиксированными 

затратами на задачи. Поэтому уменьшить затраты можно, уменьшив один или 

несколько определяющих факторов.

Для выполнения работ, которые необходимо удешевить, можно привлечь 

более дешевые ресурсы или использовать таблицы норм затрат с более 

низкими ставками у назначенных ресурсов. Первый вариант опасен 

снижением качества проекта, поскольку более дешевые ресурсы часто имеют 

более низкую квалификацию. 

Кроме того, это может привести к увеличению сроков исполнения задач. 

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

использования зависит от условий предоставления ресурсов для проектных 

работ. Также можно попробовать отказаться от использования некоторых 

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

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

длительности задач или снижению качества.

При сокращении трудозатрат нужно определить, какие работы имеют 

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

результатов. Эти работы и нужно удалить из плана проекта. Как правило, 

сокращение трудозатрат приводит к снижению качества проекта, но, если 

сокращаемые задачи лежат на критическом пути, может привести и к 

сокращению сроков выполнения проекта.

В проектах обычно не так много задач с фиксированными затратами. Если же 

они есть, то можно попробовать найти способы сокращения этих затрат, хотя, 

так как эти затраты относятся к внепроектной деятельности, это не всегда 

получается. Сокращение этих затрат в некоторых ситуациях может повлиять 

на качество проекта.

Увеличение затрат

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

можно использовать, то увеличить затраты можно за счет увеличения объема 

работ, увеличения числа используемых ресурсов или их стоимости. 

Добавив работы, можно улучшить качество проектных результатов, 

например, осуществив их дополнительный контроль. Использовав 

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

больший объем работы. Наконец, если привлечь к исполнению работ 

специалистов более высокого уровня с более высокими ставками, можно 

улучшить качество и уменьшить длительность выполнения работы.

Что нового вы узнали?

●     

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

метода.

●     

Как уточнять длительность задач с использованием метода PERT.

●     

Как оптимизировать план работ проекта.

●     

Как использовать метод критического пути при анадизе плана работ.

●     

Как анализировать распределение затрат по фазам проекта, типам 

работ, типам трудозатрат и типам ресурсов.

●     

Как уменьшать или увеличивать затраты на проект.

Глава 15. Анализ рисков

●     

Анализ рисков

●     

Определение рисков

 

❍

     

Риски в расписании

❍

     

Ресурсные риски

❍

     

Бюджетные риски

●     

Разработка стратегии смягчения рисков 

❍

     

План сдерживания рисков

❍

     

План реакции на риски

❍

     

Формирование временного буфера

❍

     

Анализ распределения трудозатрат

●     

Что нового вы узнали?

Анализ рисков 

Анализ опасностей, которые могут возникнуть при выполнении составленного 

плана, — один из самых интересных и сложных этапов планирования 

проекта. От того, как проведен анализ, зависит, будет ли проект успешно 

завершен. В этом уроке вы научитесь определять риски с помощью 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. Сортируем задачи по созданному полю