Ongoing Change: Fast and Slow

Just because the change would be easy to implement doesn't mean it should be done quickly

When making changes to your web presence, some things should happen quickly, and some should happen slowly. Change that is routine and standardized should be fast—for example, publishing a routine webpage update should happen quickly. But other changes should be more considered. If someone is requesting raw HTML access to their page so they can add a new feature to their web page (perhaps to use a new JavaScript library), then that exception is probably easy to provide. But when thinking of your web presence as a product, allowing that workaround is usually not ideal. Obviously others won't benefit by this one-off, but in addition this will always be a separate page that has to be considered separately. For example, what happens if the custom work hard-codes your current color scheme? If you need to change that across the board later, then you have this embedded in this one-off code.

Some change should be fast, and other change should be slow

Ideally you introduce breathing room in your responses to requests. The first is probably to streamline things that take a long time now but should happen quickly. So for example if your current publishing process for routine content is confusing or slow, then this should be optimized. This would be a very high impact change for the website. It will also open up some breathing room to work on other important changes.

Some change should happen more slowly, if at all. Fundamentally, this allows you to consider changes. Some of the possible outcomes after more consideration:

• Potentially you realize that the request, although it was presented as urgent, is not nearly as important as other possible website improvements.
  

• The specifics of the request weren't accurate, or perhaps didn't really get to the true business need.
  

• Many of the requests, although seemingly different, actually could be grouped together as a deeper change.
  

• You can respond to the change in a way that people not even requesting the improvement could benefit.
  

For an example of the last bullet, if someone wants raw HTML access in order to add new data table functionality, then chances are others in your organization would benefit from similar functionality. If you create breathing room for considering and discussing this, then everyone can win (rather than just the requesting team if they get raw HTML access).

Find patterns, and move at the right speed

You should try to look for patterns. Any type of frequent change (that should actually happen) should be streamlined. Similarly, look for types of changes that are happening quickly that should be more carefully considered.

Place the types of changes that happen on your website (functionality changes, content changes, new sites, new topics, etc) on a simple grid of how hard they are currently to implement and how streamlined they should be. Try to set things up so these are better aligned.

Things that should happen quickly, and are currently easy to implement, should stay that way. Similarly, changes that deserve more careful attention should happen slower to allow the above types of responses to occur. That said, if things are currently happening quickly that are eroding your site quality, or just plain taking time that could be spent more effectively, then rules (or other restrictions) should be placed on those changes. Even better, it may be possible to shift the conversation so that you are looking at creative solutions to changes.