Акупунктура, Аюрведа Ароматерапия и эфирные масла, Консультации специалистов: Рэйки; Гомеопатия; Народная медицина; Йога; Лекарственные травы; Нетрадиционная медицина; Дыхательные практики; Гороскоп; Правильное питание Эзотерика

INTUIT.ru::Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий http://www.INTUIT.ru Основы управления проектами 1. Лекция: Основные понятия и определения управления проектами: версия для печати и PDA

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

Основные цели:

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

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

В качестве субъектов управления в СУП рассматриваются активные участники проекта, взаимодействующие при выработке и принятии управленческих решений. К ним относятся:

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

В качестве объекта управления рассматриваются:

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

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

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

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

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

Процессы управления проектами

О различных трактовках понятия "проект"

Понятие "проект" в разных моделях и стандартах трактуется с разных позиций. Например, в процессной модели (ISO 9000, 10006) проект рассматривается как процесс. А в рамках "менеджерской" (организационно-деятельностной) модели (ICB IPMA) "проект" как понятие определяется через "предприятие", "усилие" и "деятельность".

Таблица 1.1. Некоторые определения термина "проект"

Проект - это:

предприятие, которое характеризуется принципиальной уникальностью условий его деятельности, таких как цели (задачи), время, затраты и качественные характеристики и другие условия, и отличается от других подобных предприятий специфической проектной организацией; предпринимаемое усилие, организующее человеческие, материальные и финансовые ресурсы в неизвестный путь в рамках уникального предмета работы, заданной спецификации, с ограничениями на затраты и время, с тем чтобы следование стандартному жизненному циклу проекта приводило к осуществлению успешных изменений, определенных посредством количественных и качественных целей и задач; уникальный набор скоординированных действий с определенным началом и завершением, осуществляемых индивидуумом или организацией для решения специфических задач с определенным расписанием, затратами и параметрами выполнения. IСB - IPMA Competence Baseline. Version 2.0. IPMA Editorial Committee. - Bremen: Eigenverlag, 1999 -p.23. Проект Уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам. ISO/TR 10006: 1997 (Е). Quality Management - Guidelines to quality in project management - p. 1.

Проект

Временное предприятие (усилие), осуществляемое (предпринятое) для создания уникального продукта или услуги.

A Guide to the Project Management Body of Knowledge. PMI Standards Committee. 2000 Edition, 2000 - p.4.

Проект

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

AIPM - Australian Institute for Project Management, National Competence Standard for Project Management - Guidelines 1996 - p. 18.

Проект

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

British Standard BS 6079-1:2000. Project management- Part 1: Guide to Project management- p.2

Определение проекта

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

ЭТАП 1: разработка технического заданияЭТАП 2: расстановка приоритетовЭТАП 3: структурирование работ по этапамЭТАП 4: совмещение структуры распределения работы по этапам (СРРПЭ) с организациейЭТАП 5: кодирование СРРПЭ для информационной системы

Этап 1: разработка технического задания

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

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

В ходе работы с более, чем 1400 управляющими проектами в США и Канаде было установлено, что около 50% проблем планирования связаны с нечетким техническим заданием и постановкой целей.

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

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

Использование перечня контрольных вопросов проекта

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

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

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

Контрольные точки. График контрольных точек отражает только основные сегменты работы; он показывает первую, приблизительную оценку затрат времени, стоимости и необходимых ресурсов для проекта. Этот график составляется с использованием промежуточных результатов работы, как основы для определения основных сегментов работы и конечной даты. Технические требования. Обычно товар или услуга для того, что бы хорошо работать, должны отвечать техническим требованиям. Например, техническим требованием к ПК может быть способность работать от сети переменного тока в 120 вольт или от постоянного тока в 240 вольт без адаптеров. Ограничения и исключения. Следует четко определить границы ТЗ. Примером такого ограничения является сбор данных клиентом, а не подрядчиком; какой нужно построить дом, а не то, как он вписывается в пейзаж, или какие приборы, обеспечивающие охрану и безопасность, нужно установить; какие программы нужно ввести, а не какую подготовку дать персоналу. Проверка выполнения работы совместно с заказчиком. Контрольный список вопросов ТЗ проекта заканчивается совместной с заказчиком проверкой выполнения работы. Получает ли заказчик в виде промежуточных результатов то, что он хочет? Указывает ли определение проекта ключевые достижения, сметы, сроки и требования к выполнению работ? Рассматриваются ли вопросы ограничений и исключений? Обсуждение всех этих вопросов крайне необходимо во избежание недопонимания.

Разработка ТЗ проекта

Цель проекта

Построить высококачественный дом по индивидуальному проекту за пять месяцев, не превышая затрат в $ 150 000.

Промежуточные результаты работы

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

Контрольные точки:

Получить разрешения - 5 марта. Заложить фундамент - 14 марта. Внутренние работы. Установка рам, внутренняя отделка, слесарные работы, монтаж, электропроводка, прохождение инженерно-технического контроля - 25 мая. Итоговый контроль - 7 июня.

Технические требования:

Дом должен соответствовать местным строительным нормам. Все окна и двери должны соответствовать стандартам NFRC class 40 energy ratings. Внешняя облицовка стен должна соответствовать стандарту "R" factor of 21. Покрытие потолка должно соответствовать стандарту "R" factor of 38. Покрытие пола должно соответствовать стандарту "R" factor of 25. Гараж должен быть построен на две большие машины и один 20-футовый Winnebago. Конструкция должна соответствовать нормам сейсмической устойчивости.

Ограничения и исключения:

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

Проверка выполнения работ заказчиком: Джон и Джоан Смит.

Этап 2: расстановка приоритетов

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

Матрица приоритетов проекта

Время Результаты Стоимость Ограничить * Улучшить * Принять *

Этап 3: структурирование работ по этапам

Основные группы в структуре распределения работы по этапам (СРРПЭ)

Работу над проектом можно разделить на более мелкие элементы.

Результат этого поэтапного процесса называется структурой распределения работы по этапам (СРРПЭ).

Рис. 1.1. Иерархическое деление СРРПЭ

Разработка СРРПЭ

Структура распределения процесса работы по этапам

Каждый набор работ в СРРПЭ:

Определяет, какая работа будет выполняться (что). Указывает время выполнения набора работ (как долго). Определяет смету с учетом времени на выполнение набора работ (стоимость). Определяет ресурсы, необходимые для выполнения набора работ (сколько). Определяет контрольные пункты для измерения хода выполнения.

Этап 4: совмещение СРРПЭ с организацией

Для определения подразделений организации, ответственных за выполнение конкретных работ строится схема организационной структуры (СОС).

Целями СОС являются:

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

Обычные пакеты прикладных программ позволяют управляющим проектом выбирать СРРПЭ или СОС.

Таблица 1.2А. Упорядочение по СРРПЭ Смета прямых расходов 1.1.3 Жесткий диск 1660 1.1.3.1 Двигатель 10 Закупка 10 1.1.3.2 Микросхема 1000 Дизайн 300 Производство 400 Испытания 120 Программное обеспечение 180 1.1.3.3 Крепежная рама Производство 50 1.1.3.4 Головка чтения/записи 600 Дизайн 300 Производство 200 Испытания 100 Таблица 1.2В. Упорядочение по СОС Смета прямых расходов Дизайн 600 1.1.3.2 Микросхема 300 1.1.3.4 Головка чтения/записи 300 Производство 650 1 1.3.2 Микросхема 400 1.1.3.3 Крепежная рама 50 1 1.3.4 Головка чтения/записи 200 Испытания 220 1.1.3.2 Микросхема 120 1.1.3.4 Головка чтения/записи 100 Закупка 10 1.1.3.1 Двигатель 10 Программы 180 1.1.3.2 Микросхема 180 Итого 1660

Этап 5: кодирование СРРПЭ для информационной системы

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

Пример проекта нового компьютера и "Дискового запоминающего устройства":

Компьютерный проектДисковое запоминающее устройство Гибкий диск Оптический диск Жесткий диск Двигатель Исходный набор работ Головка чтения/записи Учетный номер издержек Учетный номер издержек Набор работ Набор работ Набор работ Учетный номер издержки. т. д.

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

"М" - материалы,

"И" - инженеры.

Если проект небольшой, можно использовать целые числа. А вот пример из более крупного и сложного проекта;

3R-237A-P2-33.6,

где

3R обозначает объект,

237А - высоту и территорию,

Р2 - трубу диаметром 2 дюйма;

33.6 - номер набора работ.

Подсчет затрат и разработка смет

Типичные статьи затрат для проекта:

Прямые затраты: Труд;Материалы;Оборудование;Иные затраты. Накладные расходы проекта. Общие и административные накладные расходы.

Вывод

СРРПЭ не дает возможности проекту полностью попасть под влияние организационной функции или финансовой системы.

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

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

© INTUIT.ru, 2003-2010. Все права защищены.

INTUIT.ru::Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий http://www.INTUIT.ru Основы управления проектами 2. Лекция: Разработка сетевого графика проекта: версия для печати и PDA

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

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

Сетевой график раскрывает внутренние связи проекта и служит основой для календарного планирования работ и использования оборудования.

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

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

От набора работ к сетевому графику

Сетевой график строится при помощи прямоугольников (блоков) и стрелок.

На рис. 2.1 блок обозначает операцию и стрелка показывает подчиненность операций и направленность хода выполнения проекта.

Рис. 2.1. Развертка сетевых графиков

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

Наборы работ используются для разработки детального сетевого графика для руководителей первого уровня (см. уровень 3 "Планы" на рис. 2.1).

Подробные графики двух проектов для руководителей отделов (уровень 2) могут быть объединены в более агрегированную форму и, далее, могут быть сведены к самому общему виду, необходимому для руководителя проекта, высшего руководства и клиента.

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

Первое, что нужно сделать для разработки сетевого графика проекта, определить набор работ.

Рис. 2.2 показывает часть структурированного набора работ и как информация используется для разработки сетевого графика.

Рис. 2.2. Перевод наборов работ в сетевой график

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

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

Рис. 2.2 показывает, как наборы работ используются для разработки сетевого графика проекта. Использование наборов работ можно отследить при помощи специальной системы кодирования. Например, в операции А используется рабочий пакет D-1-1 и D-1-2 (спецификация и документация), тогда как операция C использует рабочий пакет S-22-1. Управляющий проектом дает оценку времени выполнения всей операции, исходя из времени на выполнение отдельных работ в наборе. Например, выполнение операции В (прототип 1) потребует 5 недель; операции К (тестирование) -3 недели. После расчета начала и окончания выполнения операций менеджер может определить необходимые ресурсы и составить поэтапный бюджет проекта (с датами).

Конструирование сетевого графика проекта

Терминология

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

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

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

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

Операция слияния. Это операция, которая имеет более одной непосредственно предшествующей ей операции.

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

Путь. Последовательность связанных, взаимозависимых операций.

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

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

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

Два подхода к разработке сетевых графиков

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

подход с обозначением операций в узлах (блоках) графика - ОУ;

подход с обозначением операций на стрелках графика - ОС.

На практике первый метод - ОУ - используется значительно чаще и далее излагается именно этот метод.

Основные правила разработки сетевого графика

При разработке сетевого графика целесообразно придерживаться следующих 8 правил:

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

Принципы построения и анализа сетевых графиков типа "ОУ"

Рис. 2.3 дает несколько типичных конструкций сетевого графика, построенного этим методом ОУ.

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

Зависимость между операциями показывается на графике стрелками между прямоугольниками (блоками).

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

На практике операциям соответствуют определенные номера и краткое описание.

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

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

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

Рис. 2.3 (А) дает пример того, какие действия должны выполняться после того, как что-то уже сделано. Такой график показывает менеджеру проекта, что операция А должна быть выполнена до начала операции В, а операция В должна быть завершена до начала операции С.

Рис. 2.3. Типичные конструкции сетевого графика, построенного методом ОУ

Рис. 2.3(В) показывает, что операции Y и Z не могут быть начаты, пока не завершена операция X. Этот рисунок также показывает, что операции Y и Z могут происходить параллельно или одновременно, по желанию менеджера, но это не обязательное условие. Например, заливка бетоном дороги (операция Y) может происходить во время процесса укладки газона (операция Z), но уборка территории (операция X) должна быть завершена до начала операций Y и Z. Операции Y и Z считаются параллельными.

Рис. 2.3(С) показывает, что операции J,K,L при желании могут происходить одновременно, а операция М не может быть начата, пока операции J,K,L не будут завершены. Операции J, К, L параллельны.

В рис. 2.3(D) операции Y и X параллельны и могут происходить одновременно; операции Z и АА также параллельны. Но операции Z и АА нельзя начинать, пока обе операции X и Y не завершены.

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

Информация для упрощенной сети проекта нового бизнес-центра дана в табл. 2.1.

Таблица 2.1. Информация для сетевого графика Бизнес-центр Колла Операция Описание Предшествующая операция А Утверждение приложения Нет В Планы конструирования А С Изучение трафика А D Проверка наличия службы А Е Отчет персонала В, С F Утверждение на комиссии В, C, D G Ожидание работ F Н Включение в работу E,G

Операции А (одобрение заявки) ничего не предшествует, следовательно, она является первым блоком, который нужно нарисовать. Далее, отметим, что операциям В, C, и D (планы строительства, изучение движения и наличия рынка услуг) предшествует операция А

Рис. 2.4. Сетевой график разработки бизнес-центра Колла

Мы рисуем три стрелки и соединяем их с операциями В, C, и D. Этот сегмент показывает руководителю проекта, что операция А должна быть завершена до начала операций В, C и D. После завершения А, операции В,C, и D могут при желании проходить параллельно. рис. 2.4 показывает сеть полностью со всеми операциями.

Оценка начала и окончания работ с помощью сетевого графика

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

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

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

Процесс расчета параметров сетевого графика

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

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

Прямой анализ - Определение ранних сроков начала операций

