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

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

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

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

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

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

Введение

Я владею компанией, которая выполняет развертывание решения корпорации Майкрософт для управления крупными проектами (Enterprise Project Management, или EPM). Честно говоря, HMS Software делает намного больше. Мы также являемся независимым поставщиком программного обеспечения, однако я большую часть времени работаю с организациями среднего и крупного размера, консультируя их по развертыванию решения EPM. Некоторые проблемы характерны для технологии Майкрософт, но многие из них являются общими для всех компаний, с которыми я сотрудничал с 1983 г., когда начал работать в области ПО для управления корпоративными проектами. В этой статье мы поговорим о том, как можно спланировать развертывание решения EPM.

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

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

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

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

Что такое "управление корпоративными проектами"?

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

Схема, на которой перечислены различные аспекты EMP-решений

Я задаю вопрос: "Что такое EPM с вашей точки зрения?" В ответах часто упоминаются элементы, показанные на этом слайде. Рассмотрим эти ответы подробнее.

  • Базовое управление проектами   . "Для нас управление корпоративными проектами означает, что все сотрудники используют для управления проектами одни и те же методики и инструменты".

  • Управление корпоративными проектами   . "Этого для нас недостаточно, — может сказать кто-то. — Для нас управление корпоративными проектами означает, данные, связанные с управлением проектами, должны быть интегрированы. Нам нужно получать отчеты, в которых в сводном виде будут представлены наши расписания, и мы хотим управлять влиянием одних проектов на другие".

  • Управление портфелем проектов (PPM)   . "Речь идет об управлении портфелем проектов, — может сказать клиент. — Для нас управление корпоративными проектами — это управление на более высоком уровне, чем отдельные проекты. Мы хотим объединить проекты в портфели или группы для анализа и составления отчетов. Нам нужно отслеживать ход выполнения на сводном уровне и использовать промежуточные контрольные точки".

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

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

  • Бюджетирование и управление затратами   . "Для нас управление корпоративными проектами связано с деньгами. Мы составляем бюджет в начале года. Затем мы составляем бюджет для каждого проекта, и единственная важная вещь для нас — гарантировать, что расходы каждый месяц соответствуют плану".

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

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

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

  • Рабочий процесс   . "Мы представляем себе систему, в которой автоматизировано отслеживание не только задач, но и процедур. Мы бы хотели, чтобы руководители проектов заполняли веб-форму, чтобы запросить финансирование для проекта. Затем эта форма должна попадать к уполномоченному сотрудник, который может принять или отклонить запрос с помощью автоматизированной процедуры. Если запрос одобрен, проект должен сразу же быть внесен в корпоративную систему управления проектами. Мы хотели бы использовать такой же процесс для всех наших документов по проектам. Фактически нам нужно автоматизировать таким образом все процедуры, связанные с управлением проектами, используя управление рабочими процессами. Это означало бы, что мы действительно внедрили управление корпоративными проектами".

  • Бизнес-аналитика   . "Нам нужны системы показателей, панели мониторинга и интеллектуальный анализ наших проектных данных, — скажет нам кто-то. — Это была бы прекрасная среда управления проектами".

  • Модель зрелости системы управления проектами   . "Мы работаем над повышением уровня нашей зрелости в соответствии с моделью зрелости системы управления проектами".

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

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

Решение EPM должно охватывать стратегии, людей, процессы и технологии

Помните: развертывание управления корпоративными проектами — это не просто технология. Если бы это было так, внедрение занимало бы всего несколько дней. Однако развертывание решения EPM охватывает стратегию, людей, процессы и технологии. Чтобы развертывание решения EPM корпорации Майкрософт было успешным, практически всегда необходимо рассматривать этот проект не как технический, а как проект по управлению изменениями. Ведь задача состоит в том, чтобы изменить принципы, по которым работает бизнес. Как это сделать? В зависимости от результатов дискуссии на семинаре по выработке концепции могут быть выбраны разные пути.

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

Подходы к развертыванию управления корпоративными проектами

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

Большой взрыв

Теория большого взрыва гласит: "Давайте сделаем все сразу!" Идея такова: в течение неопределенного времени мы занимаемся проектированием, построением, переделками и программированием, создавая законченную среду управления корпоративными проектами. Для этого потребуется группа программистов, и когда-нибудь в будущем, в один прекрасный уикенд мы повернем выключатель, и система управления проектами сразу заработает в полную силу. Если попытаться изобразить это в виде зависимости рентабельности инвестиций от времени, получится график, показанный на рисунке.

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

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

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

Мгновенный взрыв

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

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

Поэтапный подход

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

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

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

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

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

При поэтапном подходе рентабельность инвестиций стабильно растет

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

Начало реализации стратегии развертывания решения EPM

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

1. Отдел управления проектами

Если вы намереваетесь развернуть корпоративную среду управления проектами, в организации обязательно должно существовать соответствующее подразделение. Обычно это отдел управления проектами. Назвать его можно как угодно, но этот отдел должен быть центром управления всей системой, например решением EPM корпорации Майкрософт. Кто отбирает "официальные" шаблоны? Кто решает вопросы предоставления полномочий на изменение приоритетов ресурсов? Кто определяет внешний вид и содержимое отчетов и имеет доступ к ним? Кто решает, есть ли необходимость в управлении рисками и, если да, то какую процедуру следует использовать? И так далее, и тому подобное… Нет, отдел управления проектами совершенно необходим. Если у вас нет такого подразделения (пусть даже состоящего из одного человека), то его создание должно стать одним из первых шагов на пути к построению корпоративной среды управления проектами.

2. Ответственные спонсоры

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

3. Мы — руководители проектов, и нам не требуется управление проектами!

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

4. Постановка целей

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

Начало работы

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

Концепция

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

Кто есть кто?

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

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

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

Заключение

Если вы планируете или осуществляете развертывание решения EPM корпорации Майкрософт, сконцентрируйте свое внимание на трех перечисленных ниже моментах.

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

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

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

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

Об авторе

Крис Вандерслуис (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.

×