Collaboration, Coordination, Cooperation, and Communication

Extensively repeated throughout Cognitive Project Management literature, the essential focus of Project Management is, or should be, on Collaboration, Coordination, Cooperation, and Communication. We believe this to be true because we find it difficult to imagine how any of the traditional “knowledge areas” of Project Management attention and concern can be effectively managed if any of these four focal points is not dutifully addressed.

Distinguishing Between the Terms

Briefly, let me clarify these terms. In a nutshell:

  • Collaboration refers to the simple reality that multiple entities are working within close enough proximity to one another that, if not prudently managed, such juxtapositions have the potential to negatively impact the efficient performance of all involved parties.

  • Coordination speaks to a conscious and concerted effort by the parties involved to figure out an orchestration of their respective movements such that they minimize the amount of negative impact they might cause one another.

  • Cooperation has to do with attitude, especially the attitude of those being managed in the course of coordinating collaborative activities. Cooperation cannot be mandated or forced.  It is only volunteered or offered freely.

  • Communication, a familiar and self-explanatory term, is the medium through which the other three focus factors are accomplished.

Note: For more about the Four C’s of Project Management, see Dynamics Projects: It’s all About Attitude,” a blog I wrote back in September 2012.

Equitable and Mutually-Supportive Intentions

The simple assertion of this blog article is that the Project Schedule is the perfect tool for cultivating, nurturing, and safeguarding Project Collaboration, Coordination, Cooperation, and Communication. The Project Schedule — most especially a dynamic and interactive network-based schedule (such as a Critical Path Method schedule)  — must nevertheless be allowed to express the equitable and mutually-embraced intentions of the Project Team.

Please don’t gloss over that last sentence.  The key to a powerful Project Schedule — at least, with respect to the achievement of Collaboration, Coordination, Cooperation, and Communication — is that as a Project Execution Strategy the details within it must be:

  • Equitable: When viewed holistically, the Project Schedule reflects the most equitable win-win scenario possible, given the particular circumstances of the project.

  • Embraced: The Project Execution Strategy must not only represent a mutually-agreed-upon plan of attack, it must be one that all parties commit to, especially with respect to their individual portions of the overall execution strategy.

A Short, Controlled Rant

If you will indulge me, I would like to rant for a few minutes about arbitrary limits that have been placed on the use of Date Constraints, certain Relationship types (specifically, Start-to-Start and Finish-to-Finish), automated work calendars, and certain software settings. In recent years the floodgates seem to have been opened with respect to opinions about the legitimacy of these scheduling mechanisms. It is my firm opinion that each of them is individually legitimate as a technique or method, and none should be condemned as “bad practice” on their face.

As I see it, each of these mechanisms can contribute to the effective achievement of what is, or ought to be, the primary purpose behind the creation and maintenance of any Projects Schedule: to model Project Execution Strategy. To me, these mechanisms are no different than an illustration that accompanies an article, a graphic that augments a narrative, or punctuation that adds meaning and context to a sentence.

  • Date Constraints: When attached to an activity, a Date Constraint qualifies an otherwise less certain statement of timing for the associated activity. Without the Date Constraint, the activity’s start and/or finish dates are subject to the compounding effects of durations and logic of other activities. Date Constraints come along to clarify the intentions of the Project Team, that certain activities are expected to happen with greater temporal certainty than what might be predicted to manifest solely from the eventual progression of effort.

  • Automated Work Calendars: Similarly, automated work calendars that have been peppered with blocked-out “non-workdays” reflect the intentions of the Project Team, as well.

  • Overlapped Activities: Start-to-Start and Finish-to-Finish logic ties are used in CPM schedules to depict the Project Team’s expectation that certain activities will occur somewhat concurrently. How more relevant can one get to the concerns of Collaboration, Coordination, and Cooperation than to identify which activities might be occurring concurrently, and to contemplate how their juxtaposed work efforts will interrelate to one another?

  • Software Settings: There are a number of scheduling software settings that are routinely argued among Scheduling Technocrats as to their appropriateness. To name some of the more hotly-debated: progress override versus retained logic; continuous versus interruptible durations, zero total float, and zero free float, and others. The point is that each of these settings provides us with additional ways to reflect the intentions of the Project Team, with respect to Project Execution Strategy.

Banning Contractions

Could you ever imagine the Chicago Manual of Style banning the use of contractions? Well, not only does it not prohibit their use, it actually encourages them, saying, “Most types of writing benefit from the use of contractions. If used thoughtfully, contractions in prose sound natural and relaxed and make reading more enjoyable.”

I bring up contractions because that is how I view Start-to-Start and Finish-to-Finish ties: they are a more “natural and relaxed” way of depicting the intention for two activities to be partially overlapped. In a simple example I often use, picture two activities: Wash Dishes and Dry Dishes. Now assume two people assigned to kitchen duties: one person washes while another dries.

Clearly, Drying Dishes cannot begin any sooner than some time after Washing Dishes has not only begun but progressed to the point that at least one dish has been washed and stood in a dish rack to drain. Likewise, Drying Dishes cannot finish until after the last dish is washed. Using traditional Precedence Diagramming Method (PDM) notation, we merely create two activities and link them with a pair Start-to-Start and Finish-to-Finish ties.

