Анна Леммниц

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

Ключевые PMO процессы поддерживаются рядом документов, поэтому в ресурсах PMO мы обязательно публикуем templates (шаблоны), положения, статус репорта, шаблоны для управления рисками. Эти документы и параметры доступа к ним мы отправляем проект-менеджерам, Workstream лидерам из PMO. Таким образом мы добиваемся того, чтобы все использовали один и тот же шаблон, одни и те же инструменты и способы коммуникации с руководителями.

Следующий шаг – создание плана проекта, определение ключевых точек. Мы исходим из цели проекта и определяем, в каких точках будем проверять – насколько успешно к ней продвигаемся. Задача руководителя PMO – контролировать, периодически проверять это расписание, при необходимости – корректировать его. Мы используем свой формат SAP Jam и разные share drives, document room.

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

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

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

Например, у нас был проект по переводу ERP-системы на HANA. В конце августа топ-менеджмент задался вопросом, возможно ли запустить в октябре новые функции, которые на тот момент только разрабатывались в системе SAP. От меня требовалось создать так называемый flat-plan. Вот пример такого расписания. Его можно сделать в любом формате, который у вас используется.

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

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

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

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

Управление рисками программы

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

Как выйти на поставленные цели, если меньше денег? Уменьшить масштаб? Не вариант. Мы оценили риски и поняли, что не сможем реализовать проект в августе, так как в это же время уже будет запускаться другой крупный проекти – перевод ERP-системы на HANA. Поэтому работу, которую мы планировали завершить в августе, нужно завершить раньше – в мае, в крайнем случае – в начале июня. Бизнес был этим недоволен: помимо необходимости ускорить работу, им не требовалось вводить эту функциональность в июне, а требовалось в октябре.

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

Невозможно определить все риски в самом начале. Процессы управления рисками ведутся на проектном и на программном уровнях. Определяете риски и помещаете их в Risk log. Есть такой инструмент в SAP, который называется Giro, где фиксируются эти риски. Вы их либо принимаете, либо отвергаете, и для этого у нас принято проводить еженедельное совещание. Какова вероятность наступления такого риска и его последствия? Какова процедура предотвращения и снижения серьезности риска? Для программы перевода ERP на HANA основная сложность была c ранним внедрением и с сохранением свободных ресурсов. Следующий этап – мониторинг рисков на проектном уровне: разрешимы ли они на данном уровне или могут повлиять на всю программу. За такими рисками я должна следить, как руководитель программы. Определение рисков на программном уровне определялось также на еженедельных совещаниях.