Согласователь/контролер

Лицо, определяющее соответствие проекта и его продуктов требованиям внешних стандартов

2.4 Определение успешности проекта

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

70 - 80 годы послужили временем изменения подхода к проектному управлению. К этому времени относится использование новых "мягких" (soft) инструментов и подходов, в первую очередь связанных с человеческими ресурсами; следующим шагом стало распространение так называемого системного подхода в проектном менеджменте - подхода, при котором менеджеры проекта начали рассматривать более широкий контекст предприятия и общества в целом, в котором выполняется проект. Применение проектного управления в совершенно новых областях - в том числе при реорганизации предприятий государственной службы и реализации международных социо-экономических проектов - а также его активное использование внутренними ИТ-проектами предприятия кардинально изменило отношение к данной методологии руководителей всех уровней компании, превратив его из простого технического инструмента в средство реализации стратегических решений компании.

Естественно, подобные изменения подхода к использованию методологии повлекли за собой и изменение самого инструментария, а также понимания ответственности проектного менеджера. Если 10 лет назад проектный менеджер мог вполне обоснованно утверждать, что он "не несет ответственности за все то, что лежит за пределами содержания проекта", на сегодняшний день, с повсеместным внедрением клиенто-ориентированных подходов, уже нельзя отделить сам продукт проекта от, скажем, последствий его внедрения в организациях. Таким образом, в сегодняшнем управлении проектами появляется много новых методов и подходов, которые позволяют менеджеру и его команде оценивать результативность проекта и продукта в долгосрочном масштабе.

Одну из таких методик мы рассматривали ранее в части, посвященной управлению изменениями в компаниях - это методология управления по результатам, или result-based management (см. след. главу).

Еще один подход, получающий все большую популярность в наше время - методология оценки успешности проекта.

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

 Всегда применяются по окончанию проекта.

 Обычно находятся под контролем команды проекта,

то показатели успешности продукта:

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

 И обычно выходят за рамки прямого контроля проектной команды.

По сути дела, данный анализ дополняет первичные шаги исследования окружения проекта (поле сил и матрица заинтересованных сторон). На данном этапе мы проводим анализ тех критериев (факторов), согласно которым будут оценивать успешность проекта все заинтересованные участники, и в результате получаем собственно stakeholder matrix:

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

Возможные примеры соотношения критериев успешности продукта для разных заинтересованных сторон представлены ниже:

Заинтересованное лицо	Определяет успешность как…
Контроль качества, ИТ	Соответствие внутренним стандартам качества
ИТ, разработка	Простота в разработке и поддержке
Маркетинг	Рыночная новизна
Фиансы	Проект с низкими затратами
Акционеры	Продукт с высокой "маржой"
Покупатли	Дешевый продукт

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

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

 Что должна будет сделать команда, чтобы удовлетворить этим критериям?

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

Окончательные данные по оценке успешности проекта могут быть сведены в следующую табличку:

Ключевые факторы успеха
Организация
Проект
Ключевые заинтересованные стороны, типы
Основные факторы успешности проекта
Заинт. Сторона	Фактор 1	Фактор 2	Фактор 3
Предлагаемые стратегии проектной команды по повышению вероятности достижения фактора успешности

2.5 Метод Управления по результатам

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

Отличие метода УпР от классической методологии УП

· Рассмотрение более долгосрочных ожидаемых результатов проекта - изменений, происходящих как в самом проекте, так и в окружающей его среде

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

· Более четкое и постоянно обновляющееся построение логической связи между затратами на производство, деятельностью, достижением краткосрочных задач, среднесрочных и долгосрочных результатов (также именуемых последствиями).

· Особый акцент на рассмотрение внешних факторов, способствующих или препятствующих прогрессу проекта согласно этой схеме;

· Определение качественных показателей эффективности проекта наравне с показателями количественными и разработка методов сбора информации для определения прогресса проекта.

Примеры организаций, использующих RBM

