c. One called "Change Risk" with Enumerations of "Minimal, Moderate, Significant"

d. One called "Change Type" with Enumerations of "Low, Medium, High, Emergency"

It should look like this:

2. When a change needs to tracked, a ticket is created with a title, "Request for Change", or "RFC".

3. The description of the change, the roll-back procedures, and all other required normal change management information is included in the ticket. In some instances, the requestor attaches a document with additional information.

4. The ticket is assigned to IT Manager (me) and I mark my approval in the ticket.

5. If other approvals are needed, I then assign the ticket to those individuals for their additional approval.

6. After all approvals, the ticket is assigned to the Infrastructure technician performing the work and closes it when the task is completed successfully.

Now, some of this requires solid business processes to work, but so far it’s worked great. I am able to pull reports at anytime through the custom Change Management Report I created and review past, present, and future RFC’s. I’ve even exported the reports to Excel and created great slides and graphs that Senior Managers love. But, most importantly I’ve been able to associate all RFC’s with a real devices in our infrastructure inventory – a vital requirement for our tracking purposes.

It’s worked great for me, I hope others can find useful things to do as well!