Степень детализации плана

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

Рис. 5.5. Пример неожиданных результатов выравнивания ресурсов: до и после выравнивания: задание «проверка документа» смещается вправо из-за 10%-ной загрузки исполнителя

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

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

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

Рассмотрим тот факт, что средняя величина операции в плане (затраты на нее в долларах, длительность выполнения или время работы исполнителей) обратно пропорциональна количеству операций. Следовательно, средняя операция в плане из 100 операций составляет 1% от всего проекта. Поскольку параметры большинства операций нельзя оценить точнее, чем с вероятностью плюс-минус 50%, нет смысла делить проект на более мелкие составляющие.

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

Чем больше операций вы включаете, тем больше усилий тратится на составление плана. Если определенное количество усилий тратится на большее количество операций, значит, на каждую из них уйдет усилий меньше. А значит, и план будет менее точным, а не наоборот. Раз вы можете позволить себе потратить на составление плана больше усилий, стоит направить их на связки между операциями, проверить, все ли «входы-выходы» учтены правильно, посмотреть данные по исполнителям и рабочим процессам выполнения операций, а не добавлять в план новые записи.

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

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

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