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

Стандарты управления проектами: структура, роли и процессы
Мы рассмотрим, что представляют собой стандарты по управлению проектами. Ранее мы обсуждали отдельные нюансы и приемы, которые полезно использовать в проектной работе. Правила планирования, контроля и организации деятельности команды сформулированы именно в стандартах. Существует множество национальных стандартов: американские, европейские, австралийские. В России, однако, чаще ориентируются не на европейские подходы. Один из самых известных — стандарт, разработанный американским Институтом управления проектами (Project Management Institute, PMI) — PMBOK (Project Management Body of Knowledge).

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

Две ключевые организации, разрабатывающие стандарты, — это Институт управления проектами США (PMI) и Ассоциация управления проектами Великобритании. Поддерживаемые ими подходы различаются формулировками необходимых действий и их порядком. Мы будем рассматривать в основном стандарт PMBOK, прошедший несколько стадий развития: версии 1996, 2000 и 2004 годов.

Стандарт PMBOK определяет:
• Действующих лиц, участвующих в проекте;
• 9 областей знаний, необходимых для грамотной организации управления;
• 5 групп процессов, в которые сведены 39 конкретных задач управления.

Рассмотрим эти элементы последовательно.

Действующие лица в проекте

Участники делятся на две группы: связанные с управлением и непосредственные исполнители.

1. Лица, управляющие проектом:
• Менеджер проекта — лицо, отвечающее за достижение результатов в рамках ограничений по времени и ресурсам. Это «виноватый за всё». В PMBOK менеджер — это человек с широкими властными полномочиями. Существует и другой взгляд, зафиксированный в стандарте Microsoft Solutions Framework (MSF). В MSF менеджер проекта — скорее наставник и методолог, а ответственность за исполнение работ переходит между ролевыми кластерами по мере выполнения проекта. Обе точки зрения жизнеспособны.
• Спонсор (куратор) проекта — позиция, важность которой долго недооценивалась. Рассмотрим ситуацию: внедрением информационной системы руководит генеральный директор. Это плохо, потому что руководитель проекта не сможет оперативно попасть к нему со своими проблемами: у директора в приоритете сбыт, поставщики и другие производственные вопросы. Проблемы приходится решать своими силами, что часто неэффективно. Спонсор — это лицо на промежуточной должности (заместитель директора, руководитель направления), которому высшее руководство делегирует полномочия распределять ресурсы и решать проблемы проекта. Он, с одной стороны, обладает доступом к самому верхнему уровню руководства, с другой — доступен для менеджера проекта. Спонсор — это движущая сила, «проталкивающая» проект вперед. Также он отслеживает изменения в окружении и своевременно информирует менеджера о политических событиях, способных повлиять на проект.
• Заказчик — роль, чьи интересы и потребности определяют содержание проекта.

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

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

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

Выбор менеджера проекта

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

Области знаний и процессы управления

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

Действия, которые нужно выполнять, объединены в 5 групп процессов:
1. Процессы инициации — запуск проекта и переход между его этапами.
2. Процессы планирования — определение содержания работ, их цепочки, оценка времени и стоимости.
3. Процессы исполнения — реализация работ по созданию продукта (с точки зрения управления проектами — лишь один небольшой элемент).
4. Процессы контроля — проверка соблюдения планов.
5. Процессы завершения — формальное закрытие проекта или его этапов.

Если наложить 9 областей знаний на 5 групп процессов, получится матрица, включающая 39 конкретных процессов. Основной вывод: с точки зрения управления проектами, основная деятельность сосредоточена в области планирования и контроля. Именно здесь менеджер прикладывает наибольшие усилия. Версия PMBOK 2004 года внесла некоторые изменения (например, более явную цепочку от предварительного описания проекта до иерархической структуры работ), но они не носят революционного характера.

Области знаний в Microsoft Solutions Framework (MSF) называются немного иначе, но по содержанию практически идентичны PMBOK. Таким образом, перечень компетенций, которыми должен обладать руководитель проекта для грамотной организации работ, уже сформирован и признан профессиональным сообществом.

Краткие итоги

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

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

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