Выбор информационной системы управления проектами

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

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

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

и их совместная потребительская ценность значительно возрас­тает.

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

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

Кроме того, как правило (90 % всех компаний), все отчетные документы ведут уже в Word и Excel, то есть используют все тот же продукт Microsoft — MS Office.

По этому пути дальнейшего использования продуктов Microsoft и придется идти дальше — поэтому для управления проектами я рекомендую пользоваться все-таки именно MS Project [10].

Просто для успешной организации проектного офиса на ос­нове популярного MS Project необходима его интеграция с MS Share Point Team Services (см. табл. 1.5). Это даст возможность легко управлять версиями документов и обеспечит необходимое управление записями по качеству. Другой важный аспект — MS Share Point позволяет вам создавать виртуальные простран­ства для совместной работы.

Еще большее усиление синергетического эффекта наблюдает­ся со средствами групповой работы (обеспечение эффективных внутренних коммуникаций) на базе MS Outlook и MS Exchange (см. рис. 1.26).

Рассмотрим теперь, как можно реализовать требования более продвинутой для управления проектами модели обеспечения ка­чества СММ при организации проектного офиса на примере его реализации в среде MS Project (табл. 1.8).

Таблица 1.8

Матрица реализации требований модели СММ [3]

при управлении проектами [9] с использованием

информационной системы управления проектами (ИСУП),

построенной в среде MS Project [10]

Уровень модели СММ	Процессы	Комментарии
Уровень 1 — началь­ный (Initial)	Не определены	Неуправляемая разработка
Уровень 2 — повторяемый (Repeatable) Г	Управление требованиями (Requirements Management)	При изменении требований изменяется и план в MS Project. Требования документированы и выкладываются в проектную библиотеку MS Project
Планирование проектов (Software Project Planning)	Все задачи проекта документируются в виде плана в MS Project. Все дополнительные требования потребителя документируются в виде запросов на изменения (CR) в проектной библиотеке и отража­ются в корректировках плана в MS Project
Отслеживание пла­на и периодический контроль (Software Project Tracking and Oversight)	Документируется статус задач по резуль­татам мониторинга плана, Результат проектного аудита можно фик­сировать в MS Project в папке QA проект­ной библиотеки. Для этих целей можно использовать Windows SharePoint Services
Субконтрактное управление (Software Subcontract Management)	Менеджер и исполнитель достигают договоренности о сроках (ценах) задачи. Задача может быть принята в план только при обоюдном согласии. Можно использовать Team Inbox (Team Assign) для автоматизации согласования плана в MS Project
Уровень модели СММ	Процессы	Комментарии
	Контроль качества (Software Quality Assurance)	Проводится анализ результатов проекта с документированными требованиями к ним. Результаты испытаний или тестиро­вания оформляются актом или про­токолом и рассылаются РП и исполни­телям. Требуется документировать ошибки в виде баг-листа и производить регрес­сивное тестирование. Протокол и акты выкладываются в про­ектную библиотеку MS Project
Управление вер­сиями и конфигу­рациями продукта (Software Configuration management)	До1сументируются изменения продукта в различных версиях. Существует описание отличий продукта от базовой версии. Во всех проектных документах ведется лист изменений, и все проектные доку­менты находятся в проектной библиотеке MS Project. Для этих целей можно использовать Windows SharePoint Services
Уровень 3 — определенный (Defined) i	Настройка организационной структуры на процесс разработки (Organization Process Focus)	Приводится в соответствии с технологией
ведения проектов организационная струк-
ра компании (создаются необходимые подразделения, перераспределяется от­ветственность). Ведется общий учет как проектной ин­формации, так и организационных меро­приятий, таких как обучение, апробиро­вание новых технологий. Производится стоимостная оценка задач, оценка новой трудоемкости процедур, сводятся результаты обучения, собира­ются планы всех групп. Данная информация должна быть размещена в централизованной базе данных проектного офиса, на основе этой

Продолжение #

