Идеальное состояние управления качеством - когда управление уже не требует проверки. (Каору Исикава)

Опыт организации проектного офиса

Владислав Ильин

"Если делаешь что-нибудь

неправильно -- не нужно
рассчитывать на

правильный результат."

Народная китайская мудрость

Организация проектного офиса - это прежде всего  показатель зрелости системы управления проектами в компании.

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

Поэтому типичными подразделениями проектного офиса {2, 3} являются -см.Рис. 1:

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

• Методологический отдел, в котором разрабатываются стандарты управления проектами в организации,

• Архив, в котором ведутся архивы проектной документации.

(Информация  по управлению проектами в рисунках   в основном базируется на терминах стандартов ISO 9000 {1} и  PMBOK {2}. Рисунки взяты из репозитария моделей бизнес процессов в среде моделирования ARIS {5})

Рис. 1 Пример Структуры  Проектного офиса  в проектной компании

Именно на  сотрудников Проектного офиса  ложиться обязанность по описанию существующих в организации практик управления проектами и сравнении их с лучшими практиками стандарта (best practices). Таким образом, существенно возрастают методические функции офиса проектов. Кроме того, появляются аналитические функции, связанные с оценкой эффективности применяемых методик и выработкой предложений по их улучшению. Расширение учетных функций происходит за счет того, что необходимо наладить сбор, накопление и обработку метрик: количественных показателей выполненных проектов, что является необходимым условием постоянного совершенствования проектного управления.

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

На Рис. 2 показан пример дерева функций Проектного офиса.

Рис. 2 Пример дерева функций Проектного офиса

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

На  Рис. 3  показан пример распределения ответственности Ролей Проектного офиса и СМК.

Рис. 3 Пример схемы ответственности ролей  Проектного офиса и СМК

На  Рис. 4  показан пример   схемы взаимодействия функционалов  Проектного офиса и СМК.

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

Тайм или ресурс-менеджмент -это управление распределением рабочего времени между сотрудниками (проектными группами) {3}. Как показывает наша  практика, это самая "конфликтоопасная" зона.

Практические задачи которые должен решать  ресурс-менеджмент:

• Анализ первоначальных  ( Base) планов реализации проектов компании,

• Декомпозиция целей проектов до задач конкретным исполнителям,

• Оценка временных затрат на выполнение заданий,

• Распределение заданий среди сотрудников,

• Создание временных резервов, которые будут задействованы при поступлении новых проектов или затягивании работ над старыми,

• Проведение регулярного мониторинга загрузки персонала.

• Контроль над соблюдением сроков сдач работ,

• Предотвращение конфликта ресурсов - при увеличении загрузки персонала до критической -  разнесение проектов во времени.

Эти задачи у нас, например,  решает Группа координаторов, состоящая из ресурс-менеджеров  по каждому проектному подразделению. Принятие решений по управлению ресурсами лежит на Руководителях проектных подразделений, а информацию по  управлению ресурсами для них предоставляет именно группа координаторов - см. Рис. 3

Без этого  на практике у Вас постоянно будут возникать конфликты (недостаток) ресурсов. У компании могут неожиданно появиться новые проекты, которые нужно будет срочно реализовывать. Кроме того, всегда есть риск, что работа над уже имеющимися проектами затянется. Так, по результатам исследований специалистов, около 18% дел, запланированных на день, переносится на более позднее время. В результате конфликта ресурсов сроки сдачи проектов будут постоянно сдвигаться.

Рис. 5 Схема взаимодействия функционалов Проектного офиса и СМК

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

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

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

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

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

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

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

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

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

Просто для успешной организации Проектного офиса на основе популярного  MS Project   необходима его интеграция с MS Share Point Team Services -см. Табл. 1.  Это даст возможность легко управлять версиями документов и обеспечит необходимое управление записями по качеству.  Другой важный аспект - MS Share Point  позволяет Вам создавать "виртуальные пространства" для совместной работы.

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

Рассмотрим теперь, как можно реализовать требования наиболее эффективной  модели в смысле обеспечения качества проекта СММ при организации проектного офиса на примере его реализации в среде MS Project -см. Табл.1

