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

Этот материал продолжает начатую в декабре 2000 года Майком Ньюэллом (вице-президентом компании PSM Consulting) серию заметок по управлению проектами.

Григорий Львович Ципес, ведущий системный аналитик компании IBS, GTsipes@ibs.ru Александр Самуилович Товб, руководитель проектов компании IBS, A_Tovb@ibs.ru

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

Распространено мнение, что профессиональный руководитель проектов может успешно реализовать любой проект независимо от того, к какой области он относится, — от строительства атомной электростанции до разработки программного обеспечения. По мнению М. Ньюэлла (см. беседу с ним в февральском номере «Директора» за 2001 год), достаточно иметь лишь квалифицированных консультантов и некоторый запас времени.

В принципе этот тезис справедлив, но дьявол, как известно, кроется в деталях, здесь мы согласны с оппонентом Ньюэлла М. Дубининым (см. его заметку в майском номере «Директора» за 2001 год). Сколько потребуется времени и есть ли такой запас? Сколько нужно консультантов и какой квалификации? Сколько нам будет стоить такой руководитель проектов сам по себе и сколь велики будут дополнительные расходы?

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

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

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

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

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

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

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

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

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

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

В следующей заметке на конкретных примерах мы обсудим содержание специализированных шаблонов Плана управления проекта.

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

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