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

Аннотация: Формирование стратегии коммуникаций. Пример стратегии коммуникации. Идентификация объектов управления конфигурацией проекта. Процедура создания нового элемента конфигурации. Инфраструктура проекта. Пример требований к инфраструктуре офиса проекта (фрагмент). Пример процедуры создания инфраструктуры проекта. Формирование базовой линии конфигурации проекта. Организация управления конфигурацией проекта. Организация документирования статуса элементов конфигурации. Пример процедуры обеспечения хранения документов. Пример процедуры рассылки документов. Пример процедуры подготовки документов. Пример процедуры отчетности о деятельности.

Для выявления эффективности существующих формальных каналов связи ниже приведен список рекомендованных вопросов .

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

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

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

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

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

Таблица 7.2. Пример матрицы коммуникаций

Условные обозначения		Формальные				Специфичные					Неформальные
0 Основной канал коммуникаций? Дополнительный канал коммуникаций		Совещания	Интернет	Телеконференции	Бюллетени	Инфо-сессии	Бюллетень проекта	Обучение	Стенды вопросов	Коучинг	Электронная почта	Общение в фойе	Телефонные разговоры	elevator pitch
Участники проекта	Отдел сбыта
	Руководство
	среднего звена
	Производствен-
	ные отделы
	Поставщики
	Клиенты
	Профсоюзы

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

Организация обратной связи по проекту

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

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

Мониторинг эффективности каналов информирования предполагает следующие аспекты:

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

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

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

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

Формирование стратегии коммуникаций. Идентификация объектов управления конфигурацией проекта. Процедура создания нового элемента конфигурации.

Инфраструктура проекта. Формирование базовой линии конфигурации проекта.

Организация управления конфигурацией проекта.

Организация документирования статуса элементов конфигурации.

Пример стратегии коммуникации.

Пример требований к инфраструктуре офиса проекта (фрагмент).

Пример процедуры создания инфраструктуры проекта.

Пример процедуры обеспечения хранения документов.

Пример процедуры подготовки документов.

Пример процедуры отчетности о деятельности.

Формирование стратегии коммуникаций

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

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

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

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

3. Удовлетворение потребности участников проекта действовать Сотрудники должны быть проинформированы, какие средства,

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

Пример стратегии коммуникации

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

1. Цели и задачи информирования участников проекта Например:

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

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

§ проинформировать сотрудников компании о проекте, его важности и выгодах;

§ обеспечить доступность, корректность и своевременность получения информации о проекте;

§ поддерживать интерес к проекту на всех фазах его реализации;

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

§ обеспечить своевременность получения информации о предстоящих изменениях целевыми аудиториями;

§ сформировать образ проекта как открытой, прозрачной и доступной инициативы;

§ реализовать сбор сведений об ожиданиях/опасениях бизнес-экспертов о предстоящих изменениях;

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

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

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

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

Указание конкретных лиц, ответственных за проектные коммуникации, и их места в организационной структуре проекта.

3. Целевая аудитория

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

1. Бизнес-эксперты

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

2. Ответственные за преобразования (1-го и 2-го уровня) Первый уровень представлен сотрудниками из числа руководителей

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

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

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

3. Конечные пользователи

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

4. Каналы коммуникаций

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

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

Рис. 7.1. Каналы коммуникаций и их воздействие

1. Насколько быстро и как часто официальные решения руководства компании транслируются по этим коммуникационным каналам?

2. Какие заинтересованные стороны могут быть проинформированы посредством данного канала?

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

4. Каким образом производится оценка данного канала коммуникаций ?

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

· Кто является (неформальным) лидером в организации?

· Чье мнение имеет наибольший вес при обсуждении важных вопросов?

· Каково отношение в организации к открытому распространению проектной информации и прозрачности деятельности смежных отделов?

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

В матрице коммуникаций (см. табл. 7.2) по горизонтали перечислены все каналы коммуникаций , сгруппированные в 3 категории, которые упомянуты выше, а по вертикали – все участники проекта. На пересечении соответствующих строк и столбцов необходимо отражать, какой именно статус имеет тот или иной канал связи: основной, дополнительный или специфичный. Таким образом, просматривая строки, можно оценить степень дублирования информирования – взаимодействие с участниками по нескольким коммуникационным каналам. Каждая группа участников должна быть проинформирована хотя бы раз по формальному каналу, хотя бы раз по специфичному и один раз по неформальному коммуникационному каналу проекта. Степень дублирования следует соотносить с анализом воздействия (см. соответствующий раздел) участников проекта: если участник проекта является "агентом", то степень дублирования должна быть максимально высокой.

