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

5.3.5 Использование методологии освоенного объема

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

Плановые затраты (ПЗ) - запланированные затраты по плановому объему работы и в соответствии с расписанием (в денежном выражении). Ранее в литературе это обозначалось как BCWS (Budgeted cost for work scheduled). В последнее время изменено на PV (Planned value).

Фактические затраты (ФЗ) - фактические затраты по выполненному объему работы; затраты, реально произведенные и зарегистрированные. Предыдущее обозначение ACWP (Actual cost of work performed) сейчас изменено на AC (Actual costs).

Освоенный объем (ОО) - денежная оценка фактически выполненного объема работы по плановым расценкам. Также ранее использованная аббревиатура BCWP (Budgeted cost for work performed) изменена на EV (Earned value).

Ожидаемая прогнозная величина затрат части (фазы, рабочего пакета) проекта или всего проекта к ее (его) завершению или опенка затрат по исполнению обозначается как ЕАС (Estimate at completion).

Плановая величина затрат части проекта (фазы, рабочего пакета) или всего проекта, а также плановые затраты на весь объем работы по проекту или его элементу обозначаются как ВАС (Budgeted cost at completion).

Оценка затрат на оставшийся объем работ по проекту - средства, необходимые для завершения проекта, или ETC (Estimate to complete), равная разнице между ВАС и ЕАС.

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

В русскоязычных переводах можно встретить аббревиатуры из русских букв, отражающих прямой перевод. Например, PV в локальной версии MS Project 2003 обозначаются как БСЗР (базовая стоимость запланированных работ), EV - как БСВР (базовая стоимость выполненных работ), АС - как ФСВР (фактическая стоимость выполненных работ), ЕАС - как ПОПЗ (предварительная оценка по завершении), ВАС - как БПЗ (базовые затраты), ETC - как ОПЗ (отклонение по завершении). Во избежание путаницы будем в дальнейшем использовать оригинальные англоязычные обозначения.

Приведем основные формулы, связывающие эти значения.

CV (Cost variance) - отклонение по затратам, равное разности между освоенным объемом и фактическими затратами, т. е. CV = EV - АС. Если CV > 0, текущие затраты проекта меньше запланированных; если CV< 0, затраты больше запланированных. Относительное отклонение по затратам в процентах определяется как CV/EV(%).

CPI (Cost performance index) - индекс освоения затрат, рассчитывается как отношение освоенного объема к фактическим затратам, CPI = EV/AC. Если CPI > 1, то затраты проекта меньше запланированных; если СРI< 1, затраты больше запланированных.

SV (Schedule variance) - отставание от графика, отклонение по освоению объема работ, равное разности между освоенным объемом и плановыми затратами, т. е. SV = EV - PV. Аналогично предыдущим комментариям: если SV > 0, проект опережает его планируемое развитие; если SV < 0, проект медленнее планируемого развития. Относительное отклонение по расписанию определяется как SV/PV(%).

SPI (Schedule performance index) - индекс выполнения расписания или объема, рассчитываемый как отношение освоенного объема к плановым затратам, SPI - EV/PV. Если SPI > 1, то освоение проекта больше запланированного; если SPI < 1, освоение идет меньшими темпами, чем запланировано.

Оценка затрат по исполнению, основанная на текущей продуктивности:

Оценка оставшейся стоимости проекта:

Оценка отклонения по выполнению, основанная на текущей продуктивности



Текущее выполнение проекта или его работ по объему, равное

Выполнение проекта или его работ по затратам, равное

Проанализируем простой пример, приведенный ранее. Как уже было видно, АС равно 600 p., PV - 500 p., EV - 400 p. CV равно - 200 р., что свидетельствует о затратах, превышающих запланированные. О том же свидетельствует и CPI, равный 0,66. SV составляет - 100 р., т. е. проект развивается медленнее планируемого развития. ВАС данного проекта равен 1000 р. ЕАС равен 1000 х 600 / 400 = 1500 р., т. е. присутствует серьезное прогнозируемое превышение бюджета по исполнению. ETC равна 1500 - 600 = 900 р., т. е. руководителю вместо запланированных 500 р. необходимо затребовать на 400 р. больше. При наличии превышения затрат и опоздания проекта прогнозируемые совокупные затраты в конце проекта составляют 150% от запланированных, что явно неудовлетворительно. Процент освоения по объему равен 400 р. / 1000 р. = 40%, а по затратам - 600 р. / 1000 р. = 60%.

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

