Management of Change user guide

Type: User Documentation 26-Jan-2022 | Valdas Piekus

In this article

Management of Change

This document outlines the information required to enter the PIMS Management of Change module and use on the project.

PIMS is an electronic tool to facilitate the capture, development, approval, distribution and communication of project change. It does not replace the need to establishing proper protocols or behaviours of Management of Change (MoC). This user guide should be used in conjunction with:

Definitions and abbreviations

Workflow
Module process for completing the form.
Form
An individual numbered document held in PIMS. A form may be a Risk, Action, MoC or an IR form, which is submitted into the system.
Module
A specific module within PIMS, e.g. the Action Tracking module.
Action
A non-routine request or activity that requires formal, documented close-out and approval.
Change
Any technical, administrative or organizational adjustment to frozen conditions, whether permanent, temporary or emergency, with the potential to introduce HSSE, Risk or Delivery impacts.
Deviation
Any deviation from mandated requirements (Shall statement) within the spec.
BoDBasis of Design
DRDeviation Request
HSSEHealth, Safety, Security & Environment
MoCManagement of Change
PimsProject Information Management System - A product of Omega
S&ORSafety and Operational Risk
Originating PersonPerson who added the change into the system. Responsible for inputting initial information and identifying the Sponsor.
SponsorThe project individual who authorizes the use of resources, e.g. time / cost to further develop the MoC. Typically the technical lead engineer (TLE) / lead engineer (LE).
OwnerEngineer assigned to develop the MoC and all associated implementation requirements.
ReviewerDiscipline subject matter experts (SME) assigned to review the MoC.
Approver
Identified individual(s) with the authority and accountability for Approving or Rejecting a change. Typically includes the project manager (PM).

Accessing the system

To be able to view Management of Change forms a user must either be an Admin or have access to Management of Change for the Project.

Permissions

  • Global Admins can view all forms.
  • Portfolio Admin can view all forms.
  • Project Admin can view all forms.
  • Super users 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.

Navigation

Management of Change is accessed from the Pims menu. Click the "Changes" 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. Management of Change settings user guide.

Note: When using the Management of Change 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 Change

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

  1. Press "New Change" and you will see the below pop-up
  2. Select Project from the drop down menu
  3. Input the Change 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 - Management of Change

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 MOC header displays general information of the Management of Change.

Header Data

  • Change Title - The form title entered by the originating person
  • Status – The current status of the form. Current Pims status options for MoC’s are:
    • Proposed - Initial status set when MOC created. Form is waiting for Originating Person to complete Section 1 or Sponsor to validate the MoC in Section 2.
    • Open - Form is either in development or under review / approval.
    • Approved for Implementation - Form has been approved by all the nominated Approver(s) and the approved MoC is in the process of being implemented.
    • Closed - Form has been approved, implemented and closed.
    • Rejected - Form has been rejected and closed.
    • Replaced - Form has been replaced by another MoC and closed.
    • Void - Form is no longer required and no further activity therefore required.
    • Superseded - Form has been superseded by a new revision.
  • Change No - A Unique Number assigned to the form.
  • Target Approval for Implementation Date - The identified date which the MoC requires approval to prevent any delays to implementation start.
  • Target Close-Out Date - The identified date which the MoC requires closure to prevent any project delays.
  • 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 associated to the Originating Person in Pims. 
  • Date Submitted - Date the form was submitted for verification and validation (completion of Section 1).
  • Progress- Identifies which section in the form is currently live.

Section 1 - Initiate

Status = Proposed

This is the initial section of the change in Pims. It is here the originating person inputs all the required information to sufficiently identify the change to be reviewed / approved.

