The Constraints shall be notified to Phoenix through Request forms and template of the same is given in Appendix 17. These forms shall be numbers as per the coding given hereunder which shall be used as a Phoenix’s tracker.

This process shall enable Phoenix to delegate and fix the responsibility within our organisation to resolve these constraints.

For example, the projects shall be identified with codes as under;

H09 as H09, Centaurus as CEN, Business Hub Tower 1 as BH1, 285FD Tower 1 as FD1.

To ease understanding and make sure the right department within Phoenix addresses the issues in a timely fashion, the Constraints have been grouped in 9 Categories as under and identified by a three letters code.

The serial number shall be continuing irrespective of the category, starting with numerical number 1 and goes on as new constraints get notified by the GC.

So the coding for a constraint shall be

CRP - Project Code-Contractor code- Serial number of the request. Examples;

CRP-CEN-XYZ-1 (XYZ is prefix of Contractors name)

CRP-H09-XYZ-16

CRP-FD1-XYZ-21

Two independent constraints should not be clubbed under one request form. Different constraints, even with in the same category, need to be issued on a separate serial numbered form for each issue.

By Exception should there be a need to define elements of one issue with the inclusion of smaller sub-constraints within one larger constraint, the same may be included in one such request, with each of the elemental constraints referenced as parts, sub-numbered as (i), (ii), (iii) etc.

The Contractor shall have to attach necessary documents/ drawings/ sketches/quotation etc. as may be required to explain the constraint and help determine the solution with Phoenix’s team. Any request, which is not backed by the necessary documentary evidence, shall be construed as incomplete.

The forms shall be fully complete with relevant particulars and details and any additional information required to resolve the constraints. The onus of collating and submitting the information will rest with the Contractor. The form should clearly identify Phoenix’s dependencies and when such issue to be resolved to not to breach the Mitigation schedule in play. Care should be taken to make sure the issues are raised in time such that Phoenix’s team gets enough time to resolve them.

Some of the critical information to capture in the CRP (Constraint Resolution Protocol) forms are;

1. Nature of the CRP issue
2. Does it fall into Client domain or Contractors domain or jointly?
3. When it came to their knowledge?
4. Category & Coding
5. By when it has to be resolved?
6. What actions must be taken to resolve them?
7. Person(s) responsible for resolving them
8. Likely impact on time and cost should this not get resolved as per the timeline.
9. Other information required to process this CRP

As mentioned earlier, as a matter of general awareness, the Contractor shall be raising Constraints falling within his domain of influence and those under the Client's domain of influence. However, the Client will initiate action only for those notified and accepted as falling into the client domain of influence. There could be some constraints, which may require action from the Client and the Contractor, and they should be identified and separated in clear terms, which all actions are falling in contractors cope and which all in client scope.

The constraints may be communicated through emails directly to the GM (Client Representative) with a copy to;

(a) The Construction head from Client for the Project

(b) Common email id to be notified for CRP. All the communications by and to the Contractor shall copy the Common email id for CRP as cc. Eventually, this shall be moved into ERP. The list of open CRPs to be included in the weekly presentation by the Contractor to the Client. A suitable electronic form is enclosed as Appendix 18

In case of Request for Information on drawings and Shop drawings approvals, the communication may be sent to the Consultants directly as followed currently. Escalation through CRP shall be limited to cases where there are delays beyond the consultant's agreed timeline for resolution/ approval.

THE REGULAR COMMUNICATION OF RFIs AND SHOP DRAWING APPROVAL, WITH CONSULTANTS, SHOULD NOT BE ROUTED THROUGH THE CRP.

The Subject matter in the email should clearly mention the CRP code to track the emails and follow up for necessary actions.

7.8.1.3. CODING THE REQUESTS

Each of the requests shall be numbered as explained above; The category of the requests is as under. The type of constraints (examples) to be covered under each category are as under; The boxes shall be ticked based on the category of request.