Название: Профессиональное управление проектом - Хелдман К.

Жанр: Менеджмент

Рейтинг:

Просмотров: 7100


Составление плана проекта

 

В качестве доминирующих тем данной главы выступают:

y 6. Составление плана проекта

v 7. Результаты разработки плана проекта

 

Г^руппа процессов планирования включает в себя больше процес­сов, чем любая другая группа, представленная в учебнике РМВОК, поэтому на процесс планирования в проекте тратится больше всего времени и сил. В будущих проектах вы будете уделять больше време­ни планированию проекта, чем его выполнению и контролю. Но это не так плохо. Чем лучше вы выполнили планирование, тем успешнее будет ваш проект. Вопросы, связанные с планированием, выполнени­ем и контролем проекта, составляют примерно 70 процентов вопро­сов экзамена, поэтому уделите больше времени изучению этих сфер.

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

 

работка графика проекта

Процесс разработки графика проекта — это центральная часть группы процессов планирования. Здесь вы составляете график ва­ших проектных заданий, определяете сроки их начала и завершения, устанавливаете последовательность операций и их продолжитель­ность. Этот процесс наряду с оценкой продолжительности операций и оценкой стоимости должен повторяться несколько раз, прежде чем вы сможете составить график проекта. Далее в этом разделе мы пого­ворим об использовании программного обеспечения для управления проектом в этом процессе. На самом деле это один из методов и прие­мов этого процесса.

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

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

 

Компоненты графика

Процесс составления графика состоит из 10 компонентов, 7 из которых являются выходами из рассмотренных ранее процессов планирования. Как уже говорилось ранее, вы можете сами оценить, насколько важно выполнить процессы планирования аккуратно, так как информация, которую вы получаете почти в каждом процессе, используется где-то еще в планировании или в дальнейших группах процессов. График ва­шего проекта должен учитывать ту информацию, которая у вас есть на данный момент. Если вы неправильно определили продолжительность операций или, например, не рассмотрели их зависимость друг от друга, то график вашего проекта будет неверным. Вам придется потратить лишнее время на проверку плана вашего проекта и очень аккуратно рассмотреть все результаты каждого процесса планирования.

Новыми для вас являются три элемента: календари, опережения и задержки и признаки операций. Далее следует краткое описание каждого из этих элементов.

 

Календари

Здесь можно выделить два вида календарей: календарь проекта и ка­лендарь ресурсов. Календарь проекта включает в себя все ресурсы, ис­пользуемые в проекте, а календарь ресурсов рассматривает каждый ресурс в отдельности или группы ресурсов и их наличие.

 

Опережения и задержки

Этот элемент соотносится с последовательностью операций. Запом­ните, что последовательность операций распределяет задания в логи­ческом порядке и определяет, существуют ли между операциями раз­личного рода зависимости. Затем мы берем эти задания и составляем сетевой график. (Мы обсуждали это в 5 главе, если вам нужно вспом­нить.) Опережения и задержки имеют место, если между зависимы­ми и независимыми операциями возникают сдвиги во времени. За­держки требуют добавления дополнительного времени к дате начала или дате завершения зависимой операции. Опережения, наоборот, требуют вычитания времени от даты начала или завершения зависи­мой операции. Время опережения используется не так часто, как время задержки.

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

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

 

Признаки операций

Признаки операций представляют собой характеристики операций. Это может быть описание места, где выполняется операция, кто ее вы­полняет, является ли операция частью уровня операций в СОР или это детальная операция со своими особенностями.

 

Понимание методов и приемов разработки графика

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

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

 

Математический анализ

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

Метод критического пути

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

Резервное время называют также временем отсрочки, причем эти термины взаимозаменяемы. Здесь можно выделить два основных вида: полная отсрочка и свободная отсрочка. Полная отсрочка — это промежуток времени, на который вы можете отложить начало за­дания, не нарушая сроков выполнения проекта. Свободная отсроч­ка — это промежуток времени, на который вы можете отложить на­чало задания, не нарушая срок начала последующей операции.

На основе образца проекта мы рассчитаем КП и покажем, как определяются все даты, КП и время отсрочки.

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

