Configuration management is the overarching process of organizing and maintaining a development cycle. [1] The configuration refers to specific features of the product, how they should be implemented, and documenting changes to them. [3] Configuration management is often used by the manager of the development team to inform the stakeholders how the project will proceed.

**Image from CRR Supplemental Resource Guide V3 [5]

Change control is most often used within configuration management. Change management is the specific process of requesting, approving/denying changes, implementing them, and documenting them. [1] This process of change approval or denial helps to keep the project goals at the forefront while also monitoring and managing changes to the system.

As depicted below, the change control process can be simple even with multiple departments contributing to the approval. Creating a graphic like the below can help inform team members of how this will work in their environment. Be sure to include the approval contact, forms required, and any guidelines you deem necessary.

Geeks for Geeks graphic [1]

Configuration management is a useful tool in helping managers plan efficiently to meet project requirements. The management report can also be shared with stakeholders to demonstrate progress with deliverables. [3] However, if the implementation plan is flawed, switching to this type of system can cause irritations in the development team due to increased documentation like the requests. Ensuring that communication is good while converting to a new organization system can help to prevent many miscommunications and forgotten ideas. When it is implemented correctly, it can help the project feel flexible and accommodating to both developers, security, and stakeholders. [1]

To begin the process of configuration management, you must have a plan. The plan will likely change slightly for each project, but generally includes the same bits. The plan dictates what items are considered configurations/deliverables, how they will be completed, tracked, and tested.

Identifying the key configurations for the project is essential because it tells the team what to track and what types of changes will be under the change control system. The plan should also layout a standardized method of requesting changes, documenting changes, and testing them. Having all of these things in one place serves as a project management document that can relay progress to stakeholders and upper management. [3]

After the plan is in place for the baseline, it would be wise to examine the project budget to see what bonus features there is allocation for, or what features would be cut if a significant delay occurred. This can help set expectations for everyone in the project in terms of feature importance. [5] In other words, comparing the budget to the plan can help to create a plausible back up plan that meets as many requirements as possible. The baseline would be adjusted if a new feature is selected, if the main function of a feature is altered, or anything in the plan changes so that documentation is extremely accurate. This helps developers and stakeholders ensure what they want and need is satisfied. Changes to the plan would occur in change management with a change request, approval, and documentation updates.

Once the plan is in place, development begins. As customer feedback comes in, the baselines may shift, and those changes must be approved and documented to ensure they are verified and validated accurately in testing. The configuration management plan will also track those changes along the way such as requested, approved, implemented, tested, and complete.[3] The requested changes will alter the overall baseline a bit, but generally not a full re-configuration.[6]

With an organizational system like this in place, you can expect a change request every time a feature is added or removed from the project plan. There would be updates provided as each node or module of the software is completed, tested, etc. so that the configuration management plan can be updated. This keeps the shareholders in the loop directly with what developers are working on.

Before implementing a plan like this, I would strongly recommend some preparation. Aside from update request forms and the actual storage of information, the initial configuration plan needs to be laid out per project, one size does not fit all due to specificity. It could be beneficial to have a few meetings with developers and shareholders so that all requirements are documented, and thus tracked as part of the system. Additionally, it could be a new process for some members of the team, so some training would ensure that everyone can jump in to participate at the same level of organization. With careful planning and open communication, it should be a welcome process organization at MeCo that helps the development team deliver more accurate projects equipped with full documentation.

Resources:

[1] https://www.geeksforgeeks.org/project-management-configuration-management-and-change-control/

Review: After each major lifecycle, update the plan of significant changes made to highlight most current project plan and approval from the senior manager.

[2] https://pmcenter.bellevue.edu/2020/01/14/configuration-management-vs-change-management/

Review: Recommended use cases and examples, types of activities

[3] https://www.indeed.com/career-advice/career-development/configuration-control

Review: Categories of trackable items,

[4] https://www.indeed.com/career-advice/career-development/configuration-management-plan

Review: Definitions for config, roles,

[5] https://www.cisa.gov/sites/default/files/c3vp/crr_resources_guides/CRR_Resource_Guide-CCM.pdf

Review: How to plan, graphics, monitoring after implementation,

[6] https://www.geeksforgeeks.org/5-most-effective-steps-to-change-management/

Review: Recommended steps for success