Кто отвечает за коммуникации команды проекта: Управление коммуникациями и конфликтами в проекте

Содержание

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

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

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

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

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

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

Процессы управления коммуникациями проекта и показатели их эффективности

Размещенная выше схема добавляет к традиционной модели несколько значимых акцентов.

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

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

Модель динамики входов и выходов процессов управления коммуникациями

Конструктивные функции конфликтов в команде

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

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

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

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

предконфликтная фаза, которая никак не проявляется и остается на уровне внутренних процессов участников события;
начало конфликта;
эскалация (нагнетание) конфликта;
завершение ситуации;
постконфликтная фаза.

Управление конфликтами между участниками

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

Ролевая расстановка в проекте по Мередиту Белбину

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

Системные решения, снижающие вероятность возникновения конфликтов. Среди них – эффективное целеполагание деятельности команды и справедливая система мотивации. Четкая регламентация требований к командной деятельности и установление правил взаимодействия ее членов.
Применение методов сглаживания конфликтной ситуации, которые характеризуются пассивной формой реагирования, намерением сохранить взаимодействие и смягчить ситуацию. Методы применимы в ситуации, когда руководитель проекта и одна из сторон конфликта готовы проявить великодушие.
Использование компромисса, основанного на принятии противоположной точки зрения, открытого обсуждения позиций сторон и поиска решения, приемлемого для всех. В условиях компромисса велики риски скатиться в конформизм, что иногда неблагоприятно влияет на результаты проекта.
Включение открытой конфронтации со стороной конфликта, действующего деструктивно. Проект-менеджер вправе и обязан применить метод в ряде случаев: принципиальности и важности конфликтного вопроса для судьбы проекта; уверенности PM, что его вариант наилучший и укрепит его лидерскую позицию; когда другого способа разрешения конфликта нет, и PM не многое потеряет в случае разрыва отношений.
Разрешение конфликта в сотрудничестве конфликтующих сторон. Данный способ допустимо использовать в условиях низкой эмоциональной напряженности и высокой адекватности сторон конфликта.

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

Роли в разработке IT-продукта: аккаунт, проджект-менеджер, тимлид

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

Разберемся с терминологией

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

Аккаунт-менеджер (англ. account manager) выступает гарантом соблюдения обязательств перед клиентом, развивает с ним партнерские отношения, курирует команды проектов, решает любые нестандартные задачи и спорные вопросы.

Проджект-менеджер (англ. project manager) помогает в непосредственной реализации технических задач: общение с командой разработчиков, бюджет, содержание и сбор требований по проекту, постановка целей, распределение задач и контроль за соблюдением сроков.

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

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

Менеджеры на проекте

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

Рассмотрим подробнее, каким образом могут быть распределены обязанности между аккаунт-менеджером, руководителем проекта и тимлидом.

Аккаунт-менеджер – «правая рука» клиента на проекте

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

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

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

Проджект-менеджер или руководитель проекта

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

В числе его задач:

Согласование с заказчиком плана работ, а также сроков.

Формирование, организация и контроль работы команды.

Распределение зон ответственности среди ключевых участников.

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

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

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

Руководитель группы разработчиков или тимлид

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

Формирование сплоченной команды, ее микроклимата и корпоративной культуры.

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

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

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

Пример первый

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

Пример второй

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

Аккаунт-менеджер погрузился в бизнес-задачи заказчика и помог определить цели проекта и сроки его реализации.

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

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

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

Выводы

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

Организация :: PRINCE2® wiki

Область знаний об организации, предоставляемая PRINCE2

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

Проект PRINCE2 основан на среде заказчика/поставщика. Одной из сторон является заказчик, который будет определять результаты и, скорее всего, платить за проект, а другой стороной является поставщик, который будет предоставлять ресурсы, делать работу и поставлять необходимые продукты.

Как вы думаете, что делает проектную команду успешной? PRINCE2 утверждает, что успешная команда по управлению проектом должна:

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

В итоге, каждый проект должен иметь руководство, управление, контроль и коммуникацию.

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

Определения организации

Проект

Общее определение проекта: «определенный набор задач, необходимых для достижения конкретной цели». PRINCE2 определяет проект следующим образом: “временная организация, которая создана с целью поставки одного или нескольких бизнес-продуктов согласно утвержденному экономическому обоснованию”.

Программа

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

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

Корпоративная организация

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

Роли и определения рабочих обязанностей

PRINCE2 возлагает обязанности по проекту на роли, а не людей. Эти роли затем могут быть присвоены конкретным лицам. Таким образом, один человек может иметь более одной роли. Например, в крупных проектах, роль поддержки проектов (Project Support) можно назначить одному или нескольким лицам. В небольших проектах роли менеджера проекта и поддержки проектов могут назначаться одному человеку.

Заинтересованная сторона/лицо

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

Три интереса в проекте

Проект PRINCE2 всегда должен включать три основные категории заинтересованных сторон (три основные заинтересованные стороны), и они также должны быть представлены в совете проекта. Эти стороны следующие: бизнес, пользователи и поставщики.

Интересы бизнеса

Роль ответственного руководителя в совете проекта включает обязанность следить за соблюдением интересов бизнеса. Должно быть в наличии экономическое обоснование; в противном случае проект не может (не должен) начинаться. Ответственный руководитель задает вопрос: “Стоит ли этот проект затрачиваемых средств?”

Интересы пользователя

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

Интересы поставщиков

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

Среда заказчика/поставщика

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

Например, отдел продаж хочет иметь новое программное обеспечение.

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

Например, журнал создает новую онлайн службу новостей для клиентов.

Четыре уровня проектной организации

Важно, чтобы вы понимали разницу между структурой управления проектами (проектной организацией) и командой по управлению проектом. Структура управления проектом имеет 4 уровня, а команда по управлению проектом — 3 уровня.

4 уровня cтруктуры управления проектом / проектной организации следующие:

Уровень управления корпорацией или программой
Уровень руководства
Уровень управления
Уровень поставки

Примечание: Уровень управления корпорацией или программой находится вне команды по управлению проектом.

Уровень: Уровень управления корпорацией или программой

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

