Content deleted Content added
No edit summary Tags: Visual edit Mobile edit Mobile web edit |
Delete "already" and ", however," |
||
Line 19:
[[File:PERT Summary Report Phase 2, 1958.jpg|thumb|upright|''PERT Summary Report Phase 2'', 1958]]
Initially PERT stood for ''Program Evaluation Research Task,'' but by 1959 was
{{Quote|Through an electronic computer, the PERT technique processes data representing the major, finite accomplishments (events) essential to achieve end-objectives; the inter-dependence of those events; and [[Estimation (project management)|estimates]] of time and range of time necessary to complete each activity between two successive events. Such time expectations include estimates of "most likely time", "optimistic time", and "pessimistic time" for each activity. The technique is a management control tool that sizes up the outlook for meeting objectives on time; highlights danger signals requiring management decisions; reveals and defines both methodicalness and slack in the flow plan or the network of sequential activities that must be performed to meet objectives; compares current expectations with [[Schedule (project management)|scheduled]] completion dates and computes the probability for meeting scheduled dates; and simulates the effects of options for decision — before decision.<br />The concept of PERT was developed by an operations research team staffed with representatives from the Operations Research Department of [[Booz Allen Hamilton]]; the Evaluation Office of the [[Lockheed Martin Space Systems|Lockheed Missile Systems Division]]; and the Program Evaluation Branch, Special Projects Office, of the Department of the Navy.<ref name="SDFJWM 1959">[[Willard Fazar]] cited in: B. Ralph Stauber, H. M. Douty, Willard Fazar, Richard H. Jordan, William Weinfeld and Allen D. Manvel. "[https://www.jstor.org/stable/2682310 Federal Statistical Activities]." ''The American Statistician'' 13(2): 9-12 (Apr., 1959) , pp. 9-12</ref>}}
Line 223:
=== Uncertainty in project scheduling ===
During project execution
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.
|