Change management is an important part of managing IT projects, whether they are for internal initiatives or for projects you are working on for clients. Change is constant. How you manage it, though, is what keeps chaos at bay.
You know the downside of a poor change-management process: Scope creep. And you know that scope creep is the bane of any hope you had of profiting from that project. Fortunately, there are two habits that manage change in a way that keeps scope creep at bay: Documentation and tracking.
If these two elements are a seamless and integral part of your project management systems, your change management process will improve with every project you do. From the moment an internal need for change arises or a customer requests a change, the documentation – and tracking – should begin.
Put the change request in writing. Get it approved by key stakeholders. And document the implementation. This will transform your change management process because it will help you nail down every detail and possibility, while making it clear – to everyone on your team -- when changes are significant enough to require rescoping the project.
In an MSP, where you are managing projects for clients with different needs, expectations, and cultures, handling change is challenging. That’s why you need an outstanding change tracking system.
What is change?
At an MSP, change can come from any direction. Someone on your team might need time off or encounter an unexpected challenge. It can come from a client who adds work requests, fails to produce deliverables, or alters the schedule. It can be caused by technical problems, scheduling SNAFUs, or even the weather.
Change can also be the result of an intentional alteration to the tools, processes, compliance requirements, or standards you – or the customer – use daily.
Change comes in difference shapes and sizes, too. It can be small enough to be easily absorbed into the slack of a project plan. Or it can be so substantial that it triggers a complete change to the plan’s scope. Most problematic, though, is change that falls into the less-definable middle dimension. Here is where doubt lives and profits go to die. If a change isn’t big enough – or is an accumulation of small changes -- to trigger rescoping, it will eat away at budgets and resources.
When managing projects, documentation and tracking are essential for accurately identifying change – both within the project and change that may be caused by the project. Without these documentation and tracking, you will miss essential details and changes will invite chaos into your plan.
What is a change management process?
Whatever causes change, your change management process needs to define it clearly and explain, in explicit detail, how to respond to it. It also needs to define how change is communicated, and approved, throughout your team and the client’s team.
A standard change management process typically involves four steps: Plan, implement, monitor, and evaluate.
Plan
Because MSPs manage change internally as well as for clients who may each have different systems, planning – and documenting that plan – is especially important.
In the planning stage, you should define and document the steps, roles, and responsibilities involved in initiating, approving, communicating, and executing any change to the original project plan. Clearly explain what alterations are small enough to be absorbed by project slack and what likely isn’t. Create a checklist of actions to deploy when responding to changes that exceed that definition. Everyone working on the project, should have access to these definitions.
Before you can plan what to do if there is a change, though, you need a detailed project plan. The more thorough and complete the project plan is, the more obvious it will be to team members when something deviates from it.
Make it clear that before anyone can initiate any change, they need approval from the right stakeholders.
Implement
As you begin to implement the change, involve and engage key stakeholders on your team and from the client.
This means first identifying who these people are. Who is affected by the IT project and changes to it? Who has influence over people who will be affected by changes to the plan? Who needs to participate in implementing the change?
Bring these people into your early communications, keep them updated regularly and proactively. Solicit their input, feedback, and approval throughout the implementation process. Be sure to address their concerns, expectations, and resistance.
Monitor
Be sure to proactively monitor the changes, how well they are being received and put into practice and adjust your efforts accordingly during the implementation.
Detail the changes within the project plan so that everyone involved can see what is happening and how well it’s going.
And don’t forget to document. You should track and measure the progress and performance of the changes, comparing actual results with your expected outcomes so you can identify any gaps, issues, or risks.
Evaluate
Take a moment at the end of every project, especially if this is a service you intend to offer to other clients, to evaluate how everything went.
How well did the plan play out in reality? Were steps missing that could be added to the project plan now? Was a change something that should have been part of the initial project plan? Was there anything you should have done differently? Involve as many stakeholders as possible in this discussion so that you capture as much data as you can.
If this evaluation concluded that elements were missing from your project plan, add them to the project plan, or template, moving forward so they are covered when you use this project plan again.
How does a change management process work within projects?
When change happens within a project – because of a missing resource, missed deadline, equipment problem, or requests from the client – your change management process is put to the test. Be sure to document and track what happens so you can learn from this test.
When your plan – and what constitutes a change to it -- is clear to everyone on your team, there will be no doubt when a change is small enough to be absorbed by project slack and when it requires the project to be rescoped. The devil is in the details here.
But a collection of small changes can add up to project problems as easily as one noticeable change that triggers your change process. To guard against this type of scope creep, build milestones or steps into your project plans that ask your team to pause and compare the original scope to the current work and consider if the project scope needs to be revisited.
Communicating change, and the need to rescope because of it, to the client is an important part of IT projects. Build communication tools, processes, and steps into your overall project plans and templates to make sure you are doing that well. This could take the form of status meetings that explain your processes, getting approvals for steps along the way, and building instructional sessions and training into your project plans.
Once you have taken the time to build a project plan that implements all your change management steps and procedures, save that plan as a template so that you never miss an important step on a future project.
Project templates can help you document change and implement your change process effectively every time you take on a new project. Most importantly, though, they help you implement what you learned along the way into future project plans, which means your project plans – and your change management system -- will continuously improve.
Want to dive deeper into this or other project management subjects? Explore our webinar library for past recordings and upcoming events full of expert advice for MSPs and IT Service Providers on managing projects.
Comments