Табл.1 Пример Матрицы реализации требований наиболее эффективной  модели в смысле обеспечения качества проекта- СММ {4} при управлении проектами  с использованием информационной системы управления проектами (ИСУП), построенной в среде  MS Project

Уровень модели СММ	Процессы	Комментарии
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)	Документируются изменения продукта в различных версиях. Существует описание отличий продукта от базовой версии. Во всех проектных документах ведется лист изменений  и все проектные документы находятся в проектной библиотеке MS Project Для  этих  целей  можно использовать Windows SharePoint Services
3 уровень Уровень определеный (Defined)	Настройка организационной структуры на процесс разработки (Organization Process Focus)	Проводится в соответствие с технологией ведения проектов организационная структура компании (создаются необходимые подразделения, перераспределяется ответственность). Ведется общий учет, как проектной информации, так и организационных мероприятий, таких как обучение, апробирование новых технологий. Производится стоимостная оценка задач, оценка новых трудоемкости процедур, сводятся результаты обучения, собираются планы всех групп. Для  этих  целей  можно использовать 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)	Требования пользователя утверждаются для реализации в продукт всеми группами разработки. Руководитель проекта отлеживает выявление проблем и мониторит их статус при помощи задач подготовки статус-отчетов в MS Project.
	Периодический осмотр технологического состояния (Peer reviews)	Производится технологический аудит состояния проектов. Выявленные дефекты регистрируются. Проводится рецензирование всех  проектных документов в проектной библиотеке MS Project
4 уровень Уровень управляемый (Managed)	Метрический Процесс Управления Разработкой (Quantitative Process Management)	Вычисляются эталонные статистические показатели ( метрики) стандартного процесса разработки или внедрения. На основе сравнения с ними ведется управление проектами. Для  этих  целей  можно использовать Windows SharePoint Services На данном этапе нужно воспользоваться накопленной статистикой ведения проектов в MS Project.
	Управление Качеством (Software Quality Management)	Разрабатывается и мониторится План обеспечения качества -QA-план На данном этапе необходимо базу регистрации дефектов интегрировать с SQL Server и получить статистику по видам дефектов результаты публикуются в библиотеке MS Project.
5 уровень Уровень оптимизиро ванный (Optimizing)	Предотвращение дефектов (Defect Prevention)	Ведется анализ и статистический учет причин возникновения проблем или дефектов. Выявленные причины  ранжируются по приоритетам и устраняются организационными мероприятиями. Результаты корректирующих действий документируются в проектной библиотеке MS Project Для  этих  целей  можно использовать Windows SharePoint Services
	Управление сменой технологий (Technology Change Management)	Производится плановое апробирование новых технологий. Результаты апробирования регистрируются. Производится плановое внедрение новых технологий, которые показали высокие результаты. Для целей регистрации результатов апробирования можно использовать Windows SharePoint Services

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

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

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

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

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

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

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

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

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

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

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

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

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

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

№№	Метрика	Описание возможности реализации измерения
1	Количество этапов (фаз) проекта, N	Реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel
2	Количество отдельно оплачиваемых этапов (фаз) проекта, N1	Реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel
3	Общее количество задач в проекте, n	Реализуемо стандартными средствами в Web Access
4	Среднее количество задач в одном этапе (фазе) проекте, n1	Реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel
5	% реализованных рисков	Для WSS реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel
6	% решенных проблем	Для WSS реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel
7	Количество документированных запросов на изменения (CR), m1	В плане надо ввести для задач признак CR или, еще лучше, заложить в код признак CR. Тогда реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel
8	% проектных документов, прошедших рецензию	Теоретически реализуемо, но требуются организационные изменения. С помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel
9	% увеличения срока выполнения проекта	Реализуемо стандартными средствами в Web Access
10	% увеличения себестоимости проекта	Реализуемо стандартными средствами в Web Access для внутренней себестоимости трудозатрат
11	Общая плановая длительность проекта, T	Реализуемо стандартными средствами в Web Access
12	Средняя плановая длительность выполнения задачи проекта,  t	Реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel

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

Рис. 7. Пример аналитического анализа в рамках проектного офиса ( ЦУП)

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