Таблица 7.2. Пример матрицы коммуникаций

Условные обозначения

Формальные

Специфичные

Неформальные

0 Основной канал коммуникаций?Дополнительный канал коммуникаций

Совещания

Интернет

Телеконференции

Бюллетени

Инфо-сессии

Бюллетень проекта

Обучение

Стенды вопросов

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

Общение в фойе

Телефонные разговоры

Участники проекта

Отдел сбыта

Руководство

среднего звена

Производствен-

ные отделы

Поставщики

Профсоюзы

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

Организация обратной связи по проекту

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

Мониторинг эффективности каналов информирования предполагает следующие аспекты:

· качество информации о проекте, поступающей по установленным официальным каналам информирования;

· достаточная интенсивность поступающей информации;

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

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

Идентификация объектов управления конфигурацией проекта

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

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

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

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

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

· разработка планов и процедур процесса управления конфигурацией;

· обеспечение реализации планов и документирование результатов;

· определение базовых положений проекта и содержание релизов;

· организация и контроль выполнения процедур процесса управления конфигурацией;

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

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

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

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

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

Процедура создания нового элемента конфигурации

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

Инфраструктура проекта

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

· рабочие места;

· системы (серверы приложений и баз данных).

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

Пример требований к инфраструктуре офиса проекта (фрагмент)

Специальные помещения

Для осуществления рабочей группой проекта работ в группе компаний "Звездочка" заказчик предоставляет специальные помещения для размещения объединенной рабочей группы проекта.

Требования к помещениям

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

на одного сотрудника должно приходиться не менее 5 м2 площади рабочей комнаты, рабочее место каждого сотрудника должно быть обеспечено:

· отдельным рабочим столом;

· стулом;

· двумя розетками электрической сети;

· одной розеткой для доступа в информационную сеть;

· одной розеткой для доступа в телефонную сеть (по дополнительному обоснованию);

· телефонным аппаратом (по дополнительному обоснованию). Каждое помещение офиса должно быть обеспечено:

· сетевым лазерным черно-белым принтером с возможностью двухсторонней печати на листах формата А4 и скоростью печати не менее 30 страниц в минуту;

· вешалкой для верхней одежды всех сотрудников, размещенных в рабочей комнате;

· одним шкафом для документов.

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

· столом для заседаний;

· стульями;

· флип-чартом;

· экраном и проектором для проведения совещаний с участием 10 человек.

Обеспечение членов рабочей группы проекта персональными компьютерами :

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

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

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

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

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

Обеспечение информационного обмена членов рабочей группы проекта

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

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

· Заказчик обеспечивает доступ в Интернет для всех членов рабочей группы проекта.

· Заказчик обеспечивает выделение адреса электронной почты каждому члену рабочей группы проекта.

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

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

· Работы по проекту выполняются сотрудниками исполнителя или субподрядчика на территории заказчика и/или на территории исполнителя/субподрядчика.

· Начало рабочего дня для членов рабочей группы проекта – 9 часов 00 минут, окончание рабочего дня – 18 часов 00 минут, длительность обеденного перерыва – 1 час в интервале времени с 12:00 до 15:00. Руководители проекта от заказчика и исполнителя имеют право изменять режим работы для привлекаемых к проекту сотрудников при условии взаимного согласования таких изменений.

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

Пример процедуры создания инфраструктуры проекта

Для создания инфраструктуры необходимо:

· обеспечить поставки материальных ресурсов – требуется заказать или запросить необходимые ресурсы;

· организовать установку оборудования – обеспечить доставку, провести установку и тестирование оборудования;

· обеспечить сервисное обслуживание оборудования – разработать график сервисного обслуживания;

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

Формирование базовой линии конфигурации проекта

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

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

Организация управления конфигурацией проекта

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

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

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

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

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

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

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

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

В зависимости от размера проекта некоторые пункты плана могут быть пропущены.

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

Организация документирования статуса элементов конфигурации

Пример процедуры обеспечения хранения документов.

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

Пример процедуры рассылки документов.

Пример процедуры подготовки документов

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

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

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

Пример процедуры отчетности о деятельности

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

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

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

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

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

· Microsoft Word 2010 – для подготовки текстовой части проектных документов;

