Why do we Control Change on a Software Implementation Project?
Before we go much further I would like to clarify the type of Change Control I am focusing on here.
Change Control is often referred to as “a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner.” Usually, that mean the safekeeping of a production software system by controlling code changes, apply regression testing, etc.
That is not the topic of this post, well not exactly. I am concentrating on Controlling and managing the changes that happen to a software implementation project and the project scope throughout its life cycle.
Poorly handled Change Control on a project can lead to overages in the budget, timeline, as well as resource burnout, or compromised quality. None of which will make the project stakeholders, executives sponsors, and just generally the client happy.
Planning on not having any changes on a project and just rejecting them all, and sticking to the initial scope is a lofty ambition, but probably not very realistic. Most projects these days use a Hybrid approach that marries the benefits of a Waterfall driven approach with the speed and iteration that Agile brings. By default that will lead to discoveries and learnings throughout, and thus to changes that we need to manage and control.
It is crucial to look at each proposed change individually, as well as the cumulative effect of proposed changes. We need to ensure they are well defined, and reviewed by subject matter experts representing the impacted areas. could include:
Defining & reviewing proposed changes could include:
- A system architect to weigh in on the impact the change has on the overall system functionality, or integration between systems or modules
- A data migration lead, to assess the impact the change may have on data cleansing, staging, and loading that may already be occurring
- A functional consultant to determine whether the change can be achieved using configuration or may require development
- A developer to estimate the effort it will take to code and unit test a proposed change and regression test the surrounding areas to avoid adverse effects in the periphery of the updated code
- A project manager to assess the resources required to do the work, what their capacity and availability is and therefore the impact on the timeline, if additional resources are required to add skills or capacity there is further a budget impact to quantify
Using a fairly simple change request form that guides the requestor and the reviewers through the different aspects is often very helpful. It does not require bureaucracy or a lot of administration to be diligent.
It may turn out that some changes are large enough to be their own subsequent project. They may need to be deferred to a phase II. Other changes may be traded in for something that was deemed in scope initially and would have used similar or the same resource to work on.
Once the answers are known to the aspects we have looked at the project manager should prepare options for the decision makers to choose from. Ideally, the project manager will give the decision makers a recommendation with the options. If the project team has a clear preference what they want the decision to be they should state that.
Once proposed changes have been reviewed the project manager will:
- Inform the decision makers of the cost and timeline impact if they approve the change as requested
- What rework or redo will this cause? What documentation has to be revised to account for it (I.e. test cases, training manuals, online help, etc.)?
- What other items may need to be removed from scope to make the change cost/timeline neutral if applicable
- What impact would the users experience if the proposed change was deferred to a future enhancement project, or a phase II?
- What is the increase in risk exposure if the change is approved, nothing is removed from scope, and no resources are added – will resources burn out? Are we compromising quality just to get it done?
Of course, it matters greatly on a project in which phase a change is proposed. A change to design decisions while the project is still in the Design and Create phase is potentially easier to absorb, than the same change proposed weeks before go-live in the midst of User Acceptance Testing.
Establishing a good discipline to document, review, assess and decide on changes during the project will not only help bring the project in on time and budget, but also nicely prepare the organization to do the “other Change Control” post go-live, and review code or configuration changes before they are being applied.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.