Вовремя и в рамках бюджета. Управление проектами по методу критической цепи

Лич Лоуренс

К сожалению, упрощенный метод построения ДП, описанный Голдраттом в романе «Дело не в везенье!» [3], не подходит для разработки ИСР проектов. Дело в том, что ДП позволяет только обеспечить выполнение условий преодоления препятствий, выявленных командой. Этот метод не отслеживает достижение всех промежуточных результатов, необходимых для получения конечного продукта проекта. Детмер [4] модифицировал метод так, чтобы он охватывал и необходимые, и достаточные условия успешного завершения проекта.

Второй подход, предлагаемый в ТОС, основан на обратном планировании.

Рассматриваем последовательно все планируемые результаты проекта и к каждому задаем вопрос: «А какие исходные нам нужны, чтобы получить на выходе этот результат?» Так продолжается до тех пор, пока не достигается уровень операций, для которых уже не нужны никакие особые входные данные.

У обратного планирования есть несколько недостатков:

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

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

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

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

5.4.2. ТРАДИЦИОННАЯ ИСР

Есть ряд полезных стандартов, которые помогут вам с разработкой ИСР. Один из них сравнительно недавно выпущен PMI [5], а наиболее полный предложен министерством обороны США [6]. Харольд Керцер приводит следующие критерии хорошей ИСР [7]: «Менеджер проекта должен разбить работу на мелкие элементы, которые:

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

• независимы или имеют минимальную зависимость от других событий;

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

• измеримы, то есть можно оценить степень их выполнения.

Правильная ИСР обеспечивает следующее:

• лучшее понимание объема работ;

• планирование всех работ;

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

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

• соотнесение отдельных рабочих заданий с общими задачами проекта;

• назначение ответственных за весь объем работ;

• оценку сроков и затрат;

• планирование и распределение ресурсов компании;

• интеграцию содержания, графика и бюджета;

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

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

• управление изменениями.

В ИСР обычно выделяются определенные уровни, например:

Уровень 1: программа в целом.

Уровень 2: суммарные статьи расходов.

Уровень п-1: пакет работ.

Уровень п: операция».

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

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

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

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

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

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

5.4.3. ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА

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