It's quite clear that ideas from Continuous Service Improvement (CSI) activities will end up as Request for Change at some point. In fact the v3 CSI manual states:

Quote:

Once CSI has come up with a recommendation for improvement, a change request is submitted.

What I want to know is when does the control pass from CSI to Change Management?

The issue which has prompted this question is as follows:

Another part of the IT department have developed a CSI process for one of our major systems (and about time to) but it basically just pulls together the multiple ways improvement ideas are logged and processed. The suggested CSI process has six steps: log, assess, approve, plan, implement and review.

As the change manager it's blindingly obvious that this process an exact copy of an ITIL change process so I believe the new "CSI" process should be managed within the change management function and that the only true bit of CSI is initiating the ideas.

Although most people can see where I'm coming from, they want the business to own the assessment and approval of ideas, only handing over to change management when ideas have been approved. The main reasons they give are that only the business understand which ideas/changes are valid but my response is that, as the change manager, I can't assess or approve the ideas/changes but I at least can own and facilitate the process to ensure it runs smoothly and compliments other ITIL processes.

Before I turn into a broken record and start contradicting my own points, can anyone shed any light onto when control should pass from CSI to Change?

can anyone shed any light onto when control should pass from CSI to Change?

Mick,

I think the answer is that it doesn't.

For example you could think in the following way:

The CSI process analyses the current situation, identifies areas with room for beneficial improvement, specifies and designs these improvements, commissions their build, all done with sufficient consultation and approvals to make sure that the effort is not being wasted.

Then the CSI process submits a change request that in many respects is already approved (or else you would have not gone so far with the development); change management develops the change implementation plan, obtains all approvals (no shortcuts just because the CSI manager says it's already done), and oversees the implementation, finally reviewing the change to confirm that it was done properly etc.

CSI now reviews the improvement to ascertain how far it meets its predicated effects. This is not the same as change review, because change review looks at a) the process of change and b) whether the change does the things it was predicted to do, whereas CSI looks at whether these things have the effect they were predicted to have.

The above sequence is just an example. The nature of the improvement will have a big effect on how you proceed and, for example, you might raise the RFC before the build, perhaps as early as after the feasibility study.

Change management is how you get your improvement implemented and is concerned, not with your improvement, but with its potential to adversely impact any or all services, during implementation and after implementation. So it never takes over. It simply does its own job.

If I may backtrack a little, the very least that CSI must retain control over and manage itself is up to producing and having approved the detailed specification (including predicting the measurable or otherwise ascertainable benefits), and then performing the improvement review after implementation. Otherwise it is not really a process.

It may be arguable whether CSI then commissions design and build or simply raises a change request providing sufficient specification for the commissioning (not managing) of design and build from within change management. I'm not sure there can be a hard and fast rule for this even within an organization because improvements can take so many forms.

I'd better stop before I lose myself here. Treat the above as thinking aloud, more than a real answer._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

CSI can take many a form - and it can have multiple approaches to it... An organization could have CSI performed using non-ITIL concepts like Six Sigma or Lean - which ultimately has its relavance to ITIL models in CSI....

The point is within CSI - if the improvement plan has been formulated and approved for implementation - the plan could have many operational modifications to be made with "changes in process/policies, changes in (manual) MS word templates, etc" and no change to the actual IT production system - here there is a change in how the process is being dealt with in comparison to the past to achieve better efficiency but the change management need not be involved at all because the CSI improvemnt plans never had a step which fell into change management's scope.

if amongst the series of steps involved in CSI improvement plan, there is a need to modify the current IT system with a change, then that step alone needs to come under the change management's scope and the change management would take ownership on deciding the approval for the step or suggesting alternatives, deciding the approval on the implementation plan and post implementation - verifying whether the change was implemented as per plan and if the result needed by the change is achieved... However - again change management would not validate if the result needed or expected by the CSI plan from this step is achieved or not - it is upto the CSI implementers to ensure that they scope the change so that if the change is successful the necessary result for the progress in the CSI plan is automatically achieved...

Mate - change management should lie in its scope and not strech beyond to disturb other ITIL process streams.....however, within its scope the change management has all the authorities to decide...._________________Regards,
Subbu A
ITIL Certified and well experienced

Mate - change management should lie in its scope and not strech beyond to disturb other ITIL process streams

I hate to be picky with such a congenial post, but "other ITIL process streams" really should be "other process streams"._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

CSI can take many a form - and it can have multiple approaches to it... An organization could have CSI performed using non-ITIL concepts like Six Sigma or Lean - which ultimately has its relavance to ITIL models in CSI....

An organization can be doing, an in fact a lot do, CSI without knowing they are doing CSI. What I have seen in practice in most of the client organizations, CSI is a concept that gets executed without a specific targeted approach in a series of disparate, uncoordinated, left hand doesn't know what right hand is doing, kind of way. It DOES make an improvement in the organization, it does provide benefit... it probably just doesn't provide maximum benefit that could have been created...

I am yet to see a company that has a dedicated and coordinated set of resources to CSI. Not saying there aren't any... just haven't come across one.