Jump to content

Техника оценки и обзора программы

Сетевая диаграмма PERT для семимесячного проекта с пятью этапами (от 10 до 50) и шестью мероприятиями (от A до F).

Техника программ оценки и анализа ( PERT ) – это статистический инструмент, используемый в управлении проектами , который был разработан для анализа и представления задач, связанных с выполнением данного проекта .

PERT был первоначально разработан Чарльзом Э. Кларком для ВМС США в 1958 году; он обычно используется в сочетании с методом критического пути (CPM), который также был представлен в 1958 году. [1]

PERT — это метод анализа задач, связанных с завершением проекта, особенно времени, необходимого для выполнения каждой задачи, и определения минимального времени, необходимого для завершения всего проекта. Он включает в себя неопределенность, позволяя планировать проект, не зная точно деталей и продолжительности всех действий. Он больше ориентирован на события, чем на начало и завершение, и больше используется для проектов, где основным ограничением является время, а не стоимость. Он применяется к очень масштабным, одноразовым, сложным, нестандартным инфраструктурным проектам, а также проектам НИОКР .

PERT предлагает инструмент управления, [2] : 497  который опирается «на диаграммы действий и событий со стрелками и узлами : стрелки представляют действия или работу, необходимые для достижения событий или узлов, которые указывают на каждую завершенную фазу всего проекта». [3]

PERT и CPM являются взаимодополняющими инструментами, поскольку «CPM использует одну оценку времени и одну оценку затрат для каждого действия; PERT может использовать три оценки времени (оптимистическую, ожидаемую и пессимистическую) и не использовать затраты для каждого действия. Хотя это явные различия, термин PERT все чаще применяется ко всему планированию критического пути». [3]

PERT был разработан в первую очередь для упрощения планирования и составления графиков крупных и сложных проектов. Он был разработан для Управления специальных проектов ВМС США для поддержки проекта атомной подводной лодки ВМС США «Поларис». [4] Он нашел применение во всей промышленности. Ранним примером являются зимние Олимпийские игры 1968 года в Гренобле , где PERT использовался с 1965 года до открытия Игр 1968 года. [5] Эта проектная модель была первой в своем роде, возрождением научного менеджмента Фредерика Тейлора и позднее усовершенствованной Генри Фордом ( фордизм ). CPM компании DuPont был изобретен примерно в то же время, что и PERT.

Сводный отчет PERT, этап 2 , 1958 г.

Первоначально PERT расшифровывался как «Исследовательская задача по оценке программы», но к 1959 году был переименован. [4] Он был обнародован в 1958 году в двух публикациях Министерства военно-морского флота США под названием « Задача исследования по оценке программы, сводный отчет, этап 1». [6] и Фаза 2. [7] оба в основном написаны Чарльзом Ф. Кларком. [1] В статье 1959 года в журнале The American Statistician Уиллард Фазар , руководитель отдела оценки программ Управления специальных проектов ВМС США, дал подробное описание основных концепций PERT. Он объяснил:

С помощью электронного компьютера метод PERT обрабатывает данные, представляющие основные, конечные достижения (события), необходимые для достижения конечных целей; взаимозависимость этих событий; а также оценки времени и интервала времени, необходимого для завершения каждого действия между двумя последовательными событиями. Такие временные ожидания включают оценки «наиболее вероятного времени», «оптимистического времени» и «пессимистического времени» для каждого действия. Этот метод представляет собой инструмент управленческого контроля, который позволяет оценить перспективы своевременного достижения целей; выделяет сигналы опасности, требующие управленческих решений; выявляет и определяет как методичность, так и слабые места в плане потока или сети последовательных действий, которые необходимо выполнить для достижения целей; сравнивает текущие ожидания с запланированными датами завершения и вычисляет вероятность достижения запланированных дат; и моделирует последствия вариантов решения — до принятия решения. [8]

Руководство PERT для управленческого использования , июнь 1963 г.

Через десять лет после появления PERT американский библиотекарь Марибет Бреннан составила избранную библиографию , включающую около 150 публикаций по PERT и CPM, все из которых были опубликованы в период с 1958 по 1968 год. [3]

