<<
>>

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


Примерно 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 нии проекта в уставе Результаты анализа базы данных выполненных проектов и тенденций в ходе выполнения проектов и функционирования БП СМК обобщаются в ЦУП в виде внутренней составляющей исходных данных для отчета по анализу СМК.
СК после согласования с ЦУП выносит эти результаты в отчет по анализу СМК на заседание руководства.
Руководство компании анализирует рассмотренные на этих заседаниях данные и на их основе вырабатывает план предупреждающих действий.
<< | >>
Источник: Ильин, Владислав Владимирович.. Руководство качеством проектов. Практический опыт. 2006

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

  1. 19. ИНФОРМАЦИОННЫЕ ПРАВООТНОШЕНИЯ, ВОЗНИКАЮЩИЕ ПРИ СОЗДАНИИ И ПРИМЕНЕНИИ ИНФОРМАЦИОННЫХ СИСТЕМ, ИХ СЕТЕЙ, СРЕДСТВ ОБЕСПЕЧЕНИЯ И МЕХАНИЗМОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
  2. 39. ПОРЯДОК СОЗДАНИЯ И ПРИМЕНЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ И ИХ СЕТЕЙ. ИНФОРМАЦИОННЫЕ СИСТЕМЫ СВЯЗИ: ИНТЕРНЕТ, ЭЛЕКТРОННАЯ ПОЧТА, ЦИФРОВАЯ СВЯЗЬ И ДР
  3. 54. ГОСУДАРСТВЕННАЯ ПОЛИТИКА В ОБЛАСТИ СОЗДАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ, ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И СРЕДСТВ ИХ ОБЕСПЕЧЕНИЯ
  4. 52. ПРАВОВОЙ РЕЖИМ ИНФОРМАЦИОННЫХ СИСТЕМ, ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И СРЕДСТВ ИХ ОБЕСПЕЧЕНИЯ
  5. Глава 40. ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В ТАМОЖЕННОМ ДЕЛЕ
  6. 7.2. Ос-новные этапы проектирования и выбор инвестиционного проекта
  7. 4.8. Оценка эффективности инвестиционных проектов и выбор схемы финансирования
  8. 17. ИНФОРМАЦИОННЫЕ ПРАВООТНОШЕНИЯ, ВОЗНИКАЮЩИЕ ПРИ ОСУЩЕСТВЛЕНИИ ПОИСКА, ПОЛУЧЕНИЯ И ПОТРЕБЛЕНИЯ ИНФОРМАЦИИ, ИНФОРМАЦИОННЫХ РЕСУРСОВ, ИНФОРМАЦИОННЫХ ПРОДУКТОВ, ИНФОРМАЦИОННЫХ УСЛУГ
  9. Погорелый С.А. Управление проектами, 2004
  10. Процесс планирования и управления проектом