Project Management

When Did a priori Become A Priority?

From the Game Theory in Management Blog
Modelling Business Decisions and their Consequences

About this Blog


Recent Posts

Munchkin Project Management

How Far Away Are We From PM Robots?

Is It Standard, Or Is It Quality?

You Can Be Creative, But Don’t Be Dumb

Finally! A Use For Risk Management!

For those of you in GTIM Nation who are used to my writing direct, immediately-usable strategies for better project execution, or team cohesion, or shotgun blasts against what I perceive as management pathologies, I must request some patience. I’ll get to that kind of stuff after the next 400 words or so, but I must first take a detour into, what I’m sure will strike many as, a more theoretical, philosophical bent. But, if you stay with me, I’m pretty confident I can make it worth your blog-consuming while.

Referring back to this blog’s title – what does a priori mean? According to Merriam-Webster online[i], it’s “relating to or derived by reasoning from self-evident propositions,” and “presupposed by experience.” I was reminded of this term recently when I was looking into the concept of interface management, and my internet search turned up an article in the Project Management Quarterly, from 1979 (!). The article, “Interface Management – an organization theory approach to project management”[ii] is chock-full of a priori assertions, which isn’t necessarily a bad thing in and of itself. I think what I find frustrating about this particular article is the overuse of inchoate but impressive-sounding assertions, none of which are verifiable through observation, or even falsifiable (which Karl Popper would probably argue renders it outside of the scientific method, even if we ARE talking Management Science). Some of the gems include:

  • “Tight control of dynamic interfaces is essential to achieving project cost, schedule and scope targets.”[iii]
  • (two bullets later) “Organizational factors should not be allowed to inhibit required project integration.”[iv]
  • “Systems management is a key systems concept.”[v]

And those are just on the first page. Let’s take a look at these one at a time, shall we?

  • We learn later in the article that a “dynamic interface” is a communication among stakeholders in the project, or even within the Project Team, that are other than “static.” This differentiation appears to hinge on whether or not the communication is regular and consistent, or ad-hoc and unpredictable. Just how are these interfaces to be “tight(ly) controlled?” Is the PM to sneak around the Project Team’s offices, waiting for one of them to contact a sub-contractor with some unauthorized question, and pounce if and when such an interface occurs? Also, how is this falsifiable? Could a Karl Popper aficionado approach this author after the fact, and state (with a straight face) “I successfully achieved my project’s cost, schedule, and scope targets, and I made no effort at all at controlling the dynamic interfaces, much less tightly. I insist you retract your thesis that such ‘control’ is ‘essential!’”?
  • This notion that PM implementation strategies exist in the pure ether of a universe that allows only the mathematical and provable aspects of management science is just plain dopey. Management takes place in a world of people – real people – who will inevitably manifest some sort of organization behavior and performance pathology in any group they create. It’s just the way things are in the real world. If your PM strategy crashes and burns, and your best deflection tactic is to blame the “organizational factors,” then your strategy was poorly formulated from its inception. As I have pointed out in multiple previous blogs (usually, but not always, citing the excellent Michael Maccoby’s book The Gamesman), the “organizational factors” are part of the managerial landscape. Ignoring them, and then blaming them ex post facto for your failure to derive an appropriate management strategy is simply disingenuous.
  • Okay, this last bullet is a simple tautology. I included it because it bugged me.

But the thing that these key assertions all have in common is that they are a priori assertions. None of them is verified (or even verifiable) through direct observation. I’m not just picking on this particular author (even though he is a Ph.D.) – this sort of supporting argumentation for furthering certain ideas about Project Management is, unfortunately, rather common. Examples include:

  • The idea that “bottoms-up Estimates at Completion” need to be performed regularly,
  • Critical Path schedule networks are rendered weaker by an excess of start-to-start relationships among activities,
  • All stakeholders must be engaged,
  • As well as almost the entire codex of risk management theory,

…and this is just a short list.

My solution? Outright rejection of all PM hypotheses that are not falsifiable is probably a bit extreme. I would settle for an honest re-examination of the non-falsifiable ideas that made it all the way into the PMBOK Guide®.

And for real-world PMs: take with a huge grain of salt any a priori assertion about the way you “should” or “must” do Project Management. If the one pushing the analysis technique can’t point to real-world examples of how his approach worked, then it probably doesn’t belong in the real world.




[i] Retrieved from on 15 June 2019, 20:29 MDT.

[ii] Morris, P. W. G. (1979). Interface management—an organization theory approach to project management. Project Management Quarterly, 10(2), 27–37.

[iii] Ibid.

[iv] Ibid.

[v] Ibid.

Posted on: June 16, 2019 10:43 PM | Permalink

Comments (4)

Please login or join to subscribe to this item
Very interesting, thanks for sharing

Just be sure to complete your degree or pass the PMP before you start challenging our our favorite project management assertions! Professors and exams don't care for your defiance.

Thanks for this. I like the idea of using 'real world' exemplars on projects as these can be referenced, checked and learned from

Please Login/Register to leave a comment.


"Smoking is one of the leading causes of statistics."

- Fletcher Knebel