Challenging the Cumbersomeness of Change Management Processes
Challenging the Cumbersomeness of Change Management Processes
Change management for your help desk involves revising your Waterfall processes into Agile methods. Learn more about how to do that here.
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
Change management tends to be a cumbersome process, rather rigid and long-winded. While Waterfall processes can be difficult to manage or streamline, they can be made more Agile and there are several different ways to go about this. Let’s first establish that service management drives many of these changes or many of these processes, to be more precise.
Agile initiatives — those that allow your teams to respond rapidly, efficiently, and effectively to change — in the service management setting can identify ways to improve your service desk operations in a more efficient manner than traditional approaches and in a less rigid manner. Those two points are likely well understood at this point.
What may not be so well understood is how to go about implementing a single change in an Agile manner. To dig in, let’s start with how to make the implementation of a single change more Agile.
Agile Changes Only Need Descriptions of Your Goal and the Pre-Conditions
In an ideal service management world, there’s no need to complete a full change request form when first submitting a request. The description must only contain basic information, the most important things needed to include are goals and preconditions.
For example, as a member of the service desk team leadership, you likely receive multiple calls about appliances not operating correctly, coffee machine breaking down, email servers running slowly, or other services not getting attended to. Because calls for the same problem – a broken coffee machine, for example – can pile up, the service desk usually prefers not receiving an abundance of calls for the issue as they can bog down your operations. Ideally, you’d like your customers to be able to see if a problem has been previously reported and the status of the issue. The goal of such is simple: show your users which calls/issues have previously been submitted and which issues are being responded to by the service desk.
Likewise, the service desk must ensure that users don’t see the private information of other customers, one of the service desk’s pre-conditions.
Ensure Changes Are Still Meeting Pre-Set Goals and Pre-Conditions
Still implementing changes according to the Waterfall method? A problem with such an approach includes a chance that when the project is done, the final solution may turn out to not meet the customer’s needs. As you’re likely aware, the Waterfall method assumes that by directly executing the plan that originally drawn up — without alterations along the way – there’s a good chance that it may miss important steps required as encountered. In the Waterfall method, which is rigid, there’s just no room to adjust to new situations or observations.
As in life, changes are a daily occurrence; situations change. You might identify new information about what users really want or a new process that might be better than a previous one to provide a better solution. When designing and implementing changes, ensure that you’re regularly asking these two questions: does what you’re doing right now still contribute to the original goal, and are you still meeting pre-conditions?
These questions might help you discover that your solution is no longer sufficient. Agile processes, on the other hand, let you make adjustments along the way. It’s really as simple as that. You can change course along the way, as required or as best meets your organizational need.
When working in Waterfall, if you reach the point where it’s too late to change course, try not to be afraid to pull the plug on the change. Doing so might be one of the hardest things to do of the investment of time and resources, but quitting on the change before a complete loss occurs is better than developing a solution that, ultimately, doesn’t help anyone.
Involve Others in Your Change
Once a change will be implemented, bring in a variety of experts to take a critical look at your plans to ensure that everything you’re planning to develop meets a need, solves a problem and improves the user experience. When reviewing the proposed changes, have your expert team review whether or not the impact of the change or the change process impacts other applications, hardware, etc. Ensure that you’re not impacting security or leading to security risks because of the changes.
The Fewer Simultaneous Changes the Better
Limit the number of changes you’re executing at any given time. It becomes easier to predict the duration of changes, and working on fewer changes simultaneously means you’re working with fewer variables and moving project parts so you can better predict when you’ll finish a change. Additionally, the quality of your service will get better. Focusing on the change you’re currently working on also likely means fewer developmental mistakes.
Additionally, working on fewer changes at one time usually helps make the work more fun for your team. They can focus on the work at hand, see results quickly and not become burdened by conflicting priorities. For many, measurable progress and task completion are some of the most important factors in determining “happiness” at work.
This final point brings about one more thing about managing change management processes. Assign priorities for your team’s tasks. Doing so mitigates the constant flow of incidents coming in and ensures the likelihood that your team will experience better results and feel like they’re winning in the long term. In sum, take the time to make conscious decisions about your team’s priorities. Doing so will likely mean better results for your organization, its users and your team.
Opinions expressed by DZone contributors are their own.