Методология управления по результатам, получившая основное распространение в государственных и социально-ориентированных программах, изначально являлась модификацией классической методологии управления проектами, разрабатываемой рядом международных финансовых институтов для осуществления проектов и программ международного развития. Таким образом, немалый вклад в развитие методологии был внесен Мировым Банком, UNDP, Агентствами Международного Развития различных стран. Примененный впервые, в приложении к реформам 90-х годов в Канаде и Северной Европе, этот метод показал себя исключительно эффективным в реализации программ и проектов организационных преобразований в государственном секторе. Действительно, методология обладает рядом отличительных особенностей, позволяющих ей адресоваться к основным вопросам и проблемам государственных и социоориентированных систем, в том числе:

· учет участия лиц, вовлечённых в проект, позволяет улучшить планирование и внедрение проекта за счёт использования мнений широкого круга лиц;

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

· рассмотрение внешних факторов, способствующих или препятствующих прогрессу проекта согласно этой схеме;

· определение качественных и количественных показателей и методов сбора информации для определения прогресса проекта;

· надежная система отчётности, УПР представляет всем участникам проекта возможность получения достоверной информации о ходе достижения результатов проекта на основе использования высоко эффективной системы отчетности по выполнению проекта;

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

Ниже представлен список примеров организаций, использующих RBM:

Государственные структуры:

· Canadian Centre for management development - Canada

· The Agency for Administrative Development and the National Audit Office - Sweden

· Office of the Assistant Secretary of Defense for Command, Control, Computers, and Intelligence (C3I) - USA

Международные организации:

· World Bank

· UNDP

· Commonwealth Network of Information Technology (IT) for Development (COMNET-IT)

· Фонд Сороса

Коммерческие компании (типы бизнеса):

· Software development, installation and consulting

· Information management and communication technology

· Research and development

· Consulting

· Ecology and environment

Цепь результатов

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

Метод управления по результатам не является абсолютно новым. Однако он принципиально отличается от традиционных методов управления, устанавливающих зависимость между затратами на производство и деятельностью, с одной стороны, и непосредственными результатами проекта, с другой (например, определённое количество выпущенных в печать сообщений; число лиц, прошедших обучение; количество посаженных деревьев). RBM уделяет особое внимание таким долгосрочным результатам и последствиям, которые приводят к важным изменениям в жизни людей и общества в целом.

Для более понятной расшифровки диаграммы, необходимо ознакомится со смыслом основным приведенных в ней понятий. Ниже представлены общие принципы интерпретации элементов цепи результатов согласно основным принципам Канадского Агентства Международного Развития:

ВХОДЫ (РЕСУРСЫ) - Человеческие, организационные и физические ресурсы, прямо или косвенно выделенные заинтересованными сторонами проекта.

РАБОТЫ (ДЕЯТЕЛЬНОСТЬ) - Все работы, организованные и проводимые персоналом проекта, включая координацию и поддержку выполнения. Как правило, проекты включают в себя десятки или сотни различных видов деятельности.

КРАТКОСРОЧНЫЕ РЕЗУЛЬТАТЫ (ВЫХОДЫ) - OUTPUTS - первые результаты проекта, на которые непосредственно влияет менеджер проекта и его команда. Логическое следствие деятельности по проекту: большинство краткосрочных результатов непосредственно связаны с одним видом деятельности. Как правило, число краткосрочных результатов и видов деятельности должно приблизительно совпадать. Краткосрочные результаты могут быть выражены количественно, а также содержать качественные изменения, и указывают на потенциал деятельности. Часто такой потенциал создаётся определённой группой людей, которые непосредственно участвуют в работах (например, участников учебной программы). Иногда такой потенциал выражен определённым продуктом (например, разработка правил подачи документов или создание плаката).

СРЕДНЕСРОЧНЫЕ РЕЗУЛЬТАТЫ (РЕЗУЛЬТАТЫ) - вытекают из краткосрочных результатов и указывают на их потенциал. Обычно среднесрочные результаты достигаются в ходе проекта и являются логическим следствием комбинации краткосрочных результатов. Среднесрочные результаты невозможно полностью контролировать, поскольку они находятся вне сферы влияния проектного менеджера и подвержены внешним факторам. В то же время чрезвычайно важно приближаться к этим результатам, что влечёт за собой важные изменения, являющиеся целью работы.

