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

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

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

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

10.5 Разработка политики, процедур, инструкций

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

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

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

10.6 Разработка документооборота и использование информационной системы

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

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

10.6.1 Краткая информация о программном обеспечении управления проектами

Существует целый ряд относительно простых и сложных программных продуктов для управления проектами: «Microsoft Project», «Spider», «Open Plan», «Primavera» и ряд других. Данные решения упрощают процессы планирования, управления, контроля, модификации и внесения изменений, особенно при реализации крупных сложных проектов. Однако они не определяют целей и концепции проекта, не устанавливают приоритетов, не выставляют бюджетных или временных требований, и не определяют контрольных точек, действий или взаимосвязей. Все это должно быть сделано руководителем проекта и его командой. Чего руководитель проекта может ожидать от таких программных продуктов?

Как правило, легкости разработки и внесения изменений в календарно-сетевые графики, а также расчета резервов и критического пути.

Возможности визуализации информации на экране.

Легкости в создании смет и легкости доступа ко всей информации по проекту или проектам для подготовки отчетов.

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

Легкости разработки различных сценариев проекта.

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

Перечисленные возможности имеются у всех существующих систем. Кроме того, во всех ассортиментных предложениях, присутствующих на рынке предложений, существуют три основные разновидности: упрощенный вариант для высшего руководства (легкий в применении, позволяющий обобщать и иллюстрировать данные, осуществлять процедуры планирования сверху вниз); базовый (или профессиональный) вариант для руководителя портфеля проектов (или одного проекта) или менеджеров команды, где имеются все возможности по управлению, включая временное, ресурсное, стоимостное планирование, анализ рисков и т. д.; и веб-вариант для работы через Интернет. Выбирая продукт, среди основных требований можно предъявить следующие:

общее мнение о продукте, его имидж, популярность;

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

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

ценовая политика;

техническая поддержка;

обучение;

информация о фирме производителе;

назначение, специализация;

мощность (в управлении проектом) и ряд других.

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

«Microsoft Project 2003», продукт Microsoft Corporation, принадлежит семейству Office. В 2007 году произошел переход на новую версию. Имеет все достоинства привычного интерфейса Microsoft, те же знакомые принципы работы. Существует локализованная русская версия. По использованию в мире и в России - продукт номер один среди систем офисного класса, имеет более 15 млн. пользователей. В большей степени продукт предназначен для управления небольшими проектами. Универсален в применении к проектам различной природы. Обладает очень широкой поддержкой, существуют доступные книги и курсы обучения. Практически в каждом крупном городе России можно найти поставщика. По существующей статистике, компания, приступающая к управлению проектами, постепенно и осторожно выбирает для первых проб именно этот продукт. Проработав некоторое время, приходит понимание более осознанного выбора. Продукт особенно часто применяется в ИТ-проектах.

«Spider Project» является российской разработкой и поддерживается компанией Spider Technologies Group. По своим возможностям является полным конкурентом «MS Project», хотя и есть ряд отличий. Занимает второе место в России по популярности после конкурента. Ценовая ниша такая же. Поставка осуществляется напрямую компанией, которая дальше и сопровождает внедрение и обучение. Учитывает ряд российских особенностей, например использование нормативно-справочной информации - о производительностях ресурсов, стоимостях. Часто применяется в строительных проектах.

«Open Plan Desktop 3.1» разрабатывается компанией Deltek. Существует локализованная русская версия. В России поддерживается компанией А-Рrо-ject Technologies. Продукт значительно мощнее двух предыдущих, что также отражается и на его цене. Продукт интегрируется с ERP. Среди основных отраслей применения - строительство, крупное сборочное производство.

«Project Planner Prof my Primavera» предназначена для управления большими проектами и программами. В России распространяется компанией «ПМСОФТ». Также существует локализованная русская версия. Использование этого и предыдущего продукта предполагает большие затраты на внедрение и специальную службу дальнейшей поддержки. Отрасли применений аналогичны - строительство, крупное сборочное производство.

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

1. Неточно спланированная программа требует в 3 раза больше времени,чем предполагалось; тщательно спланированная - только в 2 раза.

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

Законы мира ЭВМ по Голубу

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

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

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

обсуждение идеи и получение поддержки руководства компании;

проведение первичной диагностики «Как есть»;