Для разделения рабочих подразделений в PERT [9] был разработан еще один инструмент: Структура иерархии работ . Структура иерархии работ обеспечивает «структуру для полноценного сетевого взаимодействия. Структура иерархии работ была официально введена в качестве первого элемента анализа при проведении базового PERT/CPM». [10]

Терминология

[ редактировать ]

События и мероприятия

[ редактировать ]

В диаграмме PERT основным строительным блоком является событие со связями с его известными событиями-предшественниками и событиями-последователями.

  • Событие PERT : точка, отмечающая начало или завершение одного или нескольких действий. Это не требует времени и не использует никаких ресурсов. Когда оно отмечает завершение одного или нескольких действий, оно не «достигается» (не происходит) до тех пор, пока не будут завершены все действия, ведущие к этому событию.
  • Событие-предшественник : событие, которое непосредственно предшествует некоторому другому событию без каких-либо промежуточных событий. Событие может иметь несколько событий-предшественников и может быть предшественником нескольких событий.
  • событие-преемник : событие, которое следует сразу за каким-либо другим событием без каких-либо других промежуточных событий. Событие может иметь несколько событий-преемников и может быть преемником нескольких событий.

Помимо событий, PERT также отслеживает действия и подвиды деятельности:

  • Деятельность PERT : фактическое выполнение задачи, которая требует времени и ресурсов (таких как рабочая сила, материалы, пространство, оборудование). Его можно понимать как представление времени, усилий и ресурсов, необходимых для перехода от одного события к другому. Действие PERT не может быть выполнено до тех пор, пока не произойдет событие-предшественник.
  • Поддействие PERT : действие PERT можно дополнительно разложить на набор поддействий. Например, деятельность А1 можно разложить на А1.1, А1.2 и А1.3. Поддействия имеют все свойства действий; в частности, у поддействия есть события-предшественники или преемники, как и у действия. Поддействие можно снова разложить на более мелкие поддействия.

PERT определяет четыре типа времени, необходимого для выполнения действия:

  • оптимистическое время : минимально возможное время, необходимое для выполнения действия (о) или пути (О), при условии, что все идет лучше, чем обычно ожидается. [2] : 512 
  • пессимистическое время : максимально возможное время, необходимое для выполнения действия (p) или пути (P), при условии, что все пойдет не так (но исключая крупные катастрофы). [2] : 512 
  • наиболее вероятное время : наилучшая оценка времени, необходимого для выполнения действия (м) или пути (М), при условии, что все идет нормально. [2] : 512 
  • ожидаемое время : наилучшая оценка времени, необходимого для выполнения действия (te) или пути (TE), с учетом того факта, что дела не всегда идут как обычно (подразумевается, что ожидаемое время — это среднее время, в течение которого потребуется выполнить задачу, если задача будет повторяться несколько раз в течение длительного периода времени). [2] : 512–513 
  • стандартное отклонение времени : изменчивость времени выполнения действия (σ te ) или пути (σ TE )

Инструменты управления

[ редактировать ]

PERT предоставляет ряд инструментов для управления с определением понятий, таких как:

  • Резерв или резерв — это мера избыточного времени и ресурсов, доступных для выполнения задачи. Это количество времени, на которое задача проекта может быть отложена, не вызывая задержки любых последующих задач ( свободный резерв ) или всего проекта ( общий резерв ). Положительный резерв будет указывать на опережение графика ; отрицательный резерв будет указывать на отставание от графика ; и нулевой резерв будет указывать на соблюдение графика .
  • критический путь : самый длинный возможный непрерывный путь от начального события до конечного события. Он определяет общее календарное время, необходимое для проекта; и, следовательно, любые временные задержки на критическом пути задержат достижение конечного события, по крайней мере, на такую ​​же величину.
  • критическая активность : деятельность, общий резерв которой равен нулю. Деятельность с нулевым свободным резервом не обязательно находится на критическом пути, поскольку ее путь может быть не самым длинным.
  • выполнения время : время, к которому предшествующее событие должно быть завершено, чтобы было достаточно времени для действий, которые должны пройти до завершения определенного события PERT.
  • время задержки : самое раннее время, в течение которого последующее событие может следовать за конкретным событием PERT.
  • быстрое отслеживание : параллельное выполнение более важных действий
  • сбой критического пути : сокращение продолжительности критических действий.

Выполнение

[ редактировать ]

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