Среднесрочным результатам соответствуют ЦЕЛИ ПРОЕКТА.

ДОЛГОСРОЧНЫЕ РЕЗУЛЬТАТЫ (ПОСЛЕДСТВИЯ) - обычно описывают непосредственные изменения, вызванные проектом в целом. Долгосрочные результаты указывают на основную цель работы и объясняют её важность, являясь логическим следствием комбинации краткосрочных и среднесрочных результатов. В идеальном случае долгосрочные результаты удовлетворяют следующим условиям: 1) они вдохновляют людей к достижению определенной цели; 2) на определённом этапе в будущем проект вызовет эти последствия.

Долгосрочным результатам соответствует МИССИЯ ПРОЕКТА.

РИСКИ И ПРЕДПОЛОЖЕНИЯ -- в конечном счёте план проекта основан на серии предположений и подсчёте риска. Предположения - условия, необходимые для запланированного прогресса проекта. Риски - вероятность отсутствия этих условий. Величина риска определяется расчётом, а для небольших проектов основана на интуиции. Риск определяется на основе всех способствующих и препятствующих факторов. Риск может быть низким, средним или высоким.

ИНДИКАТОРЫ (ПОКАЗАТЕЛИ) - подтверждение/доказательство прогресса проекта. Определение индикаторов, которые предоставят проекту точную информацию, - сложная задача, которая обычно решается методом испытаний и корректировки ошибок. Индикаторы должны предоставлять надёжную информацию, которую легко собрать и можно использовать для принятия административных решений.

На всех уровнях результатов цепь результатов предполагает рассмотрение целевой группы получателей конечного продукта - REACH.

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

2.6 Описание содержания

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

По рекомендациям Вильяма Дункана, автора Свода Знаний по Управлению проектами 1996 года, описание содержания должно включать следующие основные части:

 Обоснование проекта

 Резюме продукта

 Список всех "объектов доставки"

 Границы

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

Обоснование проекта может быть как финансовым (методы обоснования инвестиционных проектов: анализ безубыточности, анализ потоков наличности - период окупаемости, средняя ставка возврата инвестиций; наконец, методы, использующие дисконтированные величины - внутренняя ставка возврата инвестиций (IRR) и т.д.) , так и не финансовым, что в особенности актуально для внутренних проектов компаний. В последнем случае, Если вы не уверены в описании проблемы, заполните пробелы:

"Текущая ситуация _________; в результате, _________"

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

Несколько подсказок в отношении формулирования обоснования и описания содержания проекта:

Если проблема недостаточно четко определена …

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

Если проблема определена хорошо, но решение неясно…

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

Резюме продукта описывает, как именно проект адресуется к описанной проблеме, то есть отвечает на вопрос - что из себя представляет проект?

Это - описание конечного результата на более высоком уровне детализации, чем техническое задание.

При написании резюме продукта, проверьте сами себя: спросите сами себя -- действительно ли продукт "решит" (или хотя бы поможет решить) проблему, описанную вами в обосновании проекта?

Список продуктов проекта, или объектов доставки (deliverables), определяет ключевые компоненты продукта проекта. При составлении списка объектов доставки мы отвечаем на вопрос: как определить, что проект закончен? При этом под термином "законченный" мы понимаем ту ситуацию, когда не требуется никакая дополнительная работа по получению каких-либо результатов в рамках данного проекта.

Несколько подсказок в отношении составления списка объектов доставки:

 Описание ключевых объектов доставки должно помочь читателю понять, что такое проект.

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

 Каждый ключевой объект доставки должен быть измеримым, ощутимым, поддающимся проверке выходом работ

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

При составлении списка объектов доставки обязательно нужно учитывать ВСЕХ заинтересованных участников проекта и их интересы, иначе у нас есть потенциальная возможность упустить что-либо из тех работ, которые нужно выполнить для получения этих дополнительных результатов, и, соответственно, необходимых временных и бюджетных ресурсов.