Как скоро может начаться операция? (ранний старт - ES) Как скоро она может закончиться? (ранний финиш- EF) Как скоро может быть завершен проект в целом? (предполагаемое время- ТЕ)

Обратный анализ - Определение поздних сроков завершения операций

Каковы самые поздние сроки начала операции? (позднее начало -LS) Каковы самые поздние сроки завершения операции? (позднее окончание - LF) Какие операции составляют критический путь (СР)? Это самый длинный путь, при задержке выполнения операций на этом пути задерживается выполнение проекта. На какое время может быть задержано выполнение операции? (резерв времени - SL)

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

Прямой анализ - определение ранних сроков начала операций

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

По мере продвижения по любому из путей производится добавление времени выполнения операций. Самый длинный путь показывает время завершения проекта в целом и называется критическим путем (СР).

В табл. 2.2 представлено время операций в рабочих днях для проекта бизнес-центра Колла.

На рис. 2.5 показана система с оценкой продолжительности операций, которую вы можете видеть в блоке.

Например, операция А имеет продолжительность 5 дней, операция G-170 рабочих дней.

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

Рис. 2.5. Сетевой график типа ОУ для проекта создания бизнес-центра Колла Таблица 2.2. Информация для сетевого графика Бизнес-центр Колла Операция Описание Предшествующая операция Время операции А Утверждение приложения нет 5 В Планы конструирования А 15 С Изучение трафика А 10 D Проверка наличия службы А 5 Е Отчет персонала В, С 15 F Одобрение комиссии В, C, D 10 G Ожидание работ F 170 Н Включение в работу Е, G 35

В нашем примере, ранний срок начала первой операции (операция-А) это 0. Это время проставляется в верхнем левом углу блока операции А (рис. 2.6).

Самое раннее окончание операции А это 5 (ES + Dur или 0 + 5 = 5).

Далее мы видим, что операция А предшествует операциям B, C, D.

Следовательно, самое раннее время начала этих операций - это момент завершения операции А, 5 рабочих дней.

На рис. 2.6 можно видеть, что операции В,С и D могут начаться в момент завершения операции А, и поэтому все они имеют раннее начало (ES) 5.

Используя формулу ES + Dur = EF, раннее время завершения этих операций - В, C, D -(EF) будет, соответственно, 20, 15, и 10.

Рис. 2.6. Прямой анализ сетевого графика для проекта создания бизнес-центра

Какое же тогда будет раннее время начала (ES) для операции Е, которая является операцией слияния?

Это будет 15 или 20? Ответ - 20, так как все операции, непосредственно предшествующие операции Е (В и С) должны быть завершены до начала операции Е. Поскольку для завершения операции В требуется более продолжительное время, она и определяет раннее начало (ES) операции Е.

Тот же процесс используется для определения ES для операции F. Ей предшествуют операции В, C, и D. Операция В является определяющей для времени раннего окончания (EF), которой требуется больше времени (20 против 15 и 10), чем операциям (В, C, и D), непосредственно предшествующим операции F.

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

Вы добавляете время операции на каждом шаге анализа (ES + Dur = EF) Вы переносите раннее завершение (EF) предшествующей операции до следующей, у которой оно же становится временем раннего начала (ES), если только Последующая операция не является операцией слияния. В этом случае вы выбираете самое большое по значению время раннего окончания (ЕЕ) среди всех непосредственно предшествующих операций.

В нашем примере на рис. 2.6 ЕF для операции F (30) проводится до операции G, где становится ее ES (30).

Мы видим, что операция Н является операцией слияния и, следовательно, необходимо найти самое большое по значению EF у непосредственно предшествующих ей операций (Е и G). В этом случае выбор происходит между временем EF 35 и 200; выбор ES операции Н 200 EF для операции Н (235) становится самым ранним расчетным временем (ТЕ), когда проект может быть завершен в целом.

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

Обратный анализ - определение поздних сроков завершения операций

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

Каждый раз, выполняя шаг назад к началу сетевого графика, необходимо вычитать время рассматриваемой операции из общей продолжительности проекта в целом, с тем, чтобы определить сроки ее самого позднего возможного начала (LS) и окончания (LF) выполнения. За исходную временную точку при выполнении обратного анализа выбирается время позднего окончания самой последней операции проекта. В этой операции данное время совпадает с временем раннего окончания ее выполнения (EF) (или в случае нескольких завершающих операций, операции с самым большим (EF)). В некоторых случаях имеются установленные крайние сроки продолжительности проекта, тогда будут использоваться именно эти сроки. Предположим, что мы можем принять EF предполагаемого окончания проекта (ТЕ) равным 235 рабочим дням. LF для операции Н становится 235 рабочих дней (EF ~ LF) (см. рис. 2.7).

Рис. 2.7. Обратный анализ сетевого графика для проекта создания бизнес-центра

Обратный анализ похож на прямой. Выполняя его, следует помнить три вещи:

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

Давайте применим эти правила к нашему примеру с бизнес-центром Колла. Начинаем с операции Н (включение в работу) и ее LF в 235 рабочих дней, LS для операции Н оказывается равным 200 рабочих дней (LF - Dur = LS или 235 - 35 = 200).

LS для операции Н становится LF для операций Е и G. LS для операций Е и G становится соответственно 185 (200 - 15 = 185) и 30 рабочих дней (200 - 170 = 30).

LS для операции G становится LF для операции F, и ее LS становится 20.

Здесь мы видим, что операции В и C являются операциями дробления, которые связаны с операциями Е и F. Поздний финиш для операции В контролируется LS операций Е и F. LS для операции Е - 185 дней и для операции F - 20 дней. Идите по стрелке назад от операций Е и F к операции В.

Отметим, что время LS для операций Е и F помещено в правый блок, и вы можете выбрать наименьшее время - 20 дней.

Заключительная операция В может быть завершена за 20 дней; в противном случае выполнение операции F задержится, задержится и выполнение проекта.

LF для операции C идентично операции В, поскольку она также определяет LS операций Е и F.

Операция D просто получает свое позднее окончание (LF) от операции F.

Вычислив LS (LF - Dur = LS) для операций В, C, D, мы можем определить LF для операции А, которая является операцией дробления.

Окончание операции А определяется операцией В, которая является наименьшим LS для операций В, С и D.

Так как LS для операции В составляет период времени 5, LF для операции А - 5, и ее LS - период времени - 0.

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

Определение резервов времени

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

Полный простой или колебание операции представляет разницу между LS и ES (LS - ES = SL) или между LF и EF (LF - EF = SL).

Например, простой для операции C - 5 дней, для операции D - 10 дней и для операции G - 0 (см. рис. 2.8).

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

После вычисления простоя для каждой операции легко определить критический путь. Когда LF = EF для конечной операции проекта, критический путь можно определить, как те операции, у которых LF = EF или простой = О (LF - EF = 0 )(или LS - ES = 0 ).

Рис. 2.8. Сетевой график для проекта создания бизнес-центра с указанием резервов времени выполнения операций

Практика

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

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

Критический путь - это путь, который имеет наименьший простой в целом.

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

А если это так, то простой на критическом пути будет не нулевым, а будет равен разнице между EF проекта и установленным LF последней операции проекта. Например, если EF для проекта - 235 дней, а установленный LF или плановый срок - 220 дней, все операции критического пути будут иметь простой минус 15 дней.

Конечно, это приведет к позднему старту " -15 дней" для первой операции проекта.

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

На рис. 2.8 критический путь показан в виде стрелок и блоков - операций А, В, F, G и Н. Отставание одной из этих операций приведет к отставанию в выполнении проекта на то же количество дней.

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

Свободный резерв

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

Свободный резерв некоторой операции определяется, как разница между EF этой операции и ES последующей операции.

Свободный резерв никогда не может быть отрицательным.

Только операции в конце цепи операций (обычно там, где есть операции слияния) могут иметь свободный резерв.

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

Как используются результаты прямого и обратного анализа сетевого графика

Что означает для руководителя проекта резерв времени выполнения операции D в 10 дней?

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

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

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

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

Ошибки сетевой логики

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

Одно из правил гласит, что заявления типа "если испытание прошло успешно, стройте прототип, если неудачно - разработайте проект заново" не допускаются.

Сетевой график-- это не дерево решений; это план проекта, который должен быть осуществлен.

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

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

Рис. 2.9 показывает нелогичную петлю. Наличие таких петель привело бы к постоянному повторению пути.

Рис. 2.9. Петля, нарушающая логику построения сетевого графика

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

Использование задержек (лагов)

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

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

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

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

Отношения типа "от конца к началу".

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

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

Рис. 2.10. Отношения "от конца к началу"

Лаги в отношениях "от конца к началу" часто используются при отображении операций, связанных с заказами ресурсов. Например, может потребоваться 1 день для того, чтобы сделать заказ, но 19 дней, чтобы дождаться его исполнения. Использование отношений "от конца к началу" дает возможность иметь продолжительность операции - 1 день и лаг - 19 дней. Такой подход увязывает стоимость операции только с размещением заказов, а не со стоимостью операции за 20 дней работы.

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

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

Отношения "от начала к началу". Альтернативой делению операций является использование отношений типа "от начала к началу". Типичные отношения "от начала к началу" показаны на рис. 2.11. На рис. 2.11А показаны отношения старт-старт с нулевым лагом, тогда как на рис. 2.11В показаны те же самые отношения с лагом 5 единиц времени.

Рис. 2.11. Отношения "от начала к началу"

На рис. 2.11В операция Q не может начаться раньше, чем пройдет время в 5 единиц после начала операции Р.

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

Отношения "от конца к концу". Этот тип отношений можно видеть на рис. 2.12. Окончание одной операции зависит от окончания другой. Например, испытания не могут завершиться раньше, чем через 4 дня после завершения работ над прототипом.

Рис. 2.12. Отношения "от конца к концу"

Отношения "от начала к концу". Эти отношения представляют ситуацию, когда завершение одной операции зависит от начала другой операции. Например, документирование системы не может быть завершиться пока не пройдут три единицы времени после начала испытания (см. рис. 2.13).

Рис. 2.13. Отношения "от начала к концу"

Комбинация отношений задержки. Одна и та же операция может оказаться связанной с другой сразу несколькими отношениями задержки разных типов. Например, отладка программного обеспечения не может начаться, пока не пройдут две единицы времени после начала написания кода программы. Кодирование же должно завершиться за 4 единицы времени до окончания отладки (см. рис. 2.14).

Рис. 2.14. Комбинация отношений задержки

Операции растяжки

Другим распространенным приемом при построении сетевых графиков является включение подвесных операций.

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

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

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

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

Рис. 2.15 дает пример включения подвесной операции в сетевой график. Продолжительность этой операции определяется ранним началом операции В и ранним окончанием операции F, то есть разницей между 13 и 5 или 8 единицами времени. Продолжительность подвесной операции изменится, если любые ES или EF в цепочке охватываемых ею операций изменятся.

Рис. 2.15. Операция растяжки

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

Выводы

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

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

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

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

Использование лагов может привести к тому, что начало или конец операции могут стать критическими.

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

Вопросы для повторения

Чем отличается структура распределения работ от сетевого графика проекта? Как связаны структура распределения работ и сетевой график проекта? Зачем надо разрабатывать структуру распределения работ? Почему бы не перейти сразу же к построению сетевого графика, минуя структуру распределения работ? Почему знание резервов времени имеет значение для менеджера проекта? Почему при построении сетевых графиков иногда пользуются отношениями задержки? Что такое подвесная операция и когда она используется? © INTUIT.ru, 2003-2010. Все права защищены.

INTUIT.ru::Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий http://www.INTUIT.ru Основы управления проектами 3. Лекция: Планирование ресурсов: версия для печати и PDA

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

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

Проблема

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

Если к нашим находящимся в работе или запланированным проектам добавляют новый проект, выполнение какого из них может быть задержано?Реальны ли установленные даты?Какие ресурсы имеют приоритет?Соответствуют ли имеющиеся людские ресурсы и/или оборудование выполнению нового проекта?Где критический путь? Существуют ли непредвиденные зависимости?Если создается простой, то каков риск опоздания с выполнением проекта?Будут ли привлечены подрядчики со стороны?

Система календарного планирования проекта должна способствовать нахождению быстрых ответов на эти вопросы.

Сетевые графики первоначально строятся без оценки наличия ресурсов.

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

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

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

Исследование более 50 проектов показало, что продолжительность планирования сети проекта увеличилась на 38%, когда планировались ресурсы.

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

Типы ограничении проекта

Технические или логические ограничения

Технические ограничения связаны с последовательностью, в которой должны выполняться операции проекта и показаны на рис. 3.1.А.

Сеть проекта для каркаса дома должна отражать последовательность трех операций:

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

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

проектирования, кодирования, испытания в сети.

Рис. 3.1. Примеры ограничений

Ограничения на количество ресурсов

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

Потенциал для конфликта ресурсов несут параллельные операции.

Предположим, что вы занимаетесь планированием приема по случаю бракосочетания, который состоит из 4 операций:

план,заказ оркестра,украшение зала и закупка легкой закуски.

Для выполнения каждой операции требуется один день.

Нет технических причин или зависимости одной операции от другой (см. рис. 3.1.B ).

Однако, если все операции будет выполнять один человек, ограничение на количество ресурсов потребует, чтобы операции выполнялись последовательно или сериями. (см. рис. 3.1. С ).

Зависимость ресурсов имеет приоритет над технологической зависимостью, но не нарушает ее;

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

Виды ограничений на количество ресурсов

Люди

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

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

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

Материалы

Задержка в выполнении многих проектов часто объясняется нехваткой материалов.

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

Оборудование

Очень часто оборудование не рассматривают, как ограничение.

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

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

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

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

Текущие активы

В некоторых проектах текущие активы рассматриваются как ресурс, поскольку они ограниченны.

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

Такая ситуация связана с проблемой движения денежной наличности.

Классификация проблем календарного планирования

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