В следующем примере есть семь задач, помеченных A до G. от Некоторые задачи можно выполнять одновременно ( A и B ), в то время как другие не могут быть выполнены до тех пор, пока не будет завершена предшествующая им задача ( C не может начаться, пока A не завершится ). Кроме того, каждая задача имеет три оценки времени: оптимистическую оценку времени ( o ), наиболее вероятную или нормальную оценку времени ( m ) и пессимистическую оценку времени ( p ). Ожидаемое время ( te ) рассчитывается по формуле ( o + 4 m + p ) ÷ 6. [2] : 512–513 

Активность Предшественник Оценка времени Ожидаемое время
Восемь. ( о ) Нормальный ( м ) Пес. ( п )
А 2 4 6 4.00
Б 3 5 9 5.33
С А 4 5 7 5.17
Д А 4 6 10 6.33
И Б , С 4 5 7 5.17
Ф Д 3 4 8 4.50
Г И 3 5 8 5.17

После завершения этого шага можно нарисовать диаграмму Ганта или сетевую диаграмму.

Диаграмма Ганта, созданная с помощью Microsoft Project (MSP). Примечание: (1) критический путь выделен красным, (2) резерв — это черные линии, связанные с некритическими операциями, (3) поскольку суббота и воскресенье не являются рабочими днями и поэтому исключены из расписания, некоторые столбцы на графике Диаграмма Ганта становится длиннее, если она сокращает выходные дни.
Диаграмма Ганта, созданная с помощью OmniPlan . Обратите внимание: (1) критический путь выделен, (2) резерв конкретно не указан в задаче 5 (г), хотя его можно наблюдать на задачах 3 и 7 (б и е), (3) поскольку выходные дни обозначены представляют собой тонкую вертикальную линию и не занимают дополнительного места в рабочем календаре, столбцы на диаграмме Ганта не становятся длиннее или короче, когда они переносят или не переносят выходные дни.

Следующий шаг — создание сетевой диаграммы вручную или с помощью программного обеспечения для создания диаграмм.

[ редактировать ]

Сетевую диаграмму можно создать вручную или с помощью программного обеспечения для создания диаграмм. Существует два типа сетевых диаграмм: активность на стрелке ( AOA ) и активность на узле ( AON ). Действия на диаграммах узлов обычно легче создавать и интерпретировать. Чтобы создать диаграмму AON, рекомендуется (но не обязательно) начать с узла с именем start . Эта «активность» имеет нулевую продолжительность (0). Затем вы рисуете каждое действие, у которого нет предшествующего действия ( в этом примере a и b ), и соединяете их стрелкой от начала до каждого узла. Далее, поскольку и c, и d указывают a как действие-предшественник, их узлы рисуются стрелками, исходящими из a . Действие e указано с буквами b и c в качестве предшествующих действий, поэтому узел e нарисован стрелками, исходящими от b и c , что означает, что e не может начаться, пока и b, и c не будут завершены . Действие f имеет d в качестве предшествующего действия, поэтому нарисована стрелка, соединяющая действия. Аналогично рисуется стрелка от e до g . Поскольку нет никаких действий, которые следуют после f или g рекомендуется (но опять же не обязательно) соединить их с узлом с меткой Finish .

Сетевая диаграмма, созданная с помощью Microsoft Project (MSP). Обратите внимание, что критический путь выделен красным.
Рано
Начинать
Продолжительность Рано
заканчивать
Имя задачи
Поздно
Начинать
Слабый Поздно
заканчивать
Подобный узел можно использовать для отображения названия действия, продолжительности, ES, EF, LS, LF и резерва.

Сама по себе сетевая диаграмма, изображенная выше, дает не намного больше информации, чем диаграмма Ганта; однако его можно расширить для отображения дополнительной информации. Чаще всего отображается следующая информация:

  1. Название действия
  2. Ожидаемая продолжительность
  3. Раннее время начала (ES)
  4. Время раннего окончания (EF)
  5. Позднее время начала (LS)
  6. Позднее время окончания (LF)
  7. слабина