Уровень: Руководство (совет проекта)

Совет проекта отвечает за руководство проектом и несет полную ответственность за успех проекта. Его члены делают следующее:

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

Уровень: Управление (менеджер проекта)

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

Уровень: Поставка (менеджер команды)

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

В процессе управления поставкой продуктов команды производят продукцию специалистов.

Структура проектной команды

Совет проекта

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

Совет проекта имеет следующие обязанности:

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

Ответственный руководитель

Ответственный руководитель назначается руководством корпорации или программы. Ответственный руководитель отвечает за проект и поддерживается ролями старшего пользователя и старшего поставщика.

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

Ответственный руководитель отвечает за разработку экономического обоснования в начале проекта и продолжает спрашивать: «Проект по-прежнему стоит затрачиваемых средств?» на протяжении всего проекта.

Старший пользователь

Старший пользователь имеет следующие обязанности:

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

Старший поставщик

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

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

Внутренний контроль проекта

Во-первых, зачем нам нужен внутренний контроль проекта? Рассмотрим следующие ситуации:

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

Ответственный руководитель отвечает за обеспечение экономического контроля.
Он хочет убедиться в корректности экономических аспектов проекта.
Он постоянно задается вопросом: “Стоит ли этот проект затрачиваемых средств?”
Старший пользователь отвечает за контроль пользователя.
Он хочет убедиться в том, что проект будет поставлять правильные продукты, и эти продукты будут соответствовать требованиям.
Он постоянно задается вопросом: Будет ли продукт работать как ожидалось?
Старший поставщик отвечает за контроль поставщиков
Он хочет убедиться в том, что продукты будут поставлены в соответствии с ожиданиями, и что в наличии имеются нужные материалы и люди для выполнения работы.
Он постоянно задается вопросом: Можно ли это сделать в рамках переменных ограничений по срокам, стоимости и т.д?

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

Ответственный за изменения

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

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

Серьезность запроса на изменения — Кто принимает решение?

Уровень 5 — Руководство корпорации / программы
Уровень 4 — Совет проекта
Уровень 3 — Ответственный за изменения
Уровень 2 — Менеджер проекта
Уровень 1 — Поддержка проекта / хелпдеск

Например, инцидент (запрос на изменение) 2 уровня: Менеджер проекта может решать, если затрагивается только один продукт и влияние изменения менее 400 €, и, конечно, в пределах допуска.

Почему совет проекта не берет на себя полностью роль ответственного за изменения во время проекта?

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

Менеджер проекта

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

Обычно менеджер проекта (предпочтительно PRINCE2) приходит со стороны заказчика. Он несет ответственность за все процессы PRINCE2 за исключением руководства проектом.

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

Как вы думаете, какими навыками должен обладать менеджер проекта?

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

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

Какие другие роли может выполнять менеджер проекта? Менеджер проекта может брать на себя роли поддержки проекта, менеджера команды (если имеет специальные знания) и ответственного за изменения (если это разрешено советом проекта).

Менеджер команды

Роль менеджера команды является необязательной и обычно используется:

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

Поддержка проекта

Роль поддержки проекта предоставляет проекту следующие услуги:

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

Вовлечение заинтересованных сторон

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

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

Стратегия управления коммуникацией

Что такое документ стратегии управления коммуникацией? Это документ, который подробно описывает, как во время проекта будет осуществляться коммуникация (например, что сообщается, кому и как часто). Менеджер проекта будет обращаться к этому документу на протяжении проекта.

Стратегия управления коммуникацией определяет правила взаимодействия при осуществлении коммуникации во время проекта.

Что содержит документ стратегии управления коммуникацией? Он содержит описание средств (как) и частоту коммуникации с внутренними и внешними сторонами. Он может также включать руководство программы, если проект является частью программы.

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

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

Введение, чтобы напомнить читателю цель документа для данного проекта.
Процедура коммуникации: Описание методов связи, которые будут использоваться, например, электронная почта, встречи и презентации.
Инструменты и методы, такие как e-mail, интранет, информационный бюллетень.
Отчетность: Типы отчетов и информации, которую они должны содержать.
Сроки: Устанавливает, когда будет осуществляться коммуникация.
Роли и обязанности: Кто будет обрабатывать сообщения?
Анализ заинтересованных сторон: Тип заинтересованных сторон и желаемые взаимоотношения с заинтересованными сторонами.
Необходимая информация: Необходимые сведения о проекте, включая частоту сообщений и их формат.

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

Роли и обязанности

Руководство корпорации / программы
Назначение ответственного руководителя и возможно менеджера проекта в процессе начала проекта
Может предоставить шаблон стратегии управления коммуникацией
Ответственный руководитель
Может назначить менеджера проекта, если это не сделано руководством корпорации или программы
Выбирает совет проекта и утверждает состав команды по управлению проектом
Одобряет стратегию управления коммуникацией
Старший пользователь.
Предоставляет ресурсы пользователей
Старший поставщик
Предоставляет ресурсы поставщика
Менеджер проекта
Готовит документ стратегии управления коммуникацией в процессе инициации проекта
Готовит описания ролей для команды по управлению проектом в процессе начала проекта
Оказывает помощь в разработке экономического обоснования
Помогает убедиться, что экономическое обоснование содержит правильную информацию
Менеджер команды
Управляет членами команды
Внутренний контроль проекта
Дает советы при наборе команды по управлению проектом
Гарантирует, что стратегия управления коммуникацией адекватна

Навыки проектного управления, или Как стать лидером успешного проекта

ГлавнаяО проектеНовостиНавыки проектного управления, или Как стать лидером успешного проекта

30.04.2020

Стажеры Правительства Москвы временно перешли на удаленную работу: теперь в онлайне они не только выполняют задания наставников, но и общаются друг с другом и получают новые знания. Четырехдневный онлайн-марафон вебинаров для стажеров провел асессор конкурса «Проектный Олимп», ведущий эксперт—центра компетенций контрольно-надзорной деятельности кафедры финансового менеджмента и финансового права МГУУ Правительства Москвы Андрей Лякин.

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