Мы начнем наш пример с занесения информации в таблицу 7.1 (смотри ниже), учитывая процессы, которые мы уже завершили. Список операций мы берем из СОР, этот список был составлен в про­цессе определения операций. Продолжительность каждой операции, указанной в соответствующей колонке, была установлена в процессе оценки продолжительности операций. Продолжительность указана в днях. Колонка зависимости операций учитывает, что одна операция должна быть завершена, прежде чем начнется связанная с ней дру­гая операция. Мы используем только отношение завершение-начало. Например, вы видите, что операция 2 и операция 4 зависят от опера­ции 1, которая должна быть завершена прежде, чем они начнутся. Информацию о зависимости мы берем из процесса последовательно­сти операций. А теперь приступим к расчету сроков.

Первая операция связана с поставками проекта, и очевидно, где проект начинается. Операция начинается 1 апреля. Поставки длятся 12 дней. Берем 1 апреля и прибавляем 12 дней, чтобы получить ран­ние сроки завершения. 1 апреля мы считаем при этом полным рабо­чим днем. Таким образом, ранним сроком завершения этой операции будет 12 апреля. Кстати, мы игнорируем выходные и праздники в этом примере. Операция 2 зависит от операции 1, и не может начать­ся, пока не будет завершена операция 1. Ее ранним стартом будет 13 апреля. Добавьте продолжительность к этой дате минус 1, чтобы по­лучить срок завершения.

Обратите внимание, что операция 4 тоже зависит от операции 1, поэтому ее ранним стартом также считается 13 апреля. Продолжайте так же рассчитывать сроки начала и завершения операций. Этот рас­чет называется проход вперед.

Чтобы рассчитать поздние сроки начала и завершения, мы начинаем с последней операции. Поздним сроком для операции 9 является 10 июля. Ее продолжительность составляет только один день, поэтому поздним сроком начала будет также 10 июля. Вы знаете, что операция 8 должна быть завершена до начала операции 9, поэтому поздним за­вершением операции 8 является 9 июля, за день до начала 9 опера­ции — 10 июля. Продолжительность 8 операции составляет 3 дня, от­нимите их от даты завершения и добавьте 1, поздний срок начала этой операции будет 7 июля. Мы выполняем противоположные расчеты. Этот расчет называется проход назад, как вы уже могли догадаться. Продолжайте расчеты позднего старта и завершения до операции 4.

На операции 3 мы работаем по-другому. Операция 7 не может на­чаться до завершения операций 3 и 6. Другие операции не зависят от выполнения операции 3. Если поздним стартом операции 7 является 29 июня, поздним завершением операции 3 должно быть 28 июня. 28 июня минус 8 дней плюс один дает нам позднюю дату старта 21 июня. Операция 3 зависит от операции 2, которая должна быть за­вершена до начала операции 3. Рассчитайте эти даты так же, как с операциями с 9 по 4.

Осталась операция 1. Операция 4 не может начаться до заверше­ния операции 1. Поздним стартом 4 операции является 13 апреля, поздним завершением операции 1 должно быть 12 апреля. Вычтем отсюда продолжительность операции 1 и добавим 1, и поздним стар­том операции 1 станет 1 апреля.

Проход вперед и назад рассчитываются, учитывая старт первого задания, затем добавляя к нему продолжительность операции. В при­мере ранним стартом операции 1 является 1 апреля, что считается точкой отсчета или нулем. Добавьте 12 дней, и вы получите ранний срок завершения — 12 апреля.

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

Чтобы определить КП продолжительности проекта, сложите про­должительность операций, время отсрочки которых равно нулю. У вас должен получиться 101 день, так как мы складываем продолжи­тельность всех операций кроме 2 и 3. Критическим заданием счита­ется каждое задание, которое не может быть изменено, не влияя на дату завершения проекта. По определению все эти задания имеют ну­левую отсрочку.

Другим способом определения критического пути является состав­ление сетевого графика. Если есть информация о продолжительности или даны дата начала и завершения, вы легко рассчитаете продолжи­тельность и затем добавите самый длинный путь в диаграмму, чтобы определить КП. Этот метод не столь точный как в таблице 7.1. На

Действие М2 2

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

техническое обеспечение

 

Действие № 3

проверка техниче­ского обеспечение

Действие № 1

Действие № 7?

12

поставки

Действие № 4

10

программное обеспечение

Рис, 7.1. Диаграмма критического пути

 

Запомните, что критический путь — это путь с наибольшей про­должительностью. В диаграмме путь 1-2-3-7-8-9 составляет 34 дня. Путь 1-4-5-6-7-8-9 составляет 101 день; этот путь и является крити­ческим.

Метод графической оценки и анализа

