In software development, changes midway through the project’s life cycle are nothing out of the ordinary and can arise for a variety of reasons, such as shifts in market trends and end-user demands.
Agile software development accommodates change requests to some extent, but many managers still have a lot to learn about how to manage it effectively. PMI’s 2017 survey found that 28% of participants named poor change management one of the primary reasons for project failure.
That’s problematic, to say the least. So how should you accommodate the necessary changes without undermining your delivery?
By adopting a systemized change request process. In this post, we’ll explain to you what it entails.
What Is a Change Request?
A change request (CR, also called a change request document or CRD) is a formal document that describes the scope of necessary alliterations from the original specs.
Now, what is the change management process, and how does it work in outsourced projects?
In short, a change management process is your system for initiating, logging, analyzing, approving, and resolving project changes. Different people involved in a project (from the client’s side and the outsourcing team) can initiate a change request at any stage of the software development lifecycle.
Who Should Be Involved in the Change Management Process?
Most change management in software development occurs early in the lifecycle. For example, when the development team identifies a bug or inconsistency in projects requirements. But this isn’t the only scenario. Additionally, feedback from your customers or new market requirements can trigger a need to send a change request to your outsourcing team.
To better understand the mechanics of the change request management process, let’s take a look at the key people who should get involved.
- The client (outsourcing customer, or product owner). You can initiate a change yourself by creating a change request document and filing it to other project stakeholders. You may need to consult with other decision-makers about significant alterations and their impact on development. What’s more, you’ll also sometimes need to evaluate CRDs proposed by your outsourcing team.
- Your outsourcing team (vendor). The project manager evaluates the change request documents you file to determine the feasibility of changes. To do this, they can request additional information, conduct risk simulations to evaluate impact, or modify the request and file it back to you for approval. After your request is approved, the project manager proceeds with adding the change to the approved scope of work. The project manager/lead also manages change requests filed by the development team.
- Other stakeholders. Also, you may need to seek approval from your board of directors, shareholders, tech leads, or CIO about critical change requests that significantly alter a project’s budget estimates, schedule, or scope. In some cases, these stakeholders can also initiate a change request.
NB: Read more about different project roles, needed to support project delivery.
How to Manage Change Requests
Change request documents vary from company to company, but they all include the same key information. Below, you can check a sample change request document.
Image Source: Project Management Docs
As a member of the team involved in change management on your project, you need to know how to effectively create and file a change request. There are six key steps in this process.
1. Describe the Change
Be as specific as possible when you describe the proposed change. You’ll need to provide the following information in your CRD:
- The name of the change, and contact information for its initiator.
- The change category (it could be a bug fix, enhancement proposal, requirements alteration, or another type of change).
- Details of the scope of the change (is it inside or outside the original project scope?).
- The approximate time, costs, and resources, required to implement the change.
Make sure you gather enough supporting data to help the project manager analyze and implement the changes. The information should be sufficient for other decision-makers to approve your request.
2. Describe Why the Change Is Necessary
In this section of the change request document, you’ll need to:
- Define the problem and the reason for modifying the software development process
- Explain how the change will solve this problem
- Describe the consequences of not making the change (this can include possible data loss, missing deadlines, or extra workload)
- Suggest how the outsourcing team should incorporate the alterations in the software development lifecycle
- Describe any alternative solutions, if applicable (e.g. how to address the problem without implementing the change request)
You may need to consult with your in-house tech lead or CIO about this section of the CRD. This will help you establish guidelines and suggestions for your outsourcing company.
3. Determine the Priority of the Change
You’ll need to assess the problems you describe in terms of scope, urgency, and impact on software development. The change priority helps the project manager and other shareholders determine how urgently they should review the document. You can set the priority at one of four levels:
- Low
- Medium
- High
- Critical
Examples of low and medium priority change requests are non-urgent bug fixes, device replacements, and web server patches. Critical and high priority changes are those which directly affect the project’s success, such as security breach fixes and data loss prevention measures.
4. Assess the Impact of the Change
Next, you should provide an overview of how the change will impact software development. Examples of things you need to consider here are:
- Existing work processes that will be affected by a change.
- New tasks will be created as a result.
- Possible risks of introducing the change.
- The relationship between this and other changes (Can other changes invalidate this one, and does it depend on other change requests?).
- The effects of the proposed change may have on communications between your company, the outsourcing company, and C-level management.
The project manager from the outsourcing company can modify this section of the change request document. For example, they can request additional information, add comments, or propose alternative solutions to the problem.
5. Outline the Course of Action
Here you’ll indicate what will happen after your change request has been approved. This section will include:
- Project deliverables will need to be updated.
- Documentation that will need to reflect the approved alterations.
- Infrastructure (such as a new tech stack or software) is required to implement the change.
- New coding requirements.
- Any additional training that will be required for the new processes and software.
6. File Your Change Request for Approval
Once you’ve completed all the information needed for the CRD, you’re ready to file it for approval. If the changes are significant, this may include getting approval from your company’s C-level management.
Based on the review, the CRD can either be approved, rejected, put on hold, returned to you for rework, or escalated to other stakeholders.
If the CRD goes through all decision-makers successfully, you can send it to the project manager for implementation.
Communicate and Proceed with Change Request Implementation
Communication is vital for efficient change request management. The project manager at your outsourcing company should communicate alterations to the project’s team, managers, and all impacted parties.
Since many alterations affect a project’s technical requirements, you will also need to make sure the changes are reflected in the relevant documentation, such as:
- The change log. This document lists all details about change request documents, the results of their review, and their implementation status.
- Technical design documentation. The development team will need to update the descriptions of class models, security settings, workflow methodology, and other software modules affected by the changes.
- Requirements documentation. The project manager should update the requirements documentation to assist the development team with quality control and help stakeholders understand that the project is on track.
- Software code. The development team will generally need to modify (or even rewrite) existing code to accommodate the proposed changes. After this, the code should be reviewed to ensure that it conforms to the project’s standards.
- Project plans and schedules. The project may need more time or resources to incorporate new changes, as described in the CRD. The outsourcing team should modify the necessary plans and notify the responsible person of any schedule and budget adjustments.
- Test plans and test cases. Changes to the code and requirements will impact the software testing objectives. As a result, the development team will need to modify the test plans accordingly.
The scope of affected documents isn’t definite. Therefore, the change request management and engineers don’t have to modify all documents after all minor alterations.
To Conclude
You can’t anticipate what can happen during a project’s life cycle, so the best approach is to learn to manage it successfully. Well-established change management in software development will prevent confusion between stakeholders, and improve your project’s chances of success.
At Edvantis, a formalized change management process is our not-so-secret sauce to minimizing risks in managed software development projects. If you are interested to learn more about our value-driven approach to IT outsourcing, get in touch!