Мы собрали несколько советов, которые помогут вам стать настоящим лидером проекта:

Хорошо исследуйте конкретный проект, его предметную область и заказчика.

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

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

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

Пять способов стать лучшим руководителем проектов:

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

Тайм-менеджмент и продуктивность. Изучайте эффективное управление временем и производительностью— это важнейшие навыки руководителя.

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

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

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

Отзывы участников:

«Ведущий вебинара помог четко представить картину правильного и эффективного управления проектом, понять, какие могут быть подводные камни в реализации проекта и как с ними бороться, а также какова роль руководителя проекта в достижении успеха. Было много наглядных примеров, которые помогли усвоить материал. Теперь эта область знаний не кажется мне непонятной и недостижимой!» — Валентина Афонина, стажер Агентства инноваций Москвы.

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

«Тема вебинаров мне близка, потому что я не раз была в команде организаторов проекта, а в университете изучала предмет „Управление социальными проектами“. Мне понравился формат вебинаров в онлайне — мы подробно разобрались в теме, закрепили теорию на практических заданиях, задали вопросы и оперативно получили на них ответы», — Ольга Березкина, стажер Комитета общественных связей.

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

Стажировка в Правительстве Москвы сближает даже на расстоянии и дарит возможность развивать себя, становиться еще компетентнее и общаться с единомышленниками.

Присоединяйтесь к проекту, если вы еще не с нами!

Возврат к списку

Scrum, Kanban, PRINCE2 и другие

08 Июл 2016

«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было наверно самой сложной задачей»

— Роджер Лаунис, историк НАСА

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

И хотя лишь единицы из нас столкнутся с задачами такого масштаба, большинство читателей этого блога так или иначе сталкивается с проектным управлением. По оценкам PMI к 2020 году появятся 15 миллионов новых позиций проектных специалистов – а многим другим профессионалам зачастую приходится руководить мини-проектами, хотя бы на личном уровне.

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

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

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

В этой статье мы рассмотрим:

И прежде чем рассматривать конкретные методы, давайте ответим на очевидный вопрос – «А зачем вообще нужны системы и методы управления проектами?» – рассмотрим, естественно, кратко, историю управления проектами и определим базовые термины проектного управления.

Почему «управление проектами»?

Имена Нила Армстронга и Базза Олдрина навсегда войдут в историю как символы одного из величайших достижений человечества – высадке человека на Луну. Однако основной вклад в это событие внесли 400 000 сотрудников НАСА и 20 000 компаний и университетов, работавших вместе над миссией «Аполлон».

В 1961 году Джон Кеннеди поставил задачу высадить человека на спутнике Земли и вернуть его обратно – при том, что на тот момент НАСА отправляли человека в космос лишь на 15 минут. Такая амбициозная цель потребовала невероятного количества ресурсов, кооперации, инноваций и планирования.

Как говорится в книге НАСА «Managing the Moon Program», основная проблема состояла не в том, «что делать?», а в том, «как сделать столько за такой короткий срок?». По словам доктора Макса Фагета (Dr. Max Faget), главы инжиниринга в Космическом центра имени Линдона Джонсона (The Lyndon B. Johnson Space Center, JSC), тогда в НАСА не представляли, как уложить все необходимые действия в 10 лет. А потому первым шагом стало «разбить проект на управляемые этапы».

Затем важно было ускорить выполнение каждой отдельной фазы и удостовериться, что команды и компании, работающие на каждой фазе, эффективно взаимодействуют друг с другом и вовремя поставляют результаты. Эта задача была возложена на доктора Джорджа Мюллера (George E. Muller), управлявшего каждой частью проекта «Аполлон», от Белого Дома до поставщика самой мелкой детали. Чтобы контролировать проект было легче, он решил разбить проект на 5 областей: «Контроль Программы», «Системная Инженерия», «Тестирование», «Надёжность и Качество» и «Лётная эксплуатация». Схема управления программой Аполлон представлена на Рисунке 1.

Эта система из 5 этапов – названных «Этапами GEM» в честь инициалов доктора Мюллера – была разработаны «ради фокусировки на тестировании продукта, и на его разработке с учётом того, что его будут тестировать», как отмечает сам Мюллер. «Контроль Программы» определял, что нужно сделать, управлял бюджетом и требованиями, а также управлял взаимосвязями элементов программы. Область «Системная инженерия» отвечала за разработку новых устройств и узлов, «Тестирование» за то, что эти новые элементы работают, «Надёжность и Качество» проверяли разработанные элементы на соответствие требованиям и стандартам, а «Лётная эксплуатация» отвечала за то, что эти узлы будут работать во время полёта.

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

Краткая история проектного управления

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

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

Однако, если Вы – шеф-повар, и готовите не одно блюдо, а несколько, например, салат (приготовление которого состоит из 3 этапов) и десерт (который нужно только подать), то Вам потребуется инструмент, позволяющий отслеживать временные затраты на каждый из элементов и время, когда они должны быть готовы. И тут на помощь приходит один из первых современных инструментов проектного управления: Диаграмма Гантта, представленная на Рисунке 2.

Изобретённая независимо Королем Адамеки (Korol Adamecki) и Генри Л. Ганттом (Genry L. Gantt) в начале XX в., диаграмма Гантта показывает расписание проекта основываясь на датах окончания и завершения задач. В неё вносятся задачи, их длительности и взаимосвязи, а затем высчитывается критический путь – самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта. Взаимосвязи между началом и окончанием разных задач очень важны – вы же не можете подать гостям суп, пока вы его не сварили, не так ли?

Так вот, типовой проект очень похож на проект приготовления и подачи ужина, только в нём гораздо больше задач, взаимосвязей, дедлайнов и видов ресурсов. Проектам с жёсткими дедлайнами диаграмма Гантта помогает решить, когда лучше начинать те или иные задачи, чтобы сократить время реализации. А для проектов с сильными ресурсными ограничениями, диаграмма Гантта предоставляет возможность построить схему в форме событийной цепочки процессов (event-driven process chain) для планирования ресурсов.

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