Метод простого контроля, или 0/100 - незавершенная (но начатая) работа всегда имеет 0% выполнения, независимо от реальной картины выполнения, завершенная работа - 100%. Такое правило часто применяется при получении разных согласований. Только когда мы получили необходимое согласование, можно сказать, что освоение этой работы - 100%. Конечно, при таком способе появляется погрешность расчета, однако она тем меньше, чем короче данная работа. Поэтому такое правило рекомендуют не применять при оценке длительных работ.

Метод 50/50 - 50% объема осваивается в начале, как только работа началась, остальные 50% суммируются при завершении (например, работа по поставке 50% каких-либо комплектующих в начале проекта требует применения этого правила: 50% освоения присваивается работе в начале и 50% - по ее завершении).

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

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

5.4 Отчетность проекта

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

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

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

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

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

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

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

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

Введение. Описание проекта и его фазы для понимания его читателем.

Цели проекта.

Текущее состояние проекта.

* Затраты: сопоставление реальных затрат с планируемыми на момент составления отчета. Процент завершения по затратам.

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

Объем выполняемых работ: полученные технические результаты. Физические показатели выполняемых работ. Процент выполнения по освоению.

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

Состояние критических задач.

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

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

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

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

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

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

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

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

формируется и поддерживается общее понимание целей проекта;

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

происходит более реалистичное планирование потребностей всех групп и отдельных лиц в проекте;

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

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

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

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

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

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

На рис. 5.2 приведен вариант так называемой доски руководителя проекта (Dashboard). Это несложное программное обеспечение на базе таблиц Exel, использующее MS Project 2000 и распространявшееся бесплатно в Интернете, с помощью которого можно преобразовать количественные данные результатов проекта в удобную и наглядную графическую форму.

Общие проблемы отчетов.

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

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

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

высока стоимость подготовки отчетов;

плохой «интерфейс» между информационной системой проекта и информационной системой головной организации.

Рис. 5.2 Приборная доска руководителя проекта

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

5.5 Управление ошибками, проблемами и изменениями

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

5.5.1 Управление ошибками

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

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

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

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

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

Определить лицо, ответственное за ее устранение, и дату устранения.

Зафиксировать инициатора - лицо, обнаружившее ошибку.

Указать дату обнаружения ошибки.

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

5.5.2 Управление проблемами

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

При управлении проблемами необходимо следующее:

Провести анализ всех текущих проблем проекта.

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

Спрогнозировать будущее влияние на проект при отсутствии корректирующих действий.

Определить приоритетность проблем.

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

по графику (добавить ресурсы; работать сверхурочно; изменить базовый план?);

или по затратам (снизить требования; уменьшить количество; снизить качество?).

5.5.3 Управление изменениями

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

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

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

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

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

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

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

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

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

5.5.4 Осуществление корректирующих действий

В табл. 5.3 представлены меры, которые можно предпринять, если проект начинает отставать.

Таблица 5.3 Меры, предпринимаемые при отставании проекта

