I'm a new ITIL Foundation Certified employee in the IT department of a major Canadian financial institution. My role is to develop strategies on Operational Acceptance of Changes.

Having taken the ITIL Foundations course, I believe my role falls under Release Management. I intend to develop a checklist of items to be used by the Project Manager indicating the completion status of the Change Items. I would expect this checklist to be presented at an ORR board meeting. At that meeting I expect to gather the Operational Readiness and Risks of the Change Item from various stakeholders, and present that to someone or some group for a Go/No-Go decision.

My question is, within the ITIL world, who gives that final Go/No-Go decision to implement ?? is there some sort of Implementation Board under RM ??? some level of Executive decision making ?? What are other companies doing in this regard ??...Thanks

Hi Jeff, from what you have described, I think you are relating two processes into one. Release Management and Change Management.

Change Management is responsible for recording the task necessary for the implementation and gaining appropriate approvals. However, Change is not responsible for the actual implementaion. That is where Release Mgmt takes over.

Change is also responsible for the risk assessments and impact of a particular implementation, not Release Mgmt. It would be during your regular Change meetings (but not limited to), that other areas would be made aware of upcoming changes that may impact them.

As Release Manager, you role would kick in once the Change request has been completely approved, and it is time to implement. It is through the Change request that the approvals (Go/No) decision is made.

While there is more to it, I hope this breif explaination makes sense.

As mentioned I am new to ITIL Processes so I may not have this right and I appreciate yours and everyone else's patience.

My understanding is that Change Management will issue a Go/No-Go decision on the RFC. As you said, Change is also responsible for the risk assessments and impact of a particular implementation.

However, once Release Management is given the go ahead and proceeds with the Implementation, we want to ensure the Operational Readiness of a RFC to proceed into the Operational environment. Just because the CAB has issued a Go decision, to my mind, it doesn't ensure the readiness of the RFC to actually proceed to Production. That has to be the responsibility of Release Managment.

It's in the Release Management process where I would expect the Provider to attend an ORR Board meeting where they would present the status of the tasks required to implement the RFC. Based on that status and their relationship to an Operational Risk model we are developing, I plan to have the ORR Board issue a Certified/Not-Certified Operationally Ready recommendation to Someone (I'm thinking Release Management executives) who will have the final say as to whether this RFC can proced to Production.

That is the basis of my original question..Who is that Someone ?? In organizations who have "gone" ITIL, who has the final say as to whether some Change can actually proceed into Operations. I know it's part of Release Management, but what level of authority do other organizations use to suport this process....no management ??...middle management..???.senior management ??...different levels dependoing on Risk or impact ???

Hi Jeff, what we have done with some of our clients, as well as companies where I have worked is have the appropriate decision makers in the RFC approval process.

The approvers can be at the required level of magagement depending on the type of changes. We have several levels or categories of changes. You may have an emergency change which may require the CIO, to a regular desktop deployment who may be a managing director.

What I see happening if you introduce another "approval" mechanism in Release, is you are duplicating the work effort. Hence the approval process is only in Change management.

A suggestion may be to take a few of your implementations, break them down into tasks, then match the appropriate appoval needed for each task. Try a very complex change and a very simple change. Try to identify the risk up front, and depending on the risk, additional approvers maybe required.

Remember, the idea is not to get bogged down in committees, but to make sure Service is minimally impacted. If you can identify risk and approvers in Change, why would you need to repeat it?

With that said, remember ITIL is a framwork to work from, and you need to wrap the way your organization works around it or change some of the existing processes within your organization. So if you feel you need to having something in Release Mgmt, then that is your decision.

Jef, what Azard is saying is correct and his adivce about not getting to 'administrative' is wise, but perhaps there is a missunderstanding here.

To my mind Operational Readiness is the indicator that a Release is in good shape, actually confirms to the changes the CAB approved - not too much deviation from the original RFCs the release is implementing, and has been tested sufficiently to ensure no 'melt downs' when the proverbial switch is flipped - or something to that effect.

You are correct to see this as a different kind of decision point to change approval. Particularly on large complex releases, I think it would be foolish to trust that what has been built is automatically going to be what was approved.

