Change is a natural companion of every project, especially in turbulent markets as such that businesses encounter today.
The need to adjust your product development roadmap can come from early customer feedback or new customer segment research. Monetary constraints are a common issue too. Just like the broader maker factors like supply chain disruptions, currency volatility, or other economic calamities.
At any rate, the outcome stays the same: You have to change horses in midstream. IT change management requires some operational dexterity when it happens internally — and even more effort when you have to communicate change downstream to your outsourcing partner.
In this post, we discuss how to create a lean IT change management process for outsourced projects to minimize the impact of disruption on your core goals. But before we dive in, let’s level set the definitions.
What is IT Change Management in Outsourcing Context?
Stanford University offers the following definition of change management:
IT change management is the process responsible for managing all changes to the production operations environment from inception to completion. Change Management helps organizations understand and work to minimize the risks of changes to the IT environment.
The goal of the change management process is to minimize the negative impacts of proposed changes on the delivery of IT services to end users. To achieve this goal, the IT change management process has to follow a standardized methodology for initiating, managing, and communicating change within your organization.
Change management (CM) can pertain to both changes in the production environment (e.g, replacing legacy billing software with a new payment solution) or IT services delivery (e.g., setting up a new process for requesting cloud resources). These two changes are governed by the ITIL 4 methodology.
In the context of IT outsourcing, however, change management has a more narrow definition: It’s the process of initiating changes to the pre-agreed project roadmap.
The need for change management can occur when:
- The original timeline has to be extended based on extra market research/stakeholder input
- Initial budgets didn’t account for unforeseen expenses and costs associated with the increased project changes
- Market conditions change and your business must react to them
In practice, the above often translates to a sample scenario like this one.
Your project management office created an ambitious plan of delivering a new EMV payment application in 3 months. However, the initial project estimation only accounted for contactless payment transactions. Yet, you also realized that many of your clients also want to process online (card-not-present) transactions. You now need to break the news to your outsourcing partner.
The above scenario triggers an internal discussion about re-evaluating the initial project assumptions and creating a new:
- List of requirements
- Development timeline
- Budget estimates
Together with other stakeholders, you’re evaluating if it’s better to complete the MVP faster by increasing the budget, extending the timeline, or launching with fewer features. Typically, the above discussions will go through these six stages, as shown in the IT change management process flow diagram.
Source: ManageEngine
Once you reach the decision, it has to be communicated back to your in-house team and the outsourcing partner — and then all changes must be rapidly implemented. That’s the complex part.
Why Change Management in Software Engineering is Challenging
Change management may be difficult to exercise in software development because the process assumes alterations to the previously formalized project plans that your team is already executing.
Some SDLC methodologies such as Agile factor in “change” as an inevitable element and allow you to change priorities within the new Sprint. Others like Waterfall emphasize preliminary planning and leave little room for changing requirements during the Implementation stage.
However, even in Agile teams change initiation will result in a loss in the team’s velocity — an IT metric that indicates how much work the engineers can accomplish within a planned Sprint.
Secondly, changes are rarely equivalent. You don’t need to initiate a formal change management process if you plan to swap one secondary user story for another one with an equal estimation.
The need for a formal process arises when more fundamental changes to your business strategy are on the horizon, often in response to micro- or macro-economic factors.
In such cases, you need to pivot to a brand new project plan where:
- Several user stories get replaced, merged, or reprioritized
- Extra team members have to be added
- New risks/constraints are taken into account
- Project timelines and budgets are updated
On the organizational side, top-down change is also hard to execute if you lack grassroots support. You’ll need to pass down the information through several IT change management roles such as:
- Change coordinator / manager
- Business stakeholders
- Project managers
- Engineers / developers
Extra time and effort are involved in coordinating change and ensuring that it gets accepted and operationalized on the downstream level. The common challenge is ensuring timely, targeted action on each level.
Not surprisingly, lower-level management often views change as less effective than upper management presumes it to be. This is often the case because lower-level management is often the one tasked with breaking the gist of proposed changes and ensuring their effective execution.
Source: Bearing Point
A factor that often complicates the above process is that there’s no universal model for assigning IT change management team roles and responsibilities for software development projects. You will need to come up with your own model for determining who should take on the most change manager responsibilities — a product owner, project manager, Scrum master, or a person with another title. Then provide them with the necessary support to execute the proposed changes during the implementation stage.
How Does Change Management Happen in IT Outsourcing?
IT change management process in outsourcing varies based on the selected service model since each assumes a different degree of managerial responsibility on the client and vendor sides.
That said, the underlying process flow of IT change management will remain the same. You (or the vendor) will still need to:
- Record proposed changes
- Put down CM plans
- Approve the proposed scope
- Execute the plans
- Review the outcomes
In each case, the key difference is which side will take action on most of the above steps.
Staff Augmentation
In the staff augmentation service model, all the change management decisions take place on the client side and must be communicated downstream to the team members who’d then exercise them.
In some cases, however, your change management plan may trigger the need to onboard additional IT personnel. If that’s the case, you’ll have to communicate this information to the vendor. The sooner you can notify them about your plans to upscale or downscale the team — the smoother the transition process will happen.
Remember: successful IT outsourcing partnerships assume proactive, transparent communication around your business dynamics. The IT staff augmentation market is heated. Hiring expert tech talent takes time. Therefore, you should loop in your vendor as soon as you recognize the need for extra staff members.
Managed Team
The managed team model assumes staff co-management. Typically, you have a proxy product owner (PO) role present on the vendor’s end who will be your main point of downstream communication.
They can assume an informal role of change coordinator at your end: Coordinate the change initiation and implementation by a cross-functional team that’s working on your project.
In this case, the decision to initiate and execute change is still fully taken at your end. However, you must understand how the scope of the proposed change may affect the current team composition and its performance. Talk to your PO about how proposed changes will affect IT team performance metrics (velocity, cycle time, lead time, etc) and what other trade-offs are worth accounting for.
Managed Project
Managed project service model assumes end-to-end delivery of a scoped solution based on the pre-approved Scope of Work (SoW) and Master Services Agreement (MSA). Because such projects are pre-approved (and pre-budgeted for), your vendor will have to initiate a formal IT change management process on their end.
At Edvantis, we begin this process with change request evaluation, where we determine how the requested modifications will affect the legally pre-agreed SoW. Then report back to you with a feasibility analysis of the proposed changes and information on new:
- Timelines
- Budgets
- Risks
Our goal is to remain flexible but within reason. We proactively inform you about the implications of your decision to add out-of-scope items, drawing attention to the changes in costs and risks.
If you approve the proposed change management plan, we’ll prepare an updated SoW document for counter-signing. Then proceed with the execution based on the new plan.
Conclusion
Change management is often driven by the desired future outcomes. However, this process is deeply rooted in the present. You have to understand your current standing. Then create sequential steps for effective transition and work towards their implementation at every level, both internally and in conjunction with your IT outsourcing partner.
Edvantis facilitates change management by offering flexible IT outsourcing service models with clear boundaries on the areas of responsibility. Contact us to learn more about our offerings.
