Many of us like to jump to conclusions. Something happens and we deem it good or bad and either take action or abstain from acting. Hume's Guillotine seeks to differentiate between "what is" or what happened and is observed from how we interpret "what is." It looks at what is and then what ought to be. For instance, in construction productivity of a task may be abysmal at the start of a project or during a challenging (confined space, working at heights, etc.) section of work and some may view that as bad or ok. Depending on how much work there is, the total dollar amount, if it's on the critical path and just the preference of project leaders, adjustments may be made. Sometimes this is ok but other times it is not. In basic quality control or statistics, there will be some variability in day to day tracking of work. When all variables are controlled for there will still be variability. In cases where constructability negatively impacts a specific scope when compared to the majority of the work, we should be cautious on how we interpret what is observed and what action should or should not be taken.
Seeing and agreeing to what is, is usually not the most tricky part of the project. Seeing the same thing but having different onions on how it might impact the work and what can be done can vary widely. Many scopes of work have required environmental conditions (humidity, temperature) that must be controlled, maintained or accounted for when installing the work. There are obviously conditions that are ideal for each type and the ideal situation can usually be agreed to. However, depending on experience, perception on how conditions might impact the work, if there is a need to complete it quickly and/or how much extra effort might b required to get conditions closer to ideal or place quality work even under less ideal conditions, the work will progress forward. A contractor may think they can work a few tricks to install high quality work in current condition or that with a little work (with the right ROI) they can manually adjust the conditions to keep working. A client may think each of these is no good but in other cases, they may push a contractor to keep working as is or do some condition adjustments.
Another condition where what is might be agreed to is a quality issue or non-conforming work. The final product might clearly be out of spec but the response may vary. Contractors may believe no rework is required and request approval of the in place product. A client might not see it the same way and could request that the work be removed and replaced.
To complicate things further, there is the right solution and the solution that best preserves the relationships and team work on the project. Good will can be gained or lost by agreeing with someone on what ought to be the solution (even if you disagree) and then acting accordingly.
In my experience, this what is and what ought to be back and forth on a job gets muddier when setting expectations and then either meeting or not meeting them. What is actually delivered is often agreed to but whether this ought to be acceptable causes friction. The quantitative measure of a project deliverable might be exactly what is required but the qualitative measure could vary causing friction and strained relationships. This kills relationships and then kills projects.
We should strive to build projects based on what is required and how we feel this ought to be interpreted. The challenging part is that how things ought to be, or how people perceive things, can be all over the place from project to project and person to person. Build things right, manage expectations/relationships and deliver everything per the contract and we might just build a better world.
Comments