Для таких проектов лучше подходят гибкие методы управления проектами Agile и связанные с ним подходы, такие как Lean, Kanban и другие. Есть и методы, позволяющие управлять как рабочим потоком, так и временем, и ресурсами – 6 Сигм и Scrum.

Классическое проектное управление

Наиболее очевидный способ сделать свой проект более управляемым – это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. В этом смысле оно напоминает компьютерную игру – нельзя перейти на следующий уровень не завершив предыдущий. Схема рабочего процесса приведена на Рисунке 3.

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

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

5 этапов традиционного менеджмента:

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

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

Этап 3. Разработка. Данная стадия реализуется не для всех проектов — как правило она является частью фазы планирования. В фазе разработки, характерной для технологических проектов, определяется конфигурация будущего проекта и/или продукта и технические способы его достижения. Например в ИТ-проектах на данном этапе выбирается язык программирования. (В отечественной практике данная фаза обычно не выделяется, а термин «разработка» не используется — прим. пер.)

Этап 4. Реализация и тестирование. На этой фазе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам начинает создаваться содержание проекта, определённое ранее, проводится контроль по выбранным метрикам. Во второй части данной фазы происходит тестирование продукта, он проверяется на соответствие требованиям Заказчика и заинтересованных сторон. В части тестирования выявляются и исправляются недостатки продукта.

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

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

Благодаря тому, что классический проектный менеджмент строго привязан ко времени исполнения задач, как правило, заранее определённому на этапе планирования, для реализации проектов в рамках данного подхода отлично подходят инструменты календарно-сетевого планирования. Самым распространённым инструментом календарно-сетевого планирования является уже упомянутая ранее диаграмма Гантта. Существует множество инструментов для её построения – от простых таблиц вроде Excel и Smartsheet до профессиональных программных пакетов вроде Microsoft Project и Primavera.

Сильные стороны классического проектного менеджмента

Сегодня довольно часто говорится о том, что классический водопадный подход устарел, но он и не думает сдавать позиции. Большим плюсом данного подхода является то, что он требует от Заказчика и руководства компании определить, что же они хотят получить, уже на первом этапе проекта. Раннее включение привносит определённую стабильность в работу проекта, а планирование позволяет упорядочить реализацию проекта. Кроме того, этот подход подразумевает мониторинг показателей и тестирование, что совершенно необходимо для реальных проектов различного масштаба.

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

Слабые стороны классического проектного менеджмента

Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Руководство компании Toyota, знаменитую созданием таких систем как Lean и Kanban, часто критикуют за то, что они применяют классический подход в разработке софта для своей компании, причём именно за недостаток гибкости.

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

Agile

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

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на Рисунке 5.

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

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова (об истории появления Agile можно прочесть здесь – прим.пер.). Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto), закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): Scrum, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

Сильные стороны Agile

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

Один из принципов Agile: «Реакция на изменения важнее следования плану». Именно быстрая и относительно безболезненная реакция на изменения является причиной тому, что многие крупные компании стремятся сделать свои процессы более гибкими. Кроме того, Agile отлично подходит для проектов с «открытым концом» — например, запуску сервиса или блога.

Вотчина Agile – разработка новых, инновационных продуктов. В проектах по разработке таких продуктов высока доля неопределённости, а информация о продукте раскрывается по ходу проекта. В таких условиях реализовывать проект по «водопаду» становится невозможно– нет информации для планирования.

Слабые стороны Agile

В отличие от PRINCE2 и PMBOK Agile – не является ни методологией, ни стандартом. Agile — это набор принципов и ценностей. Слабая сторона состоит в том, что каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile. Это непростой и длительный процесс, который потребует изменений всей организации, начиная процедурами и заканчивая базовыми ценностями. Это тернистый путь и не всем организациям он под силу.

Этот путь потребует от лидера изменений не только знаний и упорства, но и серьёзных административных ресурсов, а также затрат. К счастью, существуют готовые наборы практик, которые облегчают Agile-трансформацию организации. К таким наборам относятся фреймворк Scrum, метод Kanban и многие другие – Crystal, LeSS, SAFe, Nexus.

Scrum

Гибкий фреймворк, созданный в 1986 году, считается самым структурированным из семейства Agile. Созданный в 1986 году, он сочетает в себе элементы классического процесса и идеи гибкого подхода к управлению проектами. В итоге получилось очень сбалансированное сочетание гибкости и структурированности.

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

Как уже говорилось, Владелец продукта является представителем Заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если Заказчика нет. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены.

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него него зависит, какую ценность получит Заказчик по итогам спринта.
Планирование Спринта: После того, как Владелец продукта определил приоритеты, команда совместно решает, что же конкретно они будут делать во время грядущей итерации, как достигнуть поставленной на предыдущей встрече цели. Команды могут применять различные инструменты планирования и оценки на данном этапе, лишь бы они не противоречили принципам и логике Scrum. Планирование Спринта проводится в самом начале итерации, после Встречи по упорядочиванию продукта.
Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.
Подведение итогов Спринта: Цель этапа – обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.
Ретроспектива Спринта: Проводится сразу после Подведения итогов спринта и до планирования следующего спринта. На нём команда выясняет, насколько чётко и слаженно проходил процесс реализации этапа. Обследованию подвергаются возникшие проблемы в работе, методологии и взаимодействии. Именно этот этап позволяет команде провести рефлексию и следующий Спринт провести эффективнее.

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

Сильные стороны Scrum

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

Онлайн телеканал Netflix является отличным примером быстрых поставок результатов. Сайт ресурса обновляется каждые две недели благодаря Scrum, который не просто позволяет работать с высокой скорости, но и аккумулирует пользовательский опыт и даёт возможность выявить самое главное для клиентов.

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

Слабые стороны Scrum

Scrum очень требователен к команде проекта. Она должна быть небольшой (5-9 человек) и кроссфункциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга.

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

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

Lean

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

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

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

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

Сильные стороны Lean

Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean

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

А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций ̶ главное помнить об этом.

Kanban

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент.

