Waaaaayyyyy before PMI® became a professional association in 1969[i], many large-scale, complex projects were being successfully completed on-time, on-budget, by managers who had an extremely advanced grasp of the field of PM, even if they didn’t articulate their understanding in terms we use today. I could be wrong about this – any day now the Construction Office chamber of the Great Pyramid could be discovered and accessed, with the schedulers still waiting for their early-version Critical Path Methodology software to complete a forward and backward pass on their 20,000-activity network. But my speculation is that these historic PMs would do things like assign a higher priority to time-critical tasks without invoking the term “crashing the schedule.” I’m also fairly certain that, prior to 1823 and Carl Friedrich Gauss’ publication of the monogram Theoria combinationis observationum erroribus minimis obnoxiae, PMs were quite aware of many of the things that could go wrong with their projects, they just didn’t document them with some statistical speculations of their odds of occurring in a “risk register” (no initial caps here, either).
Once PMI® did come into existence, and much of its approach to the management sciences took on a scholastic flavor, the lexicon not only became standardized, it became a bit more academic, a function of applying its wide range of theories across multiple industries. PMs working the American Interstate Highway system in 1958 may have had little in common with those working in the nascent National Aeronautics and Space Administration (NASA), but managers in both organizations would have instinctively known that some activities would have to be completed before others could actually start, and that comparing those activities’ percent complete to their cumulative spent cost and schedule could give them a pretty good idea of how much their work would cost at completion, and how long it would take. They would have understood the basics of schedule logic and cost/schedule performance indicators, even if they didn’t use those exact terms.
And therein lies a problem: many in PMI® today have come to the practice of Project Management on scholastic or theoretical terms, while many others have arrived with a boots-on-the-ground understanding of its precepts. This latter approach is how I swerved into PM. I was working for a Department of Defense contractor that was building a type of advanced communication system. The design and development of this system came with a myriad of research deliverables and design reviews that were described in a document known as the Contract Deliverables Requirements List, or CDRL. Trick was, these deliverables’ due dates weren’t firmly established. They were almost always described as being 90 or 180 days after some other deliverable was submitted, or 30 days prior to one of the design reviews. My title at the time was “Data Manager,” and it was my job to “coordinate” the development of all of these deliverable documents, oversee their progress, and transmit them to their far-flung recipients on-schedule. At the time personal computers were something of a novelty, but I had one in my office, running one of the earliest spreadsheet packages, Lotus 1-2-3. So, I went through the CDRL, one entry at a time, and in the cells I had labeled “Due Date,” would place the equation to add 90 (or whatever) days to that deliverable’s predecessor’s end date. Without having been taught what a finish-to-start link was, or the term “lag,” I ended up constructing a Critical Path network that would automatically re-calculate a myriad of Start and Finish Dates based on the values that were placed into the Today’s Date field, and whichever Review date was considered reliable. It wasn’t until the Project Controls Analyst on this project saw what I was doing, and told me that I should look in to the Project Management profession that I had any idea that that’s what I had been doing all along.
So, back to the communications gap. Having spent a lot of time around construction and manufacturing PMs, as well as their Agile/Scrum counterparts, I realize they’re discussing the same ideas, just using a different lexicon. So, as a service to GTIM Nation members who may find themselves in a situation where they have to serve as a translator between the Practical and Scholastic-oriented PMs, I offer the following conversion table.
|
Practical |
Academic |
|
“He’s got a fish in one hand, and a $#!^ in the other.” |
“That CAM is in a very poor position to realize his goals.” |
|
“I don’t care if those guys sitting around are assigned to something else – get them to help over there.” |
“We may have to pull resources from the non-critical activities, and assign them to this other task.” |
|
“You never know, we could all be run out of here tomorrow.” |
“The resource requirement profile for this project is highly uneven.” |
|
“I had a feeling this might happen.” |
“There’s an entry in the risk register for this event.” |
|
“I’m pretty sure we can fix it on the flip side, without much fuss.” |
“We need to prepare a zero-cost Baseline Change Proposal, and get it in front of the BCCB ASAP.” |
|
“If you’ll stop talking, I’ll give you the right answer.” |
“We should abandon the current technical approach, in favor of this alternative.” |
This is far from an exhaustive list, but it will suffice for now.
Or, there’s more, but I’m done.
[i] https://www.pmi.org/about/learn-about-pmi/founders