Наконец, последняя часть описания содержания носит название "границ" (borders) и в основном определяет, где находятся пределы проекта, то есть те рамки, за пределы которых проект не должен выходить. Эта категория информации включает:

 Ограничения -- факторы, которые лимитируют возможности планирования команды.

Реальные внешние факторы (реальность, данная нам в ощущениях), которые будут создавать трудности в процессе планирования; пример - ограничением по срокам проекта автоматизации процесса президентских выборов, станет сам день выборов.

 Предположения -- факторы, которые в целях планирования принимаются командой как определенные.

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

 Исключения -- результаты, которые может резонно ожидать покупатель и которые не будут предоставлены.

По сути дела, это ПОТЕНЦИАЛЬНЫЕ пункты списка объектов поставки, по той или иной причине нами в список не включенные. Например, мы не будем в рамках данного проекта проводить обучение. Возможно, то же самое обучение будет проведено другой группой специалистов нашей компании в рамках отдельного договора, но оно не будет частью текущего проекта.

2.7 Структура декомпозиции работ проекта (структурная декомпозиция работ проекта)

В ходе составления описания содержания, проектный менеджер и команда определяют результаты, которые должны быть достигнуты по завершении проекта, и согласовали их со всеми заинтересованными лицами. Однако команда не может продолжать процесс планирования проекта, руководствуясь лишь перечнем этих результатов. Чтобы спланировать проект, необходимо определить, какие конкретные работы должны быть выполнены для достижения этих результатов, т. е. для успешного завершения проекта. Для этого и используется структура декомпозиции работ (СДР, или Work Breakdown Structure, WBS).

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

WBS, по определению PM-BoK - это продуктно-ориентированное группирование элементов проекта, организующее и определяющее все содержание.

WBS включает результаты изготовления продукта также, как и результаты управления.

Работы, не включенные в WBS, не входят в рамки проекта.

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

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

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

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

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

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

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

 Один четкий результат

 Один четкий "владелец" (ответственный)

 Можно вычислить трудозатраты и продолжительность

 Можно измерить полноту выполнения

Если проект большой, WBS может иметь довольно общий характер. Можно остановиться на самом нижнем уровне, который отслеживает руководитель проекта. Этот уровень, напомним, принято называть пакетом работ. Следует учитывать, что, начиная с этого уровня, другие менеджеры, занятые на проекте, должны осуществить более подробное разделение проекта на части (подпроекты) до уровня элементарных работ.

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

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

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

Ниже представлены примеры структурных декомпозиций, организованных по продуктам и по фазам (основным этапам изготовления продукта проекта, характерно, в частности, для фармацевтики и строительства):

WBS по продуктам

WBS по фазам

3. Оценка затрат

3.1 Методы Оценки затрат проекта

Стоимостная оценка - это оценка вероятной стоимости тех ресурсов, которые потребуются для выполнения работ, предусмотренных проектом.

Стоимостные оценки рассчитываются в течение всего проекта.

На ранних стадиях проекта неопределенность в понимании реального объема работ проекта еще слишком велика, и нет никакого смысла в затратах усилий на то, чтобы на каждой стадии проекта делать более точные стоимостные оценки, чем это необходимо на текущий момент. Однако к моменту выработки согласованной базовой цены проекта (project cost baseline) необходимо провести окончательную стоимостную оценку (definitive estimate), значение которой не должно быть меньше реальной более чем на 5% и превышать ее более чем на 10%.

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

Методы оценки

Метод оценки затрат проекта подразделяются условно на методы "сверху вниз" (top down estimate) и "сниху вверх" (bottoms up estimate). Методы "сверху вниз" (top down estimate) используется для оценки затрат на ранних стадиях проекта, когда информация о проекте еще очень ограниченна. Смысл такой укрупненной экспертной оценки в том, что она производится обобщенно и проект оценивается в целом по одному показателю. Оценка удобна тем, что не требует больших усилий и времени. Недостатком же является не такая высокая точность, какая могла бы быть при более детальной оценке.

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

