Название: Менеджмент проектов в практике современной компании - Ципес Г. Л.

Жанр: Менеджмент

Рейтинг:

Просмотров: 6166


1.2. традиционная методология управления проектами

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

1 Более полно наши взгляды по данному вопросу отражены в работах [5-7]. При этом мы ни в коем случае не пытаемся подменить справочные и учебные пособия по управлению проектами. Для углубленного изучения рекомендуем читателям це­лый ряд таких книг [8—18].

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

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

Наибольшее внимание обычно уделяется процессам управления проектами в следующих функциональных областях:

Управление предметной областью проекта (содержанием и гра­ницами) — определение целей, результатов и критериев оценки успешности проекта (в сфере ИТ, особенно в проектах разра­ботки программных продуктов, часто называют управлением

конфигурацией).

Управление проектом по временным параметрам — разбиение проекта на группы работ и отдельные работы; определение последовательности выполнения, продолжительности и распи­сания работ — календарного плана проекта; контроль измене­ний календарного плана проекта.

Управление проектом по стоимостным параметрам — определе­ние видов и количества ресурсов (люди, оборудование, матери­алы); определение стоимости ресурсов и работ; учет и контроль

расходов и доходов, а также изменений бюджета.

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

Управление персоналом — распределение ролей, ответственности и отношений координации и субординации персонала проекта; построение организационных и ресурсных диаграмм; подбор человеческих ресурсов; создание и совершенствование команды проекта.

в Управление коммуникациями — определение источников и по­требителей информации внутри и вне проекта, сроков и перио­дичности предоставления информации, способов доставки ин­формации; описание видов распространяемой информации; управление процедурами распространения информации в ходе реализации проектов.

*          Управление проектными отклонениями:

Управление рисками — выявление событий, которые могут повлиять на проект; определение зависимостей возможных результатов проекта от наступления рисковых событий; выра­ботка стратегий работы с рисками; планирование, осущест­вление и контроль мероприятий, связанных с реагированием на риск.

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

Управление изменениями — выявление возникающих моди­фикаций ранее согласованных параметров, их анализ, приня­тие и исполнение решений, формальное закрытие и монито­ринг изменений проекта.

*          Управление контрактами — определение требуемых товаров и услуг, потенциальных продавцов; поддержание формализован­ных отношений с продавцами.

 

Таким образом, учитывая «тройственное ограничение» проекта, облас­ти управления проектом, а также организационные, программные и технические решения, обеспечивающие возможность успешной и эф­фективной работы управленческого персонала проекта, модель проек­та может быть представлена в виде так называемой пирамиды успеха (см. рис. 1.1 [2], приведен с изменениями).

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

Цели

 

Критерии и ограничения

Соответствие требованиям к результатам

 

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

 

 

Достижение результата

 

Соблюдение сроков

 

Соблюдение лимита затрат

 

Выполнение — реализация плана стадии жизненного цикла про­екта (от выдачи задания до получения результата).

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

Закрытие — завершение и закрытие проекта или стадии жиз­ненного цикла проекта.

Взаимосвязи процессов управления проектами и их реализация по фазам управления представлены на рисунке 1.2 [2] (воспроизведено с изме­нениями).

 

 

 

 

 

 

 

 

 

 

Подпись: Управление контрактами

 

 

 

і Управление !изменениями

Управление Управление стоимостью качеством

 

1.3. Динамичный менеджмент проектов

Название этого раздела мы позаимствовали у нашего друга В. Михеева, который вот уже три года проводит проектные мастерские (workshops), посвященные актуальным вопросам современного менеджмента про-

 

Организационные и технические решения

 

Подпись: Определение проектаСтандарт управления проектами: Концепция, Методика, Операционный стандарт

 

Автоматизированный комплекс управления проектами: пакеты прикладных программ календарно-ресурсного планирования, управления документами, управления персоналом и т. д.

s со

S

=г I

Открытие проекта

 

Формирование оргструктуры

 

 

Рисунок 1.1. «Пирамида успеха» — методология управления проектом

 

Фазы управления 1 проектом соответствуют традиционным фазам управленческого цикла:

Инициация — санкционирование начала проекта или очеред­ной стадии его жизненного цикла.

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

 

 

