Управление проектами по Теории Ограничений

На что часто жалуются в проектной работе:

1. Изначально спланированные сроки проекта не выдерживаются. Сроки сдвигаются всегда и не по одному разу.
   По некоторым оценкам, практически вообще не существует проектов, выполненных в срок без изменения его стоимости или содержания.
2. При реализации проекта часто происходят изменения
   Например, нет в наличии необходимых исполнителей, даже если при планировании они были обещаны.
3. Необходимые материальные ресурсы не оказываются в наличии в запланированное время (компоненты от субподрядчика; какое-то разрешение, необходимое для дальнейшей работы и т.п.).
4. Борьба за приоритеты и ресурсы между разными проектами (особенно в мультипроектной среде).
5. Превышение бюджета. Иногда критичное.
6. Слишком много работы приходится делать повторно (изменились требования, выяснилось, что были некорректно заданы технические характеристики и т.д.).

Эти жалобы не зависят от сферы деятельности компании, они общие для любых проектов. Этот список конечно же можно еще долго дополнять.
Но причины этих проблем могут быть в каждом конкретном случае разные.
И крайне важно найти корневую проблему, вызывающую все остальные НЖЯ (нежелательные явления).

Техника поиска корневой причины:
Любое НЖЯ - это конфликт. Надо взять любое НЖЯ и спросить у человека, который его озвучил: "Что в этом доставляет вам неприятности, на какой конфликт вы жалуетесь?"

- И что из этого? Чем это плохо?
- Тем, что если мы видим, что не укладываемся в сроки, то надо корректировать проект. Например, урезать его содержание или привлечь дополнительные ресурсы…
- Ну и что, что из этого?
- А то, что руководство всегда недовольно урезанием содержания или привлечением доп. ресурсов! И получить добро на подобное изменение в проекте непросто.

Мы видим здесь классический конфликт:

У руководителя проекта есть задача уложиться в срок. Если он видит, что сроки фэйлятся, он должен предпринять действия, чтобы вернуться в запланированные рамки. Для этого нужно, например, урезать содержание или увеличить ресурсы.
С другой стороны, нельзя по договору изменять обязательства, поэтому нельзя урезать содержание или увеличить количество ресурсов.

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

Грозовая туча выглядит так:

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

Не до конца известны все технические детали требований,
грозовая туча выглядит так:

В итоге мы видим, что суть конфликтов везде одна и та же.

Одно из главных свойств любого проекта - это высокий уровень неопределенности (каждый проект по определению уникален, этим он и отличается от операционной деятельности, имеющей низкий уровень неопределенности).
Т.к. неопределенность высока, срабатывание закона Мерфи в проектах гарантировано (то есть часть рисков точно будет реализована).

С одной стороны мы должны компенсировать риски, реализовавшиеся из-за неопределенности, с другой - нам нельзя это делать.

Что происходит в реальности?
Конечно мы компенсируем. Где-то немого (или много) жертвуем содержанием, где-то ведем переговоры по сдвигу сроков или превышаем бюджет.

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

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

Но внимание! Если мы разгоним грозовую тучу именно таким образом (доказав, что верхний левый исходный посыл неверен) - это нам нисколько не поможет в выполнении проекта в срок, с заданным содержанием и без превышения бюджета.
Это так же не поможет в будущих проектах, т.к. именно РЫНОК диктует условия продажникам и коммерсантам по срокам и стоимости. И если они не пообещают срок полгода вместо года, то проект уйдет другому подрядчику. Если не сделать продукт за 9 месяцев вместо двух лет, то рынок просто будет потерян.
И если разогнать тучу в этом месте, то мы будем правы, но мертвы.

То есть нам надо найти такое решение, которое сможет превратить нереалистичные обязательства в реалистичные, насколько это возможно.

