M03-6 Accepting Completed Deliverables

Contributing Authors
Raphael M. Dua
Paul Harris
Saleh Elshobokshi
Mohammed Aboul-Fotouh
Mohd Nizam
Vamsi Chand
Mark LeServe
Sam Onumah
Mufiz Sayed
Matthew Edwards
Benjamin Crosby
goduspopevawibrotoslukijecimonekumuprubruslaspotufrepuwrofri
Forest Peterson
James Williams
Clement Suhendra
Jackie Gilliland
Ray Pope
Anthony Lowery

03.0 - MANAGING SCOPE

03.1 - Module 03-1 - Introduction to Scope Management

03.2 - Module 03-2 - Developing the Scope Management Policies & Procedures Manual

03.3 - Module 03-3 - Validating Stakeholder Expectations

03.4 - Module 03-4 - Creating the Work Breakdown Structure

03.5 - Module 03-5 - Creating the Control Accounts

03.6 - MODULE 03-6 - ACCEPTING COMPLETED DELIVERABLES

li_97_mod_03-6_fig_1_rev_01.png

Figure 1 - Accepting Completed Deliverables Process Map

Source: Guild of Project Controls

03.6.1 INTRODUCTION

In order to “close the loop” on this process, it only makes sense that given this is where we defined the scope (via the WBS and Work Packages) that we end by comparing what the WBS and resulting Work Packages defined vs. what was actually delivered, understanding that rarely is what we built or delivered EXACTLY match what was specified, designed or expected.

Once we have accepted a deliverable, this becomes inputs into Module 5 - Managing Contracts and Module 10 - Managing Progress.

Whether using formal Earned Value Management (refer Module 10 - Managing Progress) or just plain “common sense” sound business practices, there are three criteria which must be met before a deliverable can or must be accepted by an Owner. These three criteria are:

1) The work must be physically completed. Work cannot or should not be billed or paid in advance of the work physically being completed.

2) The work must be in “substantial conformance or compliance”, meaning it does not have to be perfect, only fit for use.

3) The contractual requirements must have been fulfilled or met.

Normally, the burden of proof that these 3 criteria have been met lies with the Contractor and not the Owner. This will be covered more completely under Module 5 - Managing Contracts, but in many cases, Owners do not require Contractors to provide sufficient proof that the work they have done has fulfilled all three criteria.

This is important for Project Control Practitioners to understand as there is a danger that we record work as being done when in fact, it has NOT met all three criteria. This is a common error on the part of both planner / schedulers as well as cost managers. For real life applications, until or unless work deliverables have met all three criteria, they should not be recorded as being 100% complete.

03.6.2 INPUTS

  • Work Results (Physically Complete Work Packages)
  • Technical specifications
  • Contractual Terms & Conditions

03.6.3 TOOLS & TECHNIQUES

03.6.3.1 Physical Inspections (Work must be Physically Complete)

Physical Inspections can take many forms, the classic being “management by walking around” where an owners representative, usually an architect, engineer or contract manager, walks around the project with the contractors project manager and / or construction manager, and verifies what work has been done and what work remains.

However, given that many teams are disbursed, with the proliferation of mobile devices, we are seeing increased use of photographs, videos, time lapse photography and even the use of drones to capture and record physical progress on the project.

It is important to note that in the event of a dispute or claim, this information has the potential to become evidence in a court of law and should be logged and securely archived accordingly. Ideally multiple copies will be made and stored at separate locations, with the originals being stored in the home office of either or both the owner and contractor, along with other contractual documents.

03.6.3.2 Quality Assurance / Quality Control (Work must be in “Substantial Conformance or Compliance”)

In addition to work being physically completed, deliverables must “substantially” conform to the technical requirements. The team of people normally responsible for this are known as Quality Assurance and Quality Control or QA/QC which means the project controller needs to validate with QA/QC whether or not the work has fulfilled the requirement that it be in substantial compliance or substantial conformance to the technical requirements.

While the two terms are often used interchangeably, they are not the same:

1) Quality Assurance is defined to be “A process/effort that ensures that processes are followed, that the processes have the contractor (or owners own people) doing the right things, the right way, and when they fail to be used or fail to perform as expected we have a way to correct, adjust, or escalate the matter until it is resolved to everyone's satisfaction.”

2) Quality Control is defined to be “the process of examining each deliverable and ensuring it meets some minimum levels of quality as defined or implied in the contract documents or technical specifications”.

  • Quality Assurance makes sure you are doing the right things, the right way.
  • Quality Control makes sure the results of what you've done are what you expected.

Explained more simply, the difference is that QA is process oriented and QC is product oriented. For example, Testing, being product oriented is or should be a CONTRACTORS responsibility and thus falls under Quality Control. Testing for quality isn't assuring quality, it's controlling it.

While QA/QC rarely if ever falls under the responsibilities of “project controls” we do need to recognize that we have an obligation to communicate with our Quality Control colleagues before recording work as being 100% complete as even though we are uniquely positioned to capture much of this information, being physically complete does NOT mean the project controls Practitioner can record as being 100%.