Действия	Затраты	График
Провести дополнительные переговоры. Обсудите с заказчиком возможность увеличения сметы проекта или отсрочки даты завершения проекта
Компенсировать за счет более поздних стадий. Если вы отстаете на ранних шагах проекта, пересмотрите бюджеты и графики для более поздних шагов. Возможно, вы сможете там сэкономить, чтобы уложиться в смету и/или график
Уменьшите масштаб проекта. Возможно, не очень важные элементы проекта могут быть исключены, тем самым уменьшая затраты и/или сберегая время, но не в ущерб качеству
Привлечь дополнительные ресурсы. Это может привести к дополнительным затратам, однако также способно компенсировать будущие потери от срыва сроков. Вам может потребоваться привлечение большего количества людей или оборудования в проект для того, чтобы выполнить работы критического пути. Увеличенные затраты должны быть оценены в сравнении с важностью окончательного срока завершения
Допустить замещение. Если какие-либо материалы недоступны или являются более дорогими, чем предусмотрено в бюджете, замещение их на другие материалы может решить вашу проблему
Найти альтернативные источники. Если поставщик не способен осуществить поставку в рамках бюджета или графика, ищите тех, кто это сможет сделать. (У вас также есть возможность использовать заменитель вместо того, чтобы искать другие источники поставок.)
Допустить частичные поставки. Иногда поставщик может выполнить частичный заказ для того, чтобы ваш проект не выбивался из графика, и завершить поставки позднее
Предложить дополнительные вознаграждения. Расширьте масштаб первоначального контракта и предложите премию или другой стимул для поставки вовремя
Требовать выполнить соглашения. Иногда требование соблюдать достигнутые соглашения приводит к неплохим результатам. Вы можете обратиться к своим руководителям для получения их поддержки

Глава 6. Завершение проекта

6.1 Варианты завершения проекта

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

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

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

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

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

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

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

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

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

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

6.2 Причины неудачных проектов

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

ошибки в подготовке проекта, его целей, масштаба, видения;

изменение целей проекта, не согласованное с заказчиком и не прошедшее экспертизы;

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

выбор неверного проектного решения или его высокая сложность;

недостаточная поддержка высшего руководства;

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

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

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

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

назначение неподходящего руководителя проекта;

недостаток ресурсов;

отсутствие необходимых навыков, знаний, опыта у менеджмента проекта;

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

нереальные сроки;

отсутствие стандартизированного подхода к управлению проектом;

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

недостаточная сплоченность команды;

неадекватные действия из-за недостатка времени;

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

оценки времени/затрат не были подготовлены теми, кто был ответственен за эту работу;

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

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

аудиторы проекта не произвели тщательных и детальных оценок;

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

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

6.3 Процедуры и действия при завершении проекта

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

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

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

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

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

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

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

Закрытие финансовых счетов проекта.

Документирование и оформление технологических достижений. (Полезна передача достигнутого опыта всей компании-исполнителю.)

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

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

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

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

Проведение обратной связи по результатам работы.

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

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

Формализованное закрытие офиса проекта.

Приказ или объявление об окончании проекта.

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

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

написать инструкцию по использованию результата проекта;

завершить окончательные чертежи; передать результат проекта заказчику;

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

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

освободить мощности;

суммировать основные проблемы, возникшие при реализации проекта, и их решения;

документировать технологические достижения;

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

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

завершить окончательный аудит;

написать окончательный отчет; написать отчеты по оценке работы всех участников проекта;

обсудить результаты проекта с высшим руководством и объявить об окончании проекта.

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

7.1 Понятие коммуникаций проекта

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

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

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

7.2 План коммуникаций

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

2. Определите, сведения какого содержания нужно передавать? Что это заинформация? Детализируйте ее структуру и наполнение. Продумайте структуру и наименование файлов, в которых она будет находиться. Это относитсяи к электронным документам, и к бумажным папкам. Наименование папок ифайлов может быть привязано к исполнителям проекта или к элементам СРР.Необходимо, чтобы структура или дерево файлов были понятны не толькоответственному за их ведение лицу, но и остальным членам команды. Опаснопредоставлять свободу присвоения наименований кому-нибудь из сотрудников, так как он может подстроить все полностью под себя. Тогда, в случае егоухода из проекта, в файлах уже никто не разберется.

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

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

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

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

Результаты этой подготовительной работы должны быть проверены на выполнение следующих условий:

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

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

система не должна быть дорогой, если этого не требует организация проекта;

система должна быть гибкой и способной к быстрой подстройке;

*система должна приниматься и использоваться всеми участниками;

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

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

сформулированные требования к коммуникациям;

описание документов;

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

перечень отправителей и получателей информации, метод передачи, технологию, частоту, требуемую реакцию;

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