Метод оценки "по аналогу"

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

Если сходство между проектом-аналогом и оцениваемым проектом велико, то результаты оценки могут быть очень точными, в противном случае оценка будет произведена неверно.

Пусть, например, требуется разработать новый программный продукт, и его модули аналогичны модулям другого, уже разработанного продукта, но должны содержать большее количество команд. По характеру работы предыдущий и предстоящий проекты очень схожи. Если объем работ в новом проекте на 30% больше, чем в предыдущем, то метод оценки "по аналогу" позволяет предположить, что и стоимость нового проекта будет на 30% больше стоимости предыдущего.

Методы параметрических оценок

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

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

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

Простейший пример: строительство дома стоит 115 долл. за квадратный фут, следовательно, постройка дома площадью 1000 квадратных футов обойдется в 115 тыс. долл.

3.2 оценки в интервалах величин (ranged estimates)

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

Общепринятый подход к оценке затрат по проекту в условиях некоторой неопределенности по величинам затрат (как бюджетных, так и временных), носит название оценки затрат в интервалах величин, или статистической оценки для бюджета и расписания. Это - так называемый метод оценки СНИЗУ ВВЕРХ (bottom up) - в отличие от МЕТОДОВ СВЕРХУ ВНИЗ, описанных выше, он базируется на оценках индивидуальных работ на нижнем уровне структурной декомпозиции, а затем суммировании затрат на более высоких уровнях WBS для получения оценки стоимости (сметы) всего проекта.

Данный подход впервые был применен для оценки времени выполнения проекта в 50 годы в одном из оборонных проектов США с целью максимального повышения качества и точности прогнозирования дат окончания проекта и получил название метода анализа длительности проекта (PERT).

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

Очевидно, что в случае оптимистического значения мы рассматриваем тот редкий случай, когда все в проекте идет как нельзя лучше. Пессимистическое значение соответствует ситуациям, в которых исполнители умудряются наступить на все возможные грабли. При формировании наиболее вероятного значения мы предполагаем, что часть проблем проявилась в ходе проекта, а часть работ не была реализована. Иными словами, во всех трех случаях мы оцениваем стоимость выполнения той или иной задачи на основе АНАЛИЗА НОРМАЛЬНЫХ РИСКОВ (не форсмажоров!), ассоциированных с данной задачей. Форсмажоры в свою очередь тоже будут нами рассматриваться - позже, непосредственно в процессе анализа рисков проекта. Далее для каждой индивидуальной работы мы вычисляем величины дисперсии, степени отклонения - ? (или ее производного - стандартного отклонения, которое является квадратным корнем дисперсии - сигма, у, или s), а также ожидаемой бюджетной величины (мат.ожидание - X), используя эмпирически выведенные формулы:

X_работы = (X₁ + X₂ + X₃)/3, ?_работы = ((X₃ - X₁)/5)²,у_работы=v?_работы

где Х1 -- оптимистическое значение, Х2 -- наиболее вероятное значение, Х3 -- пессимистическое значение.

Данный метод предполагает использование ассиметричных распределений для описания плотностей вероятности для возможных выходов затрат по индивидуальным (отдельным) работам проекта:

По свойствам Центральной Предельной Теоремы, мы далее можем предположить, что при определенном приближении (представлении о количестве работ, стремящемся к бесконечности - преувеличение, с учетом общей ошибки измерений при определении продолжительности работ приближенное, однако, к реальной картине) мы можем постулировать, что вероятностное распределение для описания общих затрат по проекту в целом будет являться (в изначальном звучании теоремы - стремиться) к нормальному.

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

Х проекта (бюджетное значение, ожидаемая величина) = ?Х индивидуальных работ,

? проекта = ?? индивидуальных работ,

у проекта = v? проекта = v?? индивидуальных работ = v? (у) 2 индивидуальных работ

Ниже представлена таблица значений для оценки затрат по работам простого проекта:

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

По свойствам нормального распределения, число определенных значений у (s) _{проекта} , вычтенных и прибавленных к ожидаемой величине затрат по проекту, будет соответствовать тому или иному значению вероятности попадания окончательной суммы затрат в указанный промежуток:



На практике в проектах нам обычно нужно знать, какова СУММАРНАЯ вероятность того, что мы можем завершить проект в рамках данного бюджета ИЛИ МЕНЬШЕ, то есть нам нужна площадь ВСЕЙ фигуры под кривой, отделяемой от общего распределения отрезком в Х ПЛЮС соответствующее количество у (s) _{проекта .} Приведенный ниже рисунок поясняет данную связь графически на примере проекта, представленного в таблице.:

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

4.1 Диаграммы расписаний

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

Существуют три основных диаграммы расписаний, с которыми нам придется работать в ходе планирования и управления временем в проекте.

 Сетевая диаграмма - показывает логические взаимоотношения между работами. Не очень хорошо показывает внутренние связи расписания.

 Графики Гантта - хорошо показывают внутренние связи расписания. Плохо показывают логические взаимоотношения.

 Диаграммы контрольных событий и диаграммы суммарных работ - хорошо показывают основные составные части проекта. Плохо показывают детали.

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

4.2 Сетевые диаграммы. Работа - вершина

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

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

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

Логические взаимосвязи

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

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

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

Для вычисления расписания по методу критического пути, нам необходимо ввести 4 новых термина:

ES - Дата раннего начала, самая ранняя с которой, может быть начата задача при данных логических ограничениях

EF - Дата раннего окончания, ближайшая дата, когда задача может быть завершена, ES плюс продолжительность

LS - Дата позднего начала, самое позднее когда задача может начаться, чтобы удовлетворять дате позднего окончания, LF минус продолжительность

LF - Дата позднего окончания, самое позднее, когда задача может быть закончена для того, чтобы удовлетворять дате позднего окончания проекта.

Следующее, что мы делаем (а вернее, что делает компьютерная программа по управлению проектами, просчитывая наше расписание по методу критического пути) - это осуществляем так называемый "проход вперед" - forward pass (проход для определения "естественной даты окончания" проекта на основе даты его раннего начала и раннего окончания) и "проход назад" - backwards pass (для определения дат позднего начала и окончания). То есть последовательно определяем раннее и позднее расписание для всех задач проекта.

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

Запас бывает двух видов:

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

 Запас (обычный запас, общий запас) - время, на которое задача может быть задержана так, чтобы не было задержано само завершение проекта.

Резерв, или запас, являются показателями степени свободы (гибкости) расписания. Те работы, которые обладают запасом, могут использоваться нами как источник ресурсов для тех работ, которые жестко ограничены во времени, не имеют запаса и "лежат на критическом пути", являясь, таким образом, основным объектом нашего внимания как проектных менеджеров.

4.4 PERT

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

X_работы = (X₁ + 4*X₂ + X₃)/6, ?_работы = ((X₃ - X₁)/6)²,у_работы=v?_работы

где Х₁ -- оптимистическое значение, Х₂ -- наиболее вероятное значение, Х₃ -- пессимистическое значение.

В таблице внизу приведен расчет продолжительностей работ проекта на основании анализа PERT:

4.5 Буферные расписания

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

По аналогии с рассмотренной выше методикой определения стоимости проекта, вместо того чтобы выбрать наиболее вероятное значение, мы остановимся на значении, которое вместо 50-процентной даст нам 99,7-процентную вероятность того, что мы окажемся правы, -- а именно среднее + два стандартных отклонения.

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

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

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

