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

• Название: Вовремя и в рамках бюджета
• Автор: Лоуренс Лич
• Жанр: Управление, подбор персонала
• Год: 2010
• ISBN: 978-5-9614-0995-6, 978-1-5805-3903-3

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

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

Книга будет интересна всем руководителям проектов, а также топ-менеджерам, контролирующим выполнение сложных проектов.

---

Чтобы улучшить систему управления проектом, согласно теории познания, необходимо определиться с проблемами, которые заложены в существующей системе. Сравнение прогнозов, сделанных с помощью существующей проектной системы (теории), с реальностью помогает установить такие проблемы. Наблюдая возникающие при работе системы нежелательные явления (НЯ), мы естественным образом сможем определить существующие в системе проблемы и понять, каких желаемых результатов (ЖР) нам необходимо добиться, чтобы говорить об улучшении проектной системы как таковой. В главе 1 были определены следующие НЯ:

1. Проекты часто идут с нарушением графика.

2. Проекты часто идут с превышением бюджета.

3. Чтобы уложиться в срок и в бюджет, часто приходится жертвовать содержанием проекта.

4. В проектах происходит слишком много изменений.

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

6. Длительность проектов все растет.

7. Многие проекты останавливаются, не дойдя до цели.

8. Проектные работы оказывают серьезное давление на большинство участников.

Нежелательные явления — это то, что нам не нравится в существующей системе. Хороший способ проверить, что перед нами действительно НЯ, — сформулировать предложение типа «Меня действительно беспокоит то, что.». Ваш список НЯ может включать в себя какие-то иные пункты, чем вышеперечисленные. Если нужно, дополняйте или сокращайте приведенный перечень.

ТОС помогает нам понять, что все эти явления — непосредственный продукт работы проектной системы, в которой мы в данный момент находимся. Хотя это и не преднамеренные результаты, их стабильное присутствие свидетельствует о том, что они — прямое следствие действия системы. Значит, где-то в системе есть нечто, вызывающее появление этих НЯ. Ввиду того, что нежелательные явления наблюдаются в любых типах проектов во всех сферах бизнеса и в разных видах культур, мы можем сделать вывод, что тип проекта, бизнеса и культуры не является первоочередным фактором или воздействием, вызывающим появление таких результатов. ТОС подводит нас к мысли, что НЯ — это следствие некоего глубинного конфликта или дилеммы, универсальных для любого окружения. Чтобы определить, что менять, необходимо выявить эту дилемму — ограничение существующей системы.

3.2. Определяем ограничение

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

В большинстве реализуемых сегодня проектов используется метод критического пути СРМ, разработанный в начале 1950-х и являющийся «гвоздем» большинства учебных программ по управлению проектами. (Я знаю, о чем говорю. Сам веду некоторые из них в Университете Феникса). Он же описан и во всех работах по управлению проектами. На рис. 3.2 показан типичный график, построенный методом критического пути. Самый длинный путь в диаграмме — критический путь.

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

Анализ проекта на рис. 3.2 позволяет прикинуть, сколько времени он на самом деле займет. Рассмотрим работу исполнителя 1 (операции 1, 3 и 5). Начало всех этих операций запланировано на одну и ту же дату, значит, каждая операция будет длится втрое дольше, поскольку все они должны выполняться одновременно. Таким образом, самая короткая операция 1 длительностью 5 дней завершится через 15 дней, а задания 3 и 5 будут выполнены на этот момент настолько, сколько можно сделать за 5 дней. Теперь исполнитель 1 должен будет распределять время между двумя оставшимися операциями, при этом из 2 дней работы по проекту на каждую будет уходить по 1 дню. Следовательно, оставшиеся 20 дней операции 3 выльются на деле в 40 дней и общая ее продолжительность составит 55 дней. Через 55 дней по заданию 5 еще останется сделать работы на 25 дней, и длительность ее в совокупности окажется 80 дней.