· Microsoft Project 2010 – для подготовки планов проекта;

· Visio 2010 – для графического описания бизнес процессов.

Вся проектная документация будет храниться в электронном виде в библиотеке проекта.

Таблица 7.3. Структура плана управления конфигурацией
Раздел плана	Раздел плана	Требования к содержанию	Дополнительные комментарии
1. Введение		Введение в план УК представляет собой обзор содержания документа. Включает цели, область действия, определения, акронимы, сокращения, ссылки и обзор плана конфигурационного управления	Введение позволяет сделать документ более читаемым – объяснить основные моменты и расставить правильные акценты
1.1 Назначение		Содержит назначение документа "План конфигурационного управления"	Как правило, в назначение можно включить описание целей, которые решает данный план. Ведь план, в зависимости от размеров проекта, от географического распределения, также может различаться
1.2 Область применения		Краткое описание области применения плана; с какой моделью он связан, другие особенности, влияющие на документ	Зачастую можно описать подразделения, участвующие в процессе УК. Описать условия применения. При определении области полезно ответить для себя на ряд вопросов: Какова характеристика подконтрольных конфигурационных элементов? Чем должны управлять интерфейсы высокого уровня? Каковы временные рамки проекта? Каковы доступные ресурсы? Каковы подконтрольные сущности?
1.3 Определения, акронимы и сокращения	Definitions, Acronyms and Abbreviations	Представляет собой определения всех терминов, акронимов и сокращений, требующихся для точной интерпретации документа "План конфигурационного управления". Для предоставления этой информации можно воспользоваться ссылками на словарь проекта	Нам часто приходится сталкиваться с тем, что данный раздел либо игнорируют совсем, либо не придают ему особого значения. Те не менее, глоссарий – это составная и неотъемлемая часть ЛЮБОГО документа, плана УК в том числе.Здесь необходимо отразить и объяснить все термины УК и разрабатываемого продукта. Необходимо помнить, что хороший глоссарий позволит всем находиться в одном терминологическом пространстве. Вопросы: Определения легки и понятны всем участникам проекта? Есть ли список, на который можно легко сослаться? Необходимо ли определять данный термин?
		Этот подраздел представляет полный список всех документов, на которые имеется ссылка где-либо в "Плане конфигурационного управления". Идентифицируется каждый документ по названию, номеру отчета (если есть), дате и организации, его опубликовавшей. Указывается источник, из которого могут быть получены указанные документы. Для предоставления этой информации можно воспользоваться ссылками на приложения или другие документы	План УК редко разрабатывается сам по себе. Он является частью нормативно-методического обеспечения проекта. Нет смысла в плане повторять дословно разделы из других документов. Проще сформировать ссылку на документ, а в данном разделе указать все используемые источники (в том числе документы RUP, стандарты, международные и отраслевые стандарты). Вопросы: Применяются ли в плане положения, методики политики, уже используемые в организации?
		Обзор документа по разделам	Необходимо понимать, что не все участники проекта будут читать документ от корки до корки. Обзор необходим для того, чтобы впоследствии можно было читать те разделы, которые нужны в данный момент данной роли
