Вирус проектного менеджмента

Билл Дункан — основной разработчик свода знаний по управлению проектами PMBoK в версии 1996 года, автор процессной модели управления проектами, соруководитель консультационной компании Project Management Partners, ведущий эксперт компании PSM Consulting, представляющей его интересы в России. С 2001 года ведет независимую от PMI деятельность по разработке международных стандартов.

Дункан принял участие в работе недавней III Всероссийской практической конференции «Стандарты в проектах современных информационных систем» (ее организовали фонд ФОСТАС, журнал «Директор информационной службы» и издательство «Открытые системы»), во время которой с ним встретилась редактор журнала «Открытые системы» Наталья Дубова. В беседе принимала участие генеральный директор компании PSM Consulting Марина Грашина.

Первые версии РМВоК были выпущены в 1983-м и в 1987 годах. Один из важнейших вопросов, на который пытались ответить их разработчики, — является ли управление проектами отдельной профессией или всего лишь специализацией в рамках профессиональных технических дисциплин. Сегодня это трудно себе представить, но два десятилетия назад были достаточно серьезные дебаты на тему, можно ли вообще научить кого-то быть проектным менеджером, или это талант, с которым надо родиться.

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

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

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

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

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

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

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

Системы проектного управления должны быть построены таким образом, чтобы не ограничивать возможности сотрудников компании каким-то одним, конкретным типом действий. Иными словами, стандарты РМВоК и стандарты проектного управления, разработанные на корпоративном уровне, не могут быть некой «кулинарной книгой», которой надо следовать во всех обстоятельствах. Возьмем в качестве аналогии проезд в аэропорт. Мы знаем точку отправления и точку, в которую нужно попасть, но при этом существует десять разных маршрутов, которыми можно добраться до аэропорта. Сегодня один путь будет преимущественным, а завтра — другой. Если говорить о проектном управлении, то система стандартов и корпоративных, и общих должна обеспечивать определенную степень гибкости в выборе и реализации конкретных процессов конкретными людьми. Если вы ограничите своих сотрудников только одним маршрутом в аэропорт, то иногда он окажется оптимальным, но чаще они, скорее всего, будут просто пропускать свой рейс.

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

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

Повышенный интерес к ней возник во многом благодаря проникновению в ИТ-проекты. Здесь, с моей точки зрения, сыграли свою роль два очень важных фактора. Первый — это глобальный проект Y2K по переходу всех информационных систем на 2000 год. Этот проект в отличие от обычных проектов в области ИТ был жестко ограничен во времени. Впервые были предъявлены самые серьезные требования к тому, чтобы проект был действительно закончен в заданные сроки. Это, в свою очередь, вызвало необходимость повышения эффективности подходов к менеджменту. Второй фактор заключается в том, что по своей структуре РМВоК в значительной степени ориентирован на ментальность ИТ-сообщества, даже с точки зрения терминологии. Поэтому появление РМВоК повлекло за собой развитие интереса к проектному управлению в сфере ИТ. Ну а поскольку ИТ пронизывают все отрасли экономики, все сферы деятельности современного мира, причем как коммерческие, так и некоммерческие, получилось так, что именно ИТ-сообщество понесло слово о проектном управлении во все другие области деятельности.

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