Остается рассмотреть только обоснованность другого исходного посыла, который мы все считаем априори верным:
"мы должны компенсировать ошибки в оценках и неверные предварительные суждения, возникающие из-за неопределенности".
Почему мы должны компенсировать?
Потому, что не учли этого при планировании.
Да, если рассмотреть какую-то конкретную проблему, которая возникла в проекте - мы ее действительно не учли при планировании, потому что не могли знать, что она произойдет. НО!
При оценках сроков/трудоемкости каждой конкретной задачи при планировании проекта ВСЕГДА закладывается подстраховка! Каждый человек, у которого есть хоть немного опыта, закладывает подстраховку на стадии планирования. Причем, подстраховка закладывается и в сроки, и в содержание, и в бюджет.

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

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

Это смелое заявление. Но подумайте вот над чем: какие проекты длятся вечно и никогда не будут завершены? Те, которые не имеют срока сдачи. У таких проектов, сколько бы не было заложено подстраховки, всегда находятся объективные причины, которые постоянно сдвигают сроки. Согласитесь, в этом есть что-то концептуально неправильно. Где-то здесь заложена system error.

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

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

Рассмотрим подробнее, почему.

Как происходит планирование проекта?
Руководитель проекта собирает с участников проекта оценки по их части работ и на основе этих оценок выстраивает план проекта.
Как делается эта оценка?
Человек, давая оценку, понимает, что если он не уложится в этот срок, то его за это по головке не погладят. И это естественно вносит вклад в оценку.
При этом оценка всегда строится на неких статистических предположениях, осознает это человек или нет. Это можно представить через классическую функцию распределения вероятности.

Верхняя точка - наиболее вероятный срок выполнения задачи. С 50% вероятностью задача будет выполнена раньше и с такой же - позже.

Но в реальности эта кривая не симметрична, а вытянута вправо (и чем выше уровень неопределенности, тем сильнее вытягивается кривая):

Время выполнения задачи, при котором вероятность ее выполнения в срок составляет 80%, примерно в два раза больше, чем время выполнения задачи с 50%-ной вероятностью уложиться в срок (это при небольшом уровне неопределенности). 90%-ная вероятность выполнения задачи в срок дает уже в три раза бОльшую оценку.

Представьте, что у вас есть статистика по многократному выполнению подобной задачи и вас просят дать оценку, за какое время вы эту задачу сделаете. При этом вы понимаете, что ваша работа оценивается и что если вы не уложитесь в этот срок, то недополучите премию. Ну, как минимум, испытаете психологический прессинг и неприятные эмоции.
Вы дадите оценку времени, которая обеспечивает 50% вероятности уложиться в срок и такую же вероятность взлететь на воздух? Да ни за что! Вы же не камикадзе )). Более-менее опытные люди дают оценку из расчета не менее 90% вероятности уложиться в срок. Это зависит от человека, от зловредности начальства, от системы KPI и т.д.

Кроме этого, кстати говоря, есть еще процесс раздувания оценок при их движения по пирамиде: формула 15+5=20 25.
Пример: я начальник, собираю оценку работ у команды. Одна работа оценивается в 15 дней, другая в 5. Суммарная оценка, которую я передам вышестоящему руководителю - 25 дней.
Почему? Да потому, что я тоже заложил свою подстраховку. Почему я это делаю? Да просто потому, что я понимаю, что мою первоначальную оценку, взятую в условиях неопределенности "с потолка", мне же вменят как священное обязательство! ВЕДЬ ТАК?!? Это реальность.

А теперь, исходя из этого механизма оценки работ, представьте, какой суммарный запас у вас заложен в проекте!!! Этот запас огромен. Но при этом всем мы все-таки умудряемся весь этот запас спустить.
Как это происходит? Ведь при таких оценках подавляющее число задач проекта должно выполняться раньше срока. А по факту мы видим вот такой эффект "выпрямления" сроков, описанный у Максима Дорофеева в книге "Джедайские техники":

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

Происходит это потому, что мы имеем дело не с компьютерами, а с людьми.

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