2. Конфигурационное управление программным продуктом	Software Configuration Management		Один из основных разделов. Описывает все технические и технологические аспекты применения УК в проекте или организации. Количество подразделов и их вложенность могут отличаться от приведенных ниже
2.1 Организация, распределение ответственности и взаимодействия	Organization, Responsibilities and Interfaces	Указывается, кто будет ответственным за выполнение различных зада ч конфигурационного управления, описанных в ходе процессов конфигурационного управления	Данный пункт оговаривает не только список ответственных за выполняемые действия, но может описывать состав и взаимодействие между проектными группами. Данный аспект особенно важен, если речь идет о разработке, распределенной по нескольким географическим точкам. Эффективное дополнение данного раздела – подраздел, описывающий политику доступа. Это может быть простая таблица, в которой описывается в терминах применяемых средств автоматизации процесса, что можно выполнять отдельному участнику проекту, а что для него запрещено. Обычно для этого выбирают способ описания либо только доступных операций, либо только запрещенных.В дальнейшем данная политика перекладывается в средства реализации, где выставляются соответствующие разрешения и запрещения. В зависимости от выбранной проектной структуры (матричной или иерархической) адаптируется политика. Вопросы: Каковы возможности организации по штату для выполнения операций УК? Какова структура управления? Каков стиль управления? Кто будет ответственным за выполнение операций? Какие организационные изменения могут быть в течение жизни плана УК? Каковы планы по поддержке текущей организационной структуры? Какой уровень поддержки необходим для осуществления плана УК? Это единственный проект для руководства, или руководство управляет несколькими проектами одновременно? Как распределяется ответственность при возникновении нештатных ситуаций? Имеются ли особенности для этого проекта, которые могут повлиять на бизнес? Какие действия выполняет группа ССВ в проектном управлении при планировании? Прозрачно ли описаны роли участников?
2.2 Инструментарий, рабочая среда и инфраструктура	Tools, Environment and Infrastructure	Рассматриваются рабочая среда и программное обеспечение, которое будет использовано при выполнении функций конфигурационного управления в ходе жизненного цикла проекта или программного продукта. Описываются инструменты и процедуры, которые нужно использовать для версионного контроля объектов конфигурационного управления, создаваемых в ходе жизненного цикла проекта или программного продукта. Вопросы, рассматриваемые при настройке рабочей среды конфигурационного управления ожидаемый размер данных по программному продукту; распределение рабочей команды; расположение серверов и рабочих станций	Детальное описание данного пункта позволит, для начала, понять самим, какие средства разработки используются в компании (зачастую до начала внедрения в большой компании никто, кроме начальника отдела разработки, не представляет полного списка средств). Полный учет средств необходим еще и для того, чтобы определить методы интеграции средств разработки со средствами УК, ведь известно, что любое средство УК имеет ограниченные возможности по интеграции со средствами разработки. Задача менеджера УК и администратора в этом случае заключается в том, чтобы выбрать сторонние разработки, которые либо делают интеграцию более полной, либо просто добавляют саму интеграцию в используемое средство разработки + в средство УК. Не менее важно описать среду исполнения. Не все средства УК одинаково ставятся на всех платформах. Здесь могут быть особенности. Как вариант: сервер Linux, клиенты Windows. Не все средства УК умеют работать в подобной среде, что надо учитывать при выборе средства. Вопросы: Каковы организационные интерфейсы? Как взаимодействуют процессы? Каков перечень процессов для взаимодействия? Каковы интерфейсы между применяемыми средствами автоматизации? Какова зависимость между ними? Есть ли аппаратная зависимость? Где определены документы, регламентирующие процесс? Они утверждены? Каковы процедуры внесения изменений в эти документы? Каковы задействованные ресурсы (человеческие, оборудование)?
3. Программа конфигурационного управления	The Configuration Management Program
3.1 Конфигурационная идентификация	Configuration Identification		Доступны ли стандартные методы идентификации? В чем состоит используемая схема идентификации объектов УК? Связаны ли программная и аппаратная идентификация (для встроенных систем)? Какие спецификации и планы управления должны быть идентифицированы? Необходима ли специальная схема идентификации, чтобы отслеживать ПС третьей стороны? Есть ли разница в идентификации элементов в зависимости от типа приложений? Есть ли подтипы (например, компилятор C++ может работать с файлами с, срр, h, hpp и др)? Идентифицируются ли и хранятся скрипты автоматизированного тестирования?
3.1.1 Методы идентификации	Identification Methods	Описывается, как именуются, маркируются и нумеруются артефакты проекта или программного продукта. Схема идентификации должна покрывать оборудование, системное программное обеспечение, продукты внешних разработчиков и все артефакты разрабатываемого приложения, указанные в структуре директорий программного продукта; например, модели, планы, компоненты, тестовое ПО, результаты и данные, исполняемые файлы и т.д.	Очень важный пункт, в котором нужно описать все правила именования объектов УК. Также здесь должна быть детально расписана структура каталогов проекта. Обычно к моменту внедрения УК структура каталогов проекта складывается исторически, зачастую – спонтанно. Цель описания – выработать новую, более эффективную структуру. Практика показывает, что человек на этапе восстановления структуры может увидеть уязвимые или неэффективные места
3.1.2 Базовые версии проекта	Project Baselines	Базовые версии предоставляют официальный стандарт, на котором основывается последующая работа и для которого проводятся только авторизованные изменения. Описывается, в какой точке жизненного цикла проекта или продукта должны создаваться базовые версии. Наиболее общие базовые версии должны быть в конце каждой из фаз обследования, проработки проекта, построения системы и передачи в эксплуатацию. Базовые версии также могут создаваться в конце итераций внутри различных фаз или даже чаще. Определяется, кто может создавать базовые версии и что входит в их состав (обычно это интегратор, но может быть и по-другому)	Здесь описывается то, каким образом будет происходить сама работа в средстве УК: как будут ставиться метки, как выпускаться релизы, сколько ветвей для реализации проекта будет использовано и по какому принципу ветви будут именоваться. Обратите особое внимание на данный пункт – без него невозможна эффективная работа. При проработке пункта учитывается региональная раздробленность команды (влияет состав команд, количество регионов), интенсивность внесения изменений, количество выпускаемых релизов за единицу времени. Соответственно, в зависимости от данных показателей выбирается наиболее эффективный способ управления конфигурациями, что и отражается в данном разделе. Вопросы: Какой способ выбора базовых версий используется? Для всех ли элементов базовые версии строятся по одинаковым правилам? Кто разрешает создание базовых версий? Кто физически создает базовую версию? Как и по какому шаблону создаются базовые версии? Как осуществляется продвижение базовых версий? Как и кем осуществляется проверка базовых версий? Какова периодичность проверок? Используется ли существующий (устоявшийся) стандарт именования меток и ответвлений? – Есть ли иерархия между объектами? Какая?
3.2 Контроль конфигураций и изменении	Configuration and Change Control		Как известно, процесс УК состоит из двух частей -управление изменениями и управления версиями. Управление изменениями – неотъемлемая и важная часть процесса. Управлять необходимо любыми изменениями: от заявок пользователей до исправляемых дефектов. Данный раздел содержит полное описание всех запросов на изменения, включая атрибуты и жизненный цикл. Подробное описание – залог успешно построенного процесса УК. Очень часто для отслеживания существенных событий в проекте применяют уведомления различного вида. Как правило, это уведомления по электронной почте (например, при исправлении ошибки тестер получает уведомление и может приступить к тестированию). Укажите все типы уведомлений, которые применяются в проекте. Вопросы: Какие типы запросов планируется использовать в процессе УК? Каков полный цикл запросов на изменения? Будет ли храниться в системе УК справочная информация, или необходимо подключаться к имеющейся справочной информации? В какой информации, возможно, будут нуждаться члены ССВ? Каковы основные ожидания от автоматизации управления изменениями? При иерархической проектной структуре как будут приниматься решения по запросу? Необходимо ли управлять всеми запросами на изменения? Какой уровень детальности управления будет выбран (сколько шагов/этапов)? Обеспечивается ли отслеживание изменений в исходных текстах (есть ли связь между изменениями на верхнем уровнем и описанием изменений на уровне файлов)? Как исходный текст ассоциируется с запросом? Будет ли применена система оповещений?
3.2.1 Отработка и утверждение запросов на изменение	Change RequestProcessing and Approval	Рассматриваются процессы, которые обеспечивают внесение, рассмотрение и упорядочение проблем и изменений	Определяются типы запросов. Как правило, это дефект, запрос на расширение, задача и заявка. Состав типов может существенно меняться, главное – не сводить все управление изменениями к одному типу запросов (очень часто, кроме как дефектами компании, ничем не управляют)
3.2.2 Группа управления изменениями	Change Control Board(CCB)	Описывается, кто входит в состав группы управления изменениями, и процедуры, которым она следует, для отработки и утверждения запросов на изменение. В некоторых случаях указывается регламент сбора группы	Решение о принятии запроса от пользователя, решение о реализации новой технической идеи практически никогда не принимаются одним человеком. В любой компании это группа людей. В терминах стандартов данная группа называется ССВ. В данном разделе необходимо описать состав участников (как правило, это аналитик или постановщик, лидер группы разработчиков, лидер группы тестировщиков и представитель отдела маркетинга) и периодичность заседаний. Например, группа ССВ может собираться каждую неделю (по регламенту) либо по возникшей потребности (не рекомендуется). Вопросы: Каковы пределы полномочий группы? Одна группа на все проекты или несколько групп, каждая на свой проект? Если несколько, то каким образом они сотрудничают друг с другом? Есть ли иерархия ССВ? Кто отвечает за коммуникации между ССВ? Будет ли поддерживать система УК специальные запросы для организации встреч и выпуска протоколов по результатам? Есть ли потребность в выработке регламента для ограничения действий группы (жесткий регламент встреч с высокой степенью формализма)? Как различаются уровни привилегий в группе? Меняет ли введение группы ССВ установленный порядок принятия решений в организации? Введены ли в состав ССВ все ключевые участники, включая менеджера УК, менеджера проекта, лидера тестировщиков, лидера разработчиков и архитекторов? Каковы процедуры устранения разногласий (выпуск протокола разногласий или нечто иное)? Автоматизирована ли данная процедура?
3.3 Учет состояния конфигурации	Configuration Status Accounting
3.3.1 Хранение материалов проекта и выпуск релизов	Project Media Storage and Release Process	Описываются правила хранения и регламенты резервирования, действия на случай непредвиденных обстоятельств. Описание процесса выпуска релизов включает их содержание, для кого они предназначены и имеются ли какие-либо известные проблемы и инструкции по инсталляции (можно вынести в отдельное приложение)
3.3.2 Отчеты и проверки	Reports and Aidits	Рассматривается содержание, формат и цель запрашиваемых отчетов и проверок состояния конфигурации. Отчеты используются для получения данных о качестве программного продукта в любой заданный момент времени жизненного цикла программного продукта или проекта. Отчетность по дефектам, основанная на запросах на изменения, может обеспечить некоторые удобные индикаторы качества и, следовательно, предостеречь предупредить? Потому что предостеречь от чего-либо менеджеров и разработчиков об определенных критических областях процесса разработки	Отчетам следует уделить особое внимание. Только по отчетам можно проследить ход выполнения работ. Здесь необходимо определить отчеты по ролям участников проекта и описать их формат. Также рекомендуется сформировать регламент сбора отчета, то есть, с какой периодичностью собираются метрики (в реальном времени, раз в день… и т. д.). Желательно выделить различные типы отчетов и периодичность сбора их метрик. Вопросы: Есть ли необходимость в более чем одной ревизии для каждой базовой версии? Вовлечены ли субподрядчики в ревизию? Отчеты Вопросы: Какие метрики собираются в ходе проекта? Какие типы отчетов необходимо иметь? Каковы способы представления отчетной информации? Есть ли внешние отчетные документы для клиентов? Дифференцируются ли отчеты в зависимости от типа выполняемой участником роли в проекте? Доступны ли отчеты? Какие будут предусмотрены формальные шаги для получения отчетов? Какие типы нотификационных сообщений будут применяться? Отслеживаются ли тенденции в проекте? По каким отчетам? Как ведется учет (статически, динамически)? Какие средства используются для получения отчетов (допускается использование любого числа систем для получения достоверной и понятной информации о ходе проекта)?
3.3.3 Документирование		Раздел определяет способы и типы документов
3.3.3.1 Описание версии	\eision Description	Данный документ описывает диски, CD или другие носители, используемые для поставки ПО. Также данный раздел также определяет состав документов, поставляемых с версией ПО и доступных для конечных пользователей	Примерный состав документов: архив релизов с описанием (Release Media); описание релиза (Release Notes); описание функций; перечень решенных проблем в релизе; перечень новых возможностей; инструкция по установке ПО; инвентаризация, опись. Данный пункт может содержать основные правила формирования документов, отражать способ выпуска документов (ручной, автоматический). Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК. Перечень приведенных документов относится к выпуску ПС для каждой версии, релиза, патча. В зависимости от выбранной модели выпуска состав документов, а также их детальность могут различаться
3.3.3.2 Документирование процесса		Общие документы требуются в случаях, когда продукт разрабатывается для крупных организаций, а также в тех случаях, когда продукт представляет собой программно-аппаратный комплекс	Типовые документы для данного раздела: описание системы, в которой используется ПС; описание административного управления программными средствами системы; руководство системного администратора; руководство пользователя; паспорт на ПС (общие сведения о ПС, основные характеристики, комплектность, акты о приемке и снятии с эксплуатации… и т. д.). Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК
		Детально рассматриваются этапы работ для заказчика и внутренние, относящиеся к работам по УК для программного продукта или проекта. Эта секция обычно включает детальное описание того, когда может быть модифицирован сам план конфигурационного управления	В зависимости от выбранной модели может измениться содержание этапов. Рекомендуется описать, что выполняется в УК в зависимости от этапа проекта
