Слишком длинные задачи и задачи с большим числом ресурсов.

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

Анализ опасностей, которые могут возникнуть при выполнении составленного плана, — один из самых интересных и сложных этапов планирования проекта. От того, как проведен анализ, зависит, будет ли проект успешно завершен. В этом уроке вы научитесь определять риски с помощью MS Project, описывать их и разрабатывать стратегии их смягчения. Для проведения анализа мы задействуем все имеющиеся в нашем арсенале средства: настраиваемые поля, формулы, стандартные и настраиваемые фильтры, сортировки. Анализ рисков состоит из нескольких этапов. Сначала нужно определить возможные риски. Затем для каждого из них нужно определить стратегию смягчения влияния риска на проект, то есть действия, предпринимаемые для предотвращения риска или в случае осуществления риска для того, чтобы проект был успешно завершен.

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

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

При определении рисков информацию нужно заносить в план проекта. Для этого нужно:

· Переиминовать поле «Текст2» в «Описание риска

· «Текст3» в «Вероятность осуществления риска», причем для последнего мы создали список значений: «Высокая», «Средняя» и «Низкая»

· На основании таблицы «Ввод» для задач мы создали таблицу «Ввод» информации о рисках и оставили в ней лишь необходимый набор полей.

· И, наконец, на базе таблицы мы создали два представления: «Риски», в котором эта таблица находится рядом с диаграммой Ганта Рис

Рис. Представление Риски

· И комбинированное представление «Риски2», в верхней части которого находится представление «Риски», а в нижней – «Форма задач». Теперь можно переходить к определению рисков.

Рис Представление Риски 2

Риски определяются для трех аспектов проекта: «Расписания», «Ресурсов» и «Бюджета». Так выявляются события, осуществление которых может помешать завершить проект в срок или создать нехватку ресурсов или денег в определенный момент его выполнения. Если при определении риска становится ясно, как уменьшить его, то нужно сразу же вносить соответствующие изменения в план проекта.

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

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

Задачи с предварительными длительностями.

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

Слишком короткие задачи.

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

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

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

1. В меню «Проект» выберите команду «Фильтр», а затем щелкните «Другие фильтры»;

2. Щелкните «Создать» и введите имя «Слишком короткие задачи»;

3. В столбце «И/Или» установите «Или» для поля «Длительность1»;

4. В столбце «Имя поля» выберете «Длительность» и «Длительность1»;

5. В столбце «Проверка» для поля «Длительность» установите «Меньше или равно», для поля «Длительность1» установите равно «Равно»;

6. В столбце «Значения» для поля «Длительность» установите «1д», для поля «Длительность1» установите «[Длительность2]»;

7. Аналогичным способом создайте условие для вех, в столбце «И/Или» установите «И», в столбце «Имя поля» выберете «Веха», столбце «Проверка» установите «Равно», в столбце «Значения» установите «Нет»;

8. Нажмите кнопку «Оk», а затем кнопку «Применить».

Фильтр отбирает задачи, у которых длительность меньше либо равна одному дню или значение настраиваемого поля «Длительность» равно значению настраиваемого поля «Длительность2» (эти настраиваемые поля используются при анализе по методу PERT для хранения информации об оптимистической и ожидаемой длительности). Среди задач, отобранных по одному из этих критериев, фильтр отбирает те задачи, у которых значение поля «Веха» равно «Нет», то есть задачи, не являющиеся вехами. В нашем случае коротких задач оказалось 8 («Определение проекта», «Определение тематики и организации контента», «Разработка шаблонов (дизайна)№1», «Разработка шаблонов (дизайна)№2», «Разработка графического контента (кнопки, логотипы)», «Тест функционала», «Внешнее тестирование», «Регистрация в поисковых системах»). После того как короткие задачи отобраны, определим реалистичность отведенного на них времени. Если мы обнаруживаем в плане задачи, имеющие неоправданно короткие сроки, то длительность таких задач нужно дополнительно обсудить с будущими исполнителями. При этом желательно запросить у них все три возможных срока исполнения задачи, чтобы внести их в таблицу для анализа PERT и рассчитать длительность задачи.

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

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

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

