Constraint
Constraints represent a control process that ensures the work meets the requirements of the project and the owner. They have workflow and as such would have responsibility, time and status attributes which make them schedulable and can participate in the critical path of construction. They are typically applied to one or more dimensions.
Constraints are often represented by one or more documents. The creation, submission, acknowledgement and acceptance of the documents are the workflow of the constraint. A constraint workflow has duration and may have one or more defined steps. Each step would have a responsible party, time and status. All steps would be performed in series so the entire duration of the constraint would be a sum of each step duration. A constraint could have multiple cycles of steps from start to completion.
There are four different types of constraints:
Commitment
Start
Completion
Acceptance
Commitment Constraints - Represents the transfer of risk and responsibility from the “Contractee” to the “Ccontractor” for all work items. At a minimum, these types of constraints should define who is responsible to pay for the work item and how much. And who is to perform the work item and in what time frame.
Examples of commitment constraints are:
Bid
Proposal
Agreement
Architectural Supplemental Instruction
Construction Change Directive
Change Order
Start Constraints – Requirements that must be satisfied prior to the installation of a work item. Examples of start constraints are:
Drawing
Specification
Addenda
Request For Proposal
Notice To Proceed
Requests For Interpretation
Product Data
Coordination Drawing
Material Certificate
Installer Certificate
Samples & Mockup
Pre-construction and Pre-installation conference
Fabrication
Delivery
Start constraints consist of contract documents, quality assurance documents and pre-construction activities. They typically have preparation, submission and approval workflow steps. Each may be a single document or consist of a package of documents that for the purposes of workflow are treated as one. Some start constraints are more or less an event that when complete are documented.
Completion Constraints – Requirements that must be satisfied as a part of the execution and completion of a work item prior to successive dependent work items starting. Examples of completion constraints are:
Tests and Inspections
Certifications
Field Observations *
Environmental Conditions
Non-Compliance / Deficiency Items
Occupancy Permits
Sign-offs *
Completion constraints are for the most part quality control requirements that are scheduled events which may have one or more approvals to complete the requirement. They are undertaken by the general contractor, architect and governing authorities to ensure the work is installed as per the contract documents, applicable laws and regulations.
* Before a work item can start, the party performing the work must assert that the portion of the project that he is building upon is suitable for his work to begin. A sign-off is a way of noting the completeness and suitability of a work item so that follow-on work can start. This is not to be considered “Acceptance” of the work item – that can only be done by the owner via an acceptance constraint. The sign-off only represents that upon observation of the prior work condition and to the best of the parties knowledge, the prior work is suitable for his work to start. The date of sign-off by all down-stream parties represents the actual completion date of the work item.
Acceptance Constraints – Requirements that must be satisfied prior to final acceptance and payment of the work item. Examples of acceptance constraints are:
Request for Payment *
Certificates of Substantial Completion
Corrective Items (Punch List Items)
Warranties
Operations & Maintenance Manuals
Spare Parts
Startup Demonstrations
Certificate of Payment **
Certificate of Final Completion **
Acceptance constraints are mostly about the contractee taking ownership of the work. This is the stage when the contractor is finalizing any requirements necessary for the owner to take full occupancy and control of the building. In most construction contracts the architect certifies that the work was installed as per the contract documents and that the contractor is due final payment.
* Request for Payment is the constraint that represent the transfer of responsibility of a work item back to the general contractor and signals the beginning of the closeout of a work item. By approving a request for payment the general contractor is acknowledging the work item is at a state of substantial completion and is ready for acceptance by the owner.
** Documents that represents the actual acceptance date of a work item. The owner / architect has acknowledged the work item to be complete and conforms to the contract documents. The only exception is for any specifically enumerated items to complete or any warranty issues. The certificate of final completion establishes that the work items are 100% complete with nothing outstanding. This document would normally be issues at the project level and represents the close date of the project.
Constraint Class:
Constraints can be classified from the document that represents the process based on primary use and common properties. Documents that share the same purpose and have the same key properties are grouped by constraint class and are considered to be the implementation of an instance of the class. This allows a layer of abstraction or public interface that a document representing the constraint can be referred to without having to know the specifics of the document. Each constraint class would define a standard set of properties that all instances of the constraint must have.
The scope of a constraint class could be global, organizational, or dimensional. CEM would have a catalog of standards at the appropriate scope level available for use directly on a project or used as a template for a project specific implementation of the constraint to satisfy unique requirements. Custom properties could also be defined at the varying scope levels to track unique aspects of the constraint.
Constraint Workflow Rules:
Constraint classes would also have workflow rules. Workflow rules define the steps a constraint must complete and who is responsible for completion. Each step in a constraint workflow is part of the critical path calculation and as such has float and priority. This allows for not only escalation rules built around step duration, but also around consumption and value of float.
Dependency | Time | Summary | Introduction | Work Item