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

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

Для начала выбирают модель управления информацией. Их всего 3, по основ­ным типам носителей.

• Устная речь (совещание, распоряжение, устный отчет и т.д.).

• Бумажные документы.

• Электронные носители (мейл, файлы, базы данных и т.д.).

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

Помню, как-то главный бухгалтер одного клиента не проплачивал выполненный проект, пока ему не привезли кипу распечатанных отчетов.

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

Иногда ограничиваются «контакт-листом» - перечнем участников проекта с те­лефонами и адресами электронной почты. Для мелких проектов этого достаточно.

В более крупных проектах желательно включить в план следующую информацию:

 

Информа­ция	Поставщик информа­ции	Потреби­тель ин­формации	Форма передачи	Название документа	Периодич­ность/ событие	Ожидаемая реакция по­требителя

С первыми тремя колонками все ясно.

Форму передачи мы уже обсудили выше.

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

Периодичность / событие. Любая информация перемещается либо периодиче­ски {допустим, вы получаете отчет раз в неделю к 14 часам пятницы), либо по факту некоторого события (например, когда бригадир сообщил вам о готовности объекта к сдаче заказчику).

Кстати, существует 2 подхода к распространению потоков информации, мате­риалов и пр.: «вытягивание»¹ и «заталкивание»². «Заталкивание» подразумевает, что нечто производится и доставляется потребителю независимо от того, нужно

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

Ожидаемая реакция потребителя. Заполнение этого пункта придает смысл всей строке. Если реакция не определена, то, возможно, эта информация никому не нужна?

ПРИМЕР 70. Сергей Багузин, замдиректора по развитию крупной ИТ-компании: «Чтобы участники проекта ощущали себя частью большого процесса, мы проводим периодические «летучки». Обмен файлами, общение по mail или телефону не может заменить собрания. Такие мероприятия создают «нерв» проекта, чувство локтя, ощущение, что кто-то зависит от тебя и ты от коллег».

ПРИМЕР 71. Любовь Малютина, маркетинг-директор, группа Societe Generale - Русфинанс Банк; консультант по маркетингу: «В моем те­кущем проекте, и из консалтингового опыта, у меня сложилась такая система коммуникаций:

1. Полноценные регулярные (и здесь главное слово - регулярные) со­брания по проекту.

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

3. Все коммуникации проекта — групповые. То есть все письма, касаю­щиеся проекта, рассылать ответственным лицам проекта, и в копиях - тем, кто должен быть в курсе, как движется проект, чтобы понимали, когда будет пора включиться.

4. Все коммуникации проекта маркированы, т.е. тема писем по проек­ту не изменяется в ходе проекта и обозначена определенным образом в электронной почте, например, по названию проекта.

ПРАКТИЧЕСКОЕ ЗАДАНИЕ 67

Разработайте «План управления коммуникациями» своего проекта в

Виде вышеописанной таблицы.

Включите в него основные информационные потоки.

 

¹ От англ. pull-«тянуть».

² От англ. push - «толкать».

¹ См. п. 7.5.6 «Toyota production system (TPS)». Именно на этом принципе построена известная японская система «Канбан».

СВОДНЫЙ ПЛАН ПРОЕКТА

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

Сводный план утверждается руководством компании и служит основой для по­следующего контроля проекта.

РЕАЛИЗАЦИЯ ПРОЕКТА

И вот вы полностью спланировали свой проект. Наступило время засучить ру­кава и приступить к его реализации. А значит, вам нужно:

• организовать его выполнение;

• контролировать и анализировать ход его выполнения;

• управлять изменениями.

ОРГАНИЗАЦИЯ ВЫПОЛНЕНИЯ

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

КОНТРОЛЬ ПРОЕКТА

Конечно, ни один проект не может успешно выполняться без контроля. У многих контроль ассоциируется с совещаниями, на которых грозный руководитель проводит «разбор полетов». Однако насколько эффективно «махать кулаками после драки»?

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

• «Листья» вашей WBS являются элементарными объектами контроля, т.е. мы декомпозируем проект до того уровня, до которого хотим его контролировать¹.

• Необходимо зафиксировать плановые значения (по объемам, срокам, финансам) для каждой работы проекта, чтобы в дальнейшем сравнивать с ними фактические цифры.

• Вам необходимо организовать процесс получения отчетных данных 8 удоб­ной форме с заданной периодичностью.

• Система контроля должна быть прозрачна для вас, то есть вы должны понимать, что имеет в виду исполнитель или подрядчик, когда говорит, что сделал работу на 30%.

