Вовремя и в рамках бюджета

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

5.5. Назначение ответственных

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

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

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

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

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

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

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

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