Для определения этой информации предполагается, что заданы виды деятельности и нормальная продолжительность. Первым шагом является определение ES и EF. ES определяется как максимальный EF всех предшествующих действий, за исключением случаев, когда рассматриваемое действие является первым действием, для которого ES равен нулю (0). EF — это ES плюс длительность задачи (EF = ES + длительность).

  • ES для запуска равен нулю, поскольку это первое действие. Поскольку продолжительность равна нулю, EF также равен нулю. Этот EF используется как ES для a и b .
  • ES для a равен нулю. Продолжительность (4 рабочих дня) добавляется к ES, чтобы получить EF, равный четырем. Этот EF используется как ES для c и d .
  • ES для b равен нулю. Продолжительность (5,33 рабочих дня) добавляется к ES, чтобы получить EF 5,33.
  • ES для c равен четырем. Продолжительность (5,17 рабочих дней) добавляется к ES, чтобы получить EF 9,17.
  • ES для d равен четырем. Продолжительность (6,33 рабочих дня) добавляется к ES, чтобы получить EF 10,33. Этот EF используется как ES для f .
  • ES для e — это наибольший EF из предшествующих ему видов деятельности ( b и c ). Так как b имеет EF 5,33, а c имеет EF 9,17, ES e равен 9,17. Продолжительность (5,17 рабочих дней) добавляется к ES, чтобы получить EF 14,34. Этот EF используется как ES для g .
  • ES для f составляет 10,33. Продолжительность (4,5 рабочих дня) добавляется к ES, чтобы получить EF 14,83.
  • ES для g составляет 14,34. Продолжительность (5,17 рабочих дней) добавляется к ES, чтобы получить EF 19,51.
  • ES для завершения является самым большим EF из предшествующих ему действий ( f и g ). Поскольку f имеет EF 14,83, а g имеет EF 19,51, ES финиша равен 19,51. Финиш является вехой (и поэтому имеет нулевую продолжительность), поэтому EF также равен 19,51.

За исключением каких-либо непредвиденных событий , реализация проекта займет 19,51 рабочих дня. Следующим шагом является определение позднего начала (LS) и позднего окончания (LF) каждого действия. В конечном итоге это покажет, есть ли действия, которые имеют слабину . LF определяется как минимальный LS всех последующих действий, за исключением случаев, когда действие является последним, для которого LF равен EF. LS — это LF минус длительность задачи (LS = LF — продолжительность).

  • LF для завершения равен EF (19,51 рабочих дня), поскольку это последнее действие в проекте. Поскольку продолжительность равна нулю, LS также составляет 19,51 рабочих дня. Это будет использоваться в качестве LF для f и g .
  • LF для g составляет 19,51 рабочих дня. Продолжительность (5,17 рабочих дней) вычитается из LF, чтобы получить LS, равную 14,34 рабочих дня. Это будет использоваться в качестве LF для e .
  • LF для f составляет 19,51 рабочих дня. Продолжительность (4,5 рабочих дня) вычитается из LF, чтобы получить LS, равную 15,01 рабочих дня. Это будет использоваться в качестве LF для d .
  • LF для e составляет 14,34 рабочих дня. Продолжительность (5,17 рабочих дней) вычитается из LF, чтобы получить LS, равную 9,17 рабочих дней. Это будет использоваться в качестве LF для b и c .
  • ЛФ для d составляет 15,01 рабочих дней. Продолжительность (6,33 рабочих дня) вычитается из LF, чтобы получить LS, равную 8,68 рабочих дня.
  • LF для c составляет 9,17 рабочих дней. Продолжительность (5,17 рабочих дней) вычитается из LF, чтобы получить LS, равную 4 рабочим дням.
  • LF для b составляет 9,17 рабочих дней. Продолжительность (5,33 рабочих дня) вычитается из LF, чтобы получить LS, равную 3,84 рабочих дня.
  • LF для a — это минимальный LS его последующих действий. Поскольку c имеет LS 4 рабочих дня, а d имеет LS 8,68 рабочих дней, LF для a составляет 4 рабочих дня. Продолжительность (4 рабочих дня) вычитается из LF, чтобы получить LS, равный 0 рабочих дней.
  • LF для начала — это минимальный LS его последующих действий. Поскольку у a LS составляет 0 рабочих дней, а у b — 3,84 рабочих дня, LS равен 0 рабочих дней.

Следующий шаг: определение критического пути и возможных резервов

[ редактировать ]