Расчет по исполнителю 2 более сложен ввиду взаимосвязанности операций. На 15-й день исполнитель 2 может начать работу по заданию 2 и посвящать ему 100% времени. Он не сможет приступить к операции 4, пока исполнитель 1 не завершит задание 3 (то есть не раньше дня 55). Таким образом, исполнитель 2 может полностью заниматься операцией 2 в течение 40 дней, однако последние 5 дней уже придется выполнять и задание 4, поэтому общая длительность операции 2 вырастет до 50 дней. Операция 4 теперь пересекается с задачами 2 и 6 и вырастает до 40 дней. На рис. 3.3 представлена схема ожидаемой фактической реализации проекта с датой окончания, сдвинувшейся более чем на месяц. Проект был обречен.

Существует метод решения данной проблемы — это выравнивание ресурсов. Большинство программных продуктов, основанных на методе СРМ, предлагают такую возможность. Рис. 3.4 — вариант графика с рисунка 3.1, к которому было применено выравнивание ресурсов. Обратите внимание: дата завершения плана-графика с выравненными ресурсами совпадает с датой, полученной на графике фактической реализации. Этот метод также устраняет первое нежелательное явление — частое нарушение графика. Еще бы, ведь для этого он и создан!

Рассматривая рис. 3.2 и 3.4, можно сделать интересное наблюдение. Компьютерная программа включила в критический путь только операции 5 и 6. Странно, что в критический путь не попали операции, идущие перед ними. Почему программа выбрала именно эти операции, для меня загадка. И я знаю, что после выравнивания ресурсов при помощи другой программы получится совсем иной критический путь, пусть даже выравнивание будет произведено одинаковым образом. Причина в том, что критический путь не определяется после выравнивания. До выравнивания в него не включен временной резерв («float», он же «slack»). Обратите внимание, что на рис. 3.2 у обоих некритических путей (операции 1 и 2 и операции 3 и 4) есть такой резерв, отмеченный чертой, продолжающейся справа от операции. После выравнивания ресурсов (рис. 3.4) резерв есть по всем операциям. Таким образом, ни одна из них не составляет критический путь.

На своих занятиях в PMI я устраиваю неофициальное исследование. Я спрашиваю, сколько студентов в планах своих проектов указывают загрузку по ресурсам (то есть обозначают, какие ресурсы назначены на выполнение каких операций, как на рис. 3.2). Обычно это от половины до двух третей слушателей. Затем я спрашиваю, кто из них проводит выравнивание ресурсов. Обычно таковых около 5%. Получается, что примерно 95% проектов уже с самого начала обречены на провал. Не забывайте, что я опрашивал элиту управления проектами, большинство из них — сертифицированные профессионалы РМР.

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

1. Тогда сдвигается дата окончания проекта (!).

2. Выравнивание влечет за собой действия, лишенные всякого смысла.

Первый ответ указывает на нежелание взглянуть в лицо реальности. О втором поговорим позднее.

Сейчас мы вслед за доктором Элияху Голдраттом введем небольшое изменение в определение: ограничением в отдельно взятом проекте является критическая цепь, которая выявляется как самый длинный путь в сетевом графике после выравнивания ресурсов. Рис. 3.5 показывает критическую цепь в простом проекте, взятом нами за пример. Обратите внимание: на стадии определения в ней нет временного резерва. Также отметьте, что она «прыгает» по логически связанным цепочкам задач в проекте (хотя технически логика всего плана остается неизменной).

В прошлом я никогда не ставил под сомнение, что приемлемым способом избежать борьбы за ресурсы является построение критического пути с последующим выравниванием ресурсов. Изучение литературы не выявило, на чем базируется данный подход. Подозреваю, что это, возможно, связано с эволюцией компьютерной техники. Вычислить критический путь можно вручную. Алгоритма для создания оптимального критического пути с выравненными ресурсами не существует. Таким образом, даже в плане проекта средней сложности произвести выравнивание ресурсов вручную очень сложно. Дорогостоящие и «медленные» компьютеры, существовавшие в период становления СРМ и PERT, не годились для больших расчетов, хотя идея использовать машину для расчета критического пути, построения сетевой диаграммы с дальнейшим выявлением потенциальных ограничений по ресурсам кажется вполне разумной. Может быть, даже по несложным проектам, которые планировались методом СРМ и PERT без привлечения компьютеров, ресурсы не всегда были ограничением. И вполне реально было вручную найти критический путь, а затем определить и закрыть потребности в ресурсах.