Самый простой способ проверить тип ограничения проекта - это задать вопрос: "Если наступление критического момента откладывается, потребуются ли дополнительные ресурсы, чтобы снова войти в график?"

Если ответ положительный, то проект ограничен по времени, если нет, то проект ограничен по количеству ресурсов.

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

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

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

Исходные положения

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

Второе, - уровень используемых для операции ресурсов нельзя изменить.

Эти ограничивающие допущения не существуют на практике, но они упрощают процесс изучения.

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

Проекты, ограниченные по времени

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

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

Все методы выравнивания приводят к отсрочке исполнения некритических операций для снижения пика потребностей и восполняя их нехватку.

При демонстрации этого примера будет использован только один тип ресурсов (например, плотники); в рамках этого типа все ресурсы взаимозаменяемы.

На рис. 3.2 представлен пример сети, ES графика потребности в ресурсах и график использования ресурсов.

Затемненные области на графике потребности представляют границы календарного графика для каждой операции.

Рис. 3.2A. Ограниченная по времени сеть

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

Изучение ES графика загрузки ресурса показывает, что только две операции имеют простой, который можно использовать для сокращения пика - операции B и D.

Любая из этих операций может быть задержана, чтобы сократить пик потребности в ресурсах от 5 до 4, используя 2 единицы времени простоя. Выбор, очевидно, будет сделан в пользу операции, которая имеет наименьший риск опоздания (вероятно, операция D, поскольку она имеет наибольший простой).

Схема загрузки ресурсов при раннем старте (ES) ID RES DUR ES LF TS 0 1 2 3 4 5 6 7 8 9 10 11 12 A 2 2 0 2 0 2 2 B 2 6 2 10 2 2 2 2 2 2 2 C 2 4 2 6 0 2 2 2 2 D 1 2 2 10 6 1 1 E 1 2 6 10 6 1 1 F 1 4 6 10 0 1 1 1 1 G 1 2 10 12 0 1 1 Общая загрузка ресурсов 2 2 5 5 4 4 4 4 1 1 1 1

Рис. 3.2B. Ограниченная по времени сеть

На рис.3.3А показаны результаты задержки операции B.

Рис. 3.3А. График выравнивания ресурсов. Результаты задержки операции В

Рис. 3.3B. Показаны результаты задержки операции D

На рис.3.3В показаны результаты задержки операции D.

Рис. 3.3C. График выравнивания ресурсов. Результаты задержки операции D

Обратите внимание на различие в графиках ресурсов. Важным моментом является то, что ресурсы, необходимые на время существования проекта, были сокращены с 5 до 4 (20%) и использование ресурсов возросло с 57% [необходимые 34 единицы ресурсов в целом (5х12)] до 71% [34/(4x12)].

Кроме того, график был выровнен, что означает облегчение в управлении,

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

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

Стремление слишком сильно выровнять график ресурсов рискованно. Тогда каждая операция становится критической.

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

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

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

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

Проблема составления календарного графика ресурсов представляет большую комбинаторную проблему.

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

Альтернативным подходом к проблеме было использование эвристического (приближенного метода) для решения больших комплексных проблем.

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

Ниже приводится простой пример эвристического подхода.

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

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

Минимум резерва времени начала выполнения операции. Наименьшая продолжительность выполнения операции. Наименьший порядковый номер операции.

Наиболее часто применяется метод распараллеливания операций.

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

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

Если в пятом периоде должны начаться 3 операции (т.е. они имеют тот же ES ) и требуют таких же ресурсов, то первой операцией на графике будет операция с наименьшим резервом времени (применяем правило 1).

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

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

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

В последующие периоды процедуpa повторяется до тех пор, пока не будет составлен график всего проекта.

Обратимся к рис. 3.4.

Период Действие 0-1 Приемлема только операция A. Она потребует 2 ресурса. Внесите операцию A в график 1-2 Нет приемлемых операций для внесения в график 2-3

Операции В, С, D приемлемы для внесения в график. Операция С имеет наименьший резерв времени (0) - примените правило 1.

Внесите операцию С в график.

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

Отложите операцию B. Скорректируйте ES =3, резерв =1.

Следующая приемлемая операция D, для ее выполнения требуется 1 ресурс.

Внесите операцию D в график

----------------------------------см.рис. 3.5-----------------------------------------------

3-4 Операция B приемлема, но превышает лимит 3 ресурсов общего фонда. Задержите операцию B. Скорректируйте ES = 4, резерв =0 4-5 Операция B приемлема, но превышает лимит 3 ресурсов общего фонда. Задержите операцию B. Скорректируйте ES = 5, резерв = -1. Задержите операцию G. Скорректируйте ES = 11, резерв = -1 5-6 Операция B приемлема, но превышает лимит 3 ресурсов общего фонда. Задержите операцию B. Скорректируйте ES = 6, резерв = -2. Задержите операцию G. Скорректируйте ES = 12, резерв = -2 6-7

Операции B,E,F приемлемы с резервами времени выполнения -2, 2, 0 соответственно.

Внесите операцию B в график (правило 1).

Так как операция F имеет резерв 0, она следующая приемлемая операция.

Внесите операцию F в график (правило 1).

Лимит ресурсов 3 достигнут.

Задержите операцию E. Скорректируйте ES = 7, резерв = 1

7-8

Лимит достигнут. Ресурсов в наличии нет.

Задержите операцию E. Скорректируйте ES = 8, резерв = 0

8-9

Лимит достигнут. Ресурсов в наличии нет.

Задержите операцию E. Скорректируйте ES = 9, резерв = -1

9-10

Лимит достигнут. Ресурсов в наличии нет.

Задержите операцию E. Скорректируйте ES = 10, резерв = -2

10-11

Операция E приемлема.

Внесите операцию E в график.

(Заметьте, операция F не имеет простоя, так как нет ресурсов в наличии - 3 максимум)

11-12 Нет приемлемых операций 12-13

Операция G приемлема.

Внесите операцию G в график

увеличить изображение

Рис. 3.4. График ресурсов, подчиненных ограничению в периоды 2-3

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

В сети на рис. 3.5 на графике календарного планирования указана новая дата в 14 единиц времени против продолжительности в 12 единиц времени проекта, подчиненного ограничениям по времени.

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

Сравните резервы времени для каждой операции на рис. 3.4 и рис. 3.5; резервы времени значительно сократились.

увеличить изображение

Рис. 3.5. График ресурсов, подчиненных ограничению в периоды 5-6

На рис. 3.6 показана другая сеть проекта, когда используются три различных типа ресурсов (A, B и С); общий фонд каждого типа состоит из 2 ресурсов.

Рис. 3.6. Первоначальный план сети

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

Ниже сетевого графика приводится график потребности в ресурсах. Время ("план") и ресурсы показаны внизу на графике 3.6.

Время, которое ограничивает критический путь, составляет 3, 5, 8 и 11, продолжительность проекта составляет 27 единиц времени.

Ресурсы, которые ограничивают выполнение критических операций, составляют 1, 4, 5, 7, 8 и 10 при продолжительности проекта 20 единиц времени.

Операции 3 и 11 уже не являются критическими и имеют резервы времени. Операции 4, 5, 7 и 8 уже являются не параллельными, а последовательными. Резервы времени сократились. Ресурсы A, B, и С в какой-то точке проекта являются критическими.

Влияние календарного планирования ресурсов, подлежащих ограничениям

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

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

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

И, наоборот, параллельные операции могут стать последовательными.

Распараллеливание

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

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

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

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

На рис. 3.7 можно видеть характер проблемы дробления. Первоначальная операция разбита на три отдельных операции: A, B и С.

Рис. 3.7. Структура задач

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

Метод критической цепи

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

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

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

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

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

Элиаху Голдрэт выступает за альтернативный подход управления простоями.

Он считает, что к своим оценкам люди вполне естественно добавляют время (на всякий случай).

Считается, что время оценки выполнения операции в срок или раньше оправдывается лишь в 80-90% случаев.

Следовательно, среднее время (50/50) преувеличено примерно на 30-40%. Например, по оценке программиста существует шанс 50/50, что он сможет завершить операцию за 5 дней. Однако, чтобы обеспечить успех и застраховаться от потенциальных проблем, он добавляет два дня для страховки и сообщает, что потребуется 7 дней для завершения задачи. В этом случае среднее(50/50) время преувеличено на 40%.

Эта ситуация создает интересный парадокс. Почему при наличии тенденции к преувеличению времени продолжительности операции многие проекты отстают от графика? Голдрэт предлагает несколько объяснений этому явлению.

Первое - вся работа распределена во времени. Зачем спешить и стараться выполнить работу сегодня, если она должна быть выполнена завтра?

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

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

Голдрэт предлагает решить проблему превышения времени проекта, используя "истинную 50/50" оценку времени выполнения операции (а не оценку, когда шанс выполнения досрочно составляет 80-90%). Он предлагает ввести "временные буферы" или время подстраховки только в случаях возникновения потенциальных проблем.

Буферы времени вводятся в сеть для соблюдения трех условий:

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

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

Сторонников у метода С-С в планировании проекта сегодня немного, но у него есть перспективы. Например, Harris Semiconductor сумел построить новые автоматизированные установки по производству тонких кристаллических пластин за 13 месяцев, используя метод С-С, тогда как обычные сроки составляют от 26 до 36 месяцев. Авиационная промышленность в Израиле использовала метод С-С для сокращения времени технического обслуживания самолета с двух месяцев до двух недель.

Успешное выполнение проекта требует, чтобы его участники сократили свою оценку времени, которое выделено "на всякий случай", и использовать время "50/50".

Выгода от календарного планирования ресурсов

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

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

Альтернативы стоимости времени также могут быть пересмотрены.

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

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

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

Распределение работ по проекту

Человек или ресурс?

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

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

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

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

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

В рамках проектной деятельности под "командой" понимается организационная структура проекта, создаваемая на период осуществления всего проекта либо одной из фаз (стадий) его жизненного цикла.

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

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

Задачей руководства команды проекта является выработка политики и утверждение стратегии проекта для достижения его целей.

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

Задачей КУП является исполнение всех управленческих функций и работ в проекте по ходу его осуществления.

Команда менеджмента проекта (КМП) - организационная структура проекта, возглавляемая управляющим (главным менеджером) проекта и создаваемая на период осуществления проекта или одной из стадий его жизненного цикла.

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

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

Одним из критериев выделения нескольких команд в проекте является целесообразность разделения ответственности между различными участниками и персоналом проекта по уровням принятия решений (см. рис. 3.8).

Рис. 3.8. Уровни принятия решений различными командами проекта

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

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

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

В табл. 3.1 показана RM для изучения возможностей рынка.

R - ответственный

S - помогает

Команда проекта

Таблица 3.1. Матрица ответственности (RM) для проекта изучения возможностей рынка Задача Ричард Дэн Дэйв Линда Элизабетт Определение целевых покупателей R S S Разработка проекта опросного листка R S S Экспериментальная проверка опросного листка R S Окончательный вариант опросного листка R S S с Тираж опросного листка R Подготовка адресов рассылки R Рассылка опросного листка R Получение и обработка ответов R S Ввод ответов в компьютер R Анализ результатов R S S Подготовка проекта отчета S R S S Подготовка окончательного отчета R S

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

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

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

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

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

Список

Ответственность Поддержка Консультация Уведомление Одобрение

Организация

Таблица 3.2. Матрица ответственности (RM) для проекта, управляемого компьютером ленточного конвейера Промежуточные этапы работы Проект Разработка Документация Сборка Испытание Закупка Гарантия качества Производство Архитектурный проект 1 2 2 3 3 Технические характеристики оборудования 2 1 2 3 Спецификация ядра программы 1 3 3 Спецификация обслуживающих программ 2 1 3 Дизайн оборудования 1 3 3 3 Дисководы 3 1 2 Управление памятью 1 3 3 Документация оперирующей системы 2 2 1 3 Прототипы 5 4 1 3 3 3 4 Комплексные испытания 5 2 2 1 5 5

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

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

При этом следует учитывать несколько факторов.

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

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

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

Управление трудовыми ресурсами проекта и менеджмент человеческих ресурсов проекта

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

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

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

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

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

Интегрированная культура команды проекта

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

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

Типы культур описываются следующими основными характеристиками:

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

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

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

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

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

Общее отставание от графика. Поскольку ресурсы проектов общие, отставание одного проекта может сказаться на отставании от графика других проектов. Неэффективное использование ресурсов. Поскольку проекты имеют различные графики и потребности, существуют точки пика и минимума в потребностях ресурсов. Например, у фирмы есть 10 электриков, которые могут удовлетворить спрос во время пика, а обычно требуется только 5 электриков. Нехватка ресурсов. Задержки выполнения графика могут увеличиваться в результате нехватки критических ресурсов, необходимых для осуществления нескольких проектов.

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

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

Новые графики проектов основываются на прогнозируемой оценке наличия ресурсов.

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

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

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

И, наконец, многие компании прибегают к использованию внешних ресурсов (аутсорсингу) как средству решения проблем обеспечения ресурсами.

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

Выводы

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

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

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

Любое отклонение ресурсов от плана и графика и воздействие этого на выполнение проекта может быть обнаружено своевременно.

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

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

Вопросы для повторения

Как связаны календарное планирование ресурсов и приоритет проекта? Каким образом календарное планирование ресурсов снижает гибкость в управлении проектом? Назовите 6 причин, по которым календарное планирование ресурсов является важной задачей. Как можно использовать аутсорсинг, чтобы смягчить 3 наиболее общих проблемы, связанных с календарным планированием ресурсов нескольких проектов? Объясните риски, связанные с выравниванием ресурсов, сокращением или срочным выполнением проектов и установлением сроков продолжительности проекта или с необходимостью идти по графику при выполнении проекта. © INTUIT.ru, 2003-2010. Все права защищены.

INTUIT.ru::Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий http://www.INTUIT.ru Основы управления проектами 4. Лекция: Управление временем выполнения проекта и отклонениями от плана : версия для печати и PDA

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

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

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

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

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

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

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

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

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

