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

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

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

5.6. Последовательность контрольных событий

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

Эффективный способ выстроить логичную картину — определить основные фазы проекта, или ключевые события. На рис. 5.2 дан пример схемы контрольных точек. У каждого ключевого события должен быть свой определенный результат. В диаграмме контрольных событий даты не указываются. Ведь даты вычисляются в результате составления графика, а не задаются как исходные условия для его создания (исключение — проекты с жестко установленной датой окончания, такие как подготовка коммерческого предложения, проведение мероприятия, Олимпийские игры-2004 в Афинах).

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

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

5.7. Пакеты работ

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

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

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

5.7.1. ИСХОДНЫЕ УСТАНОВКИ

План любого проекта сделан на основании каких-то установок и допущений. Какой бы детальной ни была спецификация, все равно существуют установки низшего уровня, на которых строилось описание. Всегда есть факторы, способные повлиять на ход проекта и по которым вы сделали некоторые, зачастую оставшиеся невысказанными предположения. В плане проекта должны быть указаны ключевые допущения, необходимые для выработки разумных оценок параметров проектных операций: необходимые ресурсы и длительность. Так, планируя строительные работы, можно сделать допущение о погодных условиях (например, общая длительность сорванных работ под открытым небом из-за плохой погоды составит не более шести дней). Предположения можно делать и о факторах, находящихся вне зоны прямого контроля участников проекта (например, получение разрешения от контролирующих органов не превысит 30 дней). Эти установки должны быть определены при составлении пакетов работ. Но здесь необходимо избегать двух опасных тенденций. Первая — стремление предусмотреть и описать абсолютно все, вместо того чтобы заниматься планированием. Отсюда появляются длиннейшие списки допущений, общий смысл которых сводится к следующему: мы ни за что не отвечаем. Ограничьтесь лишь тем, что действительно необходимо для создания эффективного плана. Второе широко распространенное явление — использование высказываний с частицей «не». Например, указывают, что не будет делаться в проекте, что не входит в рамки проекта, вместо того, чтобы описать результаты. Лучше напишите утвердительное предложение без всяких «не», типа «Результатами проекта являются только указанные ранее».