[an error occurred while processing the directive]
[an error occurred while processing the directive]

6.2 Управляй коммуникациями / Приемы

Придерживайтесь правил проведения совещаний

(6.2.P1)

В целом, любое совещание должно иметь повестку дня. Подготовка повестки дня требует некоторой дополнительной работы, но она может быть не более обременительной, чем написание E-Mail и отправка его участникам совещания.

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

Другие соображения о проведении совещаний включают следующее:

Посвятите статус-совещание статусу

(6.2.P2)

Когда Вы собираете вместе всех ключевых сотрудников, всегда возникает соблазн заняться решением проблем. Но ошибка здесь кроется в том, что в решении отдельно взятой проблемы будут заняты всего несколько человек, а остальные в это время будут терять время. Поэтому, собрав всю команду на статус-совещание, займитесь лучше выяснением общего статуса, неотложных вопросов, изменений и рисков. Эти вопросы являются показателями здоровья Вашего проекта и будут интересны всем присутствующим. Если же в повестку дня совещания Вам пришлось включить также и решение "горящей" проблемы, то планируйте этот вопрос последним, чтобы все лишние участники могли разойтись по рабочим местам.

Типичной жалобой на статус-совещания является их чрезмерная продолжительность. Иногда такие совещания длятся два часа и более, что действительно слишком много. Обычно, причиной затянувшихся статус-совещаний, является желание решить попутно слишком много проблем, не имеющих отношения к большинству присутствующих. Лучшим способом сфокусировать внимание во время таких статус-совещаний - просто сократить время, отведенное для совещания. Например, если Ваши совещания длятся по два часа в неделю, и Вы замечаете, что Вам этого времени систематически не хватает, попробуйте сократить время совещаний до 90 или до 60 минут. Чтобы уложиться в сокращенное время, четко придерживайтесь повестки дня. Отложите все долговременные обсуждения для отдельных совещаний, которые будут посвящены именно этим вопросам, и в которых будут участвовать люди, непосредственно в них заинтересованные.

Используйте стандартизованную статус-отчетность

(6.2.P3)

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

Собирайте отчетность команды с разумной периодичностью

(6.2.P4)

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

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

Включайте в статус-отчетность только полезную информацию

(6.2.P5)

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

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

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

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

Выносите подробности в приложения

(6.2.P6)

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

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

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

Чем выше в организации - тем меньше нужны подробности

(6.2.P7)

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

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

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

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

Применяйте наилучшие способы коммуникации

(6.2.P8)

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

"Не стреляйте в курьера"

(6.2.P9)

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

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

Используйте Зеленый / Желтый / Красный индикаторы для представления общего состояния проекта

(6.2.P10)

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

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

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

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

Упреждающе коммуницируйте для управления ожиданиями

(6.2.P11)

Одним из главных назначений коммуникаций в проекте является управление ожиданиями участников. Статус-отчетность, к примеру, является средством доведения до участников проекта информации о том, как проект развивается относительно согласованного графика и бюджета. Вы включаете в отчеты текущую информацию о неотложных вопросах, рисках, изменениях и т.п. таким образом и для того, чтобы получатели отчетов могли заранее привести свои ожидания в соответствие с вероятными показателями завершения проекта. Таким образом, Вы делаете ожидания участников проекта адекватными реальным тенденциям его развития. Более подробно вопросы управления ожиданиями клиента рассмотрены в разделе 6.1.1.1 Управление ожиданиями .

Включайте коммуникации в график проекта

(6.2.P12)

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

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

Занимайтесь брэндингом проекта, приводящего к культурным изменениям

(6.2.P13)

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

[Пред. стр. - Брэндинг проекта ]   [След. стр. - Упр. документами - расширенное ]