Такая практика почти всегда приводит к более высокой стоимости проекта, чем когда мы проводим тщательное планирование.

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

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

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

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

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

Процедура сокращения времени

Объяснение издержек проекта

Общий характер издержек проекта показан на рис. 4.1.

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

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

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

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

Рис. 4.1. График стоимости времени выполнения проекта

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

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

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

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

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

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

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

Сокращение времени выполнения проекта

Методы сокращения времени выполнения проекта (операций критического пути) ограничены.

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

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

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

Закон Брукса: дополнительная рабочая сила для опаздывающей программы проекта задержит его выполнение еще больше. Фредерик Брукс сформулировал этот принцип на основе своего опыта руководителя проекта программного обеспечения для IBM System/360 в начале 1960-х.

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

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

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

Наконец, еще одним методом выполнения работ в срок является сокращение размеров проекта.

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

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

Построение графика стоимости времени выполнения проекта

При построении графика стоимости времени выполнения проекта необходимо выполнить три следующих основных шага:

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

Затем используется график для сравнения стоимости дополнительных альтернатив и преимуществ. Далее дается подробное описание этих шагов.

Определение операций для сокращения времени их выполнения

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

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

Сокращение времени выполнения операции называется авралом (crashing).

Кратчайшее время, за которое операция реально может быть выполнена, называется ее предельным временем (crash time).

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

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

На рис. 4.2 изображен график стоимости времени выполнения гипотетической операции.

Рис. 4.2. График стоимости времени выполнения операции

Обычное время выполнения операции - 10 единиц и соответствующая стоимость - $ 400. Предельное время выполнения операции - 5 единиц и стоимость - $ 800.

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

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

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

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

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

Чем меньше угол наклона операции, тем меньше издержки на сокращение периода времени;

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

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

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

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

Упрощенный пример

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

Операция Наклон Максимально предельное время Прямые издержки Нормальные Срочные Время Стоимость Время Стоимость A 20 1 3 50 2 70 B 40 2 6 80 4 160 C 30 1 10 60 9 90 D 25 4 11 50 7 150 E 30 2 8 100 6 160 F 30 1 5 40 4 70 G 0 0 6 70 6 70 Общие прямые издержки $450

Рис. 4.3. Пример альтернативной стоимости времени

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

Например, операция D может быть сокращена с обычной продолжительности в 11 единиц времени до предельного времени в 7 единиц, или максимально на 4 единицы времени.

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

Операция A обведена кружком, поскольку является наименее дорогой.

Сокращение операции A на одну единицу времени сокращает продолжительность проекта до 24 единиц времени, но увеличивает общие прямые издержки до $ 470 ($ 450 + $ 20 = $ 470).

Рис. 4.3в отражает эти изменения. Продолжительность операции А сократилась до двух единиц времени; "х" показывает, что операция не может больше сокращаться.

Общие прямые издержки проекта продолжительностью в 23 единицы времени составят $ 495 (см. рис. 4.4a).

Рис. 4.4. Пример альтернативной стоимости времени (продолжение)

Схема проекта на рис. 4.4а теперь имеет два критических пути- A, C, F, G и A, D, F, G.

Сокращение продолжительности проекта до 22 единиц времени потребует сокращения продолжительности операции F, поэтому она обведена. Эти изменения показаны на рис. 4.4в . Общие прямые издержки для продолжительности в 22 единицы времени составят $ 525.

Это сокращение приведет к возникновению третьего критического пути - A, B, E, G; все операции критические. Наименее дорогостоящим методом сокращения продолжительности проекта до 21 единицы времени является комбинация обведенных операций C, D, E, стоимость которых соответственно $ 30, $ 25, $ 30, и увеличение общих прямых издержек до $610.

В табл. 4.1 представлены общие прямые издержки, общие косвенные издержки и общие издержки проекта.

Таблица 4.1. Сумма издержек по продолжительности Продолжительность проекта Прямые издержки Косвенные издержки Общие издержки 25 450 400 $850 24 470 350 820 23 495 300 795 22 525 250 775 21 610 200 810

Те же издержки внесены в рис. 4.5. На этом графике показано, что оптимальная стоимость продолжительности в 22 единицы времени - $ 775.

Рис. 4.5. График стоимости выполнения проекта

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

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

Практические соображения

Предельное время

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

Трудно объяснить, что означает предельное время. Что значит определение предельного времени как "минимального времени, в течение которого вы можете реально выполнить операцию"? Предельное время интерпретируют и понимают по-разному.

Расчет времени срочных операций

Иногда стратегия "поживем-увидим" является мудрым решением.

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

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

Линейность предположений

Этот простой метод подходит для большинства проектов.

Нижний уровень

Должен ли владелец проекта или руководитель проекта стремиться к оптимальной стоимости времени?

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

Сеть чувствительна, если существуют несколько критических или почти критических путей.

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

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

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

Существует положительная ситуация, когда переход к оптимальному времени может привести к реальной крупной экономии - это происходит, когда система не чувствительна.

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

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

Сценарии управления отклонениями

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

Управление отклонениями

Модели отклонений

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

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

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

Рис. 4.6. Области потерь

Рис. 4.7. Стратегии изменений в проекте

Манипулирование ресурсами

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

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

Увеличение интенсивности работ

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

Замена исполнителя

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

Материальное стимулирование

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

Привлечение дополнительных исполнителей из штата компании

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

Привлечение субподрядчиков

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

Манипулирование временем

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

изменение сроков завершения работ; смещение вех проекта; увеличение общего срока завершения проекта.

Изменение сроков завершения работ

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

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

Смещение вех

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

Увеличение общего срока проекта

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

Манипулирование продуктом (качеством)

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

снижение качества продукта; замена продукта; исключение продукта.

Снижение качества продукта

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

Замена продукта

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

Исключение продукта

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

Выводы

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

Вопросы для повторения

Определите 5 косвенных издержек для достаточно сложного проекта. Почему эти издержки классифицируются как косвенные? Как руководитель проекта может использовать график стоимости проекта? Объясните. При сокращении продолжительности проекта вы должны избегать общих фондов. Почему? Сокращение продолжительности проекта повышает риск опоздания. Объясните. Возможно ли сократить критический путь и сэкономить деньги? Объясните, как. Почему важно учитывать косвенные издержки при анализе потенциальных альтернатив проекта? Чувствительные и нечувствительные сети должны рассматриваться по-разному в решении вопроса о сокращении проекта. Дайте подробное объяснение рисков, связанных с изменением каждого типа сети проекта. © INTUIT.ru, 2003-2010. Все права защищены.

INTUIT.ru::Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий http://www.INTUIT.ru Основы управления проектами 5. Лекция: Управление риском: версия для печати и PDA

Выявление и оценка риска в проекте. Выявление источников риска. Анализ и оценка риска. Анализ сценария (а): неколичественный. Анализ с использованием поправочных коэффициентов и допусков. Анализ смешанного типа. Реакция на риск. Снижение или сохранение риска. Переадресация риска. Участие в рисках. Планирование на случай непредвиденных обстоятельств. Риски, связанные с выполнением графика работ. Использование резервов времени. Авторитарно установленные сроки работы. Сжатие графиков проекта. Риски затрат.Зависимость время - затраты. Решение о движении наличности. Прогнозы окончательных затрат. Риски защиты цен. Технические риски. Создание резервов на случай непредвиденных обстоятельств. Сметные резервы. Резервы управления. Ответственность за проектные риски. Изменение методов управления контролем. Pert и pert-моделирование. Pert - метод оценки и проверки программ. Pert-моделирование

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

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

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

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

На рис. 5.1 представлена графическая модель дилеммы управления риском.

Рис. 5.1. График возможностей риска

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

Выявление и оценка риска в проекте

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

Основными составляющими процесса управления риском являются:

Выявление источников риска; Анализ и оценка риска; Определение реакции на риск; Планирование расходов в чрезвычайных обстоятельствах; Создание резервов на случай чрезвычайных обстоятельств.

Выявление источников риска

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

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

Среди поставленных вопросов могут быть такие:

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

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

Эффективным инструментом выявления рисков является СРРПЭ (структура разбиения работ по этапам).

Использование СРРПЭ снижает вероятность пропуска возможного риска

Существует множество источников проектных рисков.

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

Риски, зависящие от конкретного проекта, также не учитываются.

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

Для каждого выявленного риска должно быть определено следующее:

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

Анализ и оценка риска

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

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

Таблица 5.1. Матрица оценки риска Событие Вероятность Степень серьезности Трудность обнаружения Время Зависание системы Низкая Высокая Высокая Начало Жалобы пользователя Высокая Средняя Средняя После установки Плохая работа оборудования Низкая. Высокая Высокая Установка

Матрица оценки риска - это один из множества подходов к оценке риска.

Оценки бывают как субъективными, так и количественными.

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

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

Типичными количественными методами являются анализ коэффициентов, анализ вероятности и анализ чувствительности.

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

Анализ сценария (А): неколичественный

Это один из первых и наиболее распространенных методов.

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

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

Анализ с использованием поправочных коэффициентов и допусков

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

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

Коэффициент, как правило, является постоянной величиной.

Анализ смешанного типа

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

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

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

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

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

Реакция на риск

Варианты реакции на риски:

снижение или сохранение риска; переадресация риска; участие в рисках.

Снижение или сохранение риска

Обычно первой рассматриваемой альтернативой является снижение риска.

Пример проекта строительства моста является иллюстрацией снижения риска.

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

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

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

При оценке возможных рисков все внимание уделили доставке цемента с завода.

Цементовозы могли задержаться в пути или завод мог встать.

Такие риски могут привести к огромным затратам на переделку уже сделанного и отставанию от графика.

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

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

В некоторых случаях сознательно идут на сохранение риска.

Владелец проекта просто принимает риск как должное, так как возможность такого риска очень мала.

Переадресация риска

Переадресация риска другой стороне - дело достаточно обычное; переадресация не меняет риск.

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

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

Следовательно, фактор финансового риска добавляется к стоимости контракта.

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

Участие в рисках

Участие в рисках означает, что разные стороны принимают на себя части риска.

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

Планирование на случай непредвиденных обстоятельств

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

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

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

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

Проект (см. табл. 5.1) использован для демонстрации такой матрицы.

На первом этапе нужно определиться, как поступить - снизить, разделить, переадресовать или принять на себя риск.

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

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

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

Риск отказа оборудования переадресуется посредством выбора надежного поставщика программ.

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

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

Если пользователь будет по-прежнему недоволен, то отдел информационных систем выделит дополнительный персонал для помощи.

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

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

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

Таблица 5.2. Матрица реакций на риск Риск Принять, снизить, участвовать, переадресовать План на случай непредвиденных обстоятельств Импульс к применению Блокирование систем Снизить Замена ОС Все еще заблокирована через час Отказ пользователя Снизить Выделить дополнительный персонал для помощи Указание сверху Плохая работа (техническая неисправность) оборудования Переадресовать Заказать оборудование другой марки Замена не работает

Риски, связанные с выполнением графика работ

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

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

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

Управляющие-практики некоторыми своими решениями увеличивают риск. Далее в качестве примера будут рассмотрены две ситуации,

Авторитарно установленные сроки работы

По опыту известно, что сроки работ примерно над 80% проектов устанавливаются авторитарно.

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

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

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

Сжатие графиков проекта

Иногда, примерно в середине работы над проектом, возникает необходимость сократить время работы над ним.

Сокращение времени работы над проектом достигается сокращением одного или большего количества действий (операций) на критическом пути.

Сокращение времени выполнения пакета работ приводит к повышению прямых расходов.

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

Чем больше критических или почти критических операций, тем больше риск опоздать с завершением проекта.

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

Например, некоторые графики можно скорректировать, если выполнять операции параллельно или использовать лаговые отношения старт-старт.

Риски затрат

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

Зависимость время - затраты.

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

Например, если на разработку образца процесса уходит на 50% больше первоначально рассчитанного времени, то можно ожидать увеличения затрат.

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

Решение о движении наличности.

Некоторые решения, связанные с движениями наличности могут увеличить риски, связанные с графиками.

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

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

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

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

Прогнозы окончательных затрат.

Достаточно часто, когда проект выполнен на 20%, задают вопрос: "Насколько будет соблюдена смета по окончании проекта?"

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

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

Если реальные затраты превышают цифру, заложенную в смете, на 4%, то делают вывод о том, что все затраты превысят смету на 4%.

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

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

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

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

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

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

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

Из-за своей сложности этот метод широко не применяется.

Риски защиты цен.

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

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

Например, если инфляция находится на уровне 3%, некоторые управленцы набавляют 3% на все ресурсы, используемые для выполнения проекта.

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

Ценовые риски необходимо оценивать пункт за пунктом.

Технические риски

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

Что будет, если система или процесс не будут давать результатов?

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

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

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

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

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

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

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

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

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

На практике непредвиденные обстоятельства составляют от 1 до 10% в проектах, аналогичных предыдущим.

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

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

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

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

Сметные резервы

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

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

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

Величина резерва определяется при расчетах затрат на принятый план выхода из непредвиденных обстоятельств или план выхода из кризиса.

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

Если риска удается избежать, фонды возвращаются в резерв управления.

Резервы управления

Эти резервные фонды необходимы для покрытия крупных непредвиденных и потенциальных рисков и поэтому применяются к проекту в целом.

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

Они не зависят от сметных резервов и контролируются управляющим проектом и "владельцем" проекта.

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

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

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

Контроль за риском такого типа - вне сферы компетенции управляющего проектом.

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

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

В табл. 5.3 показаны расчеты для фонда непредвиденных обстоятельств, сделанные для гипотетического проекта.

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

Таблица 5.3. Расчет фонда непредвиденных обстоятельств (тыс. долл.) Наименование операции Основная смета Сметный резерв Проектная смета Дизайн 500 15 515 Код 900 80 980 Испытание 20 2 22 Всего 1420 97 1517 Резерв управления - - 50 Итого 1420 97 1567

