Change Management Flashcards
Change management
- Change control
- A formal process for managing change
- Avoid downtime, confusion, and mistakes
- Nothing changes without the process
- Determine the scope of the change
- Analyze the risk associated with the change
- Create a plan
- Get end-user approval
- Present the proposal to the change control board
- Have a backout plan if the change doesn’t work
- Document the changes
Scope the change
- Determine the effect of the change
- May be limited to a single server
- Or an entire site
• A single change can be far reaching
• Multiple applications, Internet connectivity,
remote site access, external customer access
- How long will this take?
- No impact, or hours of downtime
Risk analysis
- Determine a risk value
- i.e., high, medium, low
- The risks can be minor or far-reaching
- The “fix” doesn’t actually fix anything
- The fix breaks something else
- Operating system failures
- Data corruption
• What’s the risk with NOT making the change?
• Security vulnerability, application unavailability, or
unexpected downtime to other services
Plan for change
- What’s it take to make the change?
- Detailed information
- Describe a technical process to other technical people
- Others can help identify unforeseen risk
- A complete picture
- Scheduling
- Time of day, day of week
- Include completion timeframes
End-user acceptance
- Nothing happens without a sign-off
- The end users of the application / network
- One of your jobs is to make them successful
- They ultimately decide if a change is worth it to them
• Ideally, this is a formality
• Of course, they have been involved
throughout this entire process
• There’s constant communication before and after
Change board and approvals
- Go or no go
- Lots of discussion
• All important parts of the organization are
represented
• Potential changes can affect the entire company
- Some changes have priority
- The change board makes the schedule
- Some changes happen quickly, some take time
- This is the last step
- The actual work comes next
Backout plan
• The change will work perfectly and
nothing will ever go bad
• Of course it will
- You should always have a way to revert your changes
- Prepare for the worst, hope for the best
- This isn’t as easy as it sounds
- Some changes are difficult to revert
- Always have backups
- Always have backups
Document changes
- Something changed
- Everyone needs to know
• Help desk documentation
• Version numbers, network diagram, new server
names
- Track changes over time
- Cross-reference against help desk tickets
- Track before and after statistics
- Better or worse?