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

воскресенье, 7 октября 2007 г.

Системы управления проектами. Валерий Вязовой, http://www.project.km.ru

Системы управления проектами
Валерий Вязовой, http://www.project.km.ru/
“Неудачное планирование – планирование неудачи” Б. Трейси.

Как модно нынче стало слово “проект”… “новый проект модного клипмэйкера Васи Пупкина!” (ничего личного); “менеджер проекта Вася Пупкин” (уже интересней). Так что такое проект? Очень многие рассматривают проект как набор чертежей, расчетов и технических текстов. Проект в смысле Design. И они правы. Мы же будем рассматривать проект в смысле Project, т.е. как временное предприятие, направленное на достижение определенной цели. Отсюда мы попытаемся сформулировать (формализовать) понятие “управление проектами” - это любые воздействия, помогающие оптимально (чуть не сказал “наиболее оптимально) достичь цели.
Если быть совсем дотошным, можно сказать, что управление проектами (project management) насчитывает столько же лет, сколько и человечество. И это действительно так, согласитесь. Просто методы и средства были разными. Точнее сказать, они эволюционировали.


Исходные позиции
В основе современных методов управления проектами лежат методики сетевого планирования, разработанные в конце 50-х годов в США. В 1956 г. М.Уолкер из фирмы "Дюпон", исследуя возможности более эффективного использования принадлежащей фирме вычислительной машины Univac, объединил свои усилия с Д.Келли из группы планирования капитального строительства фирмы "Ремингтон Рэнд". Они попытались использовать ЭВМ для составления планов-графиков крупных комплексов работ по модернизации заводов фирмы "Дюпон". В результате был создан рациональный и простой метод описания проекта с использованием ЭВМ. Первоначально он был назван методом Уолкера-Келли, а позже получил название Метода Критического Пути - МКП (или CPM - Critical Path Method).
Параллельно (1958г.) и независимо консалтинговой фирмой "Буз, Аллен энд Гамильтон" для реализации проекта разработки ракетной системы "Поларис" был разработан метод анализа и оценки (пересмотра) программ PERT (Program Evaluation and Review Technique). На его разработку, по заявлениям фирмы, ушло 15 лет, таким образом, начало работ относилось к 1943г.
Идеи, сходные с идеями, положенными в основу системы PERT, были еще в 30-х годах предложены в советском капитальном строительстве (на строительстве Магнитогорского металлургического комбината), но в то время они не получили распространения и для них не были произведены необходимые математические разработки.
Однако это не означает, что в нашей стране идеи метода никого не интересовали. Благодаря усилиям С.П. Никанорова, в 60-е годы Министерство обороны в лице подведомственных институтов активно занялось разработками в этой области.
Если вспомнить, сколько стоил в то время вычислительный ресурс – становится понятным, что только крупные корпорации и правительства могли использовать эти методики.
С течением времени и удешевлением вычислительного ресурса, Системы управления проектами стали более распространенными.
Хочется сразу расставить точки над i и определить, о чем пойдет речь. В данной статье мы не будем рассматривать Корпоративные информационные системы (КИС) и интегрированные системы управления предприятием. Мы рассмотрим более узкий круг. То, что традиционно называется системами управления проектами (СУП).

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

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

Как правило, СУП делятся на системы начального уровня, к которым, учитывая их функционал, наиболее применим термин Системы календарного планирования и контроля (СКПК) и профессиональные системы управления проектами. Хотя в последние три года отмечается устойчивая тенденция “подрастания” систем начального уровня к профессиональным пакетам и еще более активное расширение функциональности последних, цены на системы из разных групп могут заметно различаться. Если СКПК попадают в диапазон $200-800, то профессиональные СУП могут стоить заметно больше $5000.
В настоящее время существует несколько сотен систем, так или иначе, реализующих функции СКПК. Однако разнообразная “заточенность” и “раскрученность” их делают свое ограничительное дело. Реально, на российском рынке стабильно присутствует не более 10 систем. Среди них есть и отечественные разработки.

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

  • Поддержка расписания из неограниченного количества операций (вы встречали такое расписание в практике?) с учетом приоритетов операций, расчет критического пути, вычисление резервов времени; длительность в часах, днях, неделях или комбинированная;
  • Умение работать с пользовательскими календарями для операций и ресурсов;
  • Поддержка всех видов связей, типов работ (task, milestone, hammock), типов ресурсов (возобновляемые, не возобновляемые);
  • Способность работать с иерархической структурой работ (WBS – Work Breakdown Structure);
  • Возможность выполнения выборки, сортировки, группировки, суммирования, по кодам WBS и ID работ;
  • Поддержка основных видов визуального представления (диаграмма Ганта, PERT-диаграмма, таблица работ/ресурсов, таблица связей, гистограммы ресурсов).