Единственное, что вам необходимо знать относительно этого мето­да для экзамена, это то, что МГОА допускает наличие ветвлений по условию и циклов и вероятностную трактовку. На практике МГОА во многом похож на ТОАП за исключением того, что МГОА позволяет выделять в процессе циклы или образовывать ветвления, чтобы по­казать альтернативы. Например, наш проект по разработке програм­много обеспечения в примере с МКП может потребовать исследова­ния отдельных модулей до проверки программы, при этом каждый модуль должен пройти собственную проверку. Если проверка закон­чилась неудачно, МГОА позволяет вам изобразить цикл по условию, чтобы вы могли вернуться к проверке, а затем перейти к новой опе­рации, когда проверка модуля завершена.

Технология оценки и анализа проектов

Технология оценки и анализа проектов (ТОАП) была разработана военно-морским флотом США в 1950 году. Тогда работа велась над самым сложным для того времени техническим проектом (ракетной системой Поларис), и необходимо было разработать график проекта и управлять им с высоким уровнем надежности. Именно для этого и был разработан ТОАП.

Методы ТОАП и МКП во многом похожи. Различие состоит в том, что МКП использует наиболее вероятную продолжительность для определения продолжительности проекта, в то время как ТОАП использует то, что называется ожидаемым значением (или средним взвешенным) для определения продолжительности проекта. Ожидае­мое значение рассчитывается с использованием трех оценок времени для определения продолжительности вместо одной и затем находит взвешенное среднее на основе этих трех оценок. Если мы продолжим эту ступень далее и определим стандартное отклонение каждой опе­рации, мы можем обнаружить доверительный фактор для оценок на­шего проекта. Не углубляясь в математические расчеты, запомните, что для даты, которую мы рассчитываем с помощью ТОАП, харак­терно следующее:

Работа будет завершена в интервале плюс-минус три стандарт­ных отклонения от ожидаемого времени с вероятностью 99.73\% .

Работа будет завершена в интервале плюс-минус два стандарт­ных отклонения от ожидаемого времени с вероятностью 95.44\%).

Работа будет завершена в интервале плюс-минус одно стандарт­ное отклонение от ожидаемого времени с вероятностью 68.26\%.

К оценкам трех сроков, используемым для расчета ожидаемого значения, относятся оптимистическая оценка, пессимистическая оценка и наиболее вероятная оценка. Возвращаясь к нашему при­меру с программным обеспечением, давайте определим, как будут выглядеть эти три оценки для операции, которая называется «На­писание программ». Вы получаете эти оценки путем опроса веду­щих программистов или главных членов команды, чтобы оценить оптимистическую, пессимистическую и наиболее вероятную про­должительность операции, исходя из их прошлого опыта. Для определения этих оценок может быть использована и другая исто­рическая информация. Скажем, в этом случае у нас оптимистиче­ская оценка составляет 38 дней, пессимистическая 57 и наиболее вероятная 45 дней. (Учтите, что 45 дней ■— это то, что мы ис­пользовали для расчета МКП и что мы имеем благодаря процессу оценки продолжительности операций.)

Формула для расчета ожидаемого значения выглядит следующим образом:

 

[оптимистическая -пессимистическая +(4 х наиболее вероятная)] -:- 6.

Ожидаемое значение для операции «Написание программ» выгля­дит таким образом:

[38 + 57 + (4 х 45)] * 6 = 45.83.

Формула для стандартного отклонения, которая помогает нам опре­делить уровень доверительности, выглядит так:

(пессимистическая - оптимистическая) н- 6. Стандартное отклонение для нашей операции выглядит так:

(57 - 38) + 6 = 3.17.

Используя данную информацию, мы можем сказать:

в Вероятность, что операция «Написание программ» будет за­вершена между 42.66 и 49 днями, составляет 68.26\%.

• Вероятность, что операция «Написание программ» будет за­вершена между 39.49 и 52.17 днями, составляет 95.44\%.

Мы рассчитали интервал дат для вероятности 68.26\% путем до­бавления и вычитания одного стандартного отклонения, т. е. 3.17, к ожидаемому значению 45.83. Вероятность 95.44\%> была получена ум­ножением стандартного отклонения на 2 и добавлением и вычитани­ем 6.34 к ожидаемому значению, что дает наименьшее и наибольшее количество дней, необходимых для завершения операции. Вообще говоря, два стандартных отклонения и соответствующая им вероят­ность события 95.44\% вполне достаточны для большинства целей.

