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

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

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

Дополнительные статьи см. в технических документах "Из окопов".

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

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

Введение

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

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

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

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

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

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

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

"Что такое EPM с вашей точки зрения?" Я спрошу. Ответы часто находятся в одном из кругов на слайде. Ответы могут быть следующими:

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

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

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

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

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

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

• Расписания. "Не помните о планировании. Если бы вы могли просто сказать мне, на что мои люди на самом деле тратят свое время, мы были бы так далеко впереди, где мы находимся сейчас, мы бы назвали это успехом EPM", кто-то часто говорит.

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

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

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

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

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

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

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

Помните, что развертывание управления корпоративными проектами — это не только технология. Если бы это было так, реализация закончится через несколько дней. Нет, развертывание EPM включает стратегию, Люди, процесс и технологию. Успешные развертывания решения Microsoft EPM практически всегда считают проект проектом управления изменениями, а не технологическим проектом. То, что мы хотим сделать, это изменить способ работы бизнеса. Как это сделать? Ну, в зависимости от того, в каком направлении идет упражнение, направление может быть очень разным.

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

Подходы к развертыванию EPM

Давайте немного поговорим о том, сколько людей подходят к развертыванию EPM. Существует несколько возможных сценариев: Большой взрыв, Мгновенный взрыв и Фазовый подход.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Спонсорство руководителей

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

3. Мы руководители проектов - нам не нужно управление проектами!

Если вы хотите избежать наиболее распространенных ошибок в развертывании EPM, создайте план проекта. Я знаю, это звучит странно просто, но удивительно, сколько проектов развертывания EPM, на самом деле, не имеют плана проекта. Один из самых простых советов, которые мы можем дать организациям, рассматривающим развертывание решения Microsoft EPM, заключается в том, чтобы сделать его проектом и применить все те же методологии, которые они уже используют для любого другого проекта. Есть ли расписание проекта; бюджет; исполнительный спонсор; устав проекта; Ресурсы; метрики успеха? Эти вещи можно найти в любом другом проекте в организации, но, как и дети сапожника, которые ходят босиком, руководители проектов часто забывают применить свои навыки к своим собственным проектам.

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

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

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

Если вам интересно, как начать работу, ознакомьтесь с несколькими рекомендациями.

Выработка концепции

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

Кто есть кто?

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

Создание плана проекта

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

Заключение

Если вы планируете или начали развертывание решения Microsoft EPM, сосредоточьтесь на развертывании, учитывая следующие три момента:

1. Рассматривать этот проект как проект. Используйте все имеющиеся навыки управления проектами для управления проектом развертывания Microsoft EPM. Помните, что это в первую очередь проект управления изменениями, а не технологический проект.

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

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

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

Об авторе

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

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

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