Таблица 1.8 (продолжение)

Уровень	Процессы	Комментарии
модели СММ
		статистики производится сравнительный анализ организации проектной деятель­ности. Для этих целей можно использовать Windows SharePoint Services. В качестве базы совместного планирова­ния можно использовать MS Project Central. Необходимо создать в нем межпроектный пул ресурсов
Описание органи-	Документируется стандартный процесс
	зационного процес-	разработки.
	са разработки	Документы и статистика по организации
	(Organization	процесса собираются в едином хранилище
	Process Definition)	MS Project на проектном сервере. Для этих целей можно использовать Windows SharePoint Services. Периодически по результатам статистиче­ских наблюдений за выполнением планов и стоимостей работ производится пере­смотр элементов стандартного процесса разработки
Программа	Согласно потребностям проектов и со-
	обучения	ставляется программа обучения.
	(Traning Program)	Ведется учет результатов тестирований и сертификации. Производится периодический аудит про­грамм обучения. Если не зарезервировать время на обуче-
		ние, то персонал будет самообучаться для
проектньх целей.
		Это приведет к "непонятным" потерям
времени (неуправляемости проекта), низ-
		кому качеству получения знании. Процесс обучения отражается в MS Project в виде задач
Интегрированное	При планировании проектов используется
	управление проек-	документированный стандарт процесса
	тами и технологией	разработкп.
Уровень модели СММ	Процессы	Комментарии
	(Integrated Software	По документированной процедуре, прила­гающейся к технологии разработки, ис-
	Management)	пользуется оценка рисков, критического пути, стоимости и продолжительности работ. Разрабатываемые планы учитываются в специальной базе данных проектного сервера. Полезна выработка шаблонных докумен­тов для ТЗ, договора, устава проекта и т. д. Для оценки рисков по PERT-технике и определения критического пути можно использовать MS Project
Технология разработки	Документируется технология разработки. Описанные технологические стадии ис-
	(Software Product Engineering)	пользуются при планировании. Технология должна описывать аналитику (прототипирование, декомпозиция, моде­ли, сценарные описания), хранение ис­ходных текстов версии системы, кодиро­вание (структурирование и повторное ис­пользование), тестирование и верифика­ция (модульное, интеграционное и сис­темное тестирование, инспекции кода,
		тесты соответствия, организация доку­ментирования). На базе документированной технологии строится план. Ведется учет дефектов, выявляемых тестированием, и результа­тов рецензирования проектных докумен­тов (Peer Reviews).
		В MS Project необходимо выделить от­дельные технологические стадии (анали-
			тика, проектирование и т. д.) в виде кон­трольных точек (Mile Stone)
Межгрупповое	Требования пользователя утверждаются
	управление (Intergroup Coordination)	для реализации в продукт всеми группами разработки.

Таблица 1.8 (продолжение)

Уровень	Процессы	Комментарии
модели СММ
		Руководитель проекта отслеживает выяв­ление проблем и мониторит их статус при помощи задач подготовки статус-отчетов в MS Project
Периодический	Производится технологический аудит со-
	осмотр технологи-	стояния проектов.
	ческого состояния	Выявленные дефекты регистрируются,
	(Peer Reviews)	Проводится рецензирование всех проект­ных документов в проектной библиотеке MS Project
Уровень 4 —	Метрический	Вычисляются эталонные статистические
управляемый	процесс управления	показатели (метрики) стандартного про-
(Managed)	разработкой	цесса разработки или внедрения.
	(Quantitative Process	На основе сравнения с ними ведется
	Management)	управление проектами.
		Для этих целей можно использовать
	Windows SharePoint Services.
		На данном этапе нужно воспользоваться накопленной статистикой ведения проек­тов в MS Project.
		Построив статистические отчеты по раз-
	личным технологическим стадиям, можно
		получить реальные и проверенные прак­тикой оценки трудоемкостей. Их следует использовать в качестве эта­лонных при последующем планировании в MS Project
