Определение основных вех следует непосредственно после построения СРР и ССО. Вехи удобно использовать для согласования основных стадий, этапов, фаз и т. д. разработки и реализации проекта, а также для анализа и контроля хода реализации проекта на соответствующих этим вехам уровнях управления. Так как для определения вех необходима минимальная, доступная в начале проекта информация, их можно использовать на самых ранних стадиях процесса планирования. На рис. 14.6.1 планирование вех составляет начальную, наиболее обобщенную часть плана, который потом развертывается в укрупненный и, наконец, детальный график [32].
При определении вех используется информация о ключевых точках, стадиях и состояниях, через которые проходит проект в течение своего жизненного цикла. Вехи отмечают существенные,
определяющие дальнейший ход развития проекта точки перехода. Поэтому вехи позволяют решать проблемы контроля, предоставляя набор естественных контрольных точек.
Достижение частных, промежуточных целей проекта, являющихся средствами в достижении общих целей (миссии проекта), удобно связывать с прохождением через вехи, как контрольные ключевые точки. Тогда при анализе выполнения работ вехи становятся эффективным средством управления, помогающим понять, на какой стадии находится проект, оценить, достигнуты ли основные показатели состояния и сколько осталось времени, денег, ресурсов и конкретных работ до завершения проекта.
В отличие от работ вехи не имеют продолжительности, хотя для их представления иногда и используются линейный графики (верхний график на рис. 14.6.1). Веха используется в качестве дискретной шкалы выполнения, которая имеет две оценки — выполнено и не выполнено.
Например, при принятии решений по финансированию очередного этапа проекта вехи могут использоваться для оценки завершенности работ при выполнении платежей по контрактам.
ТИПИЧНЫЕ ОШИБКИ ПЛАНИРОВАНИЯ И ИХ ПОСЛЕДСТВИЯ
Планирование с использованием ошибочных целей. Любой проект по своему содержанию предназначен для решения проблемы, удовлетворения конкретной потребности и т. д. В зависимости от этого формулируются те или иные конкретные цели. Если проблема непонятна и недостаточно четко сформулирована, то можно столкнуться с распространенной ошибкой, когда принимается правильное решение, но неизвестно точно, по какой конкретно проблеме.
Чтобы избежать подобной ситуации, необходимо выяснить реальное основание для выполнения работ: зафиксировать — желательно документально — описание проблем и потребностей, которые должны быть решены по завершении проекта; установить, как решение конкретных проблем отражено в описании целей и задач проекта. Только после этого можно приступать к планированию.
Планирование на основе неполных данных. Подобная ситуация характерна для инжиниринговых проектов, для которых на результаты планирования существенно влияют будущие результаты тестирования или результаты поисковых работ смежных направлений. При этом приходится планировать работы, начало которых, а возможно, и сам факт выполнения которых зависит от результатов тестовых испытаний или успехов/неудач в соседних подразделениях.
Аналогичная ситуация часто встречается в проектах разработки и адаптации информационных систем. Заказчик имеет непреодолимое желание получить готовый инструмент как можно быстрее. При этом он имеет только смутное представление о возможностях программного обеспечения, которое он выбрал, и что он хочет автоматизировать. С другой стороны, поставщики программного обеспечения знают очень немного о реальных процессах управления (функциональной, информационной, организационной структурах) в организации заказчика. И только когда они приступают к реализации проекта, начинается процесс взаимного информирования и обучения. Уточнение постановки приводит к существенному, иногда в несколько раз, увеличению объемов работ и изменению их целей и состава.
Планирование осуществляется с привлечением только плановиков. Хотя по многим причинам это оправдано, подобная организация планирования может привести к существенным потерям из-за отсутствия учета важных факторов. Как правило, забывают, казалось бы, незначительные детали или обстоятельства, невыполнение которых, тем не менее,, может привести к колоссальным потерям. Например, зависимость природоохранных мероприятий и прокладка трубопровода может повлиять на изменение сроков ввода в эксплуатацию крупной нефтегазовой магистрали. Поэтому ответственные исполнители по конкретным работам проекта, ответственные за проектное финансирование, за поставки и т. д. должны также привлекаться для планирования. Не говоря уже о психологических аспектах по реализации плана, в разработке которого не принимали участие конкретные исполнители.
Планирование без учета предыдущего опыта. Даже при наличии самой лучшей сметы, без использования предыдущего опыта реализации аналогичных проектов, можно допустить серьезные ошибки в планировании.
Планирование ресурсов без учета их доступности. Это касается, прежде всего, трудовых ресурсов, обладающих определенной квалификацией и возможностью прибыть к заданному сроку в заданное место для выполнения работ по проекту. Другая проблема, если одна и та же группа специалистов планируется в нескольких одновременно выполняемых проектах. Плохое ресурсное планирование является одной из наиболее распространенных причин срыва реализации проектов. К сожалению, именно ресурсному планированию, в отличие от временного планирования, уделяется незаслуженно мало внимания.
Планирование без учета координации. Любой достаточно большой проект разбивается на относительно независимые части, за реализацию которых отвечают самостоятельные подразделения. При отсутствии координирующих воздействий со стороны руководителя проекта они могут действовать, преследуя исключительно свои частные, локальные цели, что приводит к хаосу и срыву реализации проекта в целом.
Планирование без учета мотиваций. Как правило, для работ по проектам привлекаются исполнители из функциональных подразделений, у которых есть свое руководство, свои цели и специфические задачи и, разумеется, своя форма оплаты труда, которые обычно никак не связаны с целями и задачами проекта. Поэтому исполнители не чувствуют ответственности и важности работ по проекту без надлежащего стимулирования за результаты их деятельности. А руководитель проекта не наделен достаточными правами по стимулированию исполнителей и не может формировать бюджет материального стимулирования по результатам в проекте.
Планирование с излишней детализацией. Когда проект планируется слишком детально, возникают проблемы при анализе, планировании и контроле его состояния — например, что выполнено и в чем задержка. Более того, трудно эффективно управлять большим количеством ресурсов, определять задержки по времени, оценивать затраты, разрабатывать реальные, приемлемые для целей управления графики. Излишняя детализация в учете факторов приводит к необходимости разрешения огромного числа конфликтов, к частым изменениям, к необходимости постоянных согласований с другими проектами, выполняемыми в то же время. Однако излишнее укрупнение тоже может привести к проблемам потери управляемости. Необходима золотая середина, когда в проекте планируются только те параметры, которыми можно и нужно управлять.
Планирование не для отслеживания. К сожалению, это наиболее распространенная ошибка, когда планирование выполняется ради того, чтобы был план. Причин такого отношения к плану и планированию несколько. Все ошибки планирования, перечисленные в этом параграфе, могут стать причиной негативного отношения к плану, когда он перестает быть реальным инструментом управления работами по проекту. Команда, потеряв управление, забывает в первую очередь о плане.
Другая крайность, когда план постоянно меняется и перестает служить своим целям, задавать желаемые состояния по проекту, служить ориентиром при выполнении работ и т. д. Это то же самое, как ехать на машине по карте, которая постоянно меняется. В этом случае легко и заблудиться.
Что нужно, чтобы избежать ошибок планирования [34]:
1. для проекта должен быть сформулирован список решаемых проблем;
2. основная цель проекта (миссия) должна быть доведена до сведения всех участников;
3. должны быть идентифицированы риски и, по возможности, исключены случайности;
4. необходимо убедиться, что стратегия проекта может быть реализована и удовлетворяет ограничениям по бюджету, срокам и объему (проведен PCTS-анализ осуществимости: Р — Performance, С — Cost, Т — Time, S — Scope. Затраты являются функцией уровня исполнения Р, времени Т и содержания, объема работ S);
5. наличие положительных результатов анализа «за и против» реализации проекта (проведен Force-field — анализ, заключающийся в описании и количественной оценке факторов, которые могут способствовать и препятствовать осуществлению проекта);
6. конечный результат должен быть понятен всем членам команды проекта;
7. показатели оценки результатов деятельности по проекту должны давать оценку состояния дел с необходимой точностью. Целесообразна разработка внутрифирменных шкал оценки деятельности по видам работ;
8. определен критерий выполнения планов;
9. СРР должно иметь столько уровней детализации, чтобы можно было оценивать затраты, сроки и ресурсы с необходимой точностью;
10. ССР должна быть согласована с заказчиком, инвесторами и ответственными исполнителями;
11. график вех должен соответствовать плановым проверкам для подтверждения факта выполнения работ, качества выполнения, количества израсходованных ресурсов;
12. график детальных работ разрабатывается в форме календарно-сетевого графика на основе СРР;
13. определены работы критического пути;
14. дата завершения проекта не должна противоречить критическому пути;
15. критический путь должен быть реалистичным;
16. диаграмма Ганта должна использоваться в качестве рабочего инструмента, а не для демонстрации навыков работы с ней;
17. расход ресурсов не должен превышать утвержденный уровень;
18. уровень потребления любого ресурса должен быть не более 80% его предельного уровня;
19. должны быть выявлены и разрешены ресурсные конфликты с другими проектами;
20. должна быть разработана система управления проектом и принят внутрифирменный стандарт;
21. позиции сметы должны основываться на регистрируемых данных во всех случаях, где это возможно;
22. позиции сметы должны быть понятными, не вводить в заблуждение и быть приемлемыми для управления и контроля;
23. календари ресурсов должны учитывать выходные дни, праздники, больничные, отпуска и т. д.;
24. в смете должны быть учтены накладные расходы на проезд и проживание и охрану;
25. планы должны учитывать время на диспетчерские и рабочие совещания. Все члены команды проекта должны иметь соответствующую квалификацию;
26. если дополнительное обучение членов команды необходимо, оно должно быть оплачено и проведено;
27. организация рабочих мест и коммуникации должны обеспечивать свободное и открытое взаимодействие членов команды проекта;
28. при необходимости должен проводиться обмен мнениями как на основе обычных совещаний, так и в виде телеконференций;
29. необходимо получить подтверждение от поставщиков о графиках поставок;
30. необходимо предусмотреть возможные таможенные формальности при оформлении грузов, ввозимых из заграницы;
31. ведение управленческих счетов должно быть предусмотрено для всех работ проекта;
32. календарно-сетевой график работ и управленческие счета должны быть взаимосвязаны с СРР;
33. дополнительные расходы, выходящие за рамки бюджета, должны утверждаться руководителем проекта;
34. руководители функциональных подразделений должны ставить в известность руководителя проекта до переназначения их сотрудников на другие работы;
35. должна быть принята система шкал оценки деятельности по проекту и их критические, пороговые значения;
36. любые увеличения или уменьшения бюджета проекта должны утверждаться;
37. все члены команды проекта должны иметь свои персональные графики работ;
38. изменения максимальных цен должны согласовываться с инвесторами и заказчиком;
39. по отношению к поставщикам должны планироваться и при необходимости применяться штрафные санкции;
40. у поставщиков должны быть соответствующие сертификаты и рекомендации, характеризующие их потенциальные возможности;
41. необходимо оценить возможное влияние форс-мажорных обстоятельств на ход реализации проекта;
42. должно быть проведено выравнивание потребления ресурсов;
43. изначально сверхурочные работы не должны планироваться при разработке графиков;
44. при завершении ключевых этапов работ (вех) должны быть предусмотрены процедуры составления и подписания отчетов, актов и т. д.;
45. технические условия по проекту должны письменно фиксироваться и согласовываться со всеми заинтересованными участниками проекта;
46. необходим мониторинг законодательства и нормативной базы, относящихся к целям и задачам проекта;
47. проектировщики и представители производителей комплектующих должны быть членами команды проекта;
48. заказчик должен консультироваться, прежде чем определять требования;
49. SWOT-анализ должен базироваться в большей степени на данных, чем на мнениях и субъективных оценках;
50. члены команды должны отбираться с учетом личной заинтересованности в результатах проекта;
51. должна быть разработана процедура завершения проекта и сдачи объекта в эксплуатацию;
52. методы и средства управления не должны тормозить инноваций и внедрения современных технологий;
53. при планировании текущего проекта необходимо учесть опыт аналогичных предыдущих проектов;
54. должны быть определены узкие места на календарно-сетевом графике, связанные с использованием уникальных ресурсов, например, тестового оборудования;
55. ресурсы, которых пока нет в наличии, должны учитываться при расчете рисков, влияющих на успех проекта;
56. права и обязанности каждого члена проекта должны быть четко определены;
57. процессы, технология и процедуры выполнения работ должны разрабатываться исполнителями и утверждаться руководителями;
58. не следует утверждать технические задания с избыточными характеристиками;
59. следует разделить работы с продолжительностью более 4 — 6 недель на меньшие части, чтобы избежать возможного отставания (из-за отсутствия надлежащего контроля) при их завершении;
60. параллельные критические пути должны быть по возможности исключены;
61. календарно-сетевые графики должны быть проанализированы на предмет ошибок, «петель» и т. д.;
62. у функциональных руководителей в рамках матричных организационных структур должна быть графики потребности в специалистах их подразделений;
63. для продолжительных проектов необходим учет инфляции;
64. для каждой фазы, этапа и т. д. проекта должен быть определен критерий завершения.
ДЕТАЛЬНОЕ ПЛАНИРОВАНИЕ
Детальное планирование связано с разработкой детальных графиков для оперативного управления на уровне ответственных исполнителей. Наличие и сопровождение детального графика работ является одним из главных требований для управления проектом, после его начала. Команда проекта полностью отвечает за составление графиков работ, если работы не являются излишне комплексными.
Чем больше проект, тем больше факторов надо учитывать при разработке детального графика. Это и информация от функциональных подразделений, и обязательства по контрактам, и график финансирования, и все то, что может повлиять на успех проекта. В зависимости от размеров проекта за разработку и сопровождение детального графика может отвечать конкретный специалист или специальное подразделение, например, группа разработки графиков, в западной
терминологии — плановики. Итоговая информация по готовому графику передается
персонально ответственным исполнителям, исполнителям в функциональных подразделениях, участникам проекта и, при необходимости, заказчику.
В корпоративных системах управления проектами применение детальных графиков позволяет получить синергетический эффект за счет оптимального распределения и использования ресурсов компании, ведущей несколько проектов. Большинство проектов начинается с разработки графиков для более тщательной проработки их смет, с учетом их взаимосвязей, возможности совместного использования машин и механизмов, корпоративных знаний, технологий и т. д. Детальные графики служат основой для укрупненных графиков, обеспечивая как заказчика, так и руководителя проекта всей необходимой информацией для оперативного управления, предупреждая о возможных срывах или узких местах.
Детальный график, независимо от размеров проекта и его сложности, должен включать:
1. все ключевые события и даты. Если для составления отчета по работе требуется участие заказчика, соответствующие даты (вехи) тоже должны быть внесены в график. Если по каким-либо причинам эти ключевые даты нарушаются, необходимо незамедлительно поставить заказчика в известность об изменениях;
2. точную последовательность работ. Логика их выполнения должна быть зафиксирована с помощью сетевой модели, в которой можно было бы проследить все виды зависимостей между работами и взаимосвязь событий проекта;
3. взаимосвязь графиков и СРР. Система кодирования должна позволять строить укрупненные графики в соответствии с уровнями СРР, например, определять время начала и окончания пакетов работ;
4. все графики должны служить основой для определения этапов, фаз и прочих временных интервалов по проекту. Кроме того, при необходимости определять потребность в ресурсах для каждой из частей, фрагментов или событий проекта.
Уровень детализации графика зависит от сложности и размеров проекта. Приведенные выше рекомендации справедливы для любых проектов и нуждаются в уточнении в каждом конкретном случае. Поэтому прежде чем приступать к построению детального графика, необходимо ответить на вопросы:
1. сколько событий или работ необходимо включить в график;
2. насколько детально надо описывать технологию выполнения работ;
3. для кого этот график предназначается.
Большинство организаций разрабатывают несколько графиков: укрупненные для высшего уровня управления (для руководителей, заказчика, ответственных исполнителей и т. д.) и детальные, для конкретных исполнителей работ, для более низких уровней управления. Например, детальные графики могут разрабатываться для конкретных подразделений или департаментов, отвечающих за определенный фронт работ. За верхние уровни отвечает руководитель проекта (например, первые три уровня СРР без учета пакетов работ). На уровне пакетов работ согласование с ним может и не требоваться.
Процесс разработки детального графика представлен на рис. 14.8.1 [32]. От подразделения, отвечающего за управление проектом, в функциональные подразделения поступает запрос на разработку детальных графиков. Форма и содержание запроса может быть разной, так как служит лишь основой для создания согласованного и утвержденного документа — графика работ. Функциональные подразделения разрабатывают укрупненные графики, детальные графики и, если позволяет время, детальные графики для конкретных специализированных подразделений (исполнителей работ по проекту). Представители функциональных и проектных подразделений участвуют в согласовании графиков, в проверке выполнимости сроков, требований и ограничений по контрактам.
Прежде чем графики будут окончательно утверждены, черновые, предварительные варианты планов и графиков необходимо обсуждать с заказчиком. Это важно, так как позволяет:
1. убедиться, что ничего не упущено и не осталось без внимания;
Рис. 14.8.1. Последовательность разработки детального графика
2. предупредить возможную негативную реакцию на недоработанный или недостаточно понятный для заказчика документ. Заказчик должен чувствовать себя участником процесса создания графика.
После того как график подготовлен, его необходимо довести до сведения всех участников проекта: команды проекта, функциональных подразделений, заказчика.
Методы и средства разработки графиков могут отличаться, но все графики в обязательном порядке проходят утверждение у руководителя проекта. Форма представления графика должна быть удобной и наглядной как для заказчика, так и для исполнителей. График должен стать рабочим инструментом как для управления и согласования позиций на совещаниях, так и для сдачи работ, особенно когда сроки были сорваны, а бюджет превышен по независящим от команды проекта причинам.
СЕТЕВОЕ ПЛАНИРОВАНИЕ
Сетевая диаграмма (сеть, граф сети, PERT-диаграмма) — графическое отображение работ проекта и зависимостей между ними. В планировании и управлении проектами под термином «сеть» понимается полный комплекс работ и вех проекта с установленными между ними зависимостями.
Сетевые диаграммы отображают сетевую модель в графическом виде как множество вершин, соответствующих работам, связанных линиями, представляющими взаимосвязи между работами. Этот граф, называемый сетью типа «вершина — работа» или диаграммой предшествования — следования, является наиболее распространенным представлением сети (рис. 14.9.1).
Существует другой тип сетевой диаграммы, называемый сеть типа «вершина — событие», который на практике используется реже. При данном подходе работа представляется в виде линии между двумя событиями (узлами графа), которые, в свою очередь, отображают начало и конец данной работы. PERT-диаграммы являются примерами этого типа диаграмм (рис. 14.9.2).
Сетевая диаграмма не является блок-схемой в том смысле, в котором это средство используется для моделирования деловых процессов. Принципиальным отличием от блок-схемы
Рис. 14.9.2. Фрагмент сети «вершина — работа»
Рис. 14.9.2. Фрагмент сети «вершина - событие»
является то, что сетевая диаграмма отображает только логические зависимости между работами, а не входы, процессы и выходы, а также не допускает повторяющихся циклов или так называемых петель (в терминологии графов — ребро графа, исходящее из вершины и возвращающееся в ту же вершину, рис. 14.9.3). I
Рис. 14.9.3. Пример петли в сетевой модели
Методы сетевого планирования — методы, основная цель которых заключается в том, чтобы сократить до минимума продолжительность проекта. Основываются на разработанных практически одновременно и независимо методе критического пути МКП (СРМ - Critical Path Method) и методе оценки и пересмотра планов ПЕРТ (PERT - Program Evaluation and Review Technique).
Критический путь — максимальный по продолжительности полный путь в сети называется критическим; работы, лежащие на этом пути, также называются критическими. Именно длительность критического пути определяет наименьшую общую продолжительность работ по проекту в целом. Длительность выполнения всего проекта в целом может быть сокращена за счет сокращения длительности работ, лежащих на критическом пути. Соответственно, любая задержка выполнения работ критического пути повлечет увеличение длительности проекта.
Информация о работах критического пути позволяет проект-менеджеру сконцентрировать свое внимание на сбережении основного и невосполнимого ресурса - времени. При этом анализируются как работы критического пути, так и, что очень важно, околокритические работы, не лежащие на критическом пути, но в той или иной степени близкие к нему. Подобные работы даже при самом незначительном изменении графика могут стать критическими и существенно изменить сроки завершения проекта.
Метод критического пути позволяет рассчитать возможные календарные графики выполнения комплекса работ на основе описанной логической структуры сети и оценок продолжительности выполнения каждой работы, определить критический путь для проекта в целом.
Полный резерв времени или запас времени — это разность между датами позднего и раннего окончаний (начал) работы. Управленческий смысл резерва времени заключается в том, что при необходимости урегулировать технологические, ресурсные или финансовые ограничения проекта он позволяет руководителю проекта задержать работу на этот срок без влияния на срок завершения проекта в целом. Работы, лежащие на критическом пути, имеют временной резерв, равный нулю.
Диаграмма Ганта — горизонтальная линейная диаграмма, на которой задачи проекта представляются протяженными во времени отрезками, характеризующимися датами начала и окончания, задержками и, возможно, другими временными параметрами. Пример отображения диаграммы Ганта с помощью современных компьютерных средств (глава 23) представлен на рис. 14.9.4.
Рис. 14. 9. 4 Диаграмма Ганта
Процесс сетевого планирования предполагает, что вся деятельность будет описана в виде комплекса работ или работ с определенными взаимосвязями между ними. Для расчета и анализа сетевого графика используется набор сетевых процедур, известных под названием «процедуры метода критического пути».
Процесс разработки сетевой модели включает:
1. определение списка работ проекта;
2. оценку параметров работ;
3. определение зависимостей между работами.
Определение комплекса работ проводится для описания деятельности по проекту в целом, с учетом всех возможных работ. Работа является основным элементом сетевой модели. Под работами понимается деятельность, которую необходимо выполнить для получения конкретных результатов. Пакеты работ определяют деятельность, которую необходимо осуществить для достижения результатов проекта, которые могут выделяться вехами.
Прежде чем начать разработку сетевой модели, необходимо убедиться, что на нижнем уровне СРР определены все работы, обеспечивающие достижение всех частных целей проекта. Сетевая модель образуется в результате определения зависимостей между этими работами и добавления связующих работ и событий. В общем виде данный подход основан на предположении, что каждая работа направлена на достижение частного результата. Связующие работы, возможно, и не требуют получения какого-либо материального конечного результата, например работа «организация исполнения».
Оценка параметров работ является ключевой задачей руководителя проекта, привлекающего для решения этой задачи членов команды, ответственных за реализацию отдельных частей проекта. Ценность календарных графиков, стоимостных и ресурсных планов, получаемых в результате анализа сетевой модели, полностью зависит от точности оценок продолжительности работ, а также оценок потребностей работ в ресурсах и финансовых средствах.
Оценки должны производиться для каждой детальной работы, а затем могут быть агрегированы и обобщаться по каждому из уровней СРР в плане проекта.
Продолжительность (длительность) работы определяет время, которое предполагается затратить на ее выполнение. Оценки длительности каждой детальной работы выполняются на основе предыдущего опыта и количества планируемых на работу исполнителей. Облегчает эту процедуру то, что оценки необходимо делать для детальных работ проекта, которые представляют собой, как правило, элементарные виды деятельности.
Основными являются два типа работ:
1. работа с фиксированной продолжительностью имеет определенную длительность, которая не зависит от количества назначенных ей ресурсов: нельзя ускорить выполнение работы, назначив, например, вдвое больше исполнителей, поскольку существуют факторы, влияющие на длительность работы, но не зависящие от количества исполнителей;
2. работа с фиксированным объемом имеет длительность, зависящую от количества назначенных исполнителей (ресурсов). Таким образом, для работ, продолжительность которых зависит от количества доступных ресурсов, возможен вариант непосредственного расчета длительности исходя из информации о требуемых объемах работ (например, в человеко-днях) и количестве доступных ресурсов. В этом случае увеличение числа исполнителей приведет к сокращению времени выполнения работы.
Определение зависимостей между работами необходимо для расчета календарного графика по МКП. Связь предшествования отображает в расписании логическую зависимость между работами. Наиболее частой причиной таких зависимостей являются технологические ограничения (начало одних работ зависит от результатов других), хотя возможны и ограничения, диктуемые другими соображениями. Эти связи образуют структуру сети. Совокупность взаимосвязей между работами определяет последовательность выполнения работ. В соответствии с установленными связями работы делятся на предшествующие и последующие. Предшествующая
работа является обеспечивающей для последующей; таким образом, для начала выполнения последующей работы требуется выполнение всех предшествующих.
Основными методами определения зависимостей между работами являются:
1. Метод предшествования (PDM) или «вершина — работа» (рис. 14.9.1).
Оперирует четырьмя типами зависимостей предшествования — следования:
1. «Начало после окончания*. Это стандартная последовательность, при которой предшествующая работа должна завершиться до начала последующей;
2. «Начало после начала*. Это наиболее общая последовательность при моделировании работ, которые должны выполняться одновременно. В этом случае не требуется завершения предшествующей работы до начала последующей. Для ее начала необходимо, чтобы предшествующая работа только началась;
3. «Окончание после окончания*. Этот тип зависимости также используется для моделирования параллельных работ. В этом случае окончание последующей работы контролируется окончанием работы предшественницы;
4. «Окончание после начала». Этот тип зависимости используется довольно редко и применяется, прежде всего, для работ, выполняемых вахтовым методом.
2. Метод построения стрелочных диаграмм (графиков) (ADM) или «вершина — событие». Этот метод оперирует только зависимостями «Начало после окончания» и в некоторых случаях требует применения фиктивных работ для корректного отражения технологии (рис. 14.9.2).