Для обмена проектными данными между СКПК очень часто используется формат обмена данными mpx. По сути, он представляет из себя структурированный текстовый файл, с запятыми в качестве разделителя. Недостатком этого формата является отсутствие возможности передавать данные, поддержки которых нет в MS Project.

MS Project (разработчик - Microsoft)

Этот пакет используют для планирования своих проектов около 3 миллионов людей. Его стандартный офисный интерфейс позволяет быстро научиться использовать продукт. Ранние версии этого продукта не особенно блистали своей функциональностью, однако версия MS Project 2000 радует своими обширными возможностями интеграции с другим ПО от Microsoft. Главное отличие версии MS Project 2000 от предыдущих версий - Microsoft Project Central. Это приложение для совместного управления проектами с помощью средств WEB, позволяет организовать двухсторонний обмен данными между всеми участниками проекта, а также предоставления информации лицам у которых не установлен Microsoft Project 2000.
К примеру, поддерживается обмен информацией с Outlook. менеджер проекта имеет возможность передать исполнителям данные о задачах, которые необходимо выполнить, а те, в свою очередь, могут информировать его обо всех изменениях в рабочем календаре. Кроме того, пользователи MS Outlook 2000 имеют возможность просматривать всю проектную информацию из этого приложения. Явный, на взгляд автора, недостаток последней версии – прекращение поддержки формата mpx.


Time Line (разработчик - Time Line Solutions)

Очень многие компании в нашей стране, в том числе и строительные, начинали свой путь к внедрению систем управления проектами именно с этого продукта. Этот пакет начал продаваться еще в начале девяностых. Были локализованы две версии - 5.0 для DOS и 1.0 для Windows. Отличная функциональность и при этом простота использования, сделали его весьма распространенным пакетом. Очень хорошей, по тем временам, была возможность создание вычисляемых пользовательских полей. В дистрибутив пакета входит генератор отчетов Crystal Report.
В 1995 году, уже под лейблом Symantec, была выпущена версия 6.5 для Windows. Недостатком этой версии можно считать не очень хорошо реализованный принцип WYSIWYG. На этом развитие пакета, к сожалению, остановилось. Локализированной версии выпущено не было. По сведениям компании, занимавшейся продвижением Time Line на российском рынке, продажи его прекращены около 2 лет назад.
SureTrak Project Manager (разработчик – Primavera inc. / представитель в России – ПМ СОФТ).
Являясь, младшим (и самым дешевым – стоимость в России за 5 лет осталась неизменной $700) продуктом в семействе Primavera, ST позиционируется как продукт начального уровня для управления несложными проектами в небольших компаниях. Умеет читать формат mpx и сохранять в нем проектные данные. Интерфейс – вполне стандартный. Очень хорошо реализован принцип WYSIWYG и масштабирование временной оси при отображении диаграммы Ганта. Совместим с MAPI-совместимыми системами электронной почты (умеет отправлять с помощью них данные проектов). Встроенный wizard “Быстрый старт” проектов помогает создать систему кодов для типовых проектов (правда до её четвертого шага доходить весьма нудно и незачем).
Весьма скромные минимальные системные требования: процессор 386 и выше, 4 МВ RAM, 15 МВ свободного дискового пространства, Windows 3.x, NT, 95, или OS/2. При установке под NT или Windows 2000, требуется дополнительно скачать и установить драйвер для hasp-ключа. Для активного продвижения на отечественном рынке этот пакет был полностью локализован. В российском варианте поставки русскоязычный интерфейс, система помощи и руководство пользователя. Из особенностей можно отметить удобную функцию “луч” (Progress Spotlight). При выделении на временной оси (диаграмме Ганта) временного промежутка, в таблице работ выделяются цветом операции, выполнение которых запланировано в этот временной интервал. SureTrak имеет как собственный формат данных, так и без каких либо дополнительных настроек “понимает” формат P3. В настоящее время представлен версией за № 2.0.
СУП для профи
В отличии от СКПК, профессиональные системы управления проектами в своей функциональности уже заметно отличаются друг от друга. И это, как правило, уже не отдельные программы, а комплексы, в состав которых входят различные утилиты и модули, предназначенные для решения специфических задач.