В результате осуществления рисков возможно увеличение объема работы по проекту, что приведет к росту затрат на него. Риск увеличения бюджета проекта стоит рассматривать тогда, когда проект имеет ограниченные бюджетные рамки. Например, в нашем проекте задействованы в основном штатные сотрудники организации, регулярно получающие зарплату, и бюджет проекта не имеет большого значения. Бывают и другие случаи: например, проект может выполняться на заказ, и заказчик может выделять на выполнение работ определенную сумму, которую нельзя превысить. В тех случаях, когда затраты на проект ограничены, важно предусмотреть риск увеличения бюджета в результате тех или иных обстоятельств. Для оценки возможного увеличения бюджета можно применять различные методики. Мы продемонстрируем здесь оценку возможного изменения стоимости проекта на основании данных, полученных в ходе анализа PERT. Наш анализ исходит из предположения, что при увеличении длительности задачи объем работ всех назначенных ресурсов и, соответственно, цена возрастают пропорционально. Например, если задача длится 2 дня и стоит $100, то при увеличении длительности до 4 дней стоимость возрастет до $200. Этот метод оценки не очень точен, но он и не претендует на точность. Ведь при планировании рисков сложно предсказать, как именно будут задействованы ресурсы при увеличении длительности назначения. Задача анализа - определить возможный бюджет проекта при неблагоприятном развитии событий и задачи, цена которых сильно увеличится при осуществлении рисков.

Переименуем таблицу «Ввод PERT» в «Бюджетные риски». Затем на основе фильтра «Вехи» создадим фильтр «Не вехи», изменив условие в исходном фильтре на противоположное. После его применения на плане не будут отображаться задачи с нулевой длительностью.

При анализе PERT программа автоматически помещает значения оптимистической, ожидаемой и пессимистической длительности в поля «Длительность1-3». Если разделить длительность каждого из типов на длительность, внесенную в план проекта (поле «Длительность»), то в результате мы получим коэффициент, который можно использовать для расчета стоимости. Например, если длительность задачи в плане составляет 2 дня, а пессимистическая длительность составляет 4 дня, то коэффициент будет равняться 2. Соответственно, пессимистическая стоимость задачи будет равняться стоимости, умноженной на этот коэффициент, и в случае неблагоприятного развития событий будет в два раза больше запланированной. Настроим три поля типа «Затраты» для расчета стоимости каждого из типов по этой формуле «[Длительность1(2, 3)]/[Длительность]*[Затраты]»Рис.. Если затраты на проект не были введены вами ранее – необходимо сделать это сейчас.

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

Видно, что в случае неблагоприятного развития событий стоимость проекта может увеличиться более чем на $15 000 (вычитаем из пессимистической стоимости планируемую стоимость), что составляет лишь 15, 5% от общей стоимости проекта. Но у отдельных задач или фаз отклонение цены может быть значительным, и нужно проанализировать план, чтобы понять, у каких задач в случае осуществления риска стоимость может существенно измениться. Для этого рассчитаем для каждой задачи процент отклонения пессимистической стоимости от запланированной. Переименуем поле «Число3» в «Разница стоимости» и введем в него формулу «(([Затраты5]-[Затраты])/[Затраты]*100)». Сначала определяется разница между пессимистической ценой и запланированной, для чего из поля «Затраты5», где хранится пессимистическая стоимость, рассчитанная в предыдущем примере, вычитается планируемая стоимость, хранящаяся в поле «Затраты». Затем мы определяем, какой процент от запланированной стоимости составляет полученная разность. Для этого полученное в результате вычитания число делится на запланированную стоимость и результат умножается на 100. Чтобы полученный результат было легче обрабатывать, настроим отображение индикаторов для поля. Те задачи, у которых отклонение при неблагоприятном развитии событий составит более 50%, пометим красным индикатором. Задачи с отклонением больше 25% пометим желтым, а с отклонением больше или равным 10% - зеленым. Задачи с отклонением менее 10% пометим флажком. Установим флажок «Показывать значения данных во всплывающих подсказках», и тогда значение поля будет отображаться при наведении курсора на индикатор. Определение количественных характеристик отклонений (чтобы решить, какое отклонение считать слишком высоким, а какое приемлемым) зависит от принятых в организации стандартов. В нашем случае будем считать отклонение менее 10% приемлемым, а более 50% — слишком высоким и нуждающимся в коррекции. Задачи плана, помеченные красным индикатором, нуждаются в коррекции: нужно или уменьшить пессимистическую оценку стоимости для них, или увеличить планируемую стоимость. Определение количественных характеристик отклонений (чтобы решить, какое отклонение считать слишком высоким, а какое приемлемым) зависит от принятых в организации стандартов. В нашем случае будем считать отклонение менее 10% приемлемым, а более 50% — слишком высоким и нуждающимся в коррекции. Задачи плана, помеченные красным индикатором, нуждаются в коррекции: нужно или уменьшить пессимистическую оценку стоимости для них, или увеличить планируемую стоимость. После завершения коррекции нужно определить пессимистическую стоимость проекта, согласовать ее с руководством и учитывать при планировании финансирования проекта. Если события будут развиваться по неблагоприятному сценарию, организация должна быть готова к выплате необходимого проекту бюджета. Пессимистическая стоимость проекта указана в строке суммарной задачи проекта.

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

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

