New course in web governance for online managers
5 lessons in online operations, leadership & management
90 mins video + 140 page illustrated guide + quiz test
"Shane is extremely knowledgeable. Working with him was a no-brainer."
CEO Siteimprove USA
"A lot of practical depth. I think that someone managing a large site would find it genuinely useful."
Web Content Strategist
New 3-in-1 bundle ... just $19.99
FULL '5-lesson Masterclass'
+ FREE original 'Web Manager's Handbook' (usually $9.99)
+ FREE editable 'Online Governance Manual' (usually $9.99)
» Download free samples: Masterclass or Handbook & Manual...
Change Control is a process for implementing technical and other updates to a website in a timely and non-disruptive manner. Because most sites are made up of a huge assortment of different technologies, this can present quite a considerable technical and administrative challenge. Fortunately, the process by which amendments can be managed encompasses just four steps:
- Identify the nature of the change.
- Identify the scale of the change.
- Identify the possible impact.
- Proceed or re-evaluate.
1. The Nature of the Change
The most common amendments covered by Change Control are those concerning the infrastructure of site hosting and the technology used to deliver content. In summary, these are:
Changes arising as a result of software maintenance
Problems may be found in the operating system used to run a site, which means emergency patches are required.
Changes arising as a result of hardware maintenance
This can involve the replacement of faulty components, as well as upgrades to cope with high levels of traffic, e.g. more memory.
Changes arising as a result of the initial release of content using a new technology
For example, the first use of video on a website would require significant planning in order to get it right.
Changes arising as a result of marketing activity
A campaign to attract more traffic to a site may lead to additional resources being needed to cope with increased activity, e.g. a faster connection to the internet.
2. The Scale of the Change
The scale of a change is a measure of the fraction of an existing infrastructure affected by it. It also encompasses the quantity of resource required to make such a change possible. For example, the implementation of a Website Content Management System is significant in terms of its effect on existing technology and in terms of the number of people required to expedite it. However, the interpretation of scale can differ from one site to another. For example, a replacement of the computer used for hosting a small website would represent a large change relative to its size. Yet, the same activity on a big eCommerce site could be considered quite small.
3. The Impact of the Change
The impact of a change is a measure of its effect on site visitors, business operations and site administration. In this regard, there are a number of attributes that should be reviewed before activity commences. These attributes provide a means for identifying elements that are particularly sensitive to change. They are:
Event Sensitive: This encompasses technology that (from experience) is known to be very sensitive to amendments of the type planned.
Business Critical: This includes elements that, if adversely affected, would have a very negative impact on the business, e.g. the loss of an online shopping application.
Frequently Used: This concerns elements that are very frequently used, so that if they are impacted, many customers would be inconvenienced, e.g. an intranet phonebook.
It is worth noting that large changes do not always have a big impact. For example, suppose the software used to run a website needs to be upgraded. While this will have a significant effect on site administration, it could be invisible to visitors (if properly managed). On the contrary, small changes can frequently have a very large impact - especially when they go wrong. For example, a botched hardware repair could result in a site being unavailable for several hours.
4. Proceed or Re-evaluate
Once all the facts have been considered, the decision to proceed with a change (or not) must be taken. For example, where the risk is unacceptable, the change itself (or the process of implementation) must be reconsidered. However, where the evidence suggests that risks are within acceptable limits, the project can proceed as planned. If so, it is advisable that it be scheduled to take place at a time when any negative effects are minimised, e.g. after business hours.
Contingency and Testing
Additionally, a contingency plan should be in place in case things go wrong. For example, if a software upgrade fails, it must be possible to halt the implementation and revert to the previous state with no loss of data. Once the change has been made, testing must ensue to make sure the site continues to function as intended. Furthermore, the affected site may need to be closely monitored for several weeks. This is because the complete impact of a change may not become obvious for some time.
The activity of Change Control is explained in extra detail in The Website Manager's Handbook, now on sale.