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

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

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

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

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

o Primavera Project Planner (P3) (Primavera);

o Microsoft Project (Microsoft);

o Time Line (Time Line Solutions);

o Open Plan (Welcome Software);

o Artemis Views (Artemis Management Systems);

o CA-Super Project (Computer Associates International Inc.);

o Project Scheduler (Scitor Corp.);

o TurboProject (IMSI);

o Project Workbench (Applied Business Technology);

o Spider Project (Технологии управления Спайдер);

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

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

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

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

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

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

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

43. Классификация временных ограничений.

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

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

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

определенной даты.

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

По умолчанию, у каждой задачи уже есть временное ограничение –Как можно раньше (As soon as possible) при планировании от начала,

или Как можно позже (As late as possible) при планировании от окончания. Эти ограничения считаются гибкими, с их помощью можно

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

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

начала и окончания каждой задачи (столбцы Начало и Окончание). При ручном заполнении столбца Начало к задаче применяется

ограничение Начало не ранее (указанной даты), при заполнении столбца Окончание – Окончание не ранее (указанной даты). Эти

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

дату начала задачи – 1 июня, а вы установили дату начала – 15 июня. В итоге получаем «дырку в проекте» длиной в две недели. Также

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

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

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

июня, а этого требуют условия договора, например.

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

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

завершения – 15 июня. В итоге – конфликт.

Что делать, если мы все же нарвались на конфликт планирования? Пересмотреть сроки выполнения работ ДО конфликтной даты.

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

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

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