27. Braksick, L. Unlock Behavior, Unleash Profits, New York: McGraw-Hill, 2000.

28. Kotter, J. “Leading Change: Why Transformation Efforts Fail.” In Harvard Business Review on Change, Boston, MA: Harvard Business Review Publishing, 1998, рр. 1-20 (в русском переводе: Коттер Д. П. Впереди перемен. — М.: Олимп-Бизнес, 2007).

3.1. Решаем, что менять

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

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

И теперь, став свидетелем использования ССРМ во множестве организаций, могу объяснить, как это работает.

3.1.1. ОПРЕДЕЛЯЕМ СИСТЕМУ УПРАВЛЕНИЯ ПРОЕКТОМ

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

3.1.2. ПРОВАЛ ПРОЕКТА КАК НЕЖЕЛАТЕЛЬНОЕ ЯВЛЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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