Чем выше стандартное отклонение для операции, тем выше риск. Большая цифра стандартного отклонения, измеряемого как разница между оптимистическим и пессимистическим временем, показывает большую величину риска. И наоборот, низкое стандартное отклоне­ние говорит о незначительном риске.

Давайте вернемся к нашей таблице операций и рассмотрим для каждой операции ожидаемое значение и стандартное отклонение (см. табл. 7.2).

 

Теперь мы рассмотрим общую продолжительность проекта, испо­льзуя ТОАП и стандартное отклонение, чтобы определить интервал сроков для продолжительности проекта. Вы должны учитывать толь­ко те задания, которые относятся к критическому пути. Из метода КП вы помните, что задания 2 и 3 не относятся к критическому пути, поэтому для них мы не определяли ожидаемое значение и стан­дартное отклонение в таблице. Теперь мы сложим все оставшиеся числа, и общее ожидаемое значение продолжительности составит 102.99 или 103 дня от начала проекта.

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

Возможно, справа вы заметили дополнительную колонку под заго­ловком «Квадрат стандартного отклонения». Для испытывающих страх перед математикой поясним — это просто стандартное отклоне­ние, умноженное само на себя.

После того как вы рассчитали квадрат стандартного отклонения для каждой операции, сложите эти числа, что составит 14.98. Еще один шаг, и мы все выполним. Вычислите корень из 14.98 (для этого вам понадобится калькулятор), и вы получите 3.87. Это стандартное отклонение, которое вы можете использовать для того, чтобы опреде­лить интервал планируемых сроков завершения проекта, а теперь подытожим последние несколько расчетов:

Общее ожидаемое значение = 103.00.

Сумма квадратов стандартных отклонений = 14.98.

Квадратный корень из этой суммы = 3.87.

Л теперь мы можем сделать некоторые прогнозы относительно на­шего проекта:

Шансы, что проект будет завершен в период от 99.13 до 106.87 дней, составляют 68.26\%.

Шансы, что проект будет завершен в период от 95.26 до 110.74 дней, составляют 95.44\%.

ТОАП используется в основном для больших и сложных проектов. Этот метод применяется также для определения продолжительности проекта, если неизвестна продолжительность операций. Для экзаме­на я рекомендую вам запомнить, что одно стандартное отклонение дает вам 95\% (округленно) вероятности, а два стандартных отклоне­ния дают вам 68\% (округленно) вероятности. Вы также должны знать, как рассчитать продолжительность проекта, основываясь на расчетах ожидаемого значения и стандартного отклонения. Вам не нужно запоминать, как рассчитать стандартное отклонение, посколь­ку я полагаю, что в большинстве вопросов эта информация вам будет предоставлена. Однако вы должны знать формулу ТОАП и то, как она работает. Вам не помешает запомнить формулу стандартного от­клонения, так как кто знает, что будет на экзамене.

 

Сжатие продолжительности

Согласно учебнику РМВОК сжатие продолжительности может прохо­дить в двух формах — сокращение времени путем выделения допол­нительных ресурсов и быстрое продвижение. Сжатие — это сокраще­ние графика, чтобы выполнить все операции раньше, чем запланиро­вано.

Мы сокращаем график, если после проведения МКП и ТО АН мы определяем, что проект займет больше времени, чем предполагалось. В нашем примере с МКП мы определили, что проект будет завершен к 10 июля. А что если мы планировали его завершение на 2 июля? В данном случае вам необходимо использовать сокращение времени или быстрое продвижение.

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

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

О быстром продвижении мы уже говорили в 1 главе. При быстром продвижении мы начинаем две операции в одно и то же время, что согласно графику должно было выполняться последовательно. При быстром продвижении возрастает риск проекта, и команде проекта часто приходится переделывать некоторые задания. В качестве при­мера, быстрое продвижение часто используется при объектно- ориен­тированном программировании. Программисты могут писать некото­рые модули одновременно, а не последовательно, и до завершения фазы разработки.

 

Моделирование

Одним из методов моделирования является анализ Монте-Карло, резу­льтатом которого является набор возможных значений продолжитель­ности каждой операции. Затем мы выбираем для каждой операции ве­роятность продолжительности, и начинается моделирование. Метод Монте-Карло многократно использует возможные продолжительности операций и варианты графика с учетом их вероятностей, чтобы полу­чить оценки продолжительности критического пути и резервного времени. Для экзамена вы должны запомнить, что Монте-Карло — это метод моделирования, который показывает возможность всех вероят­ных сроков завершения проекта.

