II. Стоимостной анализ проекта
УПРАВЛЕНИЕ ПРОЕКТАМИ
Методические указания к лабораторным работам
Приводятся основные сведения и методические указания по планированию проектов с помощью «Microsoft Project». Работа включает три раздела: - «Планирование проекта»; - «Стоимостной анализ проекта»; - «Управление рисками». Методические указания включают последовательность шагов на каждом из этапов и иллюстрируются многочисленными экранами представления информации.
I. Планирование проекта с помощью Microsoft Project
I.1. Введение в Microsoft Project
Microsoft Project- это простой в использовании инструмент эффективного календарного планирования, отслеживания и обмена проектной информацией. Microsoft Project предназначен для широкого круга пользователей, которые испытывают потребность в повышении организации своей работы и работы своего офиса, но не нуждаются в развертывании полно масштабной корпоративной системы управления проектами.
Основные преимущества при использовании Microsoft Project:
- Высокая организация работы с помощью мощного механизма и широких возможностей календарного планирования Microsoft Project
- Удобное и полное отслеживание всех изменений и событий по проектам
- Широкие возможности настройки календарных планов в полном соответствии со спецификой проектов
- Разнообразные представления проектов, настройка представлений, разнообразные механизмы фильтрации и группировки проектной информации.
I.2. Microsoft Project на рынке систем управления проектами
Оценка Gartner.Отчеты Gartner по системам управления проектами не оспаривает ни один серьезный поставщик систем управления проектами. Также следует отметить, что все основные поставщики систем управления проектами от Microsoft до Primavera ссылаются на отчеты Gartner, как на самый достоверный источник в сравнительном анализе данных систем. Исключительный случай, когда конкуренты доверяют одному источнику при сравнении их продуктов.
Данная оценка была сделана для MS Project 2002. Однако в отчете за 2003 год компания Gartner Group подтвердила актуальность основных оценок для MS Project 2003.
Gartner отметил сильные стороны Microsoft Project 2002:
1. Возможность производить расчет расписаний и управление сложными проектами размером, достигающим как минимум 10.000 задач. (Заметим, что проект в 10.000 задач требует затрат примерно в 1 человеко - год только на ввод и отслеживание такого количества задач).
2. Улучшенные средства групповой работы позволяют управлять несколькими проектами большому числу пользователей.
3. Наличие средств для управления ресурсами (раздел отчета "Strengths"):
- роли (квалификации) ресурсов
- управление доступностью ресурсов
- новые портфели проектов
- корпоративные пулы ресурсов
- уникальные средства анализа различных сценариев развития проекта
4. Возможность реализации на MS Project 2002 методики быстрой реакции на меняющиеся условия на рынке (Time-to-Market).
5. Отличная интеграция с Microsoft Office, включая свободный обмен информацией через Excel, Outlook, MS Visio.
6. Интеграция с библиотекой проектной документации на базе Share Point, не имеющая аналогов у конкурентов.
7. Технология SOAP позволяет интегрировать MS Project 2002 с корпоративными системами финансового учета, управления кадрами и др.
Сравнивая продукт с Primavera, PlanView и др. Gartner отмечает, что основная задача, стоящая перед Microsoft при разработке Microsoft Project 2002 - это построение внедренческой инфраструктуры для своего корпоративного решения. Gartner считает, что Microsoft Project 2002 – это лучший выбор для организаций, где используется матричная схема управления, т.е. когда проектные команды включают взаимодействие сотрудников из разных департаментов.
Для задач с большими требованиями в области бюджетирования и управления рисками. Gartner рекомендует обратить внимание на конкурирующие продукты, а также на поставщиков дополнительных компонентов MS Project 2002.
Делая общий вывод, Gartner заключает, что Microsoft Project стал на рынке "де-факто" стандартом для управления проектами как средство индивидуальной работы менеджеров проектов и начинает экспансию в сегмент тяжелых решений.
I.3. Планирование проекта «шаг за шагом»
Предположим, вам необходимо разработать план внедрения автоматизированной системы управления взаимоотношениями с клиентами для банка.
Вам, как менеджеру проекта, предстоит спланировать стадии и задачи предстоящего проекта, определить ресурсы для проекта, произвести расчет бюджета и проработать риски проекта.
Рассмотрим, как это сделать с помощью Microsoft Project шаг за шагом.
После запуска Microsoft Project вы увидите следующий экран (рис.1):
Рис. 1 Первоначальный вид экрана после открытия программы
Воспользуемся панелью помощника составления проекта (с левой стороны под словом задачи). С его помощью мы сможем:
- Задать начальные параметры проекта
- Определить рабочие часы и дни
- Ввести список задач по проекту
- Разбить задачи по фазам
- Определить сроки выполнения задач
- Добавить дополнительную информацию к задачам
- Добавить новые столбцы для особых сведений
- Установить контрольные точки по проекту, ограничения
- Идентифицировать риски проекта
- Добавить документы в проект
- Опубликовать информацию о проекте на Web-сервере
Итак, определим начальные параметры проекта. Щелкните мышкой по Определение проекта:
вам предлагается ввести планируемую дату проекта. Введем дату 01.04.2006.
Для сохранения данной информации и перехода к следующему шагу нажимаем Сохранить и перейти к шагу 2:
На втором шаге вам предлагается определить, разместить ли информацию по проекту на Web-сервере Microsoft Project (рис.2). Выбираем Нет; в дальнейшем при наличии настроенного Web-сервера и необходимости возможно опубликование вашего проекта с помощью задания
соответствующих настроек в меню приложения.
Рис. 2 Размещение информации о проекте
Движемся дальше, нажимая Сохранить и перейти к шагу 3:
Рис.3 Сохранить и закончить работу
Далее программа сообщает вам, что теперь вы готовы, чтобы планировать проект.
Нажимаем Сохранить и закончить работу (Рис.3).
Следующим вашим шагом в планировании проекта будет задание рабочего времени в ходе проекта. Для этого на панели помощника щелкаем по Определение рабочего времени проекта и видим следующий экран (рис.4):
Рис. 4 Календарь участников проекта
Здесь можно установить шаблон календаря для участников проекта. В календаре указываются рабочие часы и рабочие дни в течение недели. Возможно наличие нескольких шаблонов календарей, которые впоследствии вы сможете привязывать к участникам проекта.
Переходим к следующему шагу (Сохранить и перейти к шагу 2), где вы можете поменять типовые настройки шаблона календаря Стандартный.
Предположим, рабочие часы в вашей организации с 9.00 до 18.00 с перерывом на обед с 13.00 до 14.00; рабочая неделя 5-дневная – с понедельника по пятницу включительно.
Устанавливаем эти значение на панели помощника.
Переходим к следующему шагу – заданию нерабочих и праздничных дней. Щелкните мышкой по Изменить рабочее время, после чего появится календарь, где вы можете определить такие дни.
Выберем месяц март, и установим 8-е число нерабочим днем. Выделяем соответствующую дату и справа указываем Нерабочее время (рис.5).
Рис. 5 Задание праздников и выходных дней
Сохраняем настройки (кнопка OK) и переходим к следующему шагу.
Здесь вы можете установить параметры рабочего времени (рис.6), а именно:
· Продолжительность рабочего дня (Часов в дне)
· Количество рабочих часов в неделе (Часов в неделе) Количество рабочих дней в месяце (Дней в месяце) Оставляем введенные настройки по умолчанию и переходим к следующему шагу. Далее вам предлагается задать новые или редактировать существующие шаблоны календарей. Если вы не предполагаете использование нескольких проектных команд с рабочим временем, отличающимся от заданного ранее, пропускаем данный шаг и движемся дальше, щелкая по Сохранить и закончить работу.
Рис. 6 Установление параметров рабочего времени
Следующий этап – определение списка задач по проекту
(Ввод задач проекта) – один из самых важных в проектном управлении.
Вернемся к нашему примеру – внедрения автоматизированной системы управления взаимоотношениями с клиентами (CRM – Customer Relationship Management) в банке.
Типовой пилотный проект такого внедрения состоит из нескольких стадий:
· Разработка технического задания
· Настройка системы
· Ввод в опытную эксплуатацию
· Ввод в промышленную эксплуатацию
На этапе разработки технического задания определяются бизнес - цели проекта и детализируются требования к системе. По завершению согласования технического задания оно подписывается и Заказчиком, и Исполнителем.
Введем названия данных стадий в Microsoft Project, рис.7
Рис.7 Стадии проекта
Поскольку каждую из стадий мы можем разбить на несколько задач, то с помощью функции в меню Вставка à Новая задача (Insert à New task) (или нажатием клавиши Ins на клавиатуре) внесем первую задачу этапа разработки технического задания «Встреча команды проекта. Актуализация и согласование ПЛАН - ГРАФИКА работ на этап». Чтобы внести новую задачу в проект, вы должны установить курсор или выделить строку задачи, перед которой хотите добавить задачу (рис.8).
Рис.8 Внесение новой задачи в проект.
Далее, выделив строку «Встреча команды проекта. Актуализация и согласование ПЛАН - ГРАФИКА работ на этап», на панели инструментов щелкаем по кнопке 
(На уровень ниже) и наша задача оказывается в составе стадии «Разработка технического задания» (рис.9)
Рис. 9 Корректировка задач
Панель инструментов содержит также кнопку, которая позволяет вам переместить задачу на уровень выше: 
(На уровень выше, Outdent).
В рамках технического задания в проект входит интервьюирование заинтересованных лиц банка. Приведем типовой перечень блоков требований, собираемых во время интервью:
Ø Формализация требований к ведению информации о КЛИЕНТАХ, КОНТАКТНЫХ ЛИЦАХ
Ø Формализация требований по настройке процесса СОПРОВОЖДЕНИЯ СУЩЕСТВУЮЩИХ КЛИЕНТОВ
Ø Формализация требований к ОПОВЕЩЕНИЯМ по клиенту
Ø Формализация требований к ПРОДУКТОВОМУ КАТАЛОГУ
Ø Формализация требований по работе с ПОТЕНЦИАЛЬНЫМИ СДЕЛКАМИ
Ø Формализация требований по настройке процессов ПРОДАЖ БАНКОВСКИХ ПРОДУКТОВ
Ø Формализация требований по автоматизации работы с ТИПОВЫМИ БАНКОВСКИМИ ДОКУМЕНТАМИ
Ø Формализация и согласование механизма интеграции с АБС
Ø Формализация требований по интеграции с почтовой системой
Ø Формализация требований по настройке ПРАВ ДОСТУПА (матрица доступа: пользователи/функционал)
Ø Формализация форматов ОТЧЁТОВ
Объединив задачи в один подэтап, добавляем их в проект. Также в рамках этапа проводятся следующие задачи:
Ø Подготовка документа ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Ø Согласование Технического задания
Ø Подписание Технического задания
Таким образом, у нас должен получиться план первого этапа, как на рисунке 10:
Рис.10 Формирование полного списка задач
После того, как у нас сформировался полный список задач на первую стадию, рассмотрим, как в Microsoft Project осуществляется настройка задач, их очередность и взаимозависимость.
Двойным щелчком по первой задаче «Встреча команды проекта. Актуализация и согласование ПЛАН - ГРАФИКА работ на этап» открываем окно настройки задачи (рис.11:
Рис.11 Настройка задач
Ключевые поля, которые мы будем изменять на основной закладке Общие, это Длительность задачи, даты начала и окончания задачи, Процент завершения. В поле длительности возможно указание в минутах, часах, днях, неделях и месяцах. Отметьте поле Предварительная оценка, если даете приблизительную оценку длительности.
На второй закладке Предшественники фиксируется зависимость задачи от других.
Например, для первой встречи интервью она будет выглядеть следующим образом:
Рис.12 Взаимозависимость задач
Строка со ссылкой на первую задачу проекта указывает на то, что вторая задача может начаться сразу же после завершения первой. Тем не менее, вы можете изменить период паузы между последовательными задачами, меняя поле Запаздывание.
На закладке Ресурсы вы указываете, какие ресурсы вам необходимы для исполнения задачи. Это могут быть и людские ресурсы, и производственные. В качестве людским ресурсов выступает команда проекта: руководитель проекта, консультанты, разработчики, технические писатели, системные архитекторы, тренеры и др. К производственным ресурсам можно отнести необходимое аппаратное обеспечение, помещение для проведения переговоров, проектор и т.д.
Например, ресурсы первой задачи – встречи команды проекта для актуализации плана работ могут выглядеть следующим образом, рис.13:
Рис. 13. Ресурсы задач
В случае если ресурс может быть задействован не на всем протяжении задачи, то это можно зафиксировать в поле Единицы, уменьшив его степень вовлечения (в процентах).
Назначим ресурсы на задачи следующим образом:
| Задача | Ресурсы |
| Встреча команды проекта. Актуализация и согласование ПЛАН - ГРАФИКА работ на этап | Руководитель проекта Руководитель проекта со стороны банка |
| Серия ИНТЕРВЬЮ | |
| Формализация требований к ведению информации о КЛИЕНТАХ, КОНТАКТНЫХ ЛИЦАХ | Консультант |
| Формализация требований по настройке процесса СОПРОВОЖДЕНИЯ СУЩЕСТВУЮЩИХ КЛИЕНТОВ | Консультант |
| Формализация требований к ОПОВЕЩЕНИЯМ по клиенту | Консультант |
| Формализация требований к ПРОДУКТОВОМУ КАТАЛОГУ | Консультант |
| Формализация требований по работе с ПОТЕНЦИАЛЬНЫМИ СДЕЛКАМИ | Консультант |
| Формализация требований по настройке процессов ПРОДАЖ БАНКОВСКИХ ПРОДУКТОВ | Консультант |
| Формализация требований по автоматизации работы с ТИПОВЫМИ БАНКОВСКИМИ ДОКУМЕНТАМ | Консультант |
| Формализация и согласование механизма интеграции с АБС | Консультант |
| Формализация требований по интеграции с почтовой системой | Консультант |
| Формализация требований по настройке ПРАВ ДОСТУПА (матрица доступа: пользователи/функционал) | Консультант |
| Формализация форматов ОТЧЁТОВ | Консультант |
| Подготовка документа ТЕХНИЧЕСКОЕ ЗАДАНИЕ | Руководитель проекта[30%] Технический писатель Консультант 2 |
| Согласование Технического задания | Руководитель проекта; Руководитель проекта со стороны банка |
| Подписание Технического задания | Руководитель проекта; Руководитель проекта со стороны банка |
На закладке Дополнительно нам понадобится очень важный признак задачи – «Пометить задачу как веху» – «контрольная точка» проекта, рис.14.
Рис.14. Закладка «дополнительно».
Например, задача «Подписание Технического задания» является контрольной точкой проекта.
Определив задачи проекта и оценив их длительность, можно запланировать их выполнение путем создания зависимостей задач.
По умолчанию Microsoft Project устанавливает для всех задач дату начала, соответствующую дате начала проекта, и вычисляет дату окончания проекта на основе наиболее продолжительной задачи.
Когда пользователь вводит зависимости задач, Project настраивает календарный план для более точного определения дат каждой задачи.
В Microsoft Project существует четыре типа зависимостей, рис.15:
1. Окончание - начало (Finish to Start): задача 2 не может начаться до окончания задачи 1
2. Начало-начало (Start to Start) – задача 2 не может начаться до начала задачи 1
3. Окончание - окончание (Finish to Finish) – задача 2 не может закончиться до окончания задачи 1 Рис.15 Четыре типа зависимостей
4. Начало - окончание (Start to Finish) – задача 2 не может закончиться до начала задачи 1
Выбор конкретного типа определяется характером отношения между задачей-предшественником и задачей-последователем.
Предшественник. Задача, дата начала или окончания которой определяет дату начала или окончания задачи-последователя.
Последователь. Задача, дата начала или окончания которой определяется задачей- предшественником.
Для быстрого создания зависимостей задач на диаграмме Ганнта, удерживая левой клавишей мыши, соедините последовательные задачи; при удержании на диаграмме должен появиться пиктограмма соединения (рис. 16)
Рис.16 Пиктограмма соединения
Укажем последовательность задач, как показано на нижеприведенной схеме на рис. 17.
Рис.17 Последовательность задач
Для расчета стоимости полного проекта нам необходимо запланировать задачи по следующим этапам проекта:
Ø Этап II. НАСТРОЙКА СИСТЕМЫ
Ø Этап III. ВВОД В ОПЫТНУЮ ЭКСПЛУАТАЦИЮ
Ø Этап IV. ВВОД В ПРОМЫШЛЕННУЮ ЭКСПЛУАТАЦИЮ
Этап настройки системы состоит из стадий и задач, описанных в таблице 1 и изображенных на рис. 18.
Перечень стадий и задач проекта
Таблица 1
| Стадия/задача | Длител. | Дата начала | Ресурсы |
| Этап II. НАСТРОЙКА СИСТЕМЫ | 32 дня | 25.04. 06 | |
| Подготовка 3 рабочих мест для специалистов | 2.5 дня | 25.04. 06 | |
| Развёртывание ТЕСТОВОЙ ЗОНЫ (сервер, рабочие места, доп. модули) | 1.5 дня | 25.04. 06 | Системный инженер |
| Настройка рабочих мест для работ по интеграции | 1 день | 26.04. 06 | Системный инженер |
| Интеграция с АБС | 23 дня | 27.04. 06 | |
| Интеграция в части импорта информации о клиентах из АБС | 3 дня | 27.04. 06 | Специалист III |
| Интеграция данных с банковской системой в части счетов, проводок, остатков и оборотов по счетам | 10 дней | 02.05.2006 | Специалист III |
| Интеграция с АБС в части доступа к информации о РЕАЛИЗОВАННЫХ ПРОДУКТАХ | 10 дней | 16.05.2006 | Специалист III |
| НАСТРОЙКА СИСТЕМЫ | 31 день | 25.04.2006 | |
| Настройка системы для ведения информации о КЛИЕНТАХ, КОНТАКТНЫХ ЛИЦАХ | 2 дня | 25.04.2006 | Специалист I |
| Настройка закладок карточек КЛИЕНТА, КОНТАКТНОГО ЛИЦА | 2 дня | 27.04.2006 | Специалист I |
| Настройка процесса сопровождения существующего КЛИЕНТА | 1 день | 01.05.2006 | Специалист I |
| Разработка закладки карточки клиента НЕУДОВЛЕТВОРЕННЫЙ СПРОС | 3 дня | 02.05.2006 | Специалист I |
| Разработка механизма задания ОПОВЕЩЕНИЙ по КЛИЕНТУ (снижение оборотов, переводы денег и т.п.) | 5 дня | 05.05.2006 | Специалист I |
| Настройка закладки ВЛОЖЕНИЯ для ведения файлов с разбивкой по папкам | 2 дня | 12.05.2006 | Специалист I |
| Разработка механизма КОНТРОЛЯ ПОРУЧЕНИЙ, ЭСКАЛАЦИИ при невыполнении задач | 2 дня | 16.05.2006 | Специалист I |
| Настройка алгоритма определения ценности КЛИЕНТА для БАНКА | 2 дня | 25.04.2006 | Специалист II |
| Модификация карточек отображения реализованных ПРОДУКТОВ | 3 дня | 27.04.2006 | Специалист II |
| Настройка карточки СДЕЛКИ | 3 дня | 02.05.2006 | Специалист II |
| Настройка модуля БАНКОВСКИЕ ПРОДУКТЫ, загрузка КАТАЛОГА БАНКОВСКИХ ПРОДУКТОВ | 3 дня | 05.05.2006 | Специалист II |
| Настройка модуля учета ПРОЕКТНОГО ВРЕМЕНИ сотрудников | 5 дней | 10.05.2006 | Специалист II |
| Настройка ПРОЦЕССОВ ПРОДАЖ БАНКОВСКИХ ПРОДУКТОВ | 3 дней | 25.04.2006 | Аналитик |
| Внесение в ТИПОВЫХ ДОКУМЕНТОВ для запроса от клиента в систему | 2 дней | 28.04.2006 | Аналитик |
| Внесение в систему ТИПОВЫХ ДОГОВОРОВ | 5 дней | 02.05.2006 | Аналитик |
| Реализация отчетов по требованию Банка в дополнение к существующим при поставке | 15 дней | 17.05.2006 | Специалист II |
| Доработка основных интерфейсов по требованиям Банка | 5 дней | 30.05.2006 | Специалист III |
| Интеграция с CALL - центром | 15 дней | 18.05.2006 | Специалист I |
Рис. 18 Этап «настройка системы».
Перечень задач этапа ввода в опытную эксплуатацию расписан в таблице 2:
Этап «ввод в опытную эксплуатацию»
Таблица 2
| Стадия/задача | Длител. | Дата нач. | Ресурсы |
| Этап III. ВВОД В ОПЫТНУЮ ЭКСПЛУАТАЦИЮ | 23.13 дн | 08.06.2006 | |
| Обучение администраторов Заказчика (группы 1-3 человека) | 3 дня | 08.06.2006 | Тренер |
| Инсталляция системы на рабочих местах (25 рабочих мест) | 3 дня | 13.06.2006 | Системный инженер |
| Настройка интеграции с почтовой системой Lotus Notes в части отправки, приема сообщений клиентам, ведение архивов сообщений | 3 дня | 16.06.2006 | Специалист III |
| Загрузка в систему первичных данных о клиентах | 1.5 дня | 21.06.2006 | Специалист III |
| Заведение пользователей и Настройка прав доступа пользователей | 4 дня | 22.06.2006 | Аналитик |
| Подготовка Документации (РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ, ДОКУМЕНТАЦИЯ ПО ДОРАБОТКАМ) | 10 дней | 08.06.2006 | Технический писатель 2 |
| Обучение конечных пользователей Заказчика (25 человек) | 3 дня | 22.06.2006 | Тренер |
| Опытная эксплуатация системы | 10 дней | 27.06.2006 | Аналитик |
| Подписание протокола по итогам тестовой эксплуатации | 1 час | 11.07.2006 | Руководитель проекта со стороны банка Руководитель проекта |
Этап ввода в промышленную эксплуатацию описан в таблице 3 и представлен на рис.19:
Ввод в промышленную эксплуатацию
Таблица 3
| Стадия/задача | Длител. | Дата начала | Ресурсы |
| Этап IV. ВВОД В ПРОМЫШЛЕННУЮ ЭКСПЛУАТАЦИЮ | 2.13 дн | 11.07.2006 | |
| Перенос проекта из ТЕСТОВОЙ ЗОНЫ в БОЕВУЮ | 2 дня | 11.07.2006 | Системный инженер |
| Подписание акта приёма-сдачи работ | 1 час | 13.07.2006 | Руководитель проекта; Руководитель проекта со стороны банка |
Рис.19 Ввод в опытную эксплуатацию.
I.4. Методики выравнивания ресурсов проекта
В предыдущей главе вы познакомились с подробным описанием определения зависимостей между операциями и операцией назначения ресурсов в MS Project.
Определенную трудность составляет определение способа выравнивания ресурсов в рамках проекта, основная опасность таится в возможности получить радикальные изменения в рабочем расписании.
Здесь мы обсудим некоторые способы выравнивания ресурсов.
Менеджеры проектов могут выбирать наилучший для себя метод с целью экономии времени и уменьшения своих разочарований.
Нам известно три метода построения плана проекта, плюс один, который рекомендует MS Project. Каждый метод предлагает различные способы построения зависимостей и выравнивания ресурсов:
- "Легкий" путь: введите операции, затем изменяйте стартовые даты операций для выравнивания ресурсов.
- Метод "Управляемый зависимостью": все операции, исполняемые одним ресурсом, соединяются цепочкой "финиш-старт".
- "Традиционный" путь: постройте иерархическую структуру работ (WBS), получите сетевую диаграмму, оцените продолжительность и стоимость операций, назначьте ресурсы, и выравнивайте расписание по ресурсам. Менеджер проекта может использовать этот метод, только исследуя трудно находимые установки.
Есть четвертый метод, указанный в маркетинге MS Project и файлах помощи: создайте ваш план, добавьте ресурсы и зависимости, и запустите алгоритм "авто-выравнивание ресурсов". Не рекомендуется использовать этот метод, за исключением случаев, когда необходимо быстро получить оценку даты завершения проекта. Программное обеспечение создает очень странную последовательность операций. Поэтому поколения закаленных пользователей за долгие годы выработали следующие рекомендации:
- "Если вы увидите клавишу "авто – выравнивания - ресурсов" в меню, никогда не нажимайте ее".
- "Я не люблю использовать "авто – выравнивание - ресурсов". Если Вы хотите использовать это, всегда сохраняйте ваш план перед нажатием на соответствующий пункт меню. Вы никогда не знаете, что произойдет после с вашим расписанием".
Типичная 'Легкая' диаграмма Гантта
Первый метод самый легкий в использовании. Он превосходен для простого, основанного на контрольных точках (milestone) плана или для плана верхнего уровня. Сначала введите все операции WBS. Не заводите никаких зависимостей, назначение ресурсов и объемов работ - по желанию. Введите длительность каждой операции, и установите нулевую длительность каждой контрольной точки.
По умолчанию, каждая операция начинается с даты начала проекта. Введите корректную дату начала каждой операции. Выберите такие даты начала, которые позволяют предшествующим операциям завершаться во время, и это позволит выровнять ваши ресурсы.
Преимущества: быстрое и легкое начало. Для проекта с менее чем 50 операциями, этот метод - самый короткий путь от WBS к расписанию. Чем больше информации вводит менеджер проекта, тем более полезны отчеты MS Project, но почти вся дополнительная информация опциональна.
Недостатки: бремя отслеживания зависимостей и распределения ресурсов падает полностью на менеджера проекта. Простые проекты - хорошие кандидаты, с небольшим количеством зависимостей и простым использованием ресурсов. Единственная ценность MS Project при использовании такого метода - формирование отчетов. Графические и табличные программы для таких случаев обычно лучше, требуя меньше времени и денег.
Метод "Управляемый зависимостью"
Менеджер проектов может управлять датами операций с помощью зависимостей. Зависимости могут даже приводить к выравниванию ресурсов. Сначала активируйте опцию MS Project "автосвязь задач" (auto-link tasks) в диалоговом окне Опции (Options). Постройте WBS проекта. Если один человек исполняет несколько задач, введите их последовательно. Позвольте MS Project связывать задачу #1 с задачей #2, с задачей #3, и так далее. Назначьте ресурсы на каждую из задач. Удаляйте зависимости только тогда, когда Вы изменяете ресурсы. Например, ресурс A будет исполнять задачи от #1 до #7. Ресурс B будет исполнять задачи от #8 до #12. Удалите зависимость между 7 и 8, и оставьте связанным вместе от 1 до 7, и от 8 до 12 (рис.20).
Рис.20.Управляемая зависимостью сетевая диаграмма изображает схематически, кто на какой работает операции
Для этого метода знания длительности операций абсолютно необходимы, а оценки объемов работ очень желательны. MS Project вычислит дату завершения каждой операции. Цепочки зависимых задач выровнены по ресурсам, причем все ресурсы отдают 100% своего рабочего времени на каждую операцию от начала до конца. Создайте контрольные точки, чтобы отметить даты начала работы ресурса, и сделайте первое назначение зависимым от контрольной точки. Если дата контрольной точки изменится, все последующие операции сдвинутся вперед или назад во времени. Введите рабочие календари для каждого ресурса, и MS Project распределит операции относительно отпусков. Если фактическая доступность рабочего времени изменит даты начала и завершения, все операции в плане, на которые назначен такой ресурс, будут сдвинуты вперед или назад.
Недостатки: MS Project постоянно изменяет даты. Менеджер проекта должен внимательно контролировать план, отслеживая нежелательные автоматические изменения.
Выравнивание ресурсов работает только, если каждый ресурс назначен на полную загрузку только на одну операцию. Ресурсы, которые исполняют более одной задачи одновременно, расстраивают расписание.
Преимущества: Относительно легкая диагностика проблем расписания; следуйте по цепочкам работ в расписании. Зависимости легко запомнить, потому что они соответствуют назначениям на работы.
Даже если реальное исполнение проекта не соответствует жестким зависимостям в плане, MS Project часто выстраивает оставшиеся работы разумным, выровненным по ресурсам образом. Например, ресурс начинает как задачу #1, так и задачу #2 в одну и ту же неделю, даже при том, что в расписании операция #2 зависит от #1, финиш-старт. Остающаяся работа на задаче #2 автоматически смещается после 100% завершения задачи #1.
Менеджер проекта может также добавлять логические (т.н. "жесткие") зависимости, и MS Project будет поддерживать их. Например, если ресурс B не может начать задачу #12, пока ресурс А не завершит задачу #3, MS Project будет задерживать дату начала задачи #12 на время задержки даты завершения задачи #3. Управляемые ресурсами зависимости и необходимые (логические) зависимости поддерживаются одинаково в программе. Для контроля, добавьте колонку, называемую "Уникальный ID Предшественника" в представлении Гантта. Запишите уникальный ID для всех жестких зависимостей либо в описании операции, либо в текстовом поле каждой операции.
MS Project начинает назначения, когда ресурсы становятся доступны. Если задача #1 требует 4.25 часов для завершения в понедельник, то задача #2 получит ровно 3.75 часа в понедельник, заполняя восьмичасовой день. Это автоматически обеспечивает полную загрузку ресурсов.
"Традиционный" Путь
Третий метод обеспечивает самый высокий уровень управления. Он использует зависимости и ясно показывает распределение ресурсов без многочисленных автоматических изменений расписания. Начните с основной WBS, без зависимостей. Добавьте ресурсы, оценки объемов работ, и длительности каждой операции.
Создайте сетевую диаграмму. Создайте две контрольных точки: "старт проекта" и "финиш проекта." Все, что может реально начаться в любое время, должно быть зависимо от "старт проекта". Все, что может случиться в любое время вплоть до последней минуты - предшественник для "финиш проекта". Между этими двумя операциями каждая операция должна быть частью цепочки, которая начинается со "старта проекта" и завершается "финишем проекта". Используйте контрольные точки для выделения больших количеств зависимостей. Например, если пять задач должны завершиться прежде, чем четыре другие задачи могут начаться, создайте контрольную точку с наглядным названием, например "сборка завершена", с пятью задачами в роли предшественников и четырьмя задачами в роли последующих (рис.21).
Рис. 21 Традиционная сетевая диаграмма показывает только логические зависимости, помогая менеджеру сравнить альтернативы расписания и назначений ресурсов.
Назначения ресурсов не должны влиять на эти зависимости, так что они должны оставаться довольно статичными на стадии исполнения. По контрасту, во втором, "управляемом зависимостью" методе, зависимости изменяются каждый раз, когда ресурс переназначается. Сетевая диаграмма - полезная, постоянная карта проекта. Она показывает не изменяющиеся взаимосвязи операций.
Диаграмма Гантта покажет оптимистическую дату завершения проекта. Операции назначены без учета ограничений ресурсов. Добавление выравнивающих задержек сглаживает загрузку ресурсов.
Выравнивающие задержки позволяет менеджеру проекта точно управлять началом и завершением каждой операции без дополнительных зависимостей и фиксации даты старта. Выравнивающая задержка - скрытое поле, которая существует в двух местах: уровень задачи и уровень назначения ресурса:
- Уровень задачи самый легкий для применения, но самый трудный для управления. Просто добавьте колонку "Выравнивающая задержка" в диаграмме Гантта, или используйте представление "диаграмма выравнивания". Введите количество часов или дней задержки, и вся операция сдвинется во времени. К сожалению, задержка должна быть в АСТРОНОМИЧЕСКИХ днях или часах. Астрономические дни не учитывают нерабочее время и отпуска. Менеджеру проектов придется регулировать эти задержки вручную при изменении дат старта и финиша операций.
- Выравнивающая задержка на уровне назначений ресурсов может быть введена для каждого ресурса, назначенного на операцию. Она может быть задана часами или днями работы. Это обеспечивает гибкость выравнивания для любой работы. Если два человека назначены на задачу, но только один перегружен на 4 часа, задержите перегруженный ресурс на 4 часа. Дата старта работы другого ресурса не изменится. Однако чтобы задержать всю операцию, каждый ресурс, назначенный на операцию, должен быть задержан. Для упрощения сопровождения назначайте один и только один ресурс на операцию.
Выравнивающая задержка измеряется для зависимых задач. Например, если и задача #4, и задача #5 зависят от задачи #3, заканчивающейся в понедельник, они обе без задержки начнутся во вторник. При определении двухдневной задержки для #5, задача #4 начнется во вторник, а #5 начнется в четверг. Если дата завершения #3 сдвинется на вторник, даты старта зависимых задач сдвинутся на пятницу и среду.
Комбинируя % загрузки и выравнивающие задержки, менеджер проекта может точно смоделировать сложную работу. Люди могут исполнять много задач одновременно, участвовать во многих цепочках зависимых задач, и при этом полностью использовать все рабочее время и ни часом больше.
Недостатки: Этот метод трудоемок. Для создания организованной сетевой диаграммы большого проекта требуется много времени. Гораздо легче создавать зависимости, чтобы операции начинались в определенном порядке, вместо вычисления выравнивающих задержек и ввода их для каждой задачи. Менеджер проекта должен регулировать задержки в каждом отчетном периоде.