Следующим шагом является определение критического пути и наличия резервов для каких-либо операций . Критический путь – это путь, которого занимает больше всего времени выполнение . Чтобы определить время пути, добавьте длительность задачи для всех доступных путей. Действия, у которых есть резерв, можно отложить без изменения общего времени проекта. Slack рассчитывается одним из двух способов: Slack = LF - EF или Slack = LS - ES. Действия, находящиеся на критическом пути, имеют резерв, равный нулю (0).

  • Продолжительность пути адф составляет 14,83 рабочих дня.
  • Продолжительность пути ACEG составляет 19,51 рабочих дней.
  • Продолжительность начала пути составляет 15,67 рабочих дней.

Критический путь — aceg , критическое время — 19,51 рабочих дня. Важно отметить, что критического пути может быть несколько (в проекте более сложном, чем этот пример) или что критический путь может меняться. Например, предположим, что действия d и f занимают пессимистическое (b) время вместо ожидаемого (TE ) времени. Критический путь теперь — adf , а критическое время — 22 рабочих дня. С другой стороны, если деятельность c можно сократить до одного рабочего дня, время пути aceg сократится до 15,34 рабочих дня, что немного меньше времени нового критического пути beg (15,67 рабочих дня).

Предполагая, что эти сценарии не реализуются, теперь можно определить резерв для каждого вида деятельности.

  • Начало и окончание являются вехами и по определению не имеют продолжительности, поэтому у них не может быть резерва (0 рабочих дней).
  • Действия на критическом пути по определению имеют нулевой резерв; однако всегда полезно проверять математические расчеты при рисовании от руки.
    • ЛФ а – EF а = 4 – 4 = 0
    • LF c – EF c = 9,17 − 9,17 = 0
    • LF e – EF e = 14,34 – 14,34 = 0
    • LF г – EF г = 19,51 – 19,51 = 0
  • Для деятельности b LF равен 9,17, а EF — 5,33, поэтому резерв составляет 3,84 рабочих дня.
  • Для операции d LF равен 15,01, а EF — 10,33, поэтому резерв составляет 4,68 рабочих дня.
  • Для деятельности f LF равен 19,51, а EF — 14,83, поэтому резерв составляет 4,68 рабочих дня.

Следовательно, действие b можно отложить почти на 4 рабочих дня, не задерживая проект. Аналогично, действие d или действие f может быть отложено на 4,68 рабочих дня без задержки проекта (в качестве альтернативы, d и f могут быть отложены на 2,34 рабочих дня каждое).

Завершенная сетевая диаграмма, созданная с помощью Microsoft Visio . Обратите внимание, что критический путь выделен красным.

Как избежать циклов

[ редактировать ]

В зависимости от возможностей фазы ввода данных алгоритма критического пути можно создать цикл, например A -> B -> C -> A. Это может привести к бесконечному зацикливанию простых алгоритмов. Хотя можно «отметить» посещенные узлы, а затем очистить «отметки» по завершении процесса, гораздо более простой механизм включает вычисление общей продолжительности всех действий. Если обнаружено EF, превышающее общее количество, вычисление должно быть прекращено. Стоит сохранить идентификаторы последних посещенных узлов (около дюжины), чтобы помочь определить проблемную ссылку.

Как инструмент планирования проекта

[ редактировать ]

Преимущества

[ редактировать ]
  • Диаграмма PERT явно определяет и делает видимыми зависимости (отношения приоритета) между элементами структуры декомпозиции работ (обычно WBS ).
  • PERT облегчает идентификацию критического пути и делает его видимым.
  • PERT облегчает идентификацию раннего начала, позднего начала и резервов для каждого вида деятельности.
  • PERT обеспечивает потенциальное сокращение продолжительности проекта благодаря лучшему пониманию зависимостей, что приводит к лучшему дублированию действий и задач, где это возможно.
  • Большой объем данных проекта можно организовать и представить в виде диаграммы для использования при принятии решений.
  • PERT может обеспечить вероятность завершения до заданного времени.

Недостатки

[ редактировать ]
  • Потенциально могут существовать сотни или тысячи действий и отдельных отношений зависимости.
  • PERT нелегко масштабировать для небольших проектов.
  • Сетевые диаграммы, как правило, большие и громоздкие, для их печати требуется несколько страниц и бумага специального формата.
  • Отсутствие временных рамок на большинстве диаграмм PERT/CPM затрудняет отображение статуса, хотя цвета могут помочь, например , определенный цвет для завершенных узлов.

Неопределенность в планировании проекта

[ редактировать ]

Во время реализации проекта реальный проект никогда не будет выполнен точно так, как было запланировано, из-за неопределенности. Это может быть связано с неоднозначностью, возникающей из-за субъективных оценок, которые подвержены человеческим ошибкам, или может быть результатом изменчивости, возникающей в результате неожиданных событий или рисков. Основная причина того, что PERT может предоставить неточную информацию о сроках завершения проекта, связана с неопределенностью графика. Эта неточность может быть достаточно большой, чтобы сделать такие оценки бесполезными.

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

См. также

[ редактировать ]
  1. ^ Перейти обратно: а б Келли, Джеймс Э.; Уокер, Морган Р.; Сэйер, Джон С. (февраль 1989 г.). «Истоки CPM: личная история» . Управление проектом . 3 (2). Институт управления проектами: 18 . Проверено 20 марта 2024 г.
  2. ^ Перейти обратно: а б с д и ж Керцнер 2009 .
  3. ^ Перейти обратно: а б с Бреннан, Марибет; PERT и CPM: избранная библиография , Совет библиотекарей по планированию, Монтичелло (Иллинойс), 1968, стр. 1
  4. ^ Перейти обратно: а б Малькольм, Дональд Г.; Роузбум, Джон Х.; Кларк, Чарльз Э.; Фазар, Уиллард ; «Применение метода для оценки программ исследований и разработок», Operations Research , vol. 7, нет. 5, сентябрь – октябрь 1959 г., стр. 646–669.
  5. ^ Официальный отчет Зимних Олимпийских игр 1968 года , стр. 49. По состоянию на 1 ноября 2010 г. (на английском и французском языках).
  6. ^ Министерство военно-морского флота США, исследовательская задача по оценке программы, сводный отчет, этап 1 , государственная типография, Вашингтон (округ Колумбия), 1958 г.
  7. ^ Министерство военно-морского флота США, исследовательская задача по оценке программы, сводный отчет, этап 2 , государственная типография, Вашингтон (округ Колумбия), 1958 г.
  8. ^ Уиллард Фазар цитируется по: Стаубер, Б. Ральф; Даути, Гарри М.; Фазар, Уиллард; Джордан, Ричард Х.; Вайнфельд, Уильям; и Манвел, Аллен Д.; «Федеральная статистическая деятельность» , The American Statistician , 13 (2): 9–12 (апрель 1959 г.), стр. 9–12.
  9. ^ Кук, Десмонд Л.; Техника оценки и обзора программ , 1966, с. 12
  10. ^ Мейнард, Гарольд Брайт , Справочник по деловому администрированию, 1967, стр. 17

Дальнейшее чтение

[ редактировать ]
  • Институт управления проектами (2013). Руководство к своду знаний по управлению проектами (5-е изд.). Институт управления проектами. ISBN  978-1-935589-67-9 .
  • Класторин, Тед (2003). Управление проектами: инструменты и компромиссы (3-е изд.). Уайли. ISBN  978-0-471-41384-4 .
  • Керцнер, Гарольд (2009). Управление проектами: системный подход к планированию, составлению графиков и контролю (10-е изд.). Уайли. ISBN  978-0-470-27870-3 .
  • Милошевич, Драган З. (2003). Набор инструментов управления проектами: инструменты и методы для практикующего менеджера проектов . Уайли. ISBN  978-0-471-20822-8 .
  • Миллер, Роберт В. (1963). Контроль расписания, затрат и прибыли с помощью PERT — комплексное руководство по управлению программой . МакГроу-Хилл. ISBN  9780070419940 .
  • Сапольски, Харви М. (1971). Развитие системы Polaris: бюрократический и программный успех в правительстве . Издательство Гарвардского университета. ISBN  0674682254 .
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 4b35208899cdc597ded6722e5bdb8b55__1719434640
URL1:https://arc.ask3.ru/arc/aa/4b/55/4b35208899cdc597ded6722e5bdb8b55.html
Заголовок, (Title) документа по адресу, URL1:
Program evaluation and review technique - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)