моделирование и утверждение состояния «Как должно быть»;

разработка и одобрение проекта внедрения;

проведение вводного обучения руководства компании пользователей;

запуск рабочих проектов на месте;

осуществление обратной связи, необходимая коррекция;

разработка начальных процедур, документации;

отработка документации;

проведение специализированного обучения;

пилотное использование ИСУП;

обратная связь, коррекция;

углубление внедрения и т. д.

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

10.7 Обоснование внедрения и объект для внедрения

При определении необходимости внедрения КСУП возникает самый первый и главный вопрос: нужно ли это делать? Будет ли это помогать текущим процессам? Подходит ли бизнес и сама компания для управления проектами? Оптимальны ли предлагаемая стратегия внедрения и само решение? Задайте вопрос своим подчиненным, хотят ли они получить некоторые рамки и ограничения при управлении проектами, комфортно ли им будет работать при наличии инструкций и шаблонов, общего языка? При правильной постановке вопроса большинство ответов будут положительными. В условиях растущей конкуренции применять проектные подходы надо, и лучше делать это в рамках определенной формализации - тем более что в России существует генетическая предрасположенность к работе под чьим-то руководством (батюшки-царя, начальника, президента) и в рамках процедур и инструкций. Однако это не только русская специфика - целый ряд зарубежных компаний использует такие внутренние регламенты и системы управления проектами (Oracle, IBM, Pricewaterhouse Coopers, Andersen Consulting, SAP AG, Siemens).

Наилучшим объектом для внедрения КСУП являются не основные бизнес-процессы (которые опасно подвергать влиянию новой методологии в первую очередь), а вспомогательные. В рамках последних довольно легко формализовать какой-либо проект для пилотного использования, например проект развития.

10.8 Разработка стандарта по управлению проектами

Общие соображения по созданию стандарта

Управление проектами в общем смысле (без привязки к отрасли) регулируется так называемыми внешними рамочными документами общего характера. Чаще к таким внешним стандартам в российских компаниях относятся: «РМ Body of Knowledge» (PMBoK, версия 2004 года), признаваемый многими международным стандартом де-факто; стандарты качества системы ISO, придавшие ряду наиболее важных положений РМВоК статус стандарта де-юре, и International Competence Baseline (ICB), декларируемые европейской IPMA и известные в России больше как «Основы профессиональных знаний, национальные требования к компетенции специалистов по управлению проектами».

Основной смысл и содержание перехода от рамочных стандартов к конкретным регламентам (стандартам) компании состоит в их специализации под проекты и бизнес компании и максимальной детализации.

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

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

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

Регламент, как правило, разрабатывается в предварительной версии, рассматривается руководством компании и подразделений, тестируется, уточняется и утверждается на короткий период 6-12 месяцев. После накопления практических замечаний он корректируется и переутверждается.

10.8.1 Состав регламента или стандарта (примерный)

По своему содержанию регламент или стандарт может включать следующие основные части:

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

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

Описание политики компании при:

отборе проектов и растравлении их по приоритетности;

ресурсном обеспечении проектов;

мотивации;

построении коммуникаций между участниками проектной деятельности;

управлении рисками в проектах компании;

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

работе с поставщиками.

4. Детальные процедуры и инструкции, привязанные, например, к жизненному циклу проектов компании.

5. Шаблоны и формы всех типовых документов, используемых при управлении проектом.

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

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

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

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

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

Мероприятия по внедрению КСУП традиционно охватывают гораздо более широкий спектр задач, чем просто установка программного обеспечения: от внедрения идеологии, формализации процедур сбора и хранения управленческой информации до осуществления изменений в организационной структуре управления и перераспределения обязанностей.

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

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

Цели проекта и ожидаемые результаты не определены заранее или определены не в полном объеме. Жесткие временные ограничения, нетерпеливость или непоследовательность руководства могут не позволить реализовать цели проекта в полном объеме.

Планирование ввода в эксплуатацию всех компонентов КСУП одновременно. Это может привести к значительному усложнению проекта и делает проблематичным стабилизацию работы системы в целом.

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

Таким образом, некоторые общие рекомендации по внедрению КСУП будут следующими:

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

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

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

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

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

10.10 Краткий план внедрения

Базовая стратегия внедрения включает следующие основные элементы:

определение основных потребностей бизнеса и особенностей организации;

