Лоуренс Лич - Вовремя и в рамках бюджета

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

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

3. Почему мы не соединяем между собой некритические цепочки с учетом ограничений по ресурсам и их логической зависимости?

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

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

Рекомендую сделать обобщенную картину проекта из нескольких сотен операций максимум. Для детализации данных использовать описание пакетов работ или разбивать проект на подпроекты. Метод критической цепи успешно применялся на проектах общей численностью до 30 000 операций.

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

5. В плане нашего проекта есть операции вне зоны нашего контроля. Как с этим быть?

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

6. Наше руководство/заказчик хочет, чтобы мы назвали точные даты ряда промежуточных контрольных событий и обеспечили их соблюдение. Как нам поступить?

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

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

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

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

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

8. По мере реализации проекта выявилась необходимость в изначально не запланированных работах. Как с этим быть?

Если тип проекта предполагает прояснение объема работ по ходу реализации (пример — процедура технического обслуживания, где в первую очередь проводится диагностика неполадок), необходимо с самого начала прикинуть и заложить в план ориентировочное (не максимальное) время на выполнение «уточненных» работ. Чтобы снизить риски, необходимо, кроме того, составлять план так, чтобы необходимость в дополнительных работах выявлялась как можно раньше. Добавлять операции в план, когда проект уже идет, можно, но лишь до тех пор, пока не исчерпан проектный буфер. Как только расход буфера составит 100%, а идей его пополнения нет, придется переделывать план проекта и пересчитывать размеры буферов.

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

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

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