Best Practices for Notifying Stakeholders About System Changes

Honestly, many people don’t read notifications, so we only send them out for major outages or changes. It's just more efficient that way.

We only give notifications for changes that might cause downtime. Most of the time, if there's nothing major, we just keep it quiet.

In our organization, if we expect low impact from a change—like turning off Fast Startup—we don’t notify users. They didn’t seem to care when we made that switch two years ago; everything just worked better after! But if it’s a bigger change affecting numerous users, we send a heads-up email and keep the helpdesk in the loop, ensuring they have the info they need to assist users.

We tend to avoid telling users about minor changes unless they will significantly affect them. If we inform them about everything, we just end up with a flood of unnecessary tickets. For our internal teams, we send straightforward emails with essential details, keeping it short and focused. That way, they know what’s happening without getting bogged down in extra info.

For us, the notification process varies based on the change's impact. We notify stakeholders 1-6 weeks in advance for significant changes and send them updates during the process. If it’s a low-risk change, we’ll give a heads-up, but if it's high-risk, there will be detailed documentation for the helpdesk and probably an email to all users about the maintenance window.