диагностика существующих подходов и бизнес-процессов;

определение текущего состояния проектного управления;

разработка и согласование модели «Как есть»;

разработка и утверждение модели «Как должно быть»;

формулирование и согласование плана проекта внедрения;

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

финансирование изменений;

создание начальных элементов внутренней инфраструктуры управления проектами:

а) назначение должностного лица - заместителя директора или другого должностного лица по управлению проектами и формализация группы существующих руководителей проектов;

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

в) создание аналитического центра по представлению проектной информации (возможно совмещение со службой);

г) выделение проектного офиса (не всегда);

подготовка кадров в виде базового обучения;

разработка механизма функционирования структур;

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

разработка внутрифирменного стандарта или регламента по управлению проектами;

внедрение матричной структуры управления на ряде пилотных неосновных проектов;

апробация стандартов и инфраструктуры на пилотных проектах;

переход к постепенному использованию системы управления проектами на других проектах;

фиксирование дальнейшей разработки стандартов и инфраструктуры.

10.11 Проблемы внедрения проектного управления в компанию

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

10.11.1 Отсутствие должной поддержки руководства

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

10.11.2 Отсутствие системы делегирования полномочий

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

Из практики

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

10.11.3 Отсутствие системы стимулирования персонала

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

10.11.4 Высокие риски внедрения

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

10.11.5 Отсутствие подготовленных специалистов, информации

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

10.11.6 Высокая стоимость внедрения

Стоимость внедрения включает в себя следующие компоненты:

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

стоимость консультационной поддержки всего этапа внедрения;

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

упущенная выгода от неэффективных или нереализованных проектов во время внедрения;

стоимость работы участников проекта внедрения и т. д.

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

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

10.12 Модель зрелости управления проектами и зачем это нужно

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

Для демонстрации существующих уровней развития компании по отношению к управлению проектами приведем три наиболее популярные модели уровней зрелости компании.

1. Модель зрелости Г. Керцнера, который определил три следующих уровня.

Уровень 1 - «Терминология». Организация осознает важность управления проектами и необходимость глубокого усвоения основных знаний и изучения сопутствующей терминологии в этой области. Об этом свидетельствуют следующие признаки:

имеются отдельные практики успешных проектов;

имеются отдельные «очаги интереса» к управлению проектами;

есть понимание на уровне руководства общей полезности применения методов;

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

введен общий учет реализуемых проектов.

Уровень 2 - «Общие процессы». Организация осознает важность определения и разработки общих процессов для того, чтобы успех одного проекта мог быть повторен при выполнении других. Об этом свидетельствует:

осознание ощутимых выгод от использования управления проектами;

поддержка управления проектами на всех уровнях управления;

наличие общей методологии управления проектами;

наличие системы контроля по проектам;

разработка систематического плана по развитию персонала в области управления проектами;

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

Уровень 3 - «Единая методология». Организация осознает важность синергетического эффекта, возникающего при интеграции управления проектами с другими методологиями (управление качеством, процессами и т. д.). Об этом свидетельствуют:

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

поддержка со стороны организации (на уровне корпоративной культуры, а не только на уровне управления);

балансировка степени формализации управления проектами;

постановка процедур накопления и распространения лучших практик управления проектами.

2.Модель Организационной Зрелости Управления Проектами (Organization Project Management Maturity Model - ОРМЗ) содержит три взаимосвязанных элемента:

элемент ЗНАНИЕ (KNOWLEDGE) - лучшие практики по управлению проектами, характеризующие те или иные уровни организационной зрелости УП;

элемент ОЦЕНКА (ASSESSMENT) - инструмент, помогающий организациям оценить текущую зрелость по УП и определить области улучшения.

Если организация принимает решение развивать практики управления проектами и переходить на новые, более высокие уровни зрелости по УП, то в дело вступает:

*элемент УЛУЧШЕНИЕ (IMPROVEMENT), который помогает компаниям построить схему развития управления проектами таким образом, чтобы обеспечить максимально эффективное достижение своих стратегических целей.

3.Пятиуровневая модель (РМ)2 - (Project Management Process MaturityModel), использующая следующие пять уровней зрелости.

Первый (начальный) уровень зрелости характеризует стихийное освоение базовых процессов управления проектами.

В организации нет формально принятых процедур управления проектами.

Планы выполнения проектов не создаются.