Кроме того, создатель Kanban вдохновлялся супермаркетами, а именно их принципом – «держи на полках только то, что нужно клиенту». А потому в Kanban разрешается оставить неоконченную задачу на одном из этапов, если её приоритет изменился и есть другие срочные задачи. Неотредактированная статья для блога, подвешенная без даты публикации или часть кода функции, которую возможно не будут включать в продукт – всё это нормально для работы по Kanban.

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

Для работы с Kanban необходимо определить этапы потока операций (workflow). В Kanban они изображаются как столбцы, а задачи обозначают специальные карточки. Карточка перемещается по этапам, подобно детали на заводе, переходящей от станка к станку, и на каждом этапе процент завершения становится выше. На выходе мы получаем готовый к поставке заказчику элемент продукта. Доска со столбцами и карточками может быть как настоящей, так и электронной – даже здесь Kanban не накладывает никаких ограничений на пользователей.

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

Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны Kanban

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

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

Слабые стороны Kanban

Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких дедлайнов. Для жёстких дедлайнов лучше подходит классический подход или Scrum.

6 сигм (Six Sigma)

Компания Motorola, наряду с Toyota, также внесла вклад в развитие мирового проектного управления. Инженер этой компании Bill Smith создал концепцию 6 сигм в 1986 году. Это более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, также снижения количества брака и проблем.

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

Для этого было предложен процесс из 5 шагов, известных как DMEDI:

Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.
Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.
Исследование (Explore): На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.
Разработка (Develop): На данном этапе реализуются планы и решения, принятые на предыдущих этапах. Важно понимать, что на данном этапе необходим детальный план, в котором описаны все действия, необходимые для достижения поставленных целей. Также на данном этапе измеряется прогресс проекта.
Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

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

Сильные стороны 6 сигм

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

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

Слабые стороны 6 сигм

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

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

PRINCE2

НАСА – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2. Название произошло от акронима «PRojects IN Controlled Environments version 2», что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту. Если сравнивать PRINCE2 другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм.

Методология PRINCE2 в отличие от, например, свода знаний PMBOK не содержит:

Специализированных аспектов управления проектом, например, отраслевых;
Конкретных практик и инструментов управления проектами, таких как диаграмма Гантта, WBS и т.п.

PRINCE2 концентрируется на управленческих сторонах проекта, выраженных в 7 принципах, 7 процессах и 7 темах проекта.

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

Кроме того, PRINCE2 рекомендует адаптировать методологию под каждую конкретную организацию.

В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:

Бизнес-аспект (Принесёт ли этот проект выгоду?)
Потребительский аспект (Какой нужен продукт, что мы будем делать?)
Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)

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

Согласно PRINCE2 у каждого члена команды есть своя чёткая роль в каждом из 7 процессов:

Начало проекта (Starting up a project):В ходе данного процесса назначается менеджер проекта и определяются общие требования к характеристикам продукта. Менеджер проекта, чья основная задача – внимание к деталям, отчитывается перед Управляющим комитетом проекта, который отвечает за общее руководство проектом. Именно Управляющий комитет следит за тем, чтобы проект не сбился с курса, и он же полностью отвечает за успех проекта.
Инициация проекта (Initiation a project):В ходе данного процесса менеджер проекта составляет «Документацию по инициации проекта», в которой содержится план проекта по стадиям. Стадии могут длиться разное количество времени, но, как и в классическом подходе, они следуют строго друг за другом.
Руководство проектом (Directing a project): Данный процесс предоставляет возможность Управляющему комитету нести общую ответственность за успех проекта, не погружаясь в детали, которые находятся в границах полномочий менеджера проекта.
Контроль стадии (Controlling a stage):При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям. В обязанности менеджера проекта входит отслеживать в ходе выполнения стадии отклонения от плановых параметров проекта по срокам, содержанию, бюджету и др. Если эти отклонения превышают данные руководителю проекта Управляющим комитетом полномочия (в терминологии PRINCE2 – допуски), менеджер проекта обязан проинформировать Управляющий комитет и предложить пути выхода из ситуации.
Управление созданием продукта (Managing Product Delivery):Процесс управления созданием продукта представляет собой взаимодействие менеджера проекта и менеджера команды по созданию одного из продуктов проекта. В обязанности менеджера проекта в данном процессе входит делегирование полномочий по созданию продукта менеджеру команды и приемка созданного продукта.
Управление границами стадии (Managing a stage boundary): В ходе данного процесса менеджер проекта предоставляет Управляющему комитету всю необходимую информацию для оценки результатов пройденной стадии и принятия решения о переходе на следующую стадию.
Завершение проекта (Closing a project):Одно из отличий PRINCE2 в том, что процесс завершения проекта не выделяется в отдельный этап или стадию, как в классическом подходе, а выполняется в рамках финальной стадии создания продукта. Цель процесса – подтвердить, что продукт проекта принят, или проект больше не может принести ничего полезного.

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

Сильные стороны PRINCE2

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

Слабые стороны PRINCE2

Отсутствие отраслевых практик;
Отсутствие конкретных инструментов для работы в проекте.

Лучшая система управления проектами … для Вас!

Управление проектами – это наука, но наука не самая точная. В данной области нет незыблемых основ и универсальных решений. Если вам удастся найти метод, идеально подходящий вашему проекту – считайте, что вам крупно повезло, ведь большинству менее удачливых руководителей приходится прикладывать усилия для создания и настройки собственных систем управления проектами. Эти системы могут быть составлены из элементов существующих систем или даже созданы совершенно с нуля, как в случае с миссией «Аполлон». Главное используйте что-нибудь, что даст вам хоть какую-то структуру и позволит не забыть о том, что главное для вашего проекта.

Как получить международный сертификат по Agile?

Для тех, кто хочет получить систематизированное понимание Agile, разобраться с преимуществами и недостатками гибкого подхода к проектам и продуктам, найти области наилучшего применения Agile и получить международный сертификат ICAgile Certified Professional — наш тренинг «ICAgile Certified Professional»

Смотрите также:

Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи:

Источник: https://zapier.com/learn/ultimate-guide-to-project-management/project-management-systems/

Что такое управление проектами? | The Workstream

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

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

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

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

Польза ПО для управления проектами

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

