Период окупаемости — это период времени, проходящий с момента вложения инвестиции до того момента, когда мы ожидаем, что результаты, полученные в результате вложения, покроют инвестицию.
Прежде чем предлагать добавить ещё людей, которые будут заниматься управлением проакта, подумайте:
Больше людей означает больше времени и усилий на синхронизацию. Увеличение количества людей вдвое ведет к (условно) четырёхкратному увеличению усилий по синхронизации.
Основные проблемы, присущие большинству проектов, можно определить как высокую вероятность:
В менталитете же корпоративного руководства всегда виноват внешний мир.
В массе ими используются выражения неопределённости — тех факторов, оценку которых трудно сделать в начале проекта.
Делая оценку по времени, руководство закладывает подстраховку от неопределённости.
В большинстве случаев, управленцы удобно себя чувствуют при 80-90% вероятности выполнения задания в срок.
Однако, распределение вероятности успеха таково, что с определённой точки каждый добавочный процент вероятности успеха будет "стоить" всё больше и больше времени.
Пример:
Компании настолько привержены менталитету экономии, что забывают, что проекты предпринимаются не с целью того, чтобы экономить деньги, а с целью того, чтобы их делать.
Предположим, что наш проект — это строительство завода.
Нам нужно построить задание и затем сделать его функциональным. Провести электричество, воду, систему кондиционирования и так далее. Нам также надо выбрать поставщиков для строительства нашего оборудования и заключить с ними контракты. Нам надо дать поставщикам достаточно времени, чтобы они успели построить оборудование. Как только здания и оборудование будут готовы, мы можем установить оборудование.
Завод почти готов.
Критический путь (critical path) определяется как самая длинная (по времени) цепь зависимых элементов проекта.
Критический путь определяет время, необходимое для завершения проекта. Любое опоздание на критическом пути задержит завершение проекта. Вот почему критический путь должен быть в центре внимания управляющего проектом.
В вышеуказанном примере критическим путём будет путь, проходящий через элементы построения здания, перевода его в функциональное состояние и установки в нем оборудования. В общем, 150 дней.
Если мы начнём все пути как можно раньше (ранний старт), управляющий проектом будет вынужден заниматься слишком многими вещами одновременно. Если управляющий начинает слишком много вещей одновременно, то теряет сфокусированность, а этого управляющий проектом никак не может себе позволить.
Если мы начинаем путь в точке его позднего старта, то этот путь не имеет никакого запаса по времени. Это означает, что любое опоздание на этом пути точно так же вызовет опоздание всего проекта.
Должен быть хороший контрольный механизм, который будет держать нас сфокусированными.
Контрольный механизм — это механизм, измеряющий прогресс проекта. Вся проблема в том, что к тому времени, когда отчёт о прогрессе проекта указывает, что что-то идёт не так, уже, как правило, слишком поздно.
Для того чтобы хорошо управлять, менеджеры должны контролировать затраты, и в то же самое время менеджеры должны обеспечить проход — обеспечить, чтобы правильные товары добрались до правильных клиентов, чтобы те за них заплатили.
Предположим, что один из ваших менеджеров говорит вам, что он провёл отличную работу по сокращению затрат: ему удалось сократить затраты на 20%. Правда, это привело к тому, что 50% ваших клиентов крайне недовольны уровнем обслуживания. Вы назовёте такого менеджера хорошим?
Другой менеджер обеспечил проход — выполнил все поставки в срок, но для этого набрал дополнительных людей и перевёл всех на бесконечную сверхурочную работу. Хороший ли он менеджер?
Контролировать затраты и обеспечить проход. Два абсолютно необходимых условия. Мы не достигнем нашей цели, если удовлетворим только одно из этих двух условий. И эти подходы настолько противоположны, что приемлемого компромисса между ними не существует.
Прочность цепи определяет самое слабое звено.
А теперь давайте посмотрим, что это предполагает. Вы всё так же президент, отвечающий за всю цепь. Я всё так же отвечаю за один отдел. Поскольку существует только одно самое слабое звено, давайте возьмём более распространенный случай: отдел, за который я отвечаю, НЕ является самым слабым звеном. И... вы опять говорите мне, что я должен добиться улучшений. На этот раз улучшить прочность звена. И опять через какое-то время я прихожу к вам и говорю, что в результате моей гениальности и денег и времени я добился улучшения. Я усилил прочность моего звена. Я сделал его в три раза прочнее.
Но ведь вас на самом деле интересует не моё звено, а вся цепь.
Моё звено не было самым слабым. Если я сделал его прочнее, насколько я увеличил прочность цепи? Ни на сколько. Абсолютно ни на сколько.
Теперь вы видите что на самом деле происходит? Большинство локальных улучшений не помогают глобальному! А мы хотим глобального улучшения, мы хотим, чтобы организация как целое добилась улучшения. Теперь мы знаем, что поскольку любое улучшение требует внимания, времени и денег, обеспечение многих локальных улучшений по принципу "чем больше — тем лучше" определённо не является тем путём, который приведет к улучшению всей организации. Это неверный путь.
Вам знакомо выражение "синдром конца месяца"?
В начале месяца мы контролируем затраты. Жёстко следим, что не было сверхурочной работы, чтобы размер производимых партий был оптимальным.
Но в конце месяца кто об этом помнит? Делается всё, только чтобы выпихнуть заказ с производства: партия из трёх недостающих единиц, сверхурочная работа на все выходные. Только отгрузите этот чёртов заказ!
Итак, прочность цепи определяется её самым слабым звеном.
Проблема считается точно определённой только тогда, когда её возможно представить как конфликт между двумя необходимыми условиями.
Мы утверждаем, что для того чтобы контролировать затраты, менеджеры должны стараться управлять в соответствии с миром затрат. Почему? Потому что мы полагаем, что достижение хороших результатов с точки зрения затрат возможно только за счёт повсеместного достижения хороших локальных результатов.
А почему мы утверждаем, что для того чтобы обеспечить проход, менеджеры должны стараться управлять в соответствии с миром прохода? Потому что мы полагаем, что достижение хороших результатов с точки зрения прохода невозможно за счёт повсеместного достижения хороших локальных результатов
Теперь у нас есть три альтернативы:
"Достижение хороших результатов с точки зрения затрат возможно только за счёт повсеместного достижения хороших локальных результатов". То, что деятельность многих менеджеров и почти все наши системы основаны на этой исходной посылке, рассматривается в ТОС как существующая ключевая проблема наших организаций.
Дерево текущей реальности (ДТР) — это инструмент для анализа проблем. С его помощью можно изучить причинно-следственные связи, определяющие текущую ситуацию. ДТР начинается с имеющихся нежелательных явлений в системе (симптомов) и помогает добраться до ряда истинных причин или же до одной ключевой проблемы, вызвавшей все нежелательные явления, с которыми мы столкнулись. Ключевая проблема обычно и является тем ограничением, которое мы стараемся найти, используя тактику пяти направляющих шагов. ДТР подсказывает нам, что именно реорганизовать, — выявляет наименьшее, простейшее изменение в системе, которое даст наибольший положительный эффект.
Дерево строится "сверху вниз", идём от симптомов, каждый раз задавая себе вопрос "А почему?", к корням.
В общем виде это выглядит так:
На данный момент мы можем заключить, что существует три механизма того, как подстраховка закладывается почти в каждый элемент проект:
Опоздание одного элемента полностью передается следующему элементу. Выигрыш по времени, достигнутый одним элементом, как правило, разбазаривается.
Предположим, что работник должен сделать три элемента: А, В и С. Эти элементы могут входить в разные проекты или в один, это значения не имеет. Выполнение каждого элемента требует ровно 10 рабочих дней. Если он будет работать с элементами последовательно, то на исполнение каждого элемента уйдёт 10 дней. Так, через 10 дней после того, как он начнет работу над В, В будет готов и его передадут другому человеку для дальнейшей работы. Но наш работник находится под давлением и старается удовлетворить требования всех. В результате он работает с одним элементом 5 дней и переходит к другому элементу. Предположим, что он работает с элементами в такой очередности А, В, С, А, В, С. Каким будет время исполнения каждого элемента?
Время исполнения каждого элемента удваивается.
Пожалуй, именно перепрыгивание от задания к заданию оказывает наибольший негативный эффект на время исполнения. От этого страдают все. Неважно, в какой форме имеет место это перепрыгивание. Это могут быть совещания, "пожары", параллельные задания. Эффект тот же самый. Время исполнения раздувается. Если подумать, каждый раз, когда вы даете оценку по времени, вы знаете, что действительное время работы над заданием составляет только малую долю времени, которое вы указываете в оценке, но вы интуитивно делаете поправку на перепрыгивание от задания к заданию.
Есть три механизма разбазаривания подстраховки:
Что можно сделать — время, запланированное для каждого элемента, будет сокращено наполовину.
С другой стороны, буфер проекта не будет равен тому времени, которое мы забрали из всех элементов. Он будет сокращен наполовину:
Однако, сейчас мы обсудили элементы на самом критическом пути. Это, без сомнения, поможет.
Но в проектах часто происходит опоздание на критическом пути из-за проблемы, случившейся за пределами критического пути — на одном из многих питающих путей.
Где мы должны создать эти буферы времени? Что для нас значит "перед бутылочным горлышком"?
Буферы мы должны создать в точках, в которых питающие пути вливаются в критический путь.
-- Откуда мы возьмем время для буферов?
Но теперь у нас есть вышеуказанная формула. Для каждого питающего пути мы сократим изначальные оценки времени наполовину и используем половину урезанного времени исполнения в качестве питающего буфера:
Итак, мы:
Большинство людей, занятых в проекте, часто включая даже управляющих проектами, не знают размаха ущерба, вызванного опозданием проекта. Неудивительно, что при переговорах с поставщиками и субподрядчиками мы не обращаем достаточного внимания на их время исполнения.
Важно не объявлять дату завершения задания человеку, делающему это задание. Тем, что вы объявляете дату завершения вы почти навязываете "студенческий синдром"; и тогда время исполнения сократить невозможно.
Во многих проектах может случиться следующее — ресурс Х требуется в нескольких местах одновременно. На протяжении определенного времени Х перегружен и начинает отставать. Это ызывает опоздания, которые тянутся от одного некритического пути в другой. Питающие буферы недостаточно велики, чтобы поглотить эти опоздания. Неудивительно, что его критический путь прыгает с одного пути на другой.
Если существует конкуренция за ресурсы — критическая цепь может значительно отличаться от критического пути.
В этих случаях в чем действительная опасность следования критическому пути, а не критической цепи?
Это может привести к катастрофам. Критический путь начинает прыгать. Ты теряешь контроль.
Необходимо добавить в PERT названия ресурсов.
Необходимо добиться максимального устранения конкуренции за ресурс.
Конкуренция за ресурсы означает, что от одного и того же ресурса ожидается, что он должен делать два разных элемента проекта в одно и то же время. Устранение конкуренции за ресурс между двумя элементами во многих случаях требует, чтобы выполнение одного из элементов было отложено. Проблема в том, и мы это детально обсуждали, что не существует чёткого способа решить, какой элемент отложить. Это почти волевое решение.
Это верно и для одного проекта. Почему проблема становится более серьезной, когда эти элементы принадлежат разным проектам?
Потому что в ситуацию вовлечены два управляющих проектом Это не то же самое, как в ситуации, когда вы работаете в одном проекте, где не имеет значения, какой элемент вы отодвинете. Когда у вас два проекта, естественно, что каждый управляющий проектом будет сражаться за то, чтобы его элемент был выполнен в первую очередь.
Есть один важный пункт. Все буферы, о которых мы говорим: буфер проекта, питающие буферы и ресурсные буферы — они все защищают отдельный проект. А здесь мы должны помнить, что мы также должны защитить бутылочное горлышко, глобальную деятельность организации.
Но это не так страшно, как может показаться — достаточно ввести ещё один буфер, буфер бутылочного горлышка.