Безусловно, этот синдром знаком всем.

На одной из лекций преподаватель говорит: "На следующей неделе будет тест по темам всего семестра". Студенты дружно возмущаются, что очень мало времени, что они не успеют подготовиться. Допустим, преподаватель сжалился и перенес тест на неделю.
И как много студентов после этого сразу начнет готовиться?
Да никто! Зачем, впереди еще куча времени!

В итоге получается вот такая штука:

График распределения вероятности завершения задачи смещается вправо. А сроки при этом естественно не меняются.
И, естественно, вероятность сдать задачу в срок уменьшается.

Рассмотрим сначала аналогию: деньги.
Вы - руководитель подразделения, в прошлом году сражались за бюджет на этот год. Но вот уже год близится к завершению, а бюджет потрачен не весь. Вы пойдете к руководству и попросите забрать остаток обратно?
Ни в коем случае! Потому что вы знаете, что в этом случае в следующем году вам бюджет урежут. Поэтому вы точно найдете, на что его потратить.

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

Суммарно эта два шаблона поведения преобразуют график вероятности выполнения задачи таки образом (была левая кривая, стала правая):

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

Эти два поведенческих шаблона гарантированно съедают все заложенные в проект подстраховки.

Ужасно.

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

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

Пусть подпроект A завершили на 10 дней раньше срока (-10), по подпроекту B тоже отлично отработали и завершили раньше на 12 дней (-12), С: "-3", D: "-20". А вот подпроект E задержали на 10 дней (+10).
Среднее число "-7". Но начнем ли мы интеграцию на 7 дней раньше срока (например, комплексное тестирование)?
Конечно нет. В данном случае усреднение не применимо. Для интеграции нам нужны все части проекта. И начнем мы ее на 10 дней позже планового срока. Несмотря на то, что 80% работы было завершено раньше срока.

Теперь посчитаем, какова вероятность начать интеграцию в срок, если вероятность завершения каждой части в срок 50%.
В этом случае вероятность начать интеграцию в планируемый срок - всего три процента!

Это еще не все. Есть еще одна неприятность, связанная со сроками выполнения задач: это неприятность с использованием ресурсов.

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

Есть две ветви проекта, которые используют один ресурс. В плане-графике при планировании это естественно учтено и задачи не пересекаются по времени. Предположим, что каждое задание будет завершено в срок с вероятностью 50%.
Какова вероятность, что нижнее задание с ресурсом Y будет начато в срок? Нужно, чтобы обе первых задачи из двух веток были выполнены в срок.
Поэтому вероятность 25%.

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

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

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

Рассмотрим небольшой типовой проект, вот его PERT-диаграмма:

Каждый цвет - определенный тип ресурсов. Использование ресурсов одного типа не пересекается. Внутри каждой ветки связь между задачами "окончание-начало". У некоторых задач есть связь "окончание-начало" и между ветками, это отмечено стрелками.

На рисунке приведена ситуация для случая выполнения каждой задачи в наиболее вероятный срок (то есть 50%-ная вероятность закончить каждую задачу как раньше, так и позже). Итоговый расчетный срок в этом случае 70 дней.

Моделирование проводил Элияху Голдратт и сделал он это с учетом следующих вводных:
Оценки каждой задачи даны исходя не из 50, а из 80%-ной вероятности уложиться в срок и уровень неопределенности не очень высок (то есть оценки "раздуты" всего в два раза и клиенту пообещали 140 дней).

Обратите внимание, на каждую задачу заложено в ДВА раза больше времени, чем наиболее вероятное время ее выполнения.

Эта гистограмма показывает распределение сроков завершения проекта после его тысячи прогонов.

120 дней - проект завершен в примерно 1% случаев.
140 дней - проект завершен в половине случаев.
180 дней - проект завершен в 80% случаев.
В более чем 10% случаев проект не был завершен за 190 дней.

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

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

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

