ТОП-10 ошибочных парадигм в управлении проектами

Статья Мартина Пауэлла, одного из авторитетнейших специалистов по Теории ограничений

Причины? Нет, культура и поведение — следствия или результаты. Они не могут быть исходными причинами. Первопричины — системные правила и связанные с ними показатели, официальные и неофициальные. Если вы измените правила (см. ниже) и показатели, поведение быстро изменится. Будет вам и культура, а также и результаты.

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

Эта парадигма управляет правилом / политикой, созданной высшим руководством:

a. Запускайте проекты, как только они «получены и назначены»

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

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

b. Если вы пропустите сроки запуска одной или нескольких задач, вы должны приступить к ним немедленно, как только сможете

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

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

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

Должно быть установлено правило: «запущенная задача должна быть выполнена, если это технически возможно, без переключения на другие задачи». Это ускорит поток всех проектов.

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

Необходим механизм, устанавливающий единую устойчивую систему приоритетов, такую как цветовые приоритеты буферов в управлении проектами по методу Критической цепи.

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

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

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

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

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

Однако, если мы используем CCPM, мы изменяем способ, которым оцениваем ресурсы. Мы удаляем локальные страховые запасы с уровня задачи и аккумулируем их на уровне всего проекта. Этот запас тогда принадлежит менеджеру проекта. Размер общего запаса (буфера) потребуется намного меньше, чем было заложено в сумме всеми участниками. Фактически в CCPM буфер проекта должен быть установлен в размере 50% от суммы локальных запасов.

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

Почему часто случается такая ситуация: когда мы на 11-й день спрашиваем сотрудника, работающего над задачей с исходной предполагаемой продолжительностью 10 дней, сколько процентов завершено, он отвечает нам: «90% и потребуется еще 5 дней, чтобы закончить»? Потому что нельзя приравнивать содержание задачи к ее продолжительности.

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

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

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

Когда среда управления проектами функционирует плохо и демонстрирует плохие результаты, очевидно, что высшее руководство должно поддержать изменения. То, что обычно происходит — выбирается некий новый подход, и затем его реализация делегируется среднему звену руководства. Это может произойти даже с CCPM. У включенных в реализацию есть поддержка высшего руководства, но часто лишь пассивная и номинальная.

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

Если вы прочли этот ТОП-10 ошибочных парадигм и подумали, что все это верно, тогда вам стоит подумать снова. Если вы поняли, что эти предположения и парадигмы, возможно, ошибочны, тогда вы должны исследовать глубже, как они влияют на вашу организацию. Проверьте их на своих сотрудниках, но не всех сразу, а по одному.

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

Мартин Пауэлл

P.S.: Далее в этом цикле: ТОП-8 ошибочных парадигм в управлении производством и ТОП-8 ошибочных парадигм в управлении цепью поставок.

Источник