Fields

  • Describe the current situation / solution - HTML editor. Input a description of the current design / implementation that you want to change from.
  • Describe the proposed solution - HTML editor. Input a description of the proposed solution that you want to implement as part of the change.
  • Justification for Change - HTML editor. Input a description to justify why the change is required.
  • Preliminary Estimate - Cost - Text input. Input a “ball park” value or range as the initial estimated cost impact of the change proposal
  • Preliminary Estimate - Schedule - Text input. Input a “ball park” value or range as the initial estimated schedule impact of the change proposal
  • Associated References - Pims gives the option to reference any project documents that are applicable to the form without adding a copy. As a minimum the document number and revision should be included
  • Attachments - Add option pop-up. By pressing the Upload button when in a form, an attachment can be added to the form through the pop up that appears on screen. 
  • Affected Tags - Grid control. Type in or select tags from lookup list
  • Related Forms - Grid control. Here you can reference other PIMS-forms that are linked / associated to the change.
  • Sponsor - Drop down selection. Every change proposal needs to have an assigned change sponsor, who is responsible for that particular MoC, usually a delivery line manager.
  • Other Information - Comment control. Any additional information you need to supply to aid validation of the MoC can be supplied here.

Signature

Drop down selection and Submit button. 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

In this step the nominated Sponsor is responsible for all fields. It is important to ensure the correct Owner and Target Dates are identified to minimize any delays to the MoC development and performance management tracking.

Fields

  • Owner - Drop down selection. The Owner is the person who will fully develop the MoC. As such it is important the correct person is identified to act as the Owner.
  • In Project Scope - Yes / No selection. Indicate if the change is within project scope or not.
  • Target Approval for Implementation Date - Calendar selection. Identify the date by which the MoC requires approval for implementation (i.e. completion of section 5), at which point the approved MoC can be implemented. It is important this date is set correctly to minimize any potential impact to project schedule. The MoC will be performance managed against this date in step 5.
  • Target Close-Out Date - Calendar selection. Identify the date by which the MoC requires closure (i.e. completion of MoC), at which point the approved MoC can be closed. It is important this date is set correctly to minimize any potential impact to project schedule. The MoC will be performance managed against this date in step 7.
  • Comments - Comment control. Here you can add a comment to justify your signature type / any data you have input. It is strongly recommended that if you reject / recycle that you add a comment to justify why.

Signature

Drop down selection and Submit button. Here the Sponsor has three options:

  • Accepted – You accept the MoC is valid and requires further detail work to develop fully.
    • On sign off by the Sponsor in Section 2 the status of the form will change to Open
  • Rejected - The Sponsor 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 2.

Section 3 - Development

Status = Open

In this step the nominated owner develops the MoC including identifying the details of the change, any pre and post approvals actions, performs a risk assessment, identifies any impacts and identifies the review(s) and approver(s).

