Going Backwards to Move Forwards

In order to progress Projects, processes as defined in the Contract Documents (in addition to those of good practice) lend themselves to offering 3 main options; "1" or "A" for Approved (w/o comments); "2" or "B" for Approved WIth Comments; & "3" or "C" for Rejected.

Type 3/C is clear enough, as is 1/A but it is usually 2/B wherein problems lie.

Most engineering/delivery teams will want to move the Project on come-what-may and this will lend itself to them being favourable of 2/B (being in fear of 3/C).

Unfortunately, the other Party's Team usually do not want to commit to 1/A immediately and are in fear of 3/C - as it puts them in the spotlight as to why the deliverable has been "rejected" - hence, they usually opt for 2/B.

What is the problem with this, you may ask?

Well - always beware sentences that begin with the speaker saying "Look" or, as here, "Well" - whilst 2/B moves the Project along, it causes massive issues in a number of ways, not least with - at the end of the Project - usually having to submit each and every one of the 2/B documents again in order to achieve 1/A as per Contract requirements.

This sometimes runs into the hundreds, if not thousands and is the bane of some poor employee's existence at the end of a Project, usually when issues have arisen and tempers are slightly high.

Irrespective of that, the other more pressing issue is the fact that in view of comments having been made (presupposing they are relevant - something we shall return to later) this raises issues as to whether there are variations within the said transmittal which the Contractor has accommodated within the deliverable provided but which the Engineer/Employer will not confirm in fear of allowing EoTs and VOs to creep into the Project.

Rather than have a stalemate in which both Parties will not budge, the usual consensus reached is to add some comments and then provide Code 2/B - something that is rarely challenged by the Contractor.

A suggestion would be, in future, to see if provision exists within the Contract (usually a deliverable is to be reviewed and given 1/A etc. within 14 days or else is returned 2/B or 3/C with resubmission within (usually) 10 more days and re-review and approval within the following 14.

As such, there is (usually) provision within the Contract for 14+10+14=38 days to resolve matters and move on (presupposing this would be with 1/A).

However, even after 38 days only to keep getting 2/B most Contractors continue with the Works in the hope matters are "resolved" at the end of the Project, unfortunately, these hopeful people are the Engineering Team and are not overly concerned with the Commercial Team's tribulations that are to follow at the end of the Project.

As difficult a choice as it may be, one suggestion is to give notice at the end of this period (in the example above being 38 days) and - subject to provisions within the Contract - suspend Works in this vicinity and divert resources to other activities with a view to getting confirmation from the Engineer/Employer that the item is 1/A and may well entitled the Contractor to EoT/VO.

This is why processes within the Contract should be mapped out so that timeframes and actions therein can be defined and implemented appropriately.

As such, when doing this, start from the end of the Contract and see the process expected to be completed BEFORE the final discharge will be considered, even speak with the Tender Team and ask them how long they allowed for activities XYZ to be finalized after the Works were completed and TOC issued, then, working backwards one can see how early it is that one needs to start bringing some of these processes into play before they start to impact on the flow of the Project and possibly cause delays and additional expenditures.