В чем польза ПО для управления проектами? Оно помогает наладить работу благодаря следующим возможностям.

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

Отличный проект начинается с отличного плана

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

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

Документирование взаимоотношений в проектe — PMDoc™

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

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

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

То есть, PR — наше всё!

Определи кто и зачем коммуницирует в проекте

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

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

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

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

Всё это заносится в первую часть Плана коммуникаций проекта.

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

Определи с помощью чего будут общаться участники проекта

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

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

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

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

Задай правила коммуникаций

Я часто говорю своим проектным командам гротескную фразу «Надоело работать? Собери совещание». Знакомо? Так вот, нужно понимать, что любые, самые классные коммуникации могут превратиться в банальный трёп, если ими не управлять. И начинается это управление с задания правил коммуникаций. Например:

Считается ли отправленное членом команды электронное письмо со своего адреса, документом который он «формально подписал»?
Какова может быть длительность и частота совещаний (к примеру, не более 40 мин; не чаще 2 раз в неделю)?
Другие правила проведения совещаний:
- предварительная рассылка повестки совещания;
- обязательное ведение протокола совещания с принятыми решениями, поставленными задачами и ответственными исполнителями;
- отслеживание исполнения задач.
Горизонтальные и вертикальные связи проекта, а так же порядок эскалации.
Формат и периодичность отчётности.

Кстати о периодичности отчётности.

Тактовый генератор проекта

Знаешь чем отличается «команда» от «группы»? Даю подсказку — «спортивная команда» и «группа студентов». Правильно! У команды одна цель, в группе — у каждого своя.

Видел как работает команда гребцов на байдарках? Помимо общей цели у них ещё и отличная слаженная работа, которая задаются общим «тактовым генератором». Не знаешь такого термина? Тебе сюда — wikipedia.org/Генератор_тактовых_импульсов.

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

Но отчётность должна быть не только регулярная, но и одинаково понимаемая различными участниками проекта. Для этого:

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

Общий язык проекта

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

Для этого мы создаём Глоссарий проекта и тоже вносим его в План коммуникаций.

Итого

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

Шаблоны всех этих и других документов по управлению коммуникациями проекта можно получить/полистать здесь:
Полный пакет шаблонов, созданных на основе PMBOK (5-й редакции) можно получить здесь: ОСУП.Комплект.v5
Полный пакет шаблонов, созданных на основе ISO 21500:2012 можно получить здесь: ИСО21500:Комплект
Все примеры и шаблоны документов портала PMDoc, связанные с управлением коммуникациями различных проектов, можно получить здесь: Коммуникации проекта.

Коммуникации по проекту: ответственность менеджера проекта

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

Я рецензировал книгу Карла Притчарда «Набор средств коммуникации для управления проектами» и меня особенно заинтересовал его раздел «Роль менеджера проекта в коммуникациях».

Я не говорю, что полностью согласен, но я думаю, что это хорошее мнение одного человека по этой теме.

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

Вот взгляд на эту тему мистера Причарда…

Роль руководителя проекта в коммуникациях

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

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

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

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

Критическая роль коммуникации в управлении проектами

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

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

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

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

Загрузите наше бесплатное руководство по продвижению вашей карьеры в области управления проектами

Узнайте все, что вам нужно, от востребованных навыков до растущих возможностей трудоустройства в отрасли.

СКАЧАТЬ

Важность эффективных коммуникаций в управлении проектами

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

«Коммуникация является наиболее важным аспектом в управлении проектами, потому что то, что менеджеры проектов делают большую часть времени, — это общение для координации усилий», — говорит Сарманн Кеннедид, доцент программы магистра наук в области управления проектами Северо-Восточного региона. «Для координации усилий им необходимо собрать много информации и распространить ее среди всех команд, участвующих в проекте.”

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

«Коммуникация — один из важнейших компонентов [успешного управления проектами] и навыков, которыми должен обладать руководитель проекта», — говорит Кеннеди.

Типы коммуникации в управлении проектами

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

1. Перспектива проекта

Когда общение рассматривается с точки зрения самого проекта, оно обычно делится на две категории: внутреннее и внешнее общение.

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

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

2. Организационная перспектива

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

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

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

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

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

3. Формальная перспектива

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

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

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

4. Перспектива канала

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

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

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

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

Советы по эффективному общению в проекте

1. Используйте технологии.

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

2.Помните о культурных и языковых барьерах.

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

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

3. Поймите, кто и как должен получать информацию.

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

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

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

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

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

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

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

Коммуникация и управление проектами | См. Связь

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

Менеджер проекта должен обладать различными навыками, чтобы успешно руководить своей командой, и те, кто заинтересован в карьере менеджера проекта, могут развить эти навыки в онлайн-программе Master of Communication Management (MCM). Студенты онлайн-программы MCM разовьют коммуникативные навыки, которые компании ищут в своих менеджерах проектов, что сделает их ценным ресурсом для любого бизнеса.

Фотография предоставлена Amtec

Своевременное сообщение важной информации

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

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

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

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

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

Основная роль коммуникации в управлении проектом — убедиться, что все участники разделяют это видение и цели проекта.

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

Согласование сообщения с проектом

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

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

Для многих руководителей проектов наиболее полезными являются активные методы общения.Они включают непосредственное взаимодействие с членами команды и являются наиболее эффективным способом убедиться, что все понимают свои обязанности. Согласно данным 2020 Project Management, некоторые из наиболее распространенных форм активного общения:

Личные встречи
Видеоконференцсвязь
Телефонная конференция

Вебинары — это форма активного общения, которая становится все более популярной среди руководителей проектов, особенно тех, кто работает в крупных компаниях.По сути, вебинар — это традиционная устная презентация, которая проводится через Интернет, а не лично. Эти презентации особенно полезны для проектов, где члены команды находятся в разных местах, и их сбор будет трудным или дорогостоящим.

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

Блоги и сайты
Письма
Доски электронных объявлений
Подкасты и веб-трансляции

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

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

Собираем набор навыков менеджера проекта

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

Подключение к большему изображению

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

Приоритезация

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

Гибкое мышление