Primavera Project Planner (разработчик – Primavera inc. http://www.primavera.com/ представитель в России – ПМ СОФТ http://www.primavera.msk.ru/).
Для построения интегрированной системы управления проектами компания Primavera inc. предлагает несколько продуктов. Для использования на нижних уровнях управления уже упоминавшийся SureTrak Project Manager, профессиональный пакет управления проектами Primavera Project Planner (P3) для работы со сложными многоуровневыми иерархическими проектами и систему масштаба предприятия, работающую по технологии клиент/сервер Primavera Project Planner for the Enterprise (P3e).
В качестве системы управления контактами, предлагается полностью локализованный Expedition; обеспечивать доступ к проектной информации используя Интернет призван Webster for Primavera.
Такое разнообразие может сбить с толку, поэтому мы рассмотрим Primavera Project Planner (P3) как продукт, наиболее близкий к теме данного обзора.
Интерфейс системы – стандартный, оконный. Локализация коснулась всего, кроме системы меню (названия полей, встроенные отчеты, руководство пользователя). В версии 1.0 было ограничение на количество одновременно открытых проектов – не более 4, однако в следующих проектах это ограничение снято. В поставке - несколько десятков стандартных шаблонов представления проекта (в документации - макетов (layout)), пользователю предоставляется возможность создавать и сохранять собственные макеты. Поставляемый в составе пакета генератор отчетов Report Smith позволяет создавать любые табличные и графические отчетные формы. Иерархическая организация проекта по произвольной комбинации кодов. Радует отличная реализация принципа WYSIWYG при выводе отчетов на печать.
Для моделирования проекта доступен обширный набор инструментов, включающий в себя до 20 уровней WBS и 16 пользовательских полей данных. Реализованы 9 типов работ (задача, веха, гамак, встреча и др.), все типы зависимостей между работами; 10 типов ограничений. Текущее расписание проекта может сравниваться с неограниченным числом базовых планов.
Развита функция глобальной замены для внесения изменений в данные проекта с использованием логических, арифметических и строковых выражений.
Для управления ресурсами и стоимостями доступны все, стандартные для такого класса продуктов, инструменты. Стоимости ресурсов во времени, а так же их пределы потребления могут быть различными. Особенно интересной представляется возможность создавать собственные профили использования ресурсов в дополнение к 10 существующим.
Структура статей затрат может поддерживать неограниченное количество счетов с 12 разрядным кодом.
В пакете реализован анализ отклонений хода работ от запланированного Методом освоенного объема (Cost/Schedule Control System Criteria - C/SCSC) и прогнозирование основных параметров проекта. В качестве средства анализа рисков предлагается продукт Monte Carlo. Он позволяет оценить вероятность выполнения проекта в заданные сроки в пределах бюджета.
Р3 умеет читать формат mpx и сохранять в нем проекты. Кроме того, имеется экспорт данных в форматы dBase и Lotus. Для двустороннего обмена данными с удаленными пользователями предназначена функция Primavera Post Office.
В целом можно сказать, что Р3 – функционально развитый и удобный инструмент.


Open Plan - разработчик – Welcom Software Technology http://www.wst.com/ / представитель в России – A-Project Technologies (в настоящее время – Департамент управления проектами холдинга “Ланит” http://www.projectmanagement.ru/)
Этот продукт позиционируется как профессиональная система управления проектами масштаба предприятия. Выпускается в трех версиях: Enterprise, Professional и Desktop. По сведениям специалистов из A-Project Technologies версия Enterprise в России еще не поставлялась.

Интерфейс продукта весьма оригинален. Рабочее пространство представлено в виде нескольких рабочих столов, на которых помещаются ярлыки к стандартным объектам (файлы проектов, календарей, ресурсов, кодов, шаблонов), так и к любому файлу. При открытии проекта открывается “записная книжка проекта” - набор рабочих столов с ярлыками к файлам, непосредственно относящимся к проекту. В поставку входит несколько десятков наиболее распространенных шаблонов представления проекта. Применение шаблона к проекту осуществляется простым перетаскиванием нужного ярлыка на записную книжку проекта. Отдельного упоминания заслуживает функция “Директор Управления Проектами” (ДУП). ДУП это инструментарий автоматизации повторяющихся процессов при управлении проектами. Объектами ДУП могут быть не только стандартные формы, представления и процедуры Open Plan, но и объекты из других приложений, например, текстового редактора, электронных таблиц, CAD. В поставке – 35 стандартных шаблонов ДУП, разбитых, согласно рекомендациям PMI (http://www.pmi.org/) на 8 категорий. Естественно, есть функция создания и сохранения пользовательских шаблонов представления и шаблонов ДУП.
В продукте весьма развита система ресурсного планирования. Реализовано два базовых метода расчета расписания:
Ресурсное планирование при ограниченном времени – приоритетной является необходимость придерживаться общей даты завершения проекта при попытке минимизировать степень перегрузки ресурсов. В результате ресурсы могут быть перегружены.
Ресурсное планирование при ограниченных ресурсах – приоритет отдается предотвращению перегрузки ресурсов, даже если это приведет к выходу проекта за рамки расписания. При этом замедляется завершение проекта на столько, на сколько это необходимо для полного избежания перезагрузки ресурсов.
Реализован тип материальных ресурсов с ограниченным сроком хранения. При назначении исполнителей на операции можно указывать требуемую квалификацию или альтернативный ресурс и тогда, при ресурсном планировании, система предложит наиболее оптимальный, с точки зрения загрузки, ресурс.
Благодаря иерархической организации ресурсов, можно создавать любые структуры статей затрат.
Следует особо отметить, что функция анализа рисков – встроена в систему, тогда как в некоторых продуктах она поставляется как отдельный модуль. Для длительности избранных или всех работ проекта вводятся оптимистическая и пессимистическая оценки. Далее по методу Монте-Карло определяется вклад вероятностей в даты проекта.
Возможности сортировки, фильтрации, создания пользовательских полей и глобальной замены традиционно сильны для продуктов такого класса. Можно пользоваться стандартным набором или создать собственные. Различий в интерфейсе версий нет. Open Plan Desktop ограничен функционально. В ней присутствуют все функции для планирования и контроля за выполнением проекта, но нельзя работать с внешними подпроектами, создавать пользовательские поля, отчеты, шаблоны представлений, изменять настройки процедур ДУП, выполнять анализ рисков.
Стоимость Open Plan Professional около $ 6000, версии Desktop ~ $1000 (могут меняться в зависимости от комплекта поставки).
При использовании собственного формата хранения данных, разграничение уровней доступа к проектным данным производится с помощью специальной утилиты SysAdm. Если же данные проектов хранятся с использованием СУБД, эти операции должны выполняться средствами СУБД. В системе имеется встроенная функция создания архива проекта (backup) в одном файле. Хотелось бы отметить, что формат файлов хранения данных проекта открыт и описан в Руководстве разработчика.
В состав продукта входит модуль Web Publisher, с помощью которого осуществляется публикация данных проекта на веб-сервере. Этот модуль хотя и делает свое дело, но его реализация далеко не идеальна.
В качестве системы управления бюджетом проектов Welcom Software Technology предлагает продукт Cobra.
Совместное использование Cobra с Open Plan или с другой СУП позволяет построить интегрированную систему управления календарным графиком и затратами проекта.
Spider Project (разработчик/представитель в России – компания “Технологии управления “Спайдер”, http://www.spiderproject.ru/)
Без преувеличения можно сказать, что Spider Project лучшая отечественная система управления проектами. Версия под DOS появилась еще в 1992 году. От версии к версии заметно улучшается не только интерфейс системы, но и ее функциональность. Текущей является версия 7.23 под Windows 9x/NT/2000.
Минимальные требования к системе: процессор i486 или выше; операционная система Windows (95, 98, 2000, NT); оперативная память не менее 32М; свободное место на диске для установки программы не менее 25М, свободное место на диске для хранения проектов около 1500К на каждые 1000 операций проекта.
Рабочее пространство главного окна разбито на три функциональные зоны (см. скриншот). В левой её части – ярлыки к открытым проектам. В средней части – 16 ярлыков на шаблоны представления и данные проекта. В правой части располагаются ярлыки на открытые документы проекта. Документ проекта можно создать из текстовых файлов, html-файлов или файлов баз данных.

У этого продукта много отличий от западных собратьев, однако основным из них является подход к определению длительности операций. В большинстве известных пакетов операции характеризуются длительностью их исполнения. В Spider Project наряду с длительностями можно задавать физические объемы работ на операциях. Длительность определяется пакетом в процессе составления расписания работ в зависимости от производительности назначенных ресурсов. В связи с этим, имеется отличие и в определении задержек на связях операций. Наряду с положительными и отрицательными временными задержками, реализованные во всех пакетах, можно использовать и объемные задержки. Дело в том, что с временными задержками может возникнуть ситуация, когда работа началась, но исполняется медленнее, чем было запланировано и временная задержка может исчерпаться раньше, чем будет выполнен запланированный объем работ.
Кроме отдельных ресурсов можно задавать мультиресурсы и пулы.
Мультиресурсы - это группы ресурсов, которые выполняют работы вместе (например, бригада). Мультиресурсы можно назначить на исполнение операций целиком, что означает назначение всех ресурсов, которые в них входят. Пулы - это группы взаимозаменяемых ресурсов.
Пакет позволяет использовать неограниченное количество составляющих стоимости, причем в разных валютах. Так же можно создать неограниченное количество различных иерархических структур работ и ресурсов.
Для анализа исполнения проекта, а также для анализа “что если” очень важно иметь возможность сохранять прежние версии проекта и иметь возможности для сравнения и анализа отклонений текущей версии проекта от предыдущих. В Spider Project есть возможность хранить неограниченное количество версий проекта и анализировать ход исполнения работ не только по сравнению с какой-то базовой версией, но и с любой другой.
Расчет расписания проекта методом критического пути производится без учета ограничения по ресурсам и имеет точное математическое решение. Если же при расчетах учитывается ограниченность ресурсов, то понятие резервов, в том числе и полного резерва (total float) теряет смысл. В Spider Project вычисляется ресурсный критический путь и резервы сроков исполнения операций с учетом ограниченности ресурсов.
Алгоритм анализа рисков так же отличается от реализованного в других системах. При моделировании рисков в качестве исходной информации используются не оценки длительности (оптимистические, пессимистические), а оценки производительности ресурсов.
Непривычно, но достаточно продумано, реализована поддержка групповой работы над проектом. В Spider Project нет одновременного доступа на изменение данных. Ответственный за свою часть проекта (фазу) представляет менеджеру проекта свои файлы. И решение принять или отвергнуть изменения остается за менеджером проекта. Именно такое решение, по мнению разработчиков, позволяет избежать неразберихи при изменении проектных данных, и, как следствие, траты времени на вылавливание багов. С этих позиций разработана и система групповой работы через интернет.
Система взаимодействия между участниками проекта с использованием внутрифирменной Intranet или Internet по следующему механизму:
созданная главным менеджером полная версия проекта передается на сервер с указанием списка пользователей и уровня доступа тех, которым она предназначается,
пользователи системы согласно включенным в список ограничениям по доступу к проектам, могут получить план проекта – только для чтения или его фазу (подфазу) для управления реализацией,
в результате выполнения функции управления пользователь передает измененный план (фазы, подфазы) обратно на сервер, откуда он может быть получен руководителем проекта.
При обращении к серверу система проводит идентификацию пользователя, обеспечивая, таким образом, разграничение доступа к проектам.
Обмен данными между сервером и клиентами осуществляется с использованием протокола FTP, что позволяет развернуть систему на любой платформе. Проект отправляется на сервер непосредственно из пакета при выборе пункта меню "Отправить". FTP сервер служит таким же хранилищем проектов, как и другие директории (Рабочее, Центр, Архив) - входя на сервер, пользователь видит список доступных для него проектов и открывает их прямо в Спайдере.
Взаимодействие между участниками проекта можно осуществлять через несколько серверов. Например, главный менеджер отправлять проекты может на один сервер, а получать с другого.
Spider Project поддерживает OLE (в визуальные представления можно вставлять текст и графику).
Экспорт данных проекта в другие приложения осуществляется с помощью формата csv.
Так же следует отметить хорошую справочную систему продукта, в которую, помимо руководства пользователя включен переработанный русский перевод PMBok (Project Management Body of Knowledge).
На веб-сайте компании доступна демо-версия продукта, умещающаяся на 4 трехдюймовых дискетах. Демо-версия ограничена количеством работ в проекте – 40 без учета фаз и отсутствием функций экспорта данных.
Из наиболее известных проектов, при управлении которыми применялся Spider Project, называются строительство в 1997г. Олимпийской деревни для Всемирных Юношеских Игр в Москве (бюджет $250 млн), строительство Каспийского трубопровода, реконструкция Рязанского НПЗ.
Плата за популярность?
Все большая потребность компаний в системах управления проектами подтверждается не только присутствием разработчиков и продавцов на IT-шных (Softool) и специализированных (“Управление-2000”) выставках, но и интересом к ним бутлегеров. Многие из описанных систем при желании, можно найти на “Горбушке” или в интернете. Конечно, об этом знают и разработчики. Причем отмечается две позиции:
“Пусть воруют – нам нужна лишняя реклама; серьезным пользователям нужна поддержка, а за ней к нам придут”. Такую позицию занимают разработчики системы Spider.
Усиление и усложнение систем защиты от копирования. Если ранние версии систем (P3 1.0 и OpenPlan 2.1) защищались только ключом (hard key), то следующие версии (OpenPlan 2.5) имеют изощренные инсталляторы с привязкой к hard’у и последующим получением кода авторизации непосредственно у разработчиков.
Оценку адекватности взглядов разработчиков оставим читателю.
Камни в огород
По оценкам специалистов, основным недостатком западных систем, с точки зрения российских традиций управления, является отсутствие понятия “объем работ”. Планирование осуществляется в терминах продолжительности операции (original duration). И если в одних типах проектов (инновационные) это не проблема, то в других, в частности, строительных, создание модели проекта без применения понятия “объем работ” - заведомое признание того, что модель имеет большие допущения.
Возможные решения этой проблемы:
Радикальный – использовать системы, в логике алгоритмов которых изначально присутствует понятие “объем работ”. Примером такой системы может служить отечественная разработка Spider (http://www.spiderproject.ru/).
Другое решение – более гибко.

Искусственная реализация понятия “объем работ”. Можно изменить структуру базы данных проекта или воспользоваться встроенными пользовательскими полями и логически связать их с проектными данными с помощью встроенных макроязыков или внешних программных модулей.
Выбор системы
Если потребность бизнеса приведет вас к решению о внедрении СКПК, перед вами встанет вопрос выбора той или иной системы. Очень советую вспомнить мысль о названии яхты и ее плавании.
Наилучшим методом автору представляется такой: построить матрицу, строки которой – необходимые вам функции и ваши требования к системе, а в столбцах – оценки рассматриваемых систем. Причем не оценки, взятые из рекламных буклетов и различных сравнительных таблиц”, надерганных с сайтов разработчиков, а оценки выставленные пользователями.
Требования могут быть, например, такими:
  • “нам обязательно нужен русский интерфейс пользователя”,
  • “как хранит данные проекта система – в собственном формате или она умеет работать с СУБД; а нужно ли нам это умение”.

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

Дата публикации: 18.01.2001 Последнее изменение: 05.07.2002

http://www.cfin.ru/software/project/pms-review.shtml

Управление возможностями — инициация проектов. Дмитрий А. Шепелявый

Управление возможностями — инициация проектов
Дмитрий А. Шепелявый Директор по управлению проектами компании «Информзащита»По материалам сайта http://www.pmsoft.ru/

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

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

Инициация (старт) проекта проходит через следующие стадии:

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


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

Компании часто недооценивают стадию инициации, сразу приступая к планированию (в лучшем случае), или к реализации (обычная практика). Однако, значение инициации трудно переоценить — именно на этой стадии происходит обоснование проекта и анализ достижимости его целей. Недостаточное внимание к этим шагам чаще всего приводит к распылению усилий компании на хаотичные инициативы без видимого результата. В итоге реальные проблемы компании остаются нерешенными, а возможности — упущенными.
Попытаемся проанализировать каждый из этапов инициации проекта с точки зрения их влияния на управление проектами.
Всякий проект должен начинаться с обоснования — формулировки проблемы, которую надо решить, или возможности, которую надо использовать для получения конкурентного преимущества. Важным фактором является необходимость осознания всеми заинтересованными участниками проекта наличия проблемы или возможности для роста. Согласитесь, трудно лечить человека, если он не осознает, что болен. Аналогично: трудно ожидать от участников проекта самоотверженной работы, если они не знают цели проекта.
Естественно, процесс обоснования внешних проектов, т. е. проектов, выполняемых по заказу внешних организаций, довольно сильно отличается от обоснования внутрикорпоративных проектов. Вкратце рассмотрим эти различия.
С обоснованием проектов, которые компания проводит для внешних клиентов, обычно проблем не возникает. Если планируемая операционная прибыль от проекта или перспективные доходы от будущих проектов c этим клиентом укладываются в нормативные значения, то проект считается обоснованным. Если это не так, то обоснованность проекта сомнительна. Основная трудность при инициации внешних проектов — слишком позднее получение исполнительными подразделениями информации о проекте. Нередки ситуации, когда исполнители узнают о проекте уже после подписания договора, когда ничего изменить или отложить уже нельзя. Довольно частым заблуждением менеджеров по продажам является уверенность в готовности остальных сотрудников выполнить любой объем работ в любые поставленные сроки, обеспечив при этом отличное качество. Заблаговременное информирование о потенциальных проектах позволит заранее подготовиться к их реализации, спланировав эффективное использование ресурсов.
Обоснование внутренних проектов, т. е. проектов, которые компания реализует для себя с целью улучшения своей деятельности, разработки новых продуктов, проведения маркетинговых исследований, выглядит не столь очевидным. Одним из решений в данном случае может быть «держание руки на пульсе» — постоянный анализ рынка, генерирование и обсуждение новых идей, пристальное внимание к проблемам компании, информирование сотрудников. Организация никогда не должна быть удовлетворена ни своим положением на рынке, ни построением своей работы. Первые признаки успокоения являются и первыми признаками упадка компании — ослаблением хватки немедленно воспользуются конкуренты.
Обратная сторона постоянного потока информации, идей и проблем — желание взяться за все и сразу. В результате чаще всего не получается ничего и никогда. Распыление ресурсов на хаотичную деятельность не позволяют решить главных проблем, требующих немедленного внимания. Выходом в данной ситуации может быть проверка потенциальных проектов на соответствие стратегии компании. Данная рекомендация может показаться абстрактной и трудновыполнимой в условиях быстроменяющегося рынка, когда подробная стратегия устаревает быстрее, чем на ней высыхают подписи руководства компании. Однако, если компания хотя бы определит свое позиционирование на рынке (вариантами могут быть инновационность, низкие цены, комплексное решение проблем заказчика), то она сможет производить первоначальный отбор проектов и без подробно прописанной стратегии.
Следующий этап инициации проекта – определение ожидаемых результатов проекта. Одним из самых понятных критериев успешности проекта, естественно, является финансовый критерий, например отдача на затраты или операционная прибыль. Для проектов, нацеленных на выполнение внешнего заказа, этот критерий является и основным. При подборе адекватных финансовых показателей проекта главным является исключение из этих показателей характеристик, напрямую не связанных с проектом. Например, учет в прибыльности IT-проекта общекорпоративных административных издержек компании-исполнителя способен исказить показатели прибыльности проекта, и, как следствие, привести к неадекватной оценке успешности работы менеджера проекта. Возможная система финансовых оценок IT-проекта может быть основана на использовании валовых показателей прибыльности, принимающих во внимание только прямые затраты данного проекта. Это позволяет оценить деятельность менеджера проектов в области его прямой ответственности, т. е. без учета административных расходов, амортизации, налогов — характеристик, обычно находящихся вне влияния менеджера проекта.
Если использование только финансовых показателей по каким-либо причинам затруднительно (например, если проект связан с созданием системы мотивации персонала или деятельностью в области PR), на помощь приходит методология Balanсed scorecard, которая является прекрасным руководством по формулированию и контролю измеримых целей деятельности компании. Не претендуя на исключительную новизну, данная система позволяет упорядочить, а главное, сделать измеримыми и взаимосвязанными многочисленные показатели работы компании (от финансовых до маркетинговых и мотивационных). Нет необходимости говорить, что оценка успешности любой деятельности возможна только при наличии измеримого показателя такой успешности.
Очередной этап инициации — анализ достижимости целей проекта — часто является болевой точкой большинства компаний. Причина в том, что решение о принятии проекта в работу часто принимается без расчета реальной прибыльности, полезности, и, главное, анализа наличия ресурсов для выполнения проекта. Принцип «ввяжемся, а там будет видно» может принести тройной убыток. Во-первых, в силу отсутствия ресурсов, компания может не ответить по взятым на себя обязательствам и потерпеть финансовые убытки, во-вторых — организация может не реализовать более выгодные для себя проекты из-за занятости ресурсов заведомо невыполнимым проектом, а в-третьих компания может понести имиджевые потери из-за ненадлежащего качества выполнения проекта. А, как известно, репутация приобретается долго и трудно, а теряется быстро и легко.
Однако, ошибкой было бы полагать, что если цели проекта кажутся недостижимыми в силу отсутствия ресурсов, то следует отказаться от проекта. Наоборот, это лишь повод для выработки вариантов действий, направленных на то, чтобы сделать проект выполнимым. Основными опциями при этом являются следующие:
Начать проект раньше планируемых сроков. Не исключено, что необходимые ресурсы, отсутствующие на планируемый момент начала работ, могут быть доступны раньше сроков обычного выполнения проекта. Естественно, при выборе такого варианта риски проекта возрастут. Например, в случае, если компания начинает работу по проекту раньше подписания официального договора с заказчиком, возможны финансовые потери при отказе заказчика от проекта. При принятии решения о досрочном начале проекта компания должна сравнить риски незаключения контракта с рисками возможных трудностей исполнения проекта из-за нехватки ресурсов.
Купить ресурс. Примером подобного подхода является наем дополнительного персонала. Такой подход хорош, если набранных сотрудников можно занять в следующих проектах. Иначе при завершении проекта затраты на оставшихся без дела сотрудников можно смело списывать на потери. А для грамотного и социально ответственного сокращения персонала также требуются немалые затраты.
Нанять (арендовать) ресурс. Если ожидаемый недостаток ресурсов носит временный характер (например, только для данного проекта), а также, если компания не имеет требуемых компетенций, разумным вариантом действий является временный наем (прокат) ресурсов. Примером этого подхода служит субподряд или аутсорсинг выполнения части проекта. Положительной чертой такого подхода по сравнению с покупкой (постоянным наймом) являются сравнительно низкие затраты на привлечение и высвобождение ресурсов, что повышает гибкость этого подхода. Отрицательным является необходимость наличия четкой системы договоренностей и контроля действий субподрядчика. Кроме того, при привлечении субподрядчика повышается вероятность утечки конфиденциальной информации, а также ноу-хау и наработок компании.
Оптимизировать состав работ или сроки проекта. Если расширение ресурсной базы или досрочное начало по каким-либо причинам невозможно, вариантом действий может быть попытка оптимизации (например сокращения) требований к составу работ или срокам проекта. Поскольку этот вариант действий затрагивает интересы заказчика, прибегать к нему нужно только при невозможности решить проблему отсутствия ресурсов другими методами.
Интересной дилеммой при принятии решения об участии в проекте является выбор между отказом от проекта и снижением качества работ при невозможности достичь выполнимости целей проекта описанными выше методами. Чаще всего компании выбирают снижение качества, естественно, не объявляя об этом открыто. Ведь отказ от проекта влечет немедленные финансовые потери, а снижение качества может сказаться только в будущем. Перед тем, как высказать точку зрения на эту дилемму, приведем определение качества из стандарта управления проектами PMBOK 2000. Качество — это удовлетворенность спецификациям и пригодность к использованию. Таким образом, сделанный в соответствии с техническим заданием и пригодный к использованию продукт по определению является качественным. Принятое в некоторых компаниях понятие качества, как достижение некоего абстрактно идеального результата является неверным. Стремление достичь ненужного для заказчика качества, просто напрасная трата денег заказчика и ресурсов компании. А вот снижение качества за пределы приемлемого уровня, т. е. невыполнение четко определенных требований заказчика или непригодность результата к использованию, действительно, является недопустимым. И при осознании того, что именно этот результат (недопустимое снижение качества) является ожидаемым в случае принятия проекта, от этого проекта, конечно, лучше отказаться. Репутация дороже.
На основании понимания ожидаемого результата и анализа достижимости целей проекта компания принимает решение, будет ли она участвовать в этом проекте. Решение желательно оформить официально, чтобы обосновать планирование и подготовку к реализации проекта.
После принятия решения необходимо также определить приоритетность данного проекта по отношению к уже идущим и прочим потенциальным проектам. Показатель приоритетности проекта является хорошим основанием для решения потенциальных ресурсных конфликтов, которые могут возникнуть в ходе проекта. Входными данными для определения приоритетности могут являться характеристики проекта, значимые с точки зрения специфики бизнеса компании. Например, это может быть потенциальная доходность проекта, его политическая важность, новизна проекта для компании, риски проекта.
Немаловажным шагом при инициации проекта является как можно, раннее назначение менеджера проекта и четкое обозначение времени старта. С этого момента проект считается начатым, менеджер проекта получает полномочия и ответственность за успешность этого проекта.
В заключение хотел бы подчеркнуть, что четкая и ответственная инициация проектов позволит компаниям сконцентрировать свои усилия на проектах, наиболее полно соответствующих целям текущей деятельности и развития.
Финансовые показатели проекта

Показатель
Комментарии
1.
GM(Gross Margin) Валовая прибыль
Показывает разницу ($) между доходами и прямыми расходами проекта без учета корпоративных накладных расходов.
Данная величина показывает прибыль проекта в зоне ответственности менеджера проекта
2.
GMROI(Gross Margin Return on Investments) Валовая отдача на затраты
Показывает, какую валовую прибыль компания получила на каждый вложенный в проект рубль/доллар.
Данная величина показывает, насколько эффективными оказались прямые (вызванные непосредственной работой по проекту) затраты на проект.
3.
GMRODL(Gross Margin Return on Direct Labor) Валовая отдача на прямые трудовые расходы
Показывает, какую валовую прибыль компания получила на каждый затраченный час работы сотрудника.
Данная величина показывает, насколько эффективно Компания использует самый дефицитный ресурс — рабочее время сотрудников