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

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

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

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

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

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

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

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

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

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

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

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

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

Как утверждается в главе 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, к которому было применено выравнивание ресурсов. Обратите внимание: дата завершения плана-графика с выравненными ресурсами совпадает с датой, полученной на графике фактической реализации. Этот метод также устраняет первое нежелательное явление — частое нарушение графика. Еще бы, ведь для этого он и создан!