Классификация ресурсов

Ранее упоминалось о том, что МКП и ТОЛП не затрагивают проблему ре­сурсов. Теперь, когда у вас есть график операций, самое время опреде­лить ресурсы для этих операций и согласовать график, учитывая каждое требование к ресурсам, которое вы обнаружили.

В 5 главе мы обсуждали процессы планирования ресурсов и подбо­ра персонала. Во время этих процессов мы задокументировали уме­ния, прежний опыт, способности и персональные интересы. Мы под­бирали персонал не для отдельных операций, а для проекта в целом. Организационное развитие определяет роли и ответственность, как это установлено в сфере действия, и разрабатывает план управления пер­соналом, который описывает, как ввести ресурсы в проект и вывести их из него.

Теперь в процессе составления графика мы определяем ресурсы для специфических операций. Обычно вы сталкиваетесь с тем, что исходный график содержит периоды времени, когда ресурсов недо­статочно для выполнения всех запланированных операций. Кроме того, иногда вы столкнетесь с тем, что члены вашей команды не смо­гут уделить заданиям 100 процентов времени. Ваш график также мо­жет показать, что некоторые члены команды должны выполнить та­кой объем работы, который они просто физически не смогут реализо­вать в тот срок, который им дается. Или, наоборот, вы не сможете обеспечить их занятость на протяжении всего проекта. Эта проблема легко решается. Вы можете использовать дополнительные ресурсы для того, чтобы загрузить их работой.

Более сложную проблему представляют собой избыточные ре­сурсы. С помощью классификации ресурсов можно выровнять их рас­пределение, чтобы получить задания, которые можно выполнить, не обременяя отдельных членов команды, в то время как вы стараетесь выполнять проект согласно графику. При этом есть много способов, которые может использовать руководитель проекта. Вы можете отло­жить начало задания, до того как освободится главный член коман­ды. Или вы можете согласовать распределение ресурсов, чтобы полу­чить дополнительные задания для персонала, который недостаточно загружен. Возможно, вы выделите некоторые задания, которые тре­буют определенных знаний и умений, и поручите их членам команды с необходимым опытом. Всё это способы классификации ресурсов.

Классификация ресурсов и изыскание дополнительных ресурсов для недостаточно занятых сотрудников продляют сроки завершения проекта. Если одним из условий для вас является время, то после распределения ресурсов вам придется еще раз проверить график и скорректировать его так, чтобы проект был завершен к установлен­ной дате. Возможно, понадобится перенос ресурсов из других опера­циії на задания критического пути или согласование ресурсов, о чем упоминалось выше. Еще одним способом является использование для выполнения критических заданий тех сотрудников, которые времен­но не заняты и могли бы оказать помощь в соблюдении графика работ.

 

СЦЕНАРИЙ ИЗ РЕАЛЬНОГО МИРА

Sunny Surgeons, Inc.

Кейт Ньюман — руководитель проекта в компании Sunny Surgeons, Inc. Эта компания занимается созданием программного обеспечения, которое предназначено для медицинских работников. Программное обеспечение позволяет хирургам хранить данные о пациентах, новинках хирургии и ме­тодах исследований. Последним проектом Кейт было написание улучшен­ной версии программы обследования пациентов, которая могла бы быть объединена с программными средствами для настольных компьютеров, ис­пользуемыми в медицине.

Но в отделе программирования произошли некоторые изменения. К сча­стью Стефан, главный программист, который разрабатывал оригинальную версию программы по осмотру пациентов, все еще работает на компа­нию. Он просто незаменим для работы над проектом с его опытом и зна­ниями.

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

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

Кейт, выслушав мнение Стефана, решает все же составить классифика­цию ресурсов и посмотреть, что из этого выйдет.

Кейт пришла к выводу, что привлечение к работе Карен для выполнения незначительных заданий может быть подходящим решением. Однако в та­ком случае выполнение проекта затянется на 8 дней. Так как главным условием этого проекта является качество, Кейт считает, что сможет убе­дить участников проекта и спонсоров продлить сроки выполнения проек­та. Кроме того, классификацию ресурсов можно рассматривать как воз­можность риска низкого уровня, так как все необходимые операции будет выполнять Стефан. Но перераспределение ресурсов может вызвать стрес­совые ситуации, которые могут негативно повлиять на график проекта.

Программное обеспечение в управлении проектом

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

