Не секрет, что большинство проектов не завершаются в срок, в рамках бюджета или в соответствии с изначально обещанным содержанием. Самая популярная причина, называемая руководителями проектов, – это низкая точность оценок времени на выполнение задач проекта, ведь проектная среда имеет очень высокий уровень неопределенности.
В то же время, каждая компания, работающая с ИТ-проектами постоянно предпринимает серьезные попытки снизить уровень неопределённости и повысить тем самым точность оценок длительности заданий. И все же, если бы мы спросили руководителей проектов 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.