S X

ю

Ц ш и а с >«

х

п

03

в

а> s х со

СП

О а s і

СО

с; С

 

!

о          о

£          ^

л          -

0Q       s

 

 

Детальное планирование

 

Организация и выполнение работ <

 

Контроль, мониторинг, отчетность

 

Управление отклонениями (риски, проблемы, изменения)

 

Подпись: В литературе часто можно встретить термины «стадии процесса управления» или «группы процессов управления», что, на наш взгляд, не столь удачно для элементов процессов управления, повторяющихся на разных стадиях жизненного цикла про¬екта и при управлении всеми функциональными областями проекта. Часто встре¬чающийся термин «фазы жизненного цикла», на наш взгляд, также не слишком удачен для не повторяющихся во времени и, как правило, не существующих одно¬временно элементов жизненного цикла проекта. Поэтому мы используем вместо него термин «стадии жизненного цикла». Подпись: ш
S
I
0)
Э
CL Ш Ш
пз СО

 

Закрытие проекта

 

Рисунок 1.2. Процессы управления проектом

 

с кто в. объединенные этим названием [19]. На одной из этих встреч ее участниками, в том числе и авторами этой книги, были сформулиро­ваны и проранжированы наиболее важные тенденции развития совре­менного менеджмента проектов.

В качестве основных тенденций развития современного управле­ния проектами были выделены следующие (перечисляем в порядке убывания важности):

Неопределенность в проекте — повышенное внимание к неопре­деленности в проекте и способам ее устранения или снижения.

Границы проекта — стремление к расширению традиционных границ проекта и включению в зону ответственности менеджера проекта целого ряда пред- и постпроектных работ.

Кросс-культурная интеграция — взаимодействие и наложение американского, европейских, австралийского и азиатских под­ходов к управлению проектами.

Модели управления проектами — взаимодействие и взаимопро­никновение различных моделей управления проектами — про­цессной, системной, организационно-деятельностной — и раз­витие соответствующих стандартов.

Смежные методологам — широкое использование смежных управ­ленческих методологий и технологий в практике менеджеров проектов.

Модели зрелости — настойчивые попытки стандартизации про­ектной деятельности компаний в форме моделей зрелости.

Проектный офис и управление портфелями — переход интереса к проектным офисам и управлению портфелями в чисто практи­ческую плоскость.

 

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

 

Неопределенность в проекте

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

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

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

Р. Тернер [20] рассматривает различные подходы участвующих в проектном контракте сторон (Заказчика и Исполнителя) и показы­вает, что путь к успеху в проектах высокой неопределенности лежит в создании и отражении должным образом в контракте того, что мы назвали бы атмосферой конструктивного партнерства.

Это означает, что контракт должен являться средством гармониза­ции интересов сторон путем обеспечения:

в   соответствующих общим целям стимулов; в   гибкого и дальновидного управления в условиях неопределен­ности;

снижения трансакционных издержек;

наличия необходимых мер предосторожности.

 

Р. Тернер предложил развернутую классификацию контрактов, исполь­зуемую как инструмент управления неопределенностью, и стратегию выбора тина контракта, учитывающую следующие параметры:

в сложность проекта (простой, масштабный, сложный, многоэтап­ный и т.д.);

ответственность за риск (отвечает только Заказчик, только Ис­полнитель или обе стороны);

природа неопределенности в проекте (источники рисков в про­дукте проекта, в методе создания продукта, в управлении проек­том, разнообразные источники рисков).

