<<
>>

2.2. План управления проектами и классификация проектов

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

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

Эти вопросы являются особенно важными для предприятий, реализующих комплексные проекты, захватывающие различные предметные области. Характерным примером, в котором в равной степени очевидны и необходимость привлечения «универсального» руководителя проекта, и пути снижения стоимости его «содержания», является проект создания филиала банка. Такой проект включает целый ряд взаимосвязанных и, вместе с тем, относительно независимых подпроектов: юридический, строительный, технологический, ИТ, рекрутинговый, маркетинговый и т. д. В крупных банках филиалы создаются десятками. После одного-двух таких проектов опыт их реализации может оказаться достаточным, для того чтобы сформировать для каждого вида проектов (подпроектов) типовые цели и результаты, типовые календарный и ресурсный планы и бюджет, определить известные риски и эффективные стратегии работы с ними и т. д.

Но как раз эта информация и составляет сущность основного документа, с которого должен начинаться любой проект, — Плана управления проектом (в различных источниках можно найти и другие названия подобного документа: Устав проекта, Определение проекта). Таким образом, могут быть подготовлены специализированные шаблоны Плана управления проектом, фиксирующие совершенно конкретные методы управления проектами, рекомендованные на данном предприятии для данного типа проектов. А вслед за ними и другие типовые шаблоны.

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

Таблица 2.1. Структура типового инвестиционного проекта 1.

Подготовка бизнес-плана (ТЭО) 1.1.

Описание проекта 1.2.

Описание компании 1.3.

Обзор рынка и конкуренции 1.4.

Инвестиционное планирование 1.5.

Операционное планирование 1.6.

Планирование финансового обеспечения 2.

Реализация проекта 2.1.

Образование юридического лица 2.2.

Разработка детального финансового плана 2.3.

Исследования и разработки 2.4.

Набор персонала 2.5.

Приобретение оборудования и технологий 2.6.

Приобретение земли 2.7.

Строительство и монтаж 2.8.

Подготовка производства 2.9.

Обеспечение сырьем 2.10.

Предварительный маркетинг 2.11.

Обеспечение финансирования

независимые проекты, например, пакеты работ второго уровня, показанные в структуре инвестиционного проекта (см.

табл. 2.1).

Отметим некоторые особенности проектов в полученном разбиении: •

проекты относятся к различным профессиональным областям деятельности (юридическая, финансовая, ИТ, строительная, маркетинговая и т. д.); •

проекты имеют различную сложность с точки зрения решаемых задач; •

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

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

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

Содержание и границы проекта — цели и задачи проекта, основные оезультаты, критерии оценки того, что работа или ее часть выпо гаена. •

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

Плановый бюджет проекта. •

Предположения и ограничения — предпосылки, на основе которых делались оценки сроков выполнения, трудоемкости работ проекта и стоимости, включая описание начальных рисков. •

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

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

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

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

Управление отклонениями — процедуры работы с рисками, с возникающими проблемами и изменениями форм соответствующих проектных документов. •

Обеспечение качества— перечет и регламенты проведения мероприятий, направленных на обе» пе 1еяие качества как результатов проекта (продукта), так и процессов управления проектом и выполнения работ. •

Контроль и отчетность — регламент проведения мероприятий по анализу состояния проекта, соответствующие формы отчетности.

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

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

Варианты классификации проектов предприятия

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

Классификация по предметным областям и по продуктам в рамках этих областей позволяет специализировать разделы «Содержание и границы», «Ключевые вехи», «Требования и стандарты». Эту классификацию как раз можно выстроить по иерархическому принципу. Например, «информационные технологии» — «проекты системной интеграции» — «создание интегрированных систем управления проектами».

Классификация по масштабности проекта позволяет специализировать разделы «Организационная структура», «Управление отклонениями», «Обеспечение качества». Для построения этой классификации могут использоваться различные основания — территориальная разбросанность, как это было принято в Епгоп Согр., или стоимость проекта (1ВМ), может быть, какие-то другие основания и их комбинации.

Классификация по форме оплаты и, следовательно, учета работ позволяет специализировать «Контроль и отчетность», «Управление проектной документацией» на основании таких форм контрактов, как «Время и материалы» и «Фиксированная цена».

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

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

Рассмотренные выше примеры классификаций проектов специально подобраны нами для иллюстрации возможности сборки шаблона из относительно независимых стандартных фрагментов (см. рис. 2.3). Однако в реальной жизни встречаются и другие ситуации. Например, в 1ВМ принята классификация проектов по сложности (комплексности). В соответствии с этой классификацией проекты делятся на обычный бизнес Шаблон Плана (макрошаблон) получается как простая сборка микрошаблонов Классификация проектов По предметной области проекта По форме учета и оплаты работ По масштабности проекта План управления проектом Содержание и границы проекта Ключевые вехи проекта Г Плановый бюджет проекта і. j Требования и стандарты Организационная структура і 1 Управление документацией г.::::] Управление отклонениями Обеспечение качества Контроль и отчетность і::::.) Рис. 2.3. От классификации проектов к Плану управления проектом

