Child pages
  • Project Change Request (PCR) Process
Skip to end of metadata
Go to start of metadata

Once the baselines have been determined, all baseline changes are documented and approved through the change control process. Each year the project will determine the schedule, budget, and scope to be accomplished, and this information will be documented in a work package at level 3 of the WBS. The work package will include the distribution of budgets by institution. Budgets distributed through the sub-award process will follow NSF reporting requirements for tracking cost by NSF category. Many changes will result in document modifications (e.g., PEP, budgets, schedules).

A Project Change Request (PCR) form will document requests for any baseline changes. The PCR process allows for documentation of project changes that affect such components as scope, budget, staff, KPI/Area Metrics, and/or schedule changes. Any XSEDE staff member may submit a request to modify the execution of the project. Requestors will provide personal identification and contact information; the type of change requested (cost/budget, schedule, scope, etc.); reason for the change; expected cost, schedule, and technical impacts; and new or modified risks resulting from the change. Because PCRs may be public facing, the content of each should provide the appropriate context as part of the Explanation of Change. PCRs are submitted via a Confiforms form on the XSEDE Staff Wiki. Instructions for completing a PCR are also on the wiki. All change requests must be formally submitted using this online form.

Many different types of change requests require the completion of the PCR form (see the PCR FAQ for actions that require a PCR). The change request process is initiated once a PCR has been completed and submitted via the wiki. Information submitted via the PCR form is then used to create a Jira issue. In addition, some of the Information from the PCR is automatically entered into the Change Control Table, which is accessible by all XSEDE staff. Upon submission of a PCR and the subsequent creation of the Jira issue, the submitted information is directed to the Project Management & Reporting (PM&R) team (WBS 2.6.3). This team performs a preliminary evaluation of the change request and routes information to the appropriate stakeholders, including the decision authority. The PM&R team is responsible for guiding the PCR through the entire process until a disposition is reached. Approval authority for a PCR is determined by the PM&R team based on the nature of the change request. Once a PCR has been appropriately vetted and its disposition has been determined, the PCR submitter is notified of the disposition and the necessary processes to implement any approved change are initiated. Because the Change Control Table is dynamic, it is updated as change requests move through the process.

There are three levels of changes (major, moderate, and minor), which are described in Table 1 below. The level of the change is determined by the PM&R team who is responsible for coordinating the PCR process, including the identification of the appropriate approval authority. Minor changes are approved at WBS level 2 or 3, or by PM lead. The Project Director (PD) approves moderate changes, and major changes must be approved by the cognizant NSF Program Official or NSF-convened review committee. At the lead PM or PD’s discretion, PCR submissions may be presented to the XSEDE Senior Management Team (SMT) as an agenda item during the bi-weekly SMT meeting, depending on the nature of the request. Any significant changes directly affecting XD Service Providers will be sent to the XD Service Providers Forum for review and comment; the XD Service Providers Forum Chair is a member of the SMT. Additionally, the User Advisory Board and NSF will be consulted at the discretion of the PD. At the highest level, approval from NSF is necessary for major changes in technical scope, schedule, or cost.

As examples, NSF must approve any budget changes that impact total project funding. The PD must approve all changes that move budgets from one institution to another. PCRs that affect an institution’s SOW should be reviewed and approved by that institution’s subaward PI prior to approval by the PD.

It is anticipated that some change requests could have significant impact on one or more service providers and thus a workable conflict resolution process is essential, both here and in general. In such cases, SPs will be polled within a month for their reaction to such a change request. If an XD management consensus is achieved, but not complete agreement by the Service Providers who are required to implement the change, it may be necessary to involve the NSF in order to ensure full implementation.

The PM lead is responsible for implementing the baselines, and the project management team is ultimately responsible for ensuring the appropriate change(s) and ancillary processes are successfully followed. Thus all change requests are shepherded by the project management team from submission to disposition to implementation. Decision authority is vested in the WBS managers, PM lead, PM Deputy, PD, and NSF, or combination thereof, depending on the nature of the change. If a PCR is approved, the change will be incorporated into the project baselines as well as the PEP (as appropriate), and any other documents will be revised to reflect the new information following the configuration management practices of the project. A change request is considered complete once it is approved and implemented, is rejected, withdrawn, or annulled.

Table 1. Change Control Thresholds

Technical ScopeChange to PEP deliverablesModerate impact on the appropriate metricMinor impact on the appropriate metric
ScheduleAny delay in a deliverable milestone by > six monthsAny delay in a deliverable milestone by > three but < six monthsAny delay in a deliverable milestone by less than three months
Budget/CostAny change impacting total yearly funding or total project fundingAny change in a WBS Level 2 element or change that impacts funds by institutionAny change within a WBS Level 2 or 3
KPI/Area MetricNoneAny change to a KPIAny change to Area Metrics that are not also a KPI or a component of a KPI
StaffReplacement of XSEDE PDReplacement of XSEDE L2s, co-PIs, Assoc. project director, or PM leadReplacement of L3s
OtherAny major change, as determined by the PD or the PM lead, that doesn't fit into one of the other change typesAny moderate change, as determined by the PD or the PM lead, that doesn't fit into one of the other change typesAny minor change, as determined by the PD or PM lead, that doesn't fit into one of the other change types
  • No labels