• Вы можете применять как простой контроль (работа готова / не готова), так и детальный (любой процент выполнения от 0 до 100). Детальный контроль дает больше информации, но требует больше вашего внимания.

Таким образом, по ходу проекта вы отслеживаете фактические значения, ана­лизируете и принимаете решения. Удобно, если ваша система выдает прогнозы по срокам выполнения работ и финансам².

¹ Си. п. 4.3.1 «Управление предметной областью проекта».

² Для прогнозирования разработан ряд методов, таких как «метод освоенного объема» (Earned value). Однако в
российской практике он применяется нечасто. Его описание можно легко найти в специализированной литературе.

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

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

В специализированные программы встроены удобные средства для отслеживания проектов Так к примеру, Microsoft Project позволяет наглядно видеть, какие работы идут с отставанием или опережением графика (рис. 50). Однако для того чтобы воспользо­ваться всем этим, необходимо до начала автоматизации формализовать управление про­ектами в компании, в том числе разработать и внедрить регламенты по их контролю.

Рисунок 50. Контроль проекта в Microsoft Project

Контрольные тачки

В плане проекта удобно назначать контрольные точки. То есть вы заранее пла­нируете, что в некий день X проконтролируете проект по таким-то параметрам. Точки контроля рекомендуется ставить:

• на всех вехах;

• если в сетевом графике есть «гамак» (рис. 51);

• на работах критического пути;

• на работах с малыми резервами времени (их еще называют «субкритические»).

 

Рисунок51. «Гамак»

При планировании точки контроля определяют следующие параметры:

• Дату предполагаемого контроля;

• Объект контроля (что контролируем);

• Субъект контроля (кто контролирует).

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

• Параметры контроля и их численные измерители, целевые показатели, до­
пустимые отклонения (если есть).

Параметр: Количество рабочих мест, оборудованных доступом к локальной сети Измеритель: Штуки Целевой показатель: 50.

• Тип контроля:

~ вертикальный итоговый. Руководитель контролирует итоги выполнения работы своими подчиненными;

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

~ вертикальный текущий. То же, только время контроля заранее не известно: руководитель «сваливается, как снег на голову». Это применяется для «взба­дривания» сотрудников;

~ горизонтальный. Контроль, встроенный в бизнес-процессы. Мы уже рас­сматривали его в п. 3.3.5.1 «Типичные ошибки в процессах» при обсуждении «вертикальных колодцев».

• Способ контроля:

- собственно контроль - это сравнение фактических результатов работы с плановыми по итогам ее выполнения;

- контроллинг- выявление существенных отклонений (нужно задать четкие критерии) и реакция только на них;

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

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

• Следствия контроля. Здесь мы заранее решаем, как будем действовать, если
по результатам контроля поймем, что ситуация отличается от запланированной.
Следствия бывают 2 видов:

- мотивирующие, когда мы воздействуем на человеческий фактор исполни­теля, например ругаем его или хвалим, надеясь, что это повлияет на его дей­ствия в будущем;

-организационные, когда мы исправляем бизнес-процесс таким образом, чтобы он выполнялся правильно: желательно, независимо от личностей и на­строения исполнителей.

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

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

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

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

ПРАКТИЧЕСКОЕ ЗАДАНИЕ 68

Опишите пару точек контроля для вашего проекта. Для каждой из них определите все вышеописанные параметры, в том числе следствия: что именно предпримете в случае отклонений. Для определения точек кон­троля удобно пользоваться ранее разработанной диаграммой Гантта.

ПРИМЕР 72. Сергей Багузин, замдиректора по развитию крупной ИТ-компании: «У нас все начальники отделов еженедельно направля­ют отчеты руководству. Мы постоянно совершенствуем эти отчеты. Основное правило: должна собираться и анализироваться только та информация, которая может пригодиться для последующих управ­ленческих воздействий. Собранную информацию анализируют в пер­вую очередь сами начальники отделов, что помогает им действовать на основе сигналов, являющихся ранним оповещением грядущих про­блем. Небольшая цитата из К. Мацусито «Принципы успеха»¹:

¹ См. Коносуке Мацусито. Принципы успеха.

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

ПРАКТИЧЕСКОЕ ЗАДАНИЕ 69

Определите периодичность и форму, в которой вы хотите получать отчеты от исполнителей и подрядчиков по различным работам ваше­го проекта,

Получившуюся информацию сведите в таблицу, которая по формату

аналогична плану управления коммуникациями проекта. По сути, это

его часть.

Чем меньше будет отчетов, тем лучше, однако совсем без них не

обойтись. Кстати, часть из них может быть в устной форме, особенно

для небольших проектов.