В условиях мультипроектной среды все еще хуже. В случае одного проекта мы даем три обещания (срок, стоимость, содержание). А сколько мы даем обещаний в случае мультипроектной среды? Три * на количество проектов.

Мультипроектная среда предполагает задействование одних и тех же людей в нескольких разных проектах (иначе люди будут сильно недозагружены).

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

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

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

Это переключение контекста наносит самый большой урон срокам.
Простой пример:

Есть три проекта, использующих один ресурс. Сверху показано, как будут завершены проекты при последовательной работе над ними. Снизу - то, что часто происходит на практике. Инженер делает часть работы по проекту A, затем его переключают на проект B, потом на проект C и так по кругу.
Что при этом происходи со сроками завершения проектов?
Проекты A и B завершаются гораздо позже. На самом деле и проект C тоже будет завершен позже, т.к. на нижней диаграмме не учтено дополнительное время на переключение контекста (когда человек возвращается к работе над приостановленной задачей, ему нужно время вспомнить, что это за задача, что именно он уже успел сделать, на каком этапе остановился). И чем больше времени прошло с момента переключения, тем больше времени надо на восстановление контекста (аналог переналадки оборудования на производстве).

Получается этакая стратегия loose-loose (как антипод win-win).

Очень многие не понимают, что есть огромная разница между количеством трудозатрат на задачу и количеством времени, которое уходит, чтобы ее завершить.
Посмотрите на картинку: количество трудозатрат в верхней и нижней диаграмме вложено одинаково, а количество времени, которое потребовалось, чтобы, например, завершить задачу A - совершенно разное. Поэтому есть большая разница между трудозатратами проекта и количеством времени на его завершение. Разница может быть очень значительна - не десятки, а сотни процентов.
К слову, оптимизация в том числе и задействования ресурсов при одновременном выполнении проектов - это задача проектного офиса, поэтому его наличие в мультипроектной среде критически важно.

Помните расчет вероятности сроков завершения проекта, где всего в половине из 1000 случаев проект был завершен в запланированный срок?
Если применить это же самое моделирование для мультипроектной среды из трех одинаковых проектов, то картина получается следующая:

50% вероятности завершить каждый из проектов за 370 дней. Но это не та цифра, которую можно обещать клиенту, ведь в 10% случаев на завершение каждого проекта уходит более 430 дней.

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

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

Элияху Голдратт в своих лекциях по управлению проектами рассказывал такой показательный эпизод из своей практики:

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

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

Чтобы правильно спланировать проекты, нужно ответить на несколько вопросов:

1. Где, на каком ресурсе, вероятнее всего проекты "застрянут" на самое длительное время?
   В наиболее загруженном отделе.
2. Где вероятнее всего проекты вызовут переключение ресурсов между разными задачами?
   В наиболее загруженном отделе.
3. Где является наиболее важным максимально использовать ресурсы?
   В наиболее загруженном отделе.

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

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

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

Помните результаты моделирования, которое приводилось выше для трех проектов? Где с 50%-ной вероятностью каждый из проектов будет завершен за 370 дней. Если взять те же проекты, с теми же условиями, только проекты расположить ступенчато относительно наиболее загруженного отдела (то есть два из трех проектов начать позже по времени), то получатся такие цифры:

Первый проект с 50% вероятностью будет завершен за 155 дней (а не за 370) и с 90% вероятностью - за 195 дней (а не за 430). Второй проект тоже выполняется значительно быстрее, чем в предыдущем моделировании. А третий - показывает примерно те же сроки.

То есть мы применили вроде бы контринтуитивное решение, начав проекты позже и позволив ресурсам в самом загруженном отделе периодически простаивать, не позволяя переключаться на другие задачи, а получили при этом такой впечатляющий выигрыш!