Ответственность за проектные риски

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

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

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

В табл. 5.4 указаны самые распространенные категории рисков, типичные для проекта владелец/подрядчик; существуют также специфические проектные риски, но они не включены в эту таблицу.

Зачастую владелец и подрядчик имеют противоречащие друг другу цели - низкие затраты против качества.

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

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

Таблица 5.4. Разделение рисков Руководитель/управляющий проектом Подрядчик Инфляция Стихийные бедствия Изменение масштаба Технические 1. График 2. Затраты Совместно Безопасность Инновации - затраты и доходы

Изменение методов управления контролем

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

Большинство изменений можно разделить на три категории:

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

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

На практике большинство систем контроля над изменениями призваны выполнять следующие функции;

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

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

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

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

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

Система контроля над внесением изменений дает следующие преимущества:

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

Контроль над проектом во многом зависит от непрерывности процесса контроля над изменениями.

Выводы

Все управленцы понимают, что риски являются неотъемлемой частью проекта.

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

Ответственность за риски должна быть четко определена и документально оформлена.

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

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

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

PERT и PERT-моделирование

PERT - метод оценки и проверки программ

В 1958 г. Особый отдел Военно-морского флота и консалтинговая фирма Booze, Allen and Hamilton создали PERT (метод оценки и проверки программ) с целью разработки графика для более чем 3300 подрядчиков, работающих над проектом подводной лодки Поларис, для решения проблемы неопределенности в расчетах времени выполнения работ.

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

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

оптимистическое (наилучшее); средний показатель; пессимистическое (наихудшее).

Разработчики PERT для выражения продолжительности операции решили избрать аппроксимацию бета-распределения.

На рис. 5.2(А) представлено бета-распределение для продолжительности операции, отклоняющееся вправо, и оно представляет собой работу, которая имеет тенденцию отставать от графика.

Рис. 5.2. Операция и плотность распределения проекта

Распределение продолжительности проекта показано в симметрии на рис. А5-7 (В).

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

Средневзвешенное время операции рассчитывается по следующей формуле:

(5.1)

где t_e - средневзвешенное время операции;

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

b - пессимистическое время операции (1 шанс из 100, что при нормальных условиях операция будет закончена позже срока);

m - наиболее вероятное время операции.

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

Отклонения в оценках времени операции определяются при помощи следующих уравнений. Уравнение 5.2 представляет стандартное отклонение для операции.

(5.2) (5.3)

Уравнение 5.3 представляет стандартное отклонение для проекта.

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

Средняя продолжительность проекта (Т_Е) - это сумма всех средних показателей времени, отведенных на выполнение операций по критическому пути (сумма от t_e), и она следует нормальному распределению.

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

Уравнение 5.4 используется для расчета величины Z, приводимой в статистических таблицах (Z - количество стандартных отклонений от средней величины):

(5.4)

где Т_Е - продолжительность критического пути;

T_S - продолжительность работы по графику;

Z - вероятность (выполнения графика), определенная по статистической табл. 5.6.

Гипотетический пример использования метода PERT

Продолжительность операций и значение среднего отклонения представлены на табл. 5.5.

Таблица 5.5. Операция a m b Т_Е квадрат среднего отклонения 1-2 17 29 47 30 25 2-3 6 12 24 13 9 2-4 16 19 28 20 4 3-5 13 16 19 16 1 4-5 2 5 14 6 4 5-6 2 5 8 5 1

Сеть проекта представлена на рис. 5.3.

Рис. 5.3. Гипотетическая сеть

Прогнозируемый срок работы (Т_Е) представлен 64 единицами времени;

Критический путь - 1, 2, 3, 5, 6.

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

Например, какова вероятность завершения работы над проектом до указанного в графике времени (T_s) из 67?

Обычная кривая проекта будет такой как на рис. 5.4

Рис. 5.4. Возможная продолжительность проекта

Используя формулу для значения Z, можно рассчитать вероятность следующим образом:

По данным табл. 5.6 значение Z + 0,5 дает вероятность 0,69, что означает 69%-ную вероятность завершения работы над проектом на 67-ю единицу времени или ранее.

Таблица 5.6. Величина Z Вероятность Величина Z Вероятность -2,0 0,02 +2,0 0,98 -1,5 0,07 + 1,5 0,93 -1,0 0,16 +1,0 0,84 -0,7 0,24 +0,7 0,76 -0,5 0,31 +0,5 0,69 -0.3 0,38 +0,3 0,62 -0,1 0,36 +0,1 0,54

Вероятность выполнения проекта к периоду времени 60 рассчитывается следующим образом:

По табл. 5.6 значение Z - 0,67 дает вероятность 0,26, что означает около 26% вероятности завершения работы над проектом на 60-ю единицу времени или ранее.

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

PERT-моделирование

Для этой методики необходима компьютерная программа, моделирующая отпущенные на проект время, затраты и/или наличие ресурсов с использованием метода Monte Carlo Technique.

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

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

Вопросы для повторения

Если проект тщательно спланирован, проектные риски можно/нельзя устранить. Объясните. Возможность рисков и соответственный им рост затрат меняются на протяжении жизненного цикла проекта, Каково значение этого явления для управляющего проектом? Объясните, в чем разница между сметными резервами и резервами управления. Как связаны между собой структура распределения работы по этапам проекта и контроль над изменениями? Каковы возможные последствия неприменения процесса контроля над изменениями? Почему? Каким образом информация по PERT отличается от информации по СРМ? Как с помощью PERT рассчитать вероятность конкретной продолжительности выполнения проекта? Какие подходы лежат в основе этого метода? Почему на практике метод PERT используется редко? © INTUIT.ru, 2003-2010. Все права защищены.

INTUIT.ru::Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий http://www.INTUIT.ru Основы управления проектами 5. Лекция: Управление риском: версия для печати и PDA

Выявление и оценка риска в проекте. Выявление источников риска. Анализ и оценка риска. Анализ сценария (а): неколичественный. Анализ с использованием поправочных коэффициентов и допусков. Анализ смешанного типа. Реакция на риск. Снижение или сохранение риска. Переадресация риска. Участие в рисках. Планирование на случай непредвиденных обстоятельств. Риски, связанные с выполнением графика работ. Использование резервов времени. Авторитарно установленные сроки работы. Сжатие графиков проекта. Риски затрат.Зависимость время - затраты. Решение о движении наличности. Прогнозы окончательных затрат. Риски защиты цен. Технические риски. Создание резервов на случай непредвиденных обстоятельств. Сметные резервы. Резервы управления. Ответственность за проектные риски. Изменение методов управления контролем. Pert и pert-моделирование. Pert - метод оценки и проверки программ. Pert-моделирование

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

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

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

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

На рис. 5.1 представлена графическая модель дилеммы управления риском.

Рис. 5.1. График возможностей риска

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

Выявление и оценка риска в проекте

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

Основными составляющими процесса управления риском являются:

Выявление источников риска; Анализ и оценка риска; Определение реакции на риск; Планирование расходов в чрезвычайных обстоятельствах; Создание резервов на случай чрезвычайных обстоятельств.

Выявление источников риска

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

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

Среди поставленных вопросов могут быть такие:

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

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

Эффективным инструментом выявления рисков является СРРПЭ (структура разбиения работ по этапам).

Использование СРРПЭ снижает вероятность пропуска возможного риска

Существует множество источников проектных рисков.

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

Риски, зависящие от конкретного проекта, также не учитываются.

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

Для каждого выявленного риска должно быть определено следующее:

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

Анализ и оценка риска

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

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

Таблица 5.1. Матрица оценки риска Событие Вероятность Степень серьезности Трудность обнаружения Время Зависание системы Низкая Высокая Высокая Начало Жалобы пользователя Высокая Средняя Средняя После установки Плохая работа оборудования Низкая. Высокая Высокая Установка

Матрица оценки риска - это один из множества подходов к оценке риска.

Оценки бывают как субъективными, так и количественными.

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

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

Типичными количественными методами являются анализ коэффициентов, анализ вероятности и анализ чувствительности.

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

Анализ сценария (А): неколичественный

Это один из первых и наиболее распространенных методов.

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

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

Анализ с использованием поправочных коэффициентов и допусков

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

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

Коэффициент, как правило, является постоянной величиной.

Анализ смешанного типа

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

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

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

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

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

Реакция на риск

Варианты реакции на риски:

снижение или сохранение риска; переадресация риска; участие в рисках.

Снижение или сохранение риска

Обычно первой рассматриваемой альтернативой является снижение риска.

Пример проекта строительства моста является иллюстрацией снижения риска.

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

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

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

При оценке возможных рисков все внимание уделили доставке цемента с завода.

Цементовозы могли задержаться в пути или завод мог встать.

Такие риски могут привести к огромным затратам на переделку уже сделанного и отставанию от графика.

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

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

В некоторых случаях сознательно идут на сохранение риска.

Владелец проекта просто принимает риск как должное, так как возможность такого риска очень мала.

Переадресация риска

Переадресация риска другой стороне - дело достаточно обычное; переадресация не меняет риск.

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

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

Следовательно, фактор финансового риска добавляется к стоимости контракта.

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

Участие в рисках

Участие в рисках означает, что разные стороны принимают на себя части риска.

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

Планирование на случай непредвиденных обстоятельств

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

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

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

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

Проект (см. табл. 5.1) использован для демонстрации такой матрицы.

На первом этапе нужно определиться, как поступить - снизить, разделить, переадресовать или принять на себя риск.

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

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

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

Риск отказа оборудования переадресуется посредством выбора надежного поставщика программ.

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

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

Если пользователь будет по-прежнему недоволен, то отдел информационных систем выделит дополнительный персонал для помощи.

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

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

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

Таблица 5.2. Матрица реакций на риск Риск Принять, снизить, участвовать, переадресовать План на случай непредвиденных обстоятельств Импульс к применению Блокирование систем Снизить Замена ОС Все еще заблокирована через час Отказ пользователя Снизить Выделить дополнительный персонал для помощи Указание сверху Плохая работа (техническая неисправность) оборудования Переадресовать Заказать оборудование другой марки Замена не работает

Риски, связанные с выполнением графика работ

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

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

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

Управляющие-практики некоторыми своими решениями увеличивают риск. Далее в качестве примера будут рассмотрены две ситуации,

Авторитарно установленные сроки работы

По опыту известно, что сроки работ примерно над 80% проектов устанавливаются авторитарно.

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

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

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

Сжатие графиков проекта

Иногда, примерно в середине работы над проектом, возникает необходимость сократить время работы над ним.

Сокращение времени работы над проектом достигается сокращением одного или большего количества действий (операций) на критическом пути.

Сокращение времени выполнения пакета работ приводит к повышению прямых расходов.

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

Чем больше критических или почти критических операций, тем больше риск опоздать с завершением проекта.

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

Например, некоторые графики можно скорректировать, если выполнять операции параллельно или использовать лаговые отношения старт-старт.

Риски затрат

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

Зависимость время - затраты.

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

Например, если на разработку образца процесса уходит на 50% больше первоначально рассчитанного времени, то можно ожидать увеличения затрат.

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

Решение о движении наличности.

Некоторые решения, связанные с движениями наличности могут увеличить риски, связанные с графиками.

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

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

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

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

Прогнозы окончательных затрат.

Достаточно часто, когда проект выполнен на 20%, задают вопрос: "Насколько будет соблюдена смета по окончании проекта?"

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

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

Если реальные затраты превышают цифру, заложенную в смете, на 4%, то делают вывод о том, что все затраты превысят смету на 4%.

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

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

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

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

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

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

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

Из-за своей сложности этот метод широко не применяется.

Риски защиты цен.

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

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

Например, если инфляция находится на уровне 3%, некоторые управленцы набавляют 3% на все ресурсы, используемые для выполнения проекта.

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

Ценовые риски необходимо оценивать пункт за пунктом.

Технические риски

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

Что будет, если система или процесс не будут давать результатов?

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

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

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

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

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

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

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

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

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

На практике непредвиденные обстоятельства составляют от 1 до 10% в проектах, аналогичных предыдущим.

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

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

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

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

Сметные резервы

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

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

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

Величина резерва определяется при расчетах затрат на принятый план выхода из непредвиденных обстоятельств или план выхода из кризиса.

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

Если риска удается избежать, фонды возвращаются в резерв управления.

Резервы управления

Эти резервные фонды необходимы для покрытия крупных непредвиденных и потенциальных рисков и поэтому применяются к проекту в целом.

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

Они не зависят от сметных резервов и контролируются управляющим проектом и "владельцем" проекта.

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

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

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

Контроль за риском такого типа - вне сферы компетенции управляющего проектом.

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

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

В табл. 5.3 показаны расчеты для фонда непредвиденных обстоятельств, сделанные для гипотетического проекта.

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

Таблица 5.3. Расчет фонда непредвиденных обстоятельств (тыс. долл.) Наименование операции Основная смета Сметный резерв Проектная смета Дизайн 500 15 515 Код 900 80 980 Испытание 20 2 22 Всего 1420 97 1517 Резерв управления - - 50 Итого 1420 97 1567

Ответственность за проектные риски

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

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

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

В табл. 5.4 указаны самые распространенные категории рисков, типичные для проекта владелец/подрядчик; существуют также специфические проектные риски, но они не включены в эту таблицу.

Зачастую владелец и подрядчик имеют противоречащие друг другу цели - низкие затраты против качества.

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

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

Таблица 5.4. Разделение рисков Руководитель/управляющий проектом Подрядчик Инфляция Стихийные бедствия Изменение масштаба Технические 1. График 2. Затраты Совместно Безопасность Инновации - затраты и доходы

Изменение методов управления контролем

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

Большинство изменений можно разделить на три категории:

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

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

На практике большинство систем контроля над изменениями призваны выполнять следующие функции;

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

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

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

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

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

Система контроля над внесением изменений дает следующие преимущества:

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

Контроль над проектом во многом зависит от непрерывности процесса контроля над изменениями.

