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

Расскажите, пожалуйста, о вашей работе над стандартом РМВоК. Как родилась идея процессной модели управления проектами?

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

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

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

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

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

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

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

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

Вы являетесь соруководителем компании Project Management Partners, занимаетесь постановкой проектного управления в компаниях. Является ли PMBoK фактическим стандартом, насколько создаваемые системы проектного управления соответствуют РМВоК?

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

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

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

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

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

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

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

Можно ли говорить о специфике ИТ-проектов с точки зрения проектного управления?

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

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

Если говорить о минимально необходимом требовании, то, для того чтобы начать внедрять идею проектного управления, достаточно одного человека, который будет в нее верить. Дальше она распространяется как вирус. Сотрудники видят, что существуют практики, которые дают успешный результат, и начинают их применять. Зачастую безграмотность сотрудников в области управления проектами обусловливается не глупостью, а именно незнанием методики. Но если мы говорим о внедрении культуры управления проектами на уровне компании, то без серьезной поддержки высшего руководства не обойтись.

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

Поясните, пожалуйста, каковы основные компоненты корпоративной культуры управления проектами?

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

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

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

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

Какая из областей проектного менеджмента, определенных в РМВоК, оказывает наибольшее влияние на успех проекта?

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

Какой, на ваш взгляд, должна быть идеальная программная система для управления проектами?

Сам я мало пользуюсь специализированным программным обеспечением и знаю пакеты на довольно поверхностном уровне. Могу сказать, что системе Primavera, например, принадлежит порядка 80-90% строительного рынка, примерно такую же часть рынка ИТ захватил Microsoft Project. Но в целом на этот вопрос я могу ответить следующим образом: в руках опытного проектного менеджера, который понимает и хорошо знает методологию, любой инструмент будет работать эффективно. А в руках человека, который не знает методологии и полагается только на программный инструментарий, любая система окажется очень опасной, потому что приведет к получению неверных ответов на вопросы. Такому лучше не использовать ничего. Не стоит рассчитывать, что программное обеспечение будет отвечать на ваши вопросы, оно может только поддерживать ваши собственные ответы.

Об управлении проектами в России

В России PM Partners работает с компанией PSM Consulting и разделяет то видение рынка, которое формируется экспертами этой компании. Поэтому вопрос о состоянии дел с управлением проектами в нашей стране Билл Дункан переадресовал Марине Грашиной:

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

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

О развитии стандартов проектного менеджмента

Во время визита Вильяма Дункана в Москву в компании PSM Сonsulting состоялась его встреча со специалистами и журналистами. В ходе встречи Дункан обрисовал свое видение основных направлений в развитии стандартов проектного менеджмента.

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

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

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

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

Разработка стандартов в этой последней области будет представлять самую большую сложность, поскольку многие консалтинговые компании уже предлагают свои собственные подходы к оценке организационной зрелости компаний. Будет очень непросто объединить всю профессиональную область вокруг какого-то одного стандарта. Думаю, что здесь должен быть разработан определенный принцип, простейшая модель, некая совокупность элементов, которые в обязательном порядке должны присутствовать в организации для поддержки зрелого проектного менеджмента. С этими минимальными требованиями должны согласиться все организации, работающие в области управления проектами (IPMA, PMI, национальные ассоциации, любые организации, которые занимаются вопросами стандартизации).

PMBoK

Project Management Body of Knowledge (PMBoK) — свод понятий и практических требований по управлению проектами, признанный международный стандарт в этой области, разработанный в Институте управления проектами Project Management Institute (PMI). Определяет проект как целенаправленную деятельность временного характера, которая имеет своей целью создание уникального продукта или услуги.

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

В рамках этих процессов реализуются процедуры, которые относятся к девяти областям управления.