We all know that nothing stays the same – no matter how much we might wish it did. In business there will be new services introduced and unpopular ones discontinued in response to business requirements.
Technology is no different and new applications will need to be incorporated and others dissolved. Equally the workforce ebbs and flows with new employees to allow access and leavers to be removed, even internally bringing people in and out of project teams. Change happens, it’s a fact of life, but it needs to be handled competently if the desired benefits are to be realised.
When it comes to reflecting these changes in IT systems, complexity and a lack of process has trumped best practices. Organisations are ready to take action – but the enormity of the situation means many do not know where to start, or even how.
Where does it all go wrong?
We’ve all been there when we’ve arrived bright and breezy on a Monday morning, only to find that a change that has been implemented to the system over the weekend causes things not to work as they should.
The result is IT, with their backs firmly up against the wall, scrambling around the network, making random changes without planning or authorisation, in a desperate effort to find and ‘fix’ the fault. The reality is that all of these little tweaks can cause additional problems that may not come to light at first instead rearing up at a later date, when no connection to the original change is made, to cause the system to fail.
A more worrying issue is when these changes aren’t identified. There have been numerous examples of how failing to control the process has led to breaches and compliance violations that can be traced back to mis-configured systems.
How can we make it right?
There are many ‘steps’ that should be followed when defining a change management process. Our ‘top tips’ for handling this are :
Step 1: Graphically build existing workflow processes within your organisation. Ideally they should fit ITIL guidelines, or at the very least the organisation’s pre defined processes.
Step 2: Define how changes are requested and what supporting documentation is required. This could be as simple as an email request to a triplicate form that is completed and officially submitted to a pre-determined person(s).
Step 3: Define the change management process so everyone knows what will happen and by when. This should include how changes are prioritised, timeframes involved, how they can be tracked, how they’ll be implemented. As part of this step, you should also define the appeals process. It should cover how a person is informed that their request has been declined, the reason why it failed and what happens next.
Step 4: If you don’t already have one, establish a Change Advisory Board (CAB). This should include a representative from each area of the business. This team will have responsibility for reviewing all requested changes, checking that it is complete, that it meets a business need, the impact on other areas of the organisation both adversely or positively, and finally whether doing so would introduce risks. If declined, this needs to be communicated back to the originator with the reasons why. If approved, the team would then be responsible for communicating the change to those affected by it.
Step 5: Design the change. During this stage it is important that any conflicts or insecurities are identified and rectified to avoid expensive repercussions at a later point. It may be prudent for this role to be split in two with an administrator to verify that the change remains within corporate compliance. This is easier said than done for some changes as, in making a change to meet one standard you could quite easily be in breach of another so this role can be key in determining what is and isn’t allowed. There is technology available that can help with this veritable minefield to automate, check and flag potential compliance conflicts.
Step 6: Implement and document the change. In an ideal world, the person who implements the change should be different to the person who designed it to avoid a conflict of interest.
Step 7: Verify that the change has been made, that it has been executed correctly and that only authorised changes have been implemented.
Step 8: Have a backup plan. If a change has been implemented that has had an adverse affect on the system, rather than blindly making changes, it should be reversed, reassessed and re-implemented once the point at which it failed has been identified and rectified.
Step 9: Audit the change process. It is important to check that approved improvements have been made – after all they’ve been identified as beneficial to the organisation.
Step 10: Regularly reflect on the change management process to identify any sticking areas that can be ironed out.
Manual vs Automated
Many organisations still rely on manual documentation of their network configurations. This then means that access requests are also manually processed which opens up a number of pitfalls:
1. Extended costs of manual changes: Manual requests, typically, can take anything up to 10 days which is time that could be utilised elsewhere. A further issue is time wasted checking, verifying and implementing unnecessary or duplicated changes that an automated process would have identified.
2. Risks of something breaking: As the workflow is all on ‘paper’, it is virtually impossible to check all potential break points without automating the process. Sometimes the team will have spent a great deal of time engineering the change up front for it to be denied by the risk team because approval is sought too late in the process.
3. Lack of audit and accountability: As everything is on paper, and often hurried, processes will go out the window with paperwork submitted after the change has been implemented, if at all. This can be as basic as having no idea who requested the change or why it was needed in the first place.
4. Impossible to define and enforce compliance: With just documentation to determine what the organisation’s compliance requirements are, administrators are left to use their own personal judgement to determine whether a new rule introduces risks.
5. Quality of service: As it takes longer to submit and implement changes the service is poor – both internally and often externally. This can lead to revenue loss e.g. failing to provide access to an online sales system or CRM that has a revenue potential means every week implementation is delayed more money is lost.
As this article demonstrates, change is happening frequently and organisations need to keep pace and manage the process completely if they’re to reap the rewards. Whether you do so manually, or invest in technology to give you a winning edge, time and tide wait for no man. You need to be able to react to changes in your environment, competently, for your team to come out fighting.