5. Обучение и ресурсы	Training and Resources	Рассматриваются инструментальные средства, персонал и обучение, требуемые для реализации описанных в плане задач
6. Субподрядчики и контроль программного обеспечения со стороны поставщиков	Subcontractor and Vendor Software Control	Описывается, как будет интегрировано программное обеспечение, разработанное вне среды УК проекта	К работе над проектом могут привлекаться субподрядчики. Данный раздел описывает, каким образом будет происходить работа с субподрядчиком. Вопросы: Разработка ведется только в одно организации или в обеих? Каковы процедуры корректировки дефектов в разрабатываемом продукте? Автоматизированы ли они (полностью или частично)? Какие изменения допустимо вносить заказчику в исходные тексты после получения продукта? Ставится ли в известность об этом субподрядчик и в какой мере? Когда и как выполняются ревизии? Какой набор инструментальных средств используется заказчиком и субподрядчиком? Необходимы ли дополнительные модули синхронизации (для тех случаев, когда заказчик и подрядчик используют разные системы УК от разных производителей)? Как контролируется субподрядная организация? Кто отвечает за работу с субподрядчиком? Работает ли субподрядчик по своим процессам или заказчик обязывает его работать по собственным? Как решаются конфликты? Разрешено ли субподрядчику осуществлять полную сборку продукта у себя, или заказчик выделяет стенд для сборки на своей территории? Допускается ли субподрядчик к справочной информации заказчика (доступ к реальным базам данных, справочникам)?
Приложения		Состав приложений не определяется стандартами. Обычно включает в себя такие документы, как: регламенты; инструкции по использованию средств УК (как пользовательские, так и административные); различные методические пособия; планы обучения; инструкции по установке и администрированию средств УКит.д.	Руководствуйтесь целесообразностью внесения тех или иных изменений. Оцените, все ли попало в основные разделы плана. Если основные разделы слишком разрослись, то, возможно, нужно вынести из них часть информации в приложение