Подробное рассмотрение различных программ, которые может ис­пользовать руководитель проекта, не является целью данной книги. Можно сказать, что программы для управления проектом варьиру­ются от совсем простых до очень сложных. Выбор программы опреде­ляется видом методов управления проектом, которые вы используе­те. Многие руководители проектов, которых я знаю, успешно приме­няли программу Microsoft Project и используют исключительно эту программу. Она обладает такими широкими возможностями, что пригодна для использования в большинстве проектов.

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

 

Определение результатов составления графика проекта

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

График проекта

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

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

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

4/13 4/14 техническое обеспечение

График можно представить различными способами, с некоторыми из которых мы уже познакомились. Вы можете использовать сетевые диаграммы, о которых мы говорили в главе 5, если добавите к каж­дой операции срок начала и завершения. Такие диаграммы обычно показывают зависимость операций и критический путь. На рис. 7.2 представлена сетевая диаграмма для нашего примера с программным обеспечением.

 

4/15 4/22 проверка техниче­ского обеспечение

/

6/29 7/6 установка

7/10 7/10 принятие

4/1 4/12 поставки

7/7 7/9 тренировка

4/13 4/22 программное обеспечение

4/23 6/6 написание программ

6/7 6/28 проверка и отладка

Рис. 7.2. Сетевая диаграмма со сроками операций

Для представления операций широко используется диаграмма в виде линий (диаграмма Гантта), которая легко воспринимается. В зави­симости от программного обеспечения, которое вы используете для со­ставления этой диаграммы, она может показывать последовательность операций, сроки их выполнения, применение ресурсов, зависимость между операциями и критический путь. На рис. 7.3 показаны различ­ные операции и их распределение по времени. Эти операции никак не соотносятся с операциями в таблице или в других диаграммах.

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

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

Веха    Дата по графику     Реальня дата

Завершение поставок           4/12 4/12

Завершение проверки тех. об-я      4/22 4/25 Завершение программирования 6/06 Завершение отладки 6/28 Принятие и одобрение 7/10 Закрытие проекта 7/10

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

Вспомогательные детали V

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

В зависимости от проекта вы можете указать в этом разделе другую необходимую информацию. Согласно учебнику РМВОК вы можете включить сюда гистограммы ресурсов. Пример такой гистограммы был рассмотрен в 5 главе. В гистограмме ресурсов обычно по одной оси от­кладывается необходимое время (в часах), а по другой — период време­ни (месяц, неделя, день, год).

 

План управления графиком

План управления графиком должен быть опубликован наряду с другими документами планирования проекта. Как и любой другой план, план управления графиком показывает, как вы будете управлять его измене­ниями, и это является важной частью вашего общего плана проекта.

 

Требования к ресурсам

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

На практике такие процессы как: определение операций и их по­следовательности, оценка продолжительности операций и составле­ние графика могут быть сразу завершены при использовании хоро­шего программного обеспечения. Очень легко составить линейные диаграммы, критический путь, диаграммы ТОАП, распределение ре­сурсов, зависимость операций, анализ что/если, различные отчеты, если вы заносите вашу информацию о графике в большинство про­грамм управления проектом. Независимо от используемых вами ме­тодов, убедитесь, что график проекта одобрен и подписан участ­никами и спонсором проекта. И всегда имейте график под рукой — наверняка возникнут некоторые изменения или дополнения.

 

Установление базового уровня сметы расходов

Наш следующий вопрос связан с определением базового уровня сметы расходов. Бюджет будет использован в качестве плана для рас­пределения затрат и ресурсов по операциям проекта. До начала этого процесса вы должны завершить процессы составления графика и оценки стоимости, так как их результаты будут в нем использованы. К основным элементам процесса определения уровня расходов отно­сятся оценка стоимости, СОР, план управления риском и график проекта.

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

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

Параметрическое моделирование: это математическая модель, ко­торая используется для оценки стоимости проекта.

Оценка снизу вверх: этот метод включает в себя оценку затрат на отдельные операции, затем складывает их для получения полной стоимости проекта.

Компьютерные методы: они автоматически определяют стоимость проекта.

Процесс установления уровня расходов рассматривает оценки сто­имости операций и используется для измерения выполнения проекта и его изменения во время остальных групп процессов. Он служит основой для измерения стоимости, так как базовый уровень расходов представляет собой ожидаемую стоимость проекта. Как вы помните затраты рассчитываются в финансовой системе, связаны с кодами счетов и распределяются по операциям, которые указаны в соответ­ствующих уровнях СОР.

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

 

