Лоуренс Лич - Вовремя и в рамках бюджета

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

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

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

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

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

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

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

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

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

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

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

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

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