Управление изменениями. Часть 1

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

Является ли проектная деятельность самоцелью или компании нужно провести изменения, обязательно используя проектные методы? Ответ очевиден: нужны изменения, нужны решения глобальных и «вечных» задач бизнеса, а управление проектами — только инструмент.

Примеры некоторых задач:

• Увеличение объемов продаж

• Снижение себестоимости продукции

• Привлечение новых клиентов

• Улучшение качества продукции

• Улучшение качества обслуживания клиентов

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

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

Проект

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

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

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

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

Классические методологии проектного управления рекомендуют делать относительно подробные планы работ, разбивать крупные блоки работ на небольшие части (в частности, рекомендации PMI не более 80 часов) и распределять ресурсы по работам, добиваясь их сбалансированной загрузки (WBS). Вроде бы все логично, и такой подход должен давать качественный результат но, к сожалению, не дает! Другими словами, если совсем не вести планирование, проект перейдет в режим полного доверия руководителю проекта (всё будет хорошо, только не вмешивайтесь и подождите), а если вести, то почти всегда процесс реальной реализации проекта серьезно отличается от запланированного.

План проекта

Проект выполняется для заказчика, нужен ли ему в таком случае план? Понятно, что, если заказчик получит результат без предоставления плана, он будет так же удовлетворен, как и с планом. А вот если он получит только план, а результат — нет, удовлетворения точно не случится. Более того, современные заказчики не готовы ждать результатов завершения всего проекта, а хотят получать пусть небольшие, но готовые к использованию промежуточные результаты.

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

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

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

Крупные проекты практически всегда имеют отношение к нескольким глобальным задачам бизнеса и являются кросс-функциональными.

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

- планируемых и важных для них событиях в проекте,

- фактически достигнутых результатах,

- рисках и проблемах проекта.

Нужен ли им план и в какой детализации? Кому-то из них достаточно информации разрезе проекта, однако если проектов много, требуется консолидированная картина состояния дел со всеми проектами, своего рода Dashboard.

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

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

ЛОТ и вехи проекта

Блок работ, который необходимо выполнить, чтобы предоставить заказчикам значимый для них результат, будем называть в дальнейшем ЛОТом работ или просто ЛОТом, а выполнение каждого ЛОТа – вехами проекта.

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

Используя ЛОТ, мы получаем единицу работ/измерения/управления для конструирования двух типов дорожных карт:

1. По работе с глобальными задачами бизнеса

2. По исполнению содержания проектов

Также ЛОТ представляет собой формальное соединительное звено между стейкхолдерами и проектной деятельностью, которая становится прозрачной, актуальной и не обремененной лишними для стейхолдеров деталями.

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

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

Уровни коммуникаций

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

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

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

Таким образом, проектная работа и коммуникации в предложенном подходе условно делятся на то, что происходит «над верхнеуровневым планом» — коммуникации со стейкхолдерами, и «под верхнеуровневым планом» — работа групп, исполняющих ЛОТы.

Каждая компания может организовывать работу групп любым, привычным для себя способом и на основе методологии, принятой в компании при организации работ по реализации проектов. Кстати, если компания использует Scrum, то каждый Sprint можно считать ЛОТом.

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

Ниже перечислены основные моменты предлагаемой концепции реализации проектов:

• Больше доверять руководителям проектов – отказаться от публикации детального плана проекта и заменить его верхнеуровневым планом

• Разделить содержание проектов на ЛОТы, в каждом проекте последовательность ЛОТов, завершающихся вехами – верхнеуровневый план проекта

• Привязывать ЛОТы к глобальным задачам бизнеса, где это возможно

• Уделять особое внимание ЛОТам, результаты исполнения которых влияют на другие проекты

• Классифицировать значимые события в проекте и определить уровни коммуникаций для них

• Своевременно документально фиксировать значимые события в проекте

• Учитывать, что любое значимое событие в проекте требует времени как на свою обработку, так и на реакцию

• Хранить историю значимых событий в проекте

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

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

1. Руководитель проекта – информирование о значимых событиях в проекте

2. Специалист по методологии – стандартизация, сбор и организация проектных документов

3. Специалист по мониторингу – фиксация значимых событий в проектах, формальная отчетность

4. Специалист по финансам – контроль бюджетов и финансовых потоков в проектах

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

Продолжение следует