Название: Профессиональное управление проектом - Хелдман К. Жанр: Менеджмент Рейтинг: Просмотров: 8113 |
Составление плана проекта
В качестве доминирующих тем данной главы выступают: 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
Учебный пример: Розничная продажа кухонного оборудования
На экране вы заметили одну проблему. Открытие магазина (номер 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
Лучшие книги Гражданский процесс: Вопросы и ответы ЗАПАДНОЕВРОПЕЙСКОЕ ИСКУССТВО от ДЖОТТО до РЕМБРАНДТА Коммуникации стратегического маркетинга Консультации по английской грамматике: В помощь учителю иностранного языка. Международные экономические отношения |