Change Management Process (CMP)

A defined and accountable Change Management Process (CMP) has been established to ensure that the SDSFIE family of standards and SDSFIE Online meet requirements specified by its primary users, the Components represented in the IGG. The CMP is used to submit, evaluate, adjudicate, implement, and document suggested changes to SDSFIE.

There are four primary types of change requests (CRs) made by the Component users:

    1. Model CRs, which involve one of the data model standards – e.g., Vector or Metadata, and include:
      a. corrections to model errors (typos, grammar, missing elements)
      b. model revisions (alteration of names or definitions)
      c. model additions (“extending” the model with new elements) and deletions (“profiling” existing model elements)
    2. Tool CRs, which include:
      a. bug fixes
      b. alterations of existing functionality
      c. additions of new functionality
    3. Website CRs, which include:
      a. bug fixes, and corrections to the website content
      b. reorganization of content, and/or changes to site menu(s) or navigation
      c. change to page content or page/site functionality
      d. addition or deletion of content or page/site functionality
    4. Quality of Raster CRs, which refer to the SDSFIE-Q and SDSFIE-R standards documents:
      a. corrections to document text (typos, grammar, missing elements)
      b. changes to the meaning of existing text
      c. additions and deletions

CMP – The Process

The Change Management Process (CMP) is a series of related processes for managing change in SDSFIE Data Standards and the SDSFIE Online website and tools. This process is fully described in Section 3.4.7 of the SDSFIE Governance Plan, R3.

To ensure efficiency, in February of 2016 the IGG approved modifications to streamline the CMP, and to establish a vetting process to differentiate suggested changes that are valid Formal CRs from those that are “bug fixes”.

The modifications explore the type and nature of a suggested change (as described below), using a process summarized in the following flowchart:

Figure 1: CMP Flowchart


The CMP has two primary divisions, according to:

    1. whether the change is in the domain of a Model, or for the Website or a Tool.
    2. the nature of change being requested or reported.
Domain of Change – dictates where the CR will be adjudicated

Changes involving SDSFIE-Vector or SDSFIE-Metadata are reported to the SDSFIE Support Contractor and are adjudicated in the Working Group (WG) that corresponds to the model in which the change is being requested. For example, changes to the vector model are adjudicated by the SDSFIE-V WG.

Changes involving the SDSFIEOnline website, or a Web Tool accessed therein, are reported to the SDSFIE Support Contractor and are adjudicated by the SDSFIE Online WG.

Nature or Degree of Change – dictates what sub-process the CR will follow

To ensure an efficient process, the SDSFIE Support Contractor should be contacted about the potential CR prior to preparing a Draft CR or before submitting a Formal CR. Contact can be made either via email, phone, or during the SDSFIE Online WG meeting. Communication will ensure that:

  1. The issue is a valid CR, and not just a minor bug fix.
  2. The issue has not already been addressed, possibly through another registered CR.
  3. The issue will be addressed through changes being made, under development, or for which plans are already in place.

A bug fix was defined as simple corrections and changes which can be addressed with relatively minimal effort, including changes for simple corrections (typo, grammar, missing word, broken link, or improper function, etc.) to an SDSFIEOnline web page, or a Web Tool. Website and Tool changes that are determined to be bug fixes will not go through the formal CMP, but rather through the SDSFIE Support Contractor’s bug tracking and management system. Bug fixes should be reported to the SDSFIE Support Contractor within SDSFIE Online WG meetings, or through alternate means of communication.

Formal Change Management Process

Suggested changes that qualify as Formal CRs, enter into the Formal CMP Process, which is described in Section 3.4.7 of the SDSFIE Governance Plan, can be summarized as follows:

  1. Step 0 (Optional) – Process Draft CR. Components may use an internal process to create and adjudicate Draft CRs prior to submitting a Formal CR to the CMP.
  2. Step 1 – Submit Formal CR. Components, DISDI, or the Support Contractor may draft and submit a Formal Change Request (CR) by identifying a potential change and then developing a Formal CR.
  3. Step 2 – Analyze Formal CR. Once a Formal CR is submitted, the CR is analyzed through the following sub-processes and activities, with the two possible outcomes (accepted or rejected):
    1. o a policy review by the IGG Chair,
      o a feasibility analysis (which differs according to the type of CR being considered) by the SDSFIE Support Contractor,
      o a cost/benefit determination activity conducted by the SDSFIE Support Contractor, and
      o an implementation cost and schedule proposal prepared by the SDSFIE Support Contractor and submitted to the SDSFIE COR.
  4. Step 3 – Develop Change Recommendation: Once the Formal CR has been analyzed and accepted, a recommendation is developed by the IGG Chair in collaboration with the SDSFIE Support Contractor.
  5. Step 4 – Evaluate CR Recommendations: Once a recommendation is developed the IGG (or its delegated Working Group) approves or rejects the recommendation by consensus.
  6. Step 5 – Implement and Review Change: Once a recommendation is accepted, it is forwarded to the SDSFIE COR for implementation by the SDSFIE Support Contractor. Once implemented, the change is tested and approved (the implementation may need to be updated to pass testing).

Change Management In Practice

Draft CRs submitted by users will first be evaluated by the appropriate Component Representative and then submitted to the IGG via the SDSFIE Automated Process Portal (/A/P/P).

Because the different IGG Components use differing processes for vetting user change requests, please check with your Component IGG representative BEFORE submitting change requests for consideration.

Click here to visit the SDSFIE /A/P/P - Change Requests Page