Program evaluation and review technique
The program evaluation and review technique (PERT) is a statistical tool used in project management, which was designed to analyze and represent the tasks involved in completing a given project. First developed by the United States Navy in 1958, it is commonly used in conjunction with the critical path method (CPM) that was introduced in 1957. Overview. PERT is a method of analyzing the tasks involved in completing a given project, especially the time needed to complete each task, and to identify the minimum time needed to complete the total project. It incorporates uncertainty by  making it possible to schedule a project while not knowing precisely the details and durations of all the activities. It is more of an event-oriented technique rather than start- and completion-oriented, and is used more in those projects where time is the major factor rather than cost. It is applied on very large-scale, one-time, complex, non-routine infrastructure and on Research and Development projects. PERT offers a management tool, which relies "on arrow and node diagrams of "activities" and "events": arrows represent the "activities" or work necessary to reach the "events" or nodes that indicate each  completed phase of the total project." PERT and CPM are complementary tools, because "CPM employs one time estimation and one cost estimation for each activity; PERT may utilize three time estimates (optimistic, expected, and pessimistic) and no costs for each activity. Although these are distinct differences, the term PERT is applied increasingly to all critical path scheduling." History. "PERT" was developed primarily to simplify the planning and scheduling of large and complex projects. It was developed for the U.S. Navy Special Projects Office in 1957 to support the U.S. Navy's Polaris nuclear submarine project. It found applications all over  industry. An early example is when it was used for the 1968 Winter Olympics in Grenoble which applied PERT from 1965 until the opening of the 1968 Games. This project model was the first of its kind, a revival for scientific management, founded by Frederick Taylor (Taylorism) and later refined by Henry Ford (Fordism). DuPont's critical path method was invented at roughly the same time as PERT. Initially PERT stood for "Program Evaluation Research Task," but by 1959 was already renamed. It had been made public in 1958 in two publications of the U.S. Department of the Navy, entitled  Program Evaluation Research Task, Summary Report, Phase 1. and "Phase 2." In a 1959 article in "The American Statistician" the main Willard Fazar, Head of the Program Evaluation Branch, Special Projects Office, U.S. Navy, gave a detailed description of the main concepts of the PERT. He explained: Ten years after the introduction of PERT in 1958 the American librarian Maribeth Brennan published a selected bibliography with about 150 publications on PERT and CPM, which had been published between 1958 and 1968. The origin and development was summarized as follows: For the subdivision of work units in PERT another tool was  developed: the Work Breakdown Structure. The Work Breakdown Structure provides "a framework for complete networking, the Work Breakdown Structure was formally introduced as the first item of analysis in carrying out basic PERT/COST." Terminology. Events and activities. In a PERT diagram, the main building block is the "event", with connections to its known predecessor events and successor events. Besides events, PERT also knows activities and sub-activities: Time. PERT has defined four types of time required to accomplish an activity: Management tools. PERT supplies a number of tools for management with determination of concepts, such as: Implementation. The first  step for scheduling the project is to determine the tasks that the project requires and the order in which they must be completed. The order may be easy to record for some tasks (e.g., when building a house, the land must be graded before the foundation can be laid) while difficult for others (there are two areas that need to be graded, but there are only enough bulldozers to do one). Additionally, the time estimates usually reflect the normal, non-rushed time. Many times, the time required to execute the task can be reduced for an additional cost or a  reduction in the quality. Example. In the following example there are seven tasks, labeled "A" through "G". Some tasks can be done concurrently ("A" and "B") while others cannot be done until their predecessor task is complete ("C" cannot begin until "A" is complete). Additionally, each task has three time estimates: the optimistic time estimate ("o"), the most likely or normal time estimate ("m"), and the pessimistic time estimate ("p"). The expected time ("te") is computed using the formula ("o" + 4"m" + "p") ÷ 6. Once this step is complete, one can draw a Gantt chart or  a network diagram. Next step, creating network diagram by hand or by using diagram software. A network diagram can be created by hand or by using diagram software. There are two types of network diagrams, activity on arrow (AOA) and activity on node (AON). Activity on node diagrams are generally easier to create and interpret. To create an AON diagram, it is recommended (but not required) to start with a node named "start". This <nowiki>"activity"</nowiki> has a duration of zero (0). Then you draw each activity that does not have a predecessor activity ("a" and "b" in this  example) and connect them with an arrow from start to each node. Next, since both "c" and "d" list "a" as a predecessor activity, their nodes are drawn with arrows coming from "a". Activity "e" is listed with "b" and "c" as predecessor activities, so node "e" is drawn with arrows coming from both "b" and "c", signifying that "e" cannot begin until both "b" and "c" have been completed. Activity "f" has "d" as a predecessor activity, so an arrow is drawn connecting the activities. Likewise, an arrow is drawn from "e" to "g". Since there are no  activities that come after "f" or "g", it is recommended (but again not required) to connect them to a node labeled "finish". By itself, the network diagram pictured above does not give much more information than a Gantt chart; however, it can be expanded to display more information. The most common information shown is: In order to determine this information it is assumed that the activities and normal duration times are given. The first step is to determine the ES and EF. The ES is defined as the maximum EF of all predecessor activities, unless the activity in question is  the first activity, for which the ES is zero (0). The EF is the ES plus the task duration (EF = ES + duration). Barring any unforeseen events, the project should take 19.51 work days to complete. The next step is to determine the late start (LS) and late finish (LF) of each activity. This will eventually show if there are activities that have slack. The LF is defined as the minimum LS of all successor activities, unless the activity is the last activity, for which the LF equals the EF. The LS is the LF minus the task duration  (LS = LF − duration). Next step, determination of critical path and possible slack. The next step is to determine the critical path and if any activities have slack. The critical path is the path that takes the longest to complete. To determine the path times, add the task durations for all available paths. Activities that have slack can be delayed without changing the overall time of the project. Slack is computed in one of two ways, slack = LF − EF "or" slack = LS − ES. Activities that are on the critical path have a slack of zero  (0). The critical path is "aceg" and the critical time is 19.51 work days. It is important to note that there can be more than one critical path (in a project more complex than this example) or that the critical path can change. For example, let's say that activities "d" and "f" take their pessimistic (b) times to complete instead of their expected (T) times. The critical path is now "adf" and the critical time is 22 work days. On the other hand, if activity "c" can be reduced to one work day, the path time for "aceg" is  reduced to 15.34 work days, which is slightly less than the time of the new critical path, "beg" (15.67 work days). Assuming these scenarios do not happen, the slack for each activity can now be determined. Therefore, activity "b" can be delayed almost 4 work days without delaying the project. Likewise, activity "d" or activity "f" can be delayed 4.68 work days without delaying the project (alternatively, "d" and "f" can be delayed 2.34 work days each). Avoiding loops. Depending upon the capabilities of the data input phase of the critical path algorithm, it may be possible to create a  loop, such as A -> B -> C -> A. This can cause simple algorithms to loop indefinitely. Although it is possible to "mark" nodes that have been visited, then clear the "marks" upon completion of the process, a far simpler mechanism involves computing the total of all activity durations. If an EF of more than the total is found, the computation should be terminated. It is worth saving the identities of the most recently visited dozen or so nodes to help identify the problem link. As project scheduling tool. Uncertainty in project scheduling. During project execution, however, a real -life project will never execute exactly as it was planned due to uncertainty. This can be due to ambiguity resulting from subjective estimates that are prone to human errors or can be the result of variability arising from unexpected events or risks. The main reason that PERT may provide inaccurate information about the project completion time is due to this schedule uncertainty. This inaccuracy may be large enough to render such estimates as not helpful. One possible method to maximize solution robustness is to include safety in the baseline schedule in order to absorb the anticipated disruptions. This is called  proactive scheduling. A pure proactive scheduling is a utopia; incorporating safety in a baseline schedule which allows for every possible disruption would lead to a baseline schedule with a very large make-span. A second approach, termed "reactive scheduling", consists of defining a procedure to react to disruptions that cannot be absorbed by the baseline schedule.