Выводы

Все управленцы понимают, что риски являются неотъемлемой частью проекта.

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

Ответственность за риски должна быть четко определена и документально оформлена.

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

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

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

PERT и PERT-моделирование

PERT - метод оценки и проверки программ

В 1958 г. Особый отдел Военно-морского флота и консалтинговая фирма Booze, Allen and Hamilton создали PERT (метод оценки и проверки программ) с целью разработки графика для более чем 3300 подрядчиков, работающих над проектом подводной лодки Поларис, для решения проблемы неопределенности в расчетах времени выполнения работ.

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

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

оптимистическое (наилучшее); средний показатель; пессимистическое (наихудшее).

Разработчики PERT для выражения продолжительности операции решили избрать аппроксимацию бета-распределения.

На рис. 5.2(А) представлено бета-распределение для продолжительности операции, отклоняющееся вправо, и оно представляет собой работу, которая имеет тенденцию отставать от графика.

Рис. 5.2. Операция и плотность распределения проекта

Распределение продолжительности проекта показано в симметрии на рис. А5-7 (В).

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

Средневзвешенное время операции рассчитывается по следующей формуле:

(5.1)

где t_e - средневзвешенное время операции;

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

b - пессимистическое время операции (1 шанс из 100, что при нормальных условиях операция будет закончена позже срока);

m - наиболее вероятное время операции.

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

Отклонения в оценках времени операции определяются при помощи следующих уравнений. Уравнение 5.2 представляет стандартное отклонение для операции.

(5.2) (5.3)

Уравнение 5.3 представляет стандартное отклонение для проекта.

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

Средняя продолжительность проекта (Т_Е) - это сумма всех средних показателей времени, отведенных на выполнение операций по критическому пути (сумма от t_e), и она следует нормальному распределению.

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

Уравнение 5.4 используется для расчета величины Z, приводимой в статистических таблицах (Z - количество стандартных отклонений от средней величины):

(5.4)

где Т_Е - продолжительность критического пути;

T_S - продолжительность работы по графику;

Z - вероятность (выполнения графика), определенная по статистической табл. 5.6.

Гипотетический пример использования метода PERT

Продолжительность операций и значение среднего отклонения представлены на табл. 5.5.

Таблица 5.5. Операция a m b Т_Е квадрат среднего отклонения 1-2 17 29 47 30 25 2-3 6 12 24 13 9 2-4 16 19 28 20 4 3-5 13 16 19 16 1 4-5 2 5 14 6 4 5-6 2 5 8 5 1

Сеть проекта представлена на рис. 5.3.

Рис. 5.3. Гипотетическая сеть

Прогнозируемый срок работы (Т_Е) представлен 64 единицами времени;

Критический путь - 1, 2, 3, 5, 6.

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

Например, какова вероятность завершения работы над проектом до указанного в графике времени (T_s) из 67?

Обычная кривая проекта будет такой как на рис. 5.4

Рис. 5.4. Возможная продолжительность проекта

Используя формулу для значения Z, можно рассчитать вероятность следующим образом:

По данным табл. 5.6 значение Z + 0,5 дает вероятность 0,69, что означает 69%-ную вероятность завершения работы над проектом на 67-ю единицу времени или ранее.

Таблица 5.6. Величина Z Вероятность Величина Z Вероятность -2,0 0,02 +2,0 0,98 -1,5 0,07 + 1,5 0,93 -1,0 0,16 +1,0 0,84 -0,7 0,24 +0,7 0,76 -0,5 0,31 +0,5 0,69 -0.3 0,38 +0,3 0,62 -0,1 0,36 +0,1 0,54

Вероятность выполнения проекта к периоду времени 60 рассчитывается следующим образом:

По табл. 5.6 значение Z - 0,67 дает вероятность 0,26, что означает около 26% вероятности завершения работы над проектом на 60-ю единицу времени или ранее.

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

PERT-моделирование

Для этой методики необходима компьютерная программа, моделирующая отпущенные на проект время, затраты и/или наличие ресурсов с использованием метода Monte Carlo Technique.

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

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

Вопросы для повторения

Если проект тщательно спланирован, проектные риски можно/нельзя устранить. Объясните. Возможность рисков и соответственный им рост затрат меняются на протяжении жизненного цикла проекта, Каково значение этого явления для управляющего проектом? Объясните, в чем разница между сметными резервами и резервами управления. Как связаны между собой структура распределения работы по этапам проекта и контроль над изменениями? Каковы возможные последствия неприменения процесса контроля над изменениями? Почему? Каким образом информация по PERT отличается от информации по СРМ? Как с помощью PERT рассчитать вероятность конкретной продолжительности выполнения проекта? Какие подходы лежат в основе этого метода? Почему на практике метод PERT используется редко? © INTUIT.ru, 2003-2010. Все права защищены.

INTUIT.ru::Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий http://www.INTUIT.ru Основы управления проектами 6. Лекция: Измерение и оценка состояния и хода выполнения работ: версия для печати и PDA

Контроль процесса. Этапы контроля. Разработка основного плана. Измерение хода работы. Сравнение плана с фактом. Принятие мер. Мониторинг времени выполнения работ. Интегрированная система стоимость/график. Сметная стоимость работ (bcws). Фактическая стоимость выполненной работы (acwp). Приведенная стоимость сметная стоимость выполненных работ (bcwp). Разработка опорного плана проекта. Правила размещения затрат в опорном плане. Метод анализа отклонения. Разработка отчета о статусе. Показатели выполнения работ. Показатель процента завершенности проекта. Прогнозирование окончательной стоимости проекта

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

Контроль процесса

В управлении проектом контролем пренебрегают больше всего.

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

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

Разработка основного плана. Измерение хода работы. Сравнение плана и фактических результатов. Принятие мер.

Этап 1: разработка основного плана.

Основной план дает нам элементы измерения хода работ.

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

Этап 2: измерение хода работы.

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

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

Этап 3: сравнение плана с фактом.

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

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

Этап 4: принятие мер.

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

Мониторинг времени выполнения работ

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

Основой для сравнения плана с фактическим ходом работ служит сетевой график. Типичными инструментами контроля являются графики Ганта.

Рис. 6.1 показывает график Ганта с указанием последней информации по проекту на седьмом периоде.

Рис. 6.1. График Ганта, демонстрирующий статус графика

Прямоугольная таблица под схемой выполнения плана обозначает фактическое время начала и окончания для выполненных операций или любую часть выполненной операции (см. операции A, B, C, D и E).

Например, фактическое время начала для операции С - период 2, фактическое время окончания - период 6, фактическая продолжительность - 4 единицы времени, а не 5 периодов, как по первоначальному графику.

Незавершенные еще операции показывают фактическое время начала до настоящего момента, продолжающая линия показывает оставшееся по графику время (см. операции D и Е).

Оставшееся прогнозируемое время для операций D и Е обозначено заштрихованной линией.

Операция F, которая еще не выполнялась, обозначает параллельными линиями пересмотренное время фактического начала (10) и окончания (14).

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

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

Для операции D пересмотренная продолжительность по прогнозам составит 4 единицы времени, что на один период времени дольше первоначального графика.

График контроля расписания - еще один инструмент мониторинга хода выполненных работ и оценки тенденций.

На рис. 6.2 представлен график контроля проекта.

Рис. 6.2. Схема контроля графика проекта

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

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

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

СЛУЧАЙ ИЗ ПРАКТИКИ Отчеты о ходе выполнения проектов в Microsoft

В Microsoft каждому программному продукту соответствует отчет о ходе выполнения проекта.

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

Отчеты о статусе краткие и имеют стандартный формат.

Отчеты о ходе выполнения проекта - важный механизм для обмена информацией между руководителями компании и управляющими проектами. Как говорит Гейтс: "Я получаю все отчеты о ходе выполнения проекта.

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

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

Интегрированная система стоимость/график

Формат для системы стоимость/график был разработан Министерством обороны США в 1960 г,

Необходимость системы приведенной стоимости (ev)

Система основана на понятии приведенной стоимости, принятом в бухучете.

Системы только лишь сравнивающие факт со сметой не в состоянии измерить, что действительно удалось сделать на затраченные средства.

Такие системы не принимают во внимание параметр времени в управлении.

Пример

Фирма, занимающаяся высокими технологиями, внедряет проект НИОКР.

В первоначальный план включено завершение проекта за 10 месяцев со стоимостью примерно в $200 000 в месяц при общей стоимости в $2 млн.

Через пять месяцев после начала работ топ-менеджмент решает оценить статус проекта. В наличии следующая информация:

фактические затраты в первые пять месяцев составляют $1,3 млн; запланированные сметные затраты на пять месяцев составляют $1 млн.

Менеджмент может прийти к выводу, что затраты превысили плановые показатели на $300 000.Это может быть, а может и не быть правильным выводом.

Возможно, ход работ опережает график, и $300 000 - это зарплата за труд с опережением графика. А возможно, есть и превышение затрат, и отставание от графика. То есть, данные не раскрывают ситуацию полностью.

Используя тот же пример с другими исходными данными, мы опять увидим, что данные не могут дать нам адекватного вывода о состоянии проекта за 5 месяцев:

фактические затраты за первые пять месяцев составили $800 000;запланированные затраты за первые пять месяцев - $1 млн.

Эти данные могут привести к выводу, что проект обходится дешевле планируемого на $200 000.

Так ли это? Если проект отстает от графика, то $200 000 могут обозначать запланированные работы, к которым еще не приступили. Может быть, что проект и отстает от графика, и затраты превышены.

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

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

Краткое изложение интегрированной системы стоимость/график

Тщательное выполнение пяти шагов обеспечивает целостность системы стоимость/график.

Шаги 1-3 выполняются на стадии планирования.

Шаги 4 и 5 последовательно выполняются на стадии выполнения проекта.

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

Кумулятивные значения этих смет станут основой и будут называться сметной стоимостью работ (BCWS).

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

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

Эти затраты будут называться фактической стоимостью выполненной работы (ACWP).

Сложите сметные величины фактически выполненных работ. Они будут называться приведенной стоимостью или сметной стоимостью выполненных работ (BCWP).

Просчитайте отклонение по расписанию (SV = BCWP - BCWS) и отклонение по стоимости (CV = BCWP - ACWP).

На рис. 6.3 представлена схема интегрированной системы сбора и анализа информации.

Рис. 6.3. Схема информационной системы управления проектом

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

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

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

Распределенные по времени сметы добавляются по временной шкале проекта для создания опорного плана.

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

На рис. 6.4 показаны отношения между данными, использующимися для создания опорного плана.

Рис. 6.4. Соотношения между данными, входящими в опорный план

Какие затраты включены в опорный план!

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

Четыре типа затрат обычно включают в опорный план - затраты на труд и затраты на оборудование, затраты на материалы и затраты, возникающие в ходе работы над проектом (LOE).

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

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

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

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

Затраты LOE также можно привязать к "подвешенной" операции, покрывающей сегмент проекта. Когда затраты LOE привязаны к пакетам работ, не имеющим измеряемых показателей, их затраты вносят в смету как величину на единицу времени (например, $200/день).

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

Правила размещения затрат в опорном плане

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

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

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

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

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

Правило 0/100%. По этому правилу всю стоимость за выполнение работы списывают, когда она полностью завершена.

Это правило используют для работ с очень короткой продолжительностью.

Правило 50/50. Этот подход позволяет списать 50% стоимости сметы работ, когда работа начата, и 50% по завершении.

Это правило используют применительно к наборам работ с короткой продолжительностью и небольшими общими затратами.

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

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

При измерении процента выполнения на стадии контроля проекта обычно процент выполнения ограничивают 80% до тех пор, пока пакет работы не будет завершен на 100%.

Еще одним правилом, применяемым на практике, является правило контрольных точек.

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

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

Метод анализа отклонении

Метод измерения степени завершенности задач проекта сосредоточен на двух ключевых оценках:

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

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

В табл. 6.1 представлены термины, используемые в анализе.

Таблица 6.1. Глоссарий BCWS Budgeted Cost of Work Sheduled. Сметная стоимость работ. Оценка стоимости запланированных ресурсов в кумулятивной основе, разбитой по времени. BCWP Budgeted Cost of Work Performed Сметная стоимость выполненной работы. Приведенная стоимость или первоначальная сметная стоимость фактически выполненной работы. ACWP Actual Cost of Work Performed Фактическая стоимость выполненной работы. Сумма издержек, связанных с выполнением работы. SV Отклонения в сроках (BCWP - BCWS) CV Отклонения в стоимости (BCWP - ACWP) ВАС Сметная стоимость по завершении. Общая сметная стоимость опорного плана или счета издержек проекта. ЕАС Расчетная стоимость по завершении. Включает издержки на настоящий момент плюс пересмотренные расчетные издержки оставшейся части работ FАС Прогнозируемые расчетные издержки по завершении VAC Отклонения при завершении (ВАС - ЕАС или ВАС - FАС). Показывает ожидаемое фактическое превышение расходов или недоиспользование средств по завершении

Оценка текущего статуса проекта с использованием приведенной стоимости системы стоимость/график требует три элемента данных - BCWS, BCWP и ACWP.

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

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

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

Отклонение графика дает общую оценку всех наборов работ проекта на определенную дату.

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

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

Рис. 6.5. График сметной стоимости работ

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

Отметка "сегодня" обозначает дату отчета (отметка 25) о том, на какой стадии находится проект.

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

Верхняя линия обозначает фактические затраты (ACWP) на работу над проектом на данный момент.

Средняя линия обозначает опорный план (BCWS) и заканчивается на запланированной по графику продолжительности проекта (45).

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

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

Продолжительность проекта была увеличена и отклонения при завершении (VAC) отрицательны (ВАС - ЕАС).

В другой интерпретации данного графика используются проценты. В конце периода 25 по плану должно было быть выполнено 75% работы.

В конце периода 25 выполнено 50%.

Фактическая стоимость выполненной работы на данный момент составляет $340, или 85% от общей сметы проекта.