Для сложных проектов и программ Д. Домбкинс рассматривает исполь­зование специальной технологии контрактинга — Governance Con­tracting™, основой для разработки которой послужил подход Integrated Allianeing™, применяемый на уровне бизнес-планирования [21J. Ана­лиз развития контрактинга за период 1989-2001 гг. позволяет разде­лить традиционные контракты и так называемые контракты отноше­ний. В качестве условной границы служит появление в 1994 г. конт­рактов типа партнерства. Причину развития форм контрактинга автор видит в усложнении отношений сторон при реализации все более слож­ных проектов и программ в условиях постоянно растущей неопреде­ленности делового окружения.

Governance Contracting™ сдвигает фокус от управления проектом к управлению бизнесом или программой; эта технология обеспечивает основу для долговременных отношений сторон, необходимых для успеш­ной реализации масштабных программ, развития зрелости организа­ций, таких, например, как государственно-частные партнерства (Public/ Private Partnership, РРР).

Governance Contracting™ включает пять стадий отбора Исполните­ля, подготовки и заключения контракта:

Выражение первоначального интереса сторон.

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

Запрос на Предложение.

Потенциальным Исполнителям предлагают разработать Пред­ложение, которое в технологии Governance Contracting™ назы­вается Бизнес-планом и по своему содержанию и детализации соответствует развернутому Технико-коммерческому предложе­нию (ТКП). По этому документу Заказчик должен оценить, как потенциальный Исполнитель сможет применить к конкретному проекту свои возможности, подтвержденные на предыдущем этапе.

Обсуждение Бизнес-плана.

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

Окончательный выбор лучшего предложения.

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

Заключительные переговоры.

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

 

Вопросы перспектив институализации и внедрения методологий контр­актинга на российском рынке затрагиваются в работах В. Ананьина и его соавторов [22—24].

В работе [22] рассматриваются несколько типов ИТ-проектов, име­ющих различные уровни неопределенности, — создание нового про­дукта (инновационный проект), вывод известного продукта на новый рынок, типовое внедрение системы стандартной функциональности. На примере этих проектов анализируются зависимости эффективности типов контрактов и стилей управления проектом от уровня неопреде­ленности в проекте.

Анализ сложных ИТ-проектов, приведенный в работе [24], показы­вает, что трудозатраты на поиск взаимоприемлемого решения могут достигать 70\% от всей трудоемкости проекта. Причина в том, что За­казчик, как правило, не может четко формулировать цели и ставить задачи. Ему можно в этом помочь, но полностью сделать это за него невозможно. То. что сложный ИТ-проект начинается с размытых це­лей и не имеет четких границ, — не исключение, а правило. Несмотря на то что при заключении контракта стороны стараются детально про­писать все условия, права и обязанности, контракт все равно, по сущест­ву, остается рамочным, а в деталях порой даже противоречивым. Часто выполнение плановых проектных работ и переговорный процесс идут параллельно.

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

Горизонтальные соглашения могут заключать: спонсоры проекта — партнерские и юридические соглашения; руководители проекта — по­ложения об организации проекта; специалисты проектной группы — протоколы, планы, рабочая документация. Горизонтальные соглаше­ния дополняются по вертикали управления поручениями и приказами. Предметами соглашения могут быть не только используемые ресурсы или получаемые результаты, но также и работы, требования, статьи бюджета проекта и даже его цели, границы и намерения.

Баланс интересов сторон достигается за счет соблюдения фунда­ментальных принципов права:

в рамках соглашения права и обязанности должны быть сбалан­сированы;

должна обеспечиваться преемственность соглашений.

 

Дисбаланс соглашений рождает издержки или риски, которые также могут стать объектом соглашений: определяются их владельцы и ком­пенсационные схемы.

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

 

Границы проекта

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

Вопрос границ проекта — это вопрос ответственности. Кто отве­чает за достижение целей проекта в самом широком смысле (не только за «тройное ограничение»)? Пред проектные работы связаны, главным образом, с принятием решения о запуске проекта и его параметрах. Что относить к предпроектным работам, а что к собственно проекту, трактуется различными стандартами по-разному. Анализ этих подходов применительно к ИТ-проектам приведен Е. Зиндером в работе [25J.

Радикальное решение вопроса о границах проекта предлагается в современной японской методологии Р2М. выстроенной в соответствии с базовой японской философией «найти решение сложной проблемы». Методология Р2М сфокусирована на том, чтобы создать ценности для предприятий любого вида деятельности (коммерческих или общест­венных) в результате последовательной реализации их миссии через воплощение стратегии в программах и входящих в них проектах. Основ­ная особенность методологии Р2М может быть выражена как «опреде­ляемое миссией управление проектами или программой», которое опре­деляется сложностью решения проблемы в условиях взаимодействия между технической системой и моделью бизнеса. В рамках традицион­ного, классического управления проектами это динамическое взаимо­действие не могло быть глубоко рассмотрено и отражено в логике управ­ления. Методология Р2М положила начало решению этого вопроса за счет уникального подхода к управлению программами.

Разработчики Р2М полагают, что при реализации обычных проек­тов менеджер проекта сосредоточивает свое внимание на том, как во­время и не превышая сметных затрат поставить изделие или предоста­вить услугу [26]. При этом все, что происходит за пределами сферы действий менеджера, обычно его не интересует. Поэтому его возмож­ности выбора ограничены только на уровне работ, а оценки — структу­рой показателей освоенного объема. Однако при переходе к оценкам владельца (спонсора) проекта следует к этому добавить необходимость смягчения рисков и создания ценностей проекта (программы) в том, что касается творчества (креативности), нестабильности среды, чрез­вычайных ситуаций и широты интерфейсов. Роль владельца проекта чем-то напоминает роль пилота, управляющего аэробусом.

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

В методологии Р2М главная идея управления проектами и про­граммами — это создание новой ценности (инновация), а интеграция — самая важная часть структуры управления. При этом, как пишет К. Бре-дилле, методология Р2М предусматривает гибкую и легко приспосаб­ливаемую систему взглядов, а не только «единственный и лучший спо­соб» ведения дела, закрепленный в западной парадигме рационального позитивизма [27].

 

Кросс-культурная интеграция

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

Сравнительный анализ американского и китайского (КНР) под­ходов приведен в монографии [28]. Особенности работы проектных команд (в том числе и «виртуальных» — пространственно-распре­деленных) в мультикультурной среде рассматриваются в исследова­ниях [29] и [30]. О том, как различие культур в проекте может приво­дить не только к конфликтам и кризисам, но и порой даже к «войнам», можно узнать из работ В. Михеева (см. [31, 32]), в одной из которых представлен интересный взгляд на мужское и женское начала в проект­ной команде.

«Выравнивание» и гармонизация различных подходов — задача еже­годных открытых встреч Global Forum ведущих представителей нацио­нальных школ и международных профессиональных организаций, про­водимых параллельно со всемирными конгрессами IPMA [87].

 

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

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

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

Модель PMI

С середины 1980-х гг. PMI последовательно развивает в своих стандар­тах и в последнее время эффективно продвигает во всем мире простую в понимании, ясную и весьма действенную процессную модель управле­ния проектами, расширив ее и на управление портфелями проектов и программами. Всего в мире напечатано уже около 2 млн экземпляров Руководства к Своду знаний по управлению проектами (РМВОК® Guide) (в рамках трех изданий), осуществлен его официальный перевод на восемь наиболее распространенных в мире языков, включая и русский [18]. Многие эксперты отмечают относительное падение качества по­следних стандартов РМ1 по сравнению со стандартами PMI средины 90-х годов прошлого века. На наш взгляд, это может объясняться как ограничениями положенной в основу стандартов PMI процессной мо­дели, так и неизбежными издержками стремления к универсализации (в смысле «всеохватности») стандартов, которой можно достичь только за счет соответствуюших обобщений и унификации положений стан­дартов в ущерб учету «тонких» особенностей предмета стандартизации. К сожалению, мы вынуждены обратить внимание читателей на низкие оценки авторитетными экспертами из разных стран качества соответ­ствующих переводов РМВОК "Guide; увы, таковы многие оценки и упомянутого перевода на русский язык.

Процессный подход послужил основой для создания IPMA стандар­та ISO/TO 10006:1997 [33], получившего впоследствии статус ГОСТ Р. Само наличие такого рамочного стандарта, придавшего ряду важных положений процессной модели управления проектами статус стан­дарта де-юре, очень важно для управления проектами как профессио­нальной дисциплины, хотя сам этот стандарт по своей форме, статусу и качеству не может быть использован ни как свод знаний, ни как основа для профессиональной сертификации, ни как стандарт пря­мого действия.

 

Стандарт PRINCE2

Самого серьезного внимания, по нашему мнению, заслуживает бри­танский стандарт PRINCE2 (PRojects IN Controlled Environment). Этот стандарт первоначально был создан в 1989 г. для управления британ­скими государственными проектами в области информационных и теле­коммуникационных технологий. К настоящему времени этот стандарт в версии 1996 г., обновленный в 2002 г., стал де-факто всемирно при­знанным стандартом — структурированным процессом управления про­ектами в различных отраслях. PRINCE2 позиционируется авторами как процессный подход к управлению проектами, обеспечивающий легко адаптируемое и масштабируемое средство для управления любы­ми типами проектов. Каждый процесс в проекте определяется вместе с ключевыми входными и выходными данными, а также со специфиче­скими целями и предпринимаемыми действиями. Выделяются шесть последовательных дискретных основных процессов, соответствующих частям жизненного цикла проекта, начиная от старта проекта и заканчи­вая его закрытием, и два процесса, обеспечивающих шесть основных, — планирование и руководство. Последние имеют сквозной характер и продолжаются в течение всего проекта. В каждом из процессов пре­дусмотрены более детальные подпроцессы (всего 45). Имеются также шесть так называемых компонентов: часть из них — документы, а часть — процессы. И наконец, стандарт PR1NCE2 описывает три ме­тодики — планирование, основанное на продукте; обзоры качества; управление изменениями. Руководство по стандарту 1 представляет со­бой ясно написанный и легко читаемый документ, состоящий из основ­ного текста, четко структурированных перечней вопросов, диаграмм процессов и иногда советов и подсказок.

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

Системная модель СОВНЕТ

Научные и методологические основы системных моделей управления проектами [34] получили дальнейшее развитие в работах академиков В. И. Воропаева, В. Н. Буркова, С. Д. Бушуева и их учеников [9—11, 35, 36]. На системных моделях основаны подходы, на которых строятся такие фундаментальные работы, как исследование [8]. Авторы данной книги также выстраивали свои методологические подходы к управле­нию проектами, используя как основу так называемую «системную модель СОВНЕТ» [2].

Модели ICB IPMA и НТК СОВНЕТ

К организационно-деятельностным (менеджерским) моделям управ­ления проектами можно отнести принятую и развиваемую IPMA мо­дель International Competence Baseline (ICB) [37]. Для образующих IPMA национальных организаций модель ICB служит основой в формализа­ции знаний по управлению проектами и смежным областям при под­готовке Национальных требований к компетентности (НТК), таких как НТК СОВНЕТ [35]. НТК являются базой для подготовки к проводи­мой национальными ассоциациями международной четырехуровневой сертификации ирофесе но нал ы і ых менеджеров проектов по системе IPMA. Характерной особенностью модели ICB является ее достаточно

 

Существует пока только на английском языке.

высокая открытость, которая позволяет национальным ассоциациям вносить в нее собственные специфические элементы, в частности НТК СОВНЕТ построены в значительной степени на основе упомянутой выше «системной модели СОВНЕТ».

В 2006 г. вышла новая версия модели ICB, и, соответственно, ско­ро начнется работа над новой версией НТК СОВНЕТ. Авторы этой книги принимают определенное участие в соответствующих коллек­тивных действиях. Однако следует упомянуть, что ни мнение СОВНЕТ как национальной ассоциации, ни наше мнение не являются един­ственными и не всегда разделяются коллегами и находят воплощение в итоговых документах.

Новая версия ICB содержит описание системы четырехуровневой сертификации IPMA в соответствии со стандартом 1SO/IEC 17024 и системы знаний по управлению проектами, программами и портфеля­ми проектов в виде 45 элементов профессиональной компетентности. Эти элементы разделены на три группы:

« технические — 20 элементов, имеющих отношение к содержа­нию деятельности по управлению проектами:

• поведенческие — 15 элементов, относящихся к персональным взаимоотношениям отдельных личностей и групп в деятельно­сти по управлению проектами;

« контекстуальные — 10 элементов, определяющих взаимодействие управления проектами и окружения проекта (организационного, делового, политического, социального и т. п.); как особенно важ­ное выделяется взаимодействие с постоянной или родительской организацией.

 

Анализ модели 1СВ и ее развития можно найти в работах М. Уайдмана [34] и С. Бушуева [38], а также в статье соавторов новой версии ICB 3.0 Дж. Коха и Г. Кнопфеля [85].

Гповальный стандарт компетенции, основанный на выполнении

В середине 90-х годов прошлого века в международном профессио­нальном сообществе сложилась инициативная группа (Global Perfor­mance Based Standards for Project Management Personnel Initiative — GPBSPMPI) по разработке глобальных стандартов по управлению про­ектами. В своей деятельности GPBSPMPI опиралась на поддержку ряда международных (РМІ, IPMA) и национальных ассоциаций, а также нескольких десятков спонсоров — коммерческих компаний, прави­тельственных агентств и образовательных учреждений.

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

Деятельность рабочей группы имеет следующие основные цели:

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

поддержка локальных инициатив по разработке стандартов, ко­торые будут развиваться в контексте рамочного стандарта, пред­лагаемого рабочей группой;

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

 

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

 

Здесь имеется в виду стремление к унификации сертификационных требований различных национальных (Великобритания, Австралия, Новая Зеландия, ЮАР, Япония и др.) и международных (IPMA и PMI) систем сертификации на базе соз­даваемого GPBSPMPI стандарта. Многие эксперты не считают сертификацию PMI международной по статусу — де-юре, хотя, на наш взгляд, она фактически уже является (и во все большей степени становится) глобальной и может называться международной — де-факто.

профессионалы на своих рабочих местах при выполнении стандарти­зованных элементов профессиональной деятельности.

Работу GPBSPMPI организует и координирует известный специа­лист профессор Л. Крауфорд [39]; в ней участвуют также выдающиеся специалисты X. Танака, М. Ишикура, С. Охара, к которым в послед­ние годы присоединился и основной автор PVIBOK'Guide 1996 г. изда­ния В. Дункан [40]. В 2005 г. GPBSPMPI была переименована в GAPPS (Global Alliance for Project Performance Standards), как мы поняли, с главной целью — сосредоточиться не только на разработке и развитии стандартов, но и на их эффективном продвижении.

В настоящее время завершена разработка части стандарта, опреде­ляющей квалификацию старшего менеджера проекта (senior project manager). От человека, находящегося на данной позиции, напрямую зависит результат проекта. Это означает, что его финансовое возна­граждение соответствует степени успешности проекта. Он несет ответ­ственность за тот продукт, который должен быть предоставлен клиенту в результате выполнения проекта. Наконец, это менеджер, который работает в сложной динамической среде и должен учитывать интересы всех участников проекта. В стандарте определяются такие единицы компетентности старшего менеджера проектов, как управление запус­ком и закрытием проекта, развитием проектного плана и ресурсами проекта, взаимоотношениями с заинтересованными участниками, юри­дическими проблемами и др.

В сентябре 2005 г. стандарт был представлен отечественным экс­пертам, состоялось его публичное обсуждение. Общее мнение: доку­мент весьма высокого качества, при условии качественного перевода он может наряду с другими перечисленными выше рамочными стандар­тами служить хорошей основой для создания корпоративных стандартов управления проектами и для подбора и профессионального развития менеджеров проектов. Использование этого стандарта для профессио­нальной сертификации менеджеров проектов в нынешних условиях представляется весьма проблематичным. Мы полагаем, что достигну­тые в ходе разработки этого стандарта конкретные результаты явля­ются реальными и высокими достижениями, а поэтому могут и долж­ны быть учтены при совершенствовании существующих систем серти­фикации PMI и IPMA.

Модели «Третьей волны»

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

Заметным явлением стала публикация ряда совместных работ В. Ми-хеева и Д. Пеллса [41-43], где они всесторонне рассматривают разви­тие и современное состояние профессионального менеджмента проек­то в и программ. В его развитии они выделяют три последовательные «волны» в соответствии с господствующими на разных исторических этапах управленческими парадигмами:

« 1950—1970-е гг. — «Первая волна» — «техническая парадигма»; «   1980—1990-е гг. — «Вторая волна» — «менеджерская парадигма»;

2000—... гг. — «Третья волна» — «фенотиповая парадигма».

 

Менеджмент проектов «Третьей волны» рассматривается как стратеги­ческий ресурс организации, как мощная зрелая «трансформационная технология, которая может облегчить достижение чего угодно, если это будет определено как проект, ...как своего рода профессиональный инструмент для осуществления мечты». Более глубоко с этим подхо­дом можно познакомиться в новой книге В. Михеева [44].

Яркой иллюстрацией моделей «Третьей волны» являются интерес­ные работы целой группы специалистов из Германии и Швейцарии — М. Сайниша и его последователей — Т. Хубера, О. Вернера и С. Рис-тикера [45—47].

Эти специалисты считают, что традиционные модели менеджмента проектов сконцентрированы на выполнении отдельных проектов и должны быть расширены в корпоративном и социальном контексте для обеспечения необходимых современному бизнесу конкурентных преимуществ, достигаемых путем реализации стратегии через портфе­ли проектов и программ. Предлагается так называемая модель М. Сай­ниша, или «модель управления проектами 2-го порядка» (РМ2) [45]. Традиционный менеджмент проектов, или «модель управления проек­тами 1 - го порядка» (РМ1), при этом является интегральной частью РМ2, которая основана на использовании отдельных методов и подхо­дов естественных и социальных наук, таких как теория эволюции и теория хаоса, теория самоорганизации, теория систем, теория позна­ния, когнитивная психология и т. п.

В работе Т. Хубера, О. Вернера эта модель реализована в виде так называемой пирамиды виртуозного менеджмента проектов [46]. Эта модель включает три уровня:

« инструментальный, « процессный, « мыслительный;

 

и четыре стороны (четыре мира — по М. Сайнишу):

 

«   классический менеджмент проектов («мир твердых фактов»);

управление сложностью (система перекрестных связей);

•           управление человеческим фактором (психология, обучение, со­циология);

*          культура (базовые модели мышления, отношения).

 

В работе С. Риетикера [47] модель М. Сайниша, предназначенная для управления отдельным проектом, дополнена подходами, основанными на идеях известного современного австрийского теоретика менеджмента Ф. Малика, на теории открытых систем и на унаследованных IBM от Price Waterhause С о о ре rs проверенных методологиях Component Business Modeling (СВМ) и Seven Keys to Success™. При этом особое внимание уделено отношениям между проектной и родительской организация­ми. В результате предлагается новая методология KEY-9, которая долж­на рассматривать проекты как часть полной корпоративной системы, а менеджмент проектов — как неотъемлемую часть управления и эф­фективно создавать благоприятную для проектов рабочую окружаю­щую среду.

 

Смежные методологии

Широкое и плодотворное использование в практике менеджеров про­ектов получили смежные управленческие методологии и технологии. Перечислим только основные из них.

Сбалансированная система показателей (Balanced Scorecard)

Применение этой методологии породило радикальную идею перехода от классического «тройного ограничения» (Triple Constraint) к «четы­рехстороннему ограничению» (Quadruple Constraint). К ограничениям по срокам (on-time), стоимости (on-budget), характеристикам резуль­тата (on-quality) добавилось ограничение по соответствию стратегии (on-strategy), что позволило связать как цели, так и результаты выпол­няемых проектов развития с миссией и стратегией предприятия (см. [48, 49]).

Управление знаниями

(Knowledge Management)

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

Организационное развитие (Organization Development)

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

Для продвижения методологии в компании используются различ­ные формы — тренинги, семинары, учебные курсы. Совместное при­менение методологии интеграции знаний (Knowledge Integration, Kl) и методологии совершенствования процессов разработки программного обеспечения в корпорации TIS не только позволило повысить эффек­тивность работы, но и создало предпосылки для глубокого внутренне­го и внешнего единства работников и организации во всех аспектах.

Управление процессами (Process Management)

По утверждению Э. Ферна, рост современного производства невозмо­жен без кастомизации производимого продукта под индивидуальные требования каждого отдельного клиента, что фактически стирает грань между проектом и процессом (см., например, [53]). Каждый процесс становится настолько особенным, что есть смысл реализовывать его в проектной форме.

В. Кремзер предложил внедрить некий вид гибкой, процессно-ори-ентированной организации управления проектами, которая наилучшим образом подходит для ограниченных возможностей малого бизнеса [52].

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

Весьма глубокий анализ и конкретные практические рекомендации по организации, анализу, оценке зрелости, реинжинирингу и управле­нию бизнес-процессами в проектно-ориентированной компании даны Р. Гаррейсом [54]. Его вывод таков: чем более зрелой является проект­но-ориентированная компания в управлении бизнес-процессами, тем более стабильные и хорошие результаты она получит при управлении проектами и программами.

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

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

Описанные подходы во многом послужили основой для реализации нами описанных в главах 3, 4 и 5 этой книги конкретных «кейсов».

Интеграция информационных систем управления проектами с раз­личными программными приложениями (ERP, CRM, SCM. PLVI, PDY1

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

 

Модели зрелости

В последнее десятилетие вслед за успехом в индустрии информацион­ных технологий моделей зрелости СММ (Capability Maturity Model) и CMMI (Capability Maturity Model Integrated) предпринимались настой­чивые попытки стандартизации проектной деятельности компаний в форме моделей зрелости. Разными авторами был предложен целый ряд таких моделей (см., например, [56—58]).

В декабре 2003 г. PMI завершил разработку стандарта ОРМЗ (Organizational Project Management Maturity Model), и он поступил в свободную продажу. На сегодняшний день накоплен уже значитель­ный опыт его практического применения во всем мире, в том числе и в России (см. [59-62]).

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

 

Проектный офис

и управление портфелями

Эти темы стали популярными в России в начале 2000-х гг. В послед­ние несколько лет мы наблюдаем переход интереса к проектным офи­сам и к управлению портфелями в чисто практическую плоскость.

Хотя сегодня тема проектного офиса менее популярна, но она по-прежнему пользуется устойчивым интересом. С точки зрения мето­дологии эту тему можно считать практически исчерпанной с выходом книг [63] и [64]. На первый план выходят конкретный опыт, опенки и статистика, необходимые для решения двух главных вопросов: какую модель проектного офиса использовать в компании и в каких случаях, как измерить успех создания проектного офиса? На эти вопросы отве­ты можно найти в работах [61, 65-691.

Тема управления портфелями проектов и программами по-преж­нему пользуется значительным интересом. На первый план выходят конкретный опыт постановки управления портфелями проектов и про­граммами в компаниях, его оценка, сравнительные достоинства ис­пользования тех или иных инструментальных средств — Artemis, Prirna-vera, MS Project, IBM Rational Portfolio Manager — и прикладных про­граммных решений, построенных на их базе, таких, например, как Opus Magnum Enterprise Management [86]. Современный опыт управления портфелями проектов и программами широко представлен в статьях в журналах и докладах на конференциях и симпозиумах последних лет [70—74]. В качестве фундаментального справочного пособия по управ­лению портфелями можем рекомендовать монографию [75].

1.4, Резюме

Мы кратко рассмотрели суть, состояние и тенденции развития совре­менного менеджмента проектов, использовав все доступные нам источ­ники, для того, чтобы представить читателю наш взгляд на современ­ное управление проектами как на зрелую профессиональную сферу, имеющую, как считает В. Воропаев ]4|:

сложившиеся и выверенные практикой концепции, теорию, ме­тодологию и развитые технологии;

признанные международные и национальные стандарты и дру­гие нормативно - м етод и чес ки с до к у мен т ы;

развитый мир профессиональных публикаций, конференций и конгрессов;

богатый рынок профессиональных программных приложений;

развитый рынок профессиональных услуг;

современные системы образования, включая различные програм­мы сертификации профессионалов;

обширные области применения в современном обществе;

растущую популярность и значение.

 

Часто у наших потенциальных заказчиков возникает простой вопрос глобального для профессионалов характера: «А зачем вообще нужно управлять проектами?» Надеемся, что часть ответа читатель найдет в оригинальном материале последующих глав нашей книги. А в этой главе процитируем результаты опроса, проведенного Volkswagen Coa­ching GmbH ProjektManagement. В опросе участвовал 261 профессио­нал из разных стран мира [76].

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

 

возрастании сложности проектов

- 27\%;

увеличении числа проектов

- 25\%;

ужесточении требований к срокам

- 23\%;

к


Загрузка...

Оцените книгу: 1 2 3 4 5


Загрузка...