Вовремя и в рамках бюджета. Управление проектами по методу критической цепи
Шрифт:
Самой важной составляющей описания пакета работ является схема расположения операций. Обратите внимание, в этой диаграмме нет точных дат. Даны длительность операции, ее место в структуре работ и перечень требований по ресурсам для выполнения этих работ. Одна из причин отсутствия дат в диаграмме заключается в том, что мы не можем определить даты, пока не будет готова полная картина проекта и найдена критическая цепь. Указание дат может помешать программе правильно вычислить критическую цепь или путь. Кроме того, вероятность точного соблюдения
Мне встречались случаи, когда схему операций отдавали в руки финансовым службам, которые верстали по ней бюджет. Аналогично планировщики сами по себе должны были составлять расписание, а потом думать, как соотнести между собой разные составляющие. Используйте описание пакета работ как есть, и пусть компьютер рисует график и делает разбивку по бюджету. Даты выполнения работ и таблицы бюджета должны быть результатом создания единой картины расписания и затрат, а не исходными данными для нее. Конечно, при управлении с помощью критической цепи нас и не интересуют даты отдельных операций. Значение имеет лишь дата начала последовательностей работ и дата завершения всего проекта.
Чтобы достичь цели проекта, необходимо выполнить ряд работ в определенной последовательности. Это и есть логика проекта. Каждый пакет работ — это просто маленький проект со своей логикой. Операции должны быть спланированы так, чтобы результат одной служил материалом для другой. Каждую операцию можно рассматривать как процесс с материалом на входе, преобразующимся в результат на выходе. Проектные операции соответствуют модели SIPOC из TQM: поставщик — исходный материал на входе — процесс — результат на выходе — клиент. Поставщик здесь — менеджер предшествующей операции. Клиент — менеджер последующей операции. Затем при помощи контрольных точек и связей между операциями определяются взаимосвязи между пакетами работ.
Самый распространенный вид логических отношений — это когда после завершения одной операции начинается следующая («окончание — начало», выход первой служит входом для второй). Вообще существуют следующие основные варианты связей операций, применяемые в большинстве программных продуктов:
• Финиш-старт, часто называется также отношениями предшественника и последователя. Результат одного процесса является необходимым исходным материалом для следующего. Большинство операций в диаграмме проекта должны быть связаны именно таким образом.
• Старт-старт (с запаздыванием) — эта связь устанавливается, когда две операции могут выполняться одновременно. При этом сначала в ходе первой производится некий объем продукта, который может далее обрабатываться на второй. Например, вам нужно пропустить множество экземпляров продукции через три последовательных этапа. Вместо того чтобы запланировать три этапа для каждого экземпляра отдельно, мы делаем всего три
• Финиш-финиш — этот вид связи используется, когда операции должны завершиться одновременно, хотя начинаться могли в разное время. Например, одновременно должна завершиться выверка перекрестных ссылок в разных главах книги.
В специализированных программах часто проявляются и другие ограничения, например жестко задаются даты выполнения работ. Прописывая тип связи, в них можно указывать временные «отступы». Но всем этим надо пользоваться как можно реже, потому что зачастую люди забывают об подобных тонкостях и не отслеживают их. В итоге результаты процесса расчета сетевой диаграммы проекта могут оказаться совершенно неожиданными.
В некоторых программах, разработанных для управления методом критической цепи, допускаются отношения только типа «финиш-старт» и/или один или два других вида ограничений (например, начало не ранее чем заданная дата). В них обычно невозможно задать интервал запаздывания. Если обстоятельства требуют, можно все же отразить и какую-то особую логику выполнения работ — при помощи обычных операций и связей «финиш-старт», хотя для этого в плане могут понадобиться несуществующие операции-«пустышки». Так что удостоверьтесь, что вам известны все особенности и возможности установленной у вас программы.
За исключением случаев с заданными неизменными величинами (например, дата начала готовности стадиона к Олимпиаде или доступные объемы финансирования), четкие даты должны быть результатом создания диаграммы проекта, а не исходной информацией. Не загоняйте отдельные операции в рамки точных дат. Укажите связи, и пусть программа сама все считает. Запомните: бессмысленно назначать конкретные даты для каждой операции проекта, точность этих дат равна нулю.
Логику проекта нужно выверить по следующим пунктам.
• Определены ли результаты каждой операции?
• Действительно ли предшествующая операция необходима для начала последующей?
• Достаточно ли предшествующей операции для начала последующей?
• Обеспечивают ли указанные операции достижение запланированных результатов проекта (по сравнению с заданными в ИСР)?
• Указаны ли ресурсы, необходимые для выполнения каждой операции?
• Не введены ли ненужные ограничения (даты) операций?
• Все ли контрольные точки (из схемы ключевых событий) попали в план?
• Если длительность операции зависит от исполнителя, предусмотрена ли 100%-ная занятость данного исполнителя на данной операции?
• Все ли последовательности работ сходятся воедино к концу проекта? Если нет, объедините их хотя бы в контрольной точке «проект завершен».
Не устанавливайте связи между составными операциями, которые в плане разбиваются на мелкие работы. Необходимо указать, как соединены между собой эти составляющие. В следующей главе рассказывается, как составить план проекта методом критической цепи, используя диаграмму проекта с назначенными ресурсами.