Change Control & Maturing IT Processes in ITSM
What Is Change Control?
Change Control allows an organization to maximize the number of successful service and product changes by managing the change schedule, authorizing changes, and ensuring that risks have been properly accessed. As Information Technology departments in small- to mid-sized organizations mature, they incorporate more of the processes and constraints previously seen. This is mainly in large companies including a change control mechanism that attempts to manage control procedures to the infrastructure on which the company is so dependent with minimal disruption. Change control is a necessary management process to ensure that systems are stable and reliable in an increasingly complex environment.
Change control involves the following six steps for project scheduling:
1. Plan / Scope
2. Assess / Analyze
3. Review / Approval
4. Build / Test
5. Implement
6. Close
Problems arise from introducing a not insignificant workload, often leading to delays that can, if not managed properly, drastically negatively impact the productivity of development initiatives designed to improve those systems.
There is a temptation to treat all systems as production level and quite often development environments, particularly databases, are subject to strict change control rules and even sometimes the same rules as the production systems that they are being developed to update. Small- and mid-sized companies cannot afford the staffing levels required to keep them agile in these situations. This can cause major delays when development work requires a database refresh to fix a problem or to test out the deployment of new code. To complicate things further, many of the actors involved now work remotely. Often entire teams are all remote, working from home communicating via email and chat applications. In and of itself this decentralized working should not be a problem, but when it is combined with the ever-increasing push to do more with less and the inevitable increase in individual workload for the engineers involved, we are seeing more and more situations where things that should take an hour or less are taking several days to get done. It is no longer possible to simply walk over to a manager’s office and get something done. Often it requires booking a conference call appointment on multiple resources, calendars to discuss what is required, and then trying to get the request scheduled into the relevant engineer's busy workload.
By using some of the new tools at our disposal we can make provisioning of test and development systems much more automated whilst still conforming to sensible rules and providing adequate traceability and auditing. A developer can trigger the restoration of a development database or the rebuild of a test server on request without requiring any other human effort at all.
The first steps in change control are to properly segregate the production, test and development systems, and apply sensible rules to each environment. It is still very much the case that a developer or implementation consultant for an application that has a database at its core HAS to know enough about the database itself to be able to determine when and how it should be maintained in a development environment. Without that knowledge, how are they going to create an adequate application that will perform with any level of satisfaction in the production environment? This means that we should not be reliant on the production database management staff to manage the development database and should be able to give much more control to the developer to manage their environment.
If we provide the right change control tools to perform provisioning and maintenance of the development environment in an automated way the developer can perform all the necessary functions on their own by triggering the automation on demand and be very much more productive.