But for those who have heartburn over the use of Start-to-Start (SS) and Finish-to-Finish (FF) ties, their preferred diagramming scheme would have use revert to the logic depiction techniques which were last in wide-scale use back in the 1970s (Arrow Diagramming Method; ADM)!

They would have use create four activities: two for washing and two for drying. And they would link these four activities with four logic ties, as follows:

  • Activity 1: Start Washing Dishes
  • Activity 2: Complete Washing Dishes
  • Activity 3: Start Drying Dishes
  • Activity 4: Complete Drying Dishes

As for the logic between these activities, instead of the single SS/FF pair used PDM, we would now have four Finish-to-Start logic ties, as such:

  • Logic Tie 1:  Activity 1 > Activity 2
  • Logic Tie 2: Activity 1 > Activity 3
  • Logic Tie 3: Activity 3 > Activity 4
  • Logic Tie 4: Activity 2 > Activity 4

Twice the number of activities, and twice the number of logic ties! And in the end, they both say the same thing. So, why in the world should Start-to-Start and Finish-to-Finish ties be outlawed?

The Goal Was to Drain the Swamp

I sometimes (maybe even often) wonder whether we Scheduling Technocrats have gone too far with our self-imposed rules — with our recommended and best practice pronouncements. In fairness, losing our practical bearings is somewhat endemic of most humans. Ronald Reagan said, rather famously in February 1982, “I know it’s hard when you’re up to your armpits in alligators to remember you came here to drain the swamp.”

I fear that, over the years, the Scheduling Discipline has lost sight of why we create and maintain Project Schedules in the first place. We do so in order to facilitate the Communication needed to achieve efficient Collaboration, Coordination, and Cooperation.

Borrowing From Book Content Layout Design

After a less than satisfying experience with my first book being published through a large publishing conglomerate, I decided to self-publish my second book.  This meant doing my own copy layout. I purchased the same software that the professionals use, and took my copy from MS Word and imported it into Adobe inDesign.

Laying out my own copy was an exhausting and sometimes aggravating experience. But I did learn something that I think is transferable to this discussion about Schedule Design and, more specifically, to the use of Start-to-Start and Finish-to-Finish ties. It has to do with what are called placeholders.

Suppose you are laying out a page of text and you know that somewhere on this page you will be placing a small graphic. Suppose that at the time of the layout you have not yet developed the graphic. In fact, all you know at this point is the intended size of the graphic. Into the page you insert an empty box that measures two-inches wide by two-inches high. For now, this empty box serves as a placeholder for the ultimate image. Later, when you receive it, you will simply drop the image into the empty box.

The thing about placeholders is that there are two different ways to anchor them in the layout: absolute and relative.

  • Absolute Anchor: When a placeholder is absolute, its location is fixed on the page with respect to other fixed values (e.g., page margins).  The image will never move from this location even if the text around it does.

  • Relative Anchor: The other option is to anchor the placeholder relative to some point in the text.  Think of the image as just another character in the strings of characters that comprise the sentence. If we add more text before the insertion point, then the location of the image floats, along with the subsequent text.

The Concept of Anchoring, Applied to Project Scheduling

Back to Project Scheduling, perhaps it might be helpful to apply the concept of anchoring to schedule logic.

  • Logic Ties: When we apply logic ties, we are essentially anchoring an activity to surrounding activities. As such, when activities prior to the Subject Activity move back or forth in time, the Subject Activity’s Earliest Dates change accordingly. Likewise, should downstream activities shift, the Subject Activity’s Latest Dates will change accordingly. Thanks to logic ties, the Subject Activity is anchored in a relative manner.

  • Date Constraints: When we impose Date Constraints on a Subject Activity, we anchor that activity to an absolute point in time, by way of either a calendar-fixed starting point or calendar-fixed ending point.
  • Work Calendars: Finally, when we assign a Subject Activity to a particular work calendar, we anchor the activity to one or more operational windows that are fixed to specific calendar dates.

My hope in discussing anchoring is that perhaps by seeing Logic Ties, Date Constraints, and Work Calendars as forms of anchoring, it might be easier to appreciate why I contend that bans on the very use of these techniques is unwarranted.

Ratio of Vowels to Consonants

Back to the Chicago Manual of Style, could you ever imagine it mandating some arbitrary “ideal” ratio of vowels to consonants in a written document? Would this literary authority ever dare to suggest that the ratio of vowels to consonants ought to be such-and-such? How about the number of periods or commas in a document?  How about the number of quotation marks? Yet, in recent years we have seen a flurry of scheduling recommended or best practices that dare to opine on such quality-indicating parameters as:

  • The largest (or smallest) that an activity duration should (can) be
  • The number of Date Constraints in a schedule (some ban them altogether)
  • The use of Start-to-Start or Finish-to-Finish logic ties (some ban these, as well)

Convey the Project Execution Strategy

I will close by reminding the reader that the primary (if not sole) purpose of the Project Schedule is to depict the Project Team’s intended Project Execution Strategy. The Critical Path Method gives us many powerful and robust mechanisms for painting this picture. Since we probably agree that as a general rule simple is better, whenever one of these mechanisms presents a statement of intention more coherently, are we not remiss if we pass it over … in acquiescence to a flood of arbitrary “standards” that surround us up to our armpits.

Leave a Reply

Your email address will not be published. Required fields are marked *