Доллары

апрель май      июнь июль

Рис. 7.4. Уровень расходов

 

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

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

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

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

 

Разработка плана проекта

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

Разработка плана проекта объединяет результаты других процес­сов планирования и располагает их в логическом порядке. Это может быть один документ со ссылкой на другие, или несколько докумен­тов, организованных в логическом порядке. План проекта, который является результатом этого процесса, используется в процессе вы­полнения проекта и его контроля для принятия решений на основе оригинального плана.

Разработка плана проекта включает в себя пять элементов, кото­рые мы обсуждали до этого. Это другие результаты планирования, историческая информация, организационная политика, условия и предположения. Учебник РМВОК подчеркивает, что образ действий должен быть согласован при составлении плана проекта. Определен­ный образ действий подразумевает качество управления, админист­рацию и финансовый контроль, согласно учебнику РМВОК.

 

Инструменты и методы

Все инструменты и методы для нас новые. Это методология планиро­вания проекта, умения и знания участников проекта, система инфор­мации управления проектом (СИУП) и управление заработанной сум­мой (УЗС). Далее мы рассмотрим каждый из них.

 

Методология планирования проекта

С самой первой главы мы объясняем и применяем методологию управ­ления проектом. Это просто формальный структурированный метод, который руководитель проекта использует для составления плана про­екта. Согласно учебнику РМВОК, это может быть программное обеспе­чение, такое как Microsoft Project, или собрания. У некоторых органи­заций есть офис управления проектом со стандартными формами, кото­рые руководитель проекта использует в процессе планирования.

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

Умения и знания участников проекта

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

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

 

Система информации управления проектом (СИУП)

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

Вы как руководитель проекта должны быть уверены в том, что управляете именно проектом, а не системой информации проекта. Очень легко использовать программы для логического планирова­ния, не уделяя внимания самому проекту. Уделяйте больше внима­ния проекту, а не просто программе или информационной системе.

Управление заработанной суммой (УЗС)

Управление заработанной суммой связано с измерением и оценкой прогресса проекта. Это объединяет в себе график проекта, сферу дейст­вия и ресурсы как единое целое, чтобы определить, есть ли в проекте изменения. Анализ заработанной суммы — это метод, используемый для расчета показателей выполнения проекта, который мы рассмот­рим более подробно в 9 главе.

Результаты разработки плана проекта

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

План проекта

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

План проекта объединяет все, о чем мы говорили ранее, и представ­ляет собой формальный документ или несколько документов. В этих документах отражены сфера действия проекта, результаты, предполо­жения, риски, СОР, вехи, график операций, ресурсы и т. д. И снова с помощью этих документов мы легко можем проследить за развитием проекта. Он также используется для контроля компонентов, которые отклоняются от оригинального плана, чтобы снова вернуть их в план.

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

Учебник РМВОК подчеркивает разницу между базовым уровнем вы­полнения проекта и планом проекта. План проекта — это документ или несколько документов, которые подтверждают, что проект существует, и определяют каковы будут результаты проекта и как все процессы бу­дут управляться. В процессе выполнения проекта в его план могут быть внесены некоторые изменения, поэтому понадобится документ или до­кументы, которые будут отражать эти изменения.

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

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

Мы уже встречали этот результат раньше. Вспомогательные детали для составления плана проекта включают в себя информацию, кото­рая не содержится в других процессах планирования проекта. Это мо­жет быть техническая информация, такая как особенности разработ­ки. В главе 6 мы говорили о стандартах и образе действий. Если это важно для проекта, вы можете включить сюда эту информацию. И снова мы возвращаемся к нашему девизу управления проектом: «До­кумент, документ, документ». Если вы не можете найти логического раздела, в который необходимо включить информацию, включите ее во вспомогательные детали. Кроме того не забудьте указать здесь предпололожения и условия, которые были установлены во время этой фазы процесса планирования.

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

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