Из графика видно, что можно ожидать, что проект превысит стоимость на 12% и на 5 единиц отстанет от намеченных сроков.

Текущий статус проекта показывает, что отклонение стоимости (CV) превысит смету на $140 (BCWP - ACWP = 200 - 340 = -140).

Отклонения графика/сроков (SV) является отрицательной $100 (BCWP - BCWS = 200 - 300 = -100), что говорит об отставании проекта от сроков.

Разработка отчета о статусе: гипотетический пример

Допущения

Допустим, что каждый счет издержек имеет всего один пакет работ, и каждый счет издержек будет представлен в сети в виде операции. Время раннего начала работ в сетевом графике проекта послужит базой для определения значений опорного плана. За исключением тех случаев, когда применяются правила 0/100 и 50/50, значения опорного плана будут обозначены линейно, если особо не будет указано, что они обозначены по-другому (на практике затраты могут быть обозначены как угодно, лишь бы это соответствовало фактическим ожидаемым условиям). С момента начала операции в каждый период будут иметь место фактические затраты, вплоть до завершения операции.

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

На рис. 6.6 представлена простая структура распределения наборов работ по этапам (СРНРЭ) для примера.

Есть три промежуточных результата (X, Y, Z) и четыре ответственных за их достижение отдела (А, В, С, D). Общая цифра всех счетов издержек (СА) составляет $137.

Рис. 6.6. Сетевой план проекта

На рис. 6.8 представлена сеть проекта с ES, LS, EF, LF и резервами времени операций.

Рис. 6.7. Сетевой план проекта

Эта информация о сети нужна для распределения по времени опорного плана проекта. На рис. 6.8 представлена таблица опорного плана, разработанного на основе правил приведенной стоимости.

Рис. 6.8. Расходы по реализации опорного плана проекта

Применяются три основных правила:

100% сметы по окончании. 50% в начале и 50% по окончании. Процент выполнения объема.

Например, операция 3 использует правило приведенной стоимости 50/50 и выделяет $15 в начале периода 3-4 и $15 по окончании в периоде 5-6 при общей сметной стоимости $30.

Операция 4 использует правило выполненного процента и распределяет затраты линейно по ожидаемой продолжительности операции.

Разработка отчета о статусе

Отчет о статусе - это моментальный снимок проекта в конкретный момент времени.

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

Измерение приведенной стоимости начинается на уровне набора работ. Наборы работ могут находиться в одном из трех состояний на день отчета:

Еще не .начинались, Уже закончены. Находятся в процессе выполнения или частично завершены.

Определение приведенной стоимости для первых двух условий не представляют трудности.

Наборы работ, к которым еще не приступали, получают 100% от их сметы (BCWS).

Для наборов, находящихся в процессе выполнения, применяют одно из трех правил приведенной стоимости для разработки опорного плана (BCWP).

На рис. 6.9 представлена таблица отчета о статусе в конце периода 4. Для отчета о статусе собрана следующая информация.

Операция 1 завершена. Операции 2, 3, 4 и 5 - в процессе выполнения. операция 3 имеет продолжительность 5 единиц времени;операция 4 имеет продолжительность 5 единиц времени,Операции 2, 3, 4, 5 и б имеют пересмотренные оценки их стоимости. Операция 4 выполнена на 60% по смете в долларах. К операциям 6, 7 и 8 еще не приступили, они будут отложены.

Рис. 6.9. Отчет о статусе

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

Например, для операции 4 использовано правило 3 - правило процента выполнения. Для операции 5 используется правило 1.

Заштрихованные клеточки обозначают ACWP; под каждой клеточкой факта находится клеточка приведенной стоимости.

Например, операция 1 имеет фактические стоимости $1, $3 и $4 в периоды с 0 по 3.

Так как операция 1 завершена, то приведенная стоимость составляет 100% от сметы (BCWS).

Операции 2 и 3 находятся в процессе, и для них используется правило 50/50. Отсюда приведенная стоимость на сегодняшний момент для операции 2 составляет $10 (50% от $20), а приведенная стоимость для операции 3 составляет $15 (50% от $30). Операция 4 завершена на 66%; приведенная стоимость равна $16 (66% от $24).

Так как к операциям 6, 7 и 8 еще не приступали, они получают 0% соответственно от своих смет.

На рис. 6.9 пересмотренные цифры были получены из результатов работы и включены в отчет о статусе для оценки стоимости по окончании (ЕАС).

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

Представлены общие цифры ACWP и BCWP для каждого периода. Эти величины кумулятивные.

Рис. 6.10. График сметной стоимости работ

SV выражена в долларах и не является точной мерой времени; однако она достаточно правильно оценивает статус всего проекта относительно опережения и отставания от сроков.

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

При таких пересмотренных цифрах стоимости и сроков, проект не уложится во время и в смету, если не внести коррективы в будущие тенденции.

По оценкам, работа над проектом закончится в период времени 14, а не 12.

Разница в стоимости при завершении проекта (VAC = ВАС-ЕАС = 137 - 154) составляет - $17.

Приведенный пример демонстрирует, как традиционный метод, использующий только факт (ACWP = $32) и смету (BCWS = $37), может быть обманчив.

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

Таблица 6.2. Общий отчет о стоимости проекта Операция Работа, выполненная на конкретный момент Общая стоимость при завершении Сметная стоимость выполнен-ной работы (PCWP) Фактическая цена (ACWP) Превышение/ недостижение цены Сметная стоимость выполненной работы в комулятивной основе (BCWS) Последняя пересмотренная цена Превышение/ недостижение цены 1 6 8 (-2) 6 8 (-2) 2 10 4 6 20 18 2 3 15 6 9 30 35 (-5) 4 16 12 4 24 30 (-6) 5 0 2 (-2) 16 18 (-2) 6 16 20 (-4) 7 10 10 0 8 15 15 0 Общая 137 154 (-17)

Рис. 6.11. Период 4. Сворачивание проекта по промежуточным результатам, организации и счету издержек

На рис. 6.11 представлено крайне упрощенное сворачивание проекта в конце периода 4.

Сворачивание идет по промежуточным результатам и организационным отделам.

Относительно графика/сроков и колебания цен все переменные благоприятны.

Отдел А имеет превышение цен - $2.

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

Показатели

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

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

Показатель 1.00(100%) говорит о том, что все идет по плану.

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

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

Показатели выполнения работ

Существует два показателя эффективности выполнения работ.

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

CPI равный $1,47 показывает, что на отчетную дату было выполнено запланированной работы $1,47 на каждый $1, затраченный фактически.

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

Второй показатель - оценка выполнения плана на конкретную дату:

Показатель графика/сроков показывает, что на отчетную дату было выполнено запланированной работы $1,27 на каждый $ 1 по графику/срокам.

В табл. 6.3 дана расшифровка показателей.

Таблица 6.3. Расшифровка показателей Показатель Стоимость (CPI) График/сроки (SPI) >1.00 Ниже стоимости Опережает график/сроки = 1.00 Соответствует стоимости Совпадает с графиком/сроками < 1.00 Выше стоимости Отстает от графика/сроков

Показатель процента завершенности проекта

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

Первый показатель похож на процент выполнения относительно сметной стоимости:

Это говорит о том, что выполненная работа представляет собой 34% от всей сметной суммы (ВАС) в долларах на отчетную дату.

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

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

(21%)

Это говорит о выполнении на 21%, если учитывать фактически затра-ченые доллары на выполнение работы к определенному числу и пересмотренные фактически ожидаемые затраты на завершение проекта.

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

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

Прогнозирование окончательной стоимости проекта

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

"Укладываемся ли мы в смету?",

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

Метод, заслуживший доверия и доказавший свою точность и надежность при прогнозе окончательных проектных затрат основан на использовании показателя CPI (CPI = BCWP/ACWP).

Модель прогноза (РАС) может быть описана следующим уравнением:

где ETC - ориентировочная стоимость по завершении (работ);

CPI - кумулятивный индекс стоимости выполнения работы на определенную дату;

BCWP - кумулятивная сметная стоимость работ, завершенных к конкретному моменту;

ACWP - кумулятивная фактическая стоимость работ, завершенных к конкретному моменту;

ВАС - общая сметная стоимость опорного плана;

FАС - прогнозируемая общая стоимость работ по завершении.

Например, если мы допустим наличие следующей информации, то прогнозируемая стоимость при завершении (FАС) рассчитывается следующим образом:

Общая основная смета (ВАС) проекта 5000 Кумулятивная приведенная стоимость (BCWP) на данный момент 1600 Кумулятивная фактическая стоимость (ACWP) на данный момент 2000

Прогноз окончательной стоимости проекта равен $6250.

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

Другие вопросы контроля

Изменения в основе проекта

В целом управляющий проектом должен противостоять изменениям.

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

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

На рис. 6.12 изображено влияние стоимости изменений масштаба на основу проекта в определенный момент времени - "сегодня".

Рис. 6.12.

Линия А обозначает изменения масштаба, которые приводят к увеличению стоимости.

Линия В обозначает изменения масштаба, которые снижают стоимость.

Быстрая регистрация изменений масштаба в основе позволяет удержать приведенную стоимость на уровне расчетной.

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

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

Редко, когда все происходит в точности по плану.

Величина фонда непредвиденных расходов должна зависеть от степени неопределенности, рисков, связанных со сроками, и неточности в определении стоимости.

Если в проекте мало нового для проектной команды, резерв непредвиденных расходов может составлять 1-2% от общей стоимости проекта.

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

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

Фонды непредвиденных расходов сметного бюджетного резерва не для изменений масштаба.

Изменения масштаба покрываются из фондов управленческого резерва.

Выводы

Лучшая система информации не означает наличие хорошего контроля.

Контроль присутствует тогда, когда управляющий проектом использует информацию для руководства проектом.

График контроля и график Ганта - надежные методы контроля за временем выполнения работ.

Система стоимость/график позволяет управляющему вовремя оказывать положительное влияние на стоимость и график.

Преимущества модели стоимость/ график таковы:

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

Вопросы для повторения

Каким образом приведенная стоимость дает более четкую картину статуса графика и стоимости проекта по сравнению с простым планом против фактической системы? Каким образом опорный план способствует интеграции планирования и контроля проектов? Почему для управляющих проектами важно противостоять изменениям в опорном плане проекта? При каких условиях управляющий проектом мог бы внести изменения в опорный план? Когда управляющий проектом может не допустить внесения изменений в опорный план? Как сворачивание проекта помогает выявлять проблемы стоимости и графика проекта? Затраты можно собрать в одно целое или разъединить по горизонтали и вертикали. В чем преимущества этой системы? В чем различия между ВАС, ЕАС и FАС? © INTUIT.ru, 2003-2010. Все права защищены.

INTUIT.ru::Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий http://www.INTUIT.ru Основы управления проектами 7. Лекция: Информационные технологии в управлении проектами: версия для печати и PDA

Интеграционный подход в управлении проектами. Основные направления автоматизации. Календарно-ресурсное и финансовое планирование. Управление проектами в смежных областях. Управление документами и деловыми процессами. Управление документами. Управление деловыми процессами. Open plan - профессиональная система управления проектами

Интеграционный подход

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

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

Рис. 7.1. Процесс формирования команды проекта

В ИТ-области интеграционный подход выражается в необходимости создания контура взаимосвязанных продуктов, в котором СУП связывается с другими системами предприятия информационными и пользовательскими интерфейсами.

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

Основные направления автоматизации

Выделим два основных направления - автоматизация стандарта управления проектами и автоматизация функций управления проектами.

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

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

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

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

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

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

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

Календарно-ресурсное и финансовое планирование

В части календарно-ресурсного планирования СУП должна обеспечить следующие возможности:

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

В части финансового планирования СУП должна обеспечить следующие возможности:

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

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

Рис. 7.2. Универсальная архитектура программных средств СУП

увеличить изображение

Рис. 7.3. Процедура согласования документов и приемки работ

Управление документами и деловыми процессами

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

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

Рис. 7.4. Функциональные компоненты СУП

Управление документами

Управление документами реализуется с использованием базовой функциональности промышленных пакетов (Docs Open, Documentum).

Управление деловыми процессами

Функции управления движением документов и контроля сроков их исполнения реализуются с использованием базовой функциональности специализированных программных систем (Eastman) или промышленных пакетов управления документами (Documentum).

Расширение функциональности

Среди наиболее важных возможностей отметим следующие:

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

Оpen Plan - профессиональная система управления проектами

Расширенные возможности управления ресурсами

Средства ресурсного планирования Оpen Plan позволяют управлять всеми видами ресурсов: людьми, оборудованием, материалами, финансами.

Гибкость работы со всеми видами ресурсов достигается за счет:

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

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

Мультипроектный анализ

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

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

Гибкость и многогранность

В Оpen Plan предусмотрены механизмы вывода информации в виде диаграмм, таблиц, гистограмм, S-кривых и т.д.

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

Открытая архитектура

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

Допустимыми являются собственный формат Оpen Plan, а также форматы Oracle, MS SQL Server, Sybase, xBase.

Оптимальная реализация распределенной системы управления в компании - две версии системы - Professional - Desktop

И профессиональная, и настольная версия системы включают в себя полный комплект функций по управлению проектами.

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

Планирование и контроль проекта.

Средства создания модели проекта.

Оpen Plan поддерживает следующие структурные модели проекта:

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

Сетевая модель

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

Сетевая модель проекта отображается в форматах:

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

увеличить изображение

Рис. 7.5. Окно Диаграммы Гантта в Оpen Plan PERT-диаграмма (сетевая диаграмма).

Предусмотрены такие операции, как:

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

увеличить изображение

Рис. 7.6. Окно Сетевой диаграммы в Оpen Plan

При планировании работ возможно задавать различные настраиваемые характеристики работ:

Иерархическая структура календарей

В Оpen Plan иерархическая структура календарей позволяет построить систему шаблонов рабочего времени с учетом наследования календарем-потомком свойств родителя.

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