Управление	Разрабатывается и мониторится план
	качеством	обеспечения качества — QA-план.
	(Software Quality	Ведется статистический анализ различных
	Management)	параметров качества процессов к вне­дряемой системы. Полученные данные сравниваются с эта­лонными показателями, На основе полученных данных вносятся коррективы в технологический процесс и методы реализации проектов. На данном этапе необходимо ннтиегриро-вать базу регистрации дефектов с SQL
Уровень модели СММ	Процессы	Комментарии
		Server и получить статистику по видам дефектов. Результаты публикуются в библиотеке MS Project
Уровень 5 —	Предотвращение	-Ведется анализ и статистический учет
оптимизи­рованный	дефектов (Defect Prevention)	причин возникновения проблем или де­фектов.
(Optimizing)		Выявленные причины ранжируются по приоритетам и устраняются организаци-
		онными мероприятиями. Результаты корректирующих действий
		документируются в проектной библиотеке MS Project.
		Для этих целей можно использовать Windows SharePoint Services
Управление	Производится плановое апробирование
	сменой технологии	новых технологии.
(Technology Change Management)	Результаты апробирования регистриру­ются.
		Производится плановое внедрение новых технологий, которые показали высокие результаты. Для целей регистрации результатов апро­бирования можно использовать Windows SharePoint Services

Такая ИСУП позволит:

• иметь актуальную и достоверную картину хода проекта в части:

— плановой (например, на 1—2 месяца вперед) загрузки че­ловеческих и материальных ресурсов компании по депар­таментам;

— фактической загрузки человеческих и материальных ре­сурсов компании по департаментам;

• создать корпоративную базу знаний (документов) по управ­лению проектами для использования лучшей практики, кор-

поративных шаблонов, библиотек проектных документов, метрик задач в новых (последующих) проектах;

• получить отчетность и аналитику по всем проектам компа­нии для своевременного принятия решений по проблемам, рискам, конфликтам ресурсов:

— отчет по отклонениям проектов от запланированных сро­ков и затрат в текущих проектах;

— отчеты по плановой и фактической загрузке ресурсов и утилизации ресурсов;

— отчет по освоенному объему (экспериментально);

• сократить издержки на проведение аудитов проектов.

В целом здесь уместно привести пример варианта типичного регламента выполнения проекта при реализации ИСУП на базе MS Project [10].

1. РП составляет план в Microsoft Project. Этот шаг обязатель­ный, остальные шаги могут быть пройдены лишь выбороч­но, в зависимости от потребностей управления.

2. MS Project автоматически калькулирует бюджет под план.

3. РП рассылает план исполнителям (Team Assign), аналити­кам и топ-менеджерам (инвесторам). примеч. спонсор проекта

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

5. Аналитики (эксперты, менеджеры по качеству и т. д.) видят через Internet Explorer только те параметры плана, на кото­рые они имеют права (Views). С помощью автоматического анализа статистических показателей (Data Mining, OLAP, SQL Reports...) аналитики дают заключение о риске и рен­табельности плана. Заключение отсылается менеджеру.

6. План РП попадает в портфель (Portfolio) планов топ-менед­жеров (инвесторов), которые через браузер или MS Project

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

7. После автоматизированного согласования базовый (Base Line) план сохраняется и начинается работа.

8. РП постоянно просматривает состояние работ по различ­ным критериям и не вмешивается, если все идет в рамках стандартных отклонений (Deviation).

9. Исполнители сами могут создавать новые задачи в плане, передавать задачи друг другу (New Task, Delegate Task). Эти правила игры устанавливаются заранее и отслеживаются MS Project Centra]. Фактически исполнители дополняют план менеджера по ходу дела. У менеджера в почтовом ящике сто­ит робот (Rules), который автоматически обрабатывает со­общения исполнителей и вносит по ним коррективы в план.

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

11. Исполнители присылают отчеты о ходе выполнения работ (Team Update), это сообщения также обрабатываются робо­том, который вносит отметки об исполнении в план.

