Re: Change Management

From: dave <>
Date: Thu, 4 Sep 2008 16:46:37 -0400
Message-ID: <>

For routine administration we don't need a CM.. But we have IM's here (Incident Management) for items which require approvals. In this case, an IM would be required from a few sources and once they were obtained the account would be created.

Examples of a CM: code change, database init parameter change, patch, etc. IM: Reboot, create a user, add disk space, etc...

On Wed, Aug 20, 2008 at 1:39 PM, Ahbaid Gaffoor <> wrote:
> Today I had a developer object that I was raising too many CMs, here's my
> usual process:
> [CM = Change Mangement Request]
> 1) Receive a request
> 2) Develop the scripts to fulfill that request
> 3) Test them in an Alpha database and commit them into some form of source
> controls (CVS)
> 4) Do the final pre-production tests against the Gamma database (which is a
> pre-prod copy of prod) by checking out the source from CVS and running
> 5) Schedule the change *
> If anything changes before prod, it's back to Alpha to revise and test...
> 6) Apply the change in production by checking out the source and running it
> * When scheduling changes all interested parties are notified of the
> upcoming change and have time to revise and submit their comments.
> One of our developers (a senior one) complained today when I raised a CM to
> roll out a new user, it's role and it's profile in production
> I believe it's better to over communicate and schedule production changes as
> simple as they may appear, our developer feels that there was no need to
> raise a CM.
> What are your thoughts / experiences out there?
> Ahbaid
> --

Received on Thu Sep 04 2008 - 15:46:37 CDT

Original text of this message