Fields

  • Pre-Review Actions Required? - Yes / No selection. The owner has to decide if any pre-review actions are required. If you select:
    • Yes – you are forced to raise at least one pre-review action.
    • No – The pre-review Action Tracker is locked and you do not have to raise a pre-review action.
  • Pre-Review Actions - Action Tracking control. Any pre-review Actions required to be raised against the form can be raised here. These are actions that are required to be performed to aid in the development of the MoC prior to submitting the form for review / approval.
    • Section 3 cannot be signed off by the Owner until ALL pre-review Actions are closed.
  • Update description of the current situation / solution - HTML editor. Content from Section 2 is copied down to here. The Owner needs to edit the content as needed to provide latest / more detailed information as to the current situation / solution.
  • Update proposed solution - HTML editor. Content from Section 2 is copied down to here. The Owner needs to edit the content as needed to provide latest / more detailed information as to the current proposed solution.
  • Update justification for change  - HTML editor. Content from Section 2 is copied down to here. The Owner needs to edit the content as needed to provide latest / more detailed information as to the current proposed solution.
  • Type - Checkbox control. Indicate if the change affect any of the following:
    • Technical Documents.
    • Procedural Documents.
    • Training and Competency materials.
    • Commercial Documents.
    • Organizational.
  • Confidentiality - Drop down selection. 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 Discipline - Drop down selection. From the drop down menu select the Discipline most affected / linked to the form.
  • Implementation Type - Drop down selection. There are four options available:
    • Permanent changes will remain in effect for the duration of the project and beyond.
    • A Temporary change is defined as a change that has a pre agreed duration and will not significantly alter the content or intent of, or require revisions or modifications to, design documents, processes, procedures, policies, etc.
      • On selection of a Temporary Change Implementation you are forced to identify a Start and End Date.
      • If the Start or End Dates change in the future, you need to recycle the form back to Section 3, change the dates accordingly and re-submit for review / approval.
    • An Emergency change is a necessary change to maintain continuous safe execution of work or to mitigate immediate HSSE threat. It will have been agreed outside of the formal MoC process by the duty holder. The MoC form must be completed as soon as practical or the change reversed .
    • Retrospective changes are changes that have been implemented without being reviewed, approved or documented. The Change proposal is an essential catch up exercise. These type of changes should be kept to an absolute minimum and notified immediately to the PGM, Delivery Team Leader, and if necessary the engineering manager.
  • Associated References - Pims gives the option to reference any project documents that are applicable to the form without adding a copy. As a minimum the document number and revision should be included
  • Attachments - Add option pop-up. By pressing the Upload button when in a form, an attachment can be added to the form through the pop up that appears on screen. 
  • Affected Tags - Grid control. Type in or select tags from lookup list
  • Related Forms - Grid control. Here you can reference other PIMS-forms that are linked / associated to the change.
  • Has Risk Assessment been performed? - Yes / No selection. Indicate if an assessment of the change has been performed.
  • Describe any HSE, Operability, Maintainability and Reliability Impact - HTML Editor. Describe any HSE, Operability, Maintainability and Reliability impact of implementing the Change, this could be both positive and / or negative, e.g.:
    • Reduced Maintainability because ...
    • Reduced Operability because ...
  • Describe any Cost, Schedule or Reputation Impacts - HTML editor. Describe any business risk impact (e.g. Cost, Schedule, Reputation, etc.) of implementing the Change, this could be both positive and / or negative, e.g.:
    • Reduced weight because ...
    • Increased cost because ...
  • Funding Source - Drop down selection. Identify where funding will come from.
  • Estimated Project Impacts - Grid control. Input the value of the impact. To add a new Impact
    • Click in the cell in the bottom row (indicated with a star symbol in row selector).
    • Select the impact from the drop down selection.
    • Input the value.
  • Reviewers - Multi-option selection. The change Reviewer(s) have a significant role in the execution of this MoC Process. They are responsible for performing a thorough cross discipline review of the proposed solution ensuring a clear understanding of the content, consequences and risks of the Change within their respective area of expertise. The level and format of the review should be appropriate for the complexity of the proposed change and the potential hazards the Change poses.
    • Reviewers ONLY have input rights, i.e. they cannot approve / reject a change.
    • An Owner cannot be assigned as a Reviewer.
  • Approvers - Multi-option selection. The Change Approver has the authority and accountability for approving or rejecting a Change. Typically there will be different levels of approval depending on the scope, type or impact of the change and the individual’s delegation of authority.
    • An Owner cannot be assigned as an Approver.
  • Comment - Comment control. Here you can add a comment to justify your signature type / any data you have input. It is strongly recommended that if you reject / recycle that you add a comment to justify why.

Signatures

The signing options for the Owner are as follows:

  • Submitted – The form is submitted to the Sponsor for their endorsement.

The signing options for the Sponsor are as follows:

  • Endorsed – The Sponsors endorses the developed MoC for review / approval.
    • On sign off by the Sponsor in Section 3 the status of the form will remain as Open
  • Rejected - The Sponsor has rejected the form, which has been closed as a result.
    • On sign off the status of the form will change to Rejected
  • Recycled - This option should be chosen if the form is not validated / technically correct. The form will be returned to Owner in Section 3 for re-work. The user is forced to add a comment to justify the recycle.

