Why Communal Relationships Matter

Communal Relationships Are Important for the Project Leadership to Understand

Communal Relationships matter because they help us to understand why and how the Project Schedule can — without your ever noticing it —transform, ever so subtly, from a useful project management tool into a damaging and disruptive social weapon.

What are Communal Relationships?

Cognitive Project Management identifies three categories of relationships that exist between activities in a Project Schedule: Progressive, Symbiotic, and Communal. Anyone familiar with the Critical Path Method knows about Progressive Relationships, which are characterized by connecting logic ties (usually drawn as arrows between activity boxes). The other two relationship categories, however, are not related by way of logic. For virtually all readers of this blog article, the idea of activities being “related” without logic ties between seems impossible, if not also entirely false. In this short article, we will introduce the notion of Communal Relationships: why they exist, and how they work at cross-purposes to the established temporal objectives of the Project. So, before proceeding into a discussion about how our awareness of the existence of Communal Relationships can improve the likelihood of temporally-successful projects, let’s make sure you know what a Communal Relationship is.

First identified by ICS-Research back in 2009, a Communal Relationship is formed between two activities if they share, in common, one or more (of what Cognitive Project Management calls) Project Performance Determinants. There are five classifications of such “Project Performance Determinants,” and the  mnemonic, SMILE, helps us recall them. Specifically, successful project performance is determined by the timely availability of Situs, Materials, Information, Labor, and Equipment.

Let’s start with a simple example of a situation where Information is the common element that is in limited supply. A drywall subcontractor is reviewing the construction documents in advance of performing a certain element of work and discovers a contradiction between the plans and the specifications. Seeking clarification, he writes a Request for Information (RFI) which he sends along to the General Contractor. At about the same time, the electrical subcontractor issues an RFI on an electrical matter, and it too is forwarded to the General Contractor’s Project Engineer. The Project Engineer is tied up in day-long meetings and so the RFIs sit on his desk until he returns. The next morning he logs them into an RFI Tracking Log and then forwards the RFIs to the Architect, the party responsible for issuing a timely and adequate response. Upon receipt, the Architect adds these two RFIs to a stack of seven other RFIs received in recent days.

What the drywall and electrical subs “share, in common” is access to the Project Engineer, as well as to the Architect. Now, after nearly a year’s worth of blog articles, surely you and I are in agreement that the Project Schedule is a model of intended Project Execution Strategy. Furthermore, we are certainly in agreement that the activities in a schedule represent corresponding actions in real life, on the project.  And so, those unanswered RFIs are delaying the performance of real actions in the field, and such delays are reflected in slipping dates associated with corresponding activities in the Project Schedule.

Back to our example, if we look we will find both drywall and electrical activities that are being impacted by this informational bottleneck.  The essential dynamic of Communal Relationships is in the compounding effect each activity has on the other. Try to appreciate the subtlety of this point.  It is not just that the drywall contractor (0r, for that matter, the electrical contractor) is waiting on the Architect for an answer. It is that each subcontractor is exacerbating the delay being experienced by the other.  It is like two people trying to squeeze through an already narrow doorway, at the same time.  Each person was already having a difficult time on their own. But cramming together, only makes things worse. What is fascinating to a Scheduler from a technical perspective, is that the involved drywall and electrical activities have a Communal Relationship with one another even though they have no logic ties connecting them to one another.

[Note: For more about SMILE, you may wish to read a blog I wrote in September, 2012 for the It’s About T.I.M.E. blog site, entitled, Dynamic Projects: It’s All About Attitude.”]

Communal Relationships Impose Zero Sum Game Conditions

Back to the main point of this blog, when parties to a project compete with one another for common “Project Performance Determinants” that are in short supply, they are said to be sharing a Communal Relationship. And ICS-Research has found that Communal Relationships invariably subject the Project Schedule to a Zero Sum Game situation. [A Zero Sum Game is one in which, in order for one player to win another must lose.]

How does this happen? It’s really quite simple, and quite predictable. It has to do with human nature. Going back to our example, let us imagine how the Architect might decide which RFIs to address first? How does she prioritize her RFI backlog?  Answer: Total Float. The traditional way that priorities are set (for virtually all members of the Project Team, not just the Architect) is by reference to Total Float. The lower an activity’s Total Float, the more urgent it is perceived to be, and the more immediately it is addressed.

Now, as we know, Total Float is derived from the Critical Path (CPM) Schedule. And so, the savvy contractor quickly learns that in order to get preferential attention, it is better if its activities have less Total Float.  As the popular expression goes, “the squeaky wheel always gets the grease.” One thing is for sure: Communal Relationships — which exist extensively, just below the radar, on most construction projects — constitute a constant and serious threat to the sustained credibility and objectivity of the Project Schedule. It is this Zero Sum Game eventuality of Communal Relationships that turns up the heat on the competition for limited Project Performance Determinants and makes competition among the project players so intense. [Note: If this topic interests you, you might want to read Zero Sum Game and Project Conflict,” a blog I wrote for the Thinking Outside the Box blog site back in from September, 2012.]

The natural (and seemingly unavoidable) consequence of Communal Relationships is that each party is selfishly driven to better its own position at the expense of not only the other players, but of the project itself. And since Total Float is the singular criterion of prioritization, the Project Schedule is consciously manipulated to forge such a technical advantage.

Can We Stop Communal Relationships from Creating Zero Sum Game Conditions?

All of the above begs the obvious question (that so few seem to be asking): How else might project priorities be decided other than by Total Float? This is one of the important questions that ICS-Research has been working on for the last year or more.  And while we have much more work to be do before we can announce anything definitive, I am thrilled to report that what looks currently promising is a concept we are tentatively calling Construction Currency.  More about this as it becomes a more viable option.

But this is a crucial question for, if we can find other ways than Total Float to prioritize access to, and supply of, SMILE elements, we might just be able to reduce the gamesmanship. And if we can accomplish that, then we might also manage to preserve the Project Schedule as a viable management tool and save it from deteriorating into a self-serving claims and financial weapon.

1 Comment to Why Communal Relationships Matter

  1. Zach Reed says:

    Previously, I had a segmented view of a project schedule. Given what I’ve learned about Communal relationships, I see now that schedules are more connected than I previously thought. Since we have learned in almost every module that Dominant has disparate views of management I feel confident that I am not the only one who assumed that there was inherent disconnection in a schedule. On the contrary, there is inherent connection throughout the whole schedule, whether activities are tied logically or not.

What is your opinion? We'd like to know!