Defining ITIL Change and Release Management Processes
This chapter is from the book
This chapter is from the book
This chapter is from the book
The heart of ITIL is in processes and the disciplines surrounding them. Thus, it should be no surprise that early in the planning for change and release management, you need to begin defining processes. Although version 3 of the IT Infrastructure Library defines the processes in more detail than any previous version, it still doesn't describe exactly which process every organization should use. This is because one of the best practices is that each organization should define its process somewhat differently.
This chapter starts with a generic description of how to define any process at four levels. After you understand the basics, the ITIL suggested high-level processes are introduced, followed by specific suggestions about how to customize your own change and release management processes.
How to Define a Process
Like most specialties, process engineering uses its own vocabulary. The words aren't complex or difficult, but they are used in a specific context and must be understood that way. To work effectively with process engineers, you must know this vocabulary. This section introduces the important terms and concepts used to define a process. Figure 3.1 shows the steps required to build out a process.
)
Figure 3.1 Five basic steps are needed to create a process.
Start with Process Flow
At the onset of defining your process, you need to grapple with what is meant by a process. Although more technical definitions are available, the working definition of a process is a sequence of defined actions that produces a measurable and desirable outcome. Because a process is a sequence, the place to start with definition normally is a flow diagram of some sort. Whether you favor a "line of visibility" diagram that delineates the different roles in the process or a simple flowchart that captures only the steps, your organization should adopt a standard way of defining a process flow. Look around for other process documents, and copy whatever style is in use for your organization.
Creating a workable process flow requires a solid starting point. Fortunately, the ITIL service transition book provides a solid start. In Chapter 4 of that book, you'll find some excellent sample process flows that can serve as a starting point. If your organization already has change management and/or release management processes documented, those can also serve as good reference points.
After establishing a starting point flow, the next step is to look back at the requirements you documented. Look very closely at the process requirements, and see if any of them dictate that you change your starting flow in specific ways. It would be unlikely at this high level, but occasionally a requirement will cause you to add a step to an overall flow.
Be sure not to get too detailed in your high-level flow. A good rule of thumb is that the top level should fit on a single page. Most of the process requirements will be around the details rather than the high-level process. Those details will be worked out eventually, but you have the greatest chance of success if you start with a single sheet that all your stakeholders can agree is the top level of the process.
After you have used existing starting points and your own judgment to define a high-level process flow, it is time to validate it. Take the single sheet to your sponsor, your stakeholders, and the project team. Get their ideas and incorporate them. Be sure to keep everyone aligned with the scope of your project. This is not a second round of requirements gathering, but an attempt to meet the requirements and scope you have already defined. It is important, however, that the high-level flow meets everyone's understanding of the project scope, because you are about to base many hours of work on this single page.
Frequently one or more activities on the high-level flow will be worthy of a separate flow by themselves. In the language of the process engineer, these are subprocesses. Identify these subprocesses as you validate the high-level flow, and work with the stakeholders and project team members to build these flows as well. As before, constrain each to a single sheet of paper, and focus on getting the flow documented in a consistent format. The subprocesses do not need to be especially detailed at this point, but they should provide enough information to allow later definition of the details.
As soon as all the flows are complete, you have the basic outline for all the process work. From these simple flows, you will determine which policies need to be defined, how many procedures will be written, and ultimately how many work instructions need to be documented.
Identify Needed Policies
The next term to understand is policy. A policy is an axiom or rule that is always true because your organization says it is true. Change and release management abound with policies, and throughout this chapter, you'll find many examples of policies that you may want to adopt for your process work. For example, many organizations insist on a policy that no IT component or service can change without an authorized change record. Policies are declarative statements about how things should work, and many times these policies result directly from the requirements.
When the high-level process flow and subprocess flows are done, the next step is to read the requirements and determine where policies will be needed. One clue is that policies often are associated with making a decision. Look at the decisions on your process flows, and determine how that decision will be made. Is there a policy statement to be defined? Unless the decision is very simple, you will probably want to provide some guidance in how it is to be made, and that's the perfect reason to create a policy.
Not all policies are large and encompassing. Instead of a single grand policy on change approvals, let the process flow guide you in creating smaller policies on change advisory board (CAB) membership, voting rules, handling of emergencies, and so forth. Try to keep the policies focused on one area at a time, and later you can combine them into a single policy document if that's more convenient to manage.
Create enough policies that no important decision or action is left to the imagination of one person. That is when you know enough policies have been defined.
Create Procedures
Procedures are the meat of the process definition. They are the narrative description of the step-by-step actions that someone will take to follow the process. Although the high-level flow provides a good overview, the procedures are the details of how to actually execute the process.
Procedures should be detailed enough that two people executing the same process step will always get the same result. They do not need to be so detailed that two people following them will use exactly the same method to get the desired result. Finding the correct level of detail requires an understanding of your organization and the skill level of the people who will be assuming the change and release management roles.
Procedures normally are documented as a numbered list of the specific steps that need to be taken. Not every activity in the process and subprocess flows will require a procedure to be written, but many of those steps will. If the outcome of an activity on the high-level flow is critical, or if that activity will involve a lengthy set of steps, document that activity with a procedure.
Often procedures are written into the same document as the high-level flows. This is a good format, because it keeps all process documentation in one place and is easier to maintain. On the other hand, if you have many procedures and policies, keeping everything in a single document can result in a very long document that is difficult to review and read. Some organizations choose to keep their process and procedure documentation online in a web page or wiki. That format lends itself much more readily to having each procedure and policy written as a separate short document that can be indexed from a process home page.
Document Work Instructions Where Needed
Sometimes procedures can get too lengthy and cumbersome, or the same set of steps needs to be repeated in multiple procedures. This is where a work instruction can be useful. A work instruction is a very specific bit of guidance on how to achieve a specific task within the process domain. For example, in your change management process, you may have several procedures that start with someone looking for a specific change record in an online tool. If the tool has been in your organization for a while and everyone knows how to look up records, you can probably just include a single step in every procedure that says "Look up the change record." On the other hand, if the tool is new, you might want to document exactly how to look up a record. You could do that in one place in a work instruction and refer to it in your procedures.
Normally, work instructions are tool-specific and procedures are not. This is a good practice, because it allows you to change tools in the future without having to rewrite your procedure documents by simply creating additional work instructions. If this is important to your organization, you will have general procedures with many more work instructions.
Keep the work instructions at a higher level than a tool user guide, however. They should be used only to describe specific uses of a tool where many options might be available. For example, your release management tool might support a variety of approaches to documenting a release policy. You could write a work instruction that directs people to always follow a very specific method. This ensures that people within your release management team always use the tool in the same way regardless of the latitude offered by the software publisher.