В соответствии с рекомендациями Innovative Management Solutions руководители проектов также должны быть готовы к изменению приоритетов в ходе проекта.То, что могло быть основной целью в начале процесса, может стать менее важным, когда работа будет завершена. Менеджер проекта должен иметь возможность переоценивать приоритеты по мере продвижения проекта, а затем сообщать новые цели членам команды.

Слушайте и отвечайте соответственно

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

Характеристики эффективного менеджера проекта

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

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

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

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

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

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

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

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

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

Коммуникация является неотъемлемой частью эффективного управления проектами. Те, кто заинтересован в развитии сильных коммуникативных навыков на работе, могут посетить онлайн-программу USC Master of Communication Management, чтобы увидеть, как студенты развивают сильные коммуникативные навыки, и узнать, как применять эти навыки в реальных проектах и деловых ситуациях.

Источники:

15. Коммуникационное планирование — Управление проектами

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

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

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

Ответы на эти вопросы должны быть задокументированы в плане коммуникаций.

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

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

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

Синхронная связь

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

Прямая встреча: Сбор членов команды в том же месте
Конференц-звонок: Телефонный звонок, в котором участвуют несколько человек
Аудиоконференция: Как конференц-связь, но проводится онлайн с использованием программного обеспечения, такого как Skype
Компьютерная конференция: Аудиоконференция с подключением между компьютерами, которые могут отображать документ или электронную таблицу, которые могут редактировать обе стороны
Видеоконференция: Подобна аудиоконференции, но с живым видео участников.Некоторые портативные компьютеры имеют встроенные камеры для видеоконференцсвязи
IM (обмен мгновенными сообщениями): Обмен текстовыми или голосовыми сообщениями с использованием всплывающих окон на экранах компьютеров участников
Текстовые сообщения: Обмен текстовыми сообщениями между мобильными телефонами, пейджерами или персональными цифровыми помощниками (КПК) — устройствами, которые содержат календарь, список контактов, список задач и другие программы поддержки

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

Помнить часовые пояса

Важно помнить часовые пояса и правильно рассчитывать разницу между вашим поясом и поясом ваших коллег, чтобы не пропустить важные встречи или дедлайны.В городах и странах к северу или югу друг от друга используется одно и то же местное время. Имейте в виду, что многие образованные люди в Соединенных Штатах и Канаде думают, что Южная Америка находится непосредственно к югу от Северной Америки. Как видите, страны Южной Америки могут находиться в пяти часовых поясах к востоку от Северной Америки. Полезным сайтом для преобразования местного времени в другой часовой пояс является Конвертер часовых поясов.

Рисунок 15.1: Мировые часовые пояса.

Часовые пояса рассчитываются относительно часового пояса Королевской обсерватории в Гринвиче, Англия.Время в этом месте — среднее время по Гринвичу (GMT). В более поздних источниках оно обозначено как всемирное координированное время (UTC) вместо GMT. Часовые пояса продвигаются от Гринвича в восточном направлении (рис. 15.1). Однако на международной линии перемены дат (примерно в средней точке мира от Гринвича) вы вычитаете часовой пояс из GMT. Чтобы избежать путаницы между утра и вечера, время часто указывается в 24-часовом формате. Например, полночь обозначается как 00:00, полдень — 12:00 и 1 час.м. 13:00.

Руководитель проекта разработки программного обеспечения в Торонто находится в пяти часовых поясах к западу от эталонной зоны, поэтому время указывается в формате UTC – 5 (или GMT – 5). Если в контрольной зоне полдень, в Торонто 7 часов утра (на пять часов раньше). Менеджер хотел бы связаться с членом команды проекта в Париже, Франция. Париж находится на один часовой пояс к востоку от контрольной зоны (UTC + 1 или GMT + 1). Если в контрольной зоне полдень (12:00), то это 13:00. (13:00) в Париже. Это означает, что разница между Торонто и Парижем составляет шесть часов.Если руководитель проекта дождется после обеда, чтобы позвонить (13:00 в Торонто), в Париже (19:00) будет слишком поздно, чтобы с кем-то связаться.

Асинхронная связь

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

Доставка почты и посылок

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

Факс

Факсимильные аппараты

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

Электронная почта

Электронная почта (email) широко используется для координации проектов и общения между членами команды. Он имеет несколько ценных характеристик для управления проектами:

Информация может быть отправлена списку членов команды.
Сообщения могут быть сохранены для документирования процесса в случае недопонимания или недопонимания.
Файлы можно прикреплять и распространять.

Блог проекта

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

Действительно простое распространение (RSS)

Некоторые проекты напрямую зависят от внешних факторов, таких как политические выборы, экономические тенденции, корпоративные слияния, технологические или научные достижения или погодные условия. Чтобы быть в курсе этих факторов, вы можете подписаться на источники новостей в Интернете.Технология, которая облегчает этот процесс, — это Really Simple Syndication (RSS). Веб-страницы с новостными RSS-каналами имеют помеченные ссылки.

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

Оценка новых коммуникационных технологий

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

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

Так как же составить план коммуникации?

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

На рисунке 15.2 показан шаблон плана связи.

Рисунок 15.2 Шаблон плана связи

Текстовые атрибуты

Эта глава Управление проектами является производным от следующих текстов:

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

Время чтения: около 8 минут

Автор: Lucid Content Team

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

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

Что такое коммуникационный план управления проектом?

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

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

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

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

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

Почему важен план коммуникации

для управления проектами ?

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

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

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

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

Как составить план коммуникации для управления проектом

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

1. Выберите формат.

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

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

Пример плана коммуникации (Щелкните изображение, чтобы изменить онлайн) Матрица коммуникации (Щелкните изображение, чтобы изменить онлайн)

2. Установите цель коммуникации

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

3. Определите заинтересованные стороны

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

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

Узнайте, как

4. Определите способы связи

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

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

Рассмотрите следующие методы в зависимости от того, что ваши заинтересованные стороны, скорее всего, увидят или посетят:

Еженедельные проверки
Встречи, будь то личные, по телефону или посредством видеоконференцсвязи
Итоги встреч
Отчеты о состоянии
Официальные презентации
Опросы
Списки дел
Панели управления проектами
Приложения для совместной работы, такие как Slack или Google Hangouts

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

5. Определите частоту обмена сообщениями

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

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

6. Определите, кто предоставляет обновления для связи.

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

Что делать, если ваш проект изменится?

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

Как следует передавать конфиденциальную информацию?

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

Процесс передачи конфиденциальной информации (Нажмите на изображение, чтобы изменить в Интернете)

Как использовать план коммуникации для управления проектом

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

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

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

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

Не зацикливайтесь на деталях

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

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

Стандартизируйте процесс

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

Регулярно обновляйте свой план

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

Скрыть конфиденциальную информацию

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

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

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

Узнайте, как

Роли и обязанности менеджера проекта и группы управления проектами

Еще со школьных дней мы слышим о проектах (научные проекты, математические проекты, групповые проекты — помните?). Затем у вас есть что-то столь же масштабное, как миссия НАСА InSight (для изучения внутренней части Марса).Это также называется проектом.

Итак, как именно определить проект?

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

И, конечно же, проекты не выполняются сами по себе. Нам нужны люди, чтобы их выполнять. Здесь на сцену выходят менеджеры проектов и команда управления проектами. Когда мы смотрим на жизненный цикл управления проектами, в него вовлечено много людей и групп. Они помогают в разработке, разработке и достижении целей, поставленных в проекте. Цель этой статьи — определить роли и обязанности менеджера проекта, а также команды управления проектом.

Кто такой руководитель проекта?

Менеджер проекта — это человек, ответственный за руководство проектом.Другими словами, менеджеры проектов являются инициаторами проекта. Они гарантируют, что проект будет завершен в указанные сроки и доставлен клиенту без каких-либо недостатков. Он / она занимается всеми аспектами проекта от начала проекта до его реализации.

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

Что такое команда проекта?

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

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

Обязанности руководителя проекта

Обязанности менеджера проекта могут варьироваться от организации к организации. Иногда они могут даже меняться в зависимости от потребности проекта.Но в разных компаниях есть некоторые основные обязанности, которые берут на себя большинство менеджеров проектов. Что это? Читайте ниже:

Планирование

«Планируйте свою работу и выполняйте свой план» — Наполеон Хилл

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

Итак, что именно включает в себя планирование? Планирование отвечает на каждый из следующих вопросов:

Какие задачи нужно выполнить?
Кто должен выполнять эти задачи?
Когда должны быть выполнены эти задачи?

На этом этапе менеджер проекта определяет объем проекта и, соответственно, разрабатывает план и график проекта. Он или она разрабатывает эффективные процедуры и политики, чтобы проект был доставлен заказчику.Это делается с учетом указанного времени и указанного бюджета. Кроме того, планирование включает определение имеющихся ресурсов (человеческих, финансовых и т. Д.). Также учитывается время, необходимое для завершения проекта.

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

Организация

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

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

Ведущий

Лидерство — это та широкая роль, которая может соответствовать всем остальным ролям менеджера проекта. Следовательно, это можно считать самой важной обязанностью менеджеров проектов.

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

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

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

Мониторинг

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

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

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

Связь

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

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

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

Управление рисками

Проекты редко проходят гладко. Таким образом, риск — неизбежная часть проекта. Таким образом, управление этими неопределенными условиями, которые могут оказать негативное влияние на проект, является важной ролью менеджера проекта.Очень важно, что PMBOK Project Management Institute указывает управление рисками как одну из ключевых областей знаний. Это означает, что для получения сертификата руководитель проекта должен проявить компетентность в этой области.

Как менеджер проекта справляется с рисками?

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

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

Обязанности группы управления проектом

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

В случае, если член команды был принят в команду как «эксперт» в какой-то области. Тогда ожидается, что он или она проявит инициативу и не будет ждать, пока руководитель проекта направит их даже в небольших задачах. Что делать, если члены команды не ладят друг с другом? Это может привести к задержкам и, в худшем случае, к провалу всего проекта. Следовательно, им нужно работать с другими членами команды и относиться к ним с сердечным уважением.

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

Заключение

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

Получите сертификат и станьте успешным менеджером проекта

Почему управление коммуникациями в проекте имеет решающее значение для успеха проекта

Согласно отчету PMI, каждый третий проект страдает от сбоя связи. Фактически, компании рискуют 135 миллионами долларов на каждый миллиард долларов, потраченный на проект, и новое исследование показывает, что 75 миллионов долларов из этих 135 миллионов долларов (56 процентов) находятся под угрозой из-за неэффективных коммуникаций, что указывает на острую необходимость для организаций устранять недостатки коммуникации на местах. уровень предприятия.

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

Почему эффективная коммуникация важна в управлении проектами?

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

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

Как сбой коммуникации в проектах?

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

Вот несколько причин, по которым связь не работает в большинстве проектных команд:

Неадекватное планирование

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

Непрозрачность

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

Отсутствие доработки с течением времени

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

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

Три этапа процесса коммуникации при управлении проектом

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

1. Планирование коммуникации

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

Процесс планирования стратегии управления коммуникациями должен включать определение:

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

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

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

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

3. Монитор связи

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

Ключевые факторы коммуникации при управлении проектами

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

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

Цели

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

Аудитория

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

Сообщение

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

каналов

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

Как создать план коммуникации по проекту?

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

Сюда входят:

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

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

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

1. Введите как можно больше переменных.

Не позволяйте заинтересованным сторонам гадать (i). что, (ii). кто, (iii). почему, (iv). как, или (v). где им передавалась какая-либо информация. Заинтересованные стороны должны уметь понимать смысл и принимать решения, как только информация доходит до их стадии процесса.

Таким образом, достигается консенсус без потери времени на выполнение работы.

2. Стройте для своей команды

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

3. Будьте гибкими

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

4. Правильный выбор инструментов

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

Успешные проекты зависят от эффективного общения

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

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

Наличие программного обеспечения для управления проектами, такого как Kissflow Project, может помочь вам упростить коммуникацию в проекте и лучше согласовать команды.