КТ в управлении проектами: Тема 4. Планирование коммуникаций проекта

Тема 4.Планирование коммуникаций проекта

План лекции

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

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

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

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

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

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

1 Планирование коммуникаций – определение потребностей участников проекта в коммуникации и информации.

2 Распространение информации – своевременное предоставление необходимой информации участникам проекта.

3 Отчетность по исполнению – сбор и распространение информации о выполнении работ. Эта информация включает в себя отчеты о текущем состоянии, оценку прогресса и прогнозирование.

4 Управление участниками проекта – управление коммуникациями в целях удовлетворения требований участников проекта и решения возникающих проблем.

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

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

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

каким лицам какая информация нужна,

когда она им понадобится,

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

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

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

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

Рисунок 10-4. Планирование коммуникаций: входы, инструменты и методы, выходы

1 Планирование коммуникаций: входы процесса

1 Факторы внешней среды предприятия

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

2 Активы организационного процесса

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

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

3 Описание содержания проекта

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

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

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

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

2 Планирование коммуникаций: инструменты и методы

1 Анализ требований к коммуникациям

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

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

Общее количество каналов коммуникации равно n(n-1)/2, где n = количество участников проекта. Таким образом, получается, что в проекте, в котором 10 участников, количество потенциальных каналов коммуникации будет равно 45. Следовательно, ключевым элементом в планировании коммуникаций проекта является определение того, кто с кем будет взаимодействовать и кто какую информацию будет получать , и наложение соответствующих ограничений .

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