Но применять подход со ступенчатым расположением проектов и запрещением переключений между задачами нужно только в этом наиболее загруженном отделе. Ни в коем случае нельзя применять этот подход для всех отделов сразу, как бы это заманчиво ни выглядело. Если так поступить, в процессе работы, из-за безотказно работающего закона Мерфи, нужно будет постоянно заниматься перепланированием, в итоге получится хаос.
Ритм должен задавать только один отдел, если мы хотим иметь управляемую систему (собственно, это один из краеугольных камней Теории Ограничений).

Дальнейшие улучшения достигаются уже другим путем: оптимизацией проектного управления уже внутри каждого проекта.

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

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

Еще раз: для нас неважно, будет ли завершена в срок какая-то конкретная задача - для нас важно, чтобы весь проект был завершен в срок.
Если инженера оценивают по тому, насколько он уложился по каждой задаче в запланированный срок - это прямая мотивация делать все возможное для срыва проектов, как бы странно это ни звучало.
Мы не используем эффект статистических флуктуаций. Флуктуации дискретных событий, расположенных последовательно, усредняются. И если мы будем рассматривать проект целиком (если быть более точным, то критический путь проекта в диаграмме Ганта), то выполнение его в срок целиком требует мЕньшей подстраховки, чем суммарное выполнение каждой задачи в срок.

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

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

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

Но есть очень важный момент: этого НЕЛЬЗЯ делать, пока люди не понимают причин, для чего это делается. Люди должны быть убеждены, что руководство понимает, что оценка сроков не означает обязательство уложиться в этот срок. И, соответственно, не будет наказывать за невыполнение какой-то конкретной задачи в срок.
Это КРИТИЧЕСКИ важный момент. Нужно КАЖДОМУ человеку, участвующему в проекте, это объяснить и убедить сократить оценку наполовину. Объяснить, что это время не изымается безвозвратно - бОльшая часть этой подстраховки останется в проекте. Но не на конкретной задаче, а на проекте целиком.

---
Сколько добавлять подстраховки в проект?
Меньше, чем изъяли из задач. Т.к. в задачах мы избавились от студенческого закона и закона Паркинсона, задача после передачи на следующий этап берется в работу сразу, таким образом статистические флуктуации работают и подстраховка в 2 раза нам ни к чему.
На практике обычно используют буфер проекта в размере 1/3 длительности работ критического пути проекта (точнее, критической цепи, об этом ниже).

Что в конкретном проекте является ограничением системы? Это критический путь проекта. Определение критического пути было дано еще в 50-х годах прошлого века. Это самая длинная цепь зависимых задач, определяющая срок выполнения проекта.
Но это определение не учитывает конкуренцию за ресурсы.

На примере проекта, который уже рассматривали, классический критический путь - это 6 задач, выглядит он так:

Каждый руководитель проектов знает, что как только происходит изменение в сроках каких-либо задач, "классический" критический путь может меняться. И приходится часто заниматься перепланированием всего проекта.

Но если в критическом пути учитывать конкуренцию за ресурсы (задачи, выполняемые одним и тем же ресурсом), то критический путь будет выглядеть уже по-другому и содержать уже 7 задач:

В Теории Ограничений этот путь получил название "Критическая цепь". Критическая цепь - это самая длинная цепь зависимых заданий, но зависимость может быть как структурная, так и ресурсная. Эта цепь определяет минимальное количество времени, требуемое для выполнения проекта.

Это и есть ограничение системы в контексте проекта.

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

На рисунке: сократили срок каждой задачи критической цепи и сформировали буфер проекта. При этом видим, что общая продолжительность проекта по плану-графику сократилась - уже не 140 дней, а 115-120.

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

Эмпирическое правило: буфер проекта должен составлять ок. 1/3 общей продолжительности работ критической цепи.

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

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

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

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

Что говорят цифры? При том же моделировании, которое использовалось выше (все условия модели сохранены полностью, все вероятности те же самые, тот же самый генератор случайных чисел), но с учетом переноса подстраховки из каждой отдельной задачи в буфер завершения и питающие буферы, цифры получаются такие:

Первый проект с 50% вероятностью будет завершен за 111 дней (а не за 370, как в первоначальном варианте) и с 90% вероятностью - за 190 дней (а не за 430).
Второй и третий проекты тоже выполняются значительно быстрее, чем в обоих вариантах предыдущего моделирования.
Особенно впечатляет разница в сроках выполнения третьего проекта.

Что это означает?

Что мы, применив ступенчатое планирование проектов относительно слабого звена (наиболее загруженного отдела) и изменив методику планирования внутри проекта, добились более чем двукратного ускорения завершения проектов. При том же количестве ресурсов.

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

Нужна система приоритетов.

Давайте рассмотрим такую ситуацию: одна из двух задач, которые на мне висят, "съела" уже половину буфера завершения одного проекта, а другая "съела" 10% буфера завершения второго проекта.
Какую задачу выполнять первой?
Кажется, ответ очевиден.

Другая ситуация: одна задача расходует буфер завершения первого проекта, и 20% его уже использовано, другая задача находится не на критической цепи второго проекта, но 80% питающего буфера соответствующей подветки уже израсходовано.
Какую задачу выполнять первой?
Ту, где израсходовано 20% буфера завершения. Потому что только буфер завершения влияет на сроки проекта. И только после использования 100% питающего буфера начинает расходоваться буфер завершения. Любой расход буфера завершения важнее расхода питающего буфера.

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

Таким образом, каждый ресурсный менеджер (и конечный ресурс) получает абсолютно прозрачную систему приоритетов и точно знает, в какой очередности выполнять проектные задачи.

Кроме этого, становится гораздо проще аргументировать выделение доп. ресурсов в случае их необходимости, оперируя данными об использовании буферов проекта. Например, если на одном из проектов уже использовано 50% буфера завершения, а проект еще не перешел экватор, это может быть веской причиной выделить на него доп. ресурсы.

И эти же данные по использованию буферов проектов (в совокупности с приоритетами самих проектов) являются прозрачными показателями для руководства при принятии решения о выделении доп. ресурсов.

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

Данные все того же моделирования после учета в этой модели описанной системы приоритетов (управление буфером):

Теперь срок завершения первого проекта можно обещать уже не 190 дней, а 115. Это наверняка должно вывести из игры конкурентов (см. выше, обычно подобные проекты в мультипроектной среде реально выполняются в районе 400 дней).
Теперь мы можем обещать такие сроки, которые с точки зрения конкурентов абсолютно невыполнимы.

Это очень серьезное конкурентное преимущество.

В итоге мы получили прозрачную и понятную систему показателей для проектов, которая может использоваться как топ-менеджментом компании, так и всеми участниками проектов:

• Процент завершения критической цепи.
  Это и только это определяет процент завершения всего проекта.
  Процент завершения проекта - это не процент завершения всех работ проекта! При таком способе подсчета мы можем 90% проекта завершить за один год, а оставшиеся 10% - еще за один год. Кроме того, этот подход провоцирует РП фокусироваться не на тех задачах, от которых реально зависят сроки проекта, а зачастую на второстепенных задачах, которые позволяют немного повысить процент завершения
  Поэтому расчет процента завершения всего проекта должен вестись только на основе задач критической цепи.
• Соотношение между расходом буфера завершения и завершенностью критической цепи (процент использования буфера завершения / процент завершения проекта).
  Если процент использования буфера завершения больше процента завершения проекта - это сигнал, что с выполнением проекта, возможно, есть какие-то проблемы и необходимо уделить ему пристальное внимание
• Скорость расхода буфера завершения (дней в месяц или дней в неделю и т.п.).
  Первые два показателя - усредненные по всему проекту. А этот показатель нужен для того, чтобы на коротких отрезках понимать, как продвигается работа по проекту. Используется для протяженных по времени проектов (полгода и более).