Using SpiraPlan for Configuration & Change Management

September 29th, 2022 by inflectra

We recently demonstrated SpiraPlan to a large, multinational life sciences manufacturing company. During the series of demonstrations and proof concepts, we configured SpiraPlan for a set of different use cases, including demand management, application portfolio management, vendor selection and management, change management, application decommissioning, configuration management, and supplier qualification. In this series of articles, we will be highlighting these different use cases and providing best practices and ideas for how to configure SpiraPlan. In this article we will be covering the topic of configuration management and change management.

Change Management Banner

Before we discuss how SpiraPlan can assist with both change and configuration management, we first need to clarify the similarities and differences between these two key areas:

Change Management
Configuration Management

As described in this great guide "Configuration Management vs Change Management", “Change Management” is how you manage changes related to project management plans, processes, and baselines, whereas "Configuration Management" is how you manage changes related to product scope. Note that there are many similarities and interconnections between the two.

Therefore a change control process should be designed to handle both change and configuration management, since a request to change the schedule of a project might require a corresponding change in scope (for example).

Change Management Overview

Change Control is focused on identifying, documenting and controlling changes to the project and the project baselines. In the change management system, you manage the changes related to the project scope, planning, and baselines. For example, you run out of money and you need additional funding to complete the project, therefore, you will raise a change request for additional funds. Or, you may not be able to complete your project within the specified time and require a time extension. In the change management system, the change request is analyzed for any possible impact on any other project objectives. Afterwards, the request is either approved or rejected. To minimize disruption, a change management system must ensure that all parameters are identified and analyzed for any possible impact. If the change request is approved, you will update the concerned baseline, update the project documents, and inform the concerned stakeholders.

Change Management Activities

You do the following during change management:

Identify the changes.
Prepare a proper documentation for the changes.
Review, analyze, and make a decision for the change request.
Make sure that request is implemented, registered and communicated.

Configuration Management Overview

Configuration Control focuses on the specifications of both the deliverables and the processes. In the configuration management system, you manage the changes related to the product specification and the process. For example, suppose you are developing a product and the client requests the addition of some extra features. Since this change is related to the configuration of the product, you will deal with this change using the configuration management system. Configuration management documents how you will monitor and control changes. It; i a process of defining configurable items (product, service, result, and component) and controlling changes to such items. The configuration management plan keeps version control of the product. It's critical for effective application development, especially when you need to understand the security of your software supply chain, and plan for unanticipated side effects and risks associated with making changes.

Configuration Management Activities

You do the following during configuration management:

Identify the configurable items.
Record and prepare a report for all configurable items.
Verify and conduct an audit of all configurations are as per the requirements.

What is a Change Control Board (CCB)?

In software development, projects and programs, a Change Control Board (CCB) is a committee that consists of Subject Matter Experts (SMEs) and Managers who decide whether to implement proposed changes to a project. The factors affecting a CCB's decision can include the project's phase of development, budget, schedule, and quality goals. The CCB will be responsible for making decisions related to both the plans/timelines and the scope/requirements, so a CCB is technically involved in both the change management and the configuration management.

The Change Control Board will review any proposed changes from the original baseline requirements that were agreed upon with the client. If any change is agreed upon by the committee, the change is communicated to the project team and the client, and the requirement is baselined with the change. The authority of the Change Control Board may vary from project to project, but decisions reached by the Change Control Board are usually accepted as final and binding.

What is a Change Request

A change request is a proposal to alter some aspect of a given project. Change requests can originate either internally or externally. For example, the client may request a change to the agreed-upon deliverables, or you may receive a change request form from a team member who’s actively working on the project. Either way, without a formal change request process in place, these proposals can easily get lost, buried, or simply overlooked.

Adjusting the scope or deliverables of a project without a proper change request process can also cause confusion and misalignment of the project team and project stakeholders.

The Steps in a Change Request Process

The key steps in a change request process should be something like:

Understand the requirement, scope or schedule change
Investigate the change to understand its benefits and impacts
Review the results of the investigation as part of the CCB
Approve (or reject) the proposed change
Implement the proposed changes
Test and verify the changes work as expected, document any side effects
Update the requirements, documentation, and other configuration items
Communicate the changes to impacted stakeholders
Release the changes into production