Организационные диаграммы

Соотношение между организацией проекта и распределением ответственности между участниками проекта

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

Количество людей, задействованных в проекте, с учетом места их размещения

Внутренние информационные потребности (например, обмен информацией внутри организаций)

Внешние информационные потребности (например, коммуникации со СМИ или подрядными организациями)

Информация об участниках проекта.

2 Средства коммуникации

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

Факторы, влияющие на выбор средств коммуникации , включают в себя:

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

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

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

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

Окружение проекта . Команда проекта проводит встречи и обменивается информацией в живом общении или виртуально ?

3 Планирование коммуникаций: выходы

1 План управления коммуникациями проекта (план управления взаимодействием)

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

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

Требования к коммуникациям со стороны участников проекта

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

Имя сотрудника, ответственного за передачу информации

Имя сотрудника или группы – получателей данной информации

Методы или технологии, используемые для передачи информации (например, служебная записка, электронная почта и/или пресс-релизы)

Частота коммуникации (например, еженедельно)

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

Метод обновления и уточнения плана управления коммуникациями по мере продвижения и развития проекта

Глоссарий общепринятой терминологии.

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

Примеры разделов плана управления коммуникациями:

Предмет коммуникации . Информация, предназначенная для распространения среди участников проекта.

Цель . С какой целью распространяется данная информация.

