Concession and Deviation Requests

Definitions and abbreviations

Accessing the system

To be able to view Concession Deviation Request Forms a user must either be an Admin or have access to Concession Deviation Request for the Project.

Permissions

• Global Admins can view all forms.
• Portfolio Admin can view all forms.
• Project Admin can view all forms.
• Super User can view all forms.
• Normal users can view forms they have the corresponding Confidentiality Level and Delivery Line access to.
• Users can always view forms where they are nominated to sign.
• Additional layer of access, only Supplier / Sub-Suppliers identified on the form can see those forms (Company (owner of the deployed solution) see all)

Navigation

Concession Deviation Request is accessed from the Pims menu. Click the "Concession Deviation Requests" menu item, and you will be taken to the register.

Common functionality

For information about common functionality please refer to the Common Functionality user guide. 

Setup & Settings

Some settings allows each project to define individually. Admins can access this setting from the "Settings" option in the register. Ref. Concession Deviation Request settings user guide.

Note: When using the CDR settings admins must make sure that they are standing in the correct domain. The settings applied will only apply for the domain they are currently standing in. 

Registers

For information about the general functionality of the register please refer to the Registers user guide.

New Concession Deviation Request

Pressing this button generates a pop up for you to create a new form

1. Press "New CDR" and you will see the below pop-up
   
2. Select Project from the drop down menu
3. Input the request title
4. From the drop down menu select the required level of confidentiality. A person with a lower level of confidentiality setting will be able to see an individual form if nominated in the form to perform work. The system does not give a warning if a nominated user would not otherwise be able to see the form
5. Press "Ok"
   • On pressing "Ok" you will automatically be taken into the form for you to input required information.

Workflow - Concession Deviation Request

Toolbar

The buttons that are available in the toolbar depends on the users access. For more information please refer to the Common Functionality user guide.

Header

The CDR form header displays general information of the request.

Header Data

• Title - The form title entered by the originating person. This field can be edited.
• Status – The current status of the form. Current Pims status options for CDR are: 
  • Proposed - Initial status set when CDR created. Form is waiting for Originating Person to complete Section 1 and submit for verification and validation.
  • Open - Form is in the process of review and approval.
  • Approved for Implementation - Approved CDR is in the process of implementation.
  • Pending Close-Out - Approved and Implemented CDR is in the process of close-out.
  • Closed - Form has been Closed.
  • Rejected - Form has been rejected and closed.
  • Void - Form is no longer required and no further activity therefore required.
  • Superseded - Form has been superseded by a new revision.
• Number - A Unique Number assigned to the form.
• Target Approval for Implementation Date - The identified target date for approval.
• Target Close-Out Date - The identified target date for close out.
• Rev No. - Current revision of the form.
• Revision Date - Date the form was last revised.
• Originating Person - Person who entered the form into Pims.
• Originating Company - Company association of person who entered the form into Pims.
• Date Submitted - Date the form was submitted for verification and validation.
• Progress Indicator - Identifies which section in the form is currently live.

Section 1 - Initiate

Status - Proposed

Here the originating person inputs all the required information to sufficiently identify the form to be reviewed / approved.

Fields

• CDR Type - Identifies the type of CDR, either:
  • Concession
    • A concession is a request to depart from a specified requirement after an occurence.
  • Deviation
    • A deviation is a request to depart from a specified requirement in advance.
