Controlling Change in IT Departments Using DMAIC

During a Six Sigma project at an information technology (IT) department, there are many good reasons why a process or a system needs to change. There also are a few bad reasons – bad, but unavoidable. It’s up to the practitioners to decide how to transform bad reasons into good ones, and how to prevent good reasons from going bad, by implementing proper change control mechanisms.

Change control is a method used for requesting and managing changes to work processes that are created or maintained by the organization. Change control helps facilitate communication about requested process modifications among the team members, provides a common process for resolving requested changes and reported problems, and reduces the uncertainty around the existence, state and outcome of a change that has been requested.

Having such a system in place reduces the possibility that faults or unnecessary changes will be introduced to a process without forethought, and lessens the likelihood of undoing positive changes made by other users. The goals of a change control procedure usually include minimal disruption to services, reduction in back-out activities and cost-effective utilization of resources involved in implementing change.

Applying the DMAIC Roadmap

One of the best ways to ensure full benefit of change control is to employ the power of DMAIC (Define, Measure, Analyze, Improve, Control). For IT departments, following a DMAIC roadmap for a process change request – such as the upgrading of databases and server hardware – can provide organizations with the necessary framework to ensure that all changes are made in the most efficient manner possible.

Handpicked Content:   Bank Deposits: A Black Belt Case Study

The following change control steps, which mirror the DMAIC path, should be used by IT departments while implementing any type of procedural changes.

1. Define need for change control – First off, the person responsible for effecting change in the IT department (the change owner) needs to identify the basic requirements of change control. These requirements can be either an improvement in performance or the replacement of existing processes. The change owner needs to identify the scope of change control in terms of practical problems in existing processes and document a proposed solution on a change request template.

To build a strong business case, this person also must enumerate the reasons for the upgrade of the server (the process change being used in this example), such as higher storage capacity, faster processing speeds and tighter security. This Define step is critical for the change owner to demonstrate the value of the project and convince the organization to provide its full support for the proposed change.

2. Request change control and measure performance – Next, the change owner should list these critical criteria while making the change request.
a. Provide a detailed description of the change – Specifications of the new server
b. Describe the type of change – Hardware upgrade
c. List the reasons for the change – Higher storage capacity, a faster application process, better security
d. Describe how the newly proposed changes will replace existing procedures – How will hardware be changed? How will data on current hardware be migrated to new hardware? What are the design and installation qualification protocols?
e. Technical evaluation – The head of the IT department should describe how this will be carried out in terms of a risk-to-benefit ratio. The operation qualification of the upgraded server also must be performed to check for capability.
f. List the impacts – What are the human manpower requirements for ensuring that this proposed change is made? What will the financial effects be as a result?

Handpicked Content:   Six Sigma and the Software Development Life Cycle

This change request should be sent to both the organization’s management and its quality personnel for approval. The priority of the above criteria will be decided by management.

3. Analyze the proposed change control request – Once the proposed change control is approved by management, it also should be analyzed by all other departments that will be affected by the proposal. This impact assessment and risk analysis should be based on – but not limited to – the criteria above (a to f). The results of this impact assessment and risk analysis should be reported using the levels “low,” “medium” or “high” by operational qualification.

The analysis can be sent back to the change owner in case it is rejected or if more clarification is required for the criteria. All concerns and suggestions for rejection or clarification should be noted on the change request form. After these concerns are addressed, the change request should be sent back once more to management for approval.

4. Improve, confirm and test the statistical solution – Upon final approval by authorized personnel, the change request should be subject to performance qualification. Before the proposed change can be implemented – in this case, an upgraded server – the data on the current server needs to be backed up. Only then can the change be implemented.

To verify the new upgrade against the current server system, practitioners should take a pilot run and analyze the process; this test also should include the migration of legacy data. The new change can be evaluated by performing technical tests decided as per protocol.

Handpicked Content:   Standardize Processes to Make Change Stick

Statistical evaluation of all affected parameters should be performed against the outputs of the process. If the implemented change shows the expected improvements in performance, then an implementation plan must be developed and enacted. After completion of this procedure, a note should be made on the change request that impacts have been assessed and that the change is ready for implementation in routine practice.

5. Set up a control system with routine verification – Controlling and maintaining the change is essential to the project’s success. Newly implemented changes should be assessed at regular intervals to ensure that they are running effectively. In case of future personnel changes, it is important to provide proper training to all personnel for handling the new process.

DMAIC is a familiar method to affect change in IT performance. However, to ensure that change is controlled effectively, practitioners should remember that the DMAIC roadmap also can be employed as an organizational resource. Six Sigma provides the tools to improve the capability and reduce the defects in any process, and change control can benefit from this structured approach.

Comments 2

  1. Don Turnblade

    I appreciate the approach for the basic Change Control Process implementation. As with any approach the first layer of a Pareto improvement looks for the first 20% of process improvements — such as credible change control processes — that has a credible chance to make 80% of the difference.

    The next layer of scale needs some refinement. For example, risk ranking processes need to move from qualitative “high”, “medium” or “low” or even “Red”, “Yellow”, “Green” toward more quantitative measures. The reason for this has to do with cost/benefit justifications for change. Once basic operational change management happens, a Voice of the Customer distinction using this Process begins to appear.

    Voice of the Customer for a Change Management Process:
    A) Information Security Patches often have a rapid change need with a small fraction presenting deeply systemic operational risk if applied. When strong dependencies occur related to Information Security Patching needs, often these are sidelined in to an Update Project path. These have different priority needs than “High”, “Medium” or “Low”. For example, these need cost of quality justifications — should the patch project have a $100,000, $1,000,000, $10,000,000 budget? What is the cost of a “High” risk?
    B) Cost of Quality modeling has its own risks: Model relevance, Model Correlation to at risk technology, Model Correlation to Attack Surface Frequency, Model Correlation to Legal/Compliance/Regulatory risk, Model Correlation to computer breach damage experienced by Stakeholders such as the firm, internal operational excellence, customers and more.

    Consider the following real risk an example that is occurring on a nearly global scale.
    Any firm processing credit cards need to comply with the PCI DSS standards.
    These have made TLS 1.0 older version of SSL 3.0, 2.0 etc. as well as short list of encryption and hashing methods unacceptable after June 30, 2018. Use of encryption and vulnerable protocols are used by multiple parties, thus dependencies between them affect both Change Management and Legal/Regulatory/Compliance processes. Easy changes, have a simple upgrade and patch that works in an afternoon. Then, then the complex change customers arrive.
    – Vexing dependencies — between a firm and its business partners, between two systems once covered by PCI compliance and the other not covered by PCI compliance, applications with compiled libraries that must add features in cryptography before other features of cryptography can be turned off, systemic identify management implications by devices and LDAP services.
    – These customers quickly break in to three lines for Change Management: Fast Change, Single dependencies such as working with a vendor to create a patch or working with other internal application owners to build an upgrade, then large interdependencies — Consider turning off TLS 1.0 support for all servers in an AD domain or banning MD5 check sum use support for an entire AD domain as an example.

    A “High” risk may quickly become a 1 year project with milestone phases and a budget. Even if the a fast fix of the same type on another system is a one hour urgent patch application, even if we imagined that a TLS 1.0 patch in one case is a High and the other a Low, the Change Management team will need more process options that listed above to address these, or at least hooks to related project spin up for rejected changes.

    Change lifecycle tracking abilities show up as a need for Legal/Regulatory/Compliance changes. Often external regulators need evidence of a change project status, milestones and credible completion dates. Again, if all fast PCI TLS and crypto changes take place in a month or less, and all single dependency changes finish patch negotiation and dependent change dates within 6 months, then deeply interdependent changes still can be on going with Milestones over the course of two years with sub-achievements appearing on the Change Management schedule from time to time.

    Finally, with encryption there are simply some one way committed changes. There simply is not undo function. While these may obviously be designated “High” risk. The qualitative differences between High and High start to fail to map to quality change management processes. Risk and Priority need better “Define, Measure, Analyze, Improve and Control” refinements.

    What is a High exactly? How do you define it? How did you measure it? How did you analyze it? Can that process improve? Who controls the process of sustaining credibly measured risk?

  2. Chris Seider

    I might suggest that IT departments use more “users” in their teams. Users may be of the applications, networks, etc. Team members don’t have to be full time but “users” or “process participants” are often forgotten.

Leave a Reply