комментарии к развитию плана.

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

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

Из практики

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

7.3 Совещания в проекте

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

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

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

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

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

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

Проводите совещания регулярно по составленному графику.

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

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

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

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

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

Предварительный план совещаний проекта приведен в приложении 5.

Из практики

Автору очень понравилась процедура проведения отчетных совещаний в большом проекте одной из компаний Санкт-Петербурга. Команда проекта состояла из 10 человек, совещания проводились регулярно по вторникам на каждой неделе (за редким исключением, когда ряд сотрудников находился в командировке). Совещания начинались в 10:00, их длительность составляла ровно два часа. За полгода осуществления проекта значимая задержка начала и увеличение длительности совещания не отмечались ни разу. Допустимое опоздание составляло 10 мин, учитывая удаленность офиса от транспортных магистралей. За день до проведения совещания (в понедельник до обеда) всем членам команды раздавалась его повестка, где были отмечены предмет и время каждого выступления, очередность, результаты обсуждений прошлой встречи. Совещание вел руководитель проекта. На каждое выступление

отводилось пять минут и столько же выделялось на вопросы. Фиксировались результаты выступления и поручения к следующему совещанию через неделю.

7.4 Информационный и Проектный Офис

В управлении проектами термин «офис» имеет два довольно разных значения.

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

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

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

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

Из практики

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

2. Другое значение офиса связывают с термином «проектный офис» (Project Management Office, или РМО). Это значение определяет подразделение, осуществляющее централизацию и координацию управления прикрепленных к нему проектов. Такой офис руководит управлением проектами. Среди его основных функций - поддержание и развитие методологии управления проектами, централизованный мониторинг проектов, управление отдельными проектами, координация ресурсов и т. п.

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

7.5 Документация проекта

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

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

* подготовленный и утвержденный перечень документов по управлению проектом и его предметной области;

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

определение уровней доступа к документации с указанием должностей, позиций, условий доступа;

организация движения и маршрутизация документов;

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

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

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

Общие документы:

Положение о Проектном комитете.

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

Фаза инициирования, концепции.

Документ об инициировании проекта или заявка (см. Приложение 2).

Приказ о запуске проекта и назначении руководителя проекта (куратора проекта, команды; соответствует обычным приказам компании).

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

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

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

Устав проекта (см. разд. 3.6).

Документы по предметной области проекта (бизнес-план, техническое задание, ТЭО, обоснование инвестиций, целевые показатели продукта, спецификации и т. п.).

Приказы о переходе проекта в другую фазу.

Фаза планирования.

Приказ о начале фазы планирования.

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

Другая документация проекта:

а) форма запроса на изменение (см. Приложение 4);

б) планы и формы отчетов и совещаний (см. Приложение 5);

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

* Уточненные документы по предметной области проекта (дополненияк бизнес-плану, техническому заданию и др.).

Фаза реализации.

Приказ об утверждении рабочего плана проекта и о начале фазы реализации.

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

Текущие рабочие планы.

Запросы на изменения.

Промежуточные отчеты.

Журнал учета ошибок.

Документы текущего аудита проекта.

Документ о приемке-сдаче продукта.

Фаза завершения.

Текущий рабочий план проекта.

Приказ о переходе к фазе завершения.

Приказ о закрытии проекта.

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

Документы окончательного аудита.

Другие отчетные документы.

Архив проекта.

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

7.6 Понятие поставок. Основные определения

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

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

планирование контрактов, сопровождающих эти поставки;

запрос информации у поставщиков - получение заявок, предложений;

выбор поставщиков;

администрирование контрактов - управление отношениями с поставщиком;

закрытие контрактов - исполнение и завершение контракта, включая спорные моменты.

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

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

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

Вставка 7.1 Взаимоотношения между заказчиком и поставщиком. Принципы Исикавы

Взаимное доверие.

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

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

Между Заказчиком и Поставщиком должен быть заключен контракт.

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

Заказчик и Поставщик разрабатывают совместно методы для разрешения спорных вопросов.

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

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