Довольно элегантный способ предложил израильский менеджер Голдратт в своей теории критических цепей. Критическая цепь у Голдратта -- стандартный критический путь проекта в условиях ограниченных ресурсов, т. е. последовательность работ проекта, задержка выполнения любой из которых отодвинет дату окончания проекта, с указанием распределенных на эти работы ресурсов. Все остальные работы Голдратт представляет в виде входящих (feeding -- букв. "кормящих") цепочек проекта. В отличие от стандартного метода распределения буфера по задачам критического пути, не имеющим степени свободы, Голдратт также предлагает вычислить суммарную величину 2sigma: для каждой из входящих цепочек. Далее предлагается все работы входящих цепочек спланировать в расписании согласно датам позднего начала и окончания, то есть самым поздним датам начала работ без необходимости изменения времени окончания проекта. По мнению Голдратта, это дает нам возможность потратить больше времени на изучение задачи и сбор информации перед началом выполнения и таким образом снижает потенциальные риски, с которыми мы можем столкнуться при выполнении данных работ. Для того чтобы не подвергнуть риску выполнение работ критического пути, связанных с теми или иными входящими цепочками, необходимо отнести запланированные даты окончания и старта на часть буфера данной цепочки, распределенную на данную работу.

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

5. Управление рисками проекта

5.1 Определения и основные процессы

Определение риска, взятое из оксфордского словаря - возможность или вероятность опасности, потери или других неблагоприятных последствий

Однако в управлении проектами мы даем понятию риска более широкое определение. В соответствии с PM-BoK, риски - это задачи или работы, выполнение которых может быть, а может не быть обязательным. Иными словами, это возможное незапланированное событие, которое может быть позитивным и негативным.

Все риски ассоциированы с вероятностью.

Все риски оказывают воздействие.

Все риски характеризуются жестокостью.

Практически все действия, предпринимаемые нами в ходе планирования проекта (определение содержания, структурная декомпозиция, статистические методы оценки расписания и затрат и т.д.) так или иначе являются методами "неформального управления рисками" проекта. Когда мы говорим о "формальном управлении рисками", мы имеем в виду усилия, конкретно направленные на выполнение действий по управлению рисками.

Эти усилия сводятся к нескольким основным процессам управления рисками, которые показаны на схеме внизу:

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

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

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

Одним из известных выражений коллективной памяти являются так называемые таксономии рисков, существующие для проектов из различных отраслей.

Таксономия - это некая классификация или категоризация рисков:

 Обычно по источнику риска

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

 Может включать множественные уровни

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

Ниже приведена, для примера, таксономия рисков для ИТ-проекта разработки некоего программного обеспечения:

 Инженерия продукта -- стабильность требований, технические ограничения и т. д.

 Среда разработки -- подходящие процессы, опыт менеджеров, дух команды и т. д.

 Проектные ограничения -- бюджет, расписание, заинтересованные участники и т. д.

Несколько подсказок в отношении других подходов к определению рисков вашего проекта:

 Посмотрите на список ваших предположений и ограничений - каждый пункт - это риск!

 Посмотрите на вашу WBS -- что может пойти не так с каждой из работ или результатов?

 Устройте мозговой штурм с командой... Рассмотрите проблемы предыдущих проектов.

5.3 Оценка рисков

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

Качественный анализ величины рисков, в отличие от количественного,

 Поощряет свободное выражение идей в отношении рисков

 Позволяет высказывать мнения

 Действует на основании здравого смысла

 Хорош для получения информации от не-экспертов

 Хорош, когда существует высокий уровень неопределенности.

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

Ниже представлен простейший алгоритм для качественного определения рисков:

Оцените вероятность проявления:

 Высокая, Средняя, Низкая

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

 Высокое, Среднее, Низкое

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

Если ранжирование рисков по шкале светофорной матрицы (высокий, низкий, средний) представляется слишком сложным, можно использовать матрицу сопоставления. В этом случае мы сравниваем все риски между собой попарно - предположим, по величине вероятности или воздействия. Вначале риск N 1 сравнивается с риском N 2 (см. рисунок); тот из пары, который оказывается более значимым, получает галочку в пустой строке внизу матрицы. Далее таким же образом сравниваются остальные пары, после чего исходя из числа галочек под каждым риском ему назначается суммарный балл (по возрастанию значимости):

Другие методы оценки рисков включают в себя:

 Анализ ожидаемой денежной величины

 Взвешенные крайности

 Факторные шкалы

Ожидаемая величина для определенных вами рисков проекта вычисляется следующим образом:

 Если вероятность измеряется в пределах значений от 0 до 1.0

 Если уровень воздействия оценивается в долларах

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