• Area Classification - From the drop down menu select the area most affected / linked to this form. Where multiple areas are affected, identify the highest level.
• General CDR Category - Input the primary General CDR Category of the CDR. Inputting the correct value is important to ensure the CDR is correctly categorized for performance tracking.
• Specific CDR Category - Input the primary Specific CDR Category of the CDR. Inputting the correct value is important to ensure the CDR is correctly categorized for performance tracking.
• Supplier / Contractor - The Contractor is an organization directly contracted by the Company to provide engineering, procurement, construction, installation, and/or commissioning services to the Company.
• Sub-Supplier - Identifies the sub-supplier affected by the CDR, i.e. the organization supplying the equipment.
• Supplier NCR Number - Identifies the Non-Conformance Request (NCR) ID related to the CDR. Although an optional field, where available this information should be supplied to aid tracking purposes.
• Supplier NCR Issue Date - Identifies the date the NCR was issued.
• Part Number - Here you can identify the equipment part number affected by the CDR. This field is primarily required where a concession is being requested however, may still be applicable to deviations. Where no part number is applicable, input “N/A”.
• Part Description - Here you can identify the equipment part description affected by the CDR. This field is primarily required where a concession is being requested however, may still be applicable to deviations. Where no part description is applicable, input “N/A”.
• PO No / Call-off No / WBS No - Input the PO No / Call-off No / WBS No of the equipment affected by the CDR.
• Affected Systems - Here you can identify any Engineering Systems affected by the CDR.
• Affected Commissioning Systems - Here you can identify and Commissioning Systems affected by the CDR.
• Serial Number - Here you can identify the serial numbers affected by the CDR. This field is primarily required where a concession is being requested however, may still be applicable to deviations. Where no serial numbers are applicable, input “N/A”.
• Tag Number - Here you can identify the tag numbers affected by the CDR. This field is primarily required where a concession is being requested however, may still be applicable to deviations. Where no tag numbers are applicable, input “N/A”.
• Affected Specification / Requirement - For you to identify and input the affected specifications / requirements from which the CDR has resulted from, e.g. an ETP, Project engineering specification, Procedure, etc.
• Affected Projects - Here you can identify other affected projects by the CDR. Note, only mandatory in selected projects defined in the Setup screen.
• Problem / Non-Conformance Description - Provide a clear and concise description of the problem / non-conformance, identifying how the specification / requirement has not been met.
• Proposed Disposition Type - Identify the proposed disposition type of how best to resolve the CDR.
• Proposed Disposition Description - Describe how best to resolve the CDR, including a description of any re-work or procurement of new equipment, etc. to be performed.
• Technical Justification - Provide a technical justification of how the proposed disposition description will solve the CDR.
• Associated References - Identify any additional document references to support the CDR, e.g. P&ID’s, datasheets, etc.
• Attachments - Upload any attachments to support the CDR, e.g. marked up documents, sketches, photos, etc.
• CDR Coordinator - Identify and nominate the CDR coordinator who will verify and validate the CDR and progress it for review and approval.

Signature

Here the Originating Person has one option:

• Submitted – All required fields have been completed and the form will move forward to Section 2.
  • On sign off, the status of the form will remain Proposed

Section 2 - Verify and Validate

Status - Proposed

The CDR Coordinator reviews the request to confirm it is valid to proceed and identifies the Target dates for Implementation and Close-Out and the Owner, Reviewer(s) and Approver(s).

Fields

• CDR Owner - The Owner is the person responsible for implementing and closing out an approved CDR, including:
  • Developing an Action Plan to implement the Approved CDR.
  • Validating the successful implementation of the Action Plan to confirm the CDR can be closed.
• Confidentiality - You will notice a value already appears in the box, this is because a level of Confidentiality is applied when the form is first raised. Here you have the opportunity to edit the Confidentiality (and thus limit who can see the form). Confidentiality access is linked directly to a person’s user account. Users can see forms of that confidentiality level and below. A person with a lower level of confidentiality setting will be able to see an individual form if nominated in a role on the form. The system does not give a warning if a nominated user would not otherwise be able to see the form.
• Primary Affected Delivery Line - From the drop down menu select the Delivery Line most affected / linked to the form.
• Target Approval for Implementation Date - Identify the date by why the CDR requires Approval for Implementation (i.e. Completion of Section 4), at which point the Approved CDR can be implemented. It is important this date is set correctly to minimise any potential impact to project schedule. The CDR will be performance managed against this date.
• Target Close-Out Date - Identify the date by why the CDR requires Closure (i.e. Completion of Section 6). It is important this date is set correctly to minimise any potential impact to project schedule. The CDR will be performance managed against this date.
• Attachments - Upload any attachments to support the CDR, e.g. marked up documents, sketches, photos, etc.
• Key Milestones - Here you can assign any relevant key milestones to the CDR.
• Reviewer(s) - Identify minimum 1 reviewer of the form to validate the CDR and proposal is agreeable.
  • The Owner cannot be a Reviewer.
  • The Reviewer does not have approve / reject rights, only agree / disagree.
• Approver(s) - Identify minimum 1 approver of the form to validate the CDR and proposal is agreeable.
  • The Owner cannot be an Approver.
  • The Approver does have approve / reject rights, i.e. they have the ability to approve / reject.
• Comment - Here you can add a comment to justify your signature type / any data you have input.

Signature

The signing options for CDR Coordinator are as follows:

• Accepted - You Accept the form is valid and requires review / approval.
  • On sign off, the status of the form will change to Open
• Rejected - The CDR Coordinator has rejected the form, which has been closed as a result.
  • On sign off, the status of the form will change to Rejected
• Recycle - This option should be selected if there is insufficient information to proceed. It is good practice to discuss with the Originating Person prior to recycling and to add a comment to justify the recycle. Selecting Recycle will return the form to the Originating Person in Section 1.

Section 3 - Review

Status - Open

