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

Автор книги: Никита Сергеев

Раздел: О бизнесе популярно, Бизнес-книги

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

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

А) корпоративное требование;

Б) вопрос Ваших персональных профессиональных предпочтений.

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

Я, например начинал с Primavera и через какое-то время мне легко «зашел» MS Project Office (при разработке ПО для внутреннего CRM одного из банков). С некоторыми заказчиками работал также во Wrike в онлайне – таковы были условия проекта.

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

Для реального управления трансформационными проектами непосредственно менеджерам проектов в большинстве случаев достаточно мощностей Excel и Power Point – ведь не хранилище ядерных отходов, ядерную АЭС или ультрасовременную подлодку собираем…

Главное из PMBoK за 5 минут

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

На самом деле в нем нет ничего сложного, а есть важные два блока (рис.1.16):

· 5 групп (категорий) процессов в проектном менеджменте

· 10 основных областей знаний, которые могут быть общеиспользуемыми в проектах. Только помните, что каждый проект зачастую еще может быть дополнен чем-то специфически-отраслевым или организационным.

Рис.1.16. Группы процессов и Области знаний

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление ресурсами – при чем в последней нотации 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 – это последовательно-каскадная методология. Она предполагает, что все этапы проекта осуществляются последовательно, четко следуя плану.

Описание – Планирование – Разработка -Внедрение – и т.д….. – как изображено на рис. 1.17.

Рис.1.17. Предиктивный жизненный цикл

Закончив один этап – переходите ко второму, т.е. планомерно, от этапа к этапу двигаясь к результату проекта.

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

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

В частности, важно для длинных проектов, в которых среда нестабильна и требования могут меняться с течением времени – когда Вы 3 месяца анализировали, 2 месяца проектировали, зашли в годовую разработку… а среда и цели настолько сменились, что результат проекта уже и не нужен.

Особенно это критично для социально-экономических систем, когда и заказчик может за период реализации «вырасти» и понять, что ему не это нужно; и социальная часть изменится; или экономически станет нерентабельным…

Приведу простенький изменения среды. После M&A (слияние и поглощение) в одной из стран СНГ 5 юрлиц стали единой компанией. Но поскольку антимонопольный комитет не дал разрешение на слияние – они де-юре остались 5 юрлицами, но де-факто уже стали единой компанией с единым менеджментом.

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

И вот пока 4 месяца ИТ, кадры, управленческий учет и бухгалтерия совместно писали бизнес-требования как выгружать информацию из всех ИТ-систем для единой интегрированной компании, пока ИТ с подрядчиком еще 8 месяцев разрабатывали, пока 2 месяца тестировали и устраняли ошибки – антимонопольный комитет «дал добро» на слияние и программа в принципе стала не нужна.

Тем не менее, Waterfall подход очень эффективный для проектов с четкими требованиями и неизменной средой. Условно типовые инженерно-технологические проекты (постройка здания, моста и т.д.) лучше заходят именно по данной методологии.

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

AGILE – это итерационная методология, когда Вы двигаетесь к результату короткими итерациями. Причем важным является перечень основных характеристик продукта/результата проекта – а реализация идет по итеративным циклам.

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

Рис.1.18. Итеративный жизненный цикл (итерация этапов)

Или они могут касаться продуктарезультата проекта, который делается «по-кусочку» (инкремент за инкрементом) – тогда имеем дело с инкрементным жизненным циклом (рис.1.19).

Рис.1.19. Инкрементальный жизненный цикл (итерация продукта)

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

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

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

Очевидное преимущество Agile – это учет изменений как требований клиента, так и среды. Т.е., Agile наиболее подходит для проектов с нечеткими, вариативными, высоконеопределенными требованиями иили средой.

С моей т.з. лучше всего эту Agile-методологию (адаптивный цикл) в ее практическом виде олицетворяет SCRUM (СКРАМ) – визуализация на рис.1.19.1.

Рис.1.19.1. Визуальное представление SCRUM»а

В Скраме:

– Готовится описание результата, который разбивается на перечень всего того, что мы хотим получить (на кусочки) – Продукт-бэклог;

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