Работы слабо определены по содержанию, объему и стоимости.

Процессы управления проектами полностью непредсказуемы и слабо контролируемы.

Высшее руководство часто не понимает ключевых вопросов управления.

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

Второй уровень зрелости, или уровень индивидуального планирования проектов.

Применение в организации отдельных неформализованных и некомплектных процедур управления проектами.

Руководители проектов частично применяют и контролируют процессы управления.

Однако в каждом конкретном проекте планирование и управление зависит от индивидуального подхода его руководителя.

Третий уровень зрелости, или уровень управления.

*Предполагается частичная формализация процессов управления проектами и использование базовой системы планирования и управления проектами в организации.

Осуществляется систематический и структурированный подход к планированию и контролю.

Проектный персонал подготовлен для применения методологии и инструментальных средств управления проектами.

Четвертый уровень зрелости, или уровень интеграции.

Полная формализация с официальным утверждением всех процессов управления проектами и документированием соответствующей информации.

Эффективное планирование, управление и контроль всех выполняемых проектов.

Процессы управления проектами хорошо определены, количественно оценены, поняты персоналом и внедрены в практику.

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

*Формируется фундамент для объективного принятия решений.

Пятый уровень зрелости, или уровень совершенствования.

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

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

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

10.13 Портфель проектов

«Корпорации становятся проектно-ориентированными», - утверждает один из идеологов науки управления проектами Том Питерс. Это означает, что многие современные компании переходят от функционального управления к проектному, что подразумевает наличие не одного, а целого пула проектов, подлежащих реализации. Все проекты, согласно требованиям, изложенным в гл. 3, должны соответствовать целям и стратегическому плану компании, видению руководства, требованиям окружающей среды, специфике существующего производства, программам развития и т. д. Они могут иметь различную природу или принадлежать к различным типам. Например, одновременно могут реализовываться бизнес-проекты (увеличение числа продаж, открытие новых розничных точек, увеличение доли региональных продаж) и проекты развития (развитие новых продуктов и услуг, выход на новые рынки, обучение и реструктуризация).

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

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

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

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

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

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

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

10.14 Управление портфелем проектов

«Управление проектами» как практика менеджмента давно уже используется российскими, и тем более западными компаниями, однако что такое «управление портфелем проектов», как это внедрять и зачем это нужно - знают только немногие «продвинутые» управленцы. В 2006 г. институт проектного управления (РМ1) разработал и выпустил новый стандарт по управлению портфелем проектов «Portfolio Management». Стандарт является дополнением к третьему изданию РМВоК и Organizational Project Management Maturity Model (ОМРЗ). Стандарт представляет собой практическое пособие по внедрению корпоративной системы управления портфелем проектов. Сами разработчики полагают, что использование практик управления портфелем проектов позволит компании достигать своих стратегических целей, оптимально расходуя свои ограниченные ресурсы; позволит не только «эффективно» выполнять проекты, но и выполнять «эффективные» проекты.

Управление портфелем проектов невозможно без опыта использования в компании методологии управления проектами, уровень развития которой можно проверить через «Модель зрелости управления проектами» (Organizational Project Management Maturity Model (ОРМЗ)), также являющейся стандартом PMI. После того как вы провели тестирование своей корпоративной системы управления проектами и ваш уровень был признан достаточным или высоким, вы смело можете переходить на этап внедрения управления портфелем проектов.

Инструментарий управления портфелем проектов является новшеством для многих компаний. По результатам опроса, проведенного Center for Business Practices, 70% организаций на западе начали внедрение управления портфелем проектов сравнительно недавно - не более двух лет назад. Можно привести следующий список основных положительных результатов, которых добились компании, участвовавшие в опросе:

большее соответствие проектов стратегии компании - 70,4%;

реализация только «правильных» проектов - 57,4%;

расходование средств только на «правильные» задачи - 46,3%;

рост экономии на издержках - 42,6%.

К вышеперечисленным преимуществам управления портфелем проектов можно также добавить: более оптимальное распределение ресурсов, отказ от невыгодных проектов, отказ от реализации слишком большого количества проектов одновременно, рост прибыли, управление «пропусками» (gap) в проектах.

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

