We r in process of minimizing the no of scheduled changes as a package and wanna implement release management in our project..... But our management told that change manager has to be release manager (They r not ready to recruit new resource for release). We have scheduled deployments that include patches installation, firmware upgradation etc...... So I wanna know whatz the best way to accomplish this task. If possible reply me with an example which would be very useful for me.......

First step is to tell the Change Manager that he / she is also the Release Manager.

That in itself will not change anything, although they may push for an immediate pay rise.

Then tell the Release Manager the scope of their role, the processes they are responsible for, stakeholders, KPI's which determine their success in the role, and then give them all the support they need to get on with it.

Since release is a more or less essential component in any change implementation, then the tasks involved are already being carried out by someone and the management is probably already being done by the change manager by default.

In making release management explicit you may well be increasing the required management activity. Again, the quality improvement achieved by this may well reduce the overall change management burden by making releases more reliable.

It takes a fairly large or very complex organization to require a full-time Release Manager and in many organizations, I'm sure that release management will be performed either by the Change Manager, by an operational section head, or by a development and support section head. In the latter cases probably under the direction of the Change Manager and on a basis of horses for courses.

The important thing, as swansong pointed out is to have the role formally described and auditable._________________"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

Swansong and Diarmid have touched some good points. I have worked with different companies where the release & change manager were the same person and it has pros and cons. In your scenario it is hard to provide you with an example as we don't know what's the type of organization for the project as it can vary from functional, matrix, projectized etc. This will determine the level of authority the Change & Release manager has and the level of auditing required.

But in general this is doable just ensure to have KPI's and metrics in place to measure the performance of release's and changes and try to fill the gaps and keep on improving the processes._________________Ali Makahleh
Configuration Management(Blue Badge),
ITILV2 Service Manager(Red Badge),
ITILV3 Expert(Lilac Badge) Certified.

“If you can't describe what you are doing as a process, you don't know what you're doing." W. Edwards Deming.

Yes, they can. Throw in config in the mix and you got yourself a Chg/Rel/Config function.

It all depends on how much of a management activity one person has or is able to manage.

I have recently finished a gig with a client where we have set up just that - a Chg/Cfg/Rel function. It is a small organization, with very minimal resources so the basic premise was if you have hand in one process you have hand in the other two. It's a classic ITIL answer of "it all depends".

We r in process of minimizing the no of scheduled changes as a package and wanna implement release management in our project..... But our management told that change manager has to be release manager (They r not ready to recruit new resource for release)...... So I wanna know whatz the best way to accomplish this task. If possible reply me with an example which would be very useful for me.......

Thanks and regards,
Shiva

Please excuse me for being a grumpy old pedant, but would you write a report using that kind of language? This is a forum of professionals after all. It doesn't take much

It could be done but I wouldn't recommend it if you have the budget. They really are full time jobs if you want to perform them optimally.

You really really need to qualify that observation with a reference to scale. It takes a relatively big organization to produce enough change to keep a release manager busy full time._________________"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

I like the concept of change and release management being together, as in an ideal situation, the change manager ought to know what needs to be released and the release manager kind of needs to know all the nitty gritty details of how to perform the change.

I have found that sometimes the change request isn't detailed enough for the release manager/operator to perform and thus resulting in corrupt deployment in production while all the traces showed that it worked in DEV, TEST, and QA.

On the flipside however, I believe that there may be risk issues involved if the Change Manager is the Release Manager as the segregation of duties aren't very well defined. It has a kind of feel that someone can request a change all the way up to production without appropriate avenues (pre & post review), or at the least makes it easier to conduct some kind of fraud/embezzlement through collusion etc (since the CM is also the RM). And for an organisation with millions to billions or more of financial data (like a client of mine) then the CM MUST be different to the RM.

In a software tool I put together, to address this issue, I made the process of Change Management and Release Management integrated, AND AUTOMATED. Meaning that when a change request is raised, it is logged, goes through the CM cycle (pre review) and schedules an automated deployment according to the change window assigned to the change request, and THEN requests for post review once completed.

Essentially the tool integrates both the Change Management role and the Release Management role. But since the process isn't manual, there is a huge risk mitigation, and also a nice consistent flow from DEV to TEST to QA to PROD.

From my perspective the best solution that will resolve consistency and risk mitigation (ie Control, Deployment Consistency and segregation of duties), is to use an automated tool, and hopefully that could help kill those 2 birds with 1 stone.

fascinating. I can think of a million questions, but just one for now: how does your software assess the business impact of the change without using people inputs?

Change management is a management activity, not a mechanical process._________________"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

So you need to raise a
* Change Request in the system making you the change owner,
* write the appropriate scripts for the deployment (Database SQL),
* schedule it to a change window,
* assign the appropriate pre & post reviewers

And then let the magic happen! =D (of course ppl need to review)

And you're right, it is a management activity... the tool provides oversight for management and allows them to be involved in the change process through the review process, while not having to get down to the nitty gritty of copying a file here and pasting it there etc.

It also maintains a traceability so you can ALWAYS trace back to EXACTLY what the script executed was... whereas with an operator performing the change... they MAY have accidentally performed the change incorrectly. Who knows they may add an extra few 0000s for a bank deposit while the entire CM process showed that it should be less all the way.

Another issue we found at one of my client's is that they had a whole team pretty much just copy and pasting stuff (coz they shouldn't change anything!), but then for 1 of the changes, they used a DIFFERENT tool to what developer's used in TEST and QA, and PROD almost blew up.

So this tool is hoping to add a consistent process throughout the entire cycle.

Release-eZ is ready for a trial at the moment and while we have plans to expand it to do all forms of deployments/releases etc, it is at the moment ONLY exclusive to Database deployments via SQL.

Let me know if that answers some of your questions Diarmid... and also if you want to find out more... feel free to drop me a private email._________________Al_RelEZ_Al

Some thoughts:
CM can very well be RM. After all, the Release function (viewed from outside) is a lot about visibility to users and other processes. In its crudest, most rudimentary form...it could just be enough to show a published and accurate FSC to the business.

Internally - it´s a bit more complicated, of course. I would not recommend these two roles to the same person, but I´d have no problem handing RM to a person close to CM, for forced communication and documentation reasons. The handover between CM <>RM is often done "silently", with no documentation at all if the roles are held by ONE person. Bad thing for visibility.

Ideally, CM, RM and the config people should work together as a team, IMHO.

Release Mgmt in its more elaborate incarnations will, of course, consume time and resources.

My responsibilities have been shifted around and now I am responsible for Change/Release/Config in our organisation.

As to the question of whether one person can do it all effectively, in my case I would have to say no! Quite when management will start to listen to me telling them that I can't do everything properly, well that's anyones guess but I am trying!