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

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

Глава 1 описывает избранные примеры, свидетельствующие, что метод критической цепи ведет к желаемым результатам. («Избранные» означает, что дан вовсе не полный перечень. Это не значит, что мы выбрали лишь примеры положительных результатов!) К настоящему моменту на тысячах проектов разных типов в разных отраслях и различных культурах по всему миру был успешно использован метод критической цепи. Однако бывали случаи, когда при внедрении не удалось добиться преобразований, необходимых для эффективной работы ССРМ, и система управления проектами осталась без изменений. Глава 9 рассказывает об этом подробней.

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

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

2) проекты, завершающиеся в рамках или с экономией бюджета;

3) проекты, показавшие все запланированные результаты;

4) проекты, в которых изменения минимальны;

5) проекты, не испытывающие нехватки ресурсов и не вступающие в бой за них;

6) проекты, длительность которых становится все меньше и меньше;

7) проекты, завершающиеся все без исключений;

8) проекты, обеспечивающие решение в духе «выигрывают все», одинаково выгодные для всех участников.

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

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

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

• ограничение отдельного проекта — это критическая цепь, то есть критический путь после выравнивания ресурсов;

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

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

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

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

• растущее число практических примеров свидетельствует о реализуемости метода ССРМ на всех типах проектов.

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

1. Marris, Peter, The Politics of Uncertainty, London: Routledge, 1996.

2. Goldratt, Eliyahu M., The Goal, Great Barrington, MA: North River Press, 1984 (в русском переводе: Голдрат Э. М., Кокс Д. Цель. Процесс непрерывного совершенствования. — М.: Попурри, 2007).

3. Popper, Karl R., Objective Knowledge, An Evolutionary Approach, Oxford: Clarendon Press, 1979, р. 144 (в русском переводе: Поппер К.Р. Объективное знание. Эволюционный подход. — М.: Эдиториал УРСС, 2002).

4. Goldratt, Eliyahu M., Theory of Constraints, Great Barrington, MA: North River Press, 1994.

Глава 4. Комплексное решение для отдельного проекта

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

Табл. 4.1 представляет собой свод требований к эффективной системе управления проектом, разработанный по методу Джозефа Джурана [1]. В ней дается иерархия желаемых свойств, и в первую очередь самые необходимые условия реализации проекта. К ним относятся три граничных технических условия (содержание, бюджет и график) и необходимость удовлетворять ожиданиям участников проекта. Участники — это как минимум заказчик проекта и проектная команда, а в некоторых ситуациях и многие другие (например, субподрядчики, акционеры, законодательные органы, соседи, правительство и иные сообщества).

Это те требования, на которые я ориентировался, формулируя ССРМ. Многие сторонники ТОС и метода критической цепи не учитывают все их в полной мере по одной из следующих причин. Кто-то просто не знает всего набора требований, которым должна удовлетворять система управления проектом, и сосредотачивается лишь на том, о чем упоминает доктор Элияху Голдратт. Другие, возможно, не считают эти требования обязательными. Я думаю, некоторым организациям не удалось успешно реализовать возможности ССРМ потому, что они не выполнили все условия эффективного ведения проектов. Система управления, удовлетворяющая всем требованиям из табл. 4.1, будет соответствовать и необходимым условиям успешности проектов, хотя к каждому конкретному проекту могут предъявляться и какие-то специфические требования.

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

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

Таблица не является и не может быть полной. Это только идея, предмет для обсуждения и совершенствования. Например, я не очень доволен тем, что требования полностью включают в себя только глубинные знания, особенно знание психологии. Полагаю, можно пойти и дальше, включая в список принципы шести сигм и бережливого производства. Я считаю, что список «вполне приемлемый» для того, чтобы выстроилась картина ССРМ и мы занялись совершенствованием проектной системы, бросив вызов трудностям, описанным в главе 1.

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

1) критическая цепь определяется как самая длинная цепочка операций проекта с учетом ограничений как по ресурсам, так и по логике последовательности операций;

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

1) критическая цепь определяется как самая длинная цепочка операций проекта с учетом ограничений как по ресурсам, так и по логике последовательности операций;

2) конфликты по ресурсам не рассматриваются до момента определения критической цепи;

3) в плане используются среднеоценочные характеристики операций (имеющие вероятность 50/50), а запас на компенсацию влияния общих причин вариабельности сосредоточен в конце цепочек работ (на рис. 4.1 буфер изображен в виде амортизатора);

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

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

6) в качестве средств оценки и контроля за реализацией проекта используются проектный буфер и буфера на слияние путей.

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

Для эффективного применения ССРМ в отдельном проекте крайне необходимо добиться следующих изменений привычного стиля работы:

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

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

3) исполнители должны сосредотачивать усилия на одной операции и передавать результаты на следующий этап, как только работа завершена;

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

Вот и все!

Следующие разделы описывают характеристики метода критической цепи в свете пяти направляющих шагов ТОС. Не знаю, таким ли путем Голдратт на самом деле пришел к пониманию этих особенностей. В соответствии с приведенными у Поппера [2] описаниями теории познания и научного метода вовсе не важно, как именно Голдратт нашел эти характеристики (что Поппер назвал бы «дерзкой гипотезой»). Важно то, что мы должны подвергнуть данную гипотезу критическому обсуждению, проверить экспериментально и посмотреть, будут ли результаты свидетельствовать в пользу предпочтения критической цепи критическому пути.

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

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

В РМВОК идет речь и о вероятностных подходах к составлению расписания проекта, таких как методы PERT и Монте-Карло. Однако определения даются очень скудные, так что пользоваться этими методами, исходя только из описаний в РМВОК, невозможно. Как показали мои исследования, реально на практике они применяются редко.

Чтобы выполнить любую операцию проекта, необходимы две составляющие: результаты предыдущей операции и исполнитель. (Для самой первой операции на проекте предыдущим этапом может быть просто разрешение на начало работ.) В определении критического пути не затрагиваются возможные ограничения по ресурсам. Только в неявном виде потребность в ресурсах иногда учитывается и при нахождении критического пути, поскольку при оценке длительности операции предполагается определенный уровень доступности ресурсов. При определении критического пути не учитывается в полной мере ограниченность ресурсов на выполнение операций и не допускается нарушение логики хода работ, то есть «прыжки» с одной логической цепочки операций на другую запрещены.

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

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

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

Читая курс для членов PMI, я провел небольшое исследование. Среди слушателей много сертифицированных профессионалов в управлении проектами РМР. Практически все они согласны с тем, что получить в свой проект ресурс именно в тот момент, когда он необходим, очень трудно и часто из-за этого случаются задержки. Однако мало кто (менее 5%) указывает, что регулярно занимается выравниванием ресурсов (то есть учитывает ограниченность ресурсов на проекте). Когда я интересуюсь причинами, большинство объясняет, что после выравнивания ресурсов срок реализации превышает ожидания руководства.

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

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

Что еще более важно, первоначальный критический путь не является ограничением для выполнения проекта. Поскольку ресурсное ограничение в проекте часто самое значительное, метод планирования проекта по ТОС всегда его учитывает. Таким образом, критическая цепь зависит от ресурсов, а эта зависимость и определяет самый длинный путь (ограничение) в проекте. Этот метод снимает все ресурсные ограничения в ходе нахождения критической цепи. В критической цепи проекта между операциями могут иметься разрывы. На рис. 4.4 приведена критическая цепь для рассматриваемого нами примера.