# Talk:Program evaluation and review technique

## Two of a kind

There are two kinds of PERT diagrams. One is the sort shown in the article, which has nodes denoting stages of the project and arrows denoting tasks. The other sort, which I did at college, has nodes denoting tasks and arrows denoting the dependencies between them. The nodes tend to be shown as boxes with task information in them - there are various formats, one of which is like this

 Do something 14 3 17 19 5 22

where the boxes are

 Task description early start duration early finish late start slack late finish

(I'm not sure if the "early finish" and "late start" boxes were this or the other way round.) -- Smjg 16:14, 31 Mar 2005 (UTC)

[PDG] My long standing question is WHY are the early start and early finish dates invariably shown ABOVE the late start and late finish dates, when in fact, this makes no sense mathematically as we are supposed to DEDUCT the early dates FROM the late dates, resulting in the Total Float (or Total Slack) Thus what is shown here is logically exactly opposite and thus counterintuitive to what should be.

BR, Dr. PDG, Jakarta Dr PDG (talk) 08:38, 27 October 2008 (UTC)

I always thought that one of the major, long-term contributions of PERT for those estimating completion times for complex tasks involving the interaction of many different tasks of many different types from many different sources was the concept of lead time.

The Wiki-article Lead time makes no mention of PERT as the term's point of origin.

Also, it seems very puzzling to me that most are speaking of lead time as if it means "the time taken to produce some manufactured article"; where, according to how I always understood its meaning, application, and implication was that the "lead time" for a particular event was the amount of time before a specific point in time that one would have to commence the activities that would generate the event in question by that designated "point in time".

Thus, the "lead time" means something very significant, and something rather like "the time one commence activity in advance of an event in order for the event to occur at X point in time".

Therefore, it does not (and can not) mean what seems to to be an identical, polar-opposite meaning -- which is very different, entirely wrong, utterly misrepresenting, and totally bereft of the wonderful utility of the term's correct application -- that we see in much of the usages: i.e., something like "the earliest time in the future that an event can occur if we start now" (rather than the correct version, "the latest we can start work, so that we will have the product in our hands on date D at time T).

I feel that there should be:

(a) some significant piece about "lead time" in the PERT article; and
(b) once that is settled, appropriate changes also made to the Lead time article.

Although I may have my wires crossed, I have always thought that "lead time" was the amount of time that had to "lead" or come before the event (and that this was why it was used in the planning and setting up events and processes so that they would finish by a particular date, such as the opening ceremony of the Olympic Games); rather than it being the amount of time beyond this moment that we could expect a finished product to turn up. Can anyone clarify this for me? Lindsay658 04:22, 17 July 2006 (UTC)

Dbsheajr. I hope that what I have added assists. Please feel free to alter it in any way that better suits what you are adding to the remainder. Best to you Lindsay658 05:08, 25 July 2006

The figure seems to be a color-ized version of diagram shown at NetMBA, but with the NetMBA logo removed.

http://www.netmba.com/operations/project/pert/ —Preceding unsigned comment added by Joelwest (talkcontribs) 03:03, 11 March 2009 (UTC)

Except that they're completely different? What am I missing? Kuru talk 03:16, 11 March 2009 (UTC)

## PERT and its Origin - Mary Poppendieck's take on the matter at a Google Tech Talk in '08

Have a look at http://www.youtube.com/watch?v=ypEMdjslEOI and have Mary Poppendieck, at a Google Tech Talk, amongst other things tell you about the origins of PERT (starting at 25:14) as a smoke screen for congress to keep funding the cold war weapons program (it is easier to fund a control strategy than people doing something). —Preceding unsigned comment added by 93.132.94.115 (talk) 17:22, 30 May 2009 (UTC)

## Uncertainty in project scheduling

What does this phrase mean "include safety in the baseline schedule"? Are we talking about padding estimates? Please define "safety" in reference to a schedule.

What is a "a very large make-span"? Is that a typo for "time-span"? Is make-span a term of art in PERT lingo?

These two terms are unfamiliar to me, and I've worked with PERT charts and project management. —Preceding unsigned comment added by 24.19.105.40 (talk) 16:53, 11 December 2009 (UTC)

## Who invented Pert

A citiation is needed on the inventors, I found this citation, but I have no access to the article to confirm PERT as an Analytical Aid for Program Planning—Its Payoff and Problems J. W. Pocock Booz Allen Applied Research, Inc., Chicago, Illinois Wakelamp (talk) 06:13, 16 April 2010 (UTC)

John H. Roseboom asserts that he was a member of the original PERT team in his letter to the editor of OPERATIONS RESEARCH (Vol. 9, No. 6, November-December 1961, pp. 909-910). This would seem to be supported by the original paper on the development of PERT authored by D. G. Malcolm, J. H. Roseboom, and C. E. Clark of Booz, Allen and Hamilton; and W. Fazar of the Special Projects Office, U.S. Navy (OPERATIONS RESEARCH Vol. 7, No. 5, September-October 1959, pp. 646-669). But since I can find no secondary source for this, it is probably not appropriate for the article. 69.1.23.134 (talk) 17:01, 22 January 2011 (UTC)

## Is Program Evaluation and Review Technique a proper name?

I think "program evaluation and review technique" is a common name not a proper name and therefore should not be capitalized. I know it is accepted practice in the industry to capitalize terms especially when they are normally identified by acronym but in Wikipedia capitalization is used only for proper names. Jojalozzo 15:56, 14 August 2011 (UTC)

It is clear from the "historical" piece I have just added that "Program Evaluation and Review Technique " is a tool, and therefore, a noun, rather than "an approach", and therefore a verb. And, moreover, it is not a "common name"; it is a very specific "proper noun". Therefore it should remain capitalized. The point being, I suppose, no matter how many people habitually call Bison bison "buffalo", the animals continue to remain bison.Lindsay658 (talk) 23:21, 14 August 2011 (UTC)
PERT is a technique, method or approach. A PERT chart is a tool. Whether we use the name bison or buffalo we do not capitalize it. None of this is convincing me that program evaluation and review technique is a proper name. Jojalozzo 02:45, 15 August 2011 (UTC)
Also, Program Evaluation and Review Technique is capitalized in a reference to it in U.S. patent no.3124885.Lindsay658 (talk) 23:43, 14 August 2011 (UTC)
Wikipedia capitalization is governed by its own rules: summed up as "avoid unnecessary capitalization". Usage in patents or in the industry does not change this. Jojalozzo 02:45, 15 August 2011 (UTC)

I started a discussion of the general topic of naming ideas in engineering at the Village pump. Jojalozzo 16:14, 15 August 2011 (UTC)

## Removing bad characters from the block quote

Why is the user Herr Beethoven reverting edits that remove spaces from the block quote? — Preceding unsigned comment added by 192.91.172.36 (talk) 00:08, 29 September 2011 (UTC)

Very strange. Browsing through the history shows that this happens fairly frequently. A user cleans up the broken words in the block and another user reverts the edit. What is the underlying rationale? 192.91.172.36 (talk) 00:16, 29 September 2011 (UTC)

## File:Pert example gantt chart.gif Nominated for speedy Deletion

 An image used in this article, File:Pert example gantt chart.gif, has been nominated for speedy deletion for the following reason: Wikipedia files with no non-free use rationale as of 3 December 2011 What should I do? Don't panic; you should have time to contest the deletion (although please review deletion guidelines before doing so). The best way to contest this form of deletion is by posting on the image talk page. If the image is non-free then you may need to provide a fair use rationale If the image isn't freely licensed and there is no fair use rationale, then it cannot be uploaded or used. If the image has already been deleted you may want to try Deletion Review This notification is provided by a Bot --CommonsNotificationBot (talk) 11:55, 3 December 2011 (UTC)

## Harold Kerzner chapter on PERT

Embarassing typo in the 10th edition, p. 502: "Since there exists only one path through the network that is the longest, the other paths must be either equal in length to or shorter than that path." — Preceding unsigned comment added by 129.199.97.130 (talk) 08:49, 19 March 2015 (UTC)

## Implementation Error

The last diagram in the Implementation system fails, as it does not list the slack/float times to the left and right of the task names as is common practice in the project management community. Without this information, it is difficult to determine the critical path. With this information, the critical path(s) (yes, there can be more than one) are those blocks (activities) where the slack/float time is zero. 75.70.164.249 (talk) 06:39, 6 November 2015 (UTC)