If you'd like to see a sample Configuration and Change Control Process using SpiraPlan, we have this useful whitepaper - Managing the Change Control Process with SpiraPlan.

Configuring SpiraPlan for Managing Change Requests

Incident Types, Statuses and Fields

The first step is to login to the system, choose the appropriate product/project, and create a new incident type called 'Change Request':

For now, leave this incident type pointing to the Default Workflow. We will change this later when we create the workflow.

Next, we can add any custom properties that are specific to a Change Request and are not part of the standard 'incident' template:

For example, you might want to add custom properties to track: high level risks, actions, criticality, and area.

Next, we need to add any incident statuses that will be part of this workflow. You can reuse any existing incident statuses that are present from other workflows (New, Open, Assigned, Closed), but you may want to add additional ones, for example: Approved, Rejected, Released:

Once you have the statuses added, the next step is to create the workflow itself.

Incident Workflows

Go to the Incident Workflow list for the project template and create a new "Change Request Workflow":

Next click on the 'Steps' button for this workflow and you will be able to see the various statuses and transitions between them:

You can now add transitions to link the different change request steps together in the workflow.

Furthermore, you can click on the transition and determine (by role) who can change the status of the change request. In addition, you can choose to require an electronic signature, if applicable.

You should also click on each of the change request steps / statuses and make sure that the appropriate standard fields and custom properties are visible, hidden, required, or default.

In the example above, we have made the custom property High Level Risks required.

Finally, go back to the list of incident types and change the "Change Request" type to use your new workflow:

You are now ready to submit your first change request.

Using SpiraPlan for Change Management

Now that we have setup the system, we can submit a sample change request.

Creating the Change Request

First you will go to the Incidents section of SpiraPlan and log a new incident. When you change the type to 'Change Request', the appropriate fields will be shown for that incident type:

Now you can complete the change request, attach any relevant documentation as an attachment and submit the request. You will also want to link the change request to any configuration items such requirements that are impacted via. Associations:

If the change request affects other configuration items such as documentation, you may also want to link it to the documents in the Attachments tab as well:

Reviewing and Approving

The change request is now assigned to a reviewer, who will then either approve or reject the item.

The workflow can have multiple review steps, and you can add the option to enforce an electronic signature. You can also require that they fill out certain mandatory fields after each change of status:

The approver might want to capture additional information in either the comments or special fields.

Any changes to the change request will be sent to all stakeholders using the notifications functionality:

You can add additional stakeholders to the change request, using the 'Add Followers' option.

Updating or Creating Requirements

Once the change request has been approved, you can then either use it to update the contents of the linked requirement:

Or alternatively, you can use the special option 'Create Requirement from Incident' to create a new requirement from the change request, and then nest that under the original parent requirement:

The benefit of this approach is that it lets you track each change to the requirement in a more granular manner, assign to a different release/sprint as the parent, and have different associated test cases.

Updating Code Assets

If the approved change request will affect code assets (e.g. in a software development project), you can tag the code commits with the relevant change request ID and requirement ID:

Or if you forget, you can always associate it after the fact inside SpiraPlan itself:

Identifying Risks

Finally, as part of the change control process, you will have identified possible impacts and side effects of the proposed changes. These can be logged into the SpiraPlan risk management module and then associated with the change request:

Using SpiraPlan for Configuration Management

In addition to managing the changes to the system requirements and other project artifacts, SpiraPlan can manage general configuration items in its document repository:

The document repository contains the ability to track the changes to documents, both the different versions of the document, as well as the changes to the various metadata fields:

You can link these configuration items to the different change requests, using the Associations tab.

Baselining Configuration Items

Finally, you can use the built-in SpiraPlan baseling feature to track all changes made to configuration items between different baseline snapshots:

Summary

In this article, you have seen how important it is to have a change management and configuration management process on a project. You have learned about the main steps in a typical change control process, and you have seen how to configure SpiraPlan to handle both your change management and configuration management processes.