Рассмотрим пример организации  такого мониторинга на реальном примере проектно ориентированной компании.

Организация мониторинга корректирующих и предупреждающих действий

Пример матрицы действий,  документирования, ответственности и отчетности по корректирующим действиям представлен в Табл.3

Примечание к Табл 3 и 4 :Д ЦУП  -директор ЦУП, РСК-руководитель Службы качества ( СК), РПД- руководитель проектного департамента ( или подразделения).

Табл.3

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

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

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

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

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

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

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

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

Пример матрицы действий,  документирования, ответственности и отчетности по предупреждающим действиям представлен в Табл. 4

Табл. 4

Основание	Документ, содержащий необходимые данные	Кто принимает решение о необход.	Кто отвечает за выполнение	Отчетность
Результаты неформального опроса Потребителей (заседания Клуба Потребителей  - "TopS CIO Club)	Отчет Отдела маркетинга : "Анализ удовлетворенности Потребителей по результатам заседаний TopSBI CIO Club "	Ген. директор	РПД	Бизнес план Компании
Результаты  опроса Специалистов ИТ-решений (проведение ERP-форума)	Отчет Отдела Маркетинга "Анализ удовлетворенности Потребителей по результатам проведения ERP-форума"	Ген. директор	РПД	Бизнес план Компании
Результаты заказных и собственных маркетинговых исследований	Отчет Отдела Маркетинга  по маркетинговым исследованиям	Ген. директор	РПД	Бизнес план Компании
Анализ тенденций обнаруженных в ходе выполнения проектов	Отчет ФО и ЦУП:  "Анализ  показателей выполнения проектов".	ЦУП	РПД	Отчет СК по анализу СМК
Анализ тенденций обнаруженных в ходе мониторинга бизнес-процессов и  СМК.	Отчет СК по анализу СМК	РСК	РПД	Отчет СК по анализу СМК
Анализ возможных рисков при выполнении проекта	Шаблон Устава проекта с базовым перечнем рисков	РП	РП	Таблица конкретных рисков проекта в Уставе

(Клуб  Потребителей создан со следующими целями:

• Изучение мнения и пожеланий клиентов и профессионалов, занимающихся внедрением, развитием, эксплуатацией ИТ-систем,  по развитию ИТ- услуг (в неформальной  обстановке),

• Определение имеющихся проблем в развитии ИТ- услуг и путей их решения,

• Получение оперативной информации о  новых технологиях и решениях в области ИТ-индустрии.

Результаты неформального опроса обобщаются в Отделе маркетинга в виде отдельного отчета и передаются для анализа  Руководству компании и в ЦУП ( в виде внешней составляющей исходных данных для отчета по анализу СМК).

Проект компании  - " ERP-форум" -это ежегодная конференция,  в которой принимают участие:

• представители компаний, являющихся потенциальными Потребителями ИТ-услуг;

• представители компаний-Клиентов TopS BI;

• профессионалы различных отраслей бизнеса и информационных технологий,

• руководители подразделений самой компании.)

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

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

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

Литература

1. ISO 9000:2000.Система Менеджмента Качества. Требования.

2.  Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Institute.

3. Либерзон В. И. Основы управления проектами. М., 1997

• Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Model  for Software ( SW-CMM), version 1.1. // CMU/SEI-93-TR-024, - Februaru, 1993.

5. "Инструментарий ARIS. Методы". Файл pdf. Поставляется вместе с демо-версией системы ARIS Toolset.

Также на сайте:
Практический опыт внедрения и сертификации Системы Менеджмента Качества (СМК) по требованиям ISO 9001:2000
Причины трудностей при внедрении системы менеджмента качества и как их решать

О проекте

quality.eup.ru - один из самых старых в рунете ресурсов, посвященных менеджменту качества во всем его разнообразии.

Нам более 7 лет, и все это время ресурс пополняется новыми и новыми материалами, почти ежедневно. Если вы ищете информацию о менеджменте вообще и управлении качеством в частности, скорее всего, вы найдете эту информацию здесь.

Кроме отличной и действительно большой подборки статей, действует живой форум по менеджменту качества.

Реклама на сайте