On completion of Section 2, the CDR is submitted to the nominated Reviewer(s) for their review and comment.

Fields

• Comment - It is recommended you add a comment to justify the inputted impacts.
  
• Impacts - Input the impact values as a result of the CDR.
• Attachments - Upload any attachments to support the CDR, e.g. marked up documents, sketches, photos, etc.
• Related Forms - Identify any existing forms which are related to the CDR.

Signature

The signing options for Reviewer(s) are as follows:

• Agree - The Reviewer agrees with the CDR that it should be implemented as developed.
• Disagree - The Reviewer disagrees with the CDR, if this option is chosen the Reviewer is forced to add a comment to describe why they disagree with the CDR.

The signing options for CDR Coordinator are as follows:

• Recycle – The process is not followed correctly and the form is recycled back to Originating Person in Section 1.
• Submitted - Form is submitted for Approval in Section 5.
  • On sign off, the status of the form will remain as Open

Section 4 - Approval for Implementation

Status - Open

Once the Review is complete the form is submitted for Approval. Here the nominated Approver(s) review and approve the CDR accordingly for implementation.

Fields

• Target Approval for Implementation Date - This is the Date by which the CDR needs to be approved by, i.e. the date by which the CDR implementation can commence.
  • From time to time the date may change due to revised project priorities. In such instances a request should be made to the appropriate responsible person (i.e. CDR Super User) to request the date be changed.
  • Once approved, provide the written justification and approval of the date change to the PimsAdmin/Superuser for them to change the date.
  • Notes.
    • Only the Admin / Superuser can edit this date
    • This Date can be edited whilst Sections 3 or 4 are open
    • Any changes to the date shall be discussed with the required person(s), who have the authority to make the change, i.e. CDR Coordinator / Approver(s)
    • The request needs to include information such as:
      • What has caused the delay
      • The duration of the delay
      • Proposal for new date
      • Justification of new date
      • Evidence of the justification and approval (via email)
    • A written justification with approval should then be submitted to the Pims Admin (preferably via email) for them to make the necessary change in the system.
      • The email justification should then be attached to the form for historical / audit purposes
  • Examples of GOOD Request:
    • Work has been re-prioritized because of and as such the resultant work has been delayed by 2 months. In alignment this CDR needs to have it’s Target Approval Date changed to because this is the point by which the re-prioritized work will be required.
      • Evidence of the justification and approval can be found in the attached
  • Reason for being good request: Clearly describes why the delay has occurred, how long the delay is and when the Target Approval Date needs to be changed to.
  • Examples of BAD Requests:
    • I forgot
    • I did something else instead
    • I was on holiday
  • Reason for being bad requests: They do not meet the requirements for a date change, i.e. a valid justification as to why the delay occurred in the first place, the duration of the delay, a proposal for a new date and justification.
• Target Close-Out Date - This is the Date by which the CDR needs to be closed by, i.e. the date by which the CDR has been implemented and all relevant documentation completed and issued.
  • From time to time the date may change due to revised project priorities. In such instances a request should be made to the appropriate responsible person (i.e. Sponsor) to request the date be changed.
  • Once approved, provide the written justification and approval of the date change to the PIMS Admin/Superuser for them to change the date.
  • Notes.
    • This Date is linked to the “Target Close-Out Date” of any required Post Approval Implementation Actions
      • No Post Approval Implementation Actions can have a Target Close-Out Date later than this date
      • The nominated Approver cannot sign off Section 4 if this date is in the past
    • Only the Admin / Superuser /Nominated Approver(s) can edit this date whilst Section 3 and 4 and 5 are open
    • Any changes to the date shall be discussed with the required person(s), who have the authority to make the change, i.e. Sponsor / Approver(s)
    • The request needs to include information such as:
      • What has caused the delay
      • The duration of the delay
      • Proposal for new date
      • Justification of new date
      • Evidence of the justification and approval (via email)
    • A written justification with approval should then be submitted to the Pims Admin (preferably via email) for them to make the necessary change in the system.
      • The email justification should then be attached to the form for historical / audit purposes
  • Examples of GOOD Request:
    • Work has been re-prioritized because of and as such the resultant work has been delayed by 2 months. In alignment this CDR needs to have it’s Target Close-Out Date changed to because this is the point by which the re-prioritized work will need to be closed by.
      • Evidence of the justification and approval can be found in the attached
  • Reason for being good request: Clearly describes why the delay has occurred, how long the delay is and when the Target Close Out Date needs to be changed to.
  • Examples of BAD Requests:
    • I forgot
    • I did something else instead
    • I was on holiday
  • Reason for being bad requests: They do not meet the requirements for a date change, i.e. a valid justification as to why the delay occurred in the first place, the duration of the delay, a proposal for a new date and justification.
