Пожалуйста, введите доступный Вам адрес электронной почты. По окончании процесса покупки Вам будет выслано письмо со ссылкой на книгу.

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

Список удаленных книг:

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

Список удаленных книг:

Купить Редактировать корзину Логин
Поиск
Расширенный поиск Простой поиск
«+» - книги обязательно содержат данное слово (например, +Пушкин - все книги о Пушкине).
«-» - исключает книги, содержащие данное слово (например, -Лермонтов - в книгах нет упоминания Лермонтова).
«&&» - книги обязательно содержат оба слова (например, Пушкин && Лермонтов - в каждой книге упоминается и Пушкин, и Лермонтов).
«OR» - любое из слов (или оба) должны присутствовать в книге (например, Пушкин OR Лермонтов - в книгах упоминается либо Пушкин, либо Лермонтов, либо оба).
«*» - поиск по части слова (например, Пушк* - показаны все книги, в которых есть слова, начинающиеся на «пушк»).
«""» - определяет точный порядок слов в результатах поиска (например, "Александр Пушкин" - показаны все книги с таким словосочетанием).
«~6» - число слов между словами запроса в результатах поиска не превышает указанного (например, "Пушкин Лермонтов"~6 - в книгах не более 6 слов между словами Пушкин и Лермонтов)
 
 
Страница

Страница недоступна для просмотра

OK Cancel
Рассел Д. Арчибальд УПРАВЛЕНИЕ ВЫСОКОТЕХНОЛОГИЧНЫМИ ПРОГРАММАМИ И ПРОЕКТАМИ MANAGING HIGH TECHNOLOGY PROGRAMS AND PROJECTS Russel D. Archibald 3rd Edition John Wiley & Sons, Inc. • • • • New York Chichester Brisbane Toronto Singapore УПРАВЛЕНИЕ ВЫСОКОТЕХНОЛОГИЧНЫМИ ПРОГРАММАМИ И ПРОЕКТАМИ Рассел Д. Арчибальд Перевод под редакцией А. Д. Баженова, А. О. Арефьева 4-е издание (электронное) Москва, 2018 УДК 65.0 ББК 65.290 2 А88 Арчибальд, Рассел Д. А88 Управление высокотехнологичными программами и проектами [ЭлекЕ. В. тронный ресурс] / Рассел Д. Арчибальд ; пер. с англ. Мамонтова ; под А. Д. А. О. 4-е ред. Баженова, Арефьева. — изд. (эл.). — Электрон. текстовые дан. (1 файл pdf : 466 с.). — М. : ДМК Пресс, 2018. — Систем. требования: Adobe Reader XI либо Adobe Digital Editions 4.5 ; экран 10". ISBN 978-5-93700-031-6 — Рассел Д. Арчибальд всемирно признанный специалист по управлению проектами. Обладая более чем 40-летним опытом в управлении, инжиниринге и консалтинге, он выпустил данную книгу с целью удовлетворить давно существующую потребность во всеобъемлющем, систематическом описании практики управления программами и проектами, а также связанных с ней инструментов планирования и контроля. В книге рассматриваются все аспекты управления проектами/программами: организационные и практические концепции и методы, основные элементы планирования и управления проектами, а также многие темы, касающиеся межличностных отношений и поведения. Пристальное внимание уделяется вопросам реализации концепций управления портфелями проектов и организации управления проектами в компаниях путем создания проектных офисов. Настоящее издание книги значительно переработано и дополнено по сравненачальными. с Оно представляет интерес для руководителей высшего звена, менеджеров крупных и небольших проектов, руководителей функциональных подразделений и других членов команд проектов. УДК 65.0 ББК 65.290-2 Деривативное электронное издание на основе печатного издания: Управление высокотехнологичными программами и проектами / Рассел Д. Арчибальд ; пер. с англ. Е. В. Мамонтова ; под ред. А. Д. Баженова, А. О. Арефьева. — 3-е изд., перераб. и доп. — М. : ДМК Пресс, 2010. — 466 с. — ISBN 978-5-97060-045-0. В соответствии со ст. 1299 и 1301 ГК РФ при устранении ограничений, установленных техническими средствами защиты авторских прав, правообладатель вправе требовать от нарушителя возмещения убытков или выплаты компенсации. © John Wiley & Sons, Inc., 1976 ISBN 0-471-26557-8 (англ.) © Russell D. Archibald, 2003 ISBN 978-5-93700-031-6 (рус.) © ДМК Пресс, 2010 « « » » Содержание От редакции ............................................................................................................ 20 Предисловие к русскому изданию .................................................................... 22 ЧАСТЬ I АДМИНИСТРАТИВНОЕ РУКОВОДСТВО ............ 31 ПО УПРАВЛЕНИЮ ПРОГРАММАМИ И ПРОЕКТАМИ 1 Обзор управления проектами ....................................................................... 33 1.1 Важность эффективного управления проектом ................................. 33 ............................................................. 34 Проекты существуют во всех организациях .................................................... 34 Быстрое распространение управления проектами ............................................................... 34 Разнообразие и классификация проектов .......................... 36 Важность эффективного управления проектами для всех организаций ................................ 37 Проектно ориентированные и проектно зависимые организации 1.2 Проекты – средства стратегического развития организаций .......... 38 ........................................................................................... 40 Источники развития ......................................................................... 40 Разнообразие проектов развития ............................................................. 40 Программы и проекты – средства развития 1.3 Стратегическое управление портфелями проектов .......................... 41 .................................................. 41 Интегрированное управление портфелями проектов ............ 42 Управление мультипроектами в сравнении с управлением портфелями проектов ............................................................. 44 Процесс управления портфелями проектов 6 Содержание Управление портфелями проектов связывает стратегическое управление ..................................................................................... 45 и управление проектами .................................................... 46 Управление проектами в масштабах предприятия 1.4 Инвентаризация: реестр проектов ....................................................... 47 ....................................................................................... 48 Перегрузка проектами 1.5 Процесс управления проектами в организации ................................. 48 .............................. 49 Управление жизненным циклом проекта плюс управление рисками ............................. 49 Документирование процесса управления проектами в организации 1.6 Триада концепций управления проектами .......................................... 51 .......................................... 51 Определение центров ответственности за проект в целом ........................................ 51 Комплексные и прогнозирующие планирование и контроль .............................................................................................. 52 Команда проекта 1.7 Проблемы и возможности, связанные с Internet ............................... 52 .................. 54 Использование сети Internet для реализации связанных с ней возможностей ................................................................................... 56 2 Программы и проекты 2.1 Программы, проекты и задачи .............................................................. 56 2.2 Что такое проект ..................................................................................... 57 2.3 Категории проектов ................................................................................ 66 ............................ 66 Основные категории проектов со сходными процессами управления ........................................ 69 Классификация мультипроектных программ по категориям 2.4 Классификация проектов каждой категории ..................................... 70 ................................................................................................. 70 Объем проекта ............................................................................................ 70 Сложность проекта ........................................................................ 71 Внешний или внутренний заказчик ..................................................................... 71 Степень участия заказчика в проекте ...................................................................................... 71 Уровни риска в проекте ...................................................... 72 Большие и малые проекты в пределах категории 2.5 Жизненные циклы высокотехнологичных проектов ....................... 74 ............ 74 Важность разработки и документирования процессов жизненного цикла проекта .............................................................. 75 Категории высокотехнологичных проектов Разработка и документирование жизненных циклов ............................................................................ 77 высокотехнологичных проектов Ступенчато шлюзовой процесс жизненного цикла ...................................................................... 81 проекта разработки нового продукта ................................... 81 Жизненные циклы проекта, определение и расписания проекта ............................................................ 82 Жизненные циклы проекта и его окружение 7 Содержание 2.6 Окружение проекта ................................................................................. 83 ................................................................................... 84 Обзор окружения проекта ............................................................... 85 Связи между проектом и его окружением .............................................................................. 88 Динамика окружения проекта 3 Улучшение возможностей управления проектами в компании ........... 89 3.1 Преимущества и стоимость систематизированного управления проектами ................................. 89 ................................................. 89 Преимущества современного управления проектами ............................................ 91 Цели и преимущества управления портфелями проектов ......................................................................... 92 Стоимость управления проектами ................................................................... 92 Измерение ROI управления проектами ................................................... 95 Ценность управления проектами: за пределами ROI 3.2 Формализованные своды знаний в управлении проектами ............ 96 3.3 Модели зрелости управления проектами ......................................... 100 ............................................ 102 Два примера моделей зрелости управления проектами ....................................... 102 Модель зрелости процессов управления проектами Беркли ...... 102 Программа PMI по разработке модели зрелости управления проектами организации 3.4 Рекомендуемый подход к улучшению процессов управления проектами ......................................................................... 104 ................... 105 Идентификация благоприятных возможностей и необходимость улучшения .............. 105 Симптомы и вероятные причины неудовлетворительного исполнения проектов .............................................. 106 Идентификация проблем, рисков и подводных камней ................................................................................ 110 Метод “пилотного” проекта ........ 110 Использование реальных и учебных проектов для обучения и подготовки персонала 3.5 Улучшение системы управления жизненным циклом проекта ..... 111 ......................................... 111 Проведение реинжиниринга интегрированных процессов ......................................... 112 Улучшение процессов жизненного цикла нового продукта Рассмотрение возможности применения теории ограничений ................................. 112 для улучшения системы управления жизненным циклом проекта 3.6 Преодоление препятствий в управлении проектами ..................... 114 .............................................................................. 115 Идентификация препятствий ........................................................................... 115 Другие источники препятствий .......................................................... 115 Силы, помогающие преодолеть препятствия .................................................................. 116 Обучение и повышение квалификации ................................... 117 Выбор правильного курса действий для внедрения изменений ..................................... 117 Модификация и расширение методик управления проектами ........................................................................................................ 118 Выводы 8 Содержание 4 Роли в управлении проектами .................................................................... 120 4.1 Ключевые должности с интегрирующей ответственностью ......... 120 .......................................................................... 120 Уровень руководства компании ................................................................... 121 Уровень программ и мультипроектов ............................................................................................ 121 Уровень проектов ................................. 121 Уровень функциональных подразделений и участников проекта ........................................................ 121 Другие важные роли в управлении проектами Общая модель взаимоотношений между должностями .................................................................... 122 с интегрирующей ответственностью 4.2 Обязанности и полномочия носителей ключевых должностей с интегрирующей ответственностью ................................................. 122 4.3 Генеральный менеджер ........................................................................ 124 4.4 Группа управления портфелями проектов ........................................ 125 4.5 Спонсор проекта ................................................................................... 126 4.6 Директор по управлению проектами ................................................ 127 4.7 Менеджеры программы, проекта и мультипроекта ........................ 129 4.8 Функциональные руководители, функциональные лидеры проекта, лидеры пакетов работ ............ 131 ...................................... 132 Обязанности и полномочия функциональных руководителей .................................... 132 Обязанности и полномочия функциональных лидеров проекта .................................................. 133 Обязанности и полномочия лидеров пакетов работ 4.9 Альтернативные способы назначения на роль ................................ 134 ............................................... 134 Непрерывность ответственности менеджера проекта ............................................................................. 135 Полная и частичная занятость ........................... 135 Проекты, назначенные на исполнение функциональным менеджерам Несколько проектов, переданных в управление одному менеджеру ........................................................................................ 136 с полной занятостью ....................................................... 137 Разделение обязанностей менеджера проекта ............................. 137 Сохранение роли менеджера проекта за генеральным менеджером ............................ 138 Исполнение роли менеджера проекта в мультипроектных ситуациях 4.10 Факторы, определяющие выбор менеджеров проекта .................. 138 ...................................................... 138 Ключевые личные качества менеджера проекта ............................................................................... 139 Навыки менеджера проекта Обучение и сертификация менеджеров проектов ............................................................ 140 и специалистов по управлению проектами ........................................................................................... 141 Источники кадров ................................................................................ 142 Выбор менеджера проекта 9 Содержание 4.11 Карьерный рост в управлении проектами ........................................ 142 ................................................................. 142 Карьерный рост менеджеров проектов ....................................................... 143 Оценка производительности и карьерный рост ................................................................ 144 Специалисты по управлению проектами 4.12 Выводы .................................................................................................... 144 5 Объединяющие и прогнозирующие планирование и контроль проекта ....................................................................................... 146 5.1 Требования к IPPPC .............................................................................. 146 Необходимость использования единой информационной системы ................................................................................. 147 для управления проектами 5.2 Определение информационных систем управления проектами ......................................................................... 148 Степень детализации документов для планирования проекта, утверждения работ, ........................................................................... 149 контроля и ведения отчетности 5.3 Компьютерные информационные системы управления проектами (ИСУП) .......................................................... 153 Создание, хранение, выборка и обработка электронных документов ...................................................................................... 153 и информации в ИСУП ................................... 154 Управление проектами с использованием Internet технологий ......................... 154 Программное обеспечение распределенного управления проектами .................................................... 155 Программные пакеты для управления проектами .................................................... 155 Комплексные пакеты для управления проектами ............ 157 Программное обеспечение для управления процессами/содержанием проекта ......................................... 157 Программное обеспечение для управления расписанием .......................................... 158 Программное обеспечение для управления стоимостью ............................................ 159 Программное обеспечение для управления ресурсами ..................................... 159 Программное обеспечение для управления коммуникациями 5.4 Выбор и внедрение программных средств управления проектами ......................................................................... 161 Определение проекта выбора, адаптации и внедрения программного средства ..................................................................................... 161 управления проектами Продолжительность проекта выбора, адаптации и внедрения ..................................................... 164 программного средства управления проектами Факторы, которые необходимо учитывать ..................................... 164 при покупке программного средства управления проектами Источники информации, полезные при выборе программного обеспечения ................................................................................. 166 для управления проектами « « » » О русском издании П очти год российские менеджеры имели возможность применять на прак тике советы по управлению программами и проектами одного из наибо лее авторитетных мировых экспертов в этой области – Рассела Д. Арчибальда. Именно столько времени прошло с выхода в свет на русском языке второго из дания книги “Управление высокотехнологичными программами и проектами”. За этот год мы слышали немало отзывов о книге руководителей и специалис тов компаний самых разных отраслей, и большинство этих откликов касалось именно ее применимости. Одним особенно пригодились рекомендации по орга низации и структурированию проектного управления в компании. Другие высо ко оценили описание ролей и вариантов распределения ответственности меж ду участниками проектов. Третьи активно использовали многочисленные примеры и шаблоны. Четвертые готовы лично благодарить автора за изобилие контрольных списков, которые так легко применить «с листа» в большинстве проектов. Иными словами, многие советы автора оказались вполне «интернациональ ными», и любой менеджер, не чуждый проектного подхода к управлению, смог найти в книге Арчибальда что то для себя. Это только подтверждает целесооб разность ее использования именно как справочника, к которому можно обра титься в любой ситуации, чтобы не изобретать очередного велосипеда и к тому же избежать типовых ошибок. В новом издании – и это кажется нам очень полезным и своевременным ша гом – добавлены прямые обращения к высшему руководству, которому небезраз лично качество проектного менеджмента в компании. Это большой шаг на пути 21 О русском издании правильного определения роли и ответственности глав компаний в процессах управления проектами, чему до сих пор в литературе, на наш взгляд, не уделя лось должного внимания. В целом данное издание книги призвано не столько заменить предыду щее, сколько дополнить его. Как и любую хорошую книгу, «Управление высоко технологичными программами и проектами» можно читать с любого места и воз вращаться к ней по прошествии времени. Рекомендации и соображения, изложенные в хорошо структурированной форме, не только не устаревают, но приобретают новый смысл и значение по мере углубления читателя в теорию и практику управления проектами. Это показал опыт работы со вторым издани ем; это же доказывают практические достижения за более чем десятилетний период, прошедший с момента выхода второго издания в США. Не потеряв шая актуальности книга теперь дополнена самыми свежими идеями преуспева ющего менеджера с огромным опытом и талантливого автора – Рассела Д. Арчи бальда. Алексей Арефьев, Алексей Баженов « « » » Предисловие к русскому изданию П рименение принципов и практических приемов управления проектами в России и других странах СНГ в последние годы развивается быстрыми темпами. Наиболее интенсивное использование и совершенствование методик управления проектами как в России, так и в других странах традиционно наблю дается в двух областях: военно промышленный/аэрокосмический комплекс и ка питальное строительство. В дополнение к этому в России – а на самом деле и во всех индустриализованных странах – мы видим, как применение управления про ектами быстро распространяется, по сути, на все остальные отрасли. Сегодня концепции управления проектами проникают практически во все секторы эко номики, бизнеса и государственного управления в большинстве индустриально развитых стран. Хотя основные концепции управления проектами относительно легки для понимания, их правильное и эффективное применение к сложным проектам в организациях со сложной структурой затруднительно. Проекты и центры от ветственности в проектах не поддерживают традиционную иерархию власти и полномочий. Для того чтобы удовлетворять нужды менеджеров проектов и про грамм, а также их руководителей, разработаны особые методы, системы и ин струменты управления. Они требуют понимания, принятия и использования всеми, кто участвует в работе над проектами. 23 Предисловие Достижение такого понимания и принятия зависит от хорошо проработан ного непрерывного процесса обучения и развития сотрудников. Поэтому задача настоящей книги – обеспечить целостные, понятные описание и разъяснение принятых в настоящее время принципов и практических приемов управления проектами с тем, чтобы они могли быть поняты и эффективно использованы. Это, в свою очередь, окажет значительное позитивное воздействие на эконо мическое развитие страны в целом и расширит сферы ее влияния в мире. В последние несколько лет мне было приятно общаться и работать с несколь кими очень способными российскими специалистами в области управления про ектами, включая редакторов этого русского издания – Алексея Баженова и Алек сея Арефьева, а также Владимира Либерзона, соавтора приложения к данной книге, и других специалистов, ссылки на труды которых я приводил в тексте. Российские достижения в области реальной практической интеграции данных о планировании и контроле проектов, описанные в приложении к книге, бу дут несомненно полезны и для практиков на Западе. Хочу верить, что настоя щее издание, оказавшись в руках российских профессионалов, занятых в сфере управления проектами, поможет обеспечить широкое и эффективное приме нение практических приемов управления проектами во всех русскоговорящих регионах. Рассел Д. Арчибальд Сан Мигель де Альенде, Гуанахуато, Мексика ЧАСТЬ I « « » » Административное руководство по управлению программами и проектами Ч асть I настоящей книги предназначена для менеджеров высшего звена, от вечающих за стратегическое руководство и развитие организации, а также для тех, кто несет ответственность за портфели проектов и за составляющие их программы и проекты. Часть I также будет полезна менеджерам и специалистам по управлению программами и проектами. Наряду с материалом, изложенным в части II (и предназначенным главным образом именно руководителям среднего звена), материал части I поможет читателям достичь более полного понимания дисциплины управления и признать ее важность в обеспечении успешной дея тельности организации. В части I данной книги высшему руководству и другому персоналу предлагает ся детальное рассмотрение следующих аспектов: • роли, которые играют проекты в стратегическом управлении организаци ей, и способов интеграции управления проектами с общей корпоративной структурой (глава 1); • характера и ключевых характеристик программ и проектов; • ценности и стоимости управления проектами в организации, а также спосо бов улучшения ее возможностей по управлению проектами (глава 3); • трех базовых концепций, используемых в современном управлении проек тами: интегрирующих должностей, объединяющего и прогнозирующего планирования и контроля, командной работы в проектах (главы 4 6); • организации и функций поектного офиса; • управления портфелями проектов, программами и мультипроектами. Каждая глава части I завершается перечислением ряда требований, которые 1 исполнительный директор должен предъявлять к организации управления про ектами в своей компании. Эти требования, будучи вполне разумными и достижи мыми при современном уровне знаний, указывают высшему руководству путь к максимальному использованию всех возможностей, предоставляемых интегри рованным управлением проектами в сегодняшнюю эру эру сети Internet. 1 CEO (Chief Executive Officer) «исполнительный директор»; этот термин в тексте книги часто будет обозначать высшее руководство компании в целом. – Прим. ред. 1 « « » » Обзор управления проектами 1.1 ВАЖНОСТЬ ЭФФЕКТИВНОГО УПРАВЛЕНИЯ ПРОЕКТОМ Для многих коммерческих и государственных организаций программы и проек ты имеют огромную важность. Благодаря им многие компании могут существен но увеличить свою прибыль, особенно при поставках заказчикам сложной высо котехнологичной продукции или систем. Проекты также играют большую роль в процессе создания концепции продукта, его разработки и вывода на рынок. В ходе реализации проектов создаются новые или усовершенствованные сред ства производства, новые информационные системы. Широкомасштабные про екты в области менеджмента, такие как реструктуризация или реорганизация, общее снижение затрат и себестоимости, перемещение завода или офиса и т.п., жизненно необходимы для продолжения успешной деятельности и развития предприятий. Проекты представляют собой инструмент развития и совершенствования го сударственных организаций на всех уровнях: города, района, страны. При по мощи программ и проектов образовательные, здравоохранительные и другие учреждения вводят новые и совершенствуют уже предоставляемые ими услу ги. Но во всех этих организациях – государственных, общественных и коммер ческих – отмечается, что, хотя в них фактически ведется много проектов, они часто плохо продуманы и лишены должного управления. Цель данной книги – помочь исправить ситуацию благодаря представлению понятной, полной и име ющей практическое значение картины, раскрывающей концепции, процессы, методы, средства профессионального управления проектами, а также способы их эффективного применения и непрерывного совершенствования в высоко технологичном окружении. 34 Обзор управления проектами Проекты существуют во всех организациях – это комплекс усилий, предпринимаемых с целью получения конкрет Проект ных уникальных результатов в рамках отведенного времени и в пределах утверж денного бюджета, который выделяется на оплату ресурсов, используемых или потребляемых в ходе проекта. Под программой в рамках данной книги понимает ся группа из двух или более взаимосвязанных проектов. Более детальное опре деление проектов и программ приведено в главе 2. Понятие проекта далеко не ново. Проекты существуют во всех без исключе ния организациях, бывают большими и малыми, сложными и простыми, риско ванными и не рискованными, могут приводить к разнообразным результатам. Принципы современного управления применимы ко всем этим проектам в са мых различных компаниях. Быстрое распространение управления проектами В последнее время использование принципов и методов управления проектами получило широкое распространение во всем мире и коснулось всех областей че ловеческой деятельности. Количество книг, печатных и электронных журналов, Internet сайтов, семинаров, форумов, профессиональных и популярных статей по управлению проектами продолжает возрастать. Профессиональные ассоци ации также расширяются с впечатляющей скоростью: так, общее количество чле нов Института управления проектами (Project Management Institute, PMI – www.pmi.org) выросло от 8500 человек в 1990 году до более чем 100000 человек в 2003 году. Филиалы PMI открыты в 39 странах, а члены Института проживают в 80 странах. Международная ассоциация управления проектами (International Project Management Association, IPMA – www.ipma.ch) представляет собой меж дународную сеть, куда входят 28 национальных обществ управления проектами. Заслуживают упоминания Ассоциация управления проектами (Association of Project Management, APM – www.apm.org.uk), являющаяся членом IPMA, Ассоци ация управления разработкой продуктов (Product Development Management Association, PDMA – www.pdma.org) и Ассоциация развития стоимостного инжи ниринга (Association for the Advancement of Cost Engineering, AACE – www.aace.org). Web сайты каждой из этих ассоциаций содержат ссылки на множество имею щих отношение к управлению проектами организаций, форумов, журналов, школ, обучающих агентств, разработчиков программного обеспечения и фирм консультантов. Разнообразие и классификация проектов Разнообразные области применения управления проектами сведены в 24 основ ные группы по интересам (Specific Interest Groups, SIG), действующие в рамках PMI (табл. 1.1). Каждая из этих групп объединяет руководителей и практикующих 35 Важность эффективного управления проектами специалистов по управлению проектами, имеющих схожие интересы. Кроме этого, в PMI существуют дополнительные группы, которые имеют дело с част ными аспектами управления, касающимися всех основных областей. Деятель ность Колледжа по измерению производительности при PMI (PMI College of Per formance Measurement) посвящена военной и аэрокосмической областям. Управление проектами также показало свою эффективность в сфере реинжи ниринга и реструктуризации существующих организаций и бюрократических процессов. Òàáëèöà 1.1. Îñíîâíûå ãðóïïû ïî èíòåðåñàì â PMI 1. Аэрокосмическая и оборонная 2. Системы автоматизации 3. Автомобильная 4. Проектирование/снабжение/строительство (во всех отраслях) 5. Охрана окружающей среды (предотвращение и нейтрализация последствий загрязнения) 6. Финансовые услуги (банковское дело, инвестиции) 7. Глобальные технологии передачи данных и связи (управление и передача информации) 8. Правительство 9. Массовые мероприятия (крупные события, например Олимпийские игры) 10. Информационные системы 11. Международное развитие (инфраструктура, сельское хозяйство, образование, здравоохранение и т.д.) в развивающихся странах 12. Производство 13. Маркетинг и продажи 14. Разработка новых продуктов 15. Нефть/газ/нефтехимия 16. Фармацевтика 17. Розничная торговля 18. Услуги и аутсорсинг (покупка на стороне, а не изготовление собственными силами) 19. Коммунальное хозяйство (выработка и распределение электроэнергии, воды, газа) Несмотря на разнообразие конечных продуктов или результатов, создавае мых в этих различных отраслях, подход к управлению проектами в них на удив ление близок. Сам по себе проект не есть конечный результат, будь то новый продукт, производственное сооружение, завод, информационная система, про цесс реинжиниринга, новая организационная структура, документ или любое другое достижение. Правильнее сказать, что проект есть процесс создания нового конечного результата. Одни и те же принципы управления проектами применимы 36 Обзор управления проектами к проектам во всех предметных областях, хотя существуют значительные разли чия в акцентах и деталях планирования/исполнения проектов, зависящие от конкретной предметной области и культурной среды. Глобализация коммерческой деятельности, производства, энергетики, освое ния космического пространства, информационных технологий, сервисных от раслей и многих других областей человеческой деятельности – мощная движу щая сила развития общих подходов к планированию и исполнению проектов в разных секторах экономики и по всему миру, без учета национальных границ. Проекты международных совместных предприятий, предусматривающие полу чение таких результатов, как нефте и газопроводы, производственные мощнос ти, космические корабли и орбитальные станции, воздушные суда, автомобили, новые информационно технологические платформы и их применение – и это лишь немногие примеры! – требуют, чтобы все участвующие в проекте стороны (часто пребывающие на разных континентах и в самобытных культурных сре дах) использовали одинаковые или по крайней мере схожие системы управле ния проектами. Сотрудничество, необходимое для успешного выполнения та ких проектов, может быть эффективно достигнуто только в том случае, если каждая сторона понимает, что и как делают остальные, а также если планы и расписания взаимосвязанных проектов или программ объединены, причем используют одинаково понимаемую терминологию и методику управления. Важность эффективного управления проектами для всех организаций Проекты должны тщательно продумываться и качественно управляться как в ходе планирования, так и в ходе исполнения. Это необходимо для достижения желаемых результатов в установленные сроки и в рамках определенных расхо дов денежных или иных важных ресурсов. На практике ошибки в отборе проек тов, анализе рисков и концептуальном планировании приводили к следующему: • ограниченные ресурсы (деньги, профессиональные навыки, производствен ные мощности, время) расходовались на заведомо бесполезные операции; • финансовый, технологический и конкурентный риск организации возрас тал до неприемлемого уровня. Ошибки планирования и исполнения проектов имели такие последствия: • ожидаемая прибыль от коммерческих контрактов оборачивалась убытка ми из за превышения первоначальной стоимости, несоблюдения сроков и выплаты штрафов; • новые продукты выводились на рынок с большим опозданием, что пагубно отражалось на достижении целей бизнес плана и на возможностях продви жения продуктов на рынке; 37 Важность эффективного управления проектами • проекты по разработке новых продуктов завершались слишком поздно для того, чтобы можно было получить ожидавшиеся выгоды от их производ ства, либо по другим причинам не давали ожидаемых результатов; • задерживался ввод в действие основных средств, что приводило к невы полнению бизнес целей по линейкам продуктов, для которых предназнача лись эти средства; • проекты по информационным системам выполнялись с нарушением гра фика и превышением бюджета, что отрицательно влияло на управление, общие затраты и эффективность деятельности. Исследование хаоса (“Chaos Study”, см. www.pm2go.com/default.asp), проведенное Standish Group, по зволило сделать заключение, что только один из шести проектов по разра ботке программного обеспечения выполняется в соответствии с качествен ными, временными и стоимостными целями. Около половины проектов было остановлено до их планируемого завершения. Ошибки в одном значительном проекте способны свести на нет прибыль от множества других связанных с ним проектов, обеспеченных должным управле нием. Слишком часто мониторинг и оценка высокорискованных проектов ока зываются неэффективными, и ошибки становятся очевидными тогда, когда уже поздно предпринимать какие либо меры по исправлению нежелательных послед ствий. Поэтому важно, чтобы каждая организация, несущая ответственность за проекты, обладала умением эффективно ими управлять. Проектно ориентированные и проектно зависимые организации Из всего многообразия организаций можно выделить два обширных класса. Пер вый включает в себя организации, основной бизнес проектно ориентированные которых составляют проекты. К этому классу относятся архитектурные/инже нерные/конструкторские фирмы, фирмы – генеральные подрядчики, фирмы субподрядчики (выполняющие контракты на специфические работы), фирмы разработчики программного обеспечения (продающие свои продукты или услуги на контрактной основе), поставщики телекоммуникационных систем, консал тинговые агентства и другие компании, поставляющие услуги в тех или иных областях профессиональной деятельности, а также организации, получающие прибыль за счет выполнения одного проекта за другим. Стратегии роста в таких организациях находят свое отражение в характере, размерах, месте выполне ния и роде проектов, предлагаемых фирмой, а также в выборе способа обеспе чения этих проектов ресурсами (внутреннее обеспечение или аутсорсинг) при заключении контракта или ином утверждении проекта. Второй класс организаций – проектно зависимые, то есть те, рост которых за висит от проектов. Это организации, главным образом предлагающие товары и услуги. Проекты в этих организациях спонсируются и финансируются главным 38 Обзор управления проектами образом изнутри. Примеры можно найти в области производства (потребитель ских товаров, фармацевтической продукции, инженерной продукции и т.д.), транспорта, связи, разработки и продажи аппаратного и программного обеспе чения, а также в банковском деле, правительственной сфере, университетах, об щественных учреждениях и др. Эти организации зависят от проектов, которые обеспечивают выживание их основного бизнеса, но на рынок предлагают в пер вую очередь не проекты. Многие спонсоры внутренних проектов являются круп ными заказчиками для проектно ориентированных организаций. 1.2 ПРОЕКТЫ – СРЕДСТВА СТРАТЕГИЧЕСКОГО РАЗВИТИЯ ОРГАНИЗАЦИЙ Стратегическое управление развитием компании, учреждения, института и т.п. требует: • видения будущего организации на высшем уровне; • отсутствия разногласий во взглядах руководства на миссию и дальнейшие пути развития организации, приверженности руководства этим взглядам; • ключевых целей и стратегий для выполнения миссии орга документирования низации; • реализации или исполнения конкретных проектов для осуществления заявлен ных стратегий и достижения желаемых целей. Цель – это описание того, чего мы хотим достичь. Стратегия – это констата ция того, каким образом мы собираемся достичь цели. Стратегии осуществля ются, а цели достигаются в процессе прохождения значительных шагов на пути развития предприятия вследствие исполнения проектов и мультипроектных про грамм в рамках портфелей проектов организации. Проекты преобразуют стра тегии в действия, а цели – в реальность. В большинстве организаций вне зависимости от их размера уже установились процессы стратегического планирования или управления развитием и как ми нимум раз в год составляются долгосрочные планы, утверждаются цели и выра батываются стратегии. Важно понимать, что в большинстве организаций цели и стратегии образуют иерархическую структуру, а не один единственный уро вень. Для описания этой иерархической структуры можно выделить три различ ных уровня: • политический; • стратегический; • операционный. 39 Проекты – средства стратегического развития организаций На рис. 1.1 представлены эти уровни и показано, как стратегии становятся целями на следующем, более низком уровне иерархии вплоть до операционно го, на котором определяются проекты для достижения операционных целей. Если цели и стратегии высшего уровня не будут преобразованы в действия в виде проектов, они так и останутся на бумаге. Приверженность общему курсу компании Утверждение о миссии и целях компании Уровень политики компании Цель Цель Цель Цель №1 №2 №3 №4 2.4 1.2 2.3 3.3 1.3 2.2 3.2 4.2 Стратегия Стратегия Стратегия Стратегия 1.1 2.1 3.1 4.1 Уровень стратегий Цель 1.1 Стратегия Стратегия Стратегия Стратегия 1.1.1 1.1.2 1.1.3 1.1.4 Уровень операций Целевой проект 1.1.1.1 Детальные стратегии и планы проекта Ðèñóíîê 1.1. Èåðàðõèÿ öåëåé, ñòðàòåãèé è ïðîåêòîâ. Èñòî÷íèê: Russell D. Archibald. Projects: Vehicles for Strategic Growth // Project Management Journal, XIX, 4 (September 1988), p. 32. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðà 40 Обзор управления проектами Источники развития Можно определить два способа развития организаций: • – медленное стабильное увеличение количества и объема плавное развитие производства основных видов продукции, услуг, расширение рынков, уве личение численности персонала; • скачкообразное развитие – развитие происходит отдельными скачками (не большими, средними и большими), которые не укладываются в рамки плав ного развития. Плавное развитие – процесс относительно медленный и чаще всего наблю даемый в наиболее развитых, устойчивых отраслях. Примером может служить постепенное увеличение объема продаж за счет повышения профессионализ ма отдельных менеджеров по продажам, реализующих весь объем производи мой продукции, а также за счет более эффективного маркетинга и рекламы. Как только производственные мощности начинают сдерживать объем продаж (несмотря на то что уже были введены вторая и третья смены), дальнейший рост возможен только при осуществлении значительного или скачкообразно го изменения – строительства новой фабрики или расширения производства на старой. Разнообразие проектов развития В табл. 1.2 приведены примеры проектов развития, отличающихся как по вели чине, так и по реализуемым ими стратегиям роста. Более крупные и рискован ные проекты требуют более формализованных методов управления. Программы и проекты – средства развития Скачкообразное развитие подразумевает широкий диапазон действий – от неболь ших шажков с малым риском до крайне рискованных гигантских шагов, которые ставят на карту судьбу компании. Практически невозможно провести четкую грань между плавным ростом и маленькими шажками по расширению, такими как при ем на работу еще одного продавца или использование нового дистрибьютора в новом регионе для уже существующей линейки продуктов. Но когда эти шаги становятся значительными, о них обычно говорят как о проектах. Осуществление значительных шагов на пути развитии организации требует их исполнения в виде проектов независимо от того, касается ли это новых средств производства, систем, видов продукции, услуг, процессов, технологии или рынков. Приобретение всего вышеперечисленного за счет создания внутрен них компаний или совместных предприятий, путем покупки другой организации, 41 Стратегическое управление портфелями проектов Òàáëèöà 1.2. Ïðèìåðû ïðîåêòîâ ïî ðàñøèðåíèþ èëè èçìåíåíèþ äåÿòåëüíîñòè Размер проекта Продукты или услуги Рынки Выгоды Малый Формирование Добавление нового Изменение линейки нового пакета услуг. дистрибьютора. продуктов. Небольшое улучшение Рекламная кампания Увеличение цен продукта в местных масштабах Крупный Разработка нового Выход на новые Новая продукта в рамках рынки – внутренние информационная выпускаемой линейки и внешние система. продуктов. (иностранные): Реструктурирование Расширение – напрямую; организации. существующего завода. – путем Новые политики Проектирование лицензирования; и процедуры или строительство – путем нового завода организации совместных предприятий Мега проект Разработка или Приобретение Слияние приобретение новой крупной компании с конкурентом линейки продуктов слияния, лицензирования или иными методами почти всегда выливается в про ект той или иной степени сложности. Все больше и больше организаций в на стоящее время признает этот факт и подходит к управлению такими скачками в своем развитии, используя проверенные на практике принципы и методы управ ления проектами. 1.3 СТРАТЕГИЧЕСКОЕ УПРАВЛЕНИЕ ПОРТФЕЛЯМИ ПРОЕКТОВ Проекты – это основной объект инвестирования в большинстве организаций. Инвестициями необходимо управлять на портфельной основе. Ниже рассмат риваются характеристики и процессы управления портфелями проектов, полу чившие распространение в последнее десятилетие. Интегрированное управление портфелями проектов Отказавшись управлять отдельными проектами так, как будто они являются не зависимыми начинаниями, руководители усвоили, что каждый проект связан – главным образом через использование общих ресурсов, хотя часто и иными 42 Обзор управления проектами способами – с другими проектами в организации. Установление взаимосвязей между некоторыми выбранными проектами, входящими в программу, – первый шаг к управлению портфелем проектов. Дай (Dye) и Пеннипеккер (Pennypacker) со ставили полезную и исчерпывающую подборку статей, отражающих становле ние и развитие дисциплины управления портфелями проектов во многих орга низациях [32]. Управление мультипроектами в сравнении с управлением портфелями проектов Ключевые различия между управлением мультипроектами и управлением порт фелями проектов приведены в табл. 1.3. Как показано на рис. 1.2, портфель проектов состоит из программ и проектов, поддерживающих ту или иную стра тегию более высокого иерархического уровня. Хотя в организации может су ществовать только один общий корпоративный портфель проектов, в крупных фирмах часто представляется более разумным определить несколько портфе лей для различных стратегических целей организации, линеек продукции, гео графических регионов, технологических подразделений, предметных областей и рынков. Комби (Combe) и Гитенс (Githens) выделяют три основных типа порт фелей проектов [19]: • создающие ценности: стратегические проекты или проекты в масштабах пред приятия; • операционные: проекты, которые приводят к повышению эффективности организации и соответствуют основным нуждам функциональных подраз делений; • обязательные проекты, необходимые для под обеспечивающие соответствие: держания внутренних нормативов и стандартов. Комби утверждает: “наше высшее руководство [имеется в виду высшее руко водство Northwestern Mutual, крупной компании, предлагающей различные фи нансовые услуги. – Р. А.] было воистину изумлено результатами”, полученными в ходе анализа проектного бюджета 1998 года: из 85 млн. долларов, выделенных на проекты, лишь только 20% (17 млн. долларов) было отведено на выполнение проектов стратегического назначения. В организациях, достигших зрелого подхода к управлению проектами, за ре шения, принимаемые по входящим в портфели программам и проектам, несет ответственность специально сформированная из руководителей высшего звена группа, называемая Группой управления портфелями проектов. Ее обязанности бо лее подробно рассматриваются в главах 4 и 8. 43 Стратегическое управление портфелями проектов Таблица 1.3. Сравнение (на высоком уровне) управления портфелями проектов и управления мультипроектами. Источник: Lowell D. Dye, James S. Pennypacker. Project Portfolio Managing and Managing Multiple Projects: Two Sides of the Same Coin? / Proceedings of the 2000 PMI Seminar & Symposium. – Newton Square, PA: Project Management Institute Управление Управление портфелями проектов мультипроектами Цель Выбор проектов Распределение ресурсов и расстановка приоритетов Установка Стратегическая Тактическая Основной акцент ...долговременном ...кратковременном на планировании... и промежуточном (ежедневном) (ежегодном/ежеквартальном) Ответственные Высшее/старшее Менеджеры лица руководство проектов/ресурсов Стратегическая цель Операционная Операционная Операционная Операционная Операционная Операционная стратегия 1.1 стратегия 1.2 стратегия 1.3 стратегия 1.1 стратегия 1.2 стратегия 1.3 Проект 1.1.3 Проект 1.3.3 Проект 1.2.2 Проект 1.1.2 Проект 1.3.2 Проект 1.2.1 Проект 1.1.1 Проект 1.3.1 Программа 1.1 Портфель проектов для стратегической цели 1 Рисунок 1.2. Схематическое изображение стратегий, проектов, программ и портфелей проектов 44 Обзор управления проектами Процесс управления портфелями проектов Процесс управления портфелями проектов включает в себя следующие двенад цать этапов: 1. Определение портфелей проектов, которые необходимо сформировать в организации. Например, портфели проектов могут носить следующие названия: “Линей ка продуктов A”, “Информационно технологическое развитие”, “Корпора тивные информационные системы”, “Подразделение X”, “Международный портфель”, “Стратегический портфель”, “Операционный портфель” и “Портфель обеспечения соответствия регуляциям”. 2. Определение категорий проектов в портфелях, основанное на критериях, неизменных Примеры категорий (или типов) проектов: проектиро для всей организации. вание и сооружение средств производства, информационные технологии, разработка и выпуск на рынок новых товаров/услуг, освоение нового рын ка, приобретения, разработка систем электронной коммерции (см. главу 2). 3. Идентификация и распределение всех текущих и предлагаемых проектов по катего риям и программам. Выбор новых проектов, которые надлежит включить в конкретный портфель, особенно при исследованиях и разработке ново го продукта (НИОКР), – процесс весьма сложный (см. [26, p. 23]). Это дело входит, скорее, в задачу руководства, осуществляющего стратегическое управление организацией, чем в задачу менеджеров проектов, хотя учас тие обеих сторон может быть полезным. 4. Подтверждение того, что все проекты соответствуют стратегическим целям орга низации. Следует убедиться, что каждый проект прямо и недвусмысленно ведет к установленной стратегической цели. Каждая ли стратегическая цель в явной форме поддерживается соответствующими проектами? 5. Определение степени важности проектов в программах и портфелях. При расста новке приоритетов следует руководствоваться стратегическими соображе ниями, а не внутренними политиками. Это опять же относится в большей степени к функциям руководства, осуществляющего стратегическое управ ление организацией, а также Группы управления портфелями проектов. Для ознакомления с методами расстановки приоритетов, используемыми неко торыми ведущими компаниями, обратитесь к книге [26, p. 9]. 6. Разработка главного расписания проекта. Сюда необходимо включить логи ческие взаимозависимости проектов. На этом и последующих этапах следу ет использовать методы и инструменты управления проектами. Первона чальный вариант главного расписания проекта должен периодически подвергаться пересмотру и отражать текущий ход выполнения активных проектов. 7. Формирование и ведение банка данных ключевых ресурсов. С практической точки зрения представляется необходимым ограничить количество “ключевых 45 Стратегическое управление портфелями проектов ресурсов”, выделяемых в проекты, хотя современные системы управления проектами теоретически позволяют управлять большими объемами таких ресурсов. 8. Отразить Выделение доступных ресурсов в программы и проекты из портфелей. ресурсные ограничения следует как в приоритетах и расписаниях отдель ных проектов, так и в главном расписании портфеля проектов (при необ ходимости несколько раз повторять действия, описанные в пп. 5–8). 9. Сравнение объемов финансовых потребностей (особенно в “живых деньгах”) с до ступными средствами. Хотя деньги обычно добыть легче, чем другие ключе вые ресурсы – например, людей с конкретными знаниями и навыками, – всегда существует предел финансовых возможностей. 10. Принятие решений о том, каким способом нужно реагировать на недостаток денег или дефицит других ключевых ресурсов, и чем руководствоваться при утверждении списка финансируемых проектов и приоритетов. Требуется изучать приорите ты, содержания и последовательность проектов в портфелях; отменять или задерживать выполнение менее приоритетных проектов; приобретать дополнительные ресурсы, если это возможно и желательно; наконец, по вторять действия, описанные в пп. 5–10, до тех пор, пока деньги или иные ключевые ресурсы в доступном объеме не будут выделены на проекты оп тимальным образом. 11. Планирование, утверждение и управление каждой программой и каждым проектом с использованием процессов управления проектами организации, а также вспомога тельных систем и инструментов в каждой категории проектов. Менеджеры и ко манды проектов выверяют и тщательно прорабатывают планы, используе мые при утверждении проекта, а затем управляют фазой исполнения проекта. 12. Регулярный пересмотр приоритетов, перераспределение ресурсов, календарное пере планирование всех программ и проектов в портфелях. Отражаются изменения в стратегиях, продуктах, рыночной ситуации, конкурентной ситуации, тех нологиях, а также ход исполнения каждого проекта. Добавляются вновь предложенные проекты. Действия, описанные в пп. 1–12, следует повто рять по мере необходимости (как правило, ежемесячно). Группа управле ния портфелями проектов дает стратегические указания каждому спонсо ру всех проектов, а те, в свою очередь, интерпретируют указания и доводят их до сведения соответствующих менеджеров. Управление портфелями проектов связывает стратегическое управление и управление проектами На рис. 1.1 и 1.2 показано, как управление портфелями проектов связывает стра тегическое управление и управление проектами. Старшие менеджеры линеек в организации являются создателями стратегий развития и “владельцами” 46 Обзор управления проектами проектов, с помощью которых будут проводиться в жизнь эти стратегии. В каж дом проекте существуют назначенный спонсор, несущий исполнительную от ветственность за проект, и менеджер, являющийся ключевым лицом, которое олицетворяет объединяющую ответственность и отчетность за планирование/ исполнение проекта. Высшее руководство устанавливает будущий стратегичес кий курс организации и выбирает проекты, которые должны быть включены в портфели. Управление проектами подразумевает планирование, утверждение и выполнение конкретных действий, проводящих в жизнь стратегии развития. Менеджеры этих проектов действуют от лица их владельцев, представляя инте ресы последних, и получают указания через спонсоров проектов. Соответству ющие обязанности детально рассмотрены в главах 4 и 8. Связь между стратегическим управлением и управлением проектами, которую обеспечивает управление портфелями, нельзя назвать поверхностной. Комби (Combe), обсуждая двунаправленный поток информации, необходимый для обес печения эффективного выполнения стратегий, пишет: “Важно, чтобы высшее руководство рассматривало проекты как средства проведения в жизнь страте гий и вводило такие порядки, которые ставили бы проекты в возможно лучшее положение – чтобы облегчить реализацию этих стратегий. Не менее важно так же, чтобы менеджеры проектов имели четкое понимание стратегий компании… Только когда связь между проектами и стратегиями функционирует в обоих направлениях, организация действительно сможет получить выгоды…” [20]. Сре ди прочего Комби отмечает, что для создания двунаправленного потока необхо димо соблюдение следующих условий: наличие менеджеров проектов, руково дящих людьми, занятыми в проекте, и объединяющих их усилия; наличие четко определенной стратегии; установление определенного временного интервала для выполнения проекта. Управление проектами в масштабах предприятия В некоторых предметных областях отмечается повышение интереса к подходу, называемому управлением проектами в масштабах предприятия. Согласно этой кон цепции, предприятие рассматривается как состоящее из совокупности проектов или из одного/нескольких портфелей проектов, и управляется соответствующим образом. Динсмор (Dinsmore) описывает, как может функционировать организа ция, для которой управление проектами является внутренним кредо. Он опреде ляет управление проектами в масштабах предприятия следующим образом: Принятая в масштабах организации управленческая философия, основанная на прин ципе, согласно которому цели компании могут быть достигнуты путем одновременно го выполнения совокупности проектов, требующих систематического подхода и вклю чающих в числе прочего стратегические проекты, проекты совершенствования операций, проекты трансформации организации, а также традиционные проекты развития [31, p. 19]. 47 Инвентаризация: реестр проектов Надо полагать, этот подход может получить свое развитие, однако в настоя щее время он кажется применимым только к нескольким типам организаций. 1.4 ИНВЕНТАРИЗАЦИЯ: РЕЕСТР ПРОЕКТОВ Первый важный шаг, рекомендованный при любых действиях по совершенство ванию управления проектами, – проведение инвентаризации программ и про ектов вне зависимости от того, находятся ли они в фазе исполнения, планиро вания или формирования концепции. Результатом такой инвентаризации может стать создание реестра проектов, где для каждой программы или каждого проекта должны быть указаны: • серийный номер или иной идентификационный код проекта/программы; • полное имя менеджера проекта/программы и доля времени, которое он уделяет проекту/программе; • назначенный спонсор (если таковой имеется); • заказчик или клиент; • стоимость проекта в долларах или иной валюте (сумма по контрактам, ин вестиционные затраты или другая денежная мера стоимости проекта); • категория проекта и указание на то, является этот проект большим или ма лым (см. главу 2); • ключевые трудозатраты (человеко месяцы, человеко годы); • возможная подверженность убыткам в долларах или иной валюте (штра фы, потеря рынка, результат конкуренции, выплаты по гарантийным обя зательствам и т.д.); • наиболее важные риски (экономические, природные, политические, кон курентные, технологические); • ключевые даты начала, прохождения контрольных событий и завершения (заключения и завершения исполнения контракта, аренды, выполнения и т.д.); • взаимосвязанные проекты (строительство основных производственных мощностей, НИОКР, другие контракты); • идентификационный код программы (в случае, если проект является час тью программы); • идентификационный код портфеля, куда входит данный проект; • идентификационный код инстанции, утвердившей проект. Даты представ ления на рассмотрение высшему руководству и разрешения на выполнение; • другая относящаяся к проекту информация. 48 Обзор управления проектами Перегрузка проектами Высшее руководство часто удивлено тем, сколько проектов обнаруживается при тщательной и непредвзятой подготовке реестра проектов. Такой реестр, содержа щий все разрешенные к выполнению проекты, равно как и уже исполняемые или планируемые, для которых формальная авторизация по каким либо причинам не была осуществлена или даже предусмотрена, даст четкий ответ на вопрос, не пере гружена ли организация чрезмерным количеством проектов при имеющихся ре сурсах. Если слишком много проектов начали исполнять без тщательного планиро вания ресурсов, все эти работы, скорее всего, будут выполнены с задержкой. Если методы формального управления проектами и процедуры планирования отсутству ют, перегрузка может произойти без ведома высшего руководства. Вероятно, для обнаружения всех проектов, ведущихся в организации, понадобится внимательно изучить документацию всех функциональных подразделений. Основные обязанности высшего руководства в данном аспекте могут быть сформулированы следующим образом: • установить критерии, определяющие категории и размеры проектов; • потребовать составления и ведения реестра проектов; • установить и при необходимости пересматривать приоритеты программ и проектов. Эти действия, более детально рассматриваемые в главах 4 и 8, создадут осно ву для эффективного использования двенадцати этапов управления портфелем проектов. 1.5 ПРОЦЕСС УПРАВЛЕНИЯ ПРОЕКТАМИ В ОРГАНИЗАЦИИ Современное управление проектами ставит перед собой двоякую задачу: • гарантировать, что каждый задуманный и утвержденный к исполнению проект поддерживает установленные стратегические цели высшего уров ня, причем достижение целей проекта сопровождается риском приемле мого уровня: конкурентным, экономическим, политическим, техническим, стоимостным и временным; • планировать, контролировать и вести каждый проект одновременно со все ми остальными так, чтобы все они выполнялись эффективно и достигали намеченной цели. Под целью проекта понимается решение соответствую щей стратегической задачи организации в отведенные сроки и в пределах утвержденного бюджета. 49 Процесс управления проектами в организации Первая из задач управления проектами тесно связана со стратегическим управлением организацией. В последние годы методики систематического управления проектами на раннем этапе стратегического планирования и на кон цептуальной фазе проекта стали применяться во многих организациях, и резуль таты выглядят обнадеживающе. Однако проекты все еще слишком часто терпят неудачи из за нереалистичных технических, стоимостных или временных це лей, поставленных без учета объема доступных ресурсов, а также из за неадек ватного анализа рисков и управления ими. Управление жизненным циклом проекта плюс управление рисками В первые десятилетия современного управления проектами основной акцент делался на второй цели из двух названных в предыдущем разделе. Так или ина че, проект задумывался и утверждался, после чего передавался менеджеру про екта для планирования, составления расписания, выполнения и мониторинга в ходе всех фаз жизненного цикла. Но даже самые эффективные методы плани рования и контроля и самый преданный делу менеджер проектов с самой толко вой командой не могут избежать неудач или предотвратить их в том случае, ког да изначально поставлены недостижимые цели или когда предпринимается недопустимый риск. Повторяющиеся неудачи в достижении целей проекта при вели к осознанию того, что систематическое управление проектами должно при меняться на их концептуальной фазе в той же мере, что и на фазе исполнения. Теперь мы признали, что для достижения успеха управление проектом на протяже нии всего жизненного цикла должно сочетаться с адекватным управлением рисками. По мере того как методы управления проектами стали применяться к концеп туальным фазам, необходимость анализа и уменьшения рисков, равно как и раз работки способов реагирования на них, стала более очевидной. Сегодня первая цель управления проектами (из названных в предыдущем разделе) получает все более широкое признание, и для того, чтобы обеспечить достижение каждым проектом обеих базовых целей, постоянно разрабатывают новые методы, ин струменты и системы. Документирование процесса управления проектами в организации Чтобы достичь всех преимуществ, предоставляемых современным управлени ем проектами, каждая компания или организация должна документировать об щую картину существующего процесса управления проектами. Этот процесс: • показывает, каким образом портфели проектов организации связаны со стратегиями развития организации; 50 Обзор управления проектами • идентифицирует и определяет основные типы или категории проектов – как исполняемых, так и находящихся в стадии планирования (см. гла ву 2); • определяет жизненный цикл проекта и детальный процесс управления проектами (Project Life Cycle Management System, PLCMS, то есть систему управления жизненным циклом проекта – см. главу 3) для каждой катего рии проектов; • определяет для каждой категории проектов корпоративные указания по выполнению анализа рисков, планирования и контроля, а также по спосо бам их адаптации к конкретной ситуации; • определяет необходимые документы и соответствующие утверждающие инстанции, имеющие полномочия на инициацию и утверждение новых проектов, а также на внесение изменений в утвержденные проекты; • идентифицирует ключевые роли (должности), определяет соответствую щие обязанности и полномочия в области стратегического, проектного и функционального управления; • определяет и описывает методы, процедуры и инструменты (в том числе программное обеспечение управления проектами), которые должны ис пользоваться для каждой категории проектов; • определяет процедуры переноса неизбежных конфликтов (таких как борь ба за ограниченные ресурсы, конфликты приоритетов проектов и др.) и нерешенных вопросов на тот уровень, на котором они могут быть ре шены. Этот процесс обычно документируется в виде диаграмм с текстовым ком ментарием и ссылками на соответствующие корпоративные политики, проце дуры и формы. Если все сделано правильно, в результате достигается интегри управление проектами. Только в том случае, когда процесс управления рованное проектами должным образом документирован, могут планироваться и осу ществляться эффективные действия по его усовершенствованию, как показа но в главе 3. Разнообразие областей применения управления проектами, различия между категориями (типами) проектов, индивидуальные особенности каждого проек та, – все это затрудняет (если не делает невозможным!) составление примера хорошо документированного процесса управления проектами, который был бы применим и полезен в любой ситуации. Далее в этой книге рассматриваются блоки – концепции, методы и инструменты, – используемые при разработке, ре ализации и непрерывном совершенствовании процесса управления проектами; читатель получит представление о том, как эти блоки могут быть реализованы применительно к конкретной ситуации. 51 Триада концепций управления проектами 1.6 ТРИАДА КОНЦЕПЦИЙ УПРАВЛЕНИЯ ПРОЕКТАМИ Ниже приводятся три концепции, лежащие в основе профессионального управ ления проектами: 1. Определение центров ответственности за проект в целом (интегративной ответственности). 2. Интегральное (комплексное) и прогнозирующие планирование и контроль. 3. Определение, создание команды проекта; лидерство в команде и руковод ство ею с целью объединения и координации усилий всех исполнителей работ. Определение центров ответственности за проект в целом В любой организации, выполняющей проект, на различных уровнях управления должны быть установлены должности, которые предполагают ответственность за ход работы над проектами. Наиболее важны следующие: • на уровне высшего исполнительного руководства компании: – исполнительный директор/генеральный менеджер; – группа (группы) управления портфелем проекта; – спонсоры проектов. – менеджер/директор/вице президент по управлению проектами (дирек тор офиса управления проектами); • менеджеры программ/проектов; • руководители функциональных подразделений и функциональные лидеры проекта. Роль менеджера программы/проекта оказывается в центре внимания большин ства авторов книг по управлению проектами, однако другие перечисленные роли столь же важны для достижения эффективного управления. Эти должности и со ответствующие им обязанности подробно обсуждаются в главе 4 и части II. Комплексные и прогнозирующие планирование и контроль Вторая концепция триады управления проектом требует, чтобы планирование и контроль в каждом проекте были интегральными, комплексными. Это означа ет, что планирование и контроль должны охватывать все участвующие в проекте 52 Обзор управления проектами функциональные подразделения или организации в течение всего жизненного цикла проекта и учитывать всю имеющую отношение к проекту информацию: расписание, стоимость, технические аспекты, риск. Большинство организаций сталкивается с необходимостью одновременного планирования и исполнения нескольких проектов при условии использования общих ресурсов, что приво дит к необходимости создания единой системы планирования и координации всех исполняемых проектов. В главе 5 затрагивается эта важная тема, а некото рые главы части II предлагают ее подробное рассмотрение. Команда проекта Последняя составляющая триады – это создание команды проекта и управление ею для объединения действий всех участников. Проект по определению вклю чает в себя множество разнообразных задач (называемых во многих предмет ных областях “пакетами работ”), выполнение которых требует опыта и затрат времени ряда специалистов. Выполнение этих работ поручается различным людям как из организации, несущей основную ответственность за проект, так и из сторонних компаний. Другие сотрудники отвечают за принятие решений, соответствие проектной деятельности требованиям законодательных/норма тивных актов и процедур, согласование/утверждение документов по определен ным аспектам проекта. Каждый человек, привлекаемый к работе, рассматрива ется как член команды проекта. Наибольшая эффективность управления достигается в случае, когда все участники работают под общим управлением менеджера проекта слаженно, сообща. В главах 6 и 11 подробно рассмотрены различные аспекты проектных команд и командной работы. 1.7 ПРОБЛЕМЫ И ВОЗМОЖНОСТИ, СВЯЗАННЫЕ С INTERNET Чрезвычайно быстрое развитие сети Internet в последние годы создает серьез ные проблемы в различных отраслях промышленности, бизнесе и государствен ных структурах. Опрос, проведенный в 2001 году среди руководителей 506 круп ных компаний (с объемом продаж более 5 млрд. долларов) показал, что управленцы расценивают влияние Internet как вторую по важности проблему в своей деятельности (см. табл. 1.4). Главная задача – определить, в какой из двух ситуаций находится ваше пред приятие, учреждение или организация: • “приспособиться или погибнуть”. Для многих организаций изменения, вызван ные развитием Сети и Internet технологий, на самом деле являются вопро сом жизни или смерти. Компания должна либо претерпеть существенные 53 Проблемы и возможности, связанные с Internet Òàáëèöà 1.4. Ïåðå÷åíü íàèáîëåå çíà÷èìûõ ïðîáëåì 2001 ãîäà, ñîãëàñíî îïðîñó ðóêîâîäèòåëåé 506 çàïàäíûõ êîìïàíèé ñ îáîðîòîì áîëåå 5 ìëðä. äîëëàðîâ. Èñòî÷íèê: PC Magazine Internet Business, June 12, 2001, p. 18 Изменение характера и интенсивности конкуренции 41% Влияние Internet 38% Консолидация отраслей 37% Давление на цены, приводящее к их снижению 33% Нехватка квалифицированных ресурсов 32% преобразования, чтобы успешно конкурировать в новых условиях, либо смириться с тем фактом, что дни ее сочтены; • использовать Internet, чтобы расти и конкурировать. Все те компании, для ко торых проблема Internet не является жизненно важной, оказываются пе ред выбором – использовать для своего развития возможности, предлагае мые Сетью, или не использовать. Однако даже те организации, что сегодня не решают вопрос жизни и смерти, могут столкнуться с ним завтра. Темпы изменений настолько быстры, что невозможно предсказать, какие отрас ли, компании или агентства не останутся затронуты наступлением, кото рое предпринимает Internet. Руководители компаний сталкиваются со специфическими проблемами, свя занными с Internet. Их можно выразить в следующих вопросах: • что нужно сделать для преобразования организации таким образом, что бы она выжила и процветала? • как следует изменить организацию для того, чтобы правильно влиться в новые сообщества электронного бизнеса и участвовать в “возглавляемой потребителем революции” в рамках этой новой экономики? • каким образом компания сможет выстоять в конкурентной борьбе, учиты вая, что большая часть некогда принадлежавшей только ей интеллектуаль ной собственности станет общедоступной благодаря Internet? • каким образом можно обеспечить адекватные меры защиты интеллектуаль ной собственности и интересов организации, вступив в стратегическое парт нерство с компаниями, которые легко могут стать ее прямыми конкурентами? • каким способом поддерживать средства и методы, обеспечивающие широ кое сотрудничество внутри организации, а также между ней и ее стратеги ческими партнерами? • при каких условиях фирма сможет разрабатывать и выпускать новые про дукты/услуги достаточно быстро для того, чтобы она успешно конкуриро вала в новом высокодинамичном окружении? 2 « « » » Программы и проекты У правление проектами включает в себя концептуализацию (формирование концептуального представления), выбор, утверждение, планирование и вы полнение работ, совокупность которых называется проектом. Понятия и систе мы, используемые в управлении проектами, равно как и связанные с ним труд ности, вытекают из самой природы проектов. Поэтому важно, чтобы руководители, менеджеры и специалисты, вовлеченные в программы и проекты, хорошо пони мали их уникальные характеристики и способы их классификации. 2.1 ПРОГРАММЫ, ПРОЕКТЫ И ЗАДАЧИ При использовании терминов “программа”, “проект” и “задача” может возни кать некоторая путаница – иногда они употребляются неопределенно или даже подменяют друг друга (см. [114], где приведен обширный глоссарий, доступный через Internet и включающий термины по управлению проектами, сопровожда емые альтернативными толкованиями из различных источников. В [88, pp. 195– 209] также содержится обширный глоссарий подобного рода). Согласно сложившейся практике, во многих отраслях экономики для выше названных терминов установлены следующие общепринятые значения: Программа – долгосрочное предприятие, которое включает в себя два или бо лее проектов, требующих тесной координации. Проект – комплекс действий (обычно длительностью менее трех лет), состоя щий из взаимосвязанных задач, выполняемых различными функциональными организациями (подразделениями), с четко определенными целями, расписа нием и бюджетом. краткосрочное действие (рассчитанное на период от нескольких не Задача – дель до нескольких месяцев), выполняемое одной функциональной организацией 57 Что такое проект (подразделением); в комбинации с другими задачами может складываться в про ект. Задачи обычно состоят из взаимосвязанных операций, имеющих более ко роткую продолжительность. Не существует универсального соглашения, касающегося использования или определения этих терминов. Понятие “пакет работ”, как правило, используется в литературе по управлению проектами в том же значении, что и “задача”, – обо значает определенный объем работ, к которому могут быть применены операции оценивания, бюджетирования, календарного планирования, отчетности и кон троля времени, стоимости, других ресурсов и результатов (технических и пр.). При разбиении программы или проекта на составные элементы существует тенденция к тому, что каждая из участвующих в проекте организаций начинает применять термин “проект” к исполняемой ею работе, хотя это может привнес ти путаницу (так же, как часто происходит в технической сфере в связи с упо треблением терминов “система”, “подсистема” и т.п.). Возможно, не существует иного способа избежать подобного расхождения, кроме точного наименования каждого проекта и четкого обозначения всех его взаимосвязей. Подход к управлению проектами, представленный в этой книге, применим и к программам, и к проектам, и к задачам. Однако главным образом рассмотре ние будет вестись на уровне проектов и программ. Хотя в книге используется термин “проект”, подразумевается, что все концепции, изложенные здесь, при менимы и к программам. Понимание этих трех ключевых терминов – первый шаг на пути к достиже нию надежного управления программами и проектами. В некоторых организа циях слово “программа” может относиться к деятельности, осуществляемой на постоянной основе (например, “программа долгосрочного обучения”). Такое употребление термина отличается от используемого в данной книге. 2.2 ЧТО ТАКОЕ ПРОЕКТ Всем проектам свойственны определенные основные характеристики. Наибо лее важные из них с точки зрения управления приведены ниже. Проекты – уникальные комплексы действий, имеющие начало и конец Проекты предназначены для получения определенного результата в определен ный момент времени и в рамках установленного бюджета. Они не опираются на функциональную структуру организации. Каждый проект уникален: ни один не является точной копией предыдущих. Проект – это процесс создания определенных результатов Проект можно рассматривать как целостный процесс, необходимый для созда ния нового продукта, нового завода, новой системы или иных определенных заранее результатов. Часто создаваемому продукту уделяется больше внимания, 58 Программы и проекты чем процессу, в результате которого он создается, но и продукт, и процесс его создания, то есть проект, требуют эффективного управления. Следует отметить, что конечный результат не является проектом. К сожалению, в некоторых предметных областях долго продолжают ссылать ся на проект после того, как он был фактически завершен, особенно в случае, когда было спроектировано и возведено какое либо строение. Например, один финансируемый Международным банком (World Bank) проект вылился в проек тирование и сооружение крупнейшей в мире земляной дамбы с электростанци ей на реке Индус (Indus) в местечке Тарбелла (Tarbella) северо западной пригра ничной провинции Пакистана. Некоторые менеджеры и инженеры в Комитете по развитию водоснабжения и энергетики Пакистана (Pakistan Water and Power Development Authority) до сих пор называют это сооружение “проектом Тарбел ла”; более того, при входе все еще висит табличка с этим названием. Подоб ная двусмысленность может также вызвать нечеткое понимание фразы “запуск проекта”, поскольку в терминах управления проектами она означает начало про екта как такового, а в литературе по управлению строительными проектами тер мин “запуск” иногда относится к началу ввода в эксплуатацию и функциониро вания сооружения, являющегося конечным результатом проекта. Фаза ввода в эксплуатацию сооружения – совсем не то же самое, что и начало нового проек та либо новая фаза текущего (подробности вы найдете в главе 11). Жизненный цикл проекта Жизненный цикл проекта имеет определенные начальную и конечную точки, привязанные к временной шкале. Проект в своем естественном развитии про ходит ряд отдельных фаз, показанных в табл. 2.1. Жизненный цикл проекта вклю чает все фазы от момента инициации до момента завершения. Переходы от од ного этапа к другому редко четко определены, за исключением тех случаев, когда они формально разделяются принятием предложения или получением разре шения на продолжение работы. Однако в начале концептуальной фазы часто возникают сложности с точным определением момента, когда работу уже мож но идентифицировать как проект (в терминах управления проектами), особен но если речь идет о разработке нового продукта или новой услуги. Изменения характера проекта Каждая фаза проекта имеет определенные точки начала и завершения, а резуль татом каждой фазы является создание нового промежуточного продукта (резуль тата); при этом продукт (результат) одной фазы служит основным исходным материалом для следующей. На рис. 2.1 показан весь процесс в целом. Чтобы можно было перейти от одной фазы к другой, обычно требуется формальное разрешение, а между фазой определения и фазой проектирования, как прави ло, утверждается основной объем финансирования. Скорость потребления ресурсов в проекте меняется – как правило, возраста ет от одной фазы к другой до тех пор, пока не начнет быстро уменьшаться на 66 Программы и проекты Вопросы управления Методы и системы планирования и управления ресурсами, используемые в функ циональных отделах, обычно неэффективны в применении к проектам. Относительно новые концепции и системы, разработанные для применения в проектах, сами по себе не создают конфликтов и проблем, а скорее выявляют уже существующие различия, конфликты и несовместимость между проектами и функциональной структурой организаций. В такой ситуации основная задача менеджеров высшего звена состоит в том, чтобы эффективно управлять всеми проектами, продолжая не менее эффективно руководить функциональной орга низацией. Для решения этой задачи были разработаны концепции и методики интегрированного управления проектами. 2.3 КАТЕГОРИИ ПРОЕКТОВ В бизнесе, промышленных и государственных организациях существует огром ное многообразие проектов. Правильно классифицировать их внутри организа ции полезно по нескольким причинам. Процесс управления жизненным циклом проекта может значительно варьироваться в зависимости от категории проек тов, при этом наиболее подходящий процесс должен применяться к каждому отдельному проекту. Развивая и непрерывно совершенствуя процесс для каждой категории проектов, менеджеры могут обеспечить некоторую степень стандар тизации в управлении проектами. Существует много способов классификации проектов: по размеру, сложнос ти, географическому расположению, технологии, риску (экономическому, тех нологическому, политическому), характеру конечного продукта или результата, сектору бизнеса или предметной области, политической или экономической при надлежности и по другим признакам. Основные категории проектов со сходными процессами управления В табл. 2.3 перечислены десять категорий проектов, рекомендованных к исполь зованию. Проекты в каждой категории характеризуются очень схожими жиз ненными циклами, а также процедурами и инструментами утверждения, плани рования, бюджетирования, составления расписаний, мониторинга и контроля в течение этих жизненных циклов. В большинстве случаев между процессами управления жизненными циклами проектов в категориях и подкатегориях будут существовать различия, иногда значительные. При необходимости список подка тегорий может быть расширен – как за счет выделения подкатегорий в случае их отсутствия, так и за счет добавления новых к уже имеющимся (см. табл. 2.3). Эти категории не являются взаимоисключающими: во многих проектах при сутствуют элементы двух или более категорий. Например, большинство про ектов коммуникационных систем предусматривает как минимум адаптацию 67 Категории проектов соответствующего программного обеспечения. Проекты капитального строи тельства часто включают в себя информационные системы, и наоборот. В по добных случаях проект, вероятно, следует классифицировать исходя из преоб ладающей категории или, если это оправдано, – из размера, сложности или степени риска, определив его в этом случае как два или более проектов (либо различных категорий) в рамках программы. Òàáëèöà 2.3. Ðåêîìåíäîâàííûå êàòåãîðèè ïðîåêòîâ. Êàòåãîðèè èëè ïîäêàòåãîðèè èìåþò ñõîæèå ôàçû æèçíåííûõ öèêëîâ è óíèêàëüíûå ïðîöåññû óïðàâëåíèÿ ïðîåêòàìè № Категории проектов Примеры 1 Аэрокосмические/оборонные проекты 1.1 Оборонные системы Новая система вооружения; значительная модернизация существующей системы 1.2 Космос Разработка/запуск спутника; модификация космической станции 1.3 Военные операции Вторжение оперативной группы или экспедиционного корпуса 2 Проекты изменения бизнес процессов и организационного развития 2.1 Приобретение/слияние Приобретение конкурирующей компании и ее интеграция в структуру организации 2.2 Совершенствование Значительные улучшения в области процессов управления управления проектами 2.3 Новый бизнес Создание новой компании и начало ее деятельности 2.4 Реструктурирование организаций Слияние подразделений и уменьшение размеров компании 2.5 Судопроизводство Крупный судебный процесс 3 Проекты коммуникационных систем 3.1 Сетевые коммуникационные системы Коммуникационная сеть с использованием СВЧ (микроволн) 3.2 Коммутирующие коммуникационные Беспроводная коммуникационная системы система третьего поколения 4 Проекты событий 4.1 Международные события Летние Олимпийские игры 2004 года; Чемпионат мира 2006 года 4.2 Национальные события Суперкубок США 2005 года; политический съезд демократов и республиканцев 2004 года 69 Категории проектов Òàáëèöà 2.3. Ðåêîìåíäîâàííûå êàòåãîðèè ïðîåêòîâ. Êàòåãîðèè èëè ïîäêàòåãîðèè èìåþò ñõîæèå ôàçû æèçíåííûõ öèêëîâ è óíèêàëüíûå ïðîöåññû óïðàâëåíèÿ ïðîåêòàìè (îêîí÷àíèå) № Категории проектов Примеры 8 Культурно массовые и развлекательные проекты 8.1 Кино Новый фильм (на пленке или в цифровом формате) 8.2 Телевидение Новая серия телефильма 8.3 Спектакли или музыкальные концерты Премьера оперы 9 Разработка продукта или услуги 9.1 Аппаратное обеспечение Настольный компьютер для информационных технологий 9.2 Промышленный продукт/процесс Новая модель экскаватора 9.3 Потребительский продукт/процесс Новая модель автомобиля; новый продукт питания 9.4 Фармацевтический продукт/процесс Новое лекарство, понижающее уровень холестерина в крови 9.5 Услуги в финансовой или иной сфере Новая схема страхования жизни или определения процентов 10 НИОКР проекты 10.1 Проекты, связанные Анализ изменений в озоновом слое с окружающей средой 10.2 Промышленные проекты Способы уменьшения выбросов вредных веществ 10.3 Проекты, связанные Определение культуры, с экономическим развитием наиболее пригодной для выращивания в пустыне Сахара 10.4 Медицина Тестирование нового метода лечения рака молочной железы 10.5 Наука Определение вероятности жизни на Марсе 11 Другие категории Классификация мультипроектных программ по категориям Программы часто содержат проекты, входящие в две или более основных кате горий. Например, программа разработки крупномасштабной системы связи обычно включает проекты в области коммуникаций, капитального строительства, 70 Программы и проекты аэрокосмических разработок и информационных систем. Каждый проект дол жен планироваться и управляться индивидуально, с интеграцией на уровне про граммы; интеграция осуществляется путем связывания различных процессов в точках соответствующих интерфейсных событий. Подробное обсуждение дан ной темы представлено в главах 8 и 13. 2.4 КЛАССИФИКАЦИЯ ПРОЕКТОВ КАЖДОЙ КАТЕГОРИИ В пределах каждой категории проектов крупной организации всегда будет су ществовать множество разнообразных мероприятий. Методы управления, необхо димые для проекта стоимостью несколько миллионов долларов, скажем при соору жении новой фабрики, продумываются более тщательно, чем при строительстве классического гаража для хранения велосипедов, увековеченного Паркинсоном (Parkinson, [80]), несмотря на то что в обоих случаях мы имеем дело с проектами новых предприятий. Процесс управления проектами каждой категории должен обеспечивать гибкий выбор необходимого уровня планирования и контроля – это касается как большого сложного проекта “освоения новых территорий” с высо кой степенью риска, так и малого проекта “изобретения велосипеда”. Объем проекта Объем проекта может быть определен по нескольким показателям. Количество денег и других ограниченных ресурсов (людей, специалистов узкого профиля, производственных мощностей), содержание работ, география – это наиболее материальные и очевидные показатели. Проекты большего размера обычно ха рактеризуются большим риском по всем этим параметрам. Обычно, но не всегда. Сложность проекта Показатель сложности проекта – многообразие его целей и содержания, а так же количество участвующих в нем внутренних подразделений и внешних орга низаций (последнее часто определяет количество требуемых специалистов узкого профиля, источников технологии или финансирования). Проект, требу ющий специальных навыков и других ресурсов, которые могут быть найдены в пределах одного функционального подразделения, обычно считается менее сложным с управленческой точки зрения, чем проект совместного предприя тия, выполняемый двумя отдельными корпорациями. Сложность растет экспо ненциально с увеличением количества участвующих организаций. Пересечение работ по проекту с повседневной деятельностью организации – это обще признанный источник сложностей, особенно для проектов, затрагивающих 71 Классификация проектов каждой категории объекты и структуры, непосредственно участвующие в процессах изготовления, сборки и другой производственной операционной деятельности. Проекты, вы полняемые под контролем одного или нескольких органов государственного ре гулирования, как правило, оказываются сложнее проектов, запускаемых без та кого контроля. Внешний или внутренний заказчик Если проект должен быть выполнен по формальному контракту с внешним за казчиком, это приводит к возникновению ряда управленческих проблем, не характерных для проекта, выполняемого для внутреннего заказчика и для внут ренних нужд. Условия контракта непосредственно влияют на степень риска, связанного с проектом; тщательно сформулированные условия могут заметно снизить уровень риска. Проект, выполняемый для внутреннего заказчика, нуж дается в утверждении и контроле (с помощью нарядов на работы и других внут ренних документов и соглашений), подобно проекту, выполняемому по фор мальному контракту с внешним заказчиком; может не иметь юридических сдерживающих факторов, но при этом также и юридической поддержки. Это увеличивает риск того, что проект не приведет к выполнению поставленных целей. Относительные важность и положение заказчика конкретного проекта порой существенно влияют на присвоенный ему приоритет и организацию управления. Степень участия заказчика в проекте Во многих проектах заказчик должен выполнять значительный объем работ, при нимать важные решения и своевременно предоставлять ключевые результаты, если он хочет, чтобы проект выполнялся в соответствии с расписанием. Задерж ки со стороны заказчика – частая причина отставания проектов от графика и увеличения их стоимости. Крайне важно, чтобы та часть проекта, исполнение которой входит в обязанности заказчика, была тщательно распланирована и со гласована с остальными частями, а также чтобы менеджер проекта со стороны заказчика активно участвовал в совещаниях по обзору состояния проекта, со всей ответственностью подходя к возложенным на него задачам. Процесс управле ния проектом на стороне заказчика должен быть соответствующим образом объ единен с управлением на стороне исполнителя. Уровни риска в проекте Степень риска, связанного с выполняемой работой, варьируется от проекта к проекту и от категории к категории. Некоторые из основных факторов, влия ющих на степень риска, приведены ниже: 72 Программы и проекты • степень новизны проектов данного типа для организации; • объем проекта (как уже обсуждалось выше); • продолжительность и срочность исполнения. Риск повышается, если уста новленный срок исполнения мал и назначена фиксированная дата за вершения – либо, напротив, запланированный срок настолько велик, что повышается вероятность непредсказуемых изменений политической и эко номической ситуации, способной повлиять на проект; • сложность проекта (как обсуждалось выше); • технология: степень новизны и неопределенности технологии, применяе мой в процессе разработки или производства продукта; • наличие внешнего (в проекте, выполняемом по контракту) или внутренне го заказчика (см. выше) и, если таковой имеется, – его авторитет для орга низации; • условия контракта: штрафы, гарантийные обязательства, иностранная ва люта; • контроль со стороны органов государственного регулирования и необхо димость получения тех или иных разрешений; • степень участия заказчика в проекте; • изменчивость рынка; • степень доступности дефицитных ресурсов: опытных высококвалифици рованных работников и специализированных устройств. Большие и малые проекты в пределах категории Целесообразно выделять по крайней мере два класса проектов в категории. На зовем эти проекты и хотя в каждой организации могут исполь большими малыми, зоваться другие, более выразительные названия. Некоторые компании вычле няют несколько классов, обозначая их буквами A, B, C и далее по алфавиту. Различие между классами малых и больших проектов выражено в следующих определениях: • крупные проекты – те, которые в силу большого объема, высокой сложности и/или высокого риска требуют: – назначения из состава высшего руководства; спонсора проекта – назначения менеджера проекта или программы с полной занятостью; – применения в полном объеме процессов управления проектами, уста новленных для больших проектов в данной категории (учитываются все 73 Классификация проектов каждой категории необходимые формы, разрешения, планы, расписания, бюджеты, рыча ги управления, способы контроля, отчеты, частые совещания по обзору состояния проекта, необходимая степень детализации таких совещаний); • – те, которые в силу малого объема, невысокой сложности малые проекты и/или низкого риска допускают: – использование одного менеджера проекта для управления несколькими (двумя и более) проектами одновременно. Следует, однако, отметить, что в таком случае обязанности менеджера проекта не должны поручаться тому или иному функциональному руководителю в качестве дополнитель ной нагрузки, о чем будет дополнительно сказано в главе 4; – использование неполной версии процессов управления, установленных для проектов данной категории: применяются только отдельные основ ные формы, разрешения, планы, расписания, бюджеты, рычаги управ ления, способы контроля, отчеты, проводятся менее частые совещания по обзору состояния проекта с меньшей степенью детализации; – формальное назначение спонсора проекта из состава высшего руководства не производится. Если организация желает прийти к согласованному управлению проектами в масштабе всего предприятия, то планы, расписания и бюджеты всех проектов – больших и малых – должны быть введены в единую информационную систему управления проектами (ИСУП). Это необходимо для того, чтобы потребность в любых ресурсах могла прогнозироваться, а сами ресурсы выделялись на проек ты в соответствии с ней и с текущими приоритетами. Альтернативный вариант – включение в ИСУП предприятия не всех ресурсов, а только наиболее важных и де фицитных (остальные могут распределяться по мере необходимости). Управление множественными проектами – как большими, так и малыми – рас сматривается по ходу части I этой книги, особенно в главах 3 и 8. Не считая этих больших и малых проектов некоторые организации несут ответственность за работы, получившие название Это особен мегапроектов. но крупные проекты, в которых обычно задействовано множество компаний и/или учреждений. Международные предприятия по освоению космического пространства, транспортные и энергетические корпорации – вот лишь немно гие примеры таких мегапроектов. Они могут финансироваться из различных источников: правительственных, частных, банков международного развития; часто являются интернациональными и выходят за рамки государственных гра ниц. Мегапроекты лежат за пределами вышеприведенной классификации про ектов (больших и малых), и чрезвычайно редки случаи, когда одна организа ция одновременно принимается за два или более таких проектов. 74 Программы и проекты 2.5 ЖИЗНЕННЫЕ ЦИКЛЫ ВЫСОКОТЕХНОЛОГИЧНЫХ ПРОЕКТОВ Как уже говорилось в разделе 1.3, для того чтобы максимально использовать все преимущества, предоставляемые современным управлением проектами, каждая компания или организация должна документировать общую картину процесса управления проектами. Это предполагает выделение ряда основных типов или категорий проектов, выполняемых или планируемых в данной организации, а также описание принятых ею философии и методов управления. Однако этот общий процесс не может быть непосредственно применен ко всем существую щим в организации категориям и проектам без должной модификации. Детальный процесс управления жизненными циклами проектов каждой опре деленной категории (или подкатегории, если таковые существуют) должен: • определять жизненный цикл проекта (фазы, подфазы, моменты получения авторизации/принятия решений) и описывать методы, процедуры, фор мы, документы, инструменты, системы и другие способы авторизации, планирования, анализа и уменьшения рисков, бюджетирования, календар ного планирования, мониторинга и контроля всех проектов в данной кате гории; • определять документы и связанные с ними уровни полномочий на ини циацию, на утверждение новых проектов и значительных изменений уже утвержденных проектов; • идентифицировать в проекте ключевые должности, определять круг соот ветствующих обязанностей и полномочий; • устанавливать процедуры переноса неизбежных конфликтов (в результате конкуренции за дефицитные ресурсы, столкновения приоритетов проек тов и т.д.) и нерешенных вопросов на соответствующий уровень для их долж ного разрешения. Детальный процесс управления проектами каждой категории должен также обеспечивать возможность управления проектами разного объема, сложности, степени риска, продолжительности, с разными источниками и способами фи нансирования и удовлетворения запросов различных заказчиков. Важность разработки и документирования процессов жизненного цикла проекта Разработка и документирование процессов жизненного цикла проекта позволяют: • всем людям, занятым в создании, планировании и исполнении проектов, до стичь понимания процессов, которые должны выполняться в ходе работы; 75 Жизненные циклы высокотехнологичных проектов • накапливать передовой опыт для того, чтобы непрерывно совершенство вать жизненные циклы проектов и переносить успешный опыт с одних про ектов на другие; • осуществлять взаимосвязь 1) должностей и обязанностей в проектах и 2) ме тодов и инструментов планирования, оценивания, составления расписаний, мониторинга и контроля с общими процессами управления жизненными циклами проектов. При отсутствии хорошо документированной понятной картины жизненных циклов для каждой категории проектов будет невозможно воспользоваться все ми преимуществами современного систематического управления проектами. Категории высокотехнологичных проектов Среди десяти рекомендованных категорий проектов, перечисленных в табл. 2.3, мы выделим и сфокусируем свое внимание главным образом на следующих че тырех: 1. Проекты коммуникационных систем. 2. Проекты информационных систем. 3. Проекты разработки продуктов и услуг: • промышленных продуктов; • потребительских продуктов; • фармацевтических продуктов; • услуг. 4. Проекты в области НИОКР: • касающиеся окружающей среды; • промышленные; • связанные с экономическим развитием; • медицинские; • научные. И хотя проекты, относящиеся к оставшимся шести категориям из табл. 2.3, часто предполагают очень значительное привлечение высоких технологий, не они являются предметом принципиального рассмотрения в данной книге. Сле дует отметить, что, между тем как концепции и методики, рассмотренные в час ти I, могут быть применимы к любой категории проектов, методики, более под робно рассмотренные и представленные в части II, главным образом относятся к категориям и подкатегориям, которые выделены в вышеприведенном списке курсивом. 76 Программы и проекты Военные/аэрокосмические программы и проекты. Управление проектами этой ка тегории имеет долгую историю. Фактически управление проектами как дис циплина берет свое начало именно в области капитального строительства и во енных/аэрокосмических заказов как в западном, так и в восточном полушарии. Военные и аэрокосмические проекты/программы в большинстве случаев на ходятся на переднем крае высоких технологий. Впрочем, не на них сделан ак цент в данной книге, поскольку их жизненные циклы уникальны, определяются политиками и стандартами выполнения государственных заказов и в большин стве случаев финансируются из государственного бюджета. Ссылки на источ ники, предоставляющие полную и исчерпывающую информацию о выполне нии таких программ и проектов в США, могут быть получены в Колледже по измерению производительности PMI (PMI College of Performance Management – www.pmi.org/collegeinfo). Несмотря на приведенное выше уточнение, львиная доля концепций и мето дик, представленных в книге, применима к большинству военных/аэрокосми ческих программ и проектов на уровне частного подрядчика в большинстве за падных стран. Некоторые описываемые приемы и рассматриваемые примеры базируются именно на таких программах и проектах. Так как искусственные спутники Земли играют в современных системах и информационных системах связи основную роль, многие проекты в этих двух высокотехнологичных категориях финансируются неправительственными ком паниями и учреждениями. Такие высокотехнологичные программы и проекты входят в круг рассмотрения данной книги, а потому методики и приемы, описы ваемые в последующих главах, определенно применимы к ним. Проекты капитального строительства. Подобно военным/аэрокосмическим проектам, категория проектов капитального строительства, включая проекти рование/снабжение/постройку разнообразных сооружений и установку обору дования всех видов, характеризуется долгой историей управления проектами; масса литературы посвящена исключительно этой категории. Хотя многие про екты капитального строительства включают в себя элементы высоких техноло гий, в настоящей книге не делается попытки описать или даже кратко охаракте ризовать те эффективные методы и системы, которые существуют и широко применяются в данной категории проектов, весьма важной. В большинстве организаций имеются установленные и отработанные поли тики, а также процедуры контроля проектов, требующих инвестиций и/или ка питальных фондов. Эти политики и процедуры обеспечивают детальные описа ния различных типов проектов капитального строительства. В общем и целом они включают в себя расходы на приобретение земли и зданий, покупку, изго товление или лизинг оборудования, дополнительные расходы на значительные изменения или модернизацию существующих сооружений. Когда проект капитального строительства неотделим от проекта разработки нового продукта, информационной или коммуникационной системы, научно исследовательских работ или иного проекта (либо является их частью), он 77 Жизненные циклы высокотехнологичных проектов должен управляться как элемент всей программы/проекта. Проекты капиталь ного строительства обычно нуждаются в дополнительном финансовом контро ле, чтобы можно было обеспечить расходование средств в соответствии с поже ланиями руководства и требованиями существующей практики бухгалтерского учета и налогообложения. Проекты международного развития также часто включают в себя и проекты из области высоких технологий, и проекты капитального строительства, однако имеют существенные отличия в своих жизненных циклах и процессах управле ния, а потому тоже не будут подробно обсуждаться на страницах данной книги. Кредитные организации по международному развитию разработали большое количество процедур для таких проектов и достаточно подробно определили их жизненные циклы. Следует также отметить, что эти организации, как прави ло, требуют соблюдения рекомендованных ими методик и приемов при управ лении теми проектами, которые они финансируют. Институт Международного банка (World Bank Institute) представил детальный, состоящий из двенадцати модулей курс обучения по управлению проектами международного развития всех типов. Этот курс, основным автором которого является Роберт Юкер (Robert Youker), отражает более чем двадцатилетний опыт обучения людей из разных уголков земного шара управлению проектами. Курс в электронном формате мо жет приобрести каждый, кто заинтересован в выполнении столь важных проек тов (World Bank Institute, 2002). Разработка и документирование жизненных циклов высокотехнологичных проектов Не представляется возможным или уместным дать такое определение жизнен ного цикла, которое подошло бы практически для всех проектов, относящихся к конкретной категории, а возможно, даже и подкатегории. Наше намерение, напротив, состоит в том, чтобы представить читателю основные концепции жиз ненного цикла и “строительные блоки”, на основе которых может быть сфор мирован жизненный цикл проекта, наиболее приемлемый в условиях данной организации и применимый к конкретной категории/подкатегории, объ ему проекта (большой или малый), продолжительности, сложности и степени риска. Определение фаз жизненного цикла проекта, относящегося к той или иной категории, в общем достаточно четко. Существует соглашение о том, что жиз ненный цикл проекта состоит из следующих фаз (в скобках приведены наибо лее распространенные синонимичные термины): • концепция (инициация, идентификация, выбор); • определение (осуществимость, разработка, демонстрация, разработка про тотипа, квантификация); 78 Программы и проекты • выполнение (реализация, производство, развертывание, проектирование/ сооружение/сдача в эксплуатацию, установка, тестирование); • закрытие (завершение и послепроектное оценивание). Однако эти фазы настолько широки, и их названия настолько обобщенны, что они оказываются малопригодны для документирования жизненного цикла конкретного проекта таким образом, чтобы процесс мог быть широко понима ем, воспроизводим и постоянно совершенствовался. Что действительно необ ходимо, так это определение, быть может, пяти десяти основных фаз для каж дой категории проектов, обычно с подфазами, выделяемыми в рамках каждой основной фазы. В табл. 2.1 показаны шесть общих фаз плюс еще одна стадия “послепроектной деятельности” для различных типов проектов. Фазы 3, 4, 5 в табл. 2.1 являются подфазами одной общей фазы “выполнения”. При разработке и документировании жизненного цикла (или его модели) для проектов данной категории необходимо принимать во внимание и учитывать в работе следующие три параметра: • количество основных фаз и подфаз в каждой фазе, а также определения каждой фазы и подфазы; • какие основные фазы и подфазы будут выполняться строго последователь но, а какие могут перекрываться (и насколько сильное перекрытие допус тимо); • количество и расположение точек принятия решений (типа “выполнять/ отказаться”, “продолжать/приостановить”) в процессе работы. В табл. 2.4 перечислен ряд моделей жизненных циклов со ссылками для неко торых категорий и подкатегорий проектов из табл. 2.3, отражающий результат неполного поиска. Òàáëèöà 2.4. Ìîäåëè æèçíåííûõ öèêëîâ ïðîåêòîâ è ñîîòâåòñòâóþùèå ññûëêè: îáùèå è äëÿ ðàçëè÷íûõ êàòåãîðèé ïðîåêòîâ Категории проектов* Модели жизненных циклов и ссылки Общие модели проектов: все (или многие) Belanger 1998, pp. 62–72. Модели: общая, категории, приведенные ниже водопада, параллельная, эволюционирования. Morris, 1994, pp. 245–248. Модели: стандартная, водопада, циклическая, спиральная * Проекты всех категорий характеризуются сходными фазами жизненных циклов и уникальными процессами управления. 81 Жизненные циклы высокотехнологичных проектов Ступенчато шлюзовой процесс жизненного цикла проекта разработки нового продукта На рис. 2.4 показан общий вид широко используемого жизненного цикла проек та по разработке нового продукта. Замысел Замысел Продвижение новых продуктов на рынок Продвижение новых продуктов на рынок Отбор идей Шлюз Шлюз 1 Вторичное 1 Переход Переход Переход просеивание к разработке к тестированию к запуску идей Стадия 1 Шлюз Стадия 2 Шлюз Стадия 3 Шлюз Стадия 4 Шлюз Стадия 5 Стадия 1 Шлюз Стадия 2 Шлюз Стадия 3 Шлюз Стадия 4 Шлюз Стадия 5 2 3 4 5 2 3 4 5 Проработка Формирование Разработка Тестирование Запуск содержания бизнес плана и проверка состоятельности Работы после запуска Ðèñóíîê 2.4. Îáùåå ïðåäñòàâëåíèå òèïè÷íîãî ñòóïåí÷àòî-øëþçîâîãî ïðîöåññà. Èñòî÷íèê: Cooper, Robert G., Edgert, Scott J., Kleinschmidt, Elko J. Portfolio Management for New Products. – Cambridge, MA, 2001, p. 272. Êîíòàêòíàÿ èíôîðìàöèÿ: www.perseuspublishing.com. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðîâ. Stage-Gate – çàðåãèñòðèðîâàííàÿ ìàðêà êîìïàíèè R. G. Cooper & Associates Consultant, Inc., ÷ëåíà Èíñòèòóòà ðàçðàáîòêè ïðîäóêòîâ (Product Development Institute), – ñì. www.prod-dev.com Жизненные циклы проекта, определение и расписания проекта Все жизненные циклы проекта рассматриваются в привязке к временной шка ле, а их движение обычно отображается слева направо, хотя встречаются ситуа ции, в которых жизненный цикл показан в направлении сверху вниз. Некото рые схемы включают в себя повторяющиеся фрагменты (подфазы), которые могут быть представлены в виде циклических участков или просто изображать ся на временной шкале несколько раз. Одно из исключений – использование спиральной модели для процесса разработки программного обеспечения. Од нако даже наиболее проработанные диаграммы жизненных циклов не достаточ ны для полного определения проекта (см. главу 10) или разработки адекватного главного расписания и вспомогательных расписаний (см. ту же главу). 82 Программы и проекты Тем не менее хорошо определенный жизненный цикл может принести огром ную пользу в систематическом уточнении проекта с использованием иерархи ческой структуры проекта/работ (ИСП/ИСР) – об этом тоже рассказывается в главе 10. Менеджер/планировщик проекта имеет возможность: 1) разработать ИСП/ИСР, поместив основные фазы жизненного цикла на втором уровне структуры (вместе с элементами, образующими надстройку проекта, такими как “управление проектами”); 2) разработать независимую ИСП/ИСР для каждой основной фазы жизненного цикла; 3) применить комбинацию этих двух мето дов. Каждая основная фаза жизненного цикла проекта приводит к совершенно различным результатам, что будет со всей очевидностью подтверждаться по мере разработки ИСП/ИСР каждой фазы. Эти ИСП/ИСР в дальнейшем станут кар касом, на основе которого будет сформировано главное расписание проекта и подчиненные ему расписания (см. главу 10). Жизненные циклы проекта и его окружение Дезонье (Desaulniers) и Андерсон (Anderson) представили убедительную мо дель для адаптации жизненных циклов проекта к его текущему окружению [30]. Хотя эти авторы рассматривают только случаи разработки программного обес печения, данный вопрос может оказаться не менее важным и в отношении не которых проектов по разработке новых продуктов/услуг и исследовательских проектов. Дезонье и Андерсон утверждают следующее: “Характеристики орга низации, степень ее знакомства с используемыми технологиями, вызванный конкуренцией запуск новых проектов – это лишь некоторые из факторов окру жения, варьирующиеся от одного проекта к другому”. Более того, поскольку окружение может оказывать значительное влияние на проект, “...особое вни мание необходимо уделить выбору жизненного цикла разработки, который бу дет воплощен на практике”. Далее авторы описывают различия между прогнозирующими и адаптивными жизненными циклами. “Прогнозирующие жизненные циклы ставят оптимиза цию выше адаптивности… Адаптивные же жизненные циклы учитывают изме нения в процессе разработки и потому с трудом поддаются детальному планиро ванию”. В цитируемой работе перечислены следующие типы жизненных циклов в каждой категории: 1. Прогнозирующие жизненные циклы: • водопад (известен также как “традиционный” или “цикл сверху вниз”): основные операции по разработке программного продукта линейно упо рядочены, каждая фаза обычно завершается до начала следующей, и ни одна не повторяется; • прототипирование: функциональные требования и проектно конструк торские спецификации генерируются одновременно; 83 Окружение проекта • быстрая разработка приложения (Rapid Application Development, RAD): использует эволюционирующий прототип, который не отбрасывается; • инкрементное построение: разбиение большого объема проектно кон структорских работ на ряд меньших составных частей; • спираль: повторение одного и того же набора фаз жизненного цикла, включающего планирование, проектирование, построение и оценива ние – и так до тех пор, пока разработка продукта не будет завершена. 2. Адаптивные жизненные циклы: • адаптивная разработка программного обеспечения (Adaptive Software Development, ASD): определяемые миссией, основанные на компонентах, итеративные циклы, циклы с известной длительностью, определяемые риском, допускающие изменения; • экстремальное программирование (Extreme Programming, XP): работу ведут команды разработчиков, менеджеров и пользователей, программи рование выполняется частями, процесс носит итеративный характер, исходные коды программ принадлежат коллективу; • SCRUM: подобен приведенным выше адаптивным жизненным циклам, выполняется на итеративной основе, итерации носят название сприн тов, продолжаются порядка 30 дней (типовое значение); каждый спринт на выходе должен дать определенный результат – обеспечить некоторую степень функциональности продукта. Крайне высока роль руководства в течение всего жизненного цикла. Разработка и документирование модели жизненного цикла для каждой кате гории или подкатегории проектов должны отражать важные характеристики окружения проекта. 2.6 ОКРУЖЕНИЕ ПРОЕКТА Каждый проект нужно рассматривать, а также управлять им, учитывая окруже ние, в котором он существует. То, что хорошо и эффективно работает в одном проекте и в определенном окружении, может оказаться неэффективным в дру гом проекте и другом окружении. Многие проекты сталкиваются с трудностями и теряют ожидаемую эффективность из за того, что их цели, организационное построение и методы управления несовместимы или конфликтуют с ключевы ми элементами окружения. Успех проекта зачастую определяется не столько логическим или эффектив ным распределением ролей, обязанностей и ресурсов, сколько созданием наи более работоспособной структуры связей различных внутренних частей проек та с внешними его участниками. В дополнение к факторам, рассмотренным выше применительно к проектам разработки программного обеспечения, к внешним 84 Программы и проекты участникам можно причислить местные, региональные и национальные госу дарственные организации, поставщиков продуктов и услуг и пользователей ре зультатов проекта. Но наиболее важны в этом ряду лица или организации, кото рые получают от проекта максимальную выгоду или прибыль, и те, на которых он влияет наиболее значительным образом, то есть бенефициары проекта. Все эти стороны часто называются “заинтересованными сторонами” проекта в боль шинстве книг по управлению проектами. Создание такой работоспособной струк туры связей особенно важно при выполнении проектов международного разви тия, предназначенных для того, чтобы поднять уровень жизни огромных масс людей. Для менеджера проекта важно, во первых, понимать окружение проекта и, во вторых, обеспечивать его тесную связь с ключевыми действующими лицами и факторами в окружении таким образом, чтобы достичь максимального успе ха. Наконец, необходимо предвидеть возможные изменения (различного рода и величины) в окружении проекта за время работы над ним и в результате его выполнения, а также обеспечить его достаточно гибкими методами управления для адаптации к этим изменениям. Помимо адаптации жизненного цикла проекта к окружению (каковая рассмат ривалась выше) существуют другие важные методы идентификации ключевых действующих лиц и факторов окружения, которые предполагают последующее построение структуры связей проекта с его окружением. Обзор окружения проекта Не все элементы в окружении проекта являются решающими для его успеха. Систематический обзор окружения для выявления ключевых действующих лиц и факторов – важная функция менеджера и всей команды проекта. Такой обзор может выполняться в различной форме: от случайного наблюдения до целена правленной запланированной и высокоструктурированной инспекции. На рис. 2.5 показан один из эффективных способов выполнения подобного обзора. При использовании этого подхода сначала определяется достаточно большое число потенциально наиболее значимых субъектов и факторов, действующих в окружении проекта; они заносятся в определенный сектор или кольцо. Затем, обычно по согласованию с командой проекта, с помощью квадратного или оваль ного оформления (либо иного набора символов) выделяются наиболее критич ные из них. Под действующим лицом понимается личность, группа, институт, орга низация или учреждение – в широком смысле субъект, способный или не способный выполнить какое либо действие и тем самым повлиять на проект. Факторы – это такие элементы, которые, хотя и не могут совершать действий, оказывают огромное влияние на проект самим своим существованием. К ним относятся положения, законы, постановления, традиции, тенденции, физичес кие или экономические условия. 85 Окружение проекта В каждом секторе ИН Е определяются элементы ФР КИ ПОДДАЮЩИЕСЯ ОЦЕНКЕ ЕС АС окружения, имеющие Ч ТР ЗИ непосредственное УК Температурный И ТУ Железнодорожные отношение к проекту, Ф диапазон РН и авиационные и обводятся кольцом Ы Испарения пути сообщения Е Вероятность возмущений Благосостояние (здоровье) в регионе Земля: наклон, ПОДДАЮЩИЕСЯ ВЛИЯНИЮ геология, Выпадение Образование Дороги почва осадков в регионе Местоположения Эрозия почвы, основных рынков Международная дренажная система Электроснабжение связанных Применимые Водоснабжение власти Основные Наличие УПРАВЛЯЕМЫЕ Прочие Политика насекомых факторы и связанные правительственных, Исследования ЮРИДИЧЕСКИЕ органов организации организации Насекомые Местные в дороги специалисты проекта ТЕХНОЛОГИЧЕСКИЕ других проекты программы технологические система Общественные Исследования Исследования, местных отношения с связанные с законы проектом И.К.С. организаций ними спонсоры ПРОЕКТ в Общественные Исполняющие университетов Субсидии Налоговая / Правительственные в премущества ЕСКИЕ государственных, и данной политика национальных, или дисциплины Размещение Ч ИТИ займов области областях по проекту торговая Л Местные ПО Этнические банки группы Поставщики Религиозные группы Рабочая сила Уровень Отношение Профсоюзы к инвестиционному процентных Фирмы риску ставок Подрядчики Стимулирование Демографические Потребители Цены на энергию изменения Прочие ключевые результатов (энергоносители) проекта факторы Национальные банки Женщины и работа Факторы общеэкономического Е О КИ С Ц характера ЕС ИА Ключевые социальные ИЧ ЛЬ Уровень инфляции факторы НЫ ОМ Устойчивость местной Н Е, КО КУ валюты на мировом /Э ЛЬ рынке ЫЕ ТУ РН ОВ ЫЕ АНС ФИН Ключевые действующие лица: Ключевые факторы: (для определенного проекта) И.К.С. – исследовательская команда спонсора Ðèñóíîê 2.5. Ìåòîä äîêóìåíòèðîâàíèÿ îáçîðà îêðóæåíèÿ. Àäàïòèðîâàííûé ôðàãìåíò ñòàòüè Burrnett, Nikolas R., Youker Robert. Analyzing the Project Environment // CN-848, July 1980. – The World Bank Institute Course Note Series, Washington, DC: The World Bank Institute Связи между проектом и его окружением Для того чтобы проект был успешным, он должен находиться во взаимосвязи со всем своим окружением. Если не считать показ факторов окружения в модели жизненного цикла, это может быть достигнуто путем организации специальных 86 Программы и проекты связей, которые отражают ключевые действующие субъекты и факторы, опре деляемые путем обзора окружения. Такие связи реализуются через организаци онную структуру и процесс управления. Ниже приводится ряд примеров организационных связей: • организация формальных комитетов по управлению проектами; • включение основных участников проекта в совет директоров, группу со ветников по проекту или в организацию спонсор; • обеспечение участия менеджера проекта или членов команды в советах либо комитетах организаций – ключевых участников проекта; • объединение команды проекта и ведущих действующих лиц из сторонних организаций; • формирование целевых комитетов для координации и планирования с учас тием ключевых действующих лиц; • введение должности менеджера по взаимодействию, обязанного обеспечи вать связь с ключевыми действующими лицами, или возложение этой функ ции на менеджера проекта. Далее приводятся некоторые примеры связей процесса управления. Действующие лица: • пригласить ключевых действующих лиц для участия в совещаниях по про екту, особенно при разработке планов, которые их затрагивают; • пригласить ключевых действующих лиц посетить проектный офис и объек ты выполнения работ, познакомить их с командой и руководителями про екта; • периодически снабжать их копиями соответствующих отчетов по проекту. Факторы: • убедиться, что определенные ключевые факторы учтены при отборе про ектов и расстановке их приоритетов, разработке модели жизненного цик ла проекта, планов проекта, бюджета, расписаний и т.д.; • установить такую систему отчетности, которая позволит отражать измене ния ключевых факторов в планах проекта; • сформировать системы мониторинга предложений и сообщать менеджеру проекта о значительных изменениях. В табл. 2.5 представлены дополнительные примеры того, как проект может быть связан со своим окружением в рамках семи общих основных фаз или задач по управлению проектами. 88 Программы и проекты Динамика окружения проекта Точно так же, как по мере продвижения от фазы к фазе модифицируется сам про ект, изменяется и его окружение. Спонсоры и менеджеры проекта должны пери одически контролировать основные элементы окружения проекта и подтверж дать актуальность действующих лиц и факторов, имеющих к нему отношение. Хотя данный тип исследования окружения был разработан для проектов меж дународного развития в развивающихся странах, он способен заметно повысить вероятность успеха и в сфере высоких технологий – особенно в тех проектах, которые сложным образом взаимодействуют с внешними органами государствен ного регулирования и с местным населением (например, в проектах восстанов ления окружающей среды или демонтажа ядерных электростанций). Т РЕБОВАНИЯ ВЫСШЕГО РУКОВОДСТВА Программы и проекты При обсуждении вопросов о программах и проектах исполнительный ди ректор должен требовать, чтобы были выполнены следующие задачи: • определены соответствующие категории проектов, включающие в себя все программы и проекты в организации; • для каждой категории и подкатегории проектов подробно разработан процесс управления, а также обеспечена возможность выбора альтер нативных вариантов процессов на случай необходимости; • в определении процесса управления проектами каждой категории пре дусмотрена возможность упрощения требований к процессам для ма лых проектов при сохранении полного соответствия нуждам корпо ративной системы управления ресурсами предприятия; • для всех больших проектов выполнен систематический обзор окруже ния; установлена структура связей этих проектов с ключевыми действу ющими лицами и факторами окружения, которые способны оказать значительное влияние на ход работы. 3 « « » » Улучшение возможностей управления проектами в компании П режде чем искать пути улучшения возможностей организации по управ лению проектами, обсудим преимущества и стоимость реализации инте грального систематического подхода к управлению проектами, своды знаний, сформировавшиеся в этой области, и модели зрелости организаций, использу ющих управление проектами. Перечисленных тем достаточно, чтобы перейти от них к рассмотрению раз личных путей повышения эффективности управления проектами организации. 3.1 ПРЕИМУЩЕСТВА И СТОИМОСТЬ СИСТЕМАТИЗИРОВАННОГО УПРАВЛЕНИЯ ПРОЕКТАМИ Преимущества современного управления проектами Формализованный систематический подход к управлению проектами, представ ленный в настоящей книге, имеет ряд преимуществ и обеспечивает ряд выгод, если сравнивать его с альтернативными подходами, в основе которых лежит ис пользование функциональных руководителей для неформальной координации операций проекта, а также процедур и методов, разработанных для управления функ циональными подразделениями. Все более широкое использование описываемо го здесь подхода обусловлено тем, что он значительно увеличивает вероятность успешного завершения каждого проекта, то есть достижения им поставленной 90 Улучшение возможностей управления проектами в компании стратегической цели, а именно получения определенного результата в срок и в рамках выделенного бюджета. Это, в свою очередь, непосредственно вли яет на успех всей организации. Ниже перечислены основные методы повышения вероятности успеха: • проекты отбираются и утверждаются только в том случае, когда они явно поддерживают стратегии развития организации, когда их риски тщатель но оценены и поняты, когда им присвоены приоритеты и, как следствие, они поставлены на то или иное место в ряду проектов организации, – нако нец, когда в них выделены ключевые ресурсы (люди, средства и производ ственные мощности); • принимаемые по проекту обязательства отражают достижимые техничес кие, финансовые и временные цели; • обязанности по портфелям, программам и проектам четко определяются и выполняются должным образом; • каждый проект планируется, привязывается к календарной шкале и кон тролируется для того, чтобы принятые обязательства выполнялись; • команда проекта работает сообща, в духе приверженности целям, планам и расписаниям проекта. Преимущества, получаемые за счет утверждения должностей с общей ответствен ностью за проект и назначения на них людей (в том числе менеджера проекта в каждый большой проект), приводятся ниже: • ответственность за общие результаты проекта возлагается на одного чело века (менеджера проекта) при четком определении частных обязанностей и ответственности остальных ключевых лиц проекта как на исполнитель ном, так и на функциональном уровне; • обеспечивается принятие таких решений, которые будут наилучшим обра зом соответствовать интересам проекта и организации в целом, а не того или иного функционального подразделения; • осуществляется более эффективная координация всех функциональных подразделений, занятых в проекте; • правильно используются методы, системы и инструменты интегрального планирования и контроля, а также информация, получаемая с их помощью. Преимущества, которые достигаются за счет внедрения объединяющего и про для всех проектов, приведены ниже: гнозирующего планирования и контроля • обеспечивается планирование и выполнение всех операций для каждой функциональной области в соответствии с интересами проекта и при пол ной координации со всеми остальными проектами; 91 Преимущества и стоимость систематизированного управления проектами • эффект от выделения одного проекта в ряду других отслеживается и извес тен заранее (это касается, например, распределения критических ресурсов); • заблаговременно выявляются проблемы, которые могут поставить под угро зу успешное завершение проекта. Следовательно, возникает достаточный запас времени для корректирующего воздействия, направленного на предот вращение или разрешение проблемы. Преимущества, получаемые за счет реализации эффективной командной рабо ты (особенно в сочетании с двумя другими основополагающими концепциями управления проектами – назначением должностей с общей ответственностью за проект и прогнозирующим планированием/контролем), приводятся ниже: • представители необходимых специальных дисциплин из различных орга низаций работают в группе – тем самым обеспечивается их творческое вза имодействие на благо проекта; • у членов команды формируется глубокое понимание проекта и его целей, возникает приверженность тому и другому; • планы, расписания и бюджеты, необходимые для исполнения проекта, раз рабатываются совместными усилиями, благодаря чему достигается всеоб щее согласие с этими положениями, истинная приверженность им; • каждый проект характеризуется выдающейся производительностью команды. Цели и преимущества управления портфелями проектов Ниже перечислены три основные цели управления портфелями проектов: • максимизация важности. Основная задача большинства фирм – распределить ресурсы таким образом, чтобы максимизировать ценность портфеля про ектов в соответствии с главной целью компании (каковой может быть, на пример, долговременная рентабельность, возврат на инвестиции (ROI), по вышение вероятности успеха); • достижение баланса (равновесия). Имеется в виду построение сбалансирован ного портфеля – достижение желаемого соотношения проектов по ряду па раметров; • достижение стратегического соответствия. Главная идея заключается в том, чтобы вне зависимости от остальных соображений окончательный порт фель проектов характеризовался стратегическим соответствием, то есть фактически отражал бизнес стратегию организации [24, pp. 26–27]. Кроме преимуществ, которые приносит систематическое управление проек тами, организация, переходящая к управлению портфелями, получает и допол нительные выгоды. 92 Улучшение возможностей управления проектами в компании “Выгоды управления портфелями проектов поистине огромны. После вве дения нового процесса управления портфелями высшее руководство компании SmithKline Beecham почувствовало, что ценность нового портфеля повысилась на 30% по сравнению со старым без каких либо дополнительных инвестиций. Более того, при совершении дополнительных инвестиций прибыль на допол нительно инвестированный капитал возросла по меньшей мере втрое: от 5:1 до 15:1. Эти достижения в конце концов подвигли компанию к увеличению доли расходов на разработку (продуктов и услуг) более чем на 50%” (Bridges, 1999, p. 53; цитата из Sharpe, 1998, p. 10). Стоимость управления проектами Источники расходов, непосредственно соотносимые с применением, постоян ным развитием и совершенствованием управления проектами, перечислены в табл. 3.1. Как отмечается в таблице, многие затраты, связанные с управлением проектами, обычно включаются в бюджет прямых расходов каждого проекта. Затраты же, связанные с управлением портфелями проектов и офисом управле ния проектами (Project Management Office – PMO), как правило, относят к на кладным и/или общим и административным расходам организации. Величина общих расходов на управление проектами варьируется весьма значи тельно, поскольку зависит от типа, размера и количества проектов, а также от уров ня зрелости организации в области управления проектами. Иббс (Ibbs) и Квок (Kwak) [48, p. 20] сообщают, что в результате опроса представителей двадцати организа ций было выяснено: “80% компаний тратят менее 10% от общей стоимости проек та на управление им”. Значения расходов, встречающиеся в отчете, находятся в диапазоне от 0,3% до 15% от общей стоимости проекта, причем львиную долю этих трат составляют зарплаты и иные расходы на содержание сотрудников, осу ществляющих управление. Лицензирование программного обеспечения для управ ления проектами и иных целей, консалтинг и обучение сотрудников управлению проектами также, как правило, дают высокий процент от общих затрат. Далее Иббс и Квок формулируют организационные и финансовые преиму щества внедрения инструментов, процессов и методов управления проектами [48, p. 59]. Авторы рассматривают возврат на инвестиции в управление проек тами и предлагают инструмент оценки прибыли, которая может быть получена за счет повышения зрелости компании в области управления проектами. Измерение ROI управления проектами Натсон (Knutson) [52] описывает удобный подход к измерению ROI управления проектами, предлагая использовать следующие четыре измерительные базы: • измерительная база 1 – понимание и приятие. Каков уровень понимания и при ятия управления проектами в организации? Преимущества Òàáëèöà 3.1. Èñòî÷íèêè ðàñõîäîâ íà ïðèìåíåíèå è ðàçâèòèå óïðàâëåíèÿ ïðîåêòàìè Сотрудники Приобретение Планирование, Поездки, обучение, (зарплаты + и поддержка компьютерные консультанты накладные расходы) программного вычисления, связь: и стоимость обеспечения компьютеры управления и поставщики услуг проектами Internet (Internet Service Provider – ISP) систематизированного Управление Группа управления Поддержка Поддержка Минимальные дорожные портфелем проектов портфелем. осуществляется осуществляется расходы. При первой (см. главы 1, 4, 8) Вспомогательный офисом управления офисом управления реализации могут персонал (при проектами проектами понадобиться услуги необходимости) консультанта Офис управления Директор офиса Приобретение Заказ Обучение для постоянного проектами – управления и поддержание и администрирование совершенствования навыков. см. главы 4, 7 проектами. работоспособности Web сайта в сетях Чтобы офис начал работать, управления Вспомогательный программного Internet и intranet. необходим консультант персонал обеспечения Поддержка управления управления проектами для проектами. всей организации Приобретение проектами компьютеров 93 95 Преимущества и стоимость систематизированного управления проектами • измерительная база 2 – применение. Насколько часто и как точно применяют ся технические и социологические компоненты управления проектами в организации? • Какие результаты в области бизнеса измерительная база 3 – влияние на бизнес. были получены благодаря управлению проектами? • измерительная база 4 – возврат на инвестиции (ROI). Каково вычисленное зна чение ROI для прямых вложений в управление проектами организации? Натсон утверждает: Для того чтобы попытаться измерить степень успешности управления проектами, а не самих проектов, необходимо сфокусировать внимание на таких аспектах управления проектами, как методологии, автоматизированная поддержка управления, организа ционная структура, создание и распространение информации и т.д. В настоящей рабо те акцент делается не только на использование методов определения успеха отдельного проекта, но и – что более важно – на то, как эти методики могут применяться к различ ным аспектам, составляющим деловую и культурную основу дисциплины управления проектами. Далее автор представляет методики оценивания и измерения результатов управления проектами относительно каждой измерительной базы и перечисля ет по меньшей мере шесть возможных критериев, по которым может быть оце нено управление проектами. Некоторые из этих критериев подобны критериям моделей зрелости управления проектами, рассматриваемых ниже в этой главе. Применение такого подхода в организации позволяет разумно и обоснован но вычислить возврат на инвестиции в современное управление проектами. Ценность управления проектами: за пределами ROI По мнению Кроуфорда (Crawford) и Пеннипеккера (Pennypacker), одно только вычисление ROI управления проектами нельзя признать достаточным. Более того, эти авторы утверждают, что истинная ценность управления проектами ле жит в сфере неосязаемого, и выступают за использование подхода, основанно го на сбалансированной системе оценок. Они опираются на результаты опроса 100 руководителей проектов высшего звена, который был проведен в 2001 году компанией Center for Business Practices – исследовательским отделением фирмы PM Solutions. 94% опрошенных ощущали, что “внедрение управления проекта ми увеличило стоимость их организаций”. Согласно отчетам, опрошенные орга низации сообщают о значительных улучшениях, последовавших за внедрением управления проектами, как то: улучшение исполнения проектов/процессов на 50%, увеличение удовлетворения заказчиков на 36%, улучшение финансово го исполнения на 54% и общее повышение удовлетворения служащих на 30%. “Опрос показал, что большая часть компаний возлагает надежды на комплекс скоординированных мероприятий по улучшению процессов управления проек тами, а не просто на одно или два” [28]. 96 Улучшение возможностей управления проектами в компании 3.2 ФОРМАЛИЗОВАННЫЕ СВОДЫ ЗНАНИЙ В УПРАВЛЕНИИ ПРОЕКТАМИ Поскольку управление проектами долгие годы развивалось в особую специаль ность, за это время несколько раз предпринимались объединенные усилия по документированию и описанию свода знаний для нее. Две наиболее известные версии таких сводов были разработаны и опубликованы Институтом управле ния проектами (Project Management Institute, PMI: the PMBOK Guide, 2000) в Со единенных Штатах и Ассоциацией управления проектами (Association of Project Management, APM, 2000) в Великобритании. Использование PMBOK Guide (Project Management Body Of Knowledge – Свод знаний по управлению про ектами) в Соединенных Штатах в качестве национального стандарта (ANSI, PMI 99 001 200) было одобрено Американским национальным институтом стандартизации (American National Standards Institute, ANSI). Вокруг этих двух сводов знаний ведутся непрекращающиеся дебаты, и специалисты предпри нимают попытки усовершенствовать имеющийся стандарт [68, p. 21]. Напри мер, Варгас (Vargas) предлагает реструктуризацию PMBOK Guide и сообщает о 20 процентном увеличении общего балла, получаемого на экзаменах студен тами, которые проходили обучение по реструктурированному PMBOK Guide (в сравнении с результатами, наблюдаемыми после обучения по традиционному варианту). С сайта www.aec.com.br/newpmbok можно загрузить файл в форма те Adobe Acrobat (.pdf), содержащий все 39 процессов, которые определяются традиционной версией PMBOK Guide, но в той очередности, какая предлага ется Варгасом. PMBOK Guide идентифицирует и детально описывает 39 процессов управле ния проектами, составляющих пять “групп процессов” (process groups) и восемь “областей знаний” (knowledge areas) по управлению проектами. В табл. 3.2 пред ставлены названия этих групп, процессов и областей знаний, а также их взаимо отношения друг с другом. Этот список не претендует на исключительность. Его цель в том, чтобы показать, как перекрываются группы процессов и области зна ний по управлению проектами. Общие соотношения пяти групп процессов, а также их типичные относитель ные уровни активности в течение жизненного цикла проекта показаны на рис. 3.1. В табл. 3.3 приведена структура древа знаний от APM (APM Body of Knowledge). Моррис (Morris) описывает недавние усилия по исправлению ситуации, в кото рой сосуществуют две фундаментально различные модели “сводов знаний” по управлению проектами, заявляя, что такое положение дел “свидетельствует об интеллектуальной и профессиональной несостоятельности или, в лучшем слу чае, нуждается в срочном пересмотре и исправлении” [68, p. 22]. Группа из 33 экспертов, представителей нескольких стран, приступила к разработке гло бального свода знаний по управлению проектами в 1999 году. Основной резуль тат этой попытки на сегодняшний момент – признание чрезвычайных труднос тей, лежащих на пути разработки такого глобального стандарта, который мог Таблица 3.2. Карта распределения процессов управления проектами по группам процессов и областям знаний в соответствии со стандартом PMBOK Guide. Источник: PMBOK Guide 2000, адаптированный вариант Fig. 3.9 Формализованные Группы Инициация Планирование Исполнение Контроль Завершение процессов. Область знаний Управление Инициация Разработка плана проекта Исполнение Контроль интеграцией плана проекта общих проекта изменений Управление Планирование целей и содержания. Уточнение целей своды целями Определение целей и содержания и содержания. и содержанием Контроль знаний проекта изменений целей и содержания Управление Определение работ. Контроль в управлении временем Выстраивание последовательности расписания проекта работ. Оценивание длительности работ. Разработка расписания Управление Планирование ресурсов. Контроль проектами стоимостью Оценивание стоимости. стоимости проекта Бюджетирование Управление Планирование качества Обеспечение Контроль качеством качества качества 97 100 Улучшение возможностей управления проектами в компании Òàáëèöà 3.3. Ñòðóêòóðà APM Body of Knowledge – ñâîäà çíàíèé ïî óïðàâëåíèþ ïðîåêòàìè Áðèòàíñêîé Àññîöèàöèè óïðàâëåíèÿ ïðîåêòàìè. Èñòî÷íèê: Morris, Peter W. G. Updating the Project Management Bodies of Knowledge // Project Management Journal, 32, 3 (September 2001), p. 23 (îêîí÷àíèå) Проект Организация Методики Общее и люди и процедуры руководство Системы Мобилизация и процедуры Закрытие Послепроектное оценивание бы быть применен всеми, кто имеет отношение к управлению проектами, и во всех ситуациях. В. Либерзон заявляет: “Мы переработали принятые стандарты управления проектами (PMBOK Guide) для использования в России…” [59]: была поставле на цель отразить обширный опыт управления проектами в этой высокоиндуст риализованной стране как в годы существования СССР, так и в последующие. Либерзон предлагает добавить к пяти группам процессов, охватываемым PMBOK Guide, шестую – процессы анализа – чтобы подчеркнуть важность этой деятельности, а также сделать дополнительный акцент на управление ресурса ми, как это принято в управлении российскими проектами. Данная книга не ставит задачей охватить все темы, перечисленные в любом из упомянутых “сводов знаний”. Однако здесь обсуждаются те темы, которым, как показала практика, не хватает более широкого понимания, сложившегося у авто ра на основе личного опыта управления проектами и консультирования клиентов в различных промышленных и государственных сферах во многих странах. 3.3 МОДЕЛИ ЗРЕЛОСТИ УПРАВЛЕНИЯ ПРОЕКТАМИ В последние годы отмечается все более широкое использование моделей зрелос ти для оценки фактического положения организации по сравнению с ее потен циальными возможностями и достижениями других компаний в конкретных ас пектах управления. Совершенствование управления проектами в организации обычно предполагает продвижение “вверх по лестнице”, определяемой той мо делью зрелости, которая была выбрана как наиболее удовлетворяющая нуждам фирмы. В то же время такой процесс предполагает исследование успехов, до стигнутых в частных областях управления проектами, и внесение улучшений там, 101 Модели зрелости управления проектами где существует максимальная отдача, наряду с рассмотрением общей картины применяемых принципов и методов управления проектами. Концепция модели зрелости не нова, несмотря на то, что рост популярности таких моделей отмечен именно в последние годы. Наиболее известная из них – модель зрелости возможностей (Capability Maturity Model, CMM), разработан ная Институтом программного инжиниринга (Software Engineering Institute, SEI) и впервые увидевшая свет в 1987 году. Это была первая модель, созданная для измерения зрелости процессов разработки программного обеспечения (см. рис. 3.2). CMM стала стандартом для измерения эффективности процессов в от расли разработки программного обеспечения, обычно быстро перенимающей стандарты и использующей их, а ее структура неоднократно применялась для построения множества других моделей зрелости, в том числе модели зрелости управления проектами (Project Management Maturity Model, PMMM). Следует, однако, отметить, что в управлении проектами такие стандарты до сих пор не приживались, и будущее какого бы то ни было стандарта в этой области весьма неясно [91]. Процессы Процессы оптимизации оптимизации (5) (5) Процесс непрерывного улучшения Управляемые Управляемые процессы процессы (4) (4) Предсказуемый процесс Определенные Определенные процессы процессы (3) (3) Стандартный целостный непротиворечивый процесс Повторяющиеся Повторяющиеся процессы процессы (2) (2) Упорядоченный процесс Начальные Начальные процессы процессы (1) (1) Ðèñóíîê 3.2. Ìîäåëü çðåëîñòè ïðîöåññîâ ðàçðàáîòêè ïðîãðàììíîãî îáåñïå÷åíèÿ, ðàçðàáîòàííàÿ Èíñòèòóòîì ïðîãðàììíîãî èíæèíèðèíãà 102 Улучшение возможностей управления проектами в компании Два примера моделей зрелости управления проектами Компания PM Solutions, Inc. разработала подробную модель зрелости с восемью уровнями, которые “могут быть использованы при оценивании зрелости управ ления проектами в масштабах всей вашей организации, всего предприятия, – иными словами, при оценивании вашей культуры управления проектами…” [29]. Краткое описание каждого уровня модели, предложенной компанией PM Solutions, приводится в табл. 3.4. Модель зрелости процессов управления проектами Беркли “Пятиступенчатая модель зрелости процессов управления проектами Беркли используется для установления существующего уровня зрелости организации в области управления проектами. Эта модель построена в виде ряда ступеней, отражающих эволюцию процессов управления проектами в организации. Мо дель охватывает диапазон от функциональной структуры с функциональными подходами до проектно ориентированной, предполагающей непрерывное совер шенствование управления проектами. Текущее положение организации на “лест нице” отражает ее положение относительно других компаний, ведущих работу в той же предметной области или выбранных иным способом” [49]. Пять ступеней модели зрелости Беркли перечислены ниже: 1. Уровень 1, “бессистемный”: формальные процедуры или планы исполнения проекта отсутствуют. 2. Уровень 2, “плановый”: для управления проектом используются неформаль ные и нецелостные процессы. 3. управление проектами, осуществля Уровень 3, “управление на уровне проекта”: емое на систематической основе с использованием систем планирования и контроля, применяется к отдельным проектам. 4. Уровень 4, “управление на корпоративном уровне”: процессы управления проек тами носят формальный характер, однако документирование информации и процессов остается неформальным. 5. Уровень 5, “совершенствование”: ключевая характеристика компаний, находя щихся на этом уровне, состоит в том, что они постоянно улучшают свои процессы и подходы к управлению проектами [49]. Программа PMI по разработке модели зрелости управления проектами организации Начиная с 1998 года (см. www.pmi.org/opm3) около двухсот добровольцев рабо тают над созданием организационной модели зрелости управления проектами (Organizational Project Management Maturity Model, OPM3), которая могла бы Òàáëèöà 3.4. Îïèñàíèå óðîâíåé ìîäåëè çðåëîñòè óïðàâëåíèÿ ïðîåêòàìè êîìïàíèè PM Solutions. Èñòî÷íèê: Crawford, J. Kent, Pennypacker, James S. The Value of Project Management: Why Every Twenty-First Century Company Must Have an Effective Project Management Culture / Proceedings of the PMI 2000 Seminars & Symposium. – Houston, TX, September 7–16, 2000, Newton Square, PA: Project Management Institute Уровень модели зрелости управления проектами Модели Уровень I Уровень II Уровень III Уровень IV Уровень V Уровень VI Уровень VII Уровень VIII Зрелость управления проектами Базовые процессы Расширенные и стандартизованные процессы Оптимальные процессы зрелости Неосведом Начальные Базовые Повторя Передовые Хорошо Управляемые Процессы ленность процессы процессы ющиеся процессы определен процессы оптимизации процессы ные процессы управления Описание каждого уровня Ничего Процедуры, Базовые Большая Все процессы Процессы Информация, Непрерывное применяемые процедуры. часть стандар стандарти в рамках получаемая совершен от случая Информация тизованных зованы проекта в ходе ствование к случаю, на уровне процессов и применя интегри управления проектами бессистемно. общих применяется ются ко всем рованы проектами, Частичная сведений. к большим проектам. с корпора используется осведом Ориентация значимым Ориентация тивными. для поддер ленность на проекты проектам. на программы Ориентация жания Информация на органи стратегичес детализиро зацию ких решений ванная. Ориентация на проекты 103 104 Улучшение возможностей управления проектами в компании использоваться как стандарт PMI. “К сожалению, не достигнуто согласие не толь ко насчет содержания модели зрелости управления проектами, но даже и от носительно принципов, на основе которых можно было бы разработать такой стандарт. В настоящее время нужды рынка обслуживаются приблизительно 30 моделями, и все время появляются новые. Появляются книги на эту тему (на пример, Kerzner, 2001; Knutson, 2001)” [21]. “Проект модели, основывающийся на опросе более чем 30000 профессионалов в настоящее время, можно ска зать, завершен. Он включает 180 наилучших методов, а также более 2400 раз личных показателей, результатов и ключевых индикаторов хода процессов). Целевая дата предоставления модели в PMI для публикации – июнь 2003 го да” [94]. 3.4 РЕКОМЕНДУЕМЫЙ ПОДХОД К УЛУЧШЕНИЮ ПРОЦЕССОВ УПРАВЛЕНИЯ ПРОЕКТАМИ Рекомендуемый подход к улучшению процессов управления проектами предпо лагает, что необходимо выполнить следующие действия: • идентифицировать симптомы неэффективного управления проектами; • соотнести симптомы с вероятными причинами, используя для этого 1) дан ную книгу и другую литературу, 2) аудит хода исполнения выполняемых в данное время проектов, 3) послепроектный анализ уже завершенных про ектов; • идентифицировать и проранжировать возможности, благоприятствующие улучшению; • определить программу улучшений для исправления возможных причин не эффективного управления; • выполнить программу улучшений, оценить результаты, искать дополнитель ные пути совершенствования. Для планирования и выполнения таких проектов рекомендуется использо вать методики управления проектами. Кроуфорд (Crawford) и Пеннипеккер (Pennypacker) сообщают, что, согласно масштабному опросу более чем 100 прак тикующих специалистов по управлению проектами (о котором уже говори лось в данной главе), “более 70% организаций внедрили у себя три или более нововведений за последние три года” [28]. К таким нововведениям относятся организация офиса управления проектами, введение методологии управления проектами, применение программного обеспечения управления проектами, интеграция управления проектами в основные процессы компании, обучение персонала управлению проектами, развертывание программы переподготов ки сотрудников, занятых в проектах. 105 Рекомендуемый подход к улучшению процессов управления проектами Идентификация благоприятных возможностей и необходимость улучшения Для того чтобы признать необходимость совершенствования организации в об ласти управления проектами, достаточно всего лишь честно ответить на несколь ко фундаментальных вопросов: • существуют ли в организации проекты? • поддерживает ли каждый проект утвержденную стратегию? • идентифицируются ли риски каждого проекта, выполняется ли управление ими, эффективно ли оно? • выполнены/выполняются ли эти проекты в соответствии с оригинальны ми (или обоснованно пересмотренными) расписаниями, бюджетами, кон трактными ценами и другими требованиями, сформулированными в кон трактах и иных официальных документах? • достигнуты ли изначально запланированные цели и размеры прибыли в коммерческих проектах? Выплачивались ли неустойки? • можно ли при существующей структуре управления, планирования и кон троля эффективно управлять большими по размеру проектами либо боль шим количеством проектов, в том числе различного типа, если это потре буется для достижения стратегий организационного роста или других перспективных целей организации? Если все ответы утвердительны, то возможности организации по управле нию проектами исключительно хороши. Если же какие либо ответы отрицатель ны, то следует принять меры по улучшению ситуации. Эти меры могут заклю чаться в совершенствовании знаний и навыков людей, перераспределении обязанностей и ответственности, изменениях в политике, процессах, проце дурах, системах и методах управления проектами – по отдельности или вместе. Симптомы и вероятные причины неудовлетворительного исполнения проектов Ниже приводятся некоторые симптомы неудовлетворительного исполнения проектов: • отклонение от расписания: поздние завершения и задержки с сопутствующи ми перерасходами средств и выплатами неустоек, предусмотренных кон трактом; • высокая текучесть кадров, высо низкая производительность труда персонала: кий уровень стрессов, вялое настроение (отсутствие боевого духа); 106 Улучшение возможностей управления проектами в компании • превышение запланированных расходов: фактические траты часто выходят за рамки бюджета; • чрезмерно активное привле низкая производительность труда руководства: чение высшего руководства к мелким деталям процесса выполнения про екта; • неэффективное управление ресурсами: избыточная многозадачность (большие затраты времени на переключение между задачами), дублирование дей ствий и неэффективное использование специалистов узкого профиля. Выявление и устранение причин, приводящих к возникновению этих типич ных проблем, обычно требует весьма активного участия опытных практикую щих специалистов по управлению проектами. Идентификация проблем, рисков и подводных камней Центр управления проектами компании AT&T разработал и внедрил процесс формального оценивания управления проектами, поставив целью “найти спо соб практического воплощения концепции управления проектами…, анализи руя то, чего мы уже достигли… и определяя пути дальнейшего улучшения” [95]. Шнейдмюллер и Балабан сообщают об отличных результатах такого оценива ния и о позитивной реакции со стороны менеджеров проектов, а также персо нала их команд. Ондов (Ondov) сообщает, что “Группа технического оценивания при AT&T, в прошлом входящая в состав компании Bell Labs, проводила оценивание проек тов разработки программного обеспечения во всех компаниях AT&T в течение более десяти лет, изучив сотни проектов всех типов” [77]. Хотя результаты, сообщенные Ондовом, относятся к проектам в сферах ин формационных технологий и программного обеспечения, их также можно от нести и ко многим другим категориям проектов, не опасаясь неправильной ин терпретации. Подобное оценивание на самом деле охватывает множество дополнительных областей; те из них, которые имеют отношение к PMBOK Guide, сведены в табл. 3.5. Ондов описывает ряд улучшений, которые были отмечены в ходе подобного оценивания, а также перечисляет проблемы, характерные для управления про ектами, и критически важные факторы успеха, обнаруженные и сформулиро ванные Группой технического оценивания при AT&T за время ее существо вания. К типичным причинам неудовлетворительного управления проектами, в до полнение к вышеперечисленным, относятся следующие: • система управления жизненным циклом проекта (Project Life Cycle Ma nagement System, PLCMS) и лежащие в ее основе процессы не понимают ся или не документируются как единое целое, а то и вовсе не существуют; 107 Рекомендуемый подход к улучшению процессов управления проектами Òàáëèöà 3.5. Ïðîáëåìû, âûÿâëåííûå â õîäå îöåíèâàíèÿ ïðîåêòîâ êîìïàíèè AT&T Инициация Выполнение проекта проекта Нечетко постав Коммуникация ленная проблема и информационный в бизнесе и/или обмен затруднены критерии успеха Малый акцент на управлении Отсутствие исполнительного поставщиком спонсора Неадекватные или защитника ресурсы Последовательные Нарушения в ходе назначения выполнения нескольких чело процессов (напри век на должность мер, игнорирова менеджера проекта ние шлюзов (либо отсутствие качества) такового) Недостаточное Заниженная внимание внешним оценка содержа интерфейсам ния/масштаба (связям), разверты работ ванию, поддержке Необоснованно Сокращенные большие требова сроки тести ния к системе, рования купленной Неэффективная в готовом виде, расстановка не адаптированной приоритетов под нужды пользо вателя Конечная дата определена директивно, без учета последствий План проекта отсутствует или представляет собой только расписание проекта Неадекватные требования Нереалистичные расписания Реально существу ющие риски не признаются Отслеживание Закрытие и контроль проекта проекта Наблюдение Успех не оце при отсутствии нивается (что контроля не мешает декларировать Неэффективный его наличие!) мониторинг приближения Проект не закры к целям вается и вообще не прекращает Отчеты о состоя своего нии проекта существования вводят в заблужде ние или готовятся Полученный опыт недостаточно не накапливается часто и не используется в последующих проектах 110 Улучшение возможностей управления проектами в компании Метод “пилотного” проекта Природа проектно ориентированных ситуаций дает уникальную возможность разработать и протестировать набор определенных изменений в рамках тща тельно отобранного “пилотного”, или прототипного, проекта до начала пол номасштабной программы по осуществлению изменений. “Пилотный” проект может служить не только средством внедрения и проверки новых приемов и ме тодов, но также наглядным примером, средством обучения и подготовки управ ленческого персонала. Использование такого подхода требует тщательного выбора проекта, кото рый должен удовлетворять следующим критериям: • жизненный цикл проекта не должен быть слишком продолжительным; • проект должен быть репрезентативным, то есть его основные характерис тики должны с высокой степенью достоверности соответствовать характе ристикам других проектов; • он не должен быть отягощен заведомо неразрешимыми проблемами (на пример, предполагать невыполнимые сроки), поскольку совершенствова ние системы управления и навыков персонала не решит таких проблем. Всегда существует опасность того, что все заинтересованные лица будут уде лять повышенное внимание “пилотному” проекту и, следовательно, он окажет ся настолько успешным, что определить полезность изменений, тестируемых в нем, не получится. При этом не исключено, что значительно пострадает ис полнение других проектов, так как все ресурсы и внимание будут привлечены к “пилотному”. Однако некоторые усовершенствования могут быть применены не к отдель ному проекту, а лишь к целому ряду – в противном случае не удастся достичь мак симальной эффективности. Совершенно очевидно, что реализация управления портфелями проектов потребует наличия нескольких проектов. Внедрение ком пьютерной системы планирования и контроля мультипроекта – еще одна ситуа ция, в которой одного проекта недостаточно. Использование реальных и учебных проектов для обучения и подготовки персонала Процессы создания и обучения команды проекта на реальных проектах под робно описываются в главе 11. 111 Улучшение системы управления жизненным циклом проекта 3.5 УЛУЧШЕНИЕ СИСТЕМЫ УПРАВЛЕНИЯ ЖИЗНЕННЫМ ЦИКЛОМ ПРОЕКТА После того как жизненные циклы проектов для каждой категории или подкате гории разработаны и задокументированы (см. раздел 2.5), становится возмож ным определить и задокументировать для каждой категории систему управле ния жизненным циклом проектов. Только при наличии такой документации улучшения могут носить систематический характер. Чтобы ввести в процессы управления проектами такой элемент, как всеоб щее управление качеством (Total Quality Management, TQM), избежать бессис темности и отрывочности, рекомендуется: 1. Задокументировать и описать систему управления жизненным циклом проекта (Project Life Cycle Management System, PLCMS) для каждой категории про ектов, существующих в организации (как показано в главе 2). 2. Определить фазы жизненных циклов для каждой категории проектов. 3. Установить шлюзы и точки принятия решений/утверждений между фаза ми жизненного цикла. 4. Описать и определить протекание процессов в каждой фазе; определить промежуточные и окончательные результаты каждой фазы. 5. Идентифицировать и соотнести друг с другом процессы анализа известных рисков, планирования и контроля, а также уместные документы и разреше ния для каждой фазы. Проведение реинжиниринга интегрированных процессов 1. Применить адекватные методы реинжиниринга к системе управления жиз ненным циклом для каждой категории проектов, чтобы: • идентифицировать ограничения, пробелы и слабые места системы; • соотнести нежелательные результаты проекта и их возможные причи ны с системой управления жизненным циклом там, где это возможно; • перепроектировать систему управления жизненным циклом, начиная с наиболее очевидных ограничений, недостатков и слабых мест; задоку ментировать результаты. 2. Получить необходимые согласия и провести соответствующие тесты или выполнить анализ, подтверждающий состоятельность и осуществимость предлагаемых изменений системы. 112 Улучшение возможностей управления проектами в компании 3. Спланировать, утвердить и выполнить проект улучшения существующей системы управления жизненными циклами. 4. По мере необходимости повторять вышеописанные действия, пока не бу дет достигнута оптимальная реализация системы управления. Улучшение процессов жизненного цикла нового продукта Купер (Cooper) и другие авторы, основываясь на своем богатом опыте работы со многими компаниями в различных отраслях, описывают полезный подход к улучшению процессов разработки новых продуктов [24, Appendix A, “Over hauling the New Product Process: Stage Gate TM Methods – A Synopsis”, pp. 333–339]. Ступенчато шлюзовой (Stage Gate TM ) процесс показан на рис. 2.5. Исследователи предоставляют полную и заслуживающую доверия информацию о том, как разра батывать, реализовать и улучшать эти процессы [24, “Designing and Implementing the Portfolio Management Process: Some Thoughts Before You Charge In”, pp. 301–332]. Рассмотрение возможности применения теории ограничений для улучшения системы управления жизненным циклом проекта Теория ограничений (Theory of constraints, TOC), разработанная Голдраттом (Gold ratt), и ее применение к управлению проектами, а именно управлению на осно ве критической цепочки (Critical Chain Project Management, CCPM) [42, 44], вы звали в последние несколько лет горячий энтузиазм среди многих практикующих специалистов и консультантов в сфере управления проектами. По своей сути TOC – это основанный на здравом смысле способ понять систему. TOC утверждает, что “любая система должна иметь ограничения, лимитирующие ее полез ный результат”. …Цель использования TOC состоит в том, чтобы улучшить систему ведения бизне са. В книге “What Is This Thing Called Theory of Constraints, and How Should It Be Implemented?” (Что такое теория ограничений и как ее следует использовать?), выпу щенной в 1997 году, Голдратт утверждает, что …прежде чем мы сможем иметь дело с улучшением любой части системы, мы долж ны определить ее глобальную цель и комплекс мер, позволяющий судить о влиянии, которое оказывает любая подсистема и любое локальное решение на эту глобальную цель [57, pp. 52, 53]. Глобальная цель любой системы управления жизненным циклом проекта (Pro ject Life Cycle Management System, PLCMS) – обеспечить как можно более быст рое прохождение всего пути от фазы концепции до фазы завершения проекта 113 Улучшение системы управления жизненным циклом проекта при использовании минимума ресурсов (труда, денег, материалов, производствен ных мощностей). Применение теории ограничений к улучшению PLCMS пред ставлено на рис. 3.3 в упрощенном виде. 1 Идентифицировать ограничения системы 2 Определить, как воспользоваться ограничениями системы 3 Привести все остальное в соответствие с принятым решением 4 Устранить ограничение системы 5 Уменьшает ли новое Да ограничение возможности системы? Нет 6 Не допускайте того, чтобы в силу инерции возникали ограничения Рисунок 3.3. Пять основных стадий, поясняющих использование TOC в непрерывном совершенствовании. Источник: Leach, Lawrence P. Critical Chain Project Management. – Norwood, MA: Artech House, 2000, p. 64. Использовано с разрешения автора 114 Улучшение возможностей управления проектами в компании Лич (Leach) предлагает детальное рассмотрение этой теории, а также ин струменты и методы ее применения вкупе со всеобщим управлением каче ством (Total Quality Management, TQM) для совершенствования систем уп равления проектами [57]. Тот же автор описывает, каким образом TOC и планирование/контроль проекта на основе критической цепочки могут улуч шить исполнение расписания и стоимости проектов (см. главы 11, 13 дан ной книги). 3.6 ПРЕОДОЛЕНИЕ ПРЕПЯТСТВИЙ В УПРАВЛЕНИИ ПРОЕКТАМИ Введение практики интегрального управления проектами и связанной с этим формализации управления проектами обычно требует значительных изме нений в отношении к работе, понимании дела, обязанностях, методах и по дотчетности во всех участвующих организациях. Эти изменения затрагива ют родительскую организацию и все другие, представленные в команде проекта. Необходимым преобразованиям препятствуют культурные, национальные и иные факторы как в окружении проекта, так и в связанных с ним организаци ях, отраслях промышленности, географических областях. Для преодоления этих барьеров потребуются значительные усилия, но, если их не преодолеть, они могут привести к снижению эффективности управления проектом. Ниже представлены основные принципы пятиэтапной стратегии внедрения изменений, необходимых для эффективного управления проектом и борьбы с препятствиями. Эти принципы состоят в следующем: 1. Понимать, предвидеть и выявлять возможные препятствия на пути пред лагаемого изменения. 2. Развивать осознание необходимости изменений, понимать и использовать мотивирующие силы, способные помочь преодолеть эти препятствия. 3. Обучать и подготавливать всех вовлеченных в изменения сотрудников, ис пользуя для этого знания, полученные на первых двух этапах. 4. Определять “проекты изменений” для внедрения новых методов управле ния проектами и использования прогрессивных методов в планировании и выполнении работ. 5. Модифицировать и развивать методики управления проектами и/или ха рактер их внедрения для преодоления существующих либо предвидимых препятствий – культурных и иных. 115 Преодоление препятствий в управлении проектами Идентификация препятствий Для того чтобы преодолеть препятствия, стоящие на пути изменений, любая орга низация должна в первую очередь необходимые идентифицировать изменения, для повышения эффективности управления проектами, и установить их приори теты. Затем могут быть определены барьеры, препятствующие каждому из не обходимых изменений, а также выработаны и проведены в жизнь стратегии уменьшения этих барьеров. Ниже приводится список из восьми основных об ластей изменений, способных создать препятствия (вне всякого сомнения, дан ный список не является исчерпывающим, – в каждой организации будут выявле ны и другие области, определяемые ее спецификой): • интегрирующие должности начиная со следующей после генерального ме неджера ступеньки иерархической лестницы; • разделение ответственности в проекте; • подчинение двум руководителям – функциональному и проектному; • интегральные прогнозирующие планирование и контроль; • компьютерные информационные системы управления; • приоритет целей проекта над целями отдела; • поощрение не отдельных сотрудников, а команды в целом; • временные назначения в проект. Другие источники препятствий Помимо вышеперечисленных специфических препятствий, возникающих из за ошибок управления, существуют и дополнительные: отсутствие взаимопо нимания или многовековая вражда (национальная или этническая). Проявле ния этих качеств можно найти в совместных проектах, сводящих вместе две корпоративные культуры в одной стране, либо в проектах, предусматриваю щих участие двух отраслей промышленности, либо в многонациональных про ектах, включающих две или несколько национальностей и языков. Безусловно, внимательный читатель сможет назвать много других культурных факторов, которые создают барьеры для эффективного управления проектом. Силы, помогающие преодолеть препятствия Обычно в любой конкретной ситуации существуют силы, использование кото рых может помочь в преодолении барьеров. Давление организаций конкурентов, неудачи, показывающие неадекватность применяемых методов, взаимный обмен 116 Улучшение возможностей управления проектами в компании сотрудниками, имеющими различный опыт работы, с другими компаниями, желание многих сотрудников выполнять свою работу лучше и эффективнее, необходимость совершенствования деятельности организации в перспективе, неудовлетворенность текущей ситуацией и многое другое – все это условия, ко торые можно и нужно использовать. Особую важность имеет осознание необходимости перемен. Часто оно возникает вследствие неудачи проекта (в компании или отрасли), которая указывает на то, что продукты, рынки и окружения меняются, конкуренция принимает глобаль ные масштабы, и если организация хочет выжить, ее членам требуется менять ся вместе с ней. Для осознания необходимости перемен требуются наглядное представление текущей ситуации, обучение и общение. Как только изменения будут сочтены неизбежными, препятствия и барьеры станут менее устрашаю щими – их окажется легче преодолеть или уменьшить. При выработке страте гии внедрения изменений следует установить приоритеты, учитывая как важ ность отдельного фактора, так и осуществимость преобразований. Обучение и повышение квалификации После определения ожидаемых препятствий и условий, способных помочь в их преодолении, можно приступить к разработке программы обучения и подго товки к внедрению изменений. Природа управления проектами, предполагаю щая существование дискретных (отдельных) проектов, позволяет использовать некоторые из них в качестве инструмента для развития необходимых знаний и навыков. Такие проекты с точки зрения руководства можно рассматривать как прототипы, на которых проверяются новые приемы или методы. Они де монстрируют команде проекта и организации в целом, какую роль на самом деле играет менеджер проекта, и как сказываются на работе изменения, внедрен ные в систему планирования и контроля проекта. Однако некоторые необходимые преобразования, например внедрение управления портфелями проектов, предполагают наличие нескольких проектов. В случае управления портфелями проектов эксперимент по первоначальному внедрению может быть поставлен в масштабах отдела прототипов или линейки продуктов, а не всего предприятия. Командные совещания по планированию проектов, описываемые в главе 11, были признаны эффективным методом 1) внедрения новых методик управле ния проектами, 2) обучения, практической подготовки и сплочения проект ных команд, 3) преодоления барьеров, способных воспрепятствовать дости жению максимальной эффективности управления проектами. Одна из групп опытных профессионалов рекомендовала четыре типа совещаний для про ектов, включающих в себя несколько культур: совещания на уровне менедже ров и проектных команд, причем для каждого уровня, в свою очередь, рекомен довано проведение двух совещаний, одно из которых посвящено культурным 117 Преодоление препятствий в управлении проектами аспектам проекта, а второе – целям проекта, содержанию, перспективе и пла нам [3]. Просто объявить о внедрении нового процесса управления портфелями про ектов, о назначении менеджера проекта или о приобретении новой системы планирования и контроля не слишком действенно. В хорошо разработанной программе обучения и подготовки следует предусмотреть ожидаемые препят ствия и сделать упор на мотивационных факторах, которые помогут добиться приятия изменения. Сильнее всего внедрению новых методов управления про ектами сопротивляются, как правило, менеджеры среднего звена, поэтому их необходимо вовлечь в программу обучения и повышения квалификации. Выбор правильного курса действий для внедрения изменений Либо одновременно с обучением и повышением квалификации, либо после него необходимо предпринять действия по практическому внедрению концепций управления проектами. Руководители высшего звена сами должны узнать, по нять и поддержать новые методы, а также показать своим поведением, что со вершаемые преобразования важны для будущего компании. К тому же руко водство должно понимать, что в некотором роде утверждает поведенческие модели в организации, а потому пример, подаваемый подчиненным, будет го раздо важнее всяких речей. Введение новых интегрирующих должностей, методик или инструментов планирования и контроля, а также новых способов организации совместной работы в команде должно рассматриваться в рамках самостоятельных проек тов. Эти проекты изменений следует тщательно планировать и включать в них действия, направленные на обучение и подготовку, разработанные с учетом ожи даемых препятствий. Если считать эти действия “проектами по исследованию и развитию управления”, то они могут стать полезным инструментом внедре ния изменений и обеспечить большую их поддержку в организации. Модификация и расширение методик управления проектами Во всех организациях, управляющих проектами, методы управления развива лись в течение того или иного периода времени. Если опыт в данной области отсутствует, невозможно и даже нежелательно за короткий промежуток време ни стать в этой области образцом или подняться на уровень, на достижение которого некоторые организации тратят долгие годы. Не все препятствия (куль турные и другие) можно преодолеть, особенно за короткое время. В каждую из трех основных концептуальных областей (интегрирующие роли, планирование 118 Улучшение возможностей управления проектами в компании и контроль, команда проекта) изменения должны вноситься поэтапно. Часто бу дут требоваться компромиссы между идеалом и тем, чего можно достичь в теку щем году. Прежде чем организация будет готова перейти к следующему уровню преобразований, необходимо усвоить опыт предыдущего. Например, вследствие культурного неприятия должности “менеджер” и идеи полной интегрирующей ответственности организация может начать изменения с назначения коорди натора проекта, занимающего интегрирующую роль с ограниченной ответствен ностью. В таких случаях руководителю, которому отчитывается координатор проекта, помимо своих обычных обязанностей, вероятно, придется дополни тельно исполнять роль менеджера проекта. Выводы Вероятность успешного преодоления культурных барьеров на пути эффектив ного управления проектами может быть повышена за счет использования пяти ступенчатой стратегии, описываемой в разделе 3.6. Управление проектами – это управление изменениями. Совершенствование управления проектами требует изменений. Следовательно, само внедрение или совершенствование управления проектами требует эффективных методов ру ководства и должно рассматриваться в долгосрочной перспективе. Здесь не мо жет быть универсального рецепта. Концепции управления проектами следует адаптировать к конкретной ситуации и культуре, включая культурное смешение в команде проекта. Т РЕБОВАНИЯ ВЫСШЕГО РУКОВОДСТВА Улучшение возможностей по управлению проектами Чтобы в управлении проектами наметились значительные улучшения, ру ководитель должен добиться удовлетворения следующих условий: • в пределах каждого портфеля проектов, существующего в органи зации, составляется и ведется полный реестр входящих в него про ектов; • выполняется объективный анализ производительности, достигнутой при выполнении прошлых проектов и достигаемой в текущих; это не обходимо для определения проблемных областей, которые нуждают ся в улучшениях, а также для ранжирования этих областей в соответ ствии с системой приоритетов; 119 Преодоление препятствий в управлении проектами • идентифицируются конкретные аспекты управления проектами, требующие улучшения; при этом используется наиболее пригодная в конкретной ситуации модель зрелости управления проектами и про водится сравнение эффективности выполнения проектов в данной организации с соответствующим показателем в других компаниях; • система управления жизненным циклом проекта (PLCMS) для каждой категории проектов, существующей в организации, должна быть за документирована и пересмотрена с целью выявления и максимально го устранения присущих ей ограничений; • практическое улучшение процессов управления проектами продумы вается, планируется и организуется с использованием концепций и методов, описанных в настоящей книге; • программа внесения улучшений в управление проектами поддержива ется программами обучения и повышения квалификации, проводимы ми на постоянной основе на всех уровнях организации. 4 « « » » Роли в управлении проектами 4.1 КЛЮЧЕВЫЕ ДОЛЖНОСТИ С ИНТЕГРИРУЮЩЕЙ ОТВЕТСТВЕННОСТЬЮ Поскольку менеджер проекта играет основную роль, именно ей в последнее де сятилетие уделялось особое внимание в литературе по управлению проектами. Однако имеются и другие интегрирующие должности, которые раньше часто упускались из виду. Эти должности, соответствующие им обязанности и полно мочия описываются в последующих разделах. Уровень руководства компании объединяет стратегическое руководство всеми проектами Генеральный менеджер со стратегическими планами компании, главным образом, посредством группы управления портфелями проектов или назначенных спонсоров. Это руководство также обеспечивается за счет санкционирования выделения финансовых и дру гих ресурсов в портфели проектов. Группа управления портфелями проектов объединяет и проверяет на взаимное соответствие стратегические цели организации и программы/проекты внутри портфелей, находящиеся в ее ведении. Она же устанавливает и утверждает при оритеты проектов внутри каждого портфеля. Спонсор проекта объединяет повседневное стратегическое руководство отве денным ему проектом (осуществляемое через менеджера проекта) с повседнев ной деятельностью организации. Директор по управлению проектами объединяет операционные аспекты работ, выполняемых по всем проектам, которые находятся в ведении офиса управления 121 Ключевые должности с интегрирующей ответственностью проектами, а также использование организационных процессов, методов и ин струментов управления проектами с остальной деятельностью организации. Это же лицо несет и ответственность за работу офиса управления проектами (Project Management Office, PMO) или аналогичного подразделения (см. главу 7). Уровень программ и мультипроектов Менеджер программы объединяет усилия всех участников проектов, находящихся под его руководством. Менеджер мультипроекта объединяет приоритеты и резуль таты всех составляющих мультипроекта, а также несет общую ответственность за каждый из них. Сказанное справедливо и для группы малых проектов (см. гла ву 2), связанных недостаточно сильно, чтобы образовывать одну программу. Уровень проектов Менеджер проекта объединяет усилия всех участников проекта, находящихся под его руководством, ставя акцент на то, что должно быть сделано (то есть на со держании работ), когда это надлежит сделать согласно расписанию и как достичь выполнения этих работ в рамках утвержденного бюджета. Уровень функциональных подразделений и участников проекта Руководитель функционального подразделения объединяет усилия участников всех проектов в рамках своего подразделения или дисциплины – прежде всего, пу тем направления доступных ресурсов отдела в утвержденные активные портфе ли проектов. Функциональное руководство делает акцент на том, как будет вы полняться работа (технический аспект), насколько хорошо (качественный аспект) и кто будет выполнять ту или иную задачу либо пакет работ (аспект назначения ресурсов). Функциональный лидер проекта объединяет усилия участников всех проектов в рамках определенной функции или дисциплины. Именно с функциональными лидерами проекта контактирует менеджер проекта, перед которым они, таким образом, являются представителями функциональных подразделений. Лидер пакета работ объединяет усилия отдельных лиц в рамках определенно го пакета работ по каждому проекту. Другие важные роли в управлении проектами Управление проектами предполагает наличие и других важных ролей (должнос тей). Они перечисляются ниже: 122 Роли в управлении проектами • клиент (заказчик): лицо или организация, которое/которая санкционирует и обычно оплачивает выполнение проекта; • лицо, которое стимулирует и поддерживает проект. Мо защитник проекта: жет являться или не являться генеральным менеджером проекта; • владелец результатов проекта: лицо или организация, которое/которая мо жет являться или не являться заказчиком проекта; • пользователь результатов проекта: лицо или организация, которое/которая может являться или не являться владельцем. Хотя все эти роли имеют большое значение, уровень их интегрирующей ответ ственности ниже, чем у ключевых ролей, перечисленных выше. Однако, если организация клиент (заказчик) проекта – это основной его участник, вносящий в проект наибольший вклад и проводящий важные работы, от которых зависит выполнение проекта, то может возникнуть необходимость учреждения ряда должностей с объединяющей ответственностью и в организации клиенте. Все сказанное выше справедливо для всех внешних компаний участников, вклад ко торых в проект достаточно значителен. Общая модель взаимоотношений между должностями с интегрирующей ответственностью На рис. 4.1 приведена общая модель взаимоотношений вышерассмотренных должностей с интегрирующей ответственностью. Ключевые должности иден тифицируются и учреждаются политиками управления проектами, принятыми в организации, инструкциями и процедурами. У каждой должности свое на звание, определяемое принятыми в организации стандартами и характером ее деятельности. Обязанности и полномочия носителей каждой из этих ключевых должностей более подробно рассматриваются ниже. 4.2 ОБЯЗАННОСТИ И ПОЛНОМОЧИЯ НОСИТЕЛЕЙ КЛЮЧЕВЫХ ДОЛЖНОСТЕЙ С ИНТЕГРИРУЮЩЕЙ ОТВЕТСТВЕННОСТЬЮ Обязанности по инициации, планированию, исполнению, управлению и завер шению программ и проектов распределяются соответствующим образом среди лиц, назначенных на описанные выше должности. Наделение лица, занимаю щего ту или иную должность, полномочиями, соизмеримыми со степенью от ветственности, часто проблематично – особенно тогда, когда интегрирующий характер этих должностей не понимается в должной мере. Способ распределения 123 Обязанности и полномочия носителей ключевых должностей Генеральный менеджер Генеральный менеджер Спонсор проекта "А" Спонсор проекта "А" Другие Директор Руководство Директор Руководство функциональные по управлению функционального по управлению функционального подразделения проектами подразделения проектами подразделения Другие Насколько проекты хорошо Что Менеджер Функциональный Менеджер Функциональный Когда проекта "А" лидер проекта проекта "А" лидер проекта Сколько Кто Как Лидер пакета Отдельные Лидер пакета работ участники работ Персонал Персонал Лидер пакета Лидер пакета работ работ Планирование и контроль проекта Ðèñóíîê 4.1. Îáîáùåííûå âçàèìîîòíîøåíèÿ ìåæäó êëþ÷åâûìè äîëæíîñòÿìè ñ îáúåäèíÿþùåé îòâåòñòâåííîñòüþ обязанностей и полномочий среди сотрудников, занимающих вышеперечислен ные посты, зависит от ряда факторов, которые перечислены ниже: • размер и тип организации – является она проектно ориентированной или проектно зависимой (см. главу 1); • степень важности программ и проектов на фоне повседневной деятельнос ти организации; • отрасль или предметная область, в которой работает организация; • количество и тип портфелей проектов и категорий проектов, существую щих в организации, а также количество программ и проектов, выполняе мых в данный момент времени; • степень зрелости дисциплины управления проектами в организации; • размер, характер, приоритет данной конкретной программы или проекта и ее/его текущая фаза жизненного цикла; • опыт и способности (талантливость) лиц, занятых в проекте. 124 Роли в управлении проектами В следующих разделах будут приведены общепринятые описания обязаннос тей, соответствующие каждой из интегрирующих должностей, а также (по мере необходимости) комментарии, касающиеся полномочий носителей этих долж ностей. Более детальное описание обязанностей и полномочий группы управле ния портфелями проектов, директора по управлению проектами, менеджеров про ектов и функциональных руководителей, равно как и альтернативных способов определения должностей и назначения персонала, приведено в главах 7–9. 4.3 ГЕНЕРАЛЬНЫЙ МЕНЕДЖЕР называется лицо, несущее общую ответственность за де Генеральным менеджером ятельность многофункционального подразделения либо организации в целом. Основные задачи генерального менеджера по управлению проектами перечис лены ниже: • обеспечение соответствия портфелей проектов в организации ее глобаль ным бизнес стратегиям; • общее управление проектами в компании; • интеграция процесса управления проектами с остальными аспектами жиз ни и деятельности организации; • обеспечение утвержденных проектов достаточным количеством финансо вых, человеческих и других ресурсов. Хотя все обязанности сотрудников, занимающих вышеописанные интегриру ющие должности, делегируются им генеральным менеджером, существует ряд обязанностей, которые не могут быть делегированы другому лицу. За редким исключением генеральный менеджер не принимает прямого участия в плани ровании или исполнении любого отдельно взятого проекта. В общем и целом эта должность требует выполнения следующих обязанностей: • в первую очередь обеспечить соответствие отбираемых или создаваемых проектов стратегиям роста организации; • предоставить соответствующие ресурсы для исполнения утвержденных проектов; • обеспечить применение соответствующих методик управления проектами в компании; • осуществлять мониторинг общего хода работ по проекту и координировать ход работ по проекту с другими видами деятельности организации; • разрешать связанные с проектами конфликты, для которых не были найде ны решения силами старших менеджеров; 125 Группа управления портфелями проектов • оценивать производительность труда менеджеров, отчитывающихся перед генеральным менеджером; • периодически оценивать ход исполнения больших проектов (наступление главных контрольных событий, прогнозы стоимости по завершении и при были и т.д.). Г енеральный менеджер несет окончательную ответственность (делегирован ную ему советом директоров или аналогичным органом высшей власти) за все аспекты жизни и деятельности организации. Полномочия данного лица, касаю щиеся выполнения им вышеперечисленных обязанностей, крайне редко под вергаются сомнению – если вообще подвергаются. 4.4 ГРУППА УПРАВЛЕНИЯ ПОРТФЕЛЯМИ ПРОЕКТОВ Группа управления портфелями проектов – ключевой элемент правильно применя емой концепции управления портфелями проектов. Учитывая характер выпол няемых обязанностей, как правило, неразумно возлагать их на отдельное лицо – менеджера или руководителя. Для того чтобы удалось должным образом сбалан сировать конфликтующие возможности и принять наилучшие решения при от боре, расстановке приоритетов и выделении ключевых ресурсов в различные (часто непохожие друг на друга) проекты каждого портфеля, необходимо нали чие нескольких точек зрения. Общие обязанности группы управления портфелями проектов заключаются в следующем: • утверждать план процесса управления портфелем проектов как при перво начальной реализации, так и при последующем внесении в него значитель ных изменений; • активно участвовать в практической реализации процесса управления портфелями проектов; • рекомендовать высшему руководителю и другим старшим менеджерам по лучать (изыскивать) дополнительные финансовые и другие ресурсы в тех случаях, когда этого требуют планирование и исполнение проектов, необ ходимых для достижения стратегических целей организации в ограничен ный срок; • выявлять благоприятные возможности совершенствования управления портфелями проектов и формулировать рекомендации по такому совершен ствованию, равно как и по улучшению других процессов, систем, инстру ментов управления проектами. 126 Роли в управлении проектами Данные обязанности и сам процесс управления портфелями проектов под робно рассматриваются в главе 8. 4.5 СПОНСОР ПРОЕКТА Роль спонсора проекта обычно берет на себя менеджер высшего звена, который действует от лица руководства организации, финансирующей или исполняющей проект. Эту роль может играть генеральный менеджер ответственной за проект организации, ее руководитель высшего звена или лицо, подчиняющееся непо средственно генеральному менеджеру. В случае выполнения очень большого проекта в роли его спонсора выступает руководящая группа или “коллективный управляющий”, куда входят лица, занимающие в компании различные ключевые посты. Роль спонсора проекта имеет ряд отличий от роли группы по управлению порт фелями проектов. Последняя ответственна за всю совокупность проектов порт феля, как уже было сказано раньше. Спонсор же, в роли которого обычно высту пает одно лицо, является в первую очередь “проводником” стратегического руководства проектами, обеспечивающим непосредственный контакт с ответ ственным менеджером программы или проекта вне зависимости от места, зани маемого этим менеджером в иерархической структуре организации. Группа экспертов по управлению проектами пришла к следующему выводу: Отсутствие специально назначенного спонсора проекта с четко определенными и четко понимаемыми обязанностями – причина множества трудностей, возникаю щих в проектах и лично у их менеджеров. В большинстве организаций можно увели чить эффективность управления проектами, уделяя большее внимание этой крити чески важной роли [3]. Если для исполнения интегрирующих функций не назначается спонсор про екта, то менеджеру проекта часто бывает трудно определить, к кому обратиться за нужным решением, если таковое лежит за пределами его полномочий; тогда он вынужден адресовать свои проблемы генеральному менеджеру, доступ к ко торому часто затруднен или невозможен. Далее, при отсутствии назначенного спонсора некоторые руководители (иногда включая менеджеров проекта) мо гут предположить, что менеджер проекта должен исполнять роль спонсора про екта. Это приводит к проблемам и конфликтам, вызванным превышением пол номочий. Хотя назначение одного и того же лица на обе роли не исключается, в большинстве случаев они должны быть разделены. Спонсор – главный источник тех решений по проекту, которые лежат за пре делами полномочий менеджера проекта. Ниже приводится список типичных обязанностей спонсора проекта: • нести ответственность за средства, инвестируемые в проект; • определять и формировать бизнес план проекта; 127 Директор по управлению проектами • утверждать содержание и цели проекта, включая расписание, бюджет и вно симые в них изменения; • издавать приказы и распоряжения по проекту; • назначать менеджера проекта или утверждать это назначение, а также со ответствующую должностную инструкцию и непосредственного началь ника; • осуществлять мониторинг окружения проекта (экономического, политичес кого, конкурентного, технологического) и информировать менеджера про екта об изменениях окружения, способных повлиять на выполнение работ; • вносить и утверждать основные изменения по проекту и решения, касаю щиеся предоставления требуемых средств; • периодически отслеживать ход исполнения работ и формулировать стра тегические указания для менеджера проекта; • устанавливать стратегические приоритеты и разрешать конфликты, пере адресованные менеджером проекта или другими членами команды; • в сотрудничестве с менеджером проекта обеспечить соответствие конеч ного результата проекта его первоначальному обоснованию в свете эконо мических, конкурентных и маркетинговых изменений, произошедших за время выполнения работ. Должностная инструкция спонсора проекта должна наделять его (будь то от дельное лицо или группа лиц) полномочиями, достаточными для выполнения соответствующих функций. Как уже говорилось выше, в сложных проектах с высоким уровнем риска наилучшим решением является назначение на эту долж ность “коллективного управляющего”, то есть трех или более руководителей вы сокого уровня, если только генеральный менеджер не желает и неспособен взять лично на себя обязанности спонсора проекта. Должность спонсора проекта обыч но не предполагает работы с полной занятостью независимо от того, кто играет эту роль – лицо или коллектив. 4.6 ДИРЕКТОР ПО УПРАВЛЕНИЮ ПРОЕКТАМИ Должность директора (вице президента, менеджера и т.д.) по управлению проектами появляется во многих организациях по мере того, как их возможности по управ лению проектами становятся все более зрелыми. Наличие данной должности отражает важность и признание функции управления проектами в организации наряду с такими традиционными функциями, как маркетинг, инжиниринг, снаб жение и поставки, производство, строительство, эксплуатационные испытания, финансы и бухгалтерия, юридическая поддержка и т.д. В некоторых ситуациях директор по управлению проектами может также являться спонсором отдель ного проекта. 128 Роли в управлении проектами Некоторые практикующие специалисты предсказывали скорое появление в некоторых организациях должности главного управляющего по проектам (Chief Projects Officer) [31, p. 72] наравне с недавно возникшей должностью главного управляющего по информационному обеспечению (Chief Information Officer). Эта должность может сочетать обязанности спонсора проекта и директора по управлению проектами. Директор по управлению проектами, как правило, должен выполнять следу ющие функции: • обеспечивать профессиональное руководство и обучение для менедже ров программ, проектов и мультипроектов – вне зависимости от того, подотчетны ли эти сотрудники непосредственно директору по управле нию проектами. Главный акцент здесь делается на развитие профессио нальных навыков менеджеров программ/проектов, а также на исполь зование и практическое применение методов и информационных систем управления проектами; • разрабатывать и улучшать процессы, политики, методы управления проек тами, в частности обеспечивать приобретение и обновление соответству ющих вычислительных пакетов, а также адекватное воспитание и обуче ние персонала в масштабах всей организации; • предоставлять должную поддержку планирования, составления расписания, оценивания и ведения отчетности менеджерами проектов и мультипроек тов. Понятие “должная поддержка” существенно зависит от организации: в одной компании может существовать централизованная поддержка всех выполняющихся проектов, а в другой каждый менеджер и каждый офис проекта вполне самодостаточны в этой области; • разрешать конфликты между проектами в тесном взаимодействии с ответ ственными спонсорами и менеджерами проектов и в рамках должностных полномочий, определенных генеральным менеджером для директора по управлению проектами и спонсоров проектов; • обеспечивать исполнение проекта в соответствии с принятыми по кон тракту обязательствами и требованиями органов государственного регу лирования. Полномочия, которыми наделяется директор по управлению проектами, мо гут существенно варьироваться в зависимости от зрелости процессов управле ния проектами, степени самостоятельности каждого менеджера проекта в орга низации и способа комплектации каждого проектного офиса персоналом. Директор по управлению проектами должен выполнять свои функции в режиме с полной занятостью в любой организации, имеющей достаточно сложную и раз ветвленную структуру. В главе 8 приводится более детальное описание данной должности, а также рассматривается офис проекта. 129 Менеджеры программы, проекта и мультипроекта 4.7 МЕНЕДЖЕРЫ ПРОГРАММЫ, ПРОЕКТА И МУЛЬТИПРОЕКТА Роль, исполняемая менеджером программы или проекта, больше связана с прак тической стороной дела, чем роль спонсора, носящая стратегический характер. Менеджер проекта планирует и направляет работы по проекту таким образом, чтобы он был выполнен в срок, в рамках бюджета и в соответствии с требуемым качеством – как это определено спонсором проекта и/или документами, авто ризующими проект. Г енеральный менеджер может делегировать лицу, занимающему данную долж ность, как очень малые, так и весьма значительные обязанности и полномочия. Если обязанности и полномочия невелики, этот сотрудник фактически высту пает в роли координатора или экспедитора проекта, между тем как реальные функции менеджера проекта исполняет сам генеральный менеджер. Менеджер проекта – во всяком случае, действительно достойный так назы ваться – должен нести основную ответственность за общее планирование, на правление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемых результатов в рамках утвержденных бюджета и рас писания. Менеджер проекта является генеральным менеджером для данного проекта в том, что касается ответственности и отчетности за окончательные прибыли/потери по проекту, а также его выполнения в срок. Основная задача менеджера проекта – объединение усилий всех лиц, участвующих в нем. Эти обязанности не подменяют обязанностей функциональных руководителей, чьи подчиненные осуществляют работы по проекту, а, скорее, перекрывают такие задачи, делая акцент на проект в целом. Менеджер проекта облечен то есть правом отдавать полномочиями по проекту, функциональным лидерам проекта, а в их отсутствие – соответствующим функ циональным руководителям распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Как показано на рис. 4.1, такие распоряжения связаны с тем, что необходимо сделать и когда; сколько денег и рабочего времени это потребует. Подобные детали выясняются в ходе переговоров между менедже ром проекта и различными функциональными руководителями или лидерами проекта. Руководство проектом также включает в себя получение информации, не обходимой для планирования, мониторинга, оценивания и контроля проекта. С другой стороны, функциональный руководитель или лидер проекта дает ука зания по поводу того, насколько хорошо должна быть выполнена работа (качествен ный аспект), кто конкретно будет выполнять эту работу и как именно (техничес кий аспект). Если менеджер проекта попытается руководить проектом, решая вопросы “насколько хорошо, кто и как именно”, повышается вероятность возникно вения серьезных конфликтов с персоналом функциональных отделов. Полномочия менеджера проекта зависят в большей степени от его лич ных способностей приобрести авторитет, чем от полномочий, номинально 130 Роли в управлении проектами соответствующих его должности. В табл. 4.1 приводятся краткие сведения по двум источникам полномочий. Òàáëèöà 4.1. Èñòî÷íèêè îôèöèàëüíûõ è ïðèîáðåòåííûõ ïîëíîìî÷èé Источники официальных полномочий Источники приобретенных полномочий Устав организации Технические и организационные знания Положение и характер организации Управленческий опыт Должностная инструкция Способность к установлению контактов или квалификационные требования Принадлежность к руководящему звену Способность вести переговоры с руководителями и коллегами Документированные политики Создание и поддержание союзнических отношений Должностная субординация Ключевая должность менеджера проекта Делегированные полномочия Умышленный конфликт Иерархическая цепочка полномочий Разрешение конфликта Контроль над фондами Правота в решении вопросов Поскольку менеджер проекта вынужден добиваться выполнения работ от со трудников, не находящихся у него в прямом подчинении, то прежде всего он должен полагаться на межличностное влияние, а не на официальные полномо чия. Уайлмон (Wilemon) и Джеммилл (Gemmill) определили три важных спосо ба оказания влияния на людей: экспертная власть, референтная власть, власть поощрения и наказания [115, p. 319]. Под понимается спо экспертной властью собность менеджера проекта заставить исполнителей делать то, что ему нужно вследствие того, что ему приписывают более обширные знания и квалифика цию, дающие ему право принимать решения по проекту и оценивать последствия отдельных операций или решений. Референтная власть означает отзывчивость участников проекта, которые по той или иной причине симпатизируют менед жеру проекта и ценят как отношения с ним, так и его мнение о них. Власть поощ рения и наказания означает, что менеджер проекта может прямо или косвенно затруднить или облегчить достижение личных целей людям, которые уклоня ются от исполнения его требований. Более подробно обязанности и ответственность менеджера проекта рассмот рены в главе 9. Должность менеджера программы, по сути, предполагает выполнение тех же самых обязанностей с добавлением еще одной – интеграции и координации ра бот по нескольким (двум и более) проектам. При выполнении большой програм мы в каждый проект, являющийся ее частью, назначается менеджер проекта, а менеджер программы в этом случае осуществляет общее руководство менедже рами проектов. Все вышеприведенные соображения, касающиеся обязанностей 131 Функциональные руководители и лидеры проекта, лидеры пакетов работ и полномочий менеджера проекта, в равной степени применимы и к менеджеру программы. Менеджер программы зачастую выполняет функции спонсора проекта по от ношению к каждому проекту программы. В зависимости от положения менед жера программы в иерархической структуре организации может и не возник нуть необходимости назначать отдельное лицо на должность спонсора. Менеджер мультипроекта выполняет обязанности менеджера проекта для нескольких проектов одновременно. С одной стороны, это может быть несколь ко малых проектов; с другой, иногда возникает ситуация, когда менеджеру про екта, близящегося к завершению, передают еще один проект, находящийся, на пример, в концептуальной фазе. Менеджеры мультипроектов несут ту же ответственность за находящиеся под их управлением проекты, что и менеджеры отдельных проектов, и имеют такие же полномочия. В главе 8 должности менеджера программы и менеджера мультипроекта рас сматриваются подробнее. 4.8 ФУНКЦИОНАЛЬНЫЕ РУКОВОДИТЕЛИ, ФУНКЦИОНАЛЬНЫЕ ЛИДЕРЫ ПРОЕКТА, ЛИДЕРЫ ПАКЕТОВ РАБОТ Поскольку создание абсолютно самодостаточной (автономной) организации, в которую входят представители всех необходимых профессий и дисциплин, обычно не представляется возможным, практически все проекты нуждаются в поддержке со стороны той или иной узкоспециализированной или много функциональной организации. Большинство компаний планирует и исполняет несколько проектов одновременно. Результат такого “управления матрицей” со стоит в том, что каждый специализированный отдел выделяет своих людей для выполнения различных задач в рамках нескольких текущих проектов. Как уже упоминалось раньше, в каждом функциональном подразделении, участвующем в проекте, существуют три уровня интегрирующей ответственнос ти, соответствующие трем должностям: • функциональный руководитель; • функциональный лидер проекта; • лидер пакетов работ (или задач). Каждый руководитель сначала должен своевременно обеспечить каждый проект необходимыми ресурсами – человеческими и материальными, а затем объединить требования (часто конфликтующие друг с другом) всех активных проектов в подразделении. Руководитель функционального подразделения 132 Роли в управлении проектами объединяет работы по всем проектам опосредованно, через функциональных лидеров, назначенных в каждый проект. В свою очередь, эти функциональные лидеры получают распоряжения по проектам от менеджеров проектов. Обязанности и полномочия функциональных руководителей Каждый функциональный руководитель несет общую ответственность за пла нирование и проведение конкретных работ (задач, пакетов работ, операций), которые должны выполняться внутри подразделения для создания результатов (аппаратуры, программ, документов, капитальных средств, услуг) по каждому ак тивному проекту. Основные технические и управленческие спецификации для каждого пакета работ (конечный результат, качество, промежуточные результа ты, расписание, бюджет) устанавливаются в ходе переговоров менеджера про екта с функциональным руководителем или его представителем, а именно с функ циональным лидером проекта. Функциональный руководитель в пределах этих спецификаций отвечает за детальное планирование, функциональную полити ку и процедуры, качество и обеспечение проекта персоналом с должным уров нем навыков и подготовки. Полномочия функционального руководителя более традиционны и лучше вос принимаются сотрудниками функционального подразделения, которые в любом случае являются его непосредственными подчиненными. Однако многие функ циональные руководители с трудом привыкают разделять свои обязанности и полномочия с менеджерами проектов и допускают их “вторжение” на терри торию своих функциональных подразделений. Обязанности и полномочия функциональных лидеров проекта В любом отдельно взятом проекте будет существовать ряд функциональных ли деров, задачи которых состоят в объединяющем руководстве работами по про екту в пределах функций или подфункций, за выполнение которых они отвеча ют (маркетинг, инжиниринг, тестирование, изготовление, производство и т.д.). Каждый функциональный лидер проекта объединяет работу команды проекта в рамках своей отдельной функции, менеджер проекта объединяет работу по всем функциям на уровне проекта, а функциональный руководитель объединя ет работу по всем проектам в рамках своего функционального подразделения, осуществляя ежедневное руководство функциональными лидерами проектов. Функциональный лидер проекта (называемый иногда и по другому) – это клю чевая фигура для успешного выполнения проекта в матричной организации: на этом сотруднике сосредоточены все операции, выполняемые по проекту, на 133 Функциональные руководители и лидеры проекта, лидеры пакетов работ который он назначен, в рамках функциональной специализации. Функциональ ный лидер проекта – это alter ego своего начальника, в роли которого обычно выступает руководитель подразделения, и на нем лежит распределение всех за дач внутри функционального отдела. Его обязанности не учитывают линии су бординации в подразделении, а ориентированы в первую очередь на обеспече ние максимальной поддержки проекта. В круг задач функционального лидера входят активное планирование и контроль усилий, предпринимаемых функци ональным подразделением в рамках проекта. По сути, данное лицо является “мини менеджером” проекта на уровне своего функционального отдела. Полномочия функционального лидера проекта делегируются ему руково дителем функционального подразделения и основываются на документации, определяющей процесс управления проектами в организации. Функциональ ный лидер руководит лидерами пакетов работ (задач) в пределах функциональ ного подразделения. Ниже перечислены некоторые разновидности должности функционального лидера проекта, для каждой из которых существует свое название: • инженер проекта, объединяющий инженерные аспекты всех или некоторых проектов; • ведающий планированием, составлением расписания, контролер проекта, бюджетированием, мониторингом и ведением отчетности по проекту; • бухгалтер проекта, в ведении которого находится отчетность по использо ванию средств и ресурсов; • инженер по стоимости проекта, занимающийся контролем стоимости проекта; • администратор по контрактам проекта; • агент по поставкам и снабжению проекта; • (координатор ; производственный координатор проекта по производству) • директор по вводу в эксплуатацию, занимающийся вводом в эксплуатацию и испытаниями. Обязанности и полномочия лидеров пакетов работ Лидер пакета работ или задач координирует труд отдельных лиц, выполняющих работы в составе данного пакета – наименьшего элемента, для которого осу ществляются планирование и контроль в рамках единого плана проекта. Лидер пакета работ (иногда эта должность называется иначе) выполняет следующие обязанности: • разработка и актуализация планов пакета работ для его исполнения; • разработка технических указаний по выполнению пакета работ; 134 Роли в управлении проектами • разработка детальных расписаний и бюджетов пакета работ, сохраняющих тесную взаимосвязь с общими планами, расписаниями и бюджетами проекта; • контроль исполнения пакета работ и соответствующая отчетность. 4.9 АЛЬТЕРНАТИВНЫЕ СПОСОБЫ НАЗНАЧЕНИЯ НА РОЛЬ Наиболее эффективное управление проектом обусловлено назначением на долж ность менеджера проекта одного лица; при этом менеджер проекта должен вы полнять свои обязанности с самого начала и до окончательного завершения проекта. Однако по некоторым причинам это далеко не всегда возможно. На пример, большое количество проектов проходит фазу концепции и определе ния, не достигая фазы завершения. Количество проектов, которые предлагают ся потенциальным заказчикам (окончание фазы определения), в несколько раз больше, чем количество проектов, финансируемых ими. Также не всегда полу чается назначить менеджера проекта на каждое предложение и ожидать, что именно этот сотрудник сумеет довести его до конца в случае получения заказа. При достаточно большой длительности проекта (более 18 месяцев) нужды орга низации (да и личности) часто требуют повышения менеджера проекта в долж ности или передачи ему других полномочий до завершения проекта. Иногда вследствие недопонимания или недооценки важности роли менеджера проекта эта роль без достаточных на то оснований или по неведению передается несколь ким лицам, которые работают в разных подразделениях организации. Наибо лее частые проблемы и самые эффективные их решения рассматриваются ниже. Непрерывность ответственности менеджера проекта Эффективность работы менеджера проекта напрямую зависит от его непрерыв ной ответственности на протяжении всего жизненного цикла проекта. Выше уже обсуждались трудности на пути к достижению такой ситуации. Когда не прерывность ответственности по проекту нарушается, то текущий менеджер проекта, зная, что в определенный момент он передаст свой проект другому че ловеку, с высокой вероятностью скроет существующие проблемы и задержит при нятие важных решений, предоставив своему последователю разбираться с ними. В конце концов, менеджер проекта, замыкающий цепочку, наследует весь груз неразрешенных проблем, которые удалось бы с гораздо меньшими усилиями устранить на более ранних стадиях проекта. Избежать вышеописанных трудностей можно следующими способами: • как можно скорее поставить в известность потенциального менеджера проекта о намечаемом к исполнению проекте и поручить ему мониторинг 135 Альтернативные способы назначения на роль операций, насколько позволяет его занятость, до окончательного подписа ния контракта; • в организации, где существует отдел управления проектами, назначить ме неджера проекта, который будет представлять отдел на переговорах по всем крупным предложениям. Этот сотрудник будет, по крайней мере, оценивать предложения с точки зрения управления проектами. Он также сможет пре доставить назначенному менеджеру проекта всю необходимую информа цию после заключения контракта; • делая окончательный выбор, добиться от назначенного сотрудника и от ру ководства ясного понимания того факта, что менеджер проекта будет оста ваться на своей должности до завершения работы; • избегать практики передачи ответственности из отдела в отдел по мере перехода проекта из одной фазы в другую. Если менеджера проекта также переводят из одного отдела в другой, то непрерывность личной ответствен ности сохраняется; • установить с помощью файла проекта (см. главу 10) хорошо документиро ванную историческую базу проекта, включающую планы и показатели их выполнения, с целью передачи этой документации новому менеджеру про екта при его замене до завершения проекта; • ввести, по возможности, практику “перекрытия”, назначая менеджером нового проекта (с неполной занятостью и последующей полной занятос тью) менеджера текущего проекта, который близок к завершению, а пото му требует меньших затрат времени. Полная и частичная занятость Должность менеджера крупного проекта требует назначения одного лица с пол ной занятостью. Меньшие проекты не требуют, а потому и не оправдывают пол ной занятости; тем не менее необходимость этой должности во многих случаях сохраняется. Некоторые из наиболее распространенных причин неэффективного управ ления проектами заключаются в назначении менеджеров проекта с частичной занятостью. Порой менеджеров проекта просто не хватает, что приводит к не обходимости поиска различных компромиссов. Проекты, назначенные на исполнение функциональным менеджерам Руководителю, выполняющему функциональные обязанности с полной занятос тью, можно дополнительно поручить роль менеджера проекта по одному или нескольким проектам. В общем, такое назначение неэффективно, за исключением 136 Роли в управлении проектами тех случаев, когда от 80% до 90% работ по проекту выполняется персоналом, подотчетным именно этому менеджеру по штатному расписанию. Подобное со вмещение должностей может вызвать нехватку рабочего времени сотрудника, в результате чего начнет “хромать” исполнение функциональных обязанностей или обязанностей по проекту. Еще один конфликт возникает, когда менеджер в первую очередь отвечает за работу в отделе, а не в проекте. При любых неуря дицах прежде всего страдает проект. Если к работе над проектом в качестве функ циональных менеджеров привлекаются коллеги менеджера проекта, они пони мают, что в случае успеха помогут именно ему (а не себе) продвинуться по службе. С другой стороны, если проект хотя бы частично потерпит неудачу, то шансы на повышение менеджера проекта станут ниже; соответственно, уменьшится и его преимущество перед внутренними конкурентами. Когда к частичной занятости добавляется рассмотренная выше практика передачи проекта из отдела в отдел, соперничество усиливается из за ощущения (иногда весьма обоснованного), что каждый менеджер передает вместе с проектом множество нерешенных проблем. Последний назначенный менеджер проекта может оказаться лицом к лицу с не разрешимой задачей – в этом случае чрезвычайно трудно определить человека, виноватого в неудаче проекта. Наконец, поскольку характеристики проекта отличаются от характеристик функциональной организации (см. главу 2), большинству менеджеров трудно в течение каждого дня переключаться с управления проектами на функциональ ное управление. Это создает необычайно сильную стрессовую ситуацию как для менеджера, так и для команды проекта. Несколько проектов, переданных в управление одному менеджеру с полной занятостью В тех ситуациях, когда для каждого проекта невозможно назначить менеджера с полной занятостью или когда из нескольких проектов ни один не требует такого назначения, существует более эффективное решение. Оно заключается в пере даче одному менеджеру с полной занятостью нескольких проектов. Преиму щество такого подхода в том, что сотрудник непрерывно исполняет роль менед жера проекта и не отвлекается на выполнение функциональных обязанностей. Он отвечает в первую очередь за свои проекты и может быстрее совершенство вать профессиональные качества менеджера проекта. В процессе планирования, контроля, оценки и руководства одним проектом менеджер проекта при контактах с функциональными менеджерами и лидера ми команд часто может уделять внимание работе в других проектах. При этом экономится время функциональных менеджеров. В этом случае межпроектные конфликты могут быть разрешены непосредственно менеджером проекта. В ре зультате уменьшается и соперничество между функциональными менеджерами. 137 Альтернативные способы назначения на роль Разделение обязанностей менеджера проекта Обязанности менеджера проекта часто делит несколько сотрудников. Иногда даже трудно ответить на вопрос: “Кто в действительности является менедже ром проекта?”. Обычно фактический менеджер проекта – тот, кому адресуются отчеты. Для него зачастую оказывается неожиданностью тот факт, что он вы ступает в роли менеджера проекта, поскольку в существующей отчетной иерар хии организации этот руководитель может находиться несколькими уровнями выше. Чаще всего встречающийся метод разделения обязанностей по проекту – это поручение одному лицу технических (производственных) обязанностей, друго му – ответственности за выполнение расписания проекта, а третьему – контро ля стоимости проекта. Часто четвертому лицу поручается администрирование контракта, пятому, возможно, – обязанности по первичным контактам с клиен том, еще одному – решение производственных проблем. Такое деление обязанностей менеджера проекта является, вероятно, наибо лее распространенной причиной неудачи проекта. Если одно лицо не объеди нит операции инженера проекта, контролера, администратора по контрактам и т.д., то оценить эффективность проекта, определить текущие и будущие про блемы и выполнить корректирующие действия, чтобы обеспечить своевремен ное исполнение проекта, становится невозможно. Менеджер проекта действительно не может выполнять все необходимые опе рации планирования, контроля и оценки. Точно так же он не сумеет провести все технические операции. В его распоряжение должны быть предоставлены службы поддержки управления проектами, руководство которыми и контроль которых он будет осуществлять. Опасность, однако, заключается в том, что, даже если службы поддержки существуют, при отсутствии назначенного менеджера проекта они не могут использоваться в полной мере. Сохранение роли менеджера проекта за генеральным менеджером В определенных ситуациях, таких как наличие одного чрезвычайно важного крупного проекта, роль менеджера проекта может оставить за собой генераль ный менеджер. Это может также оказаться уместным в ситуации с несколькими небольшими проектами (см. главу 9). В этих случаях для планирования и поддер жания информационного взаимодействия в проекте желательно назначить ко ординатора проекта. Координатор проекта отчитывается непосредственно пе ред генеральным менеджером; в его обязанности входит объединение функций поддержки управления проектами. 138 Роли в управлении проектами Исполнение роли менеджера проекта в мультипроектных ситуациях Многие организации отвечают за исполнение одного двух больших проектов и множества малых, и в таких ситуациях роль менеджера проекта может остаться на уровне линейного управления. Однако в этом случае необходимо четко опре делить ответственность за объединяющее долгосрочное планирование и управ ление всеми проектами, чтобы обеспечить поддержку и координацию деятельнос ти всех функциональных менеджеров. Эта ответственность может быть передана человеку, который занимает должность, называемую по разному, в том числе “ме неджер по планированию”, “менеджер по контролю за операциями”, “координа тор проекта”, “контролер проекта” и т.д. (см. главу 8). 4.10 ФАКТОРЫ, ОПРЕДЕЛЯЮЩИЕ ВЫБОР МЕНЕДЖЕРОВ ПРОЕКТА Эффективность работы менеджера проекта в гораздо большей степени, чем других руководящих сотрудников ниже уровня генерального менеджера, зависит от его личных опыта и качеств. Способность эффективно работать и поддерживать от носительно неформальные отношения с другими менеджерами, приобретать авто ритет, объединять действия многих людей и соответствующим образом разрешать конфликты – все это имеет большое значение для успешного управления проектом. Ключевые личные качества менеджера проекта Ниже перечислены некоторые ключевые личные качества наиболее преуспева ющих менеджеров проекта: • гибкость и приспособляемость; • инициативность и качества лидера; • агрессивность, уверенность в себе, умение убеждать, способность ясно вы ражать свои мысли, честолюбие, активность, энергичность; • умение общаться, вести посредничество и объединять усилия; • широкий круг личных интересов, кругозор, способность к общему (неспе циализированному) подходу; • уравновешенность, энтузиазм, воображение, непосредственность; • способность соблюдать баланс технических решений, временного, стоимост ного и человеческого факторов; • организованность и дисциплина; • способность и желание посвящать большую часть своего времени плани рованию и контролю; 139 Факторы, определяющие выбор менеджеров проекта • способность определить проблему и желание принимать решения; • способность правильно распорядиться своим временем. Навыки менеджера проекта Команда опытных профессионалов в области управления проектами разработа ла квалификационные требования к менеджеру проекта. Она пришла к заключе нию, что для успешного завершения проекта наиболее важны объединяющие навыки менеджеров проекта [3, p. 10]. На рис. 4.2 показаны эти квалификаци онные требования с акцентом на объединяющие навыки менеджера проекта. Наиболее важные и часто используемые менеджером проекта объединяющие навыки включают следующие: • целостность мышления; • системный подход; • гибкость, приспособляемость, открытость, непредвзятость; • способность устанавливать и соблюдать баланс приоритетов; • способности взаимодействовать с различными культурами (микро и мак рокультурами). Оставшиеся четыре области навыков показаны на рис. 4.2: Навыки Умение общаться управления проектами. с людьми и работать Методы и инструменты в команде ъединяющие Об Менеджер проекта навыки Технические Базовые деловые (специальные) и управленческие навыки навыки Знание роли спонсора проекта Знание ролей и осведомленность об окружении проекта Ðèñóíîê 4.2. Ïðîôèëü íàâûêîâ ìåíåäæåðà ïðîåêòà. Èñòî÷íèê: [3, p. 10]. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðîâ 140 Роли в управлении проектами • навыки в области методов и инструментов управления проектом представляют собой классическую практическую деятельность в управлении проектами, которая описана как в данной работе, так и в других источниках по управ лению проектами. Эти навыки относятся к планированию, организации, мониторингу и контролю над проектом; • навыки работы с командой и отдельными сотрудниками включают в себя об щие навыки межличностных отношений, которые требуются для руковод ства, навыки общения, координации, мотивации и сплочения команды про екта; • включают в себя инженерную, на технические (специализированные) навыки учную, экономическую, математическую и другую квалификацию, относя щуюся к конкретной дисциплине, которая является базисной для личного опыта менеджера проекта; • основные деловые и управленческие навыки подразумевают общее понимание того, как действует бизнес или отрасль, как осуществляется управление ком паниями и другими организациями, а также наличие знаний об основных методах планирования, формирования бюджета, финансирования и управ ления организацией. Определенный минимальный уровень знаний и навыков в последних двух об ластях (технические навыки и навыки в области бизнеса и управления) необхо дим для любого сотрудника, претендующего на должность менеджера проекта. Три другие области навыков (навыки работы с командой и отдельными людьми, знание методов и инструментов управления, а также объединяющие навыки) зачастую изучаются на практике. Идентификация этих пяти областей навыков может быть полезной при структурировании учебного материала, используемо го в подготовке менеджеров проекта и их команд. Обучение и сертификация менеджеров проектов и специалистов по управлению проектами Многие университеты, институты, центры обучения, профессиональные ас социации и консалтинговые фирмы предлагают лекции, семинары и курсы по различным аспектам управления проектами, проводимые в загородных домах отдыха, на рабочем месте или через Internet. Подобные предложения ориен тированы главным образом на менеджеров программ и проектов, а также на других специалистов, работающих в сфере управления проектами. Информа ция о курсах может быть получена из Internet по ссылкам, приведенным в гла ве 1 либо найденным с помощью поисковых сайтов. В последнее время ряд университетов во всем мире выдает сертификаты по окончании таких про грамм обучения или присваивает степень в области управления проектами. 141 Факторы, определяющие выбор менеджеров проекта Институт управления проектами (Project Management Institute, PMI), нацио нальные организации, входящие в Международную ассоциацию управления про ектами (International Project Management Association, IPMA) и другие ассоциа ции проводят сертификационные программы в области управления проектами. Например, PMI выдает лицам, продемонстрировавшим определенные теорети ческие знания, практические навыки и опыт в управлении проектами и при этом сдавшим всесторонний экзамен, основанный на PMI PMBOK [88], сертификат специалиста в области управления проектами (project management professional, PMP). Британская ассоциация управления проектами (British Association of Project Management, APM) предлагает существенно иной тип сертификации, от ражающий скорее способности человека, чем его знания. Несмотря на присущие этим сертификатам ограничения, многие организации рассматривают наличие такого документа как необходимое условие для карьерного роста человека, за нятого в управлении проектами. За более подробной информацией о проце дурах сертификации можно обратиться к Internet сайтам, ссылки на которые приведены в главе 1. Источники кадров На должность менеджера проекта чаще всего назначают сотрудников других про ектов, менеджеров линеек продуктов, функциональных менеджеров и функцио нальных специалистов (изнутри или извне головной организации). Лучший источник – персонал других проектов при условии, что менеджеры проекта работали удачно и успешно завершили проект. Однако на менеджеров проекта существует постоянно возрастающий спрос, и на каждый новый проект бывает трудно найти подходящего человека, только что закончившего очеред ную работу. Возможно, второй по значимости источник кадров – персонал, занимающий ся планированием, оценкой, составлением расписаний и контролем (то есть пер сонал, осуществляющий поддержку проектов). Такие специалисты на своем опы те знают, каковы требования к планированию и контролю проекта, а кроме того, работая в тесном контакте с менеджерами программ и проектов, имеют пред ставление об этой должности. Не каждый такой специалист по своим личным качествам годится в менеджеры проекта, однако многие способны справиться с подобной работой. Эти сотрудники знакомы с программным обеспечением пла нирования и управления проектами и знают, как использовать его наилучшим образом, что, несомненно, приносит им немалую пользу, если они получают долж ность менеджера проекта. Иногда назначение на должность менеджера проекта с полной занятостью получает функциональный менеджер. Если он был менеджером низшего или среднего звена, то среда проекта будет для него незнакомой. При условиях, что у такого менеджера нет соответствующих личных качеств, он не получил 142 Роли в управлении проектами достаточной подготовки и не заручился квалифицированной помощью, ему бу дет очень трудно выполнять свои обязанности. Часто на должность менеджера назначаются функциональные специалисты проекта, и в этой роли они могут добиться значительных результатов. Наиболь шая трудность, как правило, заключается в переходе от выполнения какой либо работы к управлению работой других людей. Чтобы с максимальной эффектив ностью выполнять свои обязанности, специалисту в роли менеджера проекта необходимо не преследовать свои узкоспециальные цели, а выработать навыки обобщения. В небольших проектах это зачастую неизбежно и требует хорошего понимания различий между двумя названными ролями. Выбор менеджера проекта Назначение лица на должность менеджера проекта не является односторонней процедурой, осуществляемой генеральным менеджером или другим менеджером высшего звена. Кандидату нужно ясно и точно объяснить его должностные обя занности и описать сам проект; при этом он должен самостоятельно, без при нуждения принять новую роль или отказаться от нее. Кандидат на должность, вероятно, не станет эффективным менеджером проекта без достаточной лич ной мотивации. Необходимо приложить все усилия, чтобы подобрать сотруд ника, который будет выполнять свои обязанности вплоть до самого завершения проекта. 4.11 КАРЬЕРНЫЙ РОСТ В УПРАВЛЕНИИ ПРОЕКТАМИ По мере осознания важности назначения менеджера проекта становится явной и необходимость более формализованного подхода к карьерному росту. Посколь ку проекты, в конце концов, завершаются, то назначения в управление проекта ми менее надежны с карьерной точки зрения, чем функциональные назначения. Часто самых квалифицированных сотрудников не удается привлечь к выполне нию проекта только потому, что, уходя из функционального отдела, они риску ют ради неопределенного будущего, которое их ждет по окончании проекта. Управление проектами все теснее включается в постоянную функциональ ную структуру многих организаций. Это обеспечивает основу, на которой стро ятся непрерывность проектных назначений, долгосрочные перспективы для участвующих в проектах сотрудников и более эффективные программы карь ерного роста. Карьерный рост менеджеров проектов Навыки интегрирующей работы менеджеров проектов развиваются в процес се реальной работы над проектами. Однако это развитие можно ускорить, 143 Карьерный рост в управлении проектами а эффективность работы менеджера – повысить путем соответствующей подго товки на семинарах и ознакомления с методами работы преуспевающих менед жеров проекта. Поскольку проекты бывают самых разных размеров, можно назначать менее опытных сотрудников в небольшие или менее сложные проекты. Если резуль тат будет успешным, зарекомендовавшего себя сотрудника можно перевести в следующий, более крупный проект. Оценка производительности и карьерный рост Оценить производительность менеджера проекта зачастую труднее, чем произ водительность других менеджеров. Это связано с тем, что на проект влияет мно жество факторов, по отношению к которым у менеджера проекта имеются не значительные прямые (законные) полномочия. Исключительный успех проекта может являться или не являться прямым результатом усилий менеджера про екта. Вполне вероятно, что неудачным проектом руководил лучший менеджер. В настоящее время в области управления проектами не разработаны формаль ные или системные методы оценки производительности менеджера проекта, но очевидно, что эта оценка значительно влияет на общие результаты проекта. Другой источник потенциальных проблем – постоянные назначения сотрудни ка на должность менеджера различных проектов и влияние, которое оказали на его карьеру два три года работы в этой должности. Преуспевающие менеджеры проектов могут чувствовать себя даже более неловко, поскольку соответствующие их квалификации должности руководителей высшего звена освобождаются не часто. Если к управлению проектами нужно привлекать лучших сотрудников, выс шее руководство должно обратить внимание на эту проблему. Возможное решение данного вопроса обеспечивают два фактора. Во первых, по мере роста числа проектов и осознания их важности спрос на менеджеров проекта возрастает. Решению задачи также способствуют гибкость в назначе нии менеджеров проекта из разных отделов организации, при условии что про екты однотипны и не существует значительных трудностей в языковом обще нии. Если в одном отделе имеется способный и свободный менеджер проекта, то при необходимости его можно перевести в другой отдел. Во вторых, консолидация функций управления проектами в организации, обычно выражаемая в создании офиса управления проектами, может оказаться полезной при “перекрытии” назначений в проект, развитии навыков менедже ра проекта и непрерывности будущих назначений. Привлечению сотрудников с нужными способностями способствует также признание сферы управления проектами как перспективной в отношении по тенциального карьерного и профессионального роста. Схожесть работы менед жера проекта и руководителя высшего звена приводит к осознанию того, что опыт работы над проектом играет важную роль в развитии навыков, необходи мых для высшего уровня управления. 144 Роли в управлении проектами Специалисты по управлению проектами В последнее время все более востребованными становятся специалисты по управлению проектами, занятые в процессах планирования, анализа рисков, оценивания, составления расписания, бухгалтерского учета, контроля стоимо сти и конфигурации, ведения отчетности и выполняющие другие функции обес печения/поддержки для больших, сложных программ и проектов. Именно из среды таких специалистов можно отбирать новых менеджеров проектов. 4.12 ВЫВОДЫ Понимание и правильное использование должностей с объединяющей ответ ственностью – жизненно важный элемент успешного управления сложными про ектами в больших организациях. Если некоторые из ключевых интегрирующих должностей остаются незанятыми или неправильно определенными, вполне возможны тяжелые конфликты и значительное падение эффективности рабо ты. Даже самая совершенная информационная система управления проектами не компенсирует ошибки в назначении людей на такие должности. Т РЕБОВАНИЯ ВЫСШЕГО РУКОВОДСТВА Должности с интегрирующей ответственностью в управлении проектами Для того чтобы достичь высокой эффективности управления проектами, исполнительный директор должен добиться удовлетворения следующих требований: • все вышерассмотренные должности с объединяющей ответственнос тью четко понимаются, и на них назначены правильно подобранные люди; • генеральный менеджер понимает и выполняет свои обязанности по отношению к офису проекта; • в каждый большой проект назначается спонсор, которому даны соот ветствующие указания для эффективного исполнения этой роли; • в организации работает опытный директор по управлению проекта ми, отчитывающийся перед ее высшим руководством; 145 Карьерный рост в управлении проектами • управление проектами и занятый в нем персонал опираются на су ществующую в компании базу, роль которой может выполнять офис управления проектами (см. главу 8); • все менеджеры мультипроектов и программ проходят соответствую щую подготовку, позволяющую им наиболее эффективно выполнять свои функции; • отдавая распоряжения членам команды проекта, каждый менеджер проекта учитывает линии функциональной субординации; • функциональные руководители и лидеры проекта также принимают во внимание линии проектной субординации. 5 « « » » Объединяющие и прогнозирующие планирование и контроль проекта С истемы, инструменты и методы объединяющих и прогнозирующих пла нирования и контроля проекта (Integrative and Predictive Project Planning and Control, IPPPC) – центральный аспект дисциплины управления проектами. “Объединяющие” (integrative) означает, что все фазы проекта и все информаци онные составляющие, которые будут рассмотрены ниже, логически взаимосвя заны. Прогнозирующие (predictive) означает, что система прогнозирует развитие ситуации в будущем, основываясь на текущих планах и оценках и принимая во внимание непрерывно обновляемые данные о фактических производительнос ти и расходах. Прогнозирование заключается в том, что система постоянно об новляет результирующие данные о сроке завершения и стоимости на момент завершения проектов и сравнивает их с утвержденными расписаниями и бюд жетами. Задача прогнозирования состоит в том, чтобы заблаговременно пред сказать вероятность получения нежелательного результата, тем самым предо ставив достаточный запас времени для принятия мер по коррекции ситуации во избежание этого нежелательного оборота дел. 5.1 ТРЕБОВАНИЯ К IPPPC Вторая ключевая концепция управления проектами требует выполнения следу ющих условий: • каждый проект должен планироваться и управляться во взаимосвязи с дру гими проектами; 147 Требования к IPPPC • в рассмотрение должны быть включены все участвующие в проектах функ циональные подразделения и организации; • IPPPC должны охватывать все фазы жизненного цикла каждого из выпол няемых проектов: фазу принятия концепции, фазу определения, фазу про ектирования (дизайна), фазу разработки/производства/строительства, монтажа/пробных испытаний/ввода в эксплуатацию, фазу закрытия; • должны быть использованы все информационные составляющие (распи сание, ресурсы, расходы, технические аспекты, риски), имеющие значе ние в конкретной ситуации, а также 1) отчеты о распределении ресурсов и управлении ими и/или 2) методы стоимостного анализа [38] с необходи мыми отчетами об отклонениях по стоимости и по срокам; • управление проектами должно осуществляться с помощью программных пакетов и процедур, способных использовать современные Internet техно логии; • надлежит связывать все проекты внутри программ и портфелей проектов таким образом, чтобы информация об их исполнении могла быть сведена воедино и представлена руководству для выработки соответствующих стра тегических указаний по всем проектам. Необходимость использования единой информационной системы для управления проектами Большинство организаций сталкивается с необходимостью планировать и выпол нять множество проектов одновременно, используя общий пул ресурсов, что при водит к необходимости применять для всех таких проектов общую информаци онную систему планирования и управления. Эффективное решение этой задачи возможно при использовании современных компьютерных систем интегрально го управления проектами. Обычно такие системы состоят из взаимосвязанных проектно ориентированных подсистем для всех и каждого проекта в организа ции. Использование подобных систем позволяет получить следующие выгоды: • на систематической основе определять и контролировать цели и содержа ние проекта; • оценивать риски отдельных проектов и упреждающе управлять ими в их связи с общими рисками портфелей проектов; • определять и контролировать спецификации, качество, конфигурацию и количество (содержание) промежуточных и конечных результатов про екта; • на систематической основе, используя иерархическую структуру проекта/ работ (ИСП/ИСР), определять и контролировать содержание проекта и работ, которые должны быть выполнены в его рамках; 148 Объединяющие и прогнозирующие планирование и контроль проекта • оценивать трудозатраты, затраты материалов и иные затраты, связанные 1) с каждым результатом каждого проекта и соответствующим ему элемен том ИСП/ИСР, 2) с каждым совокупным элементом ИСП/ИСР; • планировать и контролировать последовательность и сроки получения всех результатов и выполнения всех элементов работ, используя при этом глав ное расписание проекта и совокупность иерархически подчиненных ему более детальных частичных расписаний; • утверждать и контролировать расходование фондов, рабочего времени и других ресурсов, необходимых для выполнения проекта; • предоставлять менеджерам проектов, руководителям подразделений (от делов), функциональным руководителям работ и руководителям пакетов работ информацию о 1) фактической производительности и фактических расходах, 2) прогнозах на будущее; • непрерывно оценивать фактическую производительность, а также пред видеть и уменьшать проблемы, касающиеся содержания проекта, качества работы, расходов, сроков и риска, при необходимости используя в управ лении проектами методику освоенного объема (Earned Value Project Manage ment); • предоставлять заказчикам и руководству информацию о текущем состоя нии проекта и прогнозе на будущее касательно содержания, качества, рас ходов, расписания, в том числе отчеты по завершении проекта. Бывают ситуации, когда требования заказчика или, например, работа в усло виях совместного предприятия обусловливают применение для конкретного проекта определенной системы планирования и управления, отличающейся от системы, применяемой в корпорации для других проектов. В таких случаях эта отдельная система должна обладать способностью связываться с корпоративной и передавать ей всю информацию о ходе исполнения “своего” проекта (особен но касающуюся соблюдения сроков и использования ресурсов), тем самым да вая возможность составить целостную картину в масштабах всей организации. 5.2 ОПРЕДЕЛЕНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ УПРАВЛЕНИЯ ПРОЕКТАМИ Существует много определений и описаний систем управления проектами. Кле ланд (Cleland) дал общее определение системы управления проектами, состоя щей из семи подсистем [16, p. 12]: • подсистема поддержки организационных процедур; • подсистема контроля проекта; 149 Определение информационных систем управления проектами • информационная подсистема управления проектами; • подсистема система технологий и методологий; • подсистема культурного окружения; • подсистема планирования; • подсистема человеческих ресурсов. Тьюман (Tuman) приводит подробные описания и анализы информационных систем управления и контроля проектов с нескольких точек зрения, отражаю щих огромный опыт автора по части разработки и внедрения компьютерных систем планирования и управления [104, pp. 652–691]. Он определяет “инфор мационную систему управления и контроля проектов” общего назначения, по казанную в табл. 5.1, которая в дополнение к системе информационного обеспе чения и контроля проекта включает как систему обеспечения технической информации и контроля, так и систему информации и контроля рисков. Одна ко любая информационная система, вне зависимости от определения, состоит из следующих компонентов: • документов (хранилищ информации); • для подготовки, ведения, хране процедур, процессов и программных пакетов ния, передачи и утилизации документов, используемых для создания, пла нирования, оценивания и исполнения проектов в конкретной организации. В табл. 5.2 представлены документы, обычно используемые в ходе планирова ния проекта, утверждения работ, контроля и ведения отчетности. Эти докумен ты рассмотрены в главах 10, 12 и 14. Для подготовки и использования каждой такой бумаги в соответствии со спецификой каждой категории проектов не обходимы специальные процедуры, детально описанные в документации по управлению проектами в соответствующей отрасли. Последние десять лет ста ли активно развиваться и процветать компьютерные системы, включающие в себя практически все эти документы и процедуры, что сделало возможным ис пользование одной интегральной информационной системы для управления все ми проектами в организации. Степень детализации документов для планирования проекта, утверждения работ, контроля и ведения отчетности Определение необходимой и разумной степени детализации документов все гда составляло фундаментальную проблему на пути повышения эффективнос ти управления проектами. Существующие системы, очевидно, способны рабо тать с неограниченной степенью детализации, но люди, занятые выполнением 150 Объединяющие и прогнозирующие планирование и контроль проекта Òàáëèöà 5.1. Îïðåäåëåíèå èíôîðìàöèîííîé ñèñòåìû óïðàâëåíèÿ è êîíòðîëÿ ïðîåêòîâ. Èñòî÷íèê: [104, p. 673]. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðà Система обеспечения Система обеспечения Система обеспечения технической информации информации о проекте информации о рисках и контроля и контроля проекта и контроля рисков Модуль управления Модуль разработки Модуль надежности инжинирингом иерархической структуры Модуль эксплуатационной проекта/работ Модуль управления надежности снабжением Модуль планирования (ремонтопригодности) и составления расписаний Модуль управления Модуль обеспечения строительством Модуль управления безопасности или производством стоимостью: • Модуль управления оценка стоимости; испытаниями • поддержка оценки Модуль управления стоимости; конфигурацией • команда и персонал; • общие затраты материала; • общие трудозатраты; • исходные документы; • контроль стоимости; • прогноз стоимости Бухгалтерский модуль Модуль ввода данных Модуль интерактивных запросов Модуль обеспечения планирования (оценивания рисков) Модуль обеспечения качества расчетов, составлением отчетов и оцениванием информации, могут посвятить этой деятельности только ограниченное время и, кроме того, способны опери ровать лишь ограниченными объемами данных. С этой проблемой была всегда связана другая, не менее важная: как, не потеряв эффективности, осуществить интеграцию системы информационного обеспечения и управления проектами со всей остальной деловой информацией и остальными системами в организации? 153 Компьютерные информационные системы управления проектами 5.3 КОМПЬЮТЕРНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ (ИСУП) С наступлением компьютерной эры и с разработкой и внедрением в 50 х годах 1 различных методов планирования, таких как сетевые методы PERT/CPM/PDM , компьютерные приложения для планирования, календарной привязки и кон троля проектов стали и остаются важными инструментами управления проек тами. В течение многих лет в сфере управления проектами существовала тен денция к отождествлению информационных систем управления проектами с такими компьютерными приложениями и даже к отождествлению таких при ложений с управлением проектами как с дисциплиной. Сегодня почти все прак тикующие специалисты осознают, что управление проектами – это нечто гораз до большее, чем просто компьютерные приложения. Компьютеры и программы – важные элементы сегодняшних ИСУП. Необхо димость автоматизации обработки больших и взаимосвязанных объемов инфор мации, характерных для управления крупными проектами или мультипроектами в сегодняшнем динамичном высокотехнологичном окружении, сделала возмож ными разработку и эффективное использование интегральных информационных систем управления проектами. Но только в последние годы с развитием систем, использующих Internet технологии, удалось осуществить полную автоматизацию управления всеми проектами в рамках единой интегральной компьютерной сис темы. Создание, хранение, выборка и обработка электронных документов и информации в ИСУП Все документы, перечисленные в табл. 5.2, могут быть созданы, сохранены, об работаны и найдены в цифровом формате с использованием современных про граммных пакетов управления проектами, выполняемых на той или иной вы числительной базе – будь то настольный компьютер, ноутбук или карманный компьютер, подключенный к системе связи с Internet. Каким образом информа ция и документы используются менеджерами проектов и какие лица занимают остальные ключевые должности с интегральной ответственностью, подробно определяет процесс управления проектами в организации. 1 PERT – Program Evaluation Review Technique, метод оценки и анализа программ. CPM – Critical Path Method, метод критического пути. PDM – Precedence Diagram Method, вычисления на основе диаграмм предшествования. – Прим. ред. 154 Объединяющие и прогнозирующие планирование и контроль проекта Управление проектами с использованием Internet технологий Тиммонс (Timmons) утверждает – и приводит определенные доказательства – что “наш будущий успех (как менеджеров проекта) будет определяться тем, на сколько хорошо мы умеем пользоваться возможностями, предоставляемыми Internet” [103]. Разработка и внедрение полностью интегрированной ИСУП, использующей Internet технологии, в отдельно взятой организации сами по себе являются слож ным проектом. Тиммонс описывает логически непротиворечивый подход к раз вертыванию такой системы, обращает внимание на некоторые “подводные кам ни”, сопутствующие внедрению в некоей организации одной из коммерчески доступных систем, и описывает процесс создания такой Internet ориентирован ной системы в другой организации. Его разработка “базировалась на трех фун даментальных требованиях: формах переноса данных, связи данных и процессе авторизации”. Перенос данных предполагает размещение всей информации, за исключением графических объектов, в базах данных. Это означает разработку электронных форм, которые конвертируют представленные на бумаге данные в электронные базы данных, позволяя обмениваться информацией с помощью обычного Internet браузера. Связь данных возможна благодаря открытому стандарту базы данных, кото рый позволяет связываться программам различных производителей ПО. Это устраняет дублирование информации и повышает актуальность хранимых дан ных за счет выполнения специальных процедур проверки их состоятельности. Процесс авторизации контролирует доступ к базам данных, обеспечивает инфор мационные потоки к ним и от них, а также обеспечивает их надежность, контроли руя запросы критически важных данных с помощью электронных подписей. Среди множества преимуществ и выгод, которые сулит Internet ориентиро ванное управление проектами, Тиммонс называет ускорение процессов проек тирования, повышение качества отчетов, круглосуточную доступность храня щихся в Internet баз данных, улучшенный контроль исполнения базового плана проекта, наличие списка текучести рабочей силы по проекту (перечня недоде лок и отметок об их выполнении), упрощенную процедуру хранения и использо вания информации, предоставляемой поставщиками: чертежей, журналов ре гламентных работ, протоколов тестирования, руководств и т.д. Программное обеспечение распределенного управления проектами Internet ориентированное управление проектами приобретает известность как распределенное управление проектами (Distributed Project Management, DPM) 155 Компьютерные информационные системы управления проектами и в настоящее время представляет собой очень большой и быстрорастущий сег мент рынка. Огромное количество отраслей требует использования инструментов сотрудничества. Помимо IT организаций, пользователями инструментов сотрудничества являются и организации, не связанные с информационными технологиями (не IT организации), например архитектурные, инженерные, аэрокосмические, оборонные, энергетичес кие, здравоохранительные, фармацевтические, производственные, телекоммуника ционные и строительные. Исследование, проведенное фирмой Datatech (штат Массачусетс), занимающейся исследованиями в области маркетинга и новых технологий, показало, что поставщи ки, способные поставить на рынок технологии, обеспечивающие сотрудничество в рамках проектов, будут иметь преимущество перед конкурентами. По оценкам Datatech, рынок таких специализированных инструментов превысит к 2004 году 3 млрд. долларов. А прогноз для рынка средств распределенного управления проектами, сде ланный фирмой Collaborative Strategies LLC (штат Калифорния), говорит, что доходы от таких средств, как ожидается, составят к 2003 году 1,5 млрд. долларов. И хотя США находится в авангарде стран, внедряющих инструменты сотрудничества, Европа и Азия в настоящее время также демонстрируют свою заинтересованность в них. На рынке систем распределенного управления проектами в настоящее время вы рисовываются определенные тенденции. Так, наблюдается отход от сложных прило жений, базирующихся на настольных компьютерах, к простым использующим Internet технологии средствам, несмотря даже на тот факт, что налицо смещение интереса от локальных проектов к более сложным распределенным. [82, p. 2] Программные пакеты для управления проектами Наиболее подробный список доступных сегодня пакетов для управления проек тами – “Обзор пакетов для управления проектами”, выполненный PMI в 1999 году (PMI Project Management Software Survey, 1999; далее просто PMI Survey), – делит эти пакеты на несколько категорий, показанных в табл. 5.3, и соотносит их с соот ветствующими областями управления проектами, определенными в PMBOK. Каж дая категория подробно обсуждается ниже. Комплексные пакеты для управления проектами Комплексные пакеты для управления проектами, состоящие из нескольких со вместимых друг с другом модулей (причем любой обладает теми или иными воз можностями в каждой из перечисленных ниже категорий), были разработаны в различных отраслях. Наиболее активные заказчики таких пакетов – оборон ная и аэрокосмическая отрасли. Однако, несмотря на свое происхождение, боль шая часть пакетов вполне может быть применена и во многих других отраслях и областях деятельности. 156 Объединяющие и прогнозирующие планирование и контроль проекта Таблица 5.3. Категории программных пакетов и соотносимые с ними области в управлении проектами. Таблица подготовлена на основе бюллетеня Proceedings of the PMI 1999 Seminars & Symposium. – Philadelphia, PA, October 10–16, 1999. – Newtown Square, PA: Project Management Institute, p. 3. Количество программных пакетов, рассмотренных в каждой категории, указано в скобках в соответствии с перечнем, приведенным в PMI Survey (Приложение B). Категории не являются взаимоисключающими Категория Соотносимая с ней область программных пакетов в управлении проектами (согласно PMBOK) Комплексные пакеты (36) Все Управление процессами/содержанием (19) Управление интеграцией Управление расписанием (43) Управление временем Управление стоимостью (27) Управление стоимостью Управление ресурсами (27) Управление человеческими ресурсами Управление рисками и их оценивание (15) Управление рисками Управление коммуникацией (17) Управление коммуникацией Подкатегории: Графические расширения (21) Табели учета рабочего времени (25) Web издатели/Web органайзеры (15) Модули, входящие в состав комплексных пакетов, как правило, могут быть оценены отдельно друг от друга, однако основное преимущество такого пакета заключается в том, что все модули интегрированы в единую систему, благодаря чему обеспечивается информационный обмен между ними. Эти продукты могут быть использованы в любых организациях – от малых до крупных, выполняю щих любые проекты – от простейших до сложных. “Инженерные, научно иссле довательские, проектировочные компании, правительственные учреждения, фирмы по разработке программного обеспечения, медицинские организации, фирмы разработчики электронной техники, аэрокосмические и телекоммуни кационные компании, представители сферы услуг, консалтинговые фирмы, IT компании – все могут выиграть от применения комплексных пакетов для управления проектами. Некоторые из таких пакетов ориентированы на различные сегменты рынка, определяемые спецификой той или иной отрасли” [90, p. 15]. Ключевые характеристики комплексных пакетов для управления проектами: • возможность рассмотрения и учета всех фаз жизненного цикла проекта; • возможность управления всеми проектами на предприятии, причем ито говая информация по этим проектам может представляться в различной 157 Компьютерные информационные системы управления проектами форме (как ИСП/ИСР, в организационной форме, в виде схемы счетов или ином), задаваемой пользователем пакета; • возможность осуществления информационной поддержки стратегических решений; • возможность связи с другими информационными управленческими про граммами. Программное обеспечение для управления процессами/содержанием проекта Программные продукты, работающие с процессами, объединяют процесс управ ления проектами с рабочими процессами функциональных подразделений, участ вующих в выполнении проекта. Эти продукты могут быть применены к процессу и методологии управления проектами, а также объединять их с такими вспомога тельными методологиями, как, например, методология разработки продукта или процесс разработки программного обеспечения. “Поддержка управления проек тами может быть простой, предусматривающей лишь документирование методо логии и относящихся к делу материалов, или сложной настолько, чтобы включать в себя оценивание рисков, рассмотрение благоприятных возможностей для веде ния бизнеса, анализ окупаемости, протоколирование результатов, коммуникацию, оценивание и непрерывное улучшение методологии” [90, p. 83]. Ключевые характеристики программного обеспечения для управления про цессами/содержанием проекта: • представление процессов в виде блок схем (потоковых диаграмм); • одновременное использование вспомогательного программного обеспече ния и справочных материалов; • возможность предоставлять пользователям указания и помощь при освое нии ими новой организационной методологии; • автоматизированная связь с другими системами управления проектами. Программное обеспечение для управления расписанием Программные продукты данной категории, лежащие в основе многих прило жений для управления проектами, позволяют осуществлять планирование программ и проектов, построение расписаний, мониторинг и контроль от дельных проектов, программ и мультипроектов, а также всех проектов, вхо дящих в портфели или выполняемых в масштабах всего предприятия. “Ка лендарное планирование – насущная необходимость для проектов, которые выполняются во всех отраслях и сферах деятельности, поэтому программные 158 Объединяющие и прогнозирующие планирование и контроль проекта продукты данной категории не только широко используются, но и отличают ся тем, что их можно применить практически к любой отрасли бизнеса или любому проекту” [90, p. 121]. Ключевые характеристики программного обеспечения для управления рас писанием: • способность планировать и выстраивать во времени последовательности операций, используя методы CPM/PDM/PERT или диаграммы Гантта; • способность генерировать, основываясь на ИСП/ИСР, главные расписа ния и детализированные расписания более низких иерархических уровней; • способность выполнять вычисления критического пути; • возможность распределения и выравнивания ресурсов с требуемой сте пенью точности и детальности анализа; • способность отслеживать исполнение расписания на текущий момент и де лать прогноз на будущее, основываясь на нынешнем состоянии проекта и его базовом плане; • способность формировать отчеты об исполнении расписания, в том числе в форме диаграмм Гантта и сетевых диаграмм; • для некоторых программных продуктов – способность работать с операци ями критического пути, учитывая буферы и результаты вычислений кри тического пути, ограниченного ресурсами. Программное обеспечение для управления стоимостью Программные продукты для управления стоимостью варьируются от простей ших приложений, способных связываться с модулями отслеживания расходов продуктов предыдущей категории, до сложных пакетов, способных управлять всеми статьями расходов в течение всех фаз жизненного цикла проекта – от пер вичной оценки на концептуальной фазе до итоговой оценки и анализа на мо мент завершения. Ключевые характеристики программного обеспечения для управления сто имостью: • способность формировать цену предложения, основываясь на трудозатра тах по категориям, расценках, надбавках и оценочных объемах; • способность управлять бюджетом с контролем базового плана; • способность к прогнозированию, в частности, роста расценок (тарифов, ставок); • способность измерять производительность работы, в том числе освоенный объем; • способность анализировать отклонения по срокам и стоимости. 159 Компьютерные информационные системы управления проектами Программное обеспечение для управления ресурсами Система управления ресурсами приводит доступные человеческие и иные ре сурсы в соответствие требованиям к ресурсам и информирует менеджеров и специалистов по планированию о том, где и когда существуют или могут воз никнуть недостаток/избыток ресурсов. В продукты для управления ресурсами, перечисленные в PMI Survey (27 про дуктов) не включены приложения для управления ресурсами в масштабах пред приятия – Enterprise Resource Planning (ERP) Applications, которые позволяют интегрировать управление как задействованными, так и не задействованными в проектах ресурсами. ERP приложения разработаны с целью объединения всех бизнес функций в общую систему и могут быть применены к любому аспекту де ятельности предприятия: финансовому, маркетинговому, инженерному, произ водственному, пусконаладочному и др. Фирмы PeopleSoft, Oracle и SAP предла гают на рынке три наиболее известных пакета для управления ресурсами предприятия, каждый из которых имеет свои достоинства и недостатки. Про граммное обеспечение для управления проектами может быть интегрировано в любое из этих ERP приложений. Некоторые комплексные пакеты для управле ния проектами и некоторые системы для управления ресурсами, перечислен ные в PMI Survey, позиционируются как способные управлять ресурсами пред приятия самостоятельно. Однако вопрос о том, способны ли они управлять в масштабах предприятия значительными объемами ресурсов, не занятых в про ектах, требует отдельного изучения. Программное обеспечение для управления коммуникациями Эти программные средства обеспечивают накопление всей относящейся к про ектам информации и эффективную ее передачу менеджерам проектов и членам проектных команд. Ключевые характеристики программного обеспечения для управления ком муникациями: • способность генерировать отчеты о ходе исполнения проекта в натураль ных и стоимостных показателях, а также об исполнении расписания; • автоматизация процесса обработки и взаимодействия различных проект ных документов; • использование Internet технологий для информационного обмена между всеми членами проектной команды; • использование досок объявлений, системы сообщений и других способов взаимного информирования и уведомления членов команды. 160 Объединяющие и прогнозирующие планирование и контроль проекта Системы табельного учета рабочего времени (подкатегория программного обеспечения для управления коммуникациями) Учет рабочего времени, проведенного над выполнением тех или иных задач проекта, – крайне важная процедура в обеспечении качественного контроля проекта. Средства табельного учета облегчают эту процедуру, давая членам про ектной команды возможность вести протоколы и готовить отчеты о затрачен ном рабочем времени в электронной форме. Эти средства варьируются от про стейших до весьма и весьма сложных. Ключевые характеристики систем табельного учета рабочего времени: • возможность составления и ведения членами проектных команд “списков предстоящих дел и задач” в электронной форме; • возможность аудита изменений, вносимых в листки табельного учета; • возможность взаимодействия с другими программными пакетами управле ния проектами, позволяющая автоматизировать корректировку расписания проекта; • возможность взаимодействия с финансовыми системами предприятия; • способность генерировать отчеты для членов проектной команды и руко водства в форме, задаваемой пользователем. Графические расширения (подкатегория программного обеспечения для управления коммуникацией) Программные средства этой категории принимают на вход данные, выдаваемые другими пакетами, и представляют их в графическом формате, выбранном пользователем. Примерами графического представления могут служить тради ционно используемые в управлении проектами диаграммы Гантта, сетевые диа граммы, иерархические структуры, схемы по методу PERT. Некоторые приме ры таких представлений приведены в главах части II. Ключевые характеристики графических расширений: • способность извлекать данные из различных программных пакетов управ ления проектами и других источников; • возможность осуществлять фильтрацию, сортировку и отбор информации по критериям, задаваемым пользователем, а также использовать различные форматы представления выходных данных. Web издатели и органайзеры (подкатегория программного обеспечения для управления коммуникациями) Web органайзеры – это продукты, способные сводить воедино информацию из различных проектных документов и представлять ее в форме Web сайта с сово купностью гиперссылок, создавая тем самым рабочий журнал проекта в Internet 161 Выбор и внедрение программных средств управления проектами или перенося весь процесс управления проектом в Сеть, как уже обсуждалось выше. Ключевые характеристики Web издателей и органайзеров: • способность публиковать отчеты, которые могут быть просмотрены в стан дартных Internet браузерах; • способность создавать электронный рабочий журнал проекта; • возможность размещения в Сети проектной документации и формирова ния структуры гиперссылок для обмена данными; • возможность формирования Internet ориентированных процессов управ ления проектами. 5.4 ВЫБОР И ВНЕДРЕНИЕ ПРОГРАММНЫХ СРЕДСТВ УПРАВЛЕНИЯ ПРОЕКТАМИ Рынок программных средств для управления проектами большой, активно раз вивающийся и отличающийся высокой конкуренцией. Выбор наилучшего (при менительно к определенным условиям управления проектами в конкретной орга низации) комплексного пакета или набора отдельных пакетов из множества аналогичных продуктов может сам по себе рассматриваться как крупный и слож ный проект. Определение проекта выбора, адаптации и внедрения программного средства управления проектами Если только потребности организации не ограничиваются простейшим, обла дающим рудиментарными возможностями средством составления расписаний для одного единственного проекта, то выбор, адаптация и внедрение современ ного комплексного пакета или совокупности отдельных пакетов следует рассмат ривать как отдельный проект, который должен быть создан, спланирован и вы полнен с использованием лучших доступных методик и инструментов управления проектами. Ниже приводятся основные соображения, которые могут оказаться полезными организации, приступающей к работе по улучшению своих процес сов, инструментов и процедур планирования и контроля проектов. Типичный проект выбора, адаптации и внедрения программного пакета управ ления проектами состоит из четырех фаз, занимающих первый (высший) уро вень иерархической структуры проекта/работ, приведенной в табл. 5.4. Для некоторых основных элементов каждой фазы даны описания, призванные обес печить более глубокое понимание сложностей и взаимозависимостей, свойствен ных данному проекту. 162 Объединяющие и прогнозирующие планирование и контроль проекта Òàáëèöà 5.4. Ïðåäâàðèòåëüíîå îïðåäåëåíèå ïðîåêòà âûáîðà, àäàïòàöèè è âíåäðåíèÿ ïðîãðàììíîãî ñðåäñòâà óïðàâëåíèÿ ïðîåêòàìè 1 Концепция проекта (фаза 1 жизненного цикла проекта) A Утверждение стратегических целей организации, поддержку которых обеспечит новый программный пакет B Описание предполагаемого состояния процессов управления проектами в организации, в условиях которого предстоит функционировать данному программному средству C Определение логически обоснованного ряда этапов, по которым будет развиваться управление проектами в организации; данные этапы могут коррелировать со ступенями конкретной модели зрелости управления проектами (см. главу 3), с указанием того, как вписывается применение нового пакета в уровни этой модели D Назначение дат целевых контрольных событий и формулирование оценки порядка величины вложений (как денежных средств, так и ключевых человеческих ресурсов), требуемых для достижения целей проекта E Назначение спонсора и менеджера проекта, а также обнародование устава проекта 2 Определение проекта (фаза 2 жизненного цикла проекта) A Утверждение целей проекта: технических, временных, стоимостных B Систематическое определение проекта: разработка иерархической структуры проекта/работ (ИСП/ИСР), которая должна включать следующее: I описание требований к новому программному пакету (портфели проектов, категории проектов, количество проектов, объем ресурсов, бизнес процессы и проектные процессы, документы, подлежащие связыванию, существующие базы данных, протоколы, аппаратная и программная платформа, серверы и др.); II документирование существующих и будущих или модернизированных (усовершенствованных) процессов управления проектами; III отбор существующего программного обеспечения с целью формирования краткого списка для последующей окончательной оценки; IV формирование запросов в адрес поставщиков из краткого списка с целью получения от них предложений, из числа которых следует выбрать несколько вариантов для окончательного рассмотрения; V тестирование пакетов, отобранных для окончательного рассмотрения, и анализ результатов; VI выработка требований к модификации существующих систем и процедур, необходимой для того, чтобы на фазе реализации (внедрения) можно было интегрировать выбранный программный пакет в бизнес процессы и проектные процессы и связать его с документацией, используемой в организации. Это положение особенно важно в том случае, если целью является Internet ориентированная система управления проектами; 164 Объединяющие и прогнозирующие планирование и контроль проекта Продолжительность проекта выбора, адаптации и внедрения программного средства управления проектами В зависимости от размера и структуры организации и степени ее зрелости по части управления проектами выбор, адаптация и внедрение основных усовер шенствований могут занимать период от 6 до 12 месяцев (а в некоторых ситуа циях и больше). Работы желательно проводить в несколько этапов: по отделам, региональным представительствам, портфелям проектов, категориям проектов или определив этапы из каких либо иных соображений. Факторы, которые необходимо учитывать при покупке программного средства управления проектами Как показано в табл. 5.5, имеется множество факторов, которые следует учесть при выборе программного пакета для управления проектами. Часть этих важных факторов не связана напрямую с фактически выполняемыми функциями или воз можностями программного пакета. Пользователи на своем горьком опыте узна ли, что среди фирм поставщиков программного обеспечения весьма высок “уро вень смертности” – исчезновение поставщика после того, как на внедрение его продукта и обучение персонала были потрачены значительные усилия и средства, приводит к дезорганизации и дорого обходится фирме. В итоге поддержка пользо вателей становится невозможной; пакет перестанет улучшаться и обновляться, а потому не будет использовать новые возможности, постоянно появляющиеся в динамичном мире компьютерных и телекоммуникационных технологий. Òàáëèöà 5.5. Òèïè÷íûå ôàêòîðû, ó÷èòûâàåìûå ïîêóïàòåëÿìè ïðîãðàììíîãî îáåñïå÷åíèÿ äëÿ óïðàâëåíèÿ ïðîåêòàìè. Èñòî÷íèê: [18]. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðà 1 Надежность и репутация поставщика Срок работы в данной отрасли Зона охвата поставками и технической поддержкой Репутация Наличие поддержки зарубежных Размер организации пользователей Степень сфокусированности Список клиентов или рекомендаций на управлении проектами Возможность организации обучения Линейка продуктов Возможность получения консультаций Финансовая надежность 165 Выбор и внедрение программных средств управления проектами Òàáëèöà 5.5. Òèïè÷íûå ôàêòîðû, ó÷èòûâàåìûå ïîêóïàòåëÿìè ïðîãðàììíîãî îáåñïå÷åíèÿ äëÿ óïðàâëåíèÿ ïðîåêòàìè. Èñòî÷íèê: [18]. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðà (ïðîäîëæåíèå) 2 Продукт Общая информация о продукте Пользовательский интерфейс (меню, графика, мышь) Возможность функционирования совместно с другими продуктами Импорт/экспорт данных из других систем/в другие системы Данные для определения проекта Календари: количество, применение, Иерархическая структура работ форматы дат Возможности календарного Форматы выходных документов (планов) планирования Архитектура базы данных Данные для определения операций Возможность мониторинга данных Данные о ресурсах Данные о стоимости Возможность генерации отчетов 1 (по стандарту C/SCSC или другим Графические форматы вывода стандартам) 3 Документация Интерактивная многоуровневая Учебное пособие справочная система Интерактивное учебное пособие Дополнительные материалы Система быстрого поиска (предметный по обучению указатель) Документированные процедуры коррекции ошибок 4 Поддержка пользователей Выделенный телефонный номер 24 часовая «горячая линия» поддержки пользователей Аудиторные занятия Бесплатная телефонная линия Консультации для пользователей Организация тематических семинаров Пользовательские группы (конференции) Уведомление пользователей Электронная почта об обновлениях программного пакета Информационные письма (рассылки) Поддержка с помощью Web сайта 1 C/SCSC – Cost/Schedule Control Systems Criteria, затратно временные системные показатели управления. – Прим. ред. 166 Объединяющие и прогнозирующие планирование и контроль проекта Òàáëèöà 5.5. Òèïè÷íûå ôàêòîðû, ó÷èòûâàåìûå ïîêóïàòåëÿìè ïðîãðàììíîãî îáåñïå÷åíèÿ äëÿ óïðàâëåíèÿ ïðîåêòàìè. Èñòî÷íèê: [18]. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðà (îêîí÷àíèå) 5 Контрактные особенности Функции пакета Эффективность пакета Лицензирование на использование Даты поставок системы Инсталляция и приемка Модификации пакета Обязательства по пользовательской Обучение и образование поддержке Политика совершенствования Гарантийные обязательства, соглашение и расширения функций пакета о поддержке и обслуживании Юридическая ответственность Цены и условия поставщика Выплаты при невыполнении обязательств Банкротство поставщика лицензиатом (условное депонирование) Собственные интересы фирмы Банкротство лицензиата Конфиденциальные данные Каждый из факторов, перечисленных в табл. 5.5, должен быть детализирован в целях объективного сравнения конкурирующих пакетов друг с другом. Для при мера в табл. 5.6 подробно рассмотрены два фактора из табл. 5.5. Только выпол нив рассмотрение на таком уровне детализации, покупатель может определить, отвечает ли тот или иной продукт требованиям, которые предъявляют к нему пользователи. Источники информации, полезные при выборе программного обеспечения для управления проектами Среднестатистический пользователь не осведомлен обо всех изменениях и но вовведениях, постоянно происходящих в мире компьютерных технологий. Су ществуют компьютерные журналы, в которых публикуются результаты обзоров и испытаний различных программных пакетов, а некоторые фирмы, занимаю щиеся тестированием программ, предлагают к публикации результаты собствен ных испытаний. Журналы, информационные листки и иная печатная продукция различных профессиональных ассоциаций, в той или иной степени связавших свою деятельность с управлением проектами, публикуют результаты испытаний, заключения и отзывы пользователей программных пакетов для управления про ектами. Если обратиться к какому либо поисковому сайту и ввести в качестве за проса слова “управление проектами”, будут выведены сотни ссылок, в том числе и на производителей/поставщиков программного обеспечения для этой цели. Международные, национальные, региональные встречи, организуемые различ ными ассоциациями специалистов по управлению проектами, периодически 167 Выбор и внедрение программных средств управления проектами Òàáëèöà 5.6. Ïðèìåð äåòàëèçàöèè õàðàêòåðèñòèê, êîòîðûå ñëåäóåò ó÷èòûâàòü ïðè âûáîðå ïðîãðàììíîãî îáåñïå÷åíèÿ äëÿ óïðàâëåíèÿ ïðîåêòàìè. Èñòî÷íèê: [18]. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðà 1 Данные о ресурсах Количество ресурсов на проект Количество ресурсов на операцию Распределение ресурсов по операциям: Построение расписаний с учетом ресурсных ограничений • равномерное; Выравнивание ресурсов: • неравномерное • автоматическое; Уведомление системы о ресурсе, • вызывающем ограничение по срокам по нескольким проектам Разрешено/не разрешено Приоритеты, назначаемые ресурсам: прерывистое использование ресурсов • ранние или поздние сроки (даты); Графические профили ресурсов • значения резерва/компенсации; в интерактивном режиме • прочие Отчет о ресурсах по мультипроектам Возможность отражения изменения Изменение единиц измерения единиц измерения ресурсов с помощью ресурсов в течение жизненного цикла изменения расписания проекта Возможность выбора нескольких систем учета (тарифов) для каждого ресурса Возможность установки абсолютных ограничений на объем ресурсов 2 Данные о стоимости Типы поддерживаемых данных Представление стоимости: о стоимости: • фиксированное; • фактическая стоимость; • переменное; • стоимость выполнения; • определяемое пользователем • первоначальные оценки; Итоговые отчеты о стоимости (расходах): • пересмотренные оценки • по операциям; и их количество; • по ресурсам; • целевая стоимость • за единицу времени; Оценка стоимости ресурсов: • по иерархической структуре • по всему проекту; проекта/работ; • по операции; • по мультипроектам; • за период времени; • по структуре организации • за единицу времени; Различные определяемые пользователем • по иерархической структуре работ расценки, а также значения скорости нарастания стоимости Установка приоритета пользовательских вычислений над Расписания с учетом ограничений приоритетом системных вычислений по стоимости 168 Объединяющие и прогнозирующие планирование и контроль проекта проводятся в разных странах и почти всегда сопровождаются выставками произ водителей и продавцов программного обеспечения, а также консультантов и пре подавателей, предлагающих соответствующие услуги. Большая часть фирм по ставщиков программного обеспечения периодически проводит конференции пользователей, куда открыт вход потенциальным покупателям. 5.5 ПЛАНИРОВАНИЕ И КОНТРОЛЬ ПРОЕКТА. ИНФОРМАЦИОННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ Ниже обсуждается ряд важных факторов, имеющих отношение к планированию и контролю проекта, а также к информационным системам управления проек тами. Управляют проектом и выполняют его не системы, а люди Даже самая лучшая, самая сложная, самая передовая информационная система управления проектом (ИСУП) не управляет проектом и не выполняет его – это делают люди. Генеральный менеджер, группа управления портфелем проектов, спонсор проекта, менеджер проекта, функциональные руководители проекта и другой ключевой персонал – вот кто в действительности осуществляет управ ление проектом. Люди – это единственный ресурс, выполняющий проект. В гла вах 10–14 будут детально рассмотрены общепринятые методики и процессы пла нирования, анализа и уменьшения рисков, привязки к календарной шкале, бюджетирования, утверждения, мониторинга (надзора), оценивания и контро ля сложных проектов. В простейших случаях большей частью информации мо жет владеть один человек, но для сложных высокотехнологичных проектов тре буется ее документирование с использованием описываемых форм и процедур. Хорошая ИСУП – неоценимо полезное средство, способное существенно по мочь людям управлять проектами. Три основные концепции управления проек тами (должности с объединяющей ответственностью, системы объединяющего и прогнозирующего планирования и контроля, команда проекта) должны быть сбалансированы и получить всеобщую поддержку; в противном случае их эффек тивность находится под вопросом. Сотрудники должны читать, впитывать, по нимать представляемую системой информацию и предпринимать на основе ее анализа те или иные действия. Люди и именно люди создают и вводят эту ин формацию в систему. Это соображение кажется очевидным, и все же в настоя щей главе оно подчеркивается особо с единственной целью – помочь избежать ловушки, в которую попадают многие менеджеры проектов. Очень часто они убеждены, что все, что необходимо сделать для повышения качества управле ния проектами в их организации, – это приобрести и установить последнюю 169 Планирование и контроль. Информационные системы управления проектами версию самого мощного программного пакета. Такие менеджеры испытывают разочарование и раздражение, когда оказывается, что полгода спустя после по купки и установки пакета их проекты все еще выполняются бесконтрольно. Сначала улучшают общую систему управления проектами, затем автоматизируют результат Совершенствование возможностей организации по управлению проектами в идеале происходит по трем направлениям: объединяющие должности, коман да проекта, объединяющие планирование и контроль. Как уже говорилось в гла ве 3, документирование и улучшение общих процессов управления проектами – возможно, наиболее перспективная область приложения усилий в большинстве современных организаций: ведь автоматизация разрозненных, неэффективных, устаревших процессов с помощью даже самого совершенного программного па кета дает лишь минимальную выгоду. Шаблоны планирования проектов и библиотеки проектов Многие аспекты планирования проектов допускают и предполагают разработ ку шаблонов или стандартизованных модулей, которые могут быть либо раз мещены в электронной библиотеке, либо представлены в виде твердой копии. Хотя каждый проект по определению является уникальным начинанием, не выполнявшимся прежде точно таким же образом, многие задачи (если не боль шинство), составляющие проект, повторяются от одного проекта к другому. Результаты каждого повторного выполнения той или иной задачи могут слег ка отличаться, равно как и продолжительность и задействованные ресурсы. Однако основной процесс, протекающий при очередном повторении задачи, часто идентичен процессу предыдущего выполнения той же задачи. Систематическое определение проекта с использованием иерархической структуры проекта/работ позволяет выявить и определить множество стандар тизованных модулей. Ключевые контрольные и интерфейсные события часто идентичны в различных проектах, хотя промежутки времени между такими со бытиями могут весьма заметно разниться. На уровне задач/пакетов работ сете вые планы подобных задач идентичны друг другу по меньшей мере на 80% (что касается логической последовательности выполняемых работ), хотя продолжи тельность некоторых операций сетевого плана порой широко варьируется от проекта к проекту. Картина использования ресурсов на уровне задач/пакетов работ для разных проектов часто демонстрирует сильное сходство. Вместо того чтобы просить менеджера проекта и проектную команду начи нать работу над каждым новым проектом с чистого листа бумаги (или чистого экрана компьютера), гораздо разумнее предоставить команде библиотеку шаб лонов для планирования каждой фазы или подфазы жизненного цикла проекта, 170 Объединяющие и прогнозирующие планирование и контроль проекта из которых можно выбрать необходимые, адаптировать их и интегрировать в план нового проекта. В прошлом шаблоны сетевого планирования распечатывались в виде твер дых копий, снабженных прозрачной клейкой лентой; с ее помощью можно было склеивать их в один общий план и производить ручную разметку этого плана. В наше время шаблоны хранятся в виде компьютерных файлов. Они могут быть выведены на экран компьютера или спроецированы на большой экран с помощью видеопроектора в ходе совещаний команды по планированию проекта (см. гла ву 11), модифицированы членами команды на последующих совместных сове щаниях и сведены в общий план. Члены команды проекта могут получить твер дые копии для детального ознакомления или вернуться в свои офисы и вывести соответствующие файлы с планами на экраны своих рабочих станций (при на личии локальной сети) для дальнейшего изучения и выработки дочерних пла нов более низких иерархических уровней. Кроме того, файлы с планами можно записать на магнитный носитель, а впоследствии открыть и прочитать в офисе. Таким образом, многолетний практический опыт ветеранов управления про ектами и наиболее эффективная организация хода работ, ставшая возможной благодаря использованию библиотеки “опыта прошлых проектов”, могут при нести пользу менее опытным менеджерам и членам проектных команд. Данный подход всегда таит в себе опасность избыточной стандартизации и чрезмерной зависимости от четко выверенных рутинных процессов, подавля ющих свободу творчества и возможности дальнейшего совершенствования. Про ектные команды должны использовать шаблоны только как руководства к дей ствию и постоянно искать пути их улучшения. Когда такие пути будут найдены и отражены в обновленных шаблонах, их можно будет сделать частью библиоте ки, благодаря чему все работники организации получат дополнительные выго ды. Такие электронные файлы могут быть переданы в любое подразделение орга низации или в любую точку планеты с помощью Internet или intranet. Т РЕБОВАНИЯ ВЫСШЕГО РУКОВОДСТВА Объединяющие и прогнозирующие планирование и контроль проекта Для того чтобы достичь высокой эффективности IPPPC, высший руково дитель должен требовать и добиваться следующего: • каждый проект планируется и контролируется в соответствии с указа ниями, приведенными в документации по корпоративным процессам управления проектами; 6 « « » » Команда проекта и ключевые человеческие факторы в управлении проектом П ризнание того факта, что проекты планируются и исполняются в резуль тате объединенных усилий разнородной группы людей, то есть команды проекта, и осознание необходимости организовать работу этой группы как еди ной команды лежит в основе фундаментальной концепции эффективного управ ления проектами. Вместе с определением должностей с объединяющей ответ ственностью, описанных в главе 4, и системами комплексного прогнозирующего планирования и контроля, рассматриваемыми начиная с главы 5, принцип командной работы в проектах образует триаду концепций, которая отличает управление проектами от других видов или форм управления. Хотя командная работа характерна не только для практики управления проектами, она является фундаментальным и необходимым условием эффективного управления про ектами. В этой главе рассматриваются условия эффективной командной работы в про ектах, а также некоторые ключевые человеческие факторы, которые имеют осо бое значение в управлении проектами. В области межличностных отношений и управления человеческими ресурсами существует много важных аспектов (ком муникации, переговоры, управление личным временем, принятие решений и устранение проблем, мотивация, управленческие навыки, лидерство и т.д.), которые здесь не упомянуты. Есть ряд замечательных книг, где подробно осве щаются данные темы. 173 Концепция команды проекта 6.1 КОНЦЕПЦИЯ КОМАНДЫ ПРОЕКТА Проект предполагает выполнение множества разнообразных работ. Как след ствие, для этого требуются разные сотрудники, каждый из которых имеет соот ветствующие опыт и квалификацию. В самом широком смысле все сотрудники, принимающие участие в проекте, считаются членами команды проекта. В круп ных проектах, над которыми работает несколько сотен или даже тысяч людей, необходимо определить ключевых членов команды проекта. Таковыми являются менеджер проекта (лидер команды), функциональные лидеры проекта и руко водители служб поддержки проекта. Более подробное описание обязанностей ключевых членов команды проекта приводится в главе 9. Термин “члены команды проекта” используется здесь в общем смысле: под ним подразумеваются ключевые сотрудники как головной организации, выполняю щей проект, так и внешних организаций, например консультанты, подрядчики и поставщики. Если проект достаточно крупный и его можно разбить на несколь ко меньших, то концепция команды проекта аналогичным образом применяет ся к каждому из них. В команду проекта может входить менеджер субпроекта или функциональный лидер проекта. Во многих проектах клиент или заказчик является активным участником проекта и поэтому рассматривается как член ко манды. Иногда очень результативным оказывается включение в команду проек та представителей других организаций, так или иначе задействованных в нем. Это могут быть финансовые учреждения, регулирующие или контролирующие органы, профсоюзы. Чтобы организовать эффективно работающую команду проекта (в противо вес простой группе людей, работающих над слабо связанными друг с другом за дачами), необходимы следующие условия: • определение состава команды проекта, а также четкое описание ролей и обязанностей ее членов; • четко определенные и понятные цели проекта; • реалистичный план и сроки выполнения проекта; • разумные и приемлемые правила (процедуры, определяющие информаци онные потоки, коммуникации, организацию совещаний команды и т.п.); • руководящая роль менеджера проекта. При несоблюдении одного или нескольких условий достижение эффектив ной работы команды усложняется. 6.2 ЭФФЕКТИВНАЯ РАБОТА КОМАНДЫ Для обеспечения эффективной работы команды в первую очередь необходимо определить ее состав. Менеджеры проектов часто вовсе не делают этого или 174 Команда проекта и ключевые человеческие факторы в управлении проектом пополняют команду по мере появления новых задач, которые нельзя решить уси лиями существующих ее членов. В некоторых случаях менеджер проекта знает состав команды, но не считает нужным представлять ее членов друг другу; в ре зультате полный состав команды известен только ему. Полезная практика определения состава команды заключается в выявлении всех заинтересованных сторон (project stakeholders – дословно “держателей ста вок”), то есть всех лиц, которые как либо заинтересованы в проекте и/или его результатах: упомянем, в частности, такие источники заинтересованности, как инвестированные средства, персональная ответственность в проекте, власть или право принятия решений. Брайнер (Briner), Геддес (Geddes) и Хастингс (Has tings) предлагают схему выявления основных заинтересованных сторон проек та и членов команды проекта (см. рис. 6.1) [9]. После определения состава команды оформляется ее список, который разда ется всем членам команды проекта. В этом списке должны быть указаны полное имя каждого члена команды, его адрес (почтовый и электронный), номер теле фона, факса и другая контактная информация. Нередко такой перечень содер жит номера домашних телефонов. Если в команде проекта часто приходится решать различные вопросы, проблемы, улаживать конфликты и т.п., то в спи сок заносятся номера служебного и домашнего телефонов непосредственного руководителя каждого члена команды. Общие обязанности и ответственность каждого члена команды документиру ются в соответствии с кадровой политикой конкретной организации (примеры приведены в главе 9). Однако для достижения эффективной работы команды проекта жизненно важно определить обязанности каждого ее члена по выпол нению отдельных задач. Лучший инструмент для этой цели – матрица задач и от ветственности, приведенная в главе 10. Матрица должна быть основана на иерар хической структуре проекта/работ, описанной в той же главе. Четко определенные и понятные цели проекта Основные цели проекта обычно уже известны до формирования команды про екта. Однако необходима командная работа для детализации целей проекта, их уточнения и выражения в количественных характеристиках, а также для выра ботки четких определений и описания целей, которые были бы понятны всем членам команды, приняты ими и за выполнение которых они были бы готовы нести ответственность. Хастингс (Hastings), Биксби (Bixby) и Чодри Лоусон (Chaudhry Lawson) отмечают, что члены команды должны осознавать тот факт, что у разных лиц и организаций (в том числе и не принимающих непосредствен ного участия в проекте), а также у команды и каждого отдельного ее члена су ществует множество часто конфликтующих друг с другом ожиданий результа тов работы в проекте [46]. Эти авторы предлагают оценивать эффективность работы команды в двух измерениях: “объективно/субъективно” и “приемлемо/ отлично”. Первое измерение связано с двумя критериями исполнения, второе – с двумя стандартами исполнения. 176 Команда проекта и ключевые человеческие факторы в управлении проектом производительности постоянно расширяются. Девизом суперкоманд мог бы стать лозунг “лучшее всегда можно улучшить”. Можно найти много команд, которые счита ют, что у них высокий стандарт исполнения, но на самом деле не используют весь свой потенциал. По сравнению с другими командами они могут оказаться весьма средни ми. Их уровень исполнения приемлем, но ни в коем случае не является выдающимся... Суперкоманды стремятся быть отличными от других; их достижения чуть выше, чем у конкурентов. Они постоянно совершенствуются, проверяют свои предположения относительно реально достижимого и ищут пути решения любых проблем, возникаю щих перед ними [46, pp. 35–37]. Реалистичный план и сроки проекта Эффективная командная работа в большой степени зависит от наличия плана проекта и расписания проекта, которые должны отражать реальную возмож ность членов команды сделать запланированную работу в срок. Команда должна хорошо понимать план и расписание, за которые она готова нести ответствен ность и которые, в свою очередь, должны быть выполнимыми. В главе 10 обсуж даются основные средства планирования и составления расписания проекта, раз работанные за последние десятилетия. В главе 11 описаны самые современные методы планирования эффективной работы команды проекта. Разумные и приемлемые правила Пытаться достичь эффективной работы команды в сложном проекте без разум ных и приемлемых правил – это все равно что собрать нескольких чемпионов по разным видам спорта, выпустить на неразмеченную площадку и дать каждому указание “выкладываться на все сто”. Во избежание неразберихи необходимо выработать разумные и приемлемые правила касательно того, как следует пла нировать проект, как авторизовать начало работ и оценивать выполненные ра боты, отчитываться за них, разрешать конфликты и т.д. В каждой организации должен быть свой набор процедур, которые охватыва ли бы все важные области проекта и его окружения. В больших проектах такие процедуры обычно устанавливаются для каждого конкретного проекта исхо дя из его специфики. Эту информацию предоставляют в брошюре, пособии или аналогичном документе всем членам команды. Там, где возможно, процеду ры проекта, как правило, основываются на устоявшихся корпоративных проце дурах и практике, притом не дублируя их и не противореча им. Многие сред ства, методы и правила, описанные в данной книге, могут быть изменены согласно требованиям того или иного проекта и включены в состав процедур проекта. 177 Конфликты и их разрешение Лидерство менеджера проекта Лидерство менеджера проекта освещается во многих источниках; подробное рассмотрение этой сложной и важной темы не планировалось в данной книге. Следует лишь отметить один ключевой момент: менеджер проекта должен воз главить проект, стать его лидером. Добившиеся успеха менеджеры проекта ис пользуют разные методы и средства достижения лидерства, которые, с одной стороны, зависят от их личных качеств, опыта, навыков общения и профессио нальной подготовки, а с другой – от характеристик проекта и его окружения. Оуэнс (Owens) пришел к следующим выводам в отношении лидерства в проекте и соответствующего поведения: • поведение лидера. Менеджеру проекта нельзя полагаться на один определен ный стиль руководства для влияния на поведение других людей. Различные ситуации требуют различных подходов, поэтому лидеры должны гибко ре агировать на некоторые обстоятельства и отличительные черты сотруд ников; • методы мотивации. Необходимо знать потребности команды для того, что бы успешно определить факторы мотивации и планировать работы так, чтобы эти нужды удовлетворялись; • Конфликтные ситуации возника межличностное и организационное общение. ют регулярно. Для решения проблем и улаживания конфликтов может ока заться полезным проведение неформальных собраний; • умение принимать решения и владение навыками формирования команды. Выра ботка решений при участии членов команды позволяет учесть нужды от дельных лиц, что обусловливает эффективность решений и укрепляет един ство команды [79, p. 11]. При обсуждении интегрирующей роли менеджера проекта Брайнер (Briner) и другие авторы определяют 14 процессов интеграции, важных для руководи теля проекта. Они показаны на рис. 6.2 и более подробно описаны в книге [9]. В следующих разделах этой главы изложены полезные идеи, которые помо гут менеджерам проекта усовершенствовать навыки руководства. 6.3 КОНФЛИКТЫ И ИХ РАЗРЕШЕНИЕ Изучив опыт работы 100 менеджеров проекта, Тэмхайн (Thamhain) и Уайлмон (Wilemon) выявили семь источников потенциальных конфликтов [101]: 178 Команда проекта и ключевые человеческие факторы в управлении проектом Маркетинговая Создание Поддержание раскрутка проекта поддерживающей качества культуры Документирование соглашений, достигнутых заинтересованными Прояснение сторонами индивидуальных "Завлекание "Концентрация критериев успеха заинтересован на результатах" ных сторон" Отражение (взгляд внутрь (взгляд вверх и вниз) и наружу) Работа в сети Формирование цели и обеспечение Создание Празднование руководства атмосферы доверия Поиск успеха обратной связи Предвидение "Балансирование на достигнутом" (взгляд вперед и назад) Информирование ВСЕХ членов команды Продолжительное планирование и обзор Ðèñóíîê 6.2. ×åòûðíàäöàòü ïðîöåññîâ èíòåãðàöèè. Èñòî÷íèê: [9, p. 19]. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðîâ 1. Приоритеты проекта. Участники проекта часто имеют различные точки зре ния на последовательность операций и задач, которые необходимо выпол нить для успешного завершения проекта. Конфликты, связанные с различ ным пониманием приоритетов проекта, могут возникать не только между командой проекта и службами обеспечения проекта, но и внутри команды. 2. Административные процедуры. Некоторые управленческие и административ ные конфликты могут возникать из за методов управления проектом. Дру гими словами, конфликты касаются определения отношений отчетности, обязанностей, взаимодействий, объема и содержания проекта, операцион ных требований, плана исполнения, рабочих соглашений с другими груп пами и процедур административного обеспечения. 3. Технологические разногласия и компромиссы при исполнении проекта. В техноло гических проектах разногласия могут возникать по техническим вопросам, а также в связи со спецификациями, вынужденными компромиссами и ва риантами достижения технологических показателей. 4. Конфликты могут возникать при привлечении в коман Человеческие ресурсы. ду проекта сотрудников из других функциональных структур или служб под держки, а также из за желания руководителей использовать для поддержки проекта персонал другого подразделения, даже если эти сотрудники не пе реходят в непосредственное подчинение к менеджеру проекта. 180 Команда проекта и ключевые человеческие факторы в управлении проектом Обратите внимание на следующую картину: для разрешения конфликтов с ру ководством чаще всего использовалось открытое обсуждение, в то время как при улаживании разногласий с функциональными подразделениями, обеспечиваю щими проектную деятельность, менеджеры проекта охотнее прибегали к ком промиссу. Конфликты, связанные с ответственностью Конфликты, касающиеся административных процедур, часто возникают в ре зультате “перекрытия” областей ответственности менеджера проекта и руково дителя функционального подразделения. Функциональный лидер проекта полу чает указания от двоих людей: менеджера проекта и своего непосредственного начальника. Поэтому, если должностные обязанности менеджера проекта не определены достаточно четко, такая двойная ответственность может привес ти к двусмысленности и нарастающему конфликту. Напротив, конфликты ответственности сводятся к минимуму, если все сторо ны ясно понимают роль и обязанности менеджера проекта. Иными словами, раз деление обязанностей можно упрощенно описать следующим образом: • определяет, какие задачи должны быть выполнены в рам менеджер проекта ках проекта, когда следует приступить к выполнению этих задач и решить их для достижения общих целей проекта, какие денежные средства имеют ся для проведения подобных работ; • функциональный руководитель определяет, кто будет выполнять работы, как они будут вестись технически и какие денежные средства для этого необхо димы. Невозможно четко разграничить указанные обязанности. В каждом отдель ном случае, как правило, необходимы переговоры между менеджером проекта и руководителями функциональных подразделений. Тем не менее во многих си туациях непреднамеренные противоречия может разрешить только высшее ру ководство, – и все же обращаться к такому решению следует только при крайней необходимости. Если в обязанности менеджера проекта будет входить управле ние интерфейсами (см. главу 13), это послужит действенным способом умень шения конфликтов. Неизбежность конфликтов в управлении проектами Описанные выше конфликты различных типов неизбежно возникают в ходе планирования и контроля проектов. Менеджеру проекта очень важно знать о потенциальных источниках конфликтов и быть готовым к тому, что они мо гут возникнуть на тех или иных этапах жизненного цикла. Такая осведомлен ность поможет менеджеру по возможности избежать разрушительного влияния 181 Концепция развития команды проекта конфликтов, используя возникший спор и процесс его разрешения с наиболь шей выгодой. Подобная выгода предполагает, в числе прочего, получение но вой информации, полезной для принятия решений. Устраняя разногласия, ме неджер проекта должен учитывать преимущества и недостатки разных методов улаживания конфликтов, чтобы выбрать наиболее эффективный в конкретной ситуации способ действий. 6.4 КОНЦЕПЦИЯ РАЗВИТИЯ КОМАНДЫ ПРОЕКТА Мауэр (Mower) и Уайлмон (Wilemon) разработали полезную концепцию разви тия команды проекта [70]. В основу концепции положены действия по построе суть которых изложена ниже: нию команды, Создание команды – это процесс, сходный с развитием личности. Точно так же, как развитие людей проходит через определенные фазы, процесс созревания команды протекает ступенчато. О ее зрелости можно судить как с точки зрения выполнения поставленных перед ней задач, так и с точки зрения межличностных отношений. Каж дая фаза развития команды может вызвать определенные проблемы. Менеджеры ко манды способны предотвратить их возникновение, стремясь к постоянному совершен ствованию команды. Таким образом, ее развитие не замедляется [pp. 297–198]. Концепция Мауэр и Уайлмона (табл. 6.1) предполагает четыре фазы разви тия работ и четыре фазы развития межличностных отношений. Кроме того, в ней лаконично описаны действия по построению команды. Данная система применима и на более низком уровне – для планирования и проведения общеко мандных совещаний. Òàáëèöà 6.1. Êîíöåïöèÿ ïîñòðîåíèÿ êîìàíäû ïðîåêòà. Èñòî÷íèê: [70, p. 300]. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðîâ Задачи работы с командой Личностные вопросы, Примеры действий, с которыми сталкиваются отражающих работу члены команды с командой на каждой фазе Фаза I Создание рабочей атмосферы Включение в команду Разъяснение задачи команды. В чем заключается наша Каково мое место задача? в команде? Подбор членов команды и включение их в работу. С чего нам начать? Кто еще войдет в команду? Формирование благопри ятного климата. Осознание членами команды ее целостности и роли 182 Команда проекта и ключевые человеческие факторы в управлении проектом Òàáëèöà 6.1. Êîíöåïöèÿ ïîñòðîåíèÿ êîìàíäû ïðîåêòà. Èñòî÷íèê: [70, p. 300]. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðîâ (îêîí÷àíèå) Фаза II Постановка целей и планиро Власть и конфликты Идентификация целей. вание работы Обсуждения и назначения Будет ли оценен мой вклад на роли. Какие конкретные цели в работу? Определение необходи нужно детализировать? Как я могу повлиять мых в команде процедур. Какие роли должны быть на команду? Определение того, как исполнены? Как можно сохранить команда будет связана Какие процедуры необхо свою индивидуальность с «внешним миром»: димы в команде? и в то же время остаться руководством, спонсором, “командным игроком”, группами функциональных членом команды? специалистов. Установление баланса между командой и личностью. Управление конфликтами Фаза III Исполнение проекта Личная деятельность Оценка влияния практики в “большой системе” работы, сложившейся Как нам сохранить движе в команде, на исполнение ние вперед и поддержи Каким стандартам проекта. вать моральный климат я стремлюсь соответство Оценка текущей деятель в команде? вать: личным, командным, ности. Как поддерживать стандар стандартам организации? Наглядная демонстрация ты исполнения проекта? Как сохранить и поддер успехов и хода работы Как не свернуть с нужного жать энергичность команды. пути? и интерес к работе? Обеспечение доверия Каковы мои отношения к руководителю команды с менеджером команды? Фаза IV Оценка результатов работы Успех/неудача и переход Анализ совершенствова ния команды. команды/последующие на другую должность действия Обмен опытом и впечатле Как оценили мой вклад ниями. Достигли ли мы того, чего в работу? Объединение знаний. от нас ожидали? Чему я научился? Признание вклада каждого Как нам выгодно предста Насколько я удовлетворен? члена команды. вить результаты нашей Как я расстанусь Празднование. работы? с командой? Закрытие проекта Каковы наши следующие действия? 183 Распределение и принятие обязательств в команде проекта В заключение необходимо отметить, что основу эффективного управления проектами составляет умение создать и возглавить команду проекта, опираясь на хорошо продуманные цели и надежные планы проекта, а также используя соответствующие оперативные процедуры, методы планирования и контроля. 6.5 РАСПРЕДЕЛЕНИЕ И ПРИНЯТИЕ ОБЯЗАТЕЛЬСТВ В КОМАНДЕ ПРОЕКТА Данный раздел представляет собой адаптированный фрагмент статьи: Rossi, Gerald R., Archibald, Russel D. “Building Commitment in Project Teams” // Project Management Journal, XXIII, 2 (June 1992). Авторы выражают благодарность док тору Франку Вагнеру (Dr. Frank Wagner) за вклад в первоначальное развитие не которых положений, представленных в этой главе. Важность принятия обязательств по проекту в матричной структуре Поскольку роль менеджера проекта, как правило, исполняется в рамках функ циональной структуры организации (в отношении менеджера проекта – на уров не владельца или спонсора, в отношении менеджера субпроекта – на уровне подрядчика, субподрядчика, поставщика или другой участвующей в проекте орга низации), возникающая в итоге матричная организационная структура создает ряд проблем: путаницу в обязанностях и полномочиях, конфликты между целя ми и приоритетами проекта и функциональных подразделений, а также другие связанные с этим трудности [35, pp. 54–63]. В матричной организации вопросы, связанные с принятием обязательств в проекте, – один из самых серьезных источников проблем для менеджера про екта: надо понять, во первых, как добиться того, чтобы участвующие в проек те сотрудники функциональных подразделений взяли на себя обязательства по достижению целей проекта, а во вторых, как обеспечить их выполнение [56, pp. 142–151]. Решение этих вопросов, заключающееся в выработке линии поведения участников проекта, которая должна соответствовать его целям, приоритетам и взаимозависимостям, лежит в области управления человечес кими ресурсами. Работу менеджера проекта можно рассматривать как состоящую из двух частей: • планирование и управление. Постановка задач и целей проекта; разработка ин тегрированных планов, расписаний и бюджетов; достижение оптимально го распределения имеющихся ресурсов; авторизация и контроль работ; 184 Команда проекта и ключевые человеческие факторы в управлении проектом мониторинг хода их выполнения; перепланирование; выявление отклоне ний; выполнение или инициация корректирующих действий; • Оказание влияния на всех участников проекта или заинтересо лидерство. ванных в нем сторон и выработка у них чувства ответственности за взятые на себя обязательства по проекту. Планы и расписания проекта – это необходимые предпосылки для того, что бы участники проекта взяли на себя соответствующие обязательства. Прежде чем принимать серьезную личную ответственность за взятые на себя обязатель ства перед менеджером проекта, руководители функциональных подразделений и функциональные лидеры проекта должны знать, за исполнение каких работ они ручаются и когда потребуются ресурсы для выполнения этих работ. Чтобы обес печить выполнение обязательств сотрудниками функциональных подразделе ний, участвующими в проекте, необходимо осуществлять мониторинг хода ра бот, пересматривать планы и расписания, а также сообщать о любых изменениях в содержании и календарных планах проекта. О каких бы то ни было изменени ях, касающихся исполнения проекта в прошлом и будущих планов, следует уве домить лиц, на обязательства которых эти изменения могут повлиять. Перечис ленные темы подробно обсуждаются в литературе по управлению проектами, но их важность в связи с обязательствами, взятыми на себя участниками проек та, не всегда признается. Можно определить два уровня обязательств по проекту: и организационный лич Первый предполагает выделение организацией денежных средств, челове ный. ческих и других ресурсов для выполнения задачи или проекта. Личный уровень подразумевает чувство ответственности конкретного человека, связанное с на значенными обязанностями, задачей или проектом. Ниже будут обсуждаться оба уровня, но рассмотрение главным образом коснется личных обязательств по про екту. Они являются частью организационных, поскольку их берут на себя люди, действующие скорее от имени организации, чем в собственных интересах. Лидерство и принятие обязательств Несмотря на то что вопросы лидерства и его значения в управлении довольно подробно рассмотрены в литературе, существует недостаточно много публикаций о значении принятия обязательств – как для лидера руководителя, так и для под чиненных [10, 11, 69, 92]. Требование принятия обязательств, предъявляемое к себе и к другим, – две стороны одной медали. В своей совокупности они предо ставляют возможность объединить ресурсы и мотивацию команды проекта. Прежде чем требовать от других сотрудников принятия на себя обязательств по проекту, менеджер проекта должен дать им видение основных ориентиров, обеспечить их стратегическим руководством и поддержкой. Дать видение основных 185 Распределение и принятие обязательств в команде проекта ориентиров означает определить и донести до всех членов команды видение даль нейшего пути, стратегические направления, цели и корпоративные ценности ясным и понятным для всех образом (Kouzes J. M., Posner B. Z. The Leadership Challenge. – San Francisco: Jossey Bass, 1988, p. 108). Это обычно делается на кор поративном уровне благодаря стратегическому планированию, с помощью раз личных документов, излагающих стратегическую политику организации и ее дол госрочные цели, хотя может быть легко осуществлено и в результате менее формального общения [35, p. 54]. На операционном уровне, однако, проекты являются “строительными блоками”, формирующими корпоративное видение. Создание и отбор проектов для финансирования или выбор предложений для новых проектов однозначно характеризуют то, как высшее руководство органи зации представляет себе стратегию развития. На уровне проекта в равной сте пени важно четко и ясно отразить общее видение стратегического развития орга низации в формулировании целей проекта и констатировать то, что проект способствует достижению целей более высокого уровня и реализации страте гии организации. Достижение принятия на себя обязательств членами команды проекта требу ет постановки целей перед отдельными лицами и оказания им поддержки, необхо димой для выполнения ими своих обязанностей. В организации с функциональ ной структурой это осуществляется благодаря утверждению должностных 1 инструкций, постановке ежеквартальных и ежегодных целей (MBO) , форми рованию бюджета и т.п. На уровне проекта постановка целей и оказание поддерж ки исполнителям реализуются при помощи средств и процедур базового плани рования/контроля: констатации целей и содержания проекта; иерархической структуры проекта/работ; укрупненных плана и расписания проекта; детальных планов и расписаний задач; процедур комплексной оценки и контроля; матри цы задач и ответственности и т.д. Эти понятия обсуждаются в других главах. Надо заметить, что, будучи необхо димыми для успешного управления проектом, они все же не являются достаточ ными. Должно существовать сильное у тех, кто выпол чувство ответственности няет работы для достижения целей проекта. В этой главе мы обратим внимание на методы формирования ответственности за взятые обязательства и обеспече ния их выполнения. Хотя обязательства жизненно важны в любых начинаниях независимо от того, касаются ли они отдельных лиц или групп, существует мало представлений о том, что формирует такие обязательства, и еще меньше – о том, как управлять ими. В следующих разделах будет показано, что именно требуется для принятия обя зательств исполнителями проекта и каким образом менеджер проекта может воздействовать на этот процесс. 1 Management by Objectives. – Прим. ред. 186 Команда проекта и ключевые человеческие факторы в управлении проектом Понимание приверженности целям Большая часть исследований по теории управления концентрируется вокруг “приверженности организации” – определения решающих факторов лояльнос ти к фирме и их связи с текучестью кадров. За малым исключением связь между приверженностью и производительностью в организации игнорировалась, осо бенно в отношении управления проектами и матричного окружения. Мы рас смотрим, что представляет собой приверженность целям и как ее можно исполь зовать в целях повышения эффективности управления проектами. При рассмотрении процесса, в результате которого индивидуум становится приверженным идеям организации, Сет (Sathe) отмечает, что “он принимает их, то есть относится к ним, как к собственным идеям или ценностям” [93]. В нашем случае приверженность сотрудника определяется двумя независимы ми аспектами: 1) ясным пониманием идей, ценностей и целей; 2) поведением, согласующимся с данными идеями, ценностями и целями. Приверженность – это понимание целей и приложение настойчивых усилий для их достижения. Ме неджеры проекта должны явно демонстрировать высокий личный уровень при верженности целям, причем добиваться не менее высокого уровня у тех, с кем они работают. Уайногрэд (Winograd) и Флорес (Flores) описывают эффектив ную организацию как такую, где существует развитая, просматриваемая и спра ведливая структура обязательств, которые сотрудники берут на себя и выполня ют; роль же менеджера заключается в создании, координировании и внедрении этой структуры в проекте [116]. Нельзя ожидать от членов команды высокого уровня приверженности до тех пор, пока 1) не существуют четко сформулиро ванные и понятные цели; 2) не разработаны план и расписание, по отношению к которым члены команды принимают на себя обязательства; 3) руководитель не проявляет высокого уровня приверженности целям во всех областях своей деятельности. Процесс распределения и принятия обязательств происходит на всем про тяжении жизненного цикла проекта и может быть представлен как процесс социализации (включения личности в общество и согласования ее целей с це лями общества) и группового развития, посредством которого члены коман ды вырабатывают и укрепляют определенные ценности и нормы поведения. Подобную социализацию можно ускорить с помощью семинаров на начальной фазе проекта для более быстрого включения в работу членов команды и кли ентов (см. главу 12). Ключевые линии поведения в управлении принятием обязательств и приверженностью целям Для распределения и принятия сотрудниками обязательств недостаточно просто осознавать важность этого процесса. Как и в случае с любыми другими 187 Распределение и принятие обязательств в команде проекта аспектами руководства проектом, управление распределением и принятием обя зательств требует специальных навыков, которыми менеджер может обладать в той или иной степени. Даже среди менеджеров с хорошо развитыми навыка ми распространено качество, которое можно назвать “бессознательной компе тентностью”: они преуспевают в своем деле, но не вполне осознают, что именно помогает им добиться высокого уровня принятия обязательств и привержен ности целям. Чтобы максимально увеличить эффективность своей работы, ме неджеры проекта должны обладать еще и “сознательной компетентностью”. Для активизации процесса принятия обязательств необходимо сочетание двух типов поведения – поддерживающего и инновационного. Поддерживающее поведение ведет к формированию и укреплению общего уровня принятия целей и обяза тельств; инновационное создает возможности и желание превысить начальные ожидания производительности и запланированные цели с помощью усовершен ствований. В каждом из этих двух типов можно, в свою очередь, вычленить бо лее специфические линии поведения. Необходимо сбалансированное их при менение для того, чтобы добиться от сотрудников принятия на себя обязательств и ответственности за их выполнение. Поддерживающее поведение Принятие обязательств и приверженность им обеспечиваются четырьмя основ ными линиями поддерживающего поведения: 1. Сосредоточение усилий на наиболее важных вопросах. 2. Личный пример. 3. Поощрение вклада в проект и успешных результатов. 4. Противодействие неуважению. Инновационное поведение Приверженность целям проекта полезна только до определенного момента. В ряде случаев она становится вредной. Это происходит, когда косность мышле ния отдельных сотрудников мешает им видеть или искать лучший путь к дости жению целей. Любая приверженность целям должна уравновешиваться готов ностью к изменениям, если они необходимы. В проектных ситуациях часто необходимо установить баланс между содержанием проекта, качеством, произ водительностью, стоимостью и календарным планом, особенно когда происхо дят неожиданные и незапланированные события. Член команды, который це ликом руководствуется только первоначальным планом вне зависимости от меняющихся обстоятельств, работает неэффективно. Вследствие необходимос ти адекватно и гибко реагировать на изменения менеджеру проекта и членам 188 Команда проекта и ключевые человеческие факторы в управлении проектом команды требуется умение подниматься до видения целей и стратегий более вы сокого уровня, воплощением которых является выполняемый ими проект. Это можно также назвать инновациями в управлении. Ниже перечислены четыре варианта инновационного поведения, важные для управления принятием обязательств и приверженностью целям: 1. Поиск лучших путей. 2. Стремление превзойти ожидания. 3. Создание открытой среды. 4. Поощрение рискованных действий. Где применять поведение, формирующее принятие обязательств и приверженность целям До этого момента мы обсуждали только, как должен действовать менеджер про екта, какой линии поведения ему следует придерживаться изо дня в день, чтобы команда проекта достигала результатов в срок и в пределах бюджета. Но есть и вторая важная часть уравнения, а именно – эти линии поведения нужно где применять. Имеются в виду области применения восьми линий поведения, опи санных выше. Существуют шесть основных областей, в которых руководители проектов должны постоянно демонстрировать и совершенствовать поведение, формиру ющее принятие обязательств (в каждой из этих областей должна существовать постоянная поддержка и – при необходимости – следует производить улучшения): 1. Организационные ценности. 2. Организация и ее высшее руководство. 3. Заказчики и спонсоры проекта. 4. Цели и задачи проекта. 5. Команда проекта и ее члены. 6. Сами менеджеры проекта. Выводы Для успешного выполнения своих обязанностей менеджер проекта должен до биваться принятия обязательств и приверженности целям проекта в среде, где наличествует много конфликтующих требований и факторов. Эту ответствен ность выражает сбалансированная комбинация того, что мы определили как под держивающие и инновационные линии поведения. Концепция достижения приня тия обязательств и приверженности целям может показаться простой, но сам 189 Распределение и принятие обязательств в команде проекта процесс требует постоянного внимания и совершенствования. Его ключевые положения заключаются в следующем: 1. Демонстрирование другим участникам проекта положительного примера во всех аспектах принятых на себя обязательств (то есть управление путем личного примера). 2. Поощрение регулярной обратной связи с каждым сотрудником по вопро сам производительности, хода работ и возможности совершенствования. 3. Учет как текущих планов, так и стремления совершенствовать их. 4. Сохранение баланса приоритетов. Менеджеры проекта, которые добиваются должного уровня приверженнос ти целям у членов своей команды и активно управляют этой ответственностью с помощью планирования и исполнения проектов, имеют больше шансов достичь в своем проекте поставленных целей. Т РЕБОВАНИЯ ВЫСШЕГО РУКОВОДСТВА Команда проекта В работе с командой проекта руководитель должен добиться удовлетворе ния следующих требований: • все участники проектов, выполняемых в организации, убеждены в важ ности концепции команды проекта; • каждый член команды проекта понимает: – цели проекта; – план и расписание проекта; – правила, которым необходимо следовать в процессе управления жиз ненным циклом проекта, включая процедуры разрешения нерешен ных вопросов и переноса конфликтов; • каждый менеджер проекта проходит надлежащее обучение навыкам руководства, разрешения конфликтов, построения и сплочения коман ды для достижения общих целей. 7 « « » » Организация функции управления проектами и офиса управления проектами О рганизацию функции управления проектами приходится осуществлять в отсутствие хорошо известных принципов, подобных тем, которые при меняются при организации традиционной функционально ориентированной структуры. До сих пор нет ни одной организационной модели, позволяющей дать ответы на следующие вопросы, связанные с управлением проектами. Организация управления отдельными проектами: • каким образом будут утверждаться назначения на должность менеджера проекта и другие должности с интегрирующей ответственностью, рассмот ренные в главе 4? Как будут взаимодействовать носители этих должностей? • кому должен быть подотчетен менеджер проекта? На каком уровне и в ка кой части организации? • кого следует перевести в офис проекта на работу в режиме полной занятос ти с отчетностью перед конкретным менеджером? Каких участников необ ходимо оставить в их функциональных подразделениях? • как наилучшим способом обеспечить менеджеров и команды проектов пер соналом со специальными навыками в области планирования и контроля проектов, администрирования контрактов, решения финансовых и юри дических вопросов и т.д.? 191 Организационные структуры для управления проектами Управление мультипроектами: • кто несет ответственность за разработку и функционирование системы ком плексного планирования и контроля проектов в рамках мультипроекта? • кто должен выполнять специфические обязанности по управлению муль типроектом и кому это лицо должно быть подотчетно? Управление проектами в масштабах предприятия: • какое место в структуре организации занимает директор по управлению проектами? • как данная должность соотносится с группой управления портфелями про ектов, спонсорами, назначенными в большие проекты, и менеджерами раз личных проектов и программ? • следует ли учреждать на общекорпоративном или более низком уровне офис и/или центр управления проектами, который будет служить “штабом” управления проектами в организации, местом постоянной работы дирек тора по управлению проектами? В данной главе рассматриваются основные факторы, которые определяют ответы на поставленные вопросы. Там, где это представляется возможным, да ются основные рекомендации на будущее. Материал иллюстрируется примера ми организационных структур, принятых в различных компаниях. 7.1 АЛЬТЕРНАТИВНЫЕ ВАРИАНТЫ ОРГАНИЗАЦИОННЫХ СТРУКТУР ДЛЯ УПРАВЛЕНИЯ ПРОЕКТАМИ Существуют три основные формы организационной структуры для планирова ния и исполнения проектов: 1) чисто функциональная, 2) функционально про ектная матрица, 3) чисто проектная (то есть функциональная, посвященная од ному проекту). Каждая из них имеет свои сильные и слабые стороны. Каждая из них может функционировать с различной степенью эффективности, зависящей от характеристик основной организации (размера, степени гибкости, характе ра бизнеса, культуры и традиций) и проектов (их количества, размеров, сложнос ти, степени уникальности, продолжительности и других факторов, обсуждавших ся в главе 2). Компании обычно разрабатывают собственные подходы к построению органи зационной структуры для управления проектами, комбинируя основные формы. В начале своего существования большинство организаций имеет классическую 192 Организация функции управления проектами и офиса управления проектами функциональную пирамидальную структуру, включающую в себя специализиро ванные отделы маркетинга, инжиниринга, финансирования, производства и других операций, а также штатных специалистов для решения юридических, финансовых, административных вопросов, управления человеческими ресур сами и т.д. Линейки продуктов, география, технология и заказчики также часто находят свое отражение в пирамидальной структуре. По мере того как коли чество, размер и сложность проектов в функциональной организации растут, а расписание и/или стоимость выполнения становятся все критичнее, менед жеры вносят изменения, которые приводят их к созданию функционально про ектной матрицы или отдельной самодостаточной “проектной” структуры. Зачастую ряд неудач чисто функциональной организации, рассмотренных в главе 3, вынуждает высшее руководство искать лучшие пути. Крайне редко представляется возможным сформировать полностью самостоятельную орга низацию для каждого проекта – причиной тому необходимость дублировать все специализированные ресурсы и средства производства (и тратить на это дубли рование деньги). В результате большинство организаций существует в виде функционально проектной матрицы того или иного типа. Функционально проектная матричная структура Хорошо известно, что функционально проектная матричная организация стал кивается со многими трудностями. Введение в такую устоявшуюся бюрократизи рованную структуру должности менеджера проекта, достижение необходимого баланса обязанностей и полномочий между функциональными руководителями и менеджерами проектов – нелегкие задачи. Главная проблема заключается в том, что сотрудники в функциональных подразделениях получают указания от двух руководителей – проектного и функционального, что считается нарушением традиционной управленческой практики. Если не будет достигнуто правильное понимание различий между функциональным руководством, с одной стороны, и проектным руководством, с другой, то повысится вероятность возникнове ния существенных, нежелательных и дорого обходящихся конфликтов. В главе 4 рассматривались различные проектные роли с объединяющей от ветственностью, в том числе роли функционального руководителя и менедже ра проекта. Там же разъяснялось различие между функциональным и проект ным руководством. Упомянутые выше нежелательные конфликты могут быть минимизированы, если все, кого они могут затронуть, будут понимать суть на званных ролей и вести себя соответствующим образом. Обязанности и полно мочия носителей этих ролей рассматриваются также в главах 8 и 9. Как показа но в главе 13, менеджеры проектов, которые фактически выступают в роли менеджеров по взаимодействиям, способны выполнять свою работу с минималь ными трениями. 193 Организационные структуры для управления проектами Существует широкий диапазон структур, которые могут быть отнесены к мат ричным. На рис. 7.1 представлен непрерывный континуум матричных форм, начинающийся с чисто функциональной формы (слева) и заканчивающийся чис то проектной (справа). Многие организации по мере накопления зрелости в сфе ре управления проектами продвигаются в этом континууме слева направо. Функциональная Матричная Проектная структура структура структура 100% 0% Члены команды проекта Сотрудники функциональных отделов Слабая Сильная матрица матрица 0% 100% Работает Работает Менеджер с частичной с полной проекта, Отдельная Офис Координатор занятостью занятостью работающий команда отсутствует проекта с полной проекта Координатор занятостью Ðèñóíîê 7.1. Îðãàíèçàöèîííûé êîíòèíóóì 1. Èñòî÷íèê: [118]. Èñïîëüçîâàíî ñ ðàçðåøåíèÿ àâòîðà Целевая рабочая группа проекта Часто в организациях считается полезным размещать большую часть команды проекта в одном месте для облегчения общения, управления и работы в коман де. Особенно часто такой подход используется в инженерно строительных фир мах. На первый взгляд, это является явным признаком проектной компании; тем не менее одного его недостаточно, и во многих случаях такая организация все еще оказывается матричной, поскольку работники функциональных отделов не всегда формально направляются из своих отделов в проектный (особенно при оценивании производительности их труда и выплате вознаграждения). Впро чем, размещение большей части или всех членов команды проекта вместе по зволяет преодолеть некоторые проблемы матричной организации и обычно улучшает эффективность работы команды. 194 Организация функции управления проектами и офиса управления проектами 7.2 ОТНОШЕНИЯ ОТЧЕТНОСТИ МЕНЕДЖЕРОВ ПРОЕКТА После того как крупный проект утвержден и принято решение назначить ме неджера проекта, следующее решение определяет его место на иерархической лестнице организации и в отдельной ее части. Это решение крайне важно для обеспечения эффективной работы данного сотрудника. Основной принцип подотчетности Основной применяемый на практике принцип гласит, что менеджер проекта должен отчитываться перед вышестоящим руководителем, который реально будет разрешать существенную часть противоречий и конфликтов как внутри проекта, так и вне его. Таким образом, менеджер проекта может отчитываться перед менеджером отдела, управления, продуктовой линейки или перед гене ральным либо исполнительным директором компании. В очень крупных про ектах, включающих различные компании, он будет, вероятно, отчитываться перед генеральным директором головного предприятия, которое несет ответ ственность за выполнение всего контракта. Размер, ограничения и природа проекта – это ключевые факторы при опре делении того, на каком уровне должен отчитываться менеджер проекта. Коли чество проектов в организации и существование или отсутствие формальной мультипроектной ответственности, а также должность, положение, опыт и лич ностные характеристики менеджера проекта – все это будет непосредственно влиять на окончательное решение относительно его подотчетности. Менеджеры проекта обычно чувствуют, что их работа станет легче, если они будут отчитываться перед высшим руководством организации. Опыт показыва ет, что это не всегда полезно для дела. Уровень отчетности, особенно очень вы сокий, бывает столь же неэффективен, сколь и очень низкий, по самым разным причинам. Если уровень подотчетности очень высок, могут иметь место серьез ные и ненужные конфликты со старшими линейными менеджерами, наруше ние взаимоотношений с участвующими в проекте функциональными руководи телями или невосприимчивость высшего руководства к словам менеджера проекта, обусловленная тем, что он находится на несколько уровней ниже, чем лицо, перед которым он отчитывается. Это вынуждает менеджера проекта все чаще и чаще прибегать к использованию своей власти, даваемой ему полномо чиями уровня подотчетности, и, таким образом, ведет к дальнейшему нагнета нию конфликта и ухудшению взаимопонимания. Отчетность на очень низком уровне, например перед менеджером какого либо отдела (или ниже), когда еще несколько отделов вносят существенный вклад в проект, чревата тем, что менед жер проекта не добьется необходимого содействия других отделов или не будет способен критически и объективно оценить вклад того отдела, к которому он от носится. В обоих случаях страдает проект – причина в том, что менеджер проекта 195 Офис управления проектами не находится на соответствующем уровне, необходимом для адекватного выпол нения им своих обязанностей. 7.3 ОФИС УПРАВЛЕНИЯ ПРОЕКТАМИ Один из показателей зрелости управления проектами в организации – осозна ние необходимости создания специального “штаба” – функционального подраз деления, отвечающего за управление проектами в компании. Этот “штаб” мо жет называться офисом управления проектами или как то иначе. Офис должен занимать соответствующее место в иерархической структуре организации и быть подотчетным соответствующему руководителю высшего звена. Иногда такой офис управления проектами называется Реко офисом проекта. мендуется, однако, использовать термин “офис проекта” применительно к офи су определенного отдельного проекта (программы), то есть к офису одного ме неджера проекта (программы) – см. главы 8 и 9. Обязанности офиса управления проектами намного шире и значительно отличаются от обязанностей офиса про екта/программы. Следует также признать важность еще одной организационной функции, спо собной оказать влияние на возможности компании по управлению проектами. Эта функция обобщенно называется функцией планирования и контроля операций мультипроекта. В ее задачи входят планирование, составление расписаний и кон троль большого количества малых проектов (см. главу 2). Назначение менедже ра проекта с полной занятостью не может быть оправдано ни для одного из этих малых проектов, равно как и применение в полном объеме процессов систе матического планирования и контроля. Однако в совокупности такие малые проекты могут представлять собой значительную долю бизнеса организации. Функция планирования и контроля операций мультипроекта более подробно рассматривается в главе 8. По видимому, эту функцию следует включить в обя занности офиса управления проектами, описываемые ниже. Различные варианты устава для офиса управления проектами В современной литературе по управлению проектами описывается множество вариантов устава для офисов управления проектами, учреждаемых на различ ных уровнях организации. Офис управления проектами может быть предна значен для удовлетворения нужд всего предприятия или корпорации, бизнес единицы, операционного отдела, портфеля проектов или мультипроектной программы. Содержание работы и услуги, предоставляемые офисом управления проекта ми организации, могут существенно варьироваться. В частности, приведем сле дующие примеры. 196 Организация функции управления проектами и офиса управления проектами Диапазон возможного масштаба действий: • масштаб корпорации/предприятия; • масштаб бизнес единицы/операционного отдела; • масштаб линейки продуктов; • масштаб портфеля проектов; • масштаб мультипроектной программы; • масштаб отдельных проектов (офис управления проектами заменяет офи сы отдельных проектов или перекрывается с ними). Диапазон возможных обязанностей: • проектирование, разработка, реализация (внедрение), обеспечение функ ционирования и непрерывное улучшение системы управления проектами в масштабах предприятия; • проектирование, разработка или приобретение, реализация (внедрение), обеспечение функционирования и непрерывное улучшение (благодаря со ответствующим маркетинговым и инженерным исследованиям) процессов, систем и инструментов управления проектами в организации: – процесса управления портфелями проектов; – системы управления жизненным циклом проекта (Project Life Cycle Mana gement System, PLCMS) для каждой категории проектов в организации; – программного обеспечения управления проектами для обеспечения под держки PLCMS как в каждой категории проектов, так и в масштабах пред приятия; • приобретение, распространение и применение знаний в области управле ния проектами (применительно к центру управления проектами): – выявление наиболее удачных подходов к управлению проектами и сопут ствующим вопросам в производственном или ином секторе организации; – сбор, документирование, архивирование, выборка и распространение как позитивного, так и негативного опыта организации по управлению проектами в целях ее непрерывного совершенствования; – распространение этой информации среди заинтересованных лиц в орга низации таким способом, который обеспечивал бы ее максимальную прак тическую полезность; – обеспечение корректного применения имеющейся информации и зна ний; • обеспечение подготовки персонала в области управления проектами и вос питание его в соответствующем духе: 198 Организация функции управления проектами и офиса управления проектами • обеспечение непосредственной поддержки отдельных проектов: – оказание административной поддержки менеджерам активных проектов; – по мере необходимости – предоставление менеджерам активных проектов услуг специалистов в областях управления рисками, планирования проек тов, оценивания ресурсов, контроля проектов, ведения отчетности, анали за отклонений, отслеживания нерешенных вопросов (судебных исков, тяжб), управления изменениями, администрирования контрактов и др.; – учреждение и запуск центра контроля проектов с соответствующим обо рудованием и необходимыми графическими, звуковыми и визуальными средствами представления информации, которые могут быть использо ваны командой проекта при проведении совещаний по обзору состоя ния проекта. Не рекомендуется, чтобы в организации предпринимались попытки “за одну ночь” (в авральном порядке) организовать офис управления проектами, способ ный выполнять все вышеперечисленные функции. Напротив, должен быть раз работан план постепенного развития, позволяющий, основываясь на текущей ситуации, последовательно расширять диапазон функций, выполняемых офи сом управления проектами, и повышать эффективность этой работы. Организация и развитие офиса управления проектами Становление работоспособного офиса управления проектами в большинстве организаций – как правило, эволюционный процесс. Блок (Block) очерчивает возможный диапазон услуг, которые могут предоставлять офисы такого рода, организуемые на разных уровнях [6]. Тот же автор рассматривает и различные планы практической реализации офиса управления проектами. Натсон выделяет три основных направления, в которых может развиваться деятельность офиса управления проектами, а также отмечает его основные обя занности [53]: 1. Офис управления проектами в кадровых вопросах: • поддержка и развитие методологии; • наставничество/обучение; • библиотека типовых проектов; • источник исторической информации; • предварительный анализ обзорных отчетов по завершении фаз. 2. Офис управления проектами в административной роли в масштабах пред приятия – плюс ко всему вышеперечисленному: • орган отчетности по мультипроектам; • координатор по установке приоритетов; 199 Офис управления проектами • орган отслеживания ресурсов; • администратор; • орган контроля изменений. 3. Офис управления проектами в линейной роли – плюс ко всему вышепере численному: • менеджер проектов; • лидер. Организация офиса управления проектами в компаниях, имеющих отношение к информационным технологиям (IT организациях) Страттон (Stratton) описывает, каким образом концепция офиса управления про ектами, PMO, была использована на двух уровнях – на корпоративном (нацио нальном) и на программном – для реализации “ключевых дисциплин операци онного инжиниринга (operational engineering, OE), которые дают возможность IT отделам, вечно испытывающим нехватку персонала, функционировать и ди намично подстраиваться под требования быстро изменяющегося бизнес окру жения сегодняшнего дня” [99]. Автор описывает обязанности офиса управле ния проектами на каждом из этих уровней и объясняет, каким образом PMO фокусируется на базовых процессах, которые могут быть легко поняты и исполь зованы. В той же книге показано, как PMO может выполнить возлагаемые на него задачи и обязанности по части программ и проектов. Описываемый Страт тоном офис управления проектами национального уровня называется “3P PMO Process”, где сочетание 3P означает Process – Proposal – Project (Процесс – Пред ложение – Проект), причем каждый элемент подразделяется на ряд фаз. Каждая фаза подробно определяется требуемыми от нее результатами. Все проекты и программы “прогоняются” через этот процесс (3P PMO Process) и его допол нительные фазы с использованием утвержденной метрики на национальном уровне для определения минимальной прибыли каждой программы или каждо го проекта. Также Страттон представляет подробное описание карт для подсче та баллов (при использовании системы балльных оценок) с целью отслежива ния исполнения и результатов программ и проектов. Выгоды, получаемые от работы офиса управления проектами Блок (Block) перечисляет выгоды, которые можно получить в ходе эволюции офиса управления проектами, когда он становится полновесным поставщиком услуг в сфере управления проектами [6]: 200 Организация функции управления проектами и офиса управления проектами • повсеместное признание; • увеличение прибыльности (рентабельности); • повышение производительности команд проекта; • организационные улучшения; • смещение культуры в сторону проектной; • возрастание профессионализма персонала в управлении проектами; • многократно используемые инструменты и методики управления проекта ми, обеспечивающие предсказуемые результаты. Как следствие, “скрытая выгода от использования офиса [управления проек тами. – проявляется в постепенной ассимиляции управления проектами Р. А.] во всей организации” [6]. На самом деле именно такова окончательная цель со здания PMO. Проблемы, связанные с организацией и деятельностью офиса управления проектами Не всякая попытка становления офиса управления проектами выдерживает ис пытание временем. Многие PMO были основаны, на время расцвели, а затем канули в Лету. Фундаментальный вопрос – противостояние централизации и де централизации – ведет к соблазну, заставившему многих практиков создать це лые империи. Чтобы получить ответ на вопрос о том, насколько сильной должна быть цен трализация, достаточно рассмотреть список вышеперечисленных обязанностей PMO. Те из них, которые касаются общих процессов, методов, систем и инстру ментов в масштабах всей организации, разумеется, должны быть централизова ны. Другие – главным образом те, которые связаны с планированием и контролем отдельных программ и проектов, а также с отношениями отчетности менедже ров, в ведении которых находится несколько программ или проектов, – не мо гут быть столь однозначно очерчены. Есть одно принципиальное соображение, которое нужно четко осознавать: вспомогательные услуги по планированию и контролю, предоставляемые менед жеру большого проекта, должны находиться под непосредственным контролем этого менеджера. Важно (особенно для больших проектов), чтобы лица, выпол няющие вспомогательные функции, были подотчетны непосредственно менед жеру программы или проекта. Попытки централизовать работу таких служб и просто распространять информацию среди различных менеджеров проектов обычно неуспешны по ряду причин. Детальное знание расписания, бюджета, расходов и сопутствующих прогнозов – источник жизненной силы проекта, чрез вычайно важный для любого менеджера проекта. Опытный менеджер проек та не допустит того, чтобы информация целиком и полностью поставлялась 201 Офис управления проектами независимым централизованным органом, персонал которого будет осведом лен о назревающих проблемах раньше, чем сам менеджер проекта. В результате последний часто разрабатывает свой собственный набор планов и расписа ний, а затем использует его при управлении проектом, что приводит к дублиро ванию работы и путанице в многочисленных отчетах. Вопрос о том, должны ли все менеджеры проектов или некоторые из них отчитываться перед директором по управлению проектами, достаточно не прост. Если все менеджеры проектов подотчетны директору по управлению про ектами, это наделяет его исключительно большой властью – и одновременно превращает в мишень для политических игр, так как у его конкурентов в орга низации может возникнуть вполне естественное желание сместить его с зани маемой должности. В зависимости от уровня отчетности PMO и масштаба его деятельности можно достичь гораздо большей эффективности, если отдельные менеджеры проектов будут подотчетны различным линейным руководителям. Тогда директор по управлению проектами по прежнему оказывает влияние на всех менеджеров проектов благодаря своему авторитету в области управления проектами, но не имеет повседневной линейной (определяемой субординаци онными линиями) власти над всеми проектами. Если лицо, назначенное на должность директора по управлению проектами, рассматривает это назначение как возможность создания “империи” в своем PMO и таким образом собирается нажиться на интересе к управлению проектами, не считаясь с долговременными перспективами и не проявляя уважения к позици ям и полномочиям менеджеров программ/проектов, то PMO, скорее всего, не просуществует достаточно долго. Пример офиса управления проектами, который постигла неудача Макмахон (McMahon) и Басси (Busse) предлагают интересное описание расцве та и краха офиса управления проектами в сфере информационных систем [65]. Среди проблем, которые привели к ликвидации этого PMO, упоминаются следу ющие: • офис комплектовался специалистами по управлению проектами, не распо лагающими достаточными знаниями в области информационных систем; • менеджер по информационным системам не желал вымолвить ни слова о преимуществах управления проектами и PMO за пределами отдела ин формационных систем; • менеджер по IS приложениям высказал ряд замечаний по поводу концеп ции управления проектами и офиса управления проектами, что вызвало возражения и подозрения у лидеров проекта, конфликты на уровне персо нала и привело к определенной текучести кадров; 202 Организация функции управления проектами и офиса управления проектами • основной движущей силой создания офиса управления проектами было стремление решить “проблему 2000 года”, и когда этот год наступил, исчез импульс, побуждавший к развитию офиса. После наступления 2000 года в директивном порядке было решено расходовать бюджетные средства на другие инициативы; • руководитель PMO ушел из организации, а за ним ее покинул и корпора тивный защитник концепции управления проектами; • новый директор по информационным системам, вступив в должность, на чал проводить свои инициативы – это и послужило последним сигналом к роспуску PMO. Макмахон и Басси предлагают рекомендации, которые позволят не только создать офис управления проектами, но и добиться его успешной работы [65]: • крайне важно, чтобы офис управления проектами учреждать PMO “наверху”: был учрежден на максимально высоком операционном уровне или был под отчетен комитету, находящемуся на максимально высоком операционном уровне; • утвердить крепкое основание: важность создания коалиций, учреждение PMO на уровне предприятия, периодическое проведение программ обучения персонала, – все это способствует росту крепких организационных корней, которые невозможно будет выкорчевать вследствие смены персонала како го бы то ни было уровня; • распространять информацию (осуществлять пропаганду): сформировать в мас штабе всей организации план информирования персонала о важности и преимуществах PMO; • демонстрировать реальную пользу: внедрить систему легко понимаемых отче тов, которые будут распространяться по всей организации через intranet или по электронной почте, для демонстрации успехов и извлечения уро ков из допущенных ошибок; • по заверше проводить совещания по обобщению и применению усвоенных уроков: нии каждого проекта устраивать совещания, на которых делаются выводы и формируется “хранилище” накопленных знаний. Такие совещания долж ны быть открытыми для персонала любого уровня; • повышать профессионализм менеджеров проектов: уважать должность менедже ра проекта и рассматривать ее как профессию. Развивать формальные про цессы обучения и подготовки персонала, поощрять среди менеджеров стремление вступать в профессиональные ассоциации и получать профес сиональные сертификаты в области управления проектами. Авторы перечисляют ряд других мер дальнейшего повышения профессиона лизма менеджеров проектов и специалистов узкого профиля. 203 Формирование штата проекта: офис и команда проекта 7.4 ФОРМИРОВАНИЕ ШТАТА ПРОЕКТА: ОФИС И КОМАНДА ПРОЕКТА Различные методы формирования штата Существуют три основных метода формирования штата проекта, обычно исполь зуемые в сочетании друг с другом: • направление людей в офис определенного проекта под непосредственное руководство менеджера данного проекта; • распределение задач проекта среди функциональных отделов или специ ального персонала; • заключение контрактов на работы по проекту с внешними организациями. Менеджер проекта обычно хочет, чтобы все сотрудники, участвующие в его проекте, работали с полной занятостью в организации, исполняющей про ект, или офисе, которым он непосредственно руководит. Однако в большин стве случаев это нежелательно, а иногда и невозможно по следующим при чинам: • на разных фазах своего жизненного цикла проект требует разных навыков: каждая новая фаза предполагает привлечение специалистов другого про филя; • построение на постоянной основе большого выделенного офиса для управ ления каждым проектом неизбежно “дублирует” потребность в специалис тах, обладающих отдельными навыками – зачастую именно теми, которые являются дефицитными, – а также заставляет нанимать и содержать сотруд ников, которых нет необходимости использовать в режиме полной занятос ти или на долгосрочной основе. Как следствие, возникают проблемы в кад ровых перестановках; • менеджера проекта могут отвлекать от его первоначальной основной рабо ты. Может даже возникнуть ситуация, когда менеджеру проекта придется исполнять, например, роль инженера проекта или заняться администри рованием, кадровыми проблемами крупного офиса, вместо того чтобы кон центрировать свои усилия на всех аспектах управления самим проектом; • люди узкоспециальной ориентации часто предпочитают работать в группе профессионалов того же профиля, причем ждут, что их руководителем бу дет человек, имеющий определенную квалификацию в соответствующей области. Такие сотрудники редко склонны работать в изоляции от своих коллег, а это неизбежно произойдет при их переводе и физическом пере мещении в штат офиса проекта; 204 Организация функции управления проектами и офиса управления проектами • в управлении проектами всегда возможны внезапные смены приоритетов и даже прекращение самих проектов; в таком случае персоналу офиса про екта с полной занятостью грозит безработица. Это часто заставляет неко торых сотрудников отказываться от предложений работать в том или ином проекте. Все перечисленные факторы говорят в пользу того, что офис проекта должен быть как можно меньше и максимально полагаться на имеющиеся ресурсы функ циональных отделов и специалистов для выполнения различных работ по про екту. При таком подходе большое внимание уделяется процедурам планирова ния и управления проектом. С другой стороны, имеются веские причины для привлечения некоторых кон кретных специалистов в офис проекта. Обычно это специалисты в следующих областях: • системный анализ и инжиниринг (или аналогичные технические дисцип лины), при необходимости – контроль качества и конфигурации продукта; • планирование проекта, составление расписания, управление проектом, ад министративная поддержка проекта. Опыт многих компаний показывает, что специалисты, по крайней мере, вы шеназванного профиля должны находиться под постоянным контролем менед жера проекта – если, конечно, он хочет эффективно выполнять возложенные на него обязанности. Крупный офис проекта может быть создан для улучшения управления работами в случае, когда отсутствуют эффективные процедуры или системы планирования и управления. Организация участников проекта Команда проекта включает всех сотрудников, на которых возложено выполне ние тех или иных специфических задач по проекту, в том числе сотрудников, находящихся под непосредственным руководством менеджера проекта; работа ющих в функциональных отделах, в смежных внешних организациях; обладаю щих узкоспециальными знаниями и навыками. Рис. 7.2 иллюстрирует обобщенную организационную структуру промышлен ного проекта. Здесь показаны все участники: как те, которым желательно нахо диться в офисе управления проектом под непосредственным руководством ме неджера проекта, так и те, кто почти всегда связан с проектом косвенно. Указаны также сотрудники и организационные единицы, которые могут иметь различ ные отношения подотчетности в зависимости от ситуации. Перевод некоторых или всех членов группы разработки продукта в офис про екта, как показала практика, вполне обоснован в следующих случаях: Менеджер проекта Персонал поддержки Маркетинг Управление Контроль Промышленный Технический Администрирование Закупки Кадровые Руководство Финансы продуктовой качества инжиниринг персонал контрактов и заключение вопросы проекта и бухгалтерия линейкой субподрядов Формирование Администратор по контрактам Инсталляция (монтаж, Разработка Производство Поддержка установка, ввод Функциональные и проектирование продукта продукта управления проектом в эксплуатацию) продукта лидеры проекта Инженер Производственный Менеджер по вводу Контролер штата проекта координатор проекта в эксплуатацию проекта проекта: Службы Системный Бухгалтер обработки Контроль анализ. проекта данных продукта Инженерная интеграция офис Разработка Производство Ввод продукта Планирование Функциональные продукта продукта в эксплуатацию лидеры Оценивание задач и Бюджетирование Качество команда Утверждение Стоимость и контроль работ Конфигурация Контроль стоимости, расписания и расхода человеческих ресурсов Оценка проекта проекта Административные функции Внутренние Внешние Внутренние Внешние Внутренние отделы установки компании технические инженерные производ Внешнее (монтажа, по внедрению и инженерные консультанты ственные производство внедрения, ввода (вводу в отделы и компании отделы в эксплуатацию) эксплуатацию) 205 Ðèñóíîê 7.2. Îðãàíèçàöèÿ êîìàíäû ïðîåêòà â îáùèõ ÷åðòàõ 206 Организация функции управления проектами и офиса управления проектами • когда необходимо продолжительное и тесное взаимодействие с другими членами офиса проекта; • когда такие сотрудники требуются на длительное время (шесть месяцев и более); • если нельзя гарантировать, что в противном случае эти люди будут посвя щать работе над проектом оговоренные заранее время и усилия (иными словами, в том случае, когда нет должного контроля за сотрудниками). Особое внимание нужно обращать на то, чтобы в офис проекта переводились только работники, в которых действительно существует необходимость, при чем производить отбор следует до их фактического перевода. Практическая ре комендация состоит в том, чтобы выделить в отдельные группы тех инженеров и специалистов функциональных отделов, на которых будет возложено выпол нение задач по проекту, и предоставить этим людям общее помещение как в функ циональных отделах, так и в офисе проекта. Тогда сотрудники формально не пе реводятся в офис проекта и продолжают поддерживать установившиеся связи в своих отделах, но фактически выполняют задачу проекта в команде совместно с другими специалистами. Координатор по производству в проекте должен, по видимому, оставаться в своей функциональной производственной организации, поскольку ему необ ходимо поддерживать тесную связь с непосредственными изготовителями про дукта и оперативно координировать их усилия. Менеджеру по внедрению следует, вероятно, оставаться в своей постоянной организационной структуре (монтажном или ином подразделении, осуществля ющем внедрение и установку), не подчиняясь напрямую менеджеру проекта, осо бенно если проект является относительно коротким или если менеджер по внед рению привлечен к нескольким проектам одновременно. Если какая либо фаза проекта (фаза внедрения или установки) достаточно длительна (шесть месяцев и более), рекомендуется ввести менеджера по внедрению в офис проекта. Влияние метода формирования штата на полномочия менеджера проекта Если все исполнители работ по проекту подчиняются непосредственно менед жеру проекта, его роль подобна роли руководителя многофункционального под разделения. По упомянутым выше причинам такие случаи встречаются крайне редко, если только речь не идет об очень крупных проектах с очень высоким приоритетом. В современной практике значительная (а часто и большая) часть работ по проекту выполняется сотрудниками разных функциональных отделов или сто ронних организаций, работающих по контрактам. Такие сотрудники органи зационно не подчинены менеджеру проекта, однако для достижения целей 207 Формирование штата проекта: офис и команда проекта проекта он должен объединять их усилия. При таком подходе возникает ситу ация, рассмотренная в главе 4: лидеры задач получают указания и от своего функционального руководителя (например, начальника отдела), и от руково дителя проекта. Полномочия менеджера проекта в такой проектно функцио нальной организации значительно отличаются от полномочий менеджера ав тономного проекта. В этих условиях для организации эффективного управления проектом необ ходимо, чтобы менеджер проекта выступал в качестве менеджера по взаимодей ствиям, отвечая за взаимоотношения на уровне сотрудников и отделов, и полу чал соответствующую поддержку, цель которой состоит в контролировании проекта методами интегрального планирования, формирования расписания и проведения оценок. Отношения между менеджерами проекта и функциональными руководителями: управление взаимодействиями Функциональным менеджерам, чей опыт целиком сосредоточен в области тра диционной функциональной организации, трудно выработать должное понима ние роли менеджера проекта. Обязанности менеджера проекта многоплановы и охватывают, в числе прочего, организацию взаимодействия различных функ циональных отделов, которое необходимо для завершения проекта. Эти обязан ности перекрывают обязанности функциональных менеджеров, что, однако, не отменяет основной ответственности последних за выделенную им часть про екта. Если роль менеджера проекта возьмет на себя генеральный менеджер, перед которым отчитываются все функциональные руководители, то любой функцио нальный руководитель с готовностью поймет и примет такое положение дел, ибо при этом существующий порядок отчетности не пострадает. Но когда ответ ственность за выполнение проекта лежит не на генеральном менеджере, а на другом сотруднике, функциональные руководители с трудом могут принять эту идею. Взгляд на менеджера проекта как на полезен для менеджера по взаимодействиям прояснения его взаимоотношений с функциональными руководителями и дру гими сотрудниками, находящимися вне его прямого контроля. Согласно данно му подходу, главные обязанности менеджера проекта в роли менеджера по взаи модействиям заключаются в следующем: • выявить все взаимодействия между функциональными отделами и други ми элементами проекта; • разработать планы и расписания для объединения взаимодействующих эле ментов; 208 Организация функции управления проектами и офиса управления проектами • довести до сведения всех функциональных участников проекта информа цию о текущем порядке взаимодействий и о путях их дальнейшего развития; • отслеживать ход исполнения проекта во всех областях и периодически оце нивать проект для выявления проблем и своевременного принятия мер по их устранению. Управление взаимодействиями подробно описано в главе 13. Менеджеры про екта, осуществляющие управление взаимодействиями, смогут придти к понима нию того факта, что им нет необходимости вторгаться в прерогативы функцио нальных менеджеров; таким образом, их взаимоотношения заметно улучшатся. На практике менеджер проекта может помочь функциональным руководителям, и эта его роль будет принята с энтузиазмом. 7.5 СЛУЖБЫ ПОДДЕРЖКИ ПРОДУКТА И ПРОЕКТА Помимо сотрудников и средств, необходимых для разработки, производства, внедрения создаваемого продукта или его ввода в эксплуатацию, для помощи менеджеру проекта в выполнении его обязанностей требуются специальные службы поддержки управления проектом. Как говорилось в главе 4, обязаннос ти менеджера проекта включают достижение технических (производственных) целей в рамках установленных сроков и затрат. Организация специальных служб поддержки относится к подробно описанным в главе 10 функциям планирова ния и управления как так и Рис. 7.3 иллюстрирует организа продуктом, проектом. цию служб поддержки. Службы поддержки продукта Ниже приводятся службы поддержки продукта, важность которых несомненна и в которых задействованы специально назначенные в офис сотрудники проекта. Техническое управление: • управление проектированием и разработкой продукта. Системный анализ, инжиниринг и интеграция: • анализ и определение требований к продукту и его характеристик; • оценка и сбор проектной документации от всех участников проекта; • разработка и организация функциональных испытаний системы и продук та, оценка результатов испытаний; • отслеживание состояния проектной документации. 209 Службы поддержки продукта и проекта Отчеты руководителю подразделения Менеджер проекта Инженер консультант 35 1 15 5 Ввод Проектирование Поддержка Производство Численность продукта управления и разработка продукта персонала в эксплуатацию проектом продукта Производственный Менеджер Контролер Инженер координатор по внедрению проекта проекта проекта (вводу в эксплуатацию) 1 1 Группа Контроль Отдел ввода Отделы системного продукта в эксплуатацию производства анализа Разработка продукта 22 10 Программное Аппаратное обеспечение обеспечение Технический отдел Банк моделей Инженерные службы Ðèñóíîê 7.3. Ïðèìåð îðãàíèçàöèè áîëüøîãî ïðîåêòà â îáëàñòè ýëåêòðîíèêè ïî êîíòðàêòó ñ çàêàç÷èêîì Контроль продукции: • формулирование детальных требований к характеристикам продукции и обеспечение соответствия ее качества, надежности и долговечности при нятым стандартам; • документирование базовой конфигурации системы и продукта, контроль и документирование любых изменений этой конфигурации; • детализированная оценка себестоимости продукта и ее пересмотр по мере изменения проектной документации или появления информации, способ ной повлиять на эту оценку. 210 Организация функции управления проектами и офиса управления проектами Службы поддержки управления проектами Ниже перечислены специальные функции службы поддержки: • (подробное описание приведено в главе 9) администрирование контрактов обычно осуществляется администратором контрактов, привлеченным к выполнению проекта, но не входящим в офис проекта и не находящимся в прямом подчинении у менеджера проекта; • бухгалтерский учет в проекте выполняется сотрудником бухгалтерии, привле ченным к проекту и, как правило, не подчиняющимся напрямую контроле ру проекта или лицу, занимающему должность с эквивалентными полномо чиями; • специализированные службы поддержки управления проектом обычно выполня ются сотрудниками офиса проекта под руководством контролера проекта или лица, занимающего должность с эквивалентными полномочиями. Количество сотрудников, требуемое для поддержки управления проектом, всегда различно и зависит от размера и сложности проекта. Оно может варьи роваться от одного человека (менеджера проекта) с секретарем до 10, 15 и бо лее в очень крупных проектах. В общем и целом желательно, чтобы численность персонала проектного офиса была минимальной (см. главу 9). Сравнение централизованных и децентрализованных служб поддержки управления проектами В ситуации, когда одновременно выполняется несколько относительно малых проектов, невозможно обеспечить каждый из них отдельным менеджером про екта и штатом поддержки. В такой ситуации лицам, ответственным за проект – будь то линейный менеджер, менеджер проекта или менеджер мультипроекта, – требуется группа централизованной поддержки для планирования проектов и управления ими. Опыт показывает, что эффективность работы централизованной группы при поддержке больших проектов меньше, чем эффективность работы одного двух человек, выполняющих ее в режиме полной занятости. Поскольку выполнение этих функций предполагает доступ к жизненно важной информации о текущем состоянии или конечном успехе проекта, менеджер крупного проекта часто не склонен оказывать такое доверие сторонней группе. Если подобные услуги пред лагаются или навязываются со стороны, то менеджер проекта, скорее всего, будет скрывать от сторонних лиц ключевую информацию и игнорировать их стремление оказать поддержку. Это часто приводит к разработке собственных внутренних методов поддержки проекта, которые могут оказаться менее эффек тивными и более дорогостоящими, чем введение квалифицированных специа листов в офис проекта. 211 Службы поддержки продукта и проекта Централизованное планирование для мультипроектов В большинстве крупных компаний большие проекты существуют одновремен но с многочисленными малыми. Поэтому часто возникает потребность в цен трализованной службе поддержки, занимающейся планированием и контролем малых проектов, равно как и стремление назначить подобных специалистов в офисы больших проектов. Сотрудники централизованной службы могут ис пользоваться для подготовки специалистов, которые должны будут войти в состав офисов крупных проектов, а также для координации разработки усо вершенствованных методов, процедур и систем управления, включая системы мультипроектного планирования, распределения ресурсов и контроля. Концепция одной из наиболее завершенных структур организационного пла нирования и контроля, работающей при поддержке информационной системы планирования и контроля операций, представлена в главе 8. Такая структура может обеспечить очень эффективное содействие в планировании и управле нии менеджерам различных проектов. На рис. 7.4 приведен пример подобной структуры для поддержки мультипро екта в крупной телекоммуникационной компании. Отчеты руководителю подразделения 72 Централизованные планирование и контроль Конкретный проект менеджера проекта Численность персонала 16 10 26 18 Централизованное Контроль Службы Службы составление проекта продаж документирования программ и графиков спецификации составление надзор за всеми и чертежи; главных функциональными расписаний; отделами; переводы доклады утверждение об исключительных крупных ситуациях расписаний; график производства на 6 месяцев вперед 4 19 3 Службы работы Ценообразование Розничная с заказчиками и выписка счетов продажа разрешения на поставку; внешний анализ и контроль материалов Ðèñóíîê 7.4. Ïðèìåð öåíòðàëèçîâàííîãî ïëàíèðîâàíèÿ è êîíòðîëÿ â áîëüøîì ïîäðàçäåëåíèè 212 Организация функции управления проектами и офиса управления проектами Взаимоотношения офиса проекта, служб централизованного планирования и управления и служб обработки информации Эффективное использование передовых систем, подобных описанной в главе 14, требует предоставления квалифицированной информационной поддержки. Как уже говорилось в главе 5, такие услуги должны быть доступны для непосредствен ного использования как менеджерами проектов, так и контролерами проектов. Рис. 7.5 иллюстрирует данное положение. Компания Персонал централизованного планирования проектов Руководитель отдела Главные или директор исполнительные по управлению отделы проектами Планирование и контроль руководство, операций содействие Специализированное Менеджер другое проекта Компьютерная поддержка обучение, (микро ЭВМ или ПК) Системные Офис результаты проекта и информация Службы Поддержка Прямой доступ обработки данных управления на больших ЭВМ проектами Рисунок 7.5. Рекомендованные отношения между основным штатом управления проектом, службой планирования и контроля операций, офисом проекта и службами обработки данных 213 Схемы организационных взаимоотношений и сфер ответственности 7.6 СХЕМЫ ОРГАНИЗАЦИОННЫХ ВЗАИМООТНОШЕНИЙ И СФЕР ОТВЕТСТВЕННОСТИ Поскольку обязанности менеджера проекта и его отношения с другими сотруд никами не укладываются в рамки традиционной организационной теории и практики, для корректной иллюстрации этих отношений сложно использо вать привычные методы построения схем организационной структуры. Для графического представления ситуации с целью ее анализа и достижения бо лее глубокого понимания в разных организациях применяются различные виды нетиповых схем. Для управления проектом использовались и продолжают использоваться раз личные альтернативные организационные структуры. Большинство из них в ко нечном счете представляет собой то, что обычно называется “матричной” орга низационной структурой, при которой взаимосвязи проектного управления “накладываются” на основную организационную структуру, формируя матрицу отчетности, систему руководства, координирующие линии обмена информаци ей и взаимосвязей. Наиболее типичные формы получаемой в результате орга низационной структуры приведены на рис. 7.6–7.9. Матрица ответственности Традиционные схемы организационных структур и должностные инструкции, несмотря на их необходимость и ценность, имеют существенный недостаток: они не показывают, как в действительности работает та или иная организа ция. Был разработан и другой подход, позволяющий ближе подойти к реше нию этой проблемы. Он главным образом известен как построение линейных схем ответственности и используется для создания матрицы ответственнос ти. Чтобы добиться наибольшей эффективности указанного метода, члены рабочей группы должны принимать активное участие в разработке схемы для описания своих ролей и взаимоотношений. Такая совместная работа по зволяет разрешить разногласия и облегчает взаимопонимание, обеспечивая более эффективное функционирование организации. Матрица ответствен ности полезна для анализа и графического отображения структуры любой организации, но особенно эффективной она оказывается для определения ответственности и обязанностей в проекте при уже сложившейся организа ционной структуре. Этот важный инструмент более подробно рассматрива ется в главе 10. 214 Организация функции управления проектами и офиса управления проектами Компания Генеральный менеджер или отдел Повседневные функции персонала Техническая Менеджер Менеджер Менеджер Персонал Финансовый Маркетинг или инженерная линейки линейки Производство операций персонал проекта продуктов Б поддержка продуктов А Офис проекта Матрица Назначенные сбора информации в проект и координирования участники Рисунок 7.6. Обобщенная структура организации, в которой ответственность за проект несет менеджер проекта, работающий в режиме полной занятости. Матричные отношения включают в себя каналы передачи управленческих решений менеджера проекта в дополнение к функциям обеспечения коммуникации и координации Президент компании Генеральный Генеральный Генеральный менеджер менеджер менеджер дивизиона A дивизиона B дивизиона C Лаборатория Проект Лаборатория Лаборатория Проект Лаборатория Лаборатория A 1 X B 1 B 2 Y C 1 С 2 Субпроект Субпроект Субпроект Субпроект X Y 1 Y 2 Y 3 Отдел 1 Отдел 2 Отдел 3 Отдел 4 Отдел 5 Отдел 6 Отдел 7 Рисунок 7.7. Обобщенная структура организации, состоящей из нескольких дивизионов и выполняющей несколько проектов 8 « « » » Управление портфелями проектов, программами и мультипроектами С егодня в любой организации трудно найти такой проект, который бы су ществовал сам по себе, без взаимодействия с другими проектами. Дело в том, что в больших организациях управление проектами должно выполнять ся согласованно на четырех уровнях: портфеля проектов, мультипроектной про граммы, группы малых проектов и отдельных проектов. В данной главе рассматриваются первые три уровня. Процессы, системы, про цедуры и инструменты управления отдельными большими проектами обсужда ются в части II данной книги, а именно в главах 9–15. Эти уровни не являются взаимоисключающими: большой проект может находиться одновременно как в пределах программы, так и в пределах портфеля; в таком случае проект требу ет управления на всех трех уровнях. Малый проект может управляться как часть группы либо портфеля проектов. которую обычно можно встретить во многих больших Мультипроектная среда, организациях, вызывает трудности в управлении проектами на каждом из пере численных проектных уровней и на каждом уровне функциональной организа ции. Основные проблемы возникают вследствие соперничества между проекта ми и внутри них за ресурсы и внимание руководства. Учитывая, что в мире не существует организации, обладающей неограниченными ресурсами, запланиро вать и выполнить все мыслимые проекты не представляется возможным. Даже если не брать в расчет ресурсные ограничения, многие проекты зависят от ре зультатов и продуктов других проектов. На соответствующем уровне организа ции требования и приоритеты в мультипроектах должны быть сведены воеди но, благодаря чему удастся обеспечить выполнение всех проектов таким образом, чтобы достичь максимальной выгоды для организации в целом. 220 Управление портфелями проектов, программами и мультипроектами Необходимость интеграции требований в мультипроектах зачастую не осо знается в полном объеме. Как следствие, многие проекты управляются автоном но, независимо от существования прочих, а менеджер проекта при нехватке ресурсов растрачивает свои усилия, конфликтуя из за них с другими менедже рами. Наиболее компетентный или удачливый из менеджеров может добиться успеха в отдельно взятом проекте, но компания в целом многое теряет от не соблюдения сроков завершения других проектов. Основные цели управления мультипроектами (более высокого порядка по срав нению с целями управления одним проектом) перечислены ниже: • завершение всех проектов таким образом, чтобы обеспечивалось оптималь ное достижение стратегических целей организации; • определение как долгосрочных, так и краткосрочных приоритетов про ектов для принятия необходимых решений, связанных с распределением ограниченных ресурсов; • выявление и осмысление сравнительных значений рисков, сопутствующих каждому проекту, принятие решения о том, какие из них приемлемы для организации, и упреждающее управление этими рисками; • обеспечение всех проектов нужными ресурсами, включая кадры, помеще ния, материалы и финансы, при одновременном обеспечении эффектив ного использования ресурсов в утвержденных и выполняемых работах, не обходимых для завершения проекта; • согласование требований мультипроектов с другими повседневными опе рациями и процессами, не относящимися к проектам как таковым (напри мер, с производством отработанной готовой продукции); • разработка организационных схем и систем управления для удовлетворе ния постоянно изменяющихся требований проектов, с одной стороны, и обеспечения организационной стабильности, развития профессионализ ма и эффективности работы сотрудников, управляющих и поддерживаю щих различные проекты, с другой стороны. 8.1 УПРАВЛЕНИЕ ПОРТФЕЛЯМИ ПРОЕКТОВ Развитие и применение процесса управления портфелями проектов должны планироваться как управленческий проект. Наиболее разумный подход состоит в том, чтобы назначить директора по управлению проектами (если таковой су ществует) на должность менеджера этого управленческого проекта. Лиц, кото рые со всей очевидностью претендуют на то, чтобы войти в группу управления портфелями проектов, следует включить в состав команды проекта, определив 221 Управление портфелями проектов для них соответствующий круг обязанностей. Другие члены команды могут быть набраны из офиса управления проектами (PMO). Кроме того, в команду могут входить внутренние и внешние консультанты, имеющие опыт в области страте гического планирования и управления проектами. Цель проекта состоит в том, чтобы участники спроектировали, разработали и реализовали процесс управления портфелями проектов в определенных час тях организации. Содержание проекта точно показывает, в каких именно ее частях должен быть внедрен такой процесс. В ходе его первоначального внед рения создается группа управления портфелями проектов, куда входят старшие члены команды проекта. Группу утверждают формально, когда одобряется про ектирование процесса и утверждается его внедрение. Процесс управления портфелями проектов, описанный в главе 1, состоит из двенадцати основных шагов, приведенных ниже (каждый сопровождается ком ментарием): 1. Определение портфелей проектов, которые необходимо сформировать в организации. Эту стадию, в общем, следует рассматривать как часть процесса стратегичес кого планирования и управления в организации. Определенные портфели должны отражать стратегии развития организации, структуру отчетности, географическую локализацию рынков, линейки продуктов и другие важные факторы. 2. Определение категорий проектов в портфелях на основе критериев, неизменных для Список категорий проектов, существующих в компании, всей организации. должен готовиться командой проекта таким образом, чтобы он отражал фак торы, рассмотренные в главе 2. 3. Идентификация всех текущих и предлагаемых проектов и их группировка по кате Подготовка реестра проектов, рассмотренного в раз гориям и программам. деле 1.4, – необходимое условие проведения данной операции. Выполняе мая командой группировка утвержденных проектов по категориям обычно не вызывает сложностей. Создание и отбор новых проектов обсуждаются в следующих разделах. 4. Подтверждение того факта, что все проекты соотносятся со стратегическими целями организации. Команда внедрения проекта вместе с группой управле ния портфелями проектов должна сравнить цели и содержания всех про ектов в портфеле и удостовериться, что они напрямую связаны с одной или несколькими стратегическими целями организации. Если это не так, руко водителям высшего звена предстоит решить, следует ли отменить данный проект или оставить его в портфеле после соответствующей модификации. 5. Определение степени важности проектов в программах и портфелях. Команда внед рения проекта должна подготовить и изложить рекомендации, касающиеся 224 Управление портфелями проектов, программами и мультипроектами – утверждать включение новых проектов в портфели и сразу вслед за этим пересматривать приоритеты существующих проектов; – доводить информацию о текущих приоритетах проектов до их спонсо ров, а через спонсоров – до менеджеров программ и проектов, а также до соответствующих функциональных руководителей; • рекомендовать высшему руководителю и другим старшим менеджерам изыс кивать дополнительные финансовые и другие ресурсы, когда их требуют планирование и исполнение проектов, необходимых для достижения стра тегических целей организации в ограниченный срок; • выявлять благоприятные возможности совершенствования управления портфелями проектов и формулировать рекомендации по такому совер шенствованию, равно как и по улучшению других процессов, систем и ин струментов управления проектами. В больших организациях со сложной структурой обычно приходится управ лять не одним портфелем проектов, в результате чего имеют место перекрытие портфелей и их конкуренция за доступные ресурсы и внимание руководства. Исполнительный директор, генеральный менеджер или другой руководитель высшего звена, а также группа, управляющая несколькими портфелями, мо гут столкнуться с необходимостью разрешения конфликтов между портфе лями проектов – если только одна группа управления портфелями не несет ответственность за исполнение абсолютно всех портфелей проектов в органи зации. Отношения между группой управления портфелями проектов, спонсорами проектов, офисом управления проектами и менеджерами проектов/программ Группа управления портфелями проектов обеспечивает стратегическое руководство всеми программами и проектами, входящими в портфели проектов, которые находятся в ведении данной группы. Утвержденное главное расписание порт феля отражает распределение ключевых ресурсов и приоритеты проектов, установленные группой управления портфелями. Главное расписание содержит утвержденные целевые даты ключевых контрольных событий для каждой про граммы и каждого проекта. Эта информация передается спонсорам проектов и директору по управлению проектами. Спонсоры, назначенные в большие программы и проекты, информируют ди ректора по управлению проектами, соответствующих менеджеров программ и проектов и функциональных руководителей обо всех изменениях в выделении 225 Управление портфелями проектов ресурсов и о смещении приоритетов проектов. Спонсоры также доводят до све дения соответствующих менеджеров остальную уместную информацию (как внутреннюю, так и приходящую извне) политического, экономического, техни ческого и иного характера, способную оказать позитивное или негативное вли яние на находящиеся под их управлением программы или проекты. Директор по управлению проектами доводит информацию о выделении ресурсов, расстановке приоритетов и ключевых контрольных событиях до менеджеров всех тех программ и проектов, куда не был назначен спонсор. В зависимости от должностной инструкции директор по управлению проектами может исполнять обязанности спонсора во всех таких проектах. (неважно, управляют ли они большими оди Менеджеры проектов и программ ночными программами/проектами или рядом малых) получают стратегические указания от своих спонсоров либо от директора по управлению проектами. Ди ректор по управлению проектами должен предоставлять менеджерам программ и проектов рабочую поддержку и профессиональное руководство в области управления проектами, если это предусмотрено его должностной инструкцией. Каждый менеджер программ и проектов должен отражать все стратегические изменения распределения ресурсов, приоритетов и расписаний в планах, рас писаниях и оценках своих проектов, а также быстро производить оценку влия ния таких изменений на проекты и информировать об этом влиянии своего спон сора или директора по управлению проектами. Спонсоры проектов и директор по управлению проектами должны немед ленно передать полученную информацию в комитет по управлению портфе лями проектов для включения ее в следующую итерацию процесса планиро вания. Отбор проектов Степень сложности и процессы отбора новых проектов могут существенно варьироваться. В данной книге особое внимание уделяется следующим четы рем категориям проектов (из рассмотренных в главе 2) в сфере высоких техно логий: 1. Коммуникационные системы. 2. Информационные системы. 3. Разработка продуктов и услуг. 4. НИОКР. Отбор проектов в каждой из описанных категорий рассматривается ниже. Хотя любая категория проектов требует несколько иного подхода по сравнению 226 Управление портфелями проектов, программами и мультипроектами со всеми остальными, процесс отбора для всех категорий, согласно отчету Ку пера (Cooper), Еджерта (Edgert), Кляйншмидта (Kleinschmidt) о результатах ис следования в данных отраслях, направлен в первую очередь на достижение сле дующих трех целей управления портфелями [24]: • максимизация целевой функции портфеля, каковой может являться долговре менная доходность, прибыль на инвестированный капитал/окупаемость (Return on Investment, ROI), вероятность успеха (см. главу 3); • достижение баланса: построение сбалансированного портфеля по ряду па раметров (в качестве параметров чаще всего выбираются риск/прибыль, простота/привлекательность), а также разбиение портфеля по типам про ектов, рынков и линеек продуктов (см. главу 4); • портфель проектов должен ха достижение стратегического соответствия: рактеризоваться стратегическим соответствием, то есть его цели и рас пределение ресурсов должны отражать бизнес стратегию организации (см. главу 5). “Ни одна из перечисленных выше трех целей не является доминирующей. Больше того, ни одна модель портфеля и ни один подход, как сейчас представ ляется, не позволяют достичь всех трех целей одновременно” [26, p. 29]. Дай (Dye) и Пеннипеккер (Pennypacker) подготовили весьма полезную под борку статей, где представлено очень большое количество принятых в различ ных отраслях методов и практических приемов управления проектами в общем и особенно – отбора проектов и расстановки приоритетов [32]. В этих статьях главный акцент делается на категории информационных систем, новых продук тов и НИОКР. Отбор проектов в категории коммуникационных систем Отбор проектов в данной категории производится как покупателями, так и по ставщиками новых коммуникационных систем. Только в редких случаях постав щик выполняет проект разработки подобной системы для внутреннего исполь зования. Отбор проектов в категории коммуникационных систем, производимый покупате Для покупателя новой коммуникационной системы решение о том, выпол лем. нять или не выполнять данный проект, мотивируется его стратегиями разви тия. Высшее руководство должно определить, каковы в настоящее время нужды компании по части коммуникации и какими они станут в будущем, а затем вы делить на удовлетворение этих нужд необходимые финансовые ресурсы. Кро ме того, следует выделить определенные внутренние ключевые ресурсы (в част ности, специалистов по коммуникациям и информационным технологиям) на 227 Управление портфелями проектов планирование и выполнение данного проекта. Покупатели коммуникацион ных систем существуют во всех отраслях как частного, так и государственного сектора. Наиболее трудная для покупателя задача – выбор между двумя или более кон курирующими предложениями от различных поставщиков. Основные критерии, на которых будет основан этот выбор, – цена, характеристики и возможности системы, репутация поставщика и прошлый опыт, используемые технологии и совместимость с существующим коммуникационным оборудованием, дата по ставки, гарантии качества и послегарантийное обслуживание. Перечисленные критерии образуют основу для анализа рисков новых проектов. Отбор проектов в категории коммуникационных систем, производимый постав Продавцы или поставщики коммуникационных систем используют щиком. процесс отбора, существенно отличающийся от вышеописанного. Поскольку проекты названной категории составляют немалую часть основного бизнеса (а возможно, что и весь бизнес) этих людей, они постоянно ищут потенциаль ных покупателей и убеждают их подавать запросы на технические предложе ния (Request for Proposals, RFP), а еще лучше – на подписание контракта без рассмотрения альтернативных предложений. Когда поставщик получает запрос на техническое предложение, он тщательно изучает его с целью определить, имеются ли у него возможности, необходимые для реализации данного запро са в полном объеме и в указанный срок, и будет ли эта реализация выгодна для него. Отбор новых проектов, которые войдут в технические предложения, – кри тически важный шаг в процессе принятия решения поставщиком. Анализ рис ков поставщика должен рассматривать не только планирование и исполне ние собственно проекта как такового, но и – в том случае, если техническое предложение будет принято несколькими покупателями, – ситуацию, когда поставщик не сумеет выделить количество ресурсов, достаточное для того, чтобы поставить систему в срок всем покупателям сразу. А такая ситуация вполне может возникнуть, поскольку любой поставщик неизбежно вынуж ден отправлять большее количество предложений, чем будет принято, ибо он не может ожидать стопроцентного принятия своих предложений. Те по ставщики коммуникационных систем, которые выжили в конкурентной борь бе и добились процветания, на своем нелегком опыте знают, что управление проектом, уж если его хотят сделать эффективным, должно начинаться на ста дии подготовки технического предложения. Иными словами, они применяют систему управления жизненным циклом проекта (Project Life Cycle Management System, PLCMS), описанную в разделе 3.6, уже во время подготовки своего пред ложения. Как только контракт подписан, начинается работа над проектом, и обе сто роны – покупатель и поставщик – должны сотрудничать друг с другом в ходе 228 Управление портфелями проектов, программами и мультипроектами его планирования и исполнения, ибо большинство проектов данной катего рии требует значительного участия и вклада обеих сторон. Однако окончатель ную ответственность за выполнение такого проекта, как правило, несет по ставщик. Отбор проектов в категории информационных систем В большинстве организаций потребность в проектах информационных сис тем превышает возможности, обеспечиваемые наличными финансовыми и спе циализированными ресурсами. Зачастую пользователи информационных сис тем в организациях постоянно направляют запросы на выполнение таких проектов. В процессе отбора необходимо определить, какие проекты из мно жества возможных следует добавить в портфели и утвердить их финансирова ние и исполнение. Практически все проекты в данной категории предназна чены либо для улучшения внутренних бизнес процессов организации, либо для предложения новых услуг внешним заказчикам, хотя для планирования и ис полнения многих проектов этой категории могут использоваться услуги внеш них поставщиков программных продуктов на контрактной основе. Проек ты новых информационных систем, нацеленные на подготовку аппаратного и/или программного обеспечения для продажи другим пользователям, отно сят к категории проектов по разработке новых продуктов и услуг, рассматрива емых ниже. Миллер (Miller) выделяет четыре области, где выработаны типовые крите рии, способные помочь организациям в их выборе между несколькими проекта ми в сфере информационных технологий (1997, p. 56): 1. Заказчик. Достижение обязательств, определяемых необходимостью. 2. Соответствие целям и задачам компании: Стратегия. • рентабельность – измерение экономии средств, к которой способно при вести выполнение информационного проекта; • улучшение процессов – способность к своевременному улучшению биз нес процессов; • удовлетворение наемных работников. 3. Технология. Способность удовлетворять техническим требованиям: • ключевая компетенция – способность организации выполнить проект; • ценовая конкурентоспособность – возможность найти конкурентоспо собное решение; • интеграция с существующими технологиями. 4. Поставка. Способность осуществить поставку продукта по расписанию, в рамках бюджета и в соответствии с требуемым качеством. 229 Управление портфелями проектов Бриджес (Bridges) рекомендует, взяв за основу приведенные выше соображе ния, сформировать 12–15 критериев для принятия окончательного решения по отбору информационно технологических проектов [8]. Отбор проектов в категории новых продуктов и услуг Как и в случае с проектами информационных систем, “количество идей о про изводстве новых продуктов и задумываемых с этой целью проектов во много раз больше, чем количество проектов, которые можно коммерчески реализо вать при имеющихся ресурсах. Более того, львиная доля таких проектов вооб ще непригодна для коммерческой реализации. При идеальной организации процесса отбора руководство компании в состоянии заблаговременно опре делить наиболее перспективные продукты и выделить ресурсы в соответст вующие проекты. Как следствие, уменьшится количество неудач, ошибки рас пределения ресурсов сведутся к минимуму, а прибыль будет максимальна” [22, p. 34]. Купер (Cooper) перечисляет четыре модели первоначального отбора проек тов по разработке новых продуктов: измерения выгод, экономическую, отбора проектов в портфель, маркетингового исследования [22, p. 36]. В ходе обширных исследований, проведенных Купером в различных отрас лях, были выявлены восемь факторов, способных повлиять на результаты но вых проектов: 1. Превосходство продукта над другими, качество, уникальность. 2. Соотношение ресурсов, требуемых продуктом, с ресурсами, которые спо собна предоставить компания. 3. Нужды, интенсивность развития, размер рынка. 4. Экономическая привлекательность продукта для конечного пользова теля. 5. Степень новизны для фирмы (влияние данного фактора отрицательно). 6. Технологическая совместимость с ресурсами, которые способна предоста вить компания. 7. Конкурентная ситуация на рынке (влияние данного фактора отрицательно). 8. Содержание продукта. Купер предлагает практический подход, состоящий из семи этапов, которым могут воспользоваться организации для разработки своей собственной модели отбора [22, p. 40]. В качестве примера коммерчески доступной компьютерной модели, основанной на системе оценок (баллов), можно привести модель New TM Prod 3000 (зарегистрированная торговая марка R. G. Cooper and Associates 230 Управление портфелями проектов, программами и мультипроектами Consultants, Inc.; www.prod dev.com), которая “основана на профилях и резуль татах нескольких сотен выполненных проектов разработки новых продуктов. Она может использоваться как в качестве средства диагностики, так и в каче стве средства прогнозирования. Модель основана на том, что профиль проекта разработки нового продукта является эффективным средством прогнозиро вания его успеха” (p. 67). Характеристики профиля включены в список восьми факторов, приведенный выше. Отбор проектов в категории НИОКР Данная категория включает в себя широкий диапазон проектов – от ненаправ ленных исследовательских до крайне узкоспециальных, связанных с разработ кой новых или улучшением существующих продуктов или услуг, а также с усовер шенствованием процессов. Проекты, которые со всей очевидностью связаны с разработкой нового продукта или услуги, как правило, должны быть отнесе ны к соответствующей категории (рассмотренной выше). Методы просеивания и отбора НИОКР проектов отражают ту фазу НИОКР, в которой пребывает конкретная идея или зарождающийся проект. Лэмберт (Lambert) выделяет три основных фазы НИОКР [55, pp. 388–389]: • фаза I – базовые (фундаментальные) исследования; • фаза II – анализ осуществимости и прикладные исследования; • фаза III – разработка или фаза усовершенствования (оптимизации). Как правило, результатом завершения фазы I является отчет об исследова нии или иной документ, а не физический продукт. Типичный продукт фазы II – прототип или лабораторный образец с сопроводительной документацией. В ка кой то момент на фазе III проект НИОКР превращается в проект разработки нового продукта или услуги. В этот момент он должен быть перенесен в соот ветствующую категорию и получить адекватное управление. Отбор проектов выполняется в начале каждой из перечисленных фаз. Хосли (Hosley) рекомендует “составить как можно больший список возможных проек тов, в максимальной степени отражающих сильные стороны компании, а также подготовить оценки потенциальных продаж, требуемых вложений, вероятнос ти успеха” [47, p. 386]. Следующий шаг заключается в том, чтобы “расставить приоритеты среди проектов, содержащихся в данном списке, таким образом, чтобы разрыв [между положением компании в данный момент и желаемым по ложением через десять лет. – заполнялся год за годом”. Так как большин Р. А.] ство НИОКР проектов вырастает в проекты разработки новых продуктов или услуг, методы, используемые для отбора последних, могут быть применены и для отбора проектов в категории НИОКР. 231 Расстановка и управление приоритетами проектов Общие правила отбора проектов Фрейм (Frame) излагает пять общих правил отбора проектов, соблюдение ко торых позволит улучшить результаты отбора [39, p. 180]: 1. Четко и откровенно определите для себя, что важно учитывать при отбо ре проектов. 2. Определите в явной форме процедуры отбора проектов, а впоследствии придерживайтесь их. 3. Будьте готовы отстаивать свои решения. 4. Сформируйте команду отбора проектов, члены которой будут представлять интересы различных заинтересованных сторон. 5. Вовлекайте ключевой персонал, занятый в проектах, в процесс отбора. Некоторые проблемы, свойственные моделям управления портфелями Управление портфелями проектов – процесс динамичный, имеющий дело с по стоянно меняющейся неконкретной информацией. Купер и другие авторы утверждают, что “модели портфелей «болеют» воображаемой точностью. Их об щая слабость состоит в том, что степень точности практически любой модели из числа изученных нами несопоставима с реальными возможностями людей предо ставлять надежные данные; иными словами, сложность моделей значительно пре восходит качество входных данных” [26, p. 30]. Кроме того, “многие модели порт фелей страдают информационной перегрузкой” [26, p. 33]. Совершенно очевидно, что процесс должен по возможности сохранять максимальную простоту, кото рая, однако, не приводила бы к его неспособности выполнять свою задачу. Как и в случае проектирования любого продукта или процесса, гораздо легче раз работать очень сложный и на первый взгляд впечатляющий процесс, который в конечном счете окажется неработоспособным, чем получить простой и изящ ный результат, который достигнет цели. 8.2 РАССТАНОВКА И УПРАВЛЕНИЕ ПРИОРИТЕТАМИ ПРОЕКТОВ В ситуации соперничества различных проектов за ограниченные ресурсы легко понять необходимость методики определения и переопределения относитель ных приоритетов каждого проекта. Однако разработка такой методики оказа лась весьма сложной задачей. 232 Управление портфелями проектов, программами и мультипроектами Необходимость расстановки приоритетов проектов Эффективное планирование каждого проекта и прогнозирование его ресурс ных требований могут выявить потенциальные конфликты с другими проекта ми при условии, что они также планируются эффективно. После выявления по добных конфликтов могут быть приняты решения либо о привлечении дополнительных ресурсов, либо о задержке или перепланировании одного или нескольких проектов. Для принятия таких решений необходимо определить приоритеты проектов. Прогнозирование потенциальных конфликтов – един ственный способ эффективного управления, который поможет избежать реаль ного конфликта в кризисной ситуации. К сожалению, такое планирование час то не приносит практической пользы в начале концептуальной фазы большинства проектов – главным образом из за того, что составление планов требует времени и расходов. Руководители неохотно выделяют средства для вложения в ранние фазы проектов, зная, что значительная доля проектов не пройдет дальше этих фаз. И все таки без адекватного планирования на ранних фазах принятие действительно обоснованных решений невозможно. Непредвиденные проблемы или потребности могут вызвать краткосроч ные конфликты даже в безупречно спланированных проектах. В этом случае сотрудник, распределяющий какой либо вид ограниченных ресурсов по про ектам, должен иметь точную информацию относительно их текущих приори тетов. Очень немногие организации располагают надежным методом решения дан ного вопроса. В отсутствие такого метода менеджерами и координаторами низ шего звена ежедневно принимаются многочисленные решения по относитель ным приоритетам проектов. Вполне возможна ситуация, когда в отношении двух разных проектов на разных уровнях принимаются противоречащие друг другу решения, а в результате страдают оба проекта. Следует иметь в виду, что в реальном коллективе не исключены трудности при перемещении установленных руководством приоритетов на низшие уровни орга низации (например, на тот уровень, где подаются заявки на отпуск материалов со склада). Тем не менее для эффективного исполнения решений руководства внедрение установленных приоритетов на нижних уровнях организации необ ходимо. Факторы, влияющие на приоритеты проекта Хотя относительная значимость факторов, влияющих на приоритеты проектов, различна и зависит от типа организации и рассматриваемого проекта, следую щий перечень включает наиболее важные показатели (не обязательно в поряд ке возрастания их важности): 233 Расстановка и управление приоритетами проектов • дата завершения или поставки и ее отдаленность; • риск штрафных санкций; • важность заказчика для организации; • конкурентный риск; • технический риск; • риск, обусловленный органами государственного регулирования; • риск для здоровья и ответственность за безопасность продукта; • спонсорство проекта; • окупаемость (прибыль на инвестированный капитал); • величина затрат, вложений и/или прибыли, а также сопряженный с ними риск; • влияние на другие проекты; • влияние на ассоциированные и дочерние организации; • влияние на конкретную линейку продуктов; • политический риск и риск ограниченности точки зрения при рассмотре нии проектов. Для того чтобы быть полезными с управленческой точки зрения, перечис ленные факторы должны быть преобразованы в модель той или иной формы, как будет показано в следующем разделе. Модели приоритетов Модели приоритетов варьируются от очень простых до очень сложных. Самая общая классификация может выглядеть следующим образом: есть проекты, ко торые финансируются, и есть проекты, которые ожидают выделения фондов. Однако более полезным с практической точки зрения представляется деление проектов на три класса: • приоритетные проекты – те, которые имеют преимущество перед другими. • – те, которые финансируются и находятся в активном нормальные проекты состоянии, но формально не имеют повышенного приоритета; • фоновые проекты – те, которые ожидают появления фондов или освобожде ния ресурсов. Басс (Buss) описывает использование модели с четырьмя сетками приоритетов, имеющих общую вертикальную ось, где отображается объем инвестиций (малый, средний, большой), и четыре раздельных горизонтальных оси, соответствующих 234 Управление портфелями проектов, программами и мультипроектами четырем областям, для которых также определяются значения (низкое, сред нее, высокое) [14, p. 188]: • финансовые выгоды; • нематериальные выгоды; • технические выгоды; • соответствие бизнес целям. Все проекты размещаются на отведенных для них местах на каждой из четы рех сеток, после чего определяется интегральный приоритет для каждого про екта. Среди сложных моделей приоритетов находятся те, которые используют раз личные математические методы взвешивания и вычисления рисков и выгод. Они часто зависят от исходных данных, при подготовке которых велик субъектив ный фактор, позволяющий получить обманчиво благопристойные результаты. При расстановке приоритетов проектов по разработке новых продуктов все рас смотренные выше (в связи с отбором проектов) соображения также широко ис пользуются с новыми моделями приоритетов. Правила низших приоритетов, используемые для разрешения межпроектных конфликтов по срокам и стоимости Опыт работы со многими проектами во многих отраслях промышленности по казывает, что только 15% операций проекта критически важны для завершения проекта в срок. Таким образом, с точки зрения управления мультипроектами, общие приоритеты проектов, рассмотренные выше, должны учитываться толь ко тогда, когда возникает конфликт между действительно критичными опера циями двух или нескольких проектов. Для использования данного подхода необходимо спланировать и составить расписание по каждому проекту так, чтобы можно было определить эти 15% операций проекта. Самый эффективный способ, обеспечивающий согласо ванность операций, – сетевое планирование с учетом ресурсной ограничен ности, рассмотренное в главе 10. При планировании таким способом двух или нескольких проектов появляется информация, которая позволяет применять различные правила низших приоритетов, приведенные в табл. 8.1. Разумеет ся, могут быть разработаны и использованы и другие подобные правила при оритетов. 235 Управление мультипроектными программами Òàáëèöà 8.1. Ïðàâèëà ðàññòàíîâêè ïðèîðèòåòîâ Конфликт операций в разных проектах Приоритет отдается... Критичных (с точки зрения ...проекту с самым высоким текущим расписания или ресурсов) приоритетом Критичных и некритичных ...критичной операции (независимо от общих приоритетов проекта) Некритичных и некритичных ...операции с наименьшим запасом времени либо с кратчайшим буфером критической цепочки (кратчайшей допустимой задержкой). Если запас одинаков, – то самой короткой или самой длинной операции. Если длительность одинакова, используются текущие приоритеты проектов либо предпочтение отдается операции с наибольшим количеством критичных ресурсов 8.3 УПРАВЛЕНИЕ МУЛЬТИПРОЕКТНЫМИ ПРОГРАММАМИ Как уже упоминалось выше, программы состоят из двух или более проектов. Классическое управление программами берет свое начало в сфере управления большими программами оборонного значения и в области аэрокосмических раз работок для NASA (American National Aeronautics & Space Administration – Аме риканское национальное управление по аэронавтике и исследованию косми ческого пространства). Обычно подобные предприятия требуют назначения менеджера программы на уровне спонсирующей ее правительственной органи зации, а на уровне каждого из частных подрядчиков, выполняющих проектиро вание, разработку, изготовление, сборку, испытания и другие необходимые операции, должны быть определены менеджеры проектов. Такие назначения необходимо произвести для каждой части программы, по которой заключены контракты с правительством. В некоторых случаях эти контракты настолько велики, что представляют собой, по сути, мультипроектные программы, в вы полнении которых участвует несколько субподрядчиков. Организации, имеющие дело с другими отраслями и предметными областя ми, обнаружили, что объединение взаимосвязанных проектов в программы 236 Управление портфелями проектов, программами и мультипроектами может быть полезным. Такие проекты должны иметь отношение к определен ной линейке продуктов, подразделению или географическому региону. Про екты, составляющие программу, обычно тесно связаны некоторым способом, помимо того что в них используются общие ресурсы. К подобным взаимосвя зям относятся логические зависимости – например, в случае, когда результат испытаний или продукт необходим для начала/завершения другой задачи либо операции. Программы такого рода, вероятно, можно уподобить небольшим портфелям. Сравнение управления программами с управлением проектами Сходство и различие между управлением программами и управлением проекта ми были рассмотрены в разделе 4.7. Программы могут не иметь собственного жизненного цикла, поскольку они состоят из двух или более проектов, у каждого из которых свой жизненный цикл. Программы обычно характеризуются большей продолжительностью, чем про екты, и могут выполняться в течение неограниченного времени, поскольку одни проекты завершаются, а другие добавляются. В результате назначение на долж ность менеджера программы подразумевает постоянную или, по крайней мере, более долговременную занятость, в отличие от назначения менеджера проек та. Это может затруднить сохранение непрерывной ответственности менедже ра программы и, в свою очередь, предполагает более жесткие требования к фор мированию и ведению всей необходимой документации о программе, чтобы ее новый менеджер смог воспользоваться накопленной информацией с целью успешного исполнения программы. 8.4 УПРАВЛЕНИЕ МНОЖЕСТВЕННЫМИ ПРОЕКТАМИ Эта книга ставит задачей прежде всего решение проблем, возникающих в не многих основных проектах, определенных в главе 2. Однако в равной мере важ ны проблемы, возникающие в среде с большим количеством относительно ма лых проектов. Такая ситуация типична для многих высокотехнологичных компаний, которые занимаются разработкой, производством и поставкой слож ных продуктов и систем. Рассмотрим пример, когда один или более контрактов с заказчиками требу ют поставки большого количества телефонных станций или коммутаторов и их установки в помещениях заказчика. Каждому из таких контрактов сопостав лен отдельный проект, требующий разработки оборудования, модификации 237 Управление множественными проектами программного обеспечения, поставок, производства, сборки, настройки под конкретные нужды заказчика, установки и тестирования. Эти перекрывающие друг друга задачи проходят через фазы маркетинга, инжиниринга, производ ства на одной или нескольких фабриках и выделяются в отдельные проекты только во время установки оборудования, которую выполняет персонал отде лов установки на нескольких географически разнесенных площадках. В такой ситуации невозможно и даже нежелательно назначать для проекта каждой те лефонной системы менеджера, отвечающего за проектирование, производ ство и установку. В некоторых случаях менеджер проекта может быть назна чен для проектирования, производства и тестирования подмножества однотипных коммутаторов или телефонных станций или для очень больших и сложных телефонных станций и систем. Согласно общепринятой практике, контролер назначается только на стадии установки коммутаторов или теле фонных станций в помещениях заказчиков. Даже если в каждый проект нельзя назначить менеджера, жизненно важ ным остается интегральное управление проектами – особенно в том случае, если дата перевода абонентов на новую телефонную станцию или коммутатор определена контрактом. Поскольку отдел оборудования телефонных станций служит преимущественно для выполнения таких повторяющихся (но не оди наковых) проектов, генеральный менеджер сохраняет за собой всю ответствен ность за управление ими. Это придает еще большее значение организационным методам и системам, обеспечивающим эффективное комплексное планирова ние и контроль всех проектов на всех фазах их жизненных циклов. Данная си туация очень близка к той, что имеет место в цехе единичного или мелкосерий ного производства. Каждый наряд на работы, циркулирующий в таком цехе, выписывается на подобную, но не идентичную работу. Программное обеспече ние для календарного планирования деятельности такого цеха существует уже много лет, и описываемые здесь подходы к выполнению большого количества малых проектов представляют собой всего лишь расширенные варианты этой концепции, дополненные функциями маркетинга, проектирования, производ ства и установки. В некоторых компаниях созданы службы централизованного планирования и контроля для обеспечения объединенного планирования маркетинга, инжи ниринга, производства и внедрения, а также для создания главных расписаний специально на случай работы над большим количеством малых проектов. Коор динация планов, главных расписаний и последующий контроль сроков исполне ния выполняются менеджером по планированию, подотчетным генеральному менеджеру. Такие службы полезны для обучения и подготовки сотрудников со специализированными навыками, необходимыми для управления службами под держки в крупных проектах. В табл. 8.2 приведены основные различия между двумя часто встречающимися ситуациями. 239 Управление ресурсами в проектах • повышение качества планирования, а также календарная привязка опера ций и прогнозирования ресурсных требований; • выделение из общей совокупности повторяющихся операций (моделей) планирования, которые можно использовать в разных проектах, тем самым упрощая процесс планирования; • возможность изменения расписаний операций в соответствии со взаимо связями проектов и ресурсных ограничений, согласно разработанным пра вилам приоритетов; • возможность эффективного использования компьютеров для получения своевременной, обоснованной информации, необходимой для управления мультипроектами. Концепция планирования и управления операциями мультипроекта более подробно рассматривается в разделе 8.6. Зависимости внутри проектов и между ними Проекты и операции внутри проектов могут быть связаны друг с другом тремя следующими основными способами: • через результат операции. Результат, полученный по завершении операции в проекте или задаче, должен быть доступен до начала операции в другом проекте или другой задаче; • через общую единицу ресурсов. Например, инженер должен сначала завершить операцию в проекте или задаче, прежде чем сможет начать новую опера цию в другом проекте или другой задаче; • в двух или нескольких проектах/задачах, через норму расхода общих ресурсов использующих единый пул ресурсов (например, группу слесарей водопро водчиков). Когда расход определенного вида ресурсов превышает возмож ности пула, проекты или задачи становятся взаимозависимыми из за огра ниченности запаса ресурсов. Первые две взаимозависимости могут быть представлены интерфейсными событиями и рассматриваются в части II (преимущественно в главе 13); третья подробно обсуждается в следующем разделе и в части II. 8.5 УПРАВЛЕНИЕ РЕСУРСАМИ В ПРОЕКТАХ Одна из частых причин задержки проектов, приводящая к штрафам и другим нежелательным последствиям, – попытка заключить больше контрактов и вы полнить больше проектов, чем позволяют имеющиеся ресурсы. Перерасход 240 Управление портфелями проектов, программами и мультипроектами бюджета также может иметь место в случае, когда при принятии обязательств по проекту и в ходе его исполнения не учитываются ресурсные ограничения. Поэтому управление ресурсами становится важным фактором для менедже ров проектов и мультипроектов, а также для участвующих в проекте функцио нальных руководителей. Управление ресурсами включает в себя следующие ас пекты: • оценка и прогнозирование требований к ресурсам по функциональным за дачам каждого проекта и суммирование этих требований по всем проек там. Для осуществления таких задач необходимо, чтобы планы и расписа ний операций проектов находились во взаимосвязи с оценками требований к ресурсам и информацией о фактических расходах; • своевременное и эффективное приобретение, обеспечение и распределе ние ресурсов; • планирование работы с учетом ограничений имеющихся ресурсов; • контроль использования ресурсов для успешного выполнения работы в со ответствии с планом проекта. Если говорить об управлении человеческими ресурсами, то между работой над одним или несколькими крупными проектами и работой над множеством мелких имеется одно важное отличие. В крупном проекте, как правило, су ществует возможность тем или иным способом получить требуемые ресурсы: нанять дополнительных сотрудников на постоянной или временной основе, при влечь субподрядчиков, консультантов, воспользоваться услугами агентств по подбору персонала. В ряде малых проектов доступные и всегда ограниченные ресурсы следует тщательно распределять, обеспечивая поддержку всех проек тов, а это часто труднее, чем увеличивать фонды за счет внешних источников. Ресурсы, которыми нужно управлять Управлять следует различными ресурсами, в том числе временем, финансовы ми средствами, людьми, помещениями, оборудованием и материалами. Время – это основополагающий ресурс, которым нельзя управлять, как другими. Тече ние времени имеет только одно направление. Упущенное время вернуть невоз можно. Его нельзя хранить или накапливать для последующего использования. Время – элемент, который в плане проекта взаимодействует со всеми другими ресурсами. Остальные ресурсы поддаются прогнозированию, перераспределению и управ лению с помощью соответствующих процедур, выработанных и использу емых во всех организациях для управления отделами, подотделами и другими 241 Планирование и контроль операций в мультипроекте организационными единицами. Однако практика показывает, что существую щих методик и процедур для выполнения задач по управлению этими ресурса ми часто бывает недостаточно. Процедуры и инструменты для управления ресурсами проекта Эффективные процедуры оценки, прогнозирования, распределения и контро ля ресурсов одного или нескольких проектов описаны в части II. Ввиду боль ших объемов подробной информациия в крупных проектах и мультипроектах единственным практическим средством для управления динамическими про цессами изменения планов, расписаний и распределения ресурсов часто явля ются компьютерные системы. В главе 5 рассматриваются возможности таких инструментов, а также их выбор и внедрение; в числе прочего описываются программные средства для управления ресурсами в масштабах предприятия (Enterprise Resource Planning, ERP). Планирование, календарная привязка и контроль проекта в условиях ограниченных ресурсов Сравнительно новые концепции критической цепочки и ресурсного критичес кого пути рассматриваются в разделе 10.17. Эти методы направлены в первую очередь на увязывание ресурсов с планами и расписаниями (см. приложение в конце книги). 8.6 ПЛАНИРОВАНИЕ И КОНТРОЛЬ ОПЕРАЦИЙ В МУЛЬТИПРОЕКТЕ Выполнение нескольких проектов (как больших, так и малых) часто требует вве дения функции планирования и контроля операций. Эта функция может быть введена в масштабах отдела, линейки продуктов или всей компании. Она выпол няется на уровне главного расписания всех контрактов и/или проектов и по зволяет осуществлять комплексное управление маркетингом, инжинирингом, снабжением, производством, инсталляцией и вводом в эксплуатацию (обычно в рамках конкретной линейки продуктов или подразделения). Такая функция в отдельно взятой организации, несомненно, будет полезной для управления про ектами и офиса управления проектами. Конечный результат ее использования выражается в следующем: 242 Управление портфелями проектов, программами и мультипроектами • совершенствуется поддержка планирования и контроля для каждого ме неджера проекта, что приводит к сокращению численности персонала в каждом офисе проекта (риски, связанные с чрезмерной централизацией такой поддержки применительно к большим проектам, были рассмотре ны выше); • укрепляются возможности разрешения конфликтов между проектами и кон троля относительных приоритетов проектов, особенно для большого коли чества малых проектов; • в большей степени унифицируются планирование и контроль, что дает выс шему руководству возможность рассматривать все проекты в комплексе; • улучшается прогнозирование требований всех проектов к ресурсам. Природа проблемы Руководство высшего звена должно быть уверено, что планирование ведется та ким образом, чтобы удалось достичь оптимальной корпоративной и проектной производительности. Чтобы быстро и качественно оценить последствия кон кретного компромисса, касающегося стоимости, и конкретной альтернативной стратегии действий, руководство должно своевременно получать адекватную информацию о производительности и об ожиданиях клиентов. Функции централизованного планирования не полностью удовлетворяют вы шеописанные потребности руководства, потому что, как правило, отсутствуют следующие возможности: • осуществлять постоянный мониторинг функционального планирования при достаточном уровне детализации; • точно и регулярно оценивать воздействие на корпорацию предполагаемых результатов, достигаемых в функциональных отделах; • своевременно и оперативно проводить количественный анализ результа тов альтернативных бизнес стратегий; • своевременно вносить изменения в планы, сравнивая доступные ресурсы с потребностями по контракту; • создавать расписания высшего уровня, отражающие сбалансированную и скоординированную нагрузку между инжинирингом, производством, тес тированием и установкой или операциями на территории заказчика. Необходимо такое планирование, которое позволит оценить планы функ циональных отделов и степень их влияния на эффективность корпорации и команды проекта, а также соответствие получаемых результатов контрак ту. Кроме того, необходимо применение достаточно мощных методик оценки 243 Планирование и контроль операций в мультипроекте обоснованности принимаемых решений и их соответствие условиям контрак та. При этом вышеуказанными возможностями должно располагать руководство достаточно высокого уровня, которое может предложить решения проблем, вы ходящие за пределы функциональных подразделений. Пути решения: планирование и контроль операций Основная идея, позволяющая приблизиться к решению очерченной выше про блемы, состоит в том, чтобы организовать планирование и контроль операций, обеспечив их вспомогательными системами поддержки. Эта идея подразуме вает: • оптимизацию корпоративных и проектных целей, которые касаются про изводительности (хода исполнения работ), за счет планирования процес сов маркетинга, инжиниринга, производства и ввода в эксплуатацию путем создания главных расписаний корпоративного уровня; • координацию процессов планирования в функциональных отделах путем мониторинга степени использования ресурсов, выявления функциональ ных зависимостей в проекте и расширения рамок планирования для обес печения целостного взгляда на проект; • постоянную оценку и сравнение возможностей организации с требования ми проектов, что подразумевает: а) прогнозирование производительности и сравнение ее с корпоративными и проектными требованиями; б) заост рение внимания на тех областях, в которых наблюдаются отклонения от плана и потому от руководства требуется принятие решений, связанных с потенциальной нехваткой или потенциальным избытком ресурсов; • разработку и внедрение вспомогательных систем моделирования для оцен ки вероятных результатов альтернативных действий и предложения выс шему руководству возможных альтернативных решений. Потенциальные преимущества Потенциальные преимущества внедрения функции планирования и контроля операций заключаются в следующем: • совершенствуются функциональные связи, что положительно сказывается на функциональной производительности; • улучшается общая производительность по контрактам и проектам; • при совершенствовании планирования и использования ресурсов повыша ется корпоративная производительность. 244 Управление портфелями проектов, программами и мультипроектами Примеры конкретных преимуществ: • сокращение продолжительности жизненного цикла проекта; • повышение прямой производительности труда; • повышение эффективности использования инструментального, испыта тельного и другого оборудования; • уменьшение количества требуемого оборудования; • снижение риска штрафных санкций по контрактам. В конечном счете эти преимущества приводят к увеличению количества про ектов, над которыми может работать организация, а также к возрастанию ее дохода и чистой прибыли без увеличения численности персонала и без допол нительных вложений. Обзор планирования и контроля операций В планировании и контроле операций отражено использование признанных концепций управления, сочетающихся с методами сетевого планирования. Это результат более широкого видения вышеописанной проблемы с точки зрения управления. Согласно такому видению, для внедрения систем планирования и контроля необходимо наличие соответствующей организационной структу ры; в ее отсутствие планирование и контроль не могут быть эффективными. Для решения проблемы планирования и контроля операций должны быть учтены организационные соображения и вопросы системного развития. Организационные вопросы Функция планирования и контроля операций должна быть подотчетна уров ню, который обеспечивает полную объективность и непредвзятость. Точное оп ределение места функции в конкретной организации будет зависеть от структу ры и размера последней. Понятно, что эта функция должна быть подотчетна либо уровню директоров, отвечающих за общее корпоративное планирование, либо менеджеру отдела или линейки продуктов, который отвечает за инжини ринг, производство и внедрение. В организациях, выпускающих несколько линеек продуктов, имеющих нор мальный производственный цикл более года и требующих для исполнения про екта вклада нескольких функциональных отделов, должно существовать не сколько отдельных служб планирования и контроля. Такие службы должны быть организованы для каждой линейки продуктов, а их координация должна осуществляться аналогичной службой, подотчетной уровню корпоративных менеджеров. 245 Планирование и контроль операций в мультипроекте Системы планирования и контроля операций играют роль, существенно от личающуюся от ролей, характерных для управления крупными проектами. Ме неджер проекта отвечает за большие отличающиеся друг от друга проекты. Если для управления проектом менеджер использует методы сетевого планирования, то сетевые планы проекта будут (просто обязаны для эффективного управления проектом!) иметь высокую степень детализации, что, как правило, делает их не применимыми к другим проектам. Напротив, планирование и контроль опера ций применяются к контрактам, имеющим высокую степень схожести и мень ший объем, чем те, с которыми имеет дело менеджер проекта. Менеджер планирования и контроля операций может, однако, внести значительный вклад в управление проектами, резервируя предназначенные для них ресурсы при фор мировании главного расписания проекта, обеспечивая активное взаимодействие функциональных отделов и поставляя большую часть плановой и контрольной информации, необходимой для крупных проектов. Вспомогательные системы (системы поддержки) Для организации планирования и контроля от систем поддержки требуются создание расписания и оценка стоимости операций, оценка планирования, рас пределение ресурсов. Взаимодействие организации и вспомогательных систем Концепция планирования/контроля операций и взаимодействия организаци онных и сервисных функций (функций поддержки) в проекте проиллюстриро вана рис. 8.1. Функция планирования и контроля операций предназначена для планирования, составления расписаний, мониторинга, генерации отчетов, кон троля всех заказов и контрактов (проектов) на уровне главного расписания. Набор взаимосвязей позволяет свести в единую сеть функциональные пла ны и расписания всех проектов. Информационные потоки в такой сети текут в двух направлениях: “сверху вниз” (от главного расписания) и “снизу вверх” (информация от исполнителей о ходе и состоянии работ). Сеть должна вклю чать в рассмотрение контрольные или интерфейсные события, которые явля ются общими как для системы планирования и контроля операций, так и для функциональных систем. Эти контрольные/интерфейсные события должны отвечать нуждам систем обоих типов. Опыт показывает, что оба компонента планирования и контроля операций – организационные функции и системы поддержки – должны разрабатываться и внедряться одновременно. Один элемент просто не будет функционировать без другого. Кроме того, преждевременное внедрение одного из них может при вести к весьма нежелательным результатам. 246 Подразделение, выполняющее работы Управление Функциональ ные отделы Установка и ввод Маркетинг Разработка Производство в эксплуатацию Заказы/ проекты портфелями Интегрированные Отдел Функция главные планы планирования планирования и расписания и контроля и контроля для всех заказов операций операций и проектов проектов, Взаимодействия Функциональные системы планирования отделы и контроля операций с функциональными системами программами Планирование и контроль маркетинга Планирование Планирование и контроль ввода Планирование и контроль и в эксплуатацию и контроль разработки мультипроектами производства Системы и процедуры детализированнного функционального планирования и контроля Ðèñóíîê 8.1. Îáùåå ïðåäñòàâëåíèå êîíöåïöèè ïëàíèðîâàíèÿ è êîíòðîëÿ îïåðàöèé 247 Планирование и контроль операций в мультипроекте Стандартные и уникальные контрольные события Бознак (Boznak) описывает систему планирования и контроля мультипроек тов, основанную на рассмотрении процесса, включающего в себя четыре фазы: проектирование, снабжение, строительство/тестирование и поставку/сопро вождение [7]. Эта система планирования содержит набор стандартных кон трольных событий, которые планируются и контролируются менеджером про екта, и набор уникальных для данного проекта контрольных событий, которые планируются и контролируются функциональными лидерами или функцио нальными руководителями проекта. Согласно предложенному Бознаком под ходу, менеджер проекта осуществляет мониторинг контрольных событий, которые могут быть определены по своей сути как стандартизованные, ко ординирующие (согласующие), ограниченные рамками бизнеса и обобща ющие. Функциональный же лидер проекта осуществляет мониторинг контроль ных событий, уникальных для данного проекта, координирующих (согласую щих), ограниченных рамками функциональных отделов и детализирующих по сути. Эта мультипроектная система вырабатывает несколько уровней и видов от четов: отчет об удовлетворенности заказчика (акт сдачи приемки); многоуров невый главный план, содержащий все проекты; детальные отчеты различных видов; отчеты операций управления, перечисляющие все контрольные собы тия; ежемесячный отчет о производительности, показывающий соответ ствие работ расписанию для каждого проекта и каждой функциональной орга низации. В одной организации может существовать много методов планирования, со ставления расписаний, мониторинга и контроля мультипроектов. Ключ к успе ху – существование согласованной, интегрированной, последовательной систе мы и унификация используемых систем. Т РЕБОВАНИЯ ВЫСШЕГО РУКОВОДСТВА Управление портфелями проектов, программами и мультипроектами В том, что касается управления портфелями проектов и мультипроектами, руководитель должен добиться следующего: • для каждого определенного портфеля проектов реализован хорошо определенный процесс управления портфелем; 248 Управление портфелями проектов, программами и мультипроектами • сформирована группа управления портфелями, исполняющая рас смотренные выше обязанности. Это необходимо для того, чтобы эф фективность процессов управления портфелями проектов в органи зации возросла; • управление ресурсами в мультипроектных условиях осуществляет ся с использованием доступных методик оценивания и распределе ния ресурсов; • системы планирования и контроля операций в мультипроектных и мультиконтрактных условиях внедрены в соответствующих под разделениях организации. ЧАСТЬ II « « » » Практика управления проектами Г лавы 9–16 содержат детальную информацию о случаях из практики, кото рую можно использовать в установленных методиках и процедурах управ ления конкретными проектами. Поскольку не имеет смысла приводить приме ры всех возможных проектов, которые могли бы быть интересны той или иной категории читателей, акцент в части II сделан на основные коммерческие проек ты и проекты разработки нового продукта в производственных компаниях. Од нако данный материал можеь быть адаптирован к другим типам проектов, выполняемых в других окружениях. Для простоты во всей части II будет использоваться термин “проект”, хотя в большинстве случаев он может быть заменен термином “программа”. Определе ния данных терминов приводились в главе 2. 9 « « » » Организация офиса проекта и команды проекта П одход, описанный в настоящей и последующих главах, применим в ти пичных ситуациях выполнения большого проекта, который включает раз работку, производство, сборку и тестирование сложных аппаратных и программ ных средств и систем. Рассмотрение проводится в предположении, что: • в проект или программу назначен менеджер с полной занятостью; • офис проекта организуется таким образом, чтобы численность его персо нала была минимально возможной при максимальном использовании со трудников функциональных подразделений, участвующих в проекте. В данной главе описаны функции офиса и команды проекта, работающих в условиях, указанных выше, а также обязанности ключевых действующих лиц проекта и их взаимоотношения. Как уже обсуждалось в главе 8, часто возникает ситуация, в которой за несколь ко проектов отвечает один менеджер или, при работе над множеством малых проектов, обязанности их менеджера исполняет руководитель подразделения либо другой генеральный менеджер. В любых других случаях в каждый проект назначается менеджер проекта. Именно тогда, как правило, назревает необхо димость создания централизованной службы планирования и контроля опера ций (см. раздел 8.6). 252 Организация офиса проекта и команды проекта 9.1 ФУНКЦИИ ОФИСА КОМАНДЫ ПРОЕКТА Офис проекта оказывает менеджеру проекта поддержку в выполнении им своих обя занностей. Таким образом, основные права и возможности этого менеджера, отно шения внутри организации и природа самого проекта будут влиять на структуру офиса проекта. Наличие или отсутствие других проектов и централизованной служ бы планирования и контроля операций также повлияет на организацию офиса. Команда проекта включает всех сотрудников функциональных подразделений, участвующих в реализации проекта, а также членов офиса проекта. Далее пере числены основные функции, которые возлагаются на команду в ходе работы: • управление; • проектирование и разработка продукта; • производство продукта; • поставки, закупки, заключение договоров с субподрядчиками; • инсталляция, тестирование и другие операции по вводу продукта в эксплу атацию. Взаимосвязи этих функций и менеджеров проекта представлены на обобщен ной схеме организации проекта (см. рис. 7.2). Каждая из перечисленных функ ций подробно рассматривается в следующих разделах. Управление Под функциями управления понимаются функции, обеспечивающие менедже ру проекта возможность выполнения его основных обязанностей – общего ру ководства и координации усилий по проекту на всех его фазах для достижения запланированных результатов в соответствии с установленными бюджетом и ка лендарным планом. Эти функции упоминаются в главе 7 и подробно обсуждают ся в оставшейся части книги. Проектирование и разработка продукта Основное назначение этой функции – подготовка всей необходимой документа ции (а часто и прототипа продукта или системы) для того, чтобы продукт мог быть произведен в необходимом количестве и в соответствии с установленны ми бюджетом и календарным планом. Для данной функции могут быть выделе ны следующие подфункции: • системный анализ, инжиниринг и интеграция; • проектирование продукта; • управление продуктом (качеством, стоимостью, конфигурацией). 253 Функции офиса команды проекта Системный анализ, инжиниринг и интеграция предполагают системные иссле дования, функциональный анализ и функциональное проектирование системы или продукта, координацию и объединение подробных чертежей и схем, в том числе функциональных и механических интерфейсов между основными подсис темами или компонентами продукта. Проектирование продукта включает в себя подготовку детальных инженерно технических чертежей и схем, а также процедуры разработки, необходимые для преобразования функциональных описаний в спецификации, чертежи и другие документы, которые могут быть использованы для производства, сборки, уста новки и тестирования продукта. Разработка продукта также может требовать производства и тестирования прототипа или лабораторного образца системы (продукта) с использованием опытного производства или производственных мощностей какой либо фабрики на основе субподряда. Управление продуктом предполагает контроль качества продукта с использова нием соответствующего персонала и процедур; управление стоимостью продук та, включающее методы стоимостного инжиниринга; управление конфигураци ей продукта с формированием некоторой базовой конфигурации (могут быть задействованы методы “замораживания” дизайна для принятия неизменного эта лона или базового плана); управление техническими изменениями; управление документацией. Термин “продукт” относится ко всем результатам проекта: аппаратным сред ствам, программным продуктам, документации, услугам по обучению и прочим услугам, производственным средствам и т.д. Новая организационная структура также может являться результатом проекта. В каждой конкретной ситуации в зависимости от многих факторов офис про екта может не выполнять ни одной из вышеперечисленных функций, касающих ся разработки и проектирования, выполнять часть этих функций либо же их все. Как правило, когда продукт является новым или нетипичным для подразде ления, ответственного за его разработку, либо когда возникают серьезные со мнения в том, что силами инженерно технических отделов работа будет прове дена эффективно и в срок, большая часть функций проектирования и разработки продукта возлагается на офис проекта с привлечением соответствующего пер сонала. Когда в проектировании и разработке продукта принимает участие не сколько инженерно технических подразделений (например, отделы разработ ки разных линеек продуктов или разные компании), то функции системного анализа, инжиниринга, интеграции и контроля над производством должны быть возложены на офис проекта. На рис. 7.3 представлен выполняемый по контрак ту проект разработки электронной телефонной станции, в офис которого на значено множество технических специалистов. Исключая только что рассмотренную ситуацию, вышеперечисленные инже нерно технические функции обычно выполняются членами команды проекта из инженерно технических подразделений при активной координации со сто роны менеджера проекта. 254 Организация офиса проекта и команды проекта Производство продукта Эта общая функция состоит в закупке материалов и компонентов, сборке, тести ровании и поставке оборудования, необходимого для выполнения проекта. Все перечисленное осуществляется производственными подразделениями компа нии, ответственной за выполнение проекта, или сторонними компаниями на основе субподряда либо заказа на поставку. Однако менеджер проекта должен координировать и объединять проектиро вание, разработку и производство продукта, с одной стороны, и операций по вводу продукта в эксплуатацию, с другой. Отсутствие должной интеграции функ ций – самая частая причина неудачного завершения проектов. Для достижения такого единства необходимо назначить в проект координатора по производству или лицо с эквивалентными полномочиями, выполняющее роль менеджера проекта по части производства. Это должен быть ключевой участник команды проекта, способный в режиме полной занятости заниматься одним боль шим проектом или несколькими малыми. Рекомендуется, чтобы координатор по производству оставался сотрудником соответствующего производственного подразделения. Когда несколько подраз делений или компаний выполняет значительную часть производственных опе раций, каждое должно иметь своего координатора по производству, причем одно из производственных подразделений следует назначить ведущим. Если выделить ведущее подразделение невозможно, координация производственных операций осуществляется офисом проекта. Поставки, закупки, заключение договоров с субподрядчиками Эта функция иногда рассматривается как подфункция предыдущей функции (про изводства продукта), однако обычно имеет и самостоятельное значение, что по зволяет выделить и рассмотреть ее отдельно. Для руководства всеми закупками и заключением субподрядов следует назна чить координатора по закупкам и заключению субподрядов или работника с эк вивалентными полномочиями. Статус такого лица должен быть равен статусу лица, координирующего производственные вопросы. Это должен быть сотруд ник отдела закупок, так как ему предстоит поддерживать повседневный контакт со всеми лицами, выполняющими функции снабжения. Инсталляция, испытания и другие операции по вводу продукта в эксплуатацию Многие проекты требуют ввода в эксплуатацию и испытаний продукта на местах, а некоторые подразумевают техническое сопровождение в течение определенного 255 Функции офиса команды проекта времени. В этих случаях необходим менеджер по вводу в эксплуатацию и сопро вождению. Если ввод в эксплуатацию, испытания и техническое сопровождение – часть проекта, то соответствующая фаза может быть выделена в явной форме, посколь ку этого требует сама природа проекта. Требует она и назначения ответственно го за данную фазу лица. Менеджер по вводу в эксплуатацию и сопровождению почти всегда является сотрудником отдела ввода в эксплуатацию (или отдела с аналогичными функциями), если таковой существует в организации, ответствен ной за исполнение проекта. Поскольку инженерно технические и производствен ные операции часто выполняются параллельно с операциями по установке, ру ководящая и направляющая роль менеджера по внедрению и сопровождению проекта продолжает сохранять свое значение и важность в течение выполне ния всех операций по вводу продукта в эксплуатацию. Однако общая ответствен ность за координацию всего проекта возложена на менеджера проекта. Назначение персонала в офис проекта Согласно общей рекомендации, численность персонала, назначенного в офис проекта под руководство менеджера проекта, должна быть минимальной. Такой подход позволит подчеркнуть ответственность каждого функционального под разделения за его вклад в проект и в максимальной степени сохранить все выго ды для каждого из функциональных подразделений. Это также обеспечит боль шую гибкость при формировании штата проекта, позволит избежать ненужных затрат на оплату труда персонала и уменьшит проблемы, связанные с перерас пределением персонала, высвобождающегося по мере выполнения тех или иных задач. В итоге менеджер сможет целиком посвятить себя проекту, вместо того чтобы следить за выполнением обязанностей раздутого штата офиса проекта. Если в организации разработаны и применяются адекватные процедуры пла нирования и управления проектом, то высококвалифицированный персонал сумеет осуществлять необходимые управление и контроль проекта при неболь шой численности офиса проекта. В отсутствие таких процедур обычно прихо дится формировать существенно больший штат, куда по возможности должно входить максимальное количество участвующих в проекте сотрудников функ циональных подразделений, находящихся в непосредственном подчинении у менеджера проекта. Этот дорогостоящий подход часто доставляет много не удобств, а также обостряет отношения между менеджером проекта и руководи телями функциональных подразделений, участвующих в проекте. Ниже перечислены специалисты, которые должны быть переведены в офис проекта на постоянной основе: • персонал, непосредственно вовлеченный в управление проектом; • работники, труд которых в режиме полной занятости необходим для про екта по меньшей мере в течение шести месяцев;