Каталог решений - 4 причины, почему проекты никогда не завершаются в срок

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

В то же время, каждая компания, работающая с ИТ-проектами постоянно предпринимает серьезные попытки снизить уровень неопределённости и повысить тем самым точность оценок длительности заданий. И все же, если бы мы спросили руководителей проектов 40 лет назад, что бы они сказали о своих проблемах? Были бы их жалобы другими? Думаю, нет. Даже если проекты отличаются друг от друга, жалобы практически не меняются.

Это отражает очевидный факт – проектная среда имеет две доминирующие характеристики:

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

Все мы об этом, конечно, давно знаем и пытаемся с этим бороться. Сначала мы серьезно перезакладываемся при оценках сроков и бюджетов проекта, чтобы уж точно хватило. Потом заложенных резервов, как правило, не хватает и мы начинаем что-то изобретать по ходу проекта – решаем проблемы по мере их возникновения. А потом мы начинаем урезать содержание и увеличивать нагрузку на ресурсы. Однако, возможно, нам стоит пересмотреть наши подходы к управлению заложенными резервами в оценках времени выполнения заданий. Ведь их там не так уже и мало!

Резервы времени

Вопрос: Достаточно лишь одних резервов времени, так называемой подстраховки, заложенной в оценке длительности каждого задания, для того, чтобы поглотить все отклонения от графика проекта?

Взгляните на рассуждение:

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

Однако….

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

А как вы даете оценку?

Давайте проверим себя: а как вы даете оценку?

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

Учтите следующее:

• Вы делали нечто подобное 1 или 2 раза, то есть статистики мало и придется давать оценку скорее интуитивно, чем объективно.
• Вы знаете, что ваша оценка будет переведена в разряд обязательства, то есть возможны взыскания.
• Вас попросили дать только одно число. И ни каких плюс/минус километр!

Какую оценку вы дадите? Варианты:

• Гарантирующую 50% вероятности выполнения в срок.
• Гарантирующую 80% вероятности в срок.
• Гарантирующую боле 80% вероятности завершения работ вовремя.

Дайте угадаю… большинство из вас дали оценку, гарантирующую 80% или 80%+ вероятность завершения в срок. Верно?

Почему мы даем такие оценки? Все просто:

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

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

Судя по графику + 30% к вероятности добавляет относительно немного подстраховки времени. Это рассуждение верно для нормального распределения вероятностей. Однако, в реальности из-за высокой неопределенности вероятность завершения в срок НЕ симметрична – она имеет длинный хвост.

Незначительное увеличение ВЕРОЯТНОСТИ приводит к ЗНАЧИТЕЛЬНОМУ увеличению ВРЕМЕНИ. Чем выше степень неопределенности, тем длиннее хвост! В конце концов, ни что не может быть сделано со 100% вероятностью! Так ведь? Наша практика показывает, что для большинства ИТ-проектов по меньшей мере половина времени в предварительных оценках – это подстраховка.

Позвольте тогда задать один вопрос… Если все дают оценку с высокой вероятностью завершения в срок, закладывают туда изрядное количество подстраховки, как же так получается, что большинство заданий в проектах не завершаются НАМНОГО раньше срока? Что происходит со всей этой подстраховкой, которую мы так щедро закладываем в оценки?

Давайте разбираться…

Причины потери подстраховки

Причина №1. Закон Паркинсона.

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

Первый Закон Паркинсона гласит: «Работа заполняет все время, отпущенное на неё».

Следствие: Перевод оценки в разряд обязательства приводит к реализации именно данной оценки (но никак не меньшей!)

Причина №2. Студенческий синдром

Нам хорошо известна модель поведения исполнителя, когда всё делается в последний момент. Так называемый «Студенческий синдром». Мы тянем время до последнего, каждый раз находя все более важные или более интересные дела. Да и к чему спешить, ведь до срока еще столько времени! В результате все резервы беспечно теряются.

Причина №3. Опоздания передаются, выигрыш — нет

На рисунке схема проекта зависимых заданий:

• По плану на проект должно уйти 17 дней
• Первое задание закончилось на 5 дней раньше.
• Четвертое задание закончилось на 5 дней позже.

Сколько времени уйдет на выполнение проекта? Хотелось бы, как и планировали — 17, но для указанного типа проектов правильный ответ — 22 (12+5+5=22).

Вывод: Опоздания передаются следующему заданию, выигрыш – нет.

Моделирование условного проекта

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

Исходные условия:

• Проект содержит 7 в разной степени зависимых друг от друга этапов.
• В проекте заняты 10 различных спецов и каждый может выполнять задания только своего типа.
• Каждое задание длится 20 дней и вероятность выполнения его в срок 80%.
• В каждом задании 10 дней подстраховки.
• Плановое время выполнения проекта 140 дней.

Какова вероятность, что проект будет завершен через 140 дней? Запустим симулятор проекта используя генератор случайных чисел и выполним 1000 прогонов.

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

• Вероятность успеть в срок – чуть более 10%

Почему так? Может быть, мы недостаточно заложили подстраховки? Решит ли проблему увеличение подстраховки в каждом задании?

Давайте порассуждаем:

• Мы считаем, что всему виной отдельные задания, которые не завершились в срок.
• В следующем проекте в аналогичные задания, которые «обвиняются» сейчас, будет заложено больше подстраховки.
• При планировании проекта его время исполнения будет еще больше увеличено.
• Мы продолжаем работать по-старому. Т.е. все те же явления — Студенческий синдром, Закон Паркинсона, Опоздания в цепи и потеря выигрыша- продолжают расходовать нашу подстраховку.
• Проект все равно не завершается в срок.
• Мы снова ищем виновные задания и снова добавляем резервы по времени.

Получаем замкнутый круг! В конце концов рынок ставит предел увеличению времени наших проектов… 

Причина №4. Перескакивание между заданиями

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

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

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

Реальный ущерб от перескакивания не в потере времени, уходящего на переключение от задания к заданию, а в сдвиге даты завершения каждого задания! Перепрыгивание ресурсов не помогает НИ ОДНОМУ проекту завершиться раньше назначенного срока. А это в свою очередь, как мы уже знаем, ведет к тому, что люди закладывают еще большие подстраховки, когда их просят дать свои оценки длительности заданий.

Моделирование мульти-проектной среды

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

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

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

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

Результат на рисунке:

Симулятор провел оптимизацию и рассчитал, что реально успеть все три проекта завершить за 420-430 дней.  Будем считать это отправной точкой.

Выводы

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

И так, есть, как минимум, 4 основных причины из-за которых мы теряем резервы времени в проектах:

• Закон Паркинсона.
• Студенческий синдром.
• Потеря выигрыша и передача опозданий в цепи зависимых заданий.
• Перепрыгивание от задания к заданию в мульти-проектных средах.

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

Решение должно обеспечить, чтобы:

• Оценка длительности заданий не переводилась в разряд ОБЯЗАТЕЛЬСТВ — это должно значительно сократить количество подстраховки.
• Выигрыш по времени и опоздания компенсировали друг друга.
• Перепрыгивания от задания к заданию резко сократились.

И так, что собой представляет решение?

Читайте об этом в моей следующей статье: "Как завершать проекты в срок".

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Krasnodar. Больше статей можно прочитать здесь.

Приглашаем всех принять участие в тематических митапах Инфостарта: infostart.ru/events/