I am currently working on a component of an ITIL Implementation project for Dept within a large Gov organization.

Everything is going along well, however there is one question that seems to be raising it's ugly head, and it's to do with CAB.

As all changes will now go through the Change Management process, invariably some of the changes will be from a business unit requesting a change to an application.

The question that continues to be asked is, "If Business Unit X is asking the application support to make a change to a particular app, and we tell them that the change must go to CAB for authorization, then Business Unit X is going to tell us (support) to get stuffed".

Business Unit X is also not under the same reporting line as the support group. In fact, they are outside of the dept altogether, however pay support $$ to admin and develop a particular application.

Now I know this is probably a question that often occurs, however I am looking for some real world examples or idea's how to best respond or tackle the issue.

My first thoughts are to speak to the Project Sponsor and raise it as a risk to the the project as perhaps some the Communications of the Project need to be expanded beyond our Dept (which in itself, is very large).

Another thought or attitude I have is that each Dept have their relative processes, however if they wish to make a change to an environment that we support, then they must comply with the rigours of any authoritive process we decide. Regardless of weather they pay us $$ for service or not.

Any thoughts, recommendations, ideas and direction are much apprecitated.

Who supports the application ?
Who develops the application ?
who grants and controls access to the developers/application team so that they can update the application on the dev/test and live environment ?

The answer to the question is as follows

That is fine, then

The application will not be allowed to be updated and if it is updated, we (support) wont provide support as it not a supported product_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

1) Senior Management support is required both to endorse it and ensure the different depts / reporting lines follow the proces
2) As John says the IT team are the gate keepers. Enpower them not to make changes unless approved and the process has been followed. Have the IT management report uncooperation to senior management to ensure that the IT depts are not being blamed for not doing the changes, they are just following a process designed to protact the systems and users of the system
3) You raise a good point by also working with the project sponsor to try and get the changes in._________________Mark O'Loughlin
ITSM / ITIL Consultant

It sounds like a normal government contract. By this I mean that the contract for support at both the service desk( I would bet that yours is a help desk) and the Operation group is the owner of the contract funds and the rest of the agency does what they want when they want. I would even go so far as to bet that in side of the other departments is servers that is on the network and is not managed by the OPS group.

Any Way thats how is how it goes! Your best bet is to look at your SLA's and OLA's to see if this will impact any delieveribles under contract and use your CO and COTR to apply pressure up the ladder. This could also help to unify the agency.

If you can show that the change will impact the contract that is dollars to the government and additional support cost to them. Your PM should be reviewing the contract for this impact.

Simple solution, any RFC that requires a change to the PRODUCTION environment requires a CR. That is clearly defined, business X cannot just push something into prod and expects CM to say Yes without a CR. Use your CM policies to the fullest, if need to be reinstated say so.

I had a similar problem on my ITIL implementation. I tried for a long time to deliver something that removed the change management risks, whilst at the same time appeasing the business. However there comes a time when you realise one is not compatable with the other. You also need to appreciate that there are certain things that as the project lead you cannot control.

In the end I simply rasied this as an issue to the Project Board, with the message that if they were serious about ITIL then this is something they would resolve. If they failed to resolve this, then they would have to live with the risk that change management process is less than complete and prone to failure.

In the end change management went live without resolving the above issue. However I made sure the board owned this decision and took the responsibility for the implications of taking this decision. It may sound like passing the buck, but isn't that project management is about? Passing decision making to the person best placed to deal with it.

it is not passing the buck. If there is not full commitment from senior management to endose and back a change management system to cover the required scope then it will not succeed even with the best of intentions and the best people in the world as people will just bypass it.

You do need a tough stance on the matter backed by senior management._________________Mark O'Loughlin
ITSM / ITIL Consultant

Mark, that is so true, that is the same that is happening this week at my client location. SM approved thier direct reports changes to go in tru month end freeze, what is the purpose of a month end freeze policy when there will be substantial changes to the production environment. Seems like SM are reinventing the wheel for their own gain and cannot adequetely plan projects with one additional week of lag time.