12. Исполнители не могут «забыть» отчитаться о работе, так как периодически у них в принудительном порядке запрашивает отчет система (Periodical Status Reports). РП может, анализи­руя их, получить «сводку боевых действий»: что достигнуто, какие новые цели, какие проблемы требуют вмешательства.

13. После завершения плана аналитики делают анализ откло­нений (Deviation) и уточняют статистические характери­стики исполнения планов по срокам (Duration), трудоемкостям (Work), стоимостям (Cost) и т. д. Эти данные будут

использованы для оценки рисков и рентабельности в даль­нейшем.

14. Аналитики, применяя средства Data Mining из MS SQL Server 2000, выявляют ранее неизвестные закономерности в ходе выполнения планов и разрабатывают специфические SQL-отчеты по различным характеристикам проектов.

15. Топ-менеджеры и аналитики могут просматривать проект­ную информацию для принятия решений в произвольных аналитических разрезах через Internet Explorer с помощью OLAP Services из MS SQL Server 2000.

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

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

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

Реализация, например, процедуры управления стоимостью проекта (бюджетирование проекта) при помощи ИСУП на базе MS Project представлена на рис. 1.30.

Матрица метрик, сбор которых можно обеспечить с помощью отчетов MS Project, представлена в табл. 1.9.

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

Метрика	Описание возможности реализации измерения
Количество этапов (фаз) проекта, N	Реализуемо с помощью внешнего программирован™. Нужно написать SQL-запрос к БД и вывод данных в Excel
Количество отдельно опла­чиваемых этапов (фаз) проекта, N1	Реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel
Общее количество задач в проекте, и	Реализуемо стандартными средствами в Web Access
Среднее количество задач в одном этапе (фазе) проекте, n1	Реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel
Процент реализован­ных рисков	Для WSS реализуемо с помощью внешнего программиро­вания. Нужно написать SQL-запрос к БД и вывод данных в Excel
Процент решенных проблем	Для WSS реализуемо с помощью внешнего программиро­вания. Нужно написать SQL-запрос к БД и вывод данных в Excel
Количество докумен­тированных запросов на изменения (CR),ml	В плане надо ввести для задач признак CR или, еще лучше, заложить в код признак CR, тогда реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel
Процент проектных документов, про­шедших рецензию	Теоретически реализуемо, но требуются организацион­ные изменения с помощью внешнего программиро­вания. Нужно написать SQL-запрос к БД и вывод данных в Excel
Процент увеличения срока выполнения проекта	Реализуемо стандартными средствами в Web Access

Таблица 1.9 Матрица метрик, сбор которых можно обеспечить с помощью

отчетов MS Project

Метрика	Описание возможности реализации измерения
Процент увеличения себестоимости про­екта	Реализуемо стандартными средствами в Web Access для внутренней себестоимости трудозатрат
Общая плановая длительность про­екта, Г	Реализуемо стандартными средствами в Web Access
Средняя плановая длительность выпол­нения задачи про­екта, t	Реализуемо с помощью внешнего программиро­вания. Нужно написать SQL-запрос к БД и вывод данных в Excel

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

Рассмотрим, как организуется такой мониторинг на реальном примере проектно-ориентированной компании (табл. 1.10).

Решение о необходимости проведения корректирующих дей­ствий принимается на основании анализа причин появления от­клонений или несоответствий и степени влияния этих несоот­ветствий на качество проекта и функционирование СМК.

Отчеты по корректирующим действиям проверяются:

• Д ЦУП при проведении последующих внутренних прове­рок проектов;

• РСК при проведении последующих внутренних аудитов СМК;

• РП в дальнейшем ходе проекта;

• РПД в ходе их производственной деятельности.

Результаты корректирующих действий анализируются на за­седаниях руководства, и анализ документируется в протоколах заседаний (табл. 1.11).

