“Most Projects Most of the Time” Makes Little Sense

“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.

10 Comments to “Most Projects Most of the Time” Makes Little Sense

  1. Zach reed says:

    The line that made the most impact on me was, “By contrast, Cognitive Project Management** boils down Project Management to Coordination, Collaboration, Cooperation, and Communication.” I also appreciate what Chase Childress commented by acknowledging the projects using the Dominate Project Management model that finished successfully. Regardless of the model, approach, technologies, etc., there should always be coordination, collaboration, cooperation, and communication. It is interesting that communication seems to be a common theme among each of those descriptors (a testament to the importance of good communication). From start to finish (establishment of values and beliefs to execution to final inspection, etc.), I see the value in coordination, collaboration, cooperation, and communication and feel that it would be appropriate to say that ALL projects would benefit from applying those actions in management.

  2. Ed Backiel says:

    I have never truly agreed with the “best practices” theory in any industry. While there is much to learn from tried and true procedures, there are many elements to consider, with the individuality of the poject itself to the individuality of the stakeholders and facilitators. I don’t beleive there is any predetermined best path to any project without serious thought to each projects objective and each participants experience and goal.

  3. Sue Backiel says:

    While some general guide lines should be followed, I think it is beneficial to question any practice and improve it whenever possible.

  4. Laura Neal says:

    Although I do agree that certain ‘baseline’ standards should be at play, for example, ‘cold food should arrive cold,’ in order to serve its purpose in each individual project, they must be customized.

    I know this sounds silly— but the saying ‘every pregnancy is different, even amongst the same pregnant woman,’ is also a good analogy.

    Projects vary so much from industry to industry and sometimes even more so within their industries.

  5. Dave Black says:

    The point of the blog is interesting although possibly the intent of what some of the authorities promote is to use their solutions within a more general framework, that might be useable across different industries, than as a prescriptive model that has to be followed to the letter. For example according to the Rational Unified Process (RUP) methodology is an iterative software development process that is not prescriptive but is rather an adaptable process framework intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. For the IT industry it has become a very common approach when developing software.
    Agile is another methodology that has also become very popular with some organizations within the IT industry and almost replaced the original waterfall method. To quote one source Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, and the accolades go on.
    In this context the “most projects most of the time” claim would have a ring of truth, keeping in mind as the author states, “some are better than others at some things”. For a construction project an iterative, incremental, and repetitive approach may not be very effective. Particularly, considering the hard and fast rules that construction projects adhere to, without some of the flexibility inherent in many IT projects where scope can become very fuzzy and vague to say the least. A building is a building is a building and the results are fairly constant across the board whereas an IT project can change many times during its lifetime with results that no one would envision when the project initially started.
    Even if the Cognitive approach to project management becomes the Construction standard, I suspect that many people may treat it as a general framework, using only certain parts without following the entire prescriptive way of use.

  6. Michael Neal says:

    [C] Murray, in going back through and reading the blogs and to answer the question regarding the schedule pertaining to the electrical and the NTP. There is an activity that has to start to get the project started. What this activity is could go back through getting financing, drawings and regulations for the project. There has to be a set starting point if not then everything would start with Genesis. There has to be some fashion of control and guidelines which can be modified to fit the situation that arises. Thats why trying to perform disaster drills is just a drill. The perpritrater may or may not enter at that location, so its time to change plans. The article is a great way to let those new that there is not a tunnel vision path to doing something, you have to think outside the box, right.

  7. michael neal says:

    [C] I might be missing the point of the blog, my comments are there are no two projects that are the same and thus there is a need for different strategies. The role of the project manager is different with each project and the scope of work for that manager.

    • MurrayBWoolf says:

      My point, Michael, was reflected in the opening paragraph, where I wrote: “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) about as useful as a Culinary Institute writing a set of guidelines, principles, and best practices intended for “most meals most of the time.”

      Michael, you are correct. Each project IS unique. And if we accept that a Project Schedule models a Project Execution Strategy, then how can we set absolutes with respect to Project Schedules that are meant to apply to “most projects most of the time” unless those absolutes are VERY general.

      The problem, as I see it, is that many of these so-called “standards” are way too specific to be equally beneficial, relevant, and applicable across “most projects.” As just one example, consider the abosulte rule that, to be considered legitimate, a Project Schedule can only have ONE activity without a predecessor (the first activity in the schedule). and ONE activity without a successor (the last activity in a schedule). On its face, this restriction makes sense, and seems to insure that the Schedule’s logic is continuous and not intermittent.

      But what would you do with a situation like this? The General Contractor (who has responsibility for producing the Project Schedule, is told (by contract) that the Schedule’s first Activity must be “Notice to Proceed.” He is also told, by the Owner during Bid Period discussions, that the Owner will be supplying Permanent Power to the building no later than June 1, 2010. It will be provided under a separate contract with another prime contractor who is already underway. The contract also requires the GC to include “key Owner activities.” Surely, provision of Permanent Electrical Power to the project is a “key Owner activity.”

      So, the GC includes an activity in the Schedule with the description, “Owner provides Permanent Power.” He sets the duration at one-day, and sets its Earliest Start with a Start-No-Earlier-Than date constraint of June 1, 2010.

      As far as the CPM logic is concerned, this is entirely adequate and competent. One can perform both Forward and Backward Passes on the logic, and the SNET Date Constraint fully accommodates the Forward Pass. There is NO need for a predecessor to this Owner activity.

      But the Owner’s Rep (or Construction Manager) rejects the Baseline Schedule submittal on the basis that it does not meet “industry standards” for their not to be ANY “open-ended activities” except the first and last activities. The Owner (through its agent) requires the Contractor to “tie off the start of the Permanent Power activity.”

      Michael, I ask you: What should be the predecessor activity? Can you think of one? Nothing in the work of the General Contractor actually restricts the performance of the work of the Owner’s other contractor, who is bringing electrical service TO the project site from two miles away!

      When the GC gives the question back to the Owner, its Construction Manager suggests tying it off to the “Notice to Proceed,” since that is the first activity. “But,” the GC retorts, “the work of the Owner’s other contractor began long before our Notice to Proceed! There is no LOGICAL connection.”

      I hope you get my point. We can get lost in debating the specifics of this fictitious example. But the point is that each project is unique. It is enough to have a GENERAL rule without getting too specific. For instance, there could be a standard that states something along the lines, “The Schedule’s logic should be constructed with sufficient integrity to insure that a proper Forward and Backward Pass can be performed.”

      How about “standards” that discredit the use of Start-to-Start or Finish-to-Finish ties? Do you think that “standards” should be setting limits on the use of SS or FF ties? Yet there are “”standards” out there that openly condemn their use!!

      Does this reply help you better understand the point of the blog?

  8. Chase Childress says:

    I have found in my limited experiance, that while both approaches can yield successful results, it is the projects that take the Cognitive approach provide a better or more ejoyable work atmosphere.

  9. Connie Bremer says:

    This blog is a great introduction to the strategies and purpose of the CPM Mechanics course; to introduce the many questions and acknowledge the inconsistencies and ambiguous practices involved in the scheduling realm. It speaks of why there is so much more to take into consideration when embarking on a new project. It sparks an enthusiasm to read on…

Leave a Reply to Connie Bremer Cancel reply