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

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

Чтобы загрузить этот технический документ в формате Word, воспользуйтесь ссылкой Модель зрелости системы управления проектами: технический документ.

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

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

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

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

Клиент видит экраны, которые сформированы службами Windows SharePoint Services или отображают формы Microsoft Office SharePoint Server. В ходе презентации используется функциональность Active Directory или служб SQL Server Reporting Services. Демонстрируемый рабочий процесс может быть функцией сервера BizTalk Server или платформы Windows Workflow Foundation, а изображение на экране, возможно, сформировано в среде PerformancePoint. Поток данных может соответствовать плану демонстрации или сценарию использования, что помогает осознать потенциальные преимущества, но разобраться в том, какие технологии используются, намного сложнее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Даже для области "Дополнительные функции" существуют расширенные возможности. Наиболее популярные среди них — анализ рисков по методу Монте-Карло и интегрированная методология управления проектами (особенно в секторе ИТ).

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

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

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

  • Планы проектов, на которые можно положиться.

  • Проекты, ход выполнения которых точно отслеживается.

  • Все задачи, которые должны быть назначены ресурсам.

  • Полные и точные сведения о доступности ресурсов.

  • Отслеживание и количественная оценка всех внепроектных трудозатрат.

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

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

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

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

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

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

В результате некоторые организации, например, работающие в секторах НИОКР и ИТ, теперь рассматривают модель зрелости систем управления проектами совершенно в другом ключе:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Об авторе

Крис Вандерслуис (Chris Vandersluis) — основатель и президент компании HMS Software, расположенной в Монреале, Канада, которая является партнером Майкрософт со статусом Microsoft Certified Partner. Он получил степень по экономике в университете Макгилла и имеет более чем 30-летний опыт работы в области автоматизации систем управления проектами. Он много лет является членом Института управления проектами (PMI) и оказывал содействие в основании местных отделений группы Microsoft Project Users Group (MPUG) в Монреале, Торонто и Квебеке. Крис публиковался в таких изданиях, как Fortune, Heavy Construction News, журнал Computing Canada и PMI PMNetwork, а также ведет колонку в Project Times. Он преподает углубленный курс управления проектами в университете Макгилла и часто выступает на специальных мероприятиях ассоциации управления проектами в Северной Америке и по всему миру. Компания HMS Software является разработчиком системы TimeControl, предназначенной для учета рабочего времени в рамках проектов, и с 1995 г. является партнером со статусом Microsoft Project Solution Partner.

Вы можете написать Крису Вандерслуису по следующему адресу электронной почты: chris.vandersluis@hms.ca

Если вы хотите прочитать другие статьи Криса Вандерслуиса, посвященные управлению корпоративными проектами, посетите сайт EPM Guidance компании HMS (http://www.epmguidance.com/?page_id=39).

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

Были ли сведения полезными?

Спасибо за ваш отзыв!

Благодарим за отзыв! Возможно, будет полезно связать вас с одним из наших специалистов службы поддержки Office.

×