2.8. Иерархические структуры
В Spider Project можно использовать неограниченное количество различных иерархических структур работ и ресурсов. Использование множественных иерархических структур мы считаем принципиальным, а споры вокруг того, какую именно иерархическую структуру считать оптимальной, беспредметными. Поэтому нам не понятна цель работы той группы в комитете стандартов PMI, которая разрабатывает рекомендации по структуризации проектов. Использование множественных иерархических структур позволяет не только получать отчетность о проектах в самых различных разрезах, но и проконтролировать полноту компьютерной модели проекта.
Как правило, мы используем в наших проектах по меньшей мере следующие три иерархические структуры работ - по объектам проекта, по процессам проекта, по ответственности исполнителей. При этом следует подчеркнуть, что структура ответственности с успехом заменяет матрицу ответственности, обычно разрабатываемой в плане проекта. Ответственности как правило распределяются иерархически и только в небольших проектах структура ответственности становится плоской и может быть сведена к матрице. Кроме того, в пакете Spider Project можно создавать и другие структуры работ, в том числе неполные (не содержащие всех операций проекта). Неполные структуры - удобный инструмент для подготовки отчетности и анализа отдельных аспектов проекта.
Примерами таких неполных структур могут служить структура поставок, в которую входят только те операции, которые отображают поставки материалов, или структура Milestones, включающая только контрольные события проекта (Milestone schedule). Использование иерархических структур ресурсов особенно важно при мультипроектном управлении. При этом матричная структура организации определяет необходимость получения отчетности по ресурсам как по проектной иерархии, так и по функциональной. Поэтому и для ресурсов полезно использовать множественные иерархические структуры.
2.9. Архивы
Для анализа исполнения проекта, а также для анализа “что если” очень важно иметь возможность сохранять прежние версии проекта и иметь возможности для сравнения и анализа отклонений текущей версии проекта от предыдущих. При этом мы считаем недостаточным сохранять только базовый план. В Spider Project вы можете хранить неограниченное количество версий проекта и анализировать ход исполнения работ не только по сравнению с какой-то базовой версией, но и с любой другой. Такая возможность позволяет оценить как исполнялся проект за последнюю неделю, за последний месяц, с начала года, по сравнению с базовым планом и т.д. Если производился анализ рисков, то можно сравнить текущую версию с оптимистической и пессимистической. Наличие архивов очень важно на стадии завершения проекта для проведения послепроектного анализа и для разрешения конфликтов.
3. Вычисления
Задачи, решаемые с помощью пакетов управления проектами обычно включают: n разработку расписания исполнения проекта без учета ограниченности ресурсов, n разработку расписания исполнения проекта с учетом ограниченности ресурсов (leveling), n определение критического пути и резервов времени исполнения операций проекта, n определение потребности проекта в финансировании, материалах и оборудовании в любые периоды времени, n определение распределения во времени загрузки возобновляемых ресурсов, n анализ рисков и планирование расписания и других характеристик проекта с учетом рисков, n ведение учета исполнения, n анализ отклонений хода работ от запланированного (в том числе Earned Value Analysis) и прогнозирование основных параметров проекта.
Задача составления расписания исполнения проекта без учета ограниченности ресурсов имеет точное математическое решение (метод критического пути) и для аналогичных исходных данных решается всеми пакетами одинаково. По остальным задачам имеются существенные отличия в подходах и получаемых результатах.
3.1. Расписание исполнения проекта с учетом ограниченности ресурсов
В большинстве пакетов под расписанием с учетом ограниченности ресурсов понимается расписание, в котором учитывается ограниченность возобновляемых ресурсов. При этом традиционно используются самые простые эвристики, которые не обеспечивают ни получения расписания, близкого к оптимальному, ни устойчивости этого расписания. В лучшем случае пользователям предоставляется возможность выбора критериев при назначении ресурсов в процессе составления расписания, что позволяет выполнить перебор и выбрать лучшее из полученных решений. Однако и такой перебор не обеспечивает получения приемлемых результатов. В Spider Project используются значительно более совершенные эвристики, которые позволяют устойчиво получать более короткие расписания исполнения проекта при тех же ресурсных ограничениях, чем в других пакетах. В качестве примера приведем простой проект - приобретение компьютерной программы.
Как ни странно, но для этого проекта расписания, составляемые другими пакетами при условии, что имеется только один Аналитик и один Менеджер, на три недели длиннее. В большинстве реальных проектов расписания Spider Project существенно короче расписаний, составляемых другими пакетами при тех же ограничениях на ресурсы проекта. Не менее важной является и устойчивость расписания, особенно на фазе исполнения.
В процессе исполнения оставшиеся плановые длительности операций меняются, поэтому и расписания, составленные пакетами в автоматическом режиме могут оказаться совершенно другими. Так, например, изменив плановую длительность операции “Negotiations with Vendors” в нашем примере с 15 дней на 14, вы получите совершенно другое расписание в пакете Microsoft Project. Изменение длительности операции на один день влечет за собой изменение планового срока завершения проекта на три недели в ту или другую сторону! Новое расписание будет оптимальным, соответствующим расписанию Spider Project, однако встает вопрос - а что, если вы уже заключили контракты, запланировали поставки и т.д.? С этого момента вы не сможете использовать автоматический расчет расписания проекта, если только вы не пересмотрите свои соглашения. Именно поэтому в пакете Spider Project имеется дополнительная опция - поддержка расписания предыдущей версии проекта, в качестве которой вы можете выбрать любую версию из архива проекта.
3.2. Критический путь и резервы
Традиционное понятие критического пути работает только при наличии неограниченных ресурсов. При ограниченных ресурсах традиционные способы определения критического пути теряют смысл. Это же относится и к понятию полного резерва (total float). Полный резерв, определяемый большинством пакетов, показывает резерв времени исполнения операций, если пренебречь ограничениями на количество имеющихся ресурсов. Практически такие резервы использовать нельзя. В качестве примера приведем простой проект, состоящий из трех операций - у двух операций плановая длительность по десять дней, у третьей - пятнадцать. Первые две для своего исполнения требуют ресурса А, третья - ресурса В. Если операции не взаимосвязаны, то третья операция является критической в классическом понимании, а у двух первых имеется полный резерв в пять дней. Если же рассчитать расписание с учетом того, что имеется лишь по одной единице каждого из ресурсов, первые две операции можно выполнять лишь по очереди, а у третьей возникает резерв в пять дней.
Поэтому в Spider Project вычисляется ресурсный критический путь и резервы сроков исполнения операций с учетом ограниченности ресурсов. Мы довольно давно предлагали эту концепцию (в частности, в презентациях на конференциях PMI и конгрессе IPMA в Париже в 1996 году) и рады тому, что сейчас концепции ресурсного критического пути стали уделять внимание. Имея возможность определения и использования ресурсного критического пути и ресурсных резервов, мы критически относимся к теории Critical Chain.
3.3. Определение потребности проекта в финансировании, материалах и оборудовании
В большинстве пакетов вычисляются потребности проекта в финансировании, материалах и оборудовании на базе составленного расписания проекта. Если требуемое финансирование или поставки материалов не могут быть обеспечены, то пользователи вынуждены корректировать графики вручную. В пакете Spider Project можно моделировать не только расходы финансовых средств, но и доходы, не только потребление материалов, но и поставки. Тем самым можно подсчитать не только затраты проекта, но и Cash Flow, отслеживать не только потребности, но и движение материалов. Кроме того, в Spider Project можно рассчитать расписание исполнения проекта с учетом не только ограниченности возобновляемых ресурсов, но и графиков поставок и финансирования, причем не только по суммарным затратам, но и по отдельным составляющим и центрам затрат и материалов.
3.4. Определение распределения во времени загрузки возобновляемых ресурсов
Принципиальным отличием возможностей Spider Project от других пакетов является то, что при расчетах учитывается и количество, и процентная загрузка ресурсов на операциях проекта. Таким образом, даже при неполной загрузке ресурсов на отдельных операциях результаты расчета расписания работ при ограничениях на общее количество ресурсов остаются достоверными. Соответственно и отчетность получается не только по времени загрузки ресурсов, но и по количеству загруженных ресурсов.
3.5. Анализ рисков и планирование с учетом рисков
У нас имеются серьезные замечания к подходам к моделированию рисков, принятым в большинстве пакетов. Независимо от того, используется ли метод PERT или метод Монте Карло, при моделировании рисков предполагается, что длительности операций не коррелированы между собой. В жизни это не так. Как правило, отклонения длительности исполнения операций связаны с неправильным определением производительности назначенных ресурсов, а значит и отклонения длительности исполнения операций, использующих те же ресурсы взаимосвязаны. Поэтому при моделировании рисков в пакете Spider Project мы, как правило, исходим из оптимистических, пессимистических и ожидаемых оценок не длительностей операций, а производительности назначенных ресурсов. Тем самым, моделируются не последствия, а источники рисков, и результаты получаются значительно более понятными и достоверными.