Основные этапы создания стандарта управления проектами

Основные этапы создания стандарта  управления проектами

 

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

 

Рис. Этапы создания стандарта  управления проектами

 

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

Концепция управления проектами является основополагающим документом системы управления проектами (СУП) предприятия, обосновывающим деловую необходимость создания СУП (включая экономическую эффективность внедрения), определяющим ее основные параметры и результаты, стратегию реализации и развития, объем автоматизации и используемые информационные технологии.

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

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

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

В процессе создания проектного офиса можно выделить следующие этапы::

1. Определение целей бизнеса, целей создания проектного офиса в компании.
2. Классификация проектов выполняемых на предприятии. Выявление общих и отличительных характеристик.
3. Выделение, описание и оптимизация ключевого бизнес-процесса в рамках создаваемого проектного офиса.
4. Формирование соответствующей организационной структуры для решения поставленных задач, достижения целей.
5. Оценка соответствия текущего состояния компании требуемому, формирование плана перехода к «новому» состоянию.
6. Внедрение методологии проектного управления, внедрение инструментария
7. Разработка положений, инструкций, систем мотивации.
• разработка Положения о Проектном Офисе;
• регламентирующего деятельность Проектного офиса;
• принципы взаимодействия с другими подразделениями компании по вопросам УП;
• альбом бизнес-процессов посредством которых Проектный офис осуществляет свою деятельность;
• разработка Должностных инструкций сотрудников Проектного Офиса;
• разработка Квалификационных требований к сотрудникам ПрОф.
8. Мониторинг процесса перехода к «новому» состоянию. Корректировка процессов, положений, инструкций.

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

 

Плана управления проектом

 

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

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

В Плане управления проектом должно быть отражено

• Содержание и границы проекта - цели и задачи проекта, основные результаты, критерии оценки того, что работа или ее часть выполнена.
• Ключевые вехи проекта - основные события проекта (milestones) и план их достижения, возможно, с использованием структуры декомпозиции работ (WBS).
• Плановый бюджет проекта
• Предположения и ограничения - предпосылки, на основе которых делались оценки сроков выполнения, трудоемкости работ проекта и стоимости, включая описание начальных рисков.
• Требования и стандарты - перечень нормативных и регламентирующих документов или их отдельных положений, которые следует соблюдать в ходе выполнения работ проекта.
• Подходы к выполнению проекта - концепция предполагаемого решения (возможно несколько альтернативных вариантов), методы разработки и базовые информационные технологии.
• Организационная структура - ответственность и порядок взаимодействия участников, имена и обязанности ключевых фигур проекта.
• Управление проектной документацией - структура, среда хранения и процедура создания и сопровождения репозитария документов проекта, перечень шаблонов документов.
• Управление отклонениями - процедуры работы с рисками, с возникающими проблемами и изменениями, форм соответствующих проектных документов.
• Обеспечение качества - перечень и регламенты проведения мероприятий, направленных на обеспечение качества, как результатов проекта (продукта), так и процессов управления проекта и выполнения работ.
• Контроль и отчетность - регламент проведения мероприятий по анализу состояния проекта, соответствующие формы отчетности.

Преимущества типовых шаблонов

• экономия на консультантах,
• унификация подходов,
• сокращение времени на подготовку документации проекта.

Недостатки 

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

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

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

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

• Классификация по предметным областям и по продуктам в рамках этих областей позволяет специализировать разделы Содержание и границы, Ключевые вехи, Требования и стандарты. Эту классификацию можно выстроить по иерархическому принципу. Например, "информационные технологии" - "проекты системной интеграции" - "создание интегрированных систем управления проектами".
• Классификация по масштабности проекта позволяет специализировать разделы Организационная структура , Управление отклонениями, Обеспечение качества. Для построения этой классификации могут использоваться различные основания - территориальная разбросанность, как это принято в Enron Corp., или стоимость проекта (IBM), может быть, какие-то другие основания и их комбинации.
• Классификация по форме оплаты и, следовательно, учета работ позволяет специализировать Контроль и отчетность, Управление проектной документацией на основании таких форм контрактов как "Время и материалы" и "Фиксированная цена".

Таким образом, можно вести речь, например, о шаблоне "План управления проектом создания концепции (продукт) информационной системы (предметная область) стоимостью свыше $ 100 тыс. (масштабность) с контрактом в форме "время и материалы" (форма оплаты и учета работ)", как о макрошаблоне, получаемом простой сборкой из нескольких более мелких (микро) шаблонов отдельных разделов Плана. Кроме того, в макрошаблон должны быть включены и некоторые дополнительные разделы, которые не могут быть определены на микроуровне (такие, например, как "Сроки работ по этапам"). Микрошаблоны могут быть глубоко специализированными - насколько это позволяет соответствующая классификация и накопленный на предприятии опыт.

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

При формировании Плана (шаблона Плана) часто используют структуру декомпозиции работ (WBS – Work Breakdown Structure), а многие ведущие компании включают в свои методологии и стандарты типовые WBS как в явном виде (Andersen Consulting), так и неявно (IBM).

 

Структура декомпозиции работ

 

Провести декомпозицию и составить  структуру декомпозиции работ (WBS – Work Breakdown Structure) по утверждению некоторых  авторов очень легко: "Прежде всего, следует разбить проект на несколько  подпроектов. Каждый из подпроектов, в  свою очередь, может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нужный уровень детализации" (Цитируем по статье М. Ньюэлла "Структура декомпозиции работ" в мартовском номере журнала "Директор информационной службы" за 2001 г.).

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

На стадии инициализации проекта  руководитель проекта должен ответить на целый ряд вопросов (на самом  деле их, конечно, гораздо больше, но мы ограничимся этими):

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

На какие же подпроекты следует  разбить исходный проект? Что будет удобнее видеть на первом уровне декомпозиции - компоненты ИС (программные, технические, информационные) или технологические этапы (концепция, техническое задание, проектирование и т. д.)? А может быть удобнее сгруппировать работы по исполнителям или по заказчикам?

Например, если работы проекта выполняются  в интересах различных Заказчиков и, в то же время, финансируются различными Инвесторами (см. Рис.) декомпозиция может  выполняться либо по содержательному  признаку отнесения работ к проектам, либо по формальному признаку отнесения работ к договорам финансирования. Другой случай - фиксация в структуре работ участия субподрядчиков. Тогда для этапа календарного плана проекта формально выделяются группы работ, выполняемые основным исполнителем (Подрядчиком) и другими исполнителями (Субподрядчиками). Такую декомпозицию целесообразно применять, если за субподрядчиками закреплены крупные логически взаимосвязанные блоки работ, относительно независимые от других работ проекта.

 

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

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

А следовательно, первое, что должно быть отражено в специализированном шаблоне WBS, это какие альтернативные взгляды на структуру декомпозиции работ должны поддерживаться в проекте (взгляд руководителя проекта, взгляд куратора, взгляд инвестора и т.д.).

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

 

Планирование и контроль качества в проекте

 

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

Планирование качества осуществляется как часть процесса планирования проекта в целом. Результаты планирования качества проекта (план по качеству проекта) должны отражаться в Плане управления проектом.

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

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

 

Регламент

 

СУП  предприятия реализует основной внутренний закон функционирования предприятия в области проектного управления — т.е. регламент предприятия в области УП.

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