УправлениеИТ в бизнесе

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

Игорь Киселев | 20.09.2016

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

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

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

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

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

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

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

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

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

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

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

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

Проект

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

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

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

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

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

План проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

img

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление проектами

Журнал: Журнал IT-Manager [№ 09/2016], Подписка на журналы


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Также по теме

Мысли вслух

Мы много и часто говорим о том, что "ИТ меняют наш мир". Посмотрим, как это происходит в Китае с применением конкретных инструментов и затрагивает сотни миллионов человек.
Согласно прогнозам Gartner, к 2022 г. 75% организаций, использующих инфраструктуру как сервис (IaaS), будут реализовывать продуманную мультиоблачную стратегию, в то время как в 2017 г. доля таких компаний составляла 49%.
Все жалуются на нехватку времени. Особенно обидно, что его не хватает на самые важные вещи. Совещания, созвоны, подготовка внутренних отчетов, непонятно, насколько нужных, но которые начальство требует так, как будто это именно то, ради чего мы работаем.

Компании сообщают

Мероприятия

Conversations – конференция для бизнеса и разработчиков
ОНЛАЙН
12 900 руб
21.06.2021 — 22.06.2021
09:00–18:00
Apple Tech Business Week
Санкт-Петербург, IT-пространство для бизнеса Resonance Space
22.06.2021 — 24.06.2021
VI Конференция ЦИПР-2021
Нижний Новгород, ул. Совнаркомовская, дом 13, «Нижегородская Ярмарка»
15 000 руб
23.06.2021
Выставка «EXPO-RUSSIA KAZAKHSTAN 2021»
Республика Казахстан
23.06.2021 — 25.06.2021
10:00–18:00
ЖКХ Будущего. Актуальные вопросы и решения
ОНЛАЙН
10 500 руб
24.06.2021 — 25.06.2021
10:00–18:00