Трансформация: особенности управления проектами преобразований. МВА-библиотека

Инициация – это все о начале проекта. От подготовки Устава до определения заинтересованных сторон. В трансформационных проектах я персонально еще отношу к инициации формирование проектной команды (как минимум требований к ней), но РМВоК не об этом.

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

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

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

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

Тут вроде все просто. Главное не подумайте, что процессы = фазы жизненного цикла проекта. Это ПРОЦЕССЫ и они неизменны в отличии от фаз проекта, которые можно определять под каждый конкретный проект.

Теперь об областях знаний.

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

Управление графиком – детализация и дробление работ (при необходимости до операций) и их последовательности, определение длительности, привязка к календарным датам, разработка графика и его контроль и т. д.

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

Управление качеством – процессы обеспечения и контроля качества в проекте.

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

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

Управление рисками – каждый проект всегда сопряжен с рисками. Потому тут задействуются процессы определение/идентификация рисков, количественная оцифровка и качественный анализ, система мониторинга рисков и план реагирования и предупреждения рисков.

Управление закупками проекта – планирование закупок, осуществление и контроль закупок.

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

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

· дистанция власти – на Востоке очень боятся наделенных властными полномочиями. Боятся слово сказать вразрез. На Западе – нормально так пройдутся, покритикуют, повозмущаются если что.

· Восприятие полов – ну не привыкли на Востоке к женщинам как главным или даже равноправным. И это в проектах остро чувствуется.

· Даже такие вещи как праздники и обычаи. Например, у нас майские праздники и с Днем Победы – это святое, а для норвегов – будние рабочие дни и им ничего не стоило назначить ключевое совещание и групповую работу по проекту с 1 по 10 мая – ребята из Россия и других стран СНГ были крайне возмущены.

Управление заинтересованными сторонами (как их еще называют с англ. стейкхолдерами) – на них я уже отдельно останавливался. А данная группа процессов в РМВоК рассказывает, как определить, оценить влияние, вовлечь и отслеживать вовлеченность заинтересованных сторон в проекте.

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

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

На момент публикации данной книги готовится новая 7 версия РМВоК. Отлично то, что в ней PMI вплотную подошел к тому, чтобы «накрыть» все процессы и области знаний 12 принципами.

На самом деле, каждый интенсивно практикующий менеджер проектов уже давно выработал свои принципы – и использует их «поверх» РМВоК. В т.ч. мы с Вами в данной книге рассмотрим 10 заповедейдля проектов преобразований.

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

О РМВоК на этом все – остальное само-собой подчерпнете по мере прочтения книги, а также самостоятельно изучая данный свод знаний.

То, чего нет в стандартах, но полезно в проектах преобразований

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

В технической реальности привыкли называть проекты «жесткими цифровыми идентификаторами» (изделие№3527). Или здоровенным названием, включающим и цель, и описание, и заказчика, и пользователя, и адрес прописки проекта («Проект постройки современного луна-парка на 3 Га между улицей Казачьей и промзоной», «Проектирование эффективной системы закачки рабочего агента в пласт для нужд цеха добычи сырья» или «Проект разработки ИТ-системы внутреннего CRM для улучшения взаимодействия и повышения клиенториентированности между департаментами Банка»).

Но в социально-экономической реальности название проекта имеет весомое значение.

Во-первых, люди любят красивые названия.

Персонально я, в том числе как бывший военный, поработавший в свое время с «секретками», стараюсь использовать:

· или ключевое слово из проекта (например, «Грейдинг», «OpMod» и т.д.)

· или запоминающуюся звучную аббревиатуру (например, TLDP или IRMT, iCRM). К примеру, знаете ли Вы, что у нас в СССР предлагалось еще Китовым внедрить единую госсеть вычислительных центров, а его последователем Глушковым – общегосударственную автоматизированную систему от госплана до цеха? Запомнили эти оба проекта с первого раза? А проектное название первого было ЕГСВЦ, а второго ОГАС… Думаю как минимум название ОГАС большинство слушателей не забудет.

· или какое-то интересно-заманчивое название (например «Скрепка», «Реактор», «Энштейн»). Кстати, проект ЕГСВЦ имел название «Красная книга».

Но интригующие названия я обычно использую для проектов с доступом для неширокого круга людей, чтобы звучащее название «лишним ушам» ничего не говорило. Например, для одной телекомкомпании предлагался проект по изменению звеньевой структуры управления (одно звено управления должно было «вылететь» – а в этом звене находились серьезные политические фигуры в организации). О планируемом изменении знали 5 человек, включая генерального директора, и назвали проект «Напильник». Дизайн проекта держался в секрете, управлялся проект в виде реализации, казалось бы, разрозненных задач, которые в комплексе отстраивали внутри новую систему управления. И так было до момента пока все не утрясли, и генеральный директор не озвучил решение о переходе на 3-х звеньевую модель управления.

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

Например, я когда-то реализовал для одной транснациональной компании проект TLDP – и когда его результаты перешли в процесс Performance Management, люди еще года три его TLDP называли. Но важно не то что его долго еще так называли – важно то, что при управлении проектом название уменьшает необходимость лишней коммуникации и объяснений «а о каком именно проекте идет речь?» – все все сразу схватывают.

Вот такая-вот нестандартная штука (имя / название проекта), но очень полезная для проектов преобразования социально-экономических систем.

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

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

Потому методы объединяются и упорядочиваются в рамках методологий (наборов методов и подходов). Методология – это набор взаимоувязанных подходов, практик, техник, методов, процедур, правил.

И одна из главных задач менеджера проекта – правильно выбрать методологию реализации проекта или комбинацию методологий. О комбинации методологий мы будем говорить еще отдельно.

И еще замечу, что упомянутый в предыдущей главе РМВоК (как и любой стандарт, справочник или каталог) это не методология – это свод знаний об управлении проектами.

А методологий в практике на сегодня выделяют две (если привязаться к РМВоК, то в их основе лежат уже упоминаемые ранее предиктивный и адаптивный жизненные циклы):

· Waterfall (каскад, водопад)

· Agile (гибкий, проворный, адаптивный)

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

WATERFALL – это последовательно-каскадная методология. Она предполагает, что все этапы проекта осуществляются последовательно, четко следуя плану.