TEAM Zarate Tarrani Notes From the Field

Process - Part 2. I am picking up where I left off in my 11 March entry. In that entry I discussed the basics of processes and introduced the ETVX model. Today I am going to provide a real life process as an example for how ETVX can be applied to processes.

Example. Change control is a key IT operations management process that is governed by policy (more about policies tomorrow), and is accomplished through a series of tasks. Refer to the graphical depiction of the process as you read through it.

Entry Criteria. The change control process is initiated when there is a requirement to make a change. Change is defined as any of the following:

1. New system - application, operating system, database, hardware platform or infrastructure.
2. Major upgrade to an existing system - version release, new or upgraded components and/or subsystems (hardware or software), database schema reorganization, etc.
3. Minor upgrades to an existing system - patches, modifications to existing scripts or additional scripts (batch, shell, SQL, etc.), minor database schema reorganization (dropping columns, adding or modifying constraints, triggers and stored procedures, etc.) and infrastructure changes that are transparent to end users (i.e., upgrading IOS in a Cisco router, etc.).
4. Changes to service level objectives - permanent maintenance window changes, changes to problem management response times, mean-time-to-repair metrics, availability commitments, etc.
5. Maintenance to any system that has dependencies with the system being managed - in this special case the subject matter experts (SMEs) will open a change request to document the maintenance being performed on the inter-dependent system even though the SME has no direct control over, or responsibility for, the system. For example, if a particular application exchanges data with an application that is managed and supported by different SMEs, and is owned by a different application owner a dependency exists. The SME for the external application are responsible for initiating change control. However, since the change will affect the second application, that application's SME will open a change request as well. This provision will ensure that the scope of the required impact analysis will extend to all systems that are affected by the change. It will also ensure that each SME remain cognizant of any change or maintenance activity that affects his or her system.

The following are the minimum entry criteria that must be met before the process can move to the task stage:

1. Release notes, build analyses, installation manuals and any other documentation that is needed to correctly test and install the product (hardware or software).
2. Test results from QA (product test/UAT and/or pre-production/staging).
3. Operational requirements, such as special training, maintenance window considerations, help desk entry criteria, spare parts, etc.

Tasks.

1. Perform an impact analysis. Deliverable: completed impact analysis.
2. Develop planning package. Deliverable: description of change and why change is being made (including benefits and how the change will create value for the users), how the change will affect users during the implementation (scheduled start and end time, impact on maintenance window and service level objectives) implementation plan, roll-back plan, roles and responsibilities, notifications, quality assurance plan.
3. Provide operational requirements, implementation plan and change request to application owner and SME for review and approval.
4. Application owner approve change.
5. Technical owner approve change.
6. Submit change control package to change control coordinator.
7. Change Control Board reviews and approves the change request.
8. Change is implemented in accordance with implementation plan.
9. Change action is closed out as complete.

Validation. The following are checkpoints in the change control process:

1. All entry criteria will be checked for accuracy and completeness by the SME(s).
2. Application owner will review and approve the change request before proceeding.
SME's supervisor will review and approve the change request before proceeding.
3. The change control coordinator will review the implementation plan and change request for accuracy and completeness before including the change as an agenda item at the next scheduled change control board.
4. The change will successfully pass all post implementation validation test checkpoints before the change is released into production, else the change will be rolled-back.
5. In the event of a roll-back there will be a root cause analysis performed and responsibility for eliminating the root cause and, when applicable, developing a process improvement plan will be assigned to individual(s) by cognizant authority. The change request will also be cancelled and resubmitted after the root cause has been determined and eliminated.

Exit Criteria.

1. The change is successfully released into the production environment or cancelled and resubmitted depending on validation checkpoints above.
2. After a change is successfully released into the production environment the change control coordinator will close out the change request as completed.

Policies. It may appear that policies are mixed with this process, but they aren't. Tomorrow I am going to provide the policies that govern the process just described, then discuss the relationship between policies and processes.