Section 4 - Review

Status = Open

On completion of Section 3, the MoC shall be submitted to the nominated Reviewer(s) for their review and comment.

Fields

  • Comments - Comment Control. Here you can add a comment to justify your signature type / any data you have input. It is strongly recommended that if you reject / recycle that you add a comment to justify why.
  • Attachments - Add option pop-up. By pressing the Upload button when in a form, an attachment can be added to the form through the pop up that appears on screen. 
  • Related Forms - Grid control. Here you can reference other PIMS-forms that are linked / associated to the change.
  • Edit Reviewers - Multi-option selection. By clicking "Edit" in the signature area on can edit the existing list of applied reviewers to meet current requirements.

Signatures

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

  • Agree – The Reviewer agrees with the MoC that it should be implemented as developed.
    • On sign off by the last Reviewer in Section 4 the status of the form will remain as Open
  • Disagree – The Reviewer disagrees with the MoC, if this option is chosen the Reviewer should first add a comment to describe why they disagree with the MoC.
    • On sign off by the last Reviewer in Section 4 the status of the form will remain as Open

Section 5 - 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 MoC accordingly for implementation.

Fields

  • Target Approval for Implementation Date - Calendar selection. Copied from Step 3, but can now be altered if necessary. Identify the date by which the MoC requires approval for implementation (i.e. Completion of Section 5), at which point the approved MoC can be implemented. It is important this date is set correctly to minimize any potential impact to project schedule. The MoC will be performance managed against this date in step 5.
  • Target Close-Out Date - Calendar selection. Copied from Step 3, but can now be altered if necessary. Identify the date by which the MoC requires closure (i.e. completion of MoC), at which point the approved MoC can be closed. It is important this date is set correctly to minimize any potential impact to project schedule. The MoC will be performance managed against this date in step 7.
  • Comments - Comment control. Here you can add a comment to justify your signature type / any data you have input. It is strongly recommended that if you reject / recycle that you add a comment to justify why.

Signatures

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

  • Approved – The Approver(s) approves the MoC for implementation.
    • On sign off by the last Approver the status of the form will change to Approved for Implementation.
  • Rejected – The Approver(s) disagrees with the MoC 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.
  • Recycle – The Approver believe the MoC requires further work before approval or rejection.
    • On sign off the status of the form will change back to Open and return to Section 3 with the Owner.
    • The user is forced to add a comment to justify the rejection

Section 6 - Implement

Status = Approved for Implementation

Once a Change Proposal is approved for implementation the form is returned to the change Owner in Section 6 for them to assign any actions required to implement the approved MoC. Examples of such actions are:

  • One Cost Engineer to update / transfer funds to the relevant budget.
  • One member of Engineering Team to update documents / drawings.
  • One member of Procurement to procure required.

Fields

  • Actions Required to Implement Approved MoC? - Yes / No selection. Here you need to identify if actions are required to implement the MoC.
  • Actions - Action Tracking control. Any Actions required to be raised against the form can be raised here.
  • Comment - Comment control. Here you can add a comment to justify your signature type / any data you have input. It is strongly recommended that if you reject / recycle that you add a comment to justify why.

Signatures

The signing options for Owner are as follows:

  • Completed – The Owner confirms all actions have been closed and the MoC has been implemented.
    • On selecting this, the form will proceed to the Sponsor to validate closure, and status will remain as Approved for Implementation.
  • Recycle – The Owner recycles the form back to Section 5 for re-evaluation.
    • The user is forced to add a comment to justify the recycle.

Section 7 - Close-Out

Status = Approved for Implementation

Once all post approval actions are closed (or actions required is set to “No”), the form will progress to Section 7 for Close-Out.

Fields

  • Comment - Comment control. Here you can add a comment to justify your signature type / any data you have input. It is strongly recommended that if you reject / recycle that you add a comment to justify why.

Signatures

The signing options for Sponsor are as follows:

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