План реакции на риски хранится в плане проекта в виде текстовой информации, связанной с определенными задачами или ресурсами. Для хранения информации о реакции на ресурсные риски настроим ресурсное поле «Текст4», переименовав его в «План реакции на риски». Даже после того, как план проекта проанализирован, многие риски выявлены и разработана стратегия смягчения их влияния на проект, все равно сохраняется вероятность, что в ходе выполнения проекта может произойти нечто непредвиденное. Иными словами, вполне возможно, что какие-то риски не были выявлены либо их существование нельзя предположить на нынешнем этапе планирования проекта. Поэтому в план нужно заложить временной и финансовый буфер, позволяющий отреагировать на возникающие риски и снизить вероятность увеличения длительности проекта. Финансовый буфер можно создать простым увеличением стоимости проекта на коэффициент, который принято использовать в вашей организации в таких случаях. Например, если бюджет проекта составляет $100 000, а пессимистический бюджет — $120 000, то с учетом буфера бюджет проекта может равняться $130 000.

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

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

При определении рисков информацию нужно заносить в план проекта. Для этого нужно:

· Переиминовать поле «Текст2» в «Описание риска

Рис. Представление Риски

Рис Представление Риски 2

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

Задачи с предварительными длительностями.

Слишком короткие задачи.

1. В меню «Проект» выберите команду «Фильтр», а затем щелкните «Другие фильтры»;

2. Щелкните «Создать» и введите имя «Слишком короткие задачи»;

3. В столбце «И/Или» установите «Или» для поля «Длительность1»;

4. В столбце «Имя поля» выберете «Длительность» и «Длительность1»;

8. Нажмите кнопку «Оk», а затем кнопку «Применить».

Слишком длинные задачи и задачи с большим числом ресурсов.

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

Обнаружить в плане задачи с большой длительностью очень просто. Достаточно воспользоваться автофильтром и отфильтровать задачи по столбцу «Длительность», отобрав задачи с длительностью, превышающей, например, 5 пли 10.

Оптимистическая длительность может совпадать с ожидаемой не точно, а с определенным допущением, например, различаться на 1 или 2 часа. Чтобы такие задачи тоже можно было обнаружить, в этом же файле мы создали фильтр «Слишком короткие задачи - 2», в котором можно внести это допущение.

А вот автоматически отобрать задачи с большим числом ресурсов нельзя, поскольку в MS Project нет специального столбца «внутренней» таблицы, в котором было бы указано число ресурсов, назначенных на задачу. Поэтому нам, как обычно, придется воспользоваться настраиваемым полем. Переименуем поле задач «Число2» в «Число ресурсов» и поместим в него формулу «(Len ([Названия ресурсов]))». Функция Len определяет длину текстовой строки, переданной ей в качестве параметра. В нашем случае этой строкой является значение поля «Названия ресурсов». Чем больше ресурсов назначено на задачу, тем длиннее строка и тем больше будет значение поля Число ресурсов.

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

После завершения настройки поля отсортируем задачи по этому полю. Для этого с помощью команды меню «Проект > Сортировка > Сортировать по» откроем диалоговое окно сортировки и выберем созданное поле в качестве критерия. Сортировать задачи будем по убыванию, чтобы задачи с наибольшим числом ресурсов оказались в верхней части списка, и сбросим флажок «Сохранить структуру», чтобы сортировка осуществлялась в рамках всего проекта, а не в рамках отдельных фаз.Рис.

Рис. Сортировка по ресурсам

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

Список всех предшественниц задачи приведен в поле «Предшественники», причем номера задач-предшественниц разделены точками. И если в этом поле встречается хотя бы одна точка с запятой, значит, у задачи есть как минимум две предшественницы. Поэтому наш фильтр будет отбирать те задачи, у которых в поле «Предшественники» содержится точка с запятой.

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

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

12 Следующая ⇒