Частота . Как часто предполагается распространять данную информацию.

Даты начала/завершения . Временные рамки распространения данной информации.

Формат/средство связи . Представление информации и способ передачи.

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

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

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

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

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

При помощи этих нехитрых, но необходимых действий можно значительно сократить подготовительный этап проекта. Нередко подготовка занимает столько же времени, сколько длится весь последующий проект. Это происходит из-за несогласованности интересов сторон, недооценки значения проекта или нечеткого понимания планируемых результатов. Например, план важного для организации проекта внедрения системы электронного документооборота занимал около 60 страниц. В связи с этим у руководства ушло полтора месяца на его согласование, хотя предполагалось, что работы по проекту начнутся через неделю. Из-за возникшего отставания пришлось пересматривать график финансирования проекта, что повлекло за собой задержку еще в две недели. В результате этих проволочек вместо ожидаемых результатов в текущем году система была внедрена только на следующий год. Между тем 30-минутная общая презентация проекта для руководства могла бы ликвидировать риск серьезного отставания уже на начальном этапе работ, и проект завершился бы успешно в запланированные сроки. При помощи продуманной внешней PR-кампании проекта также можно добиться неплохих результатов еще до начала каких-либо работ. Во-первых, популяризуя информацию о проекте в СМИ, компания поддерживает имидж динамично развивающейся структуры. Во-вторых, предварительное информирование готовит клиентов и сотрудников к предстоящим изменениям. Это одновременно и форма заботы о пользователях, и способ их удержания. Например, клиенты некой страховой компании недовольны качеством обслуживания и не намерены продлевать отношения с ней. При появлении информации о том, что компания в скором времени собирается внедрить систему управления взаимоотношениями с клиентами, часть сомневающихся, возможно, удастся удержать. Так, при помощи одного лишь продуманного плана коммуникаций компания может получать реальную выгоду уже на этапе инициации и ведения проекта.

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

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

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

Для начала следует определить потребности участников проекта в коммуникации и информации и подходящие средства удовлетворения этих потребностей. «Руководство к своду знаний по управлению проектами» (PMBOK) международного института управления проектами PMI рекомендует менеджеру проекта рассчитать количество потенциальных каналов коммуникации для того, чтобы оценить степень сложности коммуникаций проекта. Общее количество каналов коммуникации равно n(n-1)/2, где n - количество участников проекта. Таким образом, например, для десяти участников, число потенциальных каналов коммуникации будет равно 45. Следовательно, ключевым элементом в планировании коммуникаций проекта является определение того, кто с кем будет взаимодействовать, кто какую информацию будет получать, и наложение соответствующих ограничений.

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

На одном языке

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

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

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

Результат и сроки проекта

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

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

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

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

Актуализация

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

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

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

В обновленной версии PMBOK 2004 года к ним добавился процесс управления участниками проекта (Manage Stakeholders). Сутью этого процесса является удовлетворение требований участников проекта и решение возникающих проблем. Как показывает опыт, именно на взаимодействие с различными заинтересованными сторонами руководитель проекта тратит большую часть своих сил и времени.

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

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

Просмотры: 5 957

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

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

2. Распространение информации - дает возможность нужной информации своевременно доходить до участников проекта.

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

4. Административное закрытие - генерация, сбор и распространение информации для официального завершения фазы или проекта.

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

Например :

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

Выбор среды - когда общаться письменно, а когда устно,

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

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

Методы презентации - структура языка, дизайн наглядных пособий и т.д.

Соответствие методам управления - подготовка повестки дня, устранение конфликтов и т.д.

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

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

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

Входные данные для планирования коммуникаций

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

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

Отношения взаимной ответственности участников проекта и организаций проекта.

Дисциплины, отделения и специальности, включенные в проект.

Логистику - сколько индивидуумов будет вовлечено в проект и каково их местонахождение.

Внешние информационные требования (например, коммуникации со средствами массовой информации).

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

Выбор коммуникационных технологий включает:

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

Доступность технологии - являются ли действующие системы подходящими или проекту требуются основательные перемены?

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

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

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

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

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

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

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

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

План управления коммуникациями - документ, который предоставляет:

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

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

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

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

Методы для доступа к информации между коммуникациями, внесенными в расписание.

Метод для обновления и совершенствования плана управления коммуникациями по мере достижения прогресса и совершенствования проекта.

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