Иерархическая система кодов работ

Дополнительным средством структуризации в Оpen Plan является универсальная система кодов.

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

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

В качестве примера можно рассмотреть описание структуры затрат на проект с помощью кодов.

Предположим, что в организации приняты два вида затрат: внутренние и внешние (оплата работ Системного интегратора).

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

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

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

увеличить изображение

Иерархическая структура кодов в Оpen Plan

Кроме того, в Оpen Plan предусмотрена возможность создания иерархической структуры ресурсов (исполнителей, оборудования, материалов, затрат), что позволяет выбирать степень детализации при просмотре загрузки ресурсов, проводить планирование и назначение ресурсов на суммарном уровне.

Коды затрат назначаются работам, по которым эти затраты проводятся.

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

увеличить изображение

Рис. 7.7. Диаграмма Гантта с разбиением списка работ на группы по кодам в Оpen Plan

Планирование и контроль сроков

Процедуры временного анализа, заложенные в Оpen Plan, позволяют определить:

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

По умолчанию Оpen Plan требует указывать длительность работ.

В некоторых областях, например, в строительстве, проект изначально планируется не по длительностям работ, а по их объемам (по трудоемкости).

В Оpen Plan эта возможность реализуется через расчет длительности на основании назначенных ресурсов (задавая их мощность) или по алгоритму, задаваемому пользователем.

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

Планирование и контроль ресурсовТипы ресурсов

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

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

Иерархическая структура ресурсов

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

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

увеличить изображение

Рис. 7.8. Иерархическая структура ресурсов в Оpen Plan

Общие характеристики ресурса

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

При стоимостном анализе затраты подразделяются на финансовые затраты и затраты на ресурсы.

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

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

Для расходуемого ресурса - это общее количество и дата, с которого он поступает в распоряжение.

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

В Оpen Plan имеется опция, задающая изменение стоимости ресурсов во времени - удорожание, т.е. если после какого-то срока происходит удорожание или удешевление ресурса, то изменения отражается в результатах стоимостного анализа.

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

В системе определено понятие квалификаций.

Для работы можно определить потребность в количестве ресурсных единиц и квалификации ресурса. Это предоставит возможность менеджеру проекта не назначать на ее выполнение конкретный ресурс, а с помощью Оpen Plan выбрать наименее загруженный в период выполнения работы ресурс с необходимой квалификацией (например, может ли сотрудник провести учебные курсы по внедряемой в организации системе - квалификация УЧ_КУРСЫ).

Менеджер принимает решение о том, устраивает ли его предложенный системой ресурс - нажатие кнопки Принят, при которой квалификация переходит в графу Альтернативный, а предлагаемый ресурс в Требуемый, то есть при новом запуске процедуры ресурсного планирования, если предлагаемый ресурс К_ПР.SD.SERGEY KOLCHIN окажется задействованным на других работах, будет учитываться, что можно предложить на работу другого исполнителя, обладающего данной квалификацией.

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

Менеджер может зафиксировать предложенный вариант назначения - "окончательно и бесповоротно" назначить исполнителя на работу (нажатие кнопки Заперт переводит предлагаемый ресурс в Требуемый, однако колонка Альтернативный остается пустой).

Резервирование ресурсов

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

Например, можно зарезервировать целый отдел или конкретного человека под проект.

При резервировании конкретного специалиста поддерживаются два режима:

Полное резервирование ресурса Частичное резервирование ресурса

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

Например, специалист может быть зарезервирован на 50% рабочего времени для данного проекта на заданные 6 месяцев.

Назначение ресурсов на задачу

Оpen Plan предоставляет два способа описания расходования ресурса на работе:

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

Анализ ресурсного обеспечения работ проекта

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

увеличить изображение

Рис. 7.9. Окно Диаграммы Гантта с ресурсной гистограммой

Планирование и контроль затрат

Анализ стоимости работ на основании фактической выработки

Основу системы контроля стоимостей на основании фактической выработки образуют:

Плановая Стоимость Запланированных Работ, Плановая Стоимость Выполненных Работ, Фактическая Стоимость Выполненных Работ

увеличить изображение

Рис. 7.10. Гистограмма затрат в Оpen Plan

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

Анализ рисков в Оpen Plan реализуется следующими средствами:

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

Аналитические инструменты базируются на методе Монте-Карло.

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

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

увеличить изображение

Рис. 7.11. Гистограмма рисков по дате раннего начала работы в Оpen Plan

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

По левой оси Оpen Plan рисует шкалу с процентами итераций анализа рисков, при которых даты попали в определенный интервал.

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

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

Объединение проектов служит двум целям:

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

У каждого подпроекта может быть свой файл ресурсов.

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

Список пользователей Оpen Plan

Пользователи Оpen Plan за рубежом:

Авиастроение - Boeing, Lockheed Martin, BAE SYSTEMS, British Aerospace, Canadair Military Aircraft, Daimler Benz Aerospace, GEC Marconi и др. Машиностроение - General Motors, Renault, Rolls Royse, NASA Lewis Research Center, Chem Nuclear и др. Нефтехимия - AMOCO, British Petroleum, Dupont, ExxonMobil, Occidental Chemical, Shell и др. Телекоммуникации и ИТ - AT&T, KPMG, Intel, Teleport, Telus Communications, US Robotics и др. Строительство - Asea Brown Boveri, ABB, Bovis Construction, London Underground, Rolls Royce Engineering и др. Энергетика - British Nuclear Fuels, Florida Power&Light, Hydro Quebec, Union Electric, Westinghouse и др.

Среди российских пользователей Оpen Plan:

Авиастроение - ОКБ Сухого, Иркут (ИАПО); Газонефтедобыча - Лукойл-Бурение, Ямбурггаздолбыча, Славнефть; Игорный бизнес - Фирма "Профит" Машиностроение - Астраханский Корабел, Кранэкс; Нефтехимия - Киришнефтеоргсинтез; Торговля - ТД "Детский Мир"; Строительство - Мостоотряд 18, Cyvas, Гипротрубопровод, ГСК Холдинг, КазТрансОйл (Казахстан), Спецэлектромонтаж, Спортстройиндастриз, ГСК; Телекоммуникации и ИТ - Телекомстрой, Казахтелеком (Казахстан); Финансы - Народный Банк Казахстана, Банк Тураналем (Казахстан); Энергетика - Балаковская АЭС. © INTUIT.ru, 2003-2010. Все права защищены.

Оглавление

INTUIT.ru::Интернет-Университет Информационных Технологий

  О различных трактовках понятия "проект"

  Определение проекта

  Этап 1: разработка технического задания

  Использование перечня контрольных вопросов проекта

  Разработка ТЗ проекта

  Этап 2: расстановка приоритетов

  Матрица приоритетов проекта

  Этап 3: структурирование работ по этапам

  Основные группы в структуре распределения работы по этапам (СРРПЭ)

  Разработка СРРПЭ

  Структура распределения процесса работы по этапам

  Этап 4: совмещение СРРПЭ с организацией

  Этап 5: кодирование СРРПЭ для информационной системы

  Подсчет затрат и разработка смет

  Вывод

INTUIT.ru::Интернет-Университет Информационных Технологий

  От набора работ к сетевому графику

  Конструирование сетевого графика проекта

  Терминология

  Два подхода к разработке сетевых графиков

  Основные правила разработки сетевого графика

  Принципы построения и анализа сетевых графиков типа "ОУ"

  Оценка начала и окончания работ с помощью сетевого графика

  Процесс расчета параметров сетевого графика

  Прямой анализ - определение ранних сроков начала операций

  Обратный анализ - определение поздних сроков завершения операций

  Определение резервов времени

  Практика

  Свободный резерв

  Как используются результаты прямого и обратного анализа сетевого графика

  Ошибки сетевой логики

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

  Использование задержек (лагов)

  Отношения типа "от конца к началу".

  Операции растяжки

  Выводы

  Вопросы для повторения

INTUIT.ru::Интернет-Университет Информационных Технологий

  Проблема

  Типы ограничении проекта

  Технические или логические ограничения

  Ограничения на количество ресурсов

  Виды ограничений на количество ресурсов

  Люди

  Материалы

  Оборудование

  Текущие активы

  Классификация проблем календарного планирования

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

  Исходные положения

  Проекты, ограниченные по времени

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

  Влияние календарного планирования ресурсов, подлежащих ограничениям

  Распараллеливание

  Метод критической цепи

  Выгода от календарного планирования ресурсов

  Распределение работ по проекту

  Человек или ресурс?

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

  Команда проекта

  Управление трудовыми ресурсами проекта и менеджмент человеческих ресурсов проекта

  Интегрированная культура команды проекта

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

  Выводы

  Вопросы для повторения

INTUIT.ru::Интернет-Университет Информационных Технологий

  Процедура сокращения времени

  Объяснение издержек проекта

  Сокращение времени выполнения проекта

  Построение графика стоимости времени выполнения проекта

  Определение операций для сокращения времени их выполнения

  Упрощенный пример

  Практические соображения

  Предельное время

  Расчет времени срочных операций

  Линейность предположений

  Нижний уровень

  Сценарии управления отклонениями

  Управление отклонениями

  Модели отклонений

  Увеличение интенсивности работ

  Замена исполнителя

  Материальное стимулирование

  Привлечение дополнительных исполнителей из штата компании

  Привлечение субподрядчиков

  Манипулирование временем

  Изменение сроков завершения работ

  Смещение вех

  Увеличение общего срока проекта

  Манипулирование продуктом (качеством)

  Снижение качества продукта

  Замена продукта

  Исключение продукта

  Выводы

  Вопросы для повторения

INTUIT.ru::Интернет-Университет Информационных Технологий

  Выявление и оценка риска в проекте

  Выявление источников риска

  Анализ и оценка риска

  Анализ сценария (А): неколичественный

  Анализ с использованием поправочных коэффициентов и допусков

  Анализ смешанного типа

  Реакция на риск

  Снижение или сохранение риска

  Переадресация риска

  Участие в рисках

  Планирование на случай непредвиденных обстоятельств

  Риски, связанные с выполнением графика работ

  Авторитарно установленные сроки работы

  Сжатие графиков проекта

  Риски затрат

  Зависимость время - затраты.

  Решение о движении наличности.

  Прогнозы окончательных затрат.

  Риски защиты цен.

  Технические риски

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

  Сметные резервы

  Резервы управления

  Ответственность за проектные риски

  Изменение методов управления контролем

  Выводы

  PERT и PERT-моделирование

  PERT - метод оценки и проверки программ

  PERT-моделирование

  Вопросы для повторения

INTUIT.ru::Интернет-Университет Информационных Технологий

  Выявление и оценка риска в проекте

  Выявление источников риска

  Анализ и оценка риска

  Анализ сценария (А): неколичественный

  Анализ с использованием поправочных коэффициентов и допусков

  Анализ смешанного типа

  Реакция на риск

  Снижение или сохранение риска

  Переадресация риска

  Участие в рисках

  Планирование на случай непредвиденных обстоятельств

  Риски, связанные с выполнением графика работ

  Авторитарно установленные сроки работы

  Сжатие графиков проекта

  Риски затрат

  Зависимость время - затраты.

  Решение о движении наличности.

  Прогнозы окончательных затрат.

  Риски защиты цен.

  Технические риски

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

  Сметные резервы

  Резервы управления

  Ответственность за проектные риски

  Изменение методов управления контролем

  Выводы

  PERT и PERT-моделирование

  PERT - метод оценки и проверки программ

  PERT-моделирование

  Вопросы для повторения

INTUIT.ru::Интернет-Университет Информационных Технологий

  Контроль процесса

  Этап 1: разработка основного плана.

  Этап 2: измерение хода работы.

  Этап 3: сравнение плана с фактом.

  Этап 4: принятие мер.

  Мониторинг времени выполнения работ

  Интегрированная система стоимость/график

  Необходимость системы приведенной стоимости (ev)

  Пример

  Краткое изложение интегрированной системы стоимость/график

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

  Какие затраты включены в опорный план!

  Правила размещения затрат в опорном плане

  Метод анализа отклонении

  Разработка отчета о статусе: гипотетический пример

  Допущения

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

  Разработка отчета о статусе

  Показатели

  Показатели выполнения работ

  Показатель процента завершенности проекта

  Прогнозирование окончательной стоимости проекта

  Другие вопросы контроля

  Изменения в основе проекта

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

  Выводы

  Вопросы для повторения

INTUIT.ru::Интернет-Университет Информационных Технологий

  Интеграционный подход

  Основные направления автоматизации

  Календарно-ресурсное и финансовое планирование

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

  Управление документами и деловыми процессами

  Управление документами

  Управление деловыми процессами

  Расширение функциональности

  Оpen Plan - профессиональная система управления проектами

  Планирование и контроль проекта.

  Средства создания модели проекта.

  Сетевая модель

  Иерархическая структура календарей

  Иерархическая система кодов работ

  Иерархическая структура кодов в Оpen Plan

  Планирование и контроль сроков

  Планирование и контроль ресурсовТипы ресурсов

  Иерархическая структура ресурсов

  Общие характеристики ресурса

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

  Резервирование ресурсов

  Назначение ресурсов на задачу

  Анализ ресурсного обеспечения работ проекта

  Планирование и контроль затрат

  Анализ стоимости работ на основании фактической выработки

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

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

  Список пользователей Оpen Plan

  Пользователи Оpen Plan за рубежом:

  Среди российских пользователей Оpen Plan:

Fueled by Johannes Gensfleisch zur Laden zum Gutenberg

Наш сайт является помещением библиотеки. На основании Федерального закона Российской федерации "Об авторском и смежных правах" (в ред. Федеральных законов от 19.07.1995 N 110-ФЗ, от 20.07.2004 N 72-ФЗ) копирование, сохранение на жестком диске или иной способ сохранения произведений размещенных на данной библиотеке категорически запрешен. Все материалы представлены исключительно в ознакомительных целях.

Copyright © читать книги бесплатно