* Д ЦУП — директор ЦУП, РСК — руководитель службы качества (СК), РПД — руководитель проектного департамента (или подразделения). Для таб­лиц 1.10 и 1.11.

Основание	Документ,	Ответст-	Ответст-	Форма
	являющийся	венный	венный за	отчетности
	основанием	за решение	контроль	(запись
		о необходи-- мости	выпол­нения	о проведении)
Анализ жало-	Зарегистриро-	РПД	РПД	Протокол рабо-
бы потреби-	ванный доку-			чего совещания
теля или по-	мент произ-			по проекту
ставщика	вольной формы, содержащий жалобу потре­бителя или по­ставщика
Отклонение,	Программа (про-	Д ЦУП	РП	Программа (про-
обнаруженное	токол) — отчет			токол) — отчет
в результате	по внутренней			по внутренней
внутренней	проверке про-			проверке пpoeкra
проверки про-	екта
екта
Отклонение,	Программа	РСК	РПД	Программа (про-
обнаруженное	(протокол)—			токол) — отчет
в результате	отчет по внут-			по внутренней
внутренней	ренней проверке			проверке СМК
проверки	СМК
СМК
Несоответ-	Служебная за-	РСК	РПД	Отчет СК по ана-
ствие, обна-	писка или доку-			лизу СМК
руженное со-	мент произволь-
трудником	ной формы со-
компании	трудника компа­нии РПД

Таблица 1.10

Мониторинг и анализ корректирующих

и предупреждающих действий*

Основание	Документ,	Ответствен-	Ответст-	Отчетность
	содержащий	ныи за ре-	венный за
	необходимые	шение о не-	выпол-
	данные	обходимости	нение
Результаты	Отчет отдела мар-	Генеральный	РПД	Бизнес-план
опроса потре-	кетинга: «Анализ	директор		компании
бителей	удовлетворенно­сти потребителей»
Результаты за-	Отчет отдела мар-	Генеральный	РПД	Бизнес-план
казных и собст-	кетинга по марке-	директор		компании
венных марке-	тинговым иссле-
тинговых ис-	дованиям
следовании
Анализ тенден-	Отчет ЦУП:	ЦУП	РПД	Отчет СК по
ций, обнару-	«Анализ показа-			анализу СМК
Основание	Документ,	Ответст-	Ответст-	Форма
	являющимся	вениый за	венный за	отчетности
	основанием	решение	контроль	(запись
		о необходи­мости	выпол­нения	о проведении)
Несоответст-	Статус-отчет	РП	РП	Протоколы
вие, обнару-	о ходе проекта.			совещаний по
женное при	Протоколы со-			проекту.
выполнении	вещании по про-			Форма реги-
проекта	екту			страции про­блемы
Управление	Шаблон устава	РП	РП	Описание дейст-
рисками про-	проекта с базо-			вии по предот-
ектов	вым перечнем рисков			вращению рис­ков в уставе про­екта. Статус рисков в статус-отчетах по ходу проекта
Основание	Документ,	Ответствен-	Ответст-	Отчетность
	содержащий	ный за ре-	венныйза
	необходимые	шение о не-	выпол-
	данные	обходимости	нение
женных в ходе	телей выполнения
выполнения	проектов»
проектов
Анализ тенден-	Отчет СК по ана-	РСК	РПД	Отчет С К по
ций, обнару-	лизу СМК			анализу СМК
женных в ходе
мониторинга
бизнес-процес-
сов и СМК
Анализ воз-	Шаблон устава	РП	РП	Таблица кон-
можных рисков	проекта с оазовым			кретных рис-
при выполне-	перечнем рисков			ков npoeкrra
нии проекта				в уставе

Результаты анализа базы данных выполненных проектов и тен­денций в ходе выполнения проектов и функционирования БП СМК обобщаются в ЦУП в виде внутренней составляющей ис­ходных данных для отчета по анализу СМК.

СК после согласования с ЦУП выносит эти результаты в отчет по анализу СМК на заседание руководства.

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