This is normally done through testing, usually by and independent testing agency, hired either by the contractor or the owner, or in some cases, both, depending on the contract type and local customs or laws.

03.6.3.3 Contractual “Shall” Clauses (Contractual Requirements must have been Fulfilled)

The third criteria that the Project Control Practitioner (be they planners / schedulers or cost managers) is whether the Contractor or Vendor has fulfilled all the contractual requirements. This is known as the “shall clauses” as in “Contractor shall…”.

As with QA/QC, rarely is contract administration one of project controls responsibilities, however, the Project Controls Practitioner needs to be aware that before he / she can give credit for 100% completion of any work package, that not only must the work be physically complete and must substantially meet the technical specifications (QC), the Contractor or Vendor must have fulfilled or met whatever requirements the contract imposed on them.

Some of the contractually required items often overlooked by contractors are spare parts, operation manuals and operator training. If the Project Control Practitioner is unaware of these requirements it is easy to credit 100% completion for a Work Package when in fact the activity is really only 95% or 98% complete.

Testing and validating whether or not the “shall” clauses have been fulfilled can be the responsibility of either the Quality Assurance/Quality Control or Contract Administrator, depending on the nature of what is being required, but the burden of proof that the shall clauses have been fulfilled lie with the contractor or vendor and not the owner.

03.6.3.4 Substantial Completion vs. Substantial Performance

Substantial Completion is another term that Project Control Practitioners be they planner / schedulers, cost managers or forensic claims analysts need to know and understand. Why? For the same reasons noted above, specifically that planners, schedulers and cost managers are at risk of giving 100% credit for Work Packages before the work is really done.

  • Substantial Completion” is a legal term that Section A.9.8.1 of the American Institute of Architects (AIA) defines as: “the stage in the progress of the Work when the Work or designated portion thereof is sufficiently complete in accordance with the Contract Documents so that the Owner can occupy or utilize the Work for its intended use.”

This does NOT mean the Work Package is complete yet. What it does mean is that the work package is 90% to 95% complete and that the remaining 5% to 10% will be covered by the Punch List / Snag List / Defects List activities.

This becomes important to cost engineers in particular, as the date of substantial completion often or usually determines bonus or penalty payments.

  • Substantial Performance” is a term used in contract law to refer to a degree of performance of a contract which isn't full and complete performance, but is so nearly equivalent that it would be unfair to deny the contractor the payment agreed upon in the contract. However, the owner has a right to recover whatever damages he has suffered by reason of the contractor's failure to render full and complete performance.

Thus Substantial COMPLETION is important to the planner / scheduler because the date it was achieved is important, while both Substantial COMPLETION and Substantial PERFORMANCE are important to the forensic claims analyst.

The differences between substantial COMPLETION and substantial PERFORMANCE, although related, need to be understood by the planner and scheduler in particular.

03.6.3.5 Beneficial Use or Beneficial Occupancy

Another important term that Project Control Practitioners will hear that they need to know and understand and that is “Beneficial Use” or “Beneficial Occupancy”. These terms are synonymous and are defined to be the “Stage of construction of a building or facility before final completion, at which point the owner can occupy or use it for the purpose it was constructed.

The reason this becomes a concern to Project Controls Practitioners is just because the Owner is using some part of the facility does NOT mean that the Work Package(s) are 100% complete. It only means that the facility or some portions of the facility have reached the stage where the Owner can start to use some or even all of the facility, even though it is not complete yet.

03.6.3.6 Punch Lists / Snag List / Defects List

These are synonymous terms which often cause confusion in Project Control Practitioners particularly in determining completion dates and physical % complete. Essentially, a punch list or snag list is the work remaining AFTER “Substantial Completion”. Section A.9.8.2 of the American Institute of Architects (AIA) General Conditions tells us“ the contractor shall prepare and submit to the Architect a comprehensive list of items to be completed or corrected prior to final payment…” Depending on the contractual terms and conditions, the RETENTION money, usually 5% to 10% of the value of the work package is held back from each payment and that amount of money is to be used to protect the owner in case the contractor fails to complete the work. That retention will be released upon completion of the Punchlist as final payment to the contractor.

What this means to the project controls Practitioner is that an activity is not 100% until the punch list has been completed OR that another activity has to be added at the end of the project called “Complete Punchlist” and that activity has an appropriate duration and is cost loaded with the amount of money retained.

03.6.3.7 Certificates of Completion / Certificates of Final Acceptance

For Project Control Practitioners, this is the document which legally ends the project. For owners, this is when the product of the project is turned over to the asset managers for depreciation purposes and for the contractors, this document signifies the completion of the contract and the start of any warranty or guaranty periods.

03.6.4 OUTPUTS

  • Completed Snag / Punch Lists
  • Accepted Deliverables (Outputs) (Becomes Inputs to Module 11 - Managing Progress)
  • Certificates Of Acceptance / Certificates Of Completion

03.6.5 REFERENCES & TEMPLATES

GPCCAR Module M03-6, Revision 1.01