Большинство компаний (87%) разработали собственную систему управления проектами, и только 13,2% внедрили программный продукт. В доминирующем количестве компаний (44,4%) управление портфелем проектов охватывает все уровни (производственный и управленческий) организации, а в 20,4% - только производственный уровень.

Около трети компаний практикуют и другие виды портфельного управления (Portfolio Management) - такие как управление продуктовой линейкой (35,8%), управление портфелем активов (24,5%) и система управления внедрением (30,2%). Интеграция управления портфелем проектов с вышеперечисленными видами менеджмента крайне важна для достижения показательных результатов бизнеса.

В крупных компаниях (> $1 трлн. выручка), в отличие от средних ($100 млн. - $1 трлн. выручка) и небольших (< $100 млн. выручка), использование практик управления портфелем проектов более распространено: 50% больших бизнес-структур применяют управление портфелем проектов более двух лет, в сравнении с 14,2% и 21,1% средних и малых компаний соответственно. Обусловлено это тем, что чем крупнее бизнес-единица, тем сложнее в ней реализовывать функцию эффективного управления. Поэтому все инновации, призванные привести к росту прибыли и экономии на издержках, в основном апробируются крупными компаниями, чей опыт впоследствии перенимают более мелкие фирмы.

Чем крупнее организация, тем вероятнее, что она будет развивать и другие виды портфельного управления: 75% крупных компаний, по сравнению с 57,1% средних и 52,6% небольших, используют управление продуктовой линейкой, управление портфелем активов и другие управленческие модели.

Как в случае использования методологии управления проектами, так и при управлении портфелем проектов компании могут оценить свой уровень зрелости через модель зрелости управления портфелем проектов (Project portfolio Management Maturity Model). По итогам опроса, 90% компаний находятся на первом или втором уровне и ни одна компания не достигла четвертого или пятого. Но даже использование управления портфелем проектов не в полную силу (первый, второй и третий уровни) позволяет компаниям добиваться существенных положительных результатов (табл. 10.1).

Таблица 10.1 (в баллах)

Показатель	Первый уровень	Второй уровень	Третий уровень
Оптимальное распределение ресурсов	2,7	3,1	3,6
Отказ от невыгодных проектов	2,8	2,9	3,5
Расходование средств только на «правильные» задачи	3,1	3,5	3,8
Реализация только «правильных» проектов	3,4	3,5	3,6
Отказ от реализации слишком большого количества проектов одновременно	3,1	3,2	3,4
Большее соответствие проектов стратегии компании	3,3	3,4	3,6
Рост экономии на издержках	3,7	4,1	4,2
Рост прибыли	3,2	3,4	3,8
Управление «пропусками» (gap) в проектах	2,8	3,4	3,6

Таблица 10.1 отражает рост положительного эффекта от различных показателей при движении от первого уровня зрелости к третьему (ранжирование эффекта от 1 до 5).

Чем более зрелая модель управления портфелем проектов действует в компании, тем более развиты и другие методы портфельного управления: 80% организаций, находящихся на третьем уровне зрелости, используют управление продуктовой линейкой, портфелем активов, внедрением и др., в сравнении с 70,6% и 54,8% компаний второго и первого уровней зрелости соответственно.

Литература

ISO/TR 10006:1997 (E). Quality Management - Guidelines to quality in project management. (ИСО/ТО 10006: 1997 (E). Менеджмент качества. Руководство качеством при управлении проектами) (12/97).

Андерсен Э., Груде К., Хауг Т. Сфокусированное управление проектом. -- М.: ФАИР-ПРЕСС, 2006.

Арчибальд Р. Управление высокотехнологичными программами и проектами/Пер. с англ. под ред. А.Д. Баженова. 2-е изд. -- М.: ДМК Пресс, 2002.

Арчибальд Р. Управление высокотехнологичными программами и проектами / Пер. с англ. под общей ред. А.Д. Баженова. 3-е изд. -- М.: ДМК Пресс, 2006.

Афанасьев Н.В., Рогожин В.Д., Рудыка В.И. Управление развитием предприятия: Монография. -- Харьков: Издательский дом «ИНЖЭК», 2003.

Ахметов К. Практика управления проектами -- Microsoft Project Professional 2003. - СПб.: Питер, 2004.

Баттрик Р. Техника принятия эффективных управленческих решений. 2-е изд. / Пер. с англ. под ред. В.Н. Фунтова. -- СПб.: Питер, 2006.