- Kftetten Неавєп P(i>|ett plan - Еиімйпа end Cabling

Я

 

♦ * * -  л«*      . s   •   Ы  /   U   » « «  •       "Л .

Ш days   Мімі Set

з-

щ

I? days    Mon Ifimz ffi

 

J6d«y*     Мо<і1і7Я2 SetZitS.'Bi

 

!'          Т F

 

Учебный пример: Розничная продажа кухонного оборудования

Вы потратили пару дней на составление графика проекта с использовани­ем Microsoft Project 2000, определяя операции и задания с Джейком, Ри­кардо и Джилл. Вы решили, что линейная диаграмма подойдет для этого проекта как нельзя лучше. Часть вашего первого эскиза линейной диа­граммы показывает следующее в конце проекта:

 

На экране вы заметили одну проблему. Открытие магазина (номер 18) за­планировано на 2 недели позже, чем вам необходимо! Открытие должно проходить 1 и 2 февраля, а не 15 и 16, как это показано на графике. Вы возвращаетесь к проблеме и видите, что открытие магазина зависит от обучения персонала, что в свою очередь зависит от некоторых других операций, включая подбор работников магазина, установку и проверку технического оборудования и обустройство. Нельзя копать траншеи и на­чинать обустройство до того, как в здании будет проложен кабель. Рикар­до уже определил в контракте время, когда будет проложен кабель, это 17 сентября. Этот срок не может быть изменен, что подразумевает, что обу­стройство не может начаться раньше чем 19 сентября.

Вы берете телефонную трубку и набираете номер Джейка. «Джейк, я ра­ботаю над графиком проекта и у меня есть некоторые замечания относи­тельно операции Гомеса.»

«Неужели», говорит Джейк.

«Гомес не может начать операцию до установки кабеля. Я уже поговорил с Рикардо, это нельзя изменить. Рикардо заключил контракт на выполнение этой операции, и они смогут начать самое раннее 17 сентября. Для прокладки кабеля им понадобится 2 дня, то есть обустройство можно на­чать 19 сентября.»

«Хорошо», отвечает Джейк. «Это как раз то, о чем мы думали. Какая проб­лема?»

 

10—2832

«Джилл хочет, чтобы обустройство было завершено до того, как она наймет персонал магазина. Во время открытия последнего магазина такие опера­ции затянулись, и она сказала, что это было неуправляемо. Она хочет нанять персонал, который будет устанавливать полки при подготовке к открытию магазина, но чтобы в это время там не было тех, кто выполняет операции по контракту. Если операция Гомеса начнется 19 сентября, то датой заверше­ния будет 12 февраля, что слишком поздно, учитывая проблему Джилл. Те­перь мой вопрос, 120 дней для обустройства — это окончательная оценка?»

«Мы с Гомесом работали достаточно много раз над обустройством, и мы можем изменить лишь пару дней в этой оценке», говорит Джейк.

Вы берете ваш график и продолжаете. «Я составил календарь ресурсов Гомеса, как вы мне говорили. Гомес не работает по воскресеньям, как и мы. Но, учитывая праздники, день рабочего, день благодарения, рождест­во и новый год, мы отклоняемся от схемы. Я знаю, что Дирк не захочет от­кладывать открытие магазина, которое назначено на 1 февраля.»

«Я не могу изменить 120 дней. Это ваша проблема.»

«Тогда нужно изменить график», говорите вы. «Согласится ли Гомес разделить задания по обустройству?. Мы можем подключить еще рабочих по контракту, которые помогут его команде ускорить выполнение операции. Это сократит сроки ее выполнения до 100 дней, и мы сможем уложиться в срок 1 февраля.»

«Не получится. Я знаю Гомеса. У всех свои приемы и методы. Мы обычно работаем только с ними. Если мы подключим еще какую-либо команду, мне придется потратить много времени на переговоры.»

«Хорошо», говорите вы. «Как насчет такого варианта? Пока мы с вами гово­рим, я вношу некоторые изменения в график. Что, если Гомес будет работать по 10 часов с выходным в воскресенье, и мы попросим его поработать в день рабочего и дадим один выходной на оставшиеся праздники вместо двух?»

3. Я<Г « rJ .

« ft s о ^ (2 J U  Ш w в

Измененные данные показаны ниже.

Li I Fife l$>

1     Я и & v- * а

♦   ♦   +   -   Stow- Af*t

 

" ГТ H»dw>re

T-ar* SlOre Personnel

Of«*l Opening

 

e4 Зі

 

-«..-, С

t a

•   Si, St,

*-   «Р M .

 

-

,   и І

it .' -»

 

- *Чь

 

 

о

\%-(\%^——       

- 2            ~"

 

- "i'it'           

 

«агенсе ^яг«ї

 

 

 

 

 

 

 

 

Кйвіієе! Heaecn Pr eject plan

 

1S( days

Moil

\%яа mm

 

 

г Віяїіі


Оцените книгу: 1 2 3 4 5