“Most Projects Most of the Time” Makes Little Sense
I am of the firm opinion that the conventional wisdom with respect to how to manage projects, which is proclaimed by its proponents as being aimed at “most projects most of the time,” is not particularly well suited for the Construction Industry. I find the entire idea of a general set of guidelines, principles, and best practices to explain the broad landscape of Project Management (across all industries) to be about as useful as a culinary institute issuing a set of guidelines, principles, and best practices intended for “most meals most of the time.” There is a world of difference between a Texas barbeque and a Manhattan banquet, between a steakhouse and a pancake house, between breakfast and dinner. Some foods are hot, some cold; some soft, others crispy; some tangy, some sweet.
It seems to me that the broader the scope of any topic, the less specific must be any recommendations, if they are to be meaningful. If someone is giving advice for “most meals most of the time,” the recommendations would necessarily have to be quite general, along the lines of, “make sure cold foods arrive at the table cold, and (ahem…) hot foods arrive at the table hot.” Or, “make sure your kitchen is sanitary.”
This article ponders the value of a “most projects most of the time” approach to Project Management standards, guidelines, and best practices when they fail to get down to the nuances of each specific industry. Even within a single industry, can any set of standards, guidelines, and best practices ever be sufficiently relevant to a single project such that one need only follow the outlined steps and, voila, a successful project will result? Of course not. And I doubt that any of the authors of those international standards, guidelines, or best practices would argue that such guidance would necessarily work in every instance, every application.
Fair enough, I say. But doesn’t that beg the question: for someone not adequately knowledgeable or experienced (someone seeking guidance in the first place), how would they know which standards, guidelines, and best practices to follow, and which to ignore? This is not some rhetorical question intended merely to set up this article. Rather, it speaks to a very real problem in the Construction Industry. With each passing year, we see increasing numbers of novice Project Managers, settling into their roles for the first time, who compensate for their lack of any substantial project management experience by meticulously adhering to published standards, guidelines, and best practices. And therein lies a major challenge confronting the Construction Industry.
One Size Does Not Fit All
When it comes to the Project Management solutions being advocated today, while they clearly differ in what they recommend, most are generally the same in at least one respect: they present themselves as likely to be beneficial and applicable across virtually all project types and circumstances. One leading Project Management authority even goes as far as to use the expression, “most projects most of the time.”
I am not saying that none of these Solutions have merit or application. What I am saying is that no one of them is the entire answer, or could ever be the great panacea. Each so-called solution has its strengths and weaknesses; therefore, each must have certain practical limitations. The key is to understand what each is best (or worst) at, to learn how to choose between them and then to skillfully implement a particular solution that is best for the particular project at hand.
Mixed up in the challenge of the previous paragraph is the challenge of finding out how to accommodate differences among Project Partcicipants. As I see it, those differences exist along three axes.
- Range of Objectives Axis: Such objectives differ by Project Stakeholder.
- Range of Values and Beliefs Axis: These differ with respect to the various objectives.
- Range of Implementation Options Axis: Different ways to achieve values and beliefs.
Objectives, Values & Beliefs, and Implementation
Here is where things start to get really interesting, because each of those axes represents a wide ranges of choices, from one extreme to the other.
- Objectives: Project Stakeholders inherently and intuitively hold certain Objectives more sacrosanct than others. A constant barrage of daily decisions are taken in recognition of, and in response to, a broad spectrum of practical objectives and priorities, such as: cost, time, contract, resources, harmony, quality, etc. And each Project Stakeholder will arrange these Objectives in a different order of priority.
[Note: In the jargon of the Cognitive Project Management T.I.M.E. Framework,* Objectives belong in the realm of what we call Project Ecology, the operational context in which Project Management operates. All successful Project Management begins by fully understanding the conditions and circumstances under which the Project will be performed.]
- Values and Beliefs: These are not two synonymous words. Values have to do with what we most treasure, while Beliefs have to do with what we think will best deliver those Values. For instance, Bill and Jerry both value financial security; they share the same Value. But Bill believes that staying loyal to a single employer for as many years as possible is the best way to insure job stability which, in turn, reinforces financial security. Jerry, however, believes that progressively jumping from company to company, each time landing on a higher rung on his career ladder, is the smartest way to financial security. Same Values, different Beliefs.
How this relates to Project Management in general (and Project Time Management, in particular) is that different Project Stakeholders can value the same Project Objectives and yet have very different beliefs at to how to achieve them. As just one example, some Project Managers believe that a tight Command-and-Control approach to Project Management is the best (some even think, only) way to insure that Project Objectives are successfully achieved. Other Project Managers believe in giving their subordinates more autonomy and opportunities for self-determination and self-correction.
[Note: In the jargon of the Cognitive Project Management T.I.M.E. Framework,* Values and Beliefs are key Project Ideology factors. Each performing organization has its own operational culture to start with. This foundational management climate must be tempered and modulated based on the insights gained from diagnosing the Project Ecology.]
- Implementation: Finally, there are very real and significant differences in how we bring our Beliefs to life. To use the terminology of the Cognitive Project Management T.I.M.E. Framework,* Implementation calls for the application of Project Methodology and Project Technology. In the area of Project Time Management, for example, I happen to think of Work Breakdown Structure (WBS) as a Methodology, while Earned Value and CPM are Technologies.
- Others may disagree, but let us not get distracted over where the line should be drawn between what is Methodology and what is Technology. It matters less what label you slap on it: the thing that Methodology and Technology have in common is that they both define approaches to the manifestation of those Beliefs that we just discussed. Implementation is where “the rubber meets the road,” as the expression goes.
For the sake of clarification, the Cognitive Project Management T.I.M.E. Framework* distinguishes Methodology from Technology this way:
- Methodology: Only after important Ideological decisions have been reached can or should Project Management Methodologies be selected and tailored to the specific project.
- Technology: The final puzzle piece is the technical infrastructure of project management, one that is compatible with the Project Ideology, and supportive of the Project Methodology
The Variability of Project Management and the Projects they Manage
Much has been written over the years about the variability of projects: by type, size, length, cost, schedule, players, regulations, owners, industry, etc. What I find so surprising is just how little has been written about the variability of Project Management! Please don’t miss my point! You may be think that I am suggesting that since projects are diverse so must be the management of those projects. Well, that is a valid conclusion, and one that I will return to shortly. But that is not the point I am trying to make right now.
Right now, I am struggling to find the words to adequately highlight the exponentially mind-boggling number of combinations of Objectives, Values, Beliefs, and Implementation options that are, at once, in tension and conflict on any given project. Did you read those last four words? On any given project!
What I am pointing out is that on a single project there are countless different ways to structure a Project Management Solution … depending on the choices of Objectives, Values, Beliefs, and Implementation Preferences of the particular Project Management Team involved. Change the membership of the Project Team and you change the possible combinations of options. We only compound the challenge when we consider that, by definition, no two projects are the same!
And so, the very same Project Team, can (and almost certainly will) have a different combination of Objectives, Values, Beliefs, and Implementation Preferences for each different project they are charged with managing. When you factor just these three considerations against one another, the possible combinations are virtually limitless. Now appreciate that along each axis there is a wide range of choices, from one extreme to the other. What you end up with is an exponentially impossible spectrum of options to choose from.
Why Project Management’s Conventional Wisdom Fails Us
Hopefully the above heading is already obvious to you. Hopefully .. but not likely. Why am I so skeptical? Because the dogma of Dominant Project Management** thinking has been so indoctrinated into mainstream Project Management teaching and writing, so regulated and so certified, that any challenge of the Conventional Wisdom is immediately condemned as blasphemy. Well, last night on NCIS, Gibbs told a the wife of a murdered Naval Officer, “Just because he was paranoid doesn’t mean he wasn’t being followed.” Likewise, just because I am a heretic doesn’t mean that what I have to say has no merit whatsoever. (I am not easily silenced).
What I believe to be wrong with the Conventional Wisdom is its rigidity, its absoluteness, its “one size fits all” attitude. My critics, its advocates, will be quick to point out that within mainstream Project Management literature are any number of caveats about how standards and best practices and recommended practices are all “frameworks” that can, and should, be modified for the particular situation. Yes, I admit that most of the more credible documents do include such qualifiers.
However, those invitations to modify only apply at the Technological or Methodological level. They do not extend to the Ideological level, and they rarely acknowledge the existence of Ecological factors. It seems to me that Dominant Project Management adopts a “function follows form” approach to Project Management.
For example, someone new to Project Management (perhaps someone who has just been assigned the role of Project Manager for the first time) starts their learning curve by Googling the term “Project Management.” In less than a second they are confronted with scores of Project Management Certification Training courses. Without naming names, in the United States one particular Project Management model corners the market. (Of course — and this is part of the global problem – elsewhere in the world other Project Management models dominate.)
But let’s stay here in North America. The new Project Manager quickly learns that Project Management divides into nine “Knowledge Areas.” This is good to know, she thinks. So she orders some reading materials from Amazon.com. It doesn’t seem to matter who the author is; they all seem to be preaching the same Ideology and, to a good extent, the same Methodology. And so, on this project over which the novice Project Manager presides, a Project Management system is gradually crafted, based on what she is reading. This is why I say that this amounts to “function follows form.”
Construction Project Management Is a Laminate
As it turns out, management of construction projects calls for an Ideology that radically differs from the Conventional Wisdom. For starters, the Dominant Project Management is based on a Command-and-Control ideology. Yet most successful construction projects depend on a fair amount of delegation, partnership, diplomacy, flexibility, and open communication. While the Project Manager may be the Top Dog on the org chart, in reality very few truly successful Project Managers apply a “fist-pounding, my-way-or-the-highway” approach to Project Management. [By contrast, Cognitive Project Management** boils down Project Management to Coordination, Collaboration, Cooperation, and Communication.]
Often misunderstood about Construction Project Management is that the Management “layer” is actually a laminate. That is, there are layers to the Management layer.
Owner’s Project Manager: The Project Owner has appointed an individual to act as Project Manager, who represents the interests of the Owner.
- Construction Manager’s Project Manager: If the Project Owner has also retained the services of a Construction Management or Owner’s Representative firm, this organization also appoints its own Project Manager.
- Architect’s Project Manager: Surely the Architect has an individual designated as its Project Manager. So, does each of the key consulting engineers: Structural Engineer, Civil Engineer, Mechanical Engineer, etc.
- General Contractor’s Project Manager: The General Contractor has a Project Manager and often a General Superintendent to manage field operations.
- Subcontractor’s Project Manager: Each of the key subcontractors has someone designated as their “point man” on the project.
So when we speak of “Project Manager” we are talking about a lot of individuals with the same responsibilities, if not also the same title. The significant difference, of course, is that each Project Manager comes to the Project with different Objectives, different Values and Beliefs and (this is where things get really sticky) different Implementation Strategies. What successful Construction Project Managers have come to realize, through Hard Knocks, is that more is gained through compromise and fairness than through autocratic rule. But the Convention Wisdom of the Dominant Project Management is all about control: Cost Control, Time Control, Quality Control … even Project Control!
And so, our novice Project Manager sets up a Project Management Office (PMO), she writes a lot of recommended best practices, organizes her files (and her day) according to Knowledge Areas and then … all hell breaks loose! She tries to pin the players down to a single WBS, but gets push back. She tries to appease the Finance folks, but gets resistance from the field. Contracts and Procurement have informational needs from the Schedule, but the Superintendent and Subcontractors are determined not to contribute. Game on!
No One Simple Solution
Cognitive Project Management** was built from the inside out. That’s because we think that, under the Dominant Project Management model, the tail is wagging the dog. By contrast, we started by asking the Field (Superintendent and his subs) what they needed and wanted, information-wise in order to effectively prosecute the scope of work of the project. And then we built Methodology and Technology to suit. This returns to the more natural “form follows function,” as it should be.
And should have been all along.
Cognitive Project Management approaches Construction Project Management with tremendous respect for the multiplicity of challenges facing what is essentially a “team of Project Managers.” The point is that, just as there is no single Project Manager, there is no single Solution to Project Management … that will perform predictably well on “most projects most of the time.”
* For more information about the Cognitive Project Management T.I.M.E. Framework, click here.
** Dominant Project Management is the term used by the ICS-Compendium to represent the amalgamation of current Project Management thinking. Even though they may differ in some respects, in other respects they mainly say the same things. Cognitive Project Management is the name of a new Project Management model designed by ICS-Research specifically for the Construction Industry. To learn more about the differences between Dominant Project Management and Cognitive Project Management, click here.