•  MoC Required - Here you need to identify if the approved CDR would result in an MoC being required.
  • No – The MoC Reference locks down and you proceed further
  • Yes – You are required to either create a new MoC or reference an existing one
    • On selecting Yes a pop up will appear giving you the option to either generate a new MoC or select an existing one from a drop down menu
  • The Status, Date Approved / Rejected and Date Closed fields will automatically populate based on the referenced MoC
  • Since Pressing “Yes” gives you the option to automatically raise the form, on changing a “Yes” to “No”, will give you the option to then Void the raised MoC
•  ETP DR Required - Here you need to identify if the approved CDR would result in an ETP DR being required.
  • No – The ETP DR Reference locks down and you proceed further
  • Yes – You are required to either create a new ETP DR or reference an existing one
    • On selecting Yes a pop up will appear giving you the option to either generate a new ETP DR or select an existing one from a drop down menu
  • The Status, Date Approved / Rejected and Date Closed fields will automatically populate based on the referenced ETP DR
  • Since Pressing “Yes” gives you the option to automatically raise the form, on changing a “Yes” to “No”, will give you the option to then Void the raised ETP DR
•  NEDR Required - Here you need to identify if the approved CDR would result in an NEDR being required.
  • No – The NEDR Reference locks down and you proceed further
  • Yes – You are required to either create a new NEDR or reference an existing one
    • On selecting Yes a pop up will appear giving you the option to either generate a new NEDR or select an existing one from a drop down menu
  • The Status, Date Approved / Rejected and Date Closed fields will automatically populate based on the referenced NEDR
  • Since Pressing “Yes” gives you the option to automatically raise the form, on changing a “Yes” to “No”, will give you the option to then Void the raised NEDR
• Comment - Mandatory to add a comment to justify your signature type / any data you have input.

Signature

The signing options for Approver(s) are as follows:

• Approved – The Approver(s) approves the CDR for implementation.
  • On sign off by the last Approver the status of the form will change to Approved for Implementation, and proceed to Section 5 Implement.
• Recycle – The Approver believe the CDR requires further work before Approval or Rejection.
  • On sign off the status of the form will change back to Proposed and return to Section 1 with the Originating Person
  • The user is forced to add a comment to justify the recycle
• Rejected – The Approver(s) disagrees with the CDR and does not believe it should be implemented.
  • On sign off the status of the form will change to Rejected
  • The user is forced to add a comment to justify the rejection

Section 5 - Implement

Status - Approved for Implementation

Here you need to identify if actions are required to implement the approved form.

Fields

• Actions Required to Implement Approved CDR? - ‘No’ should only be used in exceptional circumstances, e.g. if the CDR Implementation was “Retrospective” and the CDR has already been implemented. Any Project Actions required to be raised against the form can be raised here. On Pressing “Add Action” a pop up will appear and all fields are mandatory for completion:
  • Input the required Action Title
  • Validate the Confidentiality, if required change this to a different level by opening the drop down menu
  • Identify and Nominate an applicable Delivery Line
    • All Projects actions raised will be stored in the Project domain, so the list of available Delivery Lines here will be those from the current Project Domain
  • On completion of all information press Save
    • On doing so the Action form will open for you to complete accordingly
• Comment - Here you can add a comment to justify your signature type / any data you have input / describe any actions raised.

Signature

The CDR Owner cannot sign section 5 until the referenced forms have reached the required status, i.e.

• MoC – Needs to have reached status “Approved for Implementation”.
• ETP DR – Needs to have reached status “Endorsed”.
• NE DR – Needs to have reached status “Pending Close-Out”.

The CDR Owner have the following signature options:

• Recycle - The Owner returns the CDR back to the Approver(s) in Section 4 for additional input.
  • The user is forced to add a comment to justify the recycle
• Completed - The Owner confirms all actions have been Closed and the CDR has been implemented. 
  • On selecting this, the form will proceed to the CDR Coordinator to validate Closure and the status will change to Pending Close-Out.

Section 6 - Close-Out

Status - Pending Close-Out

Once all actions are closed, the form will progress to Section 6 for Close-Out.

Fields

• Comment - Here a user can add a comment to justify any work done / not done.

Signature

The signing options for CDR Coordinator are as follows:

• Completed – The CDR Coordinator validates all actions have been Closed and the CDR has been implemented.
  • On selecting this, the form will be closed at status Closed.
• Recycle – The CDR Coordinator has the option to recycle the form back to the Owner (in Section 5) if they feel the form is not completely closed.
  • The user is forced to add a comment to justify the recycle.