(Business as Usual — Ball), стандартные проекты системной интеграции и сложные проекты системной интеграции. Причем именно эта классификация является определяющей для структуры и содержания Плана управления проектом. При этом другие классификации сохраняют свое значение для формирования отдельных разделов плана.

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

Покажем, как могут выглядеть некоторые разделы специализированного шаблона Плана управления проектом. Используем для этого пример проекта создания филиала банка, приведенный в предыдущем разделе. Рассмотрим подпроект создания ИТ-инфраструктуры филиала банка. При построении специализированного микрошаблона «Содержание и границы проекта» мы использовали рекомендации РМВОК PMI (см. табл. 2.2). В этом шаблоне остается менять только названия программного обеспечения и сроки выполнения этапов работ.

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

Таблица 2.2. Специализированный микрошаблон «Содержание и границы проекта создания ИТ-инфраструкгуры филиала банка» Пункт

микро

шаблона Рекомендация рамочного стандарта (для любого проекта) Содержание специализированного шаблона для проектов создания ИТ-инфраструктуры филиала банка Обоснование

проекта

{Project

justification) Описываются основные характеристики продукта и их взаимосвязь с деловой необходимостью или иными стимулами Во всех филиалах должна быть установлена унифицированная, надежная, гибкая и легко наращиваемая ИТ-инфраструктура на основе платформы ХХХХХХХХХ, позволяющая использовать в качестве основного средства обработки бизнес транзакций прикладного программного обеспечения УУУУУУУУУУ Продукт проекта (Project product) Основные характеристики продукта и их взаимосвязь с деловой необходимостью или иными стимулами Доставить, установить и настроить оборудование и системное программное обеспечение во вновь создаваемый филиал банка, формирующее основу для последующего внедрения банковской информационной системы Результаты

проекта

(Project

deliverables) Приводится перечень результатов (подпро- дуктов), достижение (полное и успешное создание) которых означает завершение проекта Спецификации системного программного обеспечения и его конфигурация Требования к помещению для установки оборудования Перечень оборудования и программного обеспечения План технического решения Эталонные копии установки и конфигурации системного программного обеспечения Оборудование и системное программное обеспечение, доставленное в филиал банка, установленное и подготовленное для установки банковской информационной системы Критерии оценки результатов (Project objectives)1 Описание количественных критериев, которые должны быть удовлетворены, чтобы проект считался успешным Срок доставки оборудования и программного обеспечения в Москву не должен превышать XX дней

Срок наладки оборудования и программного обеспечения в Москве не должен превышать УУ дней

Срок транспортировки оборудования и программного обеспечения в филиал банка не должен превышать 7,1 дней

Срок установки и наладки оборудования и программного обеспечения в филиале не должен превышать УШ/ дней

Таблица 2.3. План управления проектом цифрового подключения клиента телекоммуникационной компании Дата составления: Редакция: ФИО Должность Подпись Дата Утвердил Ресурсный менеджер Составил Менеджер проекта Согласовал Менеджер по продажам Сведения о клиенте

Наименование клиента Категория клиента: Крайне значимый Весьма значимый Стандартный клиент Предложение по срокам подключения: от« » 200 г. до« » 200 г. Адрес подключения:

Контактные лица Организация Должность ФИО Телефон

Параметры заказа Параметры заказа Услуги 1 г 3 4 , 5 Подключение по прямому проводу Подключение через радиодоступ Подключение через РСМ/РвБ Подключение до точки местной сети Номера {Компании} по данному адресу № т/ф линий, предоставленных для уплотнения За счет переключения номера Организация новой серийной группы Заведение в серийную группу Возможные технические решения

Содержание коммерческого предложения

Предполагаемый состав работ

Предполагаемые закупки материалов и оборудования Наименование Количество Поставщик

Требования к персоналу проекта Персональный состав Специализация Квалифи

кация Кол-во Время ] ФИО (заполняется сотрудников занятости , ресурсным менеджером Специалист по организации установок Специалист по развитию абонентской сети Специалист по бронированию Специалист по организации радиодоступа Специалист по подготовке линейных данных Специалист по станционным сооружениям Специалист по линей- ным сооружениям

Риски проекта Название риска Вероятность риска Недостаточная информированность о технических условиях клиента Слабая заинтересованность клиента Противодействие со стороны смежных организаций Недостаток рабочей силы Запаздывание в поставках Структура декомпозиции работ как часть Плана управления проектом

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

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

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

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

что нужно сделать (определить продукты проекта); •

как это нужно делать (определить технологические этапы проекта); •

кто это будет делать (определить исполнителей, соисполнителей, субподрядчиков) ; •

кто и в какой форме будет оплачивать работы (определить, какие и

с кем будут заключены контракты).

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

Например, если работы проекта выполняются в интересах различных заказчиков и в то же время финансируются различными инвесторами, декомпозиция может выполняться либо по содержательному признаку отнесения работ к проектам, либо по формальному признаку отнесения работ к договорам финансирования (см. рис. 2.4). Другой случай — фиксация в структуре работ участия субподрядчиков (см. рис. 2.5). Тогда для

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

Декомпозиция по содержательному при а у

Декомпозиция по формальному признаку (финансовые потоки)

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

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

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

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

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

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

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

План управления проектом и рамочные стандарты

Кому-то может показаться, что создать шаблон Плана управления проектом достаточно просто, надо только иметь под рукой рамочные стандарты, например РМВОК PMI и ISO 10006:1997(Е), и разбираться в предметной области. На самом деле это совсем не так. В большинстве случаев рамочный стандарт дает лишь понятийный аппарат и общие методологические принципы. Более того, дело осложняется еше и тем, что необходимая информация в самих рамочных стандартах «рассыпана» по разным разделам и ее не так-то просто «собрать, выстроить и привести к общему знаменателю».

Проиллюстрируем это на примере не самого сложного раздела плана «Организационная структура проекта». В РМВОК PMI необходимая информация разбросана по нескольким разделам (2.2.; 2.3.; 2;4.; 4.1.З.; 9), а в ISO 1000б:1997(Е) — дана в разделе 5.8. Но и в том и в другом случае для создания специализированного шаблона этой информации недостаточно!

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

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

<< | >>
Источник: Товб А. С., Ципес Г. Л.. Управление проектами: стандарты, методы, опыт. — М.: ЗАО «Олимп—Бизнес — 240 с.. 2003

Еще по теме 2.2. План управления проектами и классификация проектов:

  1. СТРУКТУРИЗАЦИЯ ПРОЕКТА — СТРУКТУРНЫЙ ПЛАН ПРОЕКТА (PSP)
  2. 3.1. КЛАССИФИКАЦИЯ БАЗОВЫХ ПОНЯТИЙ УПРАВЛЕНИЯ ПРОЕКТАМИ
  3. ПРОЦЕСС СТАНДАРТИЗИРОВАННОГО УПРАВЛЕНИЯ ПРОЕКТАМИ ПОДДЕРЖИВАЕТ СТРАТЕГИЮ УПРАВЛЕНИЯ ПРОЕКТАМИ
  4. Связь между наборами инструментов управления проектами и размером проекта
  5. 9.2. Основные этапы проекта Создание стандарта управления проектами
  6. Связь между наборами инструментов управления проектами и типом проекта
  7. Связь между наборами инструментов управления проектами и семейством проекта
  8. 9.1. Проект разработки и внедрения стандарта управления проектами
  9. УПРАВЛЕНИЕ КАРЬЕРОЙ ДЛЯ МЕНЕДЖЕРА ПРОЕКТА: ПРОЕКТ, КОТОРЫЙ НЕ ЗАКАНЧИВАЕТСЯ НИКОГДА!
  10. 1.1. ЧТО ТАКОЕ ПРОЕКТ И УПРАВЛЕНИЕ ПРОЕКТАМИ
  11. 6.1.2. Структурный план проекта
  12. КОГДА УЖЕ НИЧЕГО НЕ ПОМОГАЕТ: ПЛАН СПАСЕНИЯ ПРОЕКТА
  13. 3.2. КЛАССИФИКАЦИЯ ТИПОВ ПРОЕКТОВ
  14. 2.2. ЦЕЛЬ ПРОЕКТА — ФОРМУЛИРОВАНИЕ ЦЕЛИ ПРОЕКТА — ДОСТИЖЕНИЕ ЦЕЛИ ПРОЕКТА
  15. Глава тринадцатая Переоценка проекта: определение судьбы проекта
  16. 2.5. ПРОЕКТЫ С ЗАКЛЮЧЕНИЕМ СУБДОГОВОРА И ПРОЕКТЫ, ВЫХОДЯЩИЕ ЗА РАМКИ ОДНОГО ПРЕДПРИЯТИЯ
  17. 7.6. Экспертная классификация проектов по группам значимости (методика Российского гуманитарного научного фонда)