I think one of the best lines from Indiana Jones and the Last Crusade (1989) occurs fairly early on in the movie, when a teenaged Indiana Jones emerges from a pirate archaeological site expecting to see the boy scout troop with whom he had arrived, only to see nobody at all, and blurts out “Everybody’s lost but me!” It’s similar to a meme I’d seen previously, along the lines of everybody who drives slower than me is an idiot, and those faster than me are maniacs. Using yourself as the baseline for the frame of reference with which others are evaluated is part of human nature, I suppose, but it does have implications for the management sciences, particularly PM.
In a blog from last month I asserted that a precise and comprehensive codex of how Project Management ought to be conducted is elusive, due to the broad nature of the kinds of work that fall under the PM rubric. I also pointed out by way of contrast that this is very different for our friends, the Accountants, whose Generally Accepted Accounting Principles (GAAP) are specific and comprehensive, able to address almost all scenarios involving quantifying and managing assets. Given that we PM-types are bereft of a codex that could come close to addressing almost all (or even a plurality) of the scenarios we face, what should serve as the basis for reliable analysis and decision-making where the PMBOK Guide® is lacking, or even silent?
Before I take on that question, I wish to discuss what we should not do. We should not arrive at the Project Team technical issues eval meeting with an attitude of “everybody’s lost but me.” Human nature or not, using one’s education and experience as the nominal baseline for evaluating potential strategies going forward is always going to be a risky proposition. Part of the very basis of intelligence is the ability to encounter novel situations, remember a (validly) analogous previous situation, and derive an approach to the new one based on what worked in the previous circumstances, or avoiding a known failed strategy. But when it comes to working out a technical approach on a project, given that projects are, by definition, unique ventures, everybody on the Project Team is likely to have in their experience database some event that they believe to be analogous to the present one, but virtually none of them will have the same event in mind.
Then we have those outside the Project Team, but are nonetheless weighing in on things like the appropriate technical approach. I’m referring here to consultants who, for the reasons stated above, might not only fail to advance the Project’s technical agenda, but could even detract from it. One of the first things they teach you in auditor’s school is that you never walk into the target organization/Project Team and just start carping about things being done in a way you don’t like. If you are going to issue any kind of finding at all, it must be (a) something that’s objectively (any other person can observe) going on, (b) is in direct violation of a specific rule, procedure, regulation, etc., and (c) attachable to the exact date/time/circumstances of the observed alleged violation to the exact rule, procedure, regulation, etc. being transgressed. I think this basic rule is used to avoid the very phenomena of an auditor waltzing into the middle of the target organization and starting with the whole “everybody’s lost but me” business.
So, if that’s the approach to be avoided, which is to be embraced? Well, for that I’ll point to the character of Mr. Spock, from Star Trek. Spock is a Vulcan, a people whose entire basis for interacting with reality is based on a mastery of logic. Back here on Earth, the practice of engaging logic in the pursuit of analyzing the nature of these novel situations has consistently shown itself to maximize the odds of identifying the true nature of things, and informing the selection of workable (or even optimal) strategies to attain a solution. To illustrate what I’m talking about, I can’t recall a single instance where Mr. Spock draws a conclusion or makes a recommendation based on his educational background, or widely-perceived superior intelligence, and I’ve watched a lot of Star Trek (the original series – not so much the following stuff). Conversely, a person could read hundreds of pages of auditors’ or consultants’ findings/corrective action requests, and not see a single solitary reference to an academic study, or even refereed professional journal article. They will point to verifiable facts (the WBS Dictionary has a different title for Activity 1.4.3.2 than what appears in the Schedule Baseline), but then draw not-entirely-plausible conclusions from that little factoid (…showing a profound lack of Scope and Schedule Baseline integration).
The solution, of course, is to conduct the analysis of the Project’s central technical challenge in such a way as to reduce each of the assumptions to basic premises, which can be verified objectively or, at the very least, widely agreed to and supported. Place these premises into a valid logical structure, i.e., one that can be Venn diagrammed. If a known-successful approach is to be furthered, make sure that that success was based on a strongly analogous piece of scope.
Otherwise, you’ll be lost … and illogical.




Community Champion