If that is the case, I agree that it is a key part of the process.

I'd suggest you have a look at figure 9.1 in the Service Support book (Blue), major activities in release management.

If I understand you question an ORR is a mechanism you would use to go from the commpletion of the Fit for Purpose testing and the Release Acceptance stages.

In fact if I do get your question an ORR is either the Release Acceptance action, or a combination of both Fit for Purpose Testing and Release Acceptance.

So yes ITIL does cover it. But, alas as with many of it's components it doesn't cover the detailed 'how to' - and it's always the same reason: because the methodology will vary from case to case and site to site - but it sounds to me like you are already right up there on the methodology and are just seeking confirmation of where to put it in the overall Release Management process cycles.

Now as for who should do it? Well ITIL is annoyingly silent on a lot of the roles - same reason as above - there is going to be so much variation from site to site in the positions, roles, skills, responsibilities, etc., that it would be very difficult to say, 'Oh, make sure your configuration manager signs off on it'. How many site actually have a 'configuration manager'? So if I suggested appropriate roles I'd be guessing.

But allow me a couple of plain english comments.

Ideally it would be one or more people who are:

Technically conversant enough to know what the Fit for Release Reports is saying - and that might vary from release to release.

Someone senior enough to say the buck stops here if the wheels do fall off.

Someone who stands to loose (their buget, performance targets, etc) if the wheels do fall off - like a business process owner.

Maybe even the lead engineer on the release build

...and suddenly it's begining to sound a bit like a CAB - so maybe it should go back to the CAB?

On the other hand a simpler principle can be applied to the question of who signs off on the ORR...

Release managment, like all the other ITIL processes is managment. Sounds pedantic and picky but the term management gets used in sublty different ways in IT becasue we refer to production work as management. But release managment isn't intended to be release building, it is intended to be a business management process - authorising, planning, monitoiring, tracking and approving release builds and the release buillders. So if your 'Release Manager' is not acting as a technical lead on the build, and carrying out the managment tasks to ensure the builders are following procedure, then it is that person who is the appropriate authority for sign off on a ORR. And it would be part of their duties, (even their position description) to have that authority and to report back to the CAB in the post implementation review on anything that did go wrong becasue the release turned out not to be fit for release.

On the other hand if you don't have a 'Release Manager' (or a Change Manager whose duties extend to release managment), or your release 'manager' is really the sleeves-rolled-up technical lead for the build, then the risk is that person doesn't have the distance to make the call, and you have a 'separation of powers' problem - in which case, I think it's probably back to the CAB.

Adopt and adapt (sigh!) But I would always recommend an explicit distinction between the release 'manager' and the lead engineer for any given build.

I fully agree with RJP, CAB committee cannot be in charge about a release is in good shape and can be implemented, sometimes since a change has been approved by CAB till this change goes live lasts months.

I am working on the same line as you Jeffl, my current customer, a big regional administration TI department in Madrid (Spain)

We have defined two committees one like ITIL CAB, and one smaller committee like your ORR, this committee is very small and its only purpose is to asses if that release to be put into a production environment is acceptable in terms of nomenclature, a good and tested back up plan, a brief explanation of new functionalities, and also should decide at which time and hour this release should go live in order to avoid problems with production procedures like back_ups, etc...

Members of my "ORR" committee are a senior specialist from production environment and the lead engineer on the release build, they should decide if that release is acceptable to be put into production, the chairman of this small committee is production team leader.

I really think we are following ITIL best practices with this two committees. CAB and as JeffL call and ORR, which we call in Spanish (Comite de Paso a Producción)

As several of you mentioned, we do not want to get too hung up on ITILopia. One of the components of ITIL that is difficult for people to grasp is the idea that multiple processes can be utilized by the same person or group. In the process world Change Management is the go / no go decision point (in multiple spots..not just the initial authorization of the RFC) and Release Management is the execution of the work. With that said, you can implement ITIL with both a CAB and a ORR and have both teams working within the Change Management Process. ORR would receive the test results from the Release Management Process and make the go / no go decision within the framework of Change Management. As others have mentioned, I would set the decision for ORR involvement based on the Change category. This would prevent bottlenecks for some of the lower impact and urgent changes.