Reading: Implement change
management system
Contents
Introduction ................................................................................... 2
Logging the change request .......................................................... 2
The expected impact of the change .............................................. 5
Risk management ......................................................................... 5
Risk identification ....................................................................... 6
Risk quantification ...................................................................... 6
Risk response............................................................................. 7
Document the expected outcomes of the change ......................... 8
Inform users of changes ................................................................ 8
Assign the change to the appropriate person for actioning. .......... 9
Reading: Change management
© NSW DET 2009
1
Introduction
Website systems can be large and complex. With this size and
complexity comes a growing risk of problems and faults that can
affect user productivity. Users have high expectations of live systems
such web servers. Although users generally accept that problems
and faults can and do occur they expect minimum down-time in
accessing website resources.
Together these two issues create a strong need for effective change
management systems to support the complex website systems and
the demanding expectations of users. Internal users and IT support
staff need to be able to quickly log change requests, receive a timely
response that the request is being processed, be kept up-to-date with
the status of the request and be informed of the outcome.
Logging the change request
Good change management involves three steps:

request for change

evaluation

decision.
All change management systems need some form of logging
information or reporting a request for change. These requests for
change must be in writing, no matter the source, otherwise control is
lost and a change history cannot be accurately built up over time.
Change must be controlled to make sure that the changes have a
positive affect on all existing systems. Usually this is done via a
change request form or via a helpdesk which can log requests.
Helpdesk systems are typically only feasible for mid to large
organisations or where the nature of the business creates a large
volume of change requests. Below is an example of a change
request form:
Change request form
Contact details
Requested by:
Joe Blogs
Date:
19/08/08
Phone:
(02) 9784-4501
Email:
[email protected]
Change request
2
Reading: Change management
© NSW DET 2009
Change requested:
Upgrade website to reflect new company logo
Reason for
change:
Website visitors need to be exposed to the new logo and all
uses of the old logo are scheduled to be phases out.
Priority:
Low 
Alternative
solutions:
None known of at this time
Roll back plan:
Backup website data. If the logo image update fails use
backup to restore previous logo.
Budget:
$150
Estimated time:
3 hours
Resources
required:
New web versions of logo to be created.
Medium 
High 
Website areas affected
Areas:
Home page 
Navigation 
Other content pages 
Database 
Other systems:
Web server hardware Web
server software 
PHP 
Content management server 
None
Approval/denial details
Network manager
Approved:
YES 
NO 
Conditions for
approval:
CIO approval required YES 
Date:
20/05/09
Signature:
Peter Smith
Reason for denial:
NA
CIO Approved:
YES 
NO 
Operation performed after 7pm and before 8am.
NO 
Conditions for
approval:
Date:
Signature:
Reason for denial:
Response/Action
Action to be taken
by:
Joe Blogs
Reading: Change management
© NSW DET 2009
3
Planned date and
time of action:
Date: 21/05/09
Time: 7pm
Completed:
YES 
Outcomes:
Logo image swapped to new version and rendered correctly
in all approved browsers.
Follow up required:
Test with older version of browsers.
Other comments:
NA
NO 
There may be several versions of change requests to suit different
users and businesses.
As you can see from the example change request form both you may
to assign several people to sign–off on a request. The exact
procedure for the change request and its approval will depend upon
the size, structure, policies and procedures that are in place in an
organisation, the type of change required and the number of users
that are impacted. A balance must be found between efficiency and
risk. If too many people are involved in the approval process it can
take an inefficiently long time to make small modifications. However,
if too few people are made aware of the proposed change then
potential problems may be overlooked.
Complex and expensive modifications may require a more detailed
analysis than a simple change request form. If there is some doubt or
if the change is extensive, further research and testing should be
conducted. A final change should be made only after a
recommendation for approval or an alternative has been signed off
by the appropriate person, being the business owner or manager as
they have responsibility to pay for the work or solution.
When designing a change management system there are some
important things to consider:
4

All changes must be requested in writing and submitted via
systems such as email or an online form. This is vital if your
business uses an external IT provider to maintain your web
presence.

Is the change justified? Staff actioning change requests need to
be able to identify that the requested change is necessary and
make sure that any resulting modifications are beneficial to the
website usability.

Change requests and resulting actions must be well documented.

All changes must be tested before implementation and measured
after implementation.

A follow-up system needs to be in place to confirm that the action
has been taken and has solved the initial problem
Reading: Change management
© NSW DET 2009

The change management system must be easy to manage and
oversee.

Scheduling and prioritisation systems need to be in place to allow
modifications to be performed effectively and in a timely fashion.

The change management system should be able to support the
allocation of resources to action the change.

Checks should be in place to ensure that changes do not pull the
organisation away from its core business or that changes in
peripheral systems are not implemented at the expense of core
business systems.

Escalation processes must be in place to allow complex change
requests to be actioned as quickly as possible.

Risk analysis of system changes should be conducted. For
example should there be checks to ensure that a change in one
system does not have an adverse affect on another system.
The expected impact of the change
Some of the website changes resulting from change requests may be
minor and only fix a small problem or the modification might focus on
web server systems with little obvious change to website users.
Other changes may have a strong and direct impact on users and
require a change in visitor behaviour new ways of using the site.
You need to clearly understand what will be the impact on users, and
what can be done to minimise the negative impact. Once the impact
of a change has been assessed you can consider more carefully
what the user may need to do differently and include activities in your
change-process to minimise this impact.
No matter what the expected impact to users all changes should be
documented and carefully planned. The ability to do this should be
part of the change management logging system.
Risk management
[Acknowledgment: The material in this section on risk management
has been adapted from the UpFront! Toolbox (601) ©
Commonwealth Australia 2004.]
Protecting live systems form problems arising from implementing
requested changes should be part of a risk management policy.
Reading: Change management
© NSW DET 2009
5
Any change to a live website comes with a level of risk. The level of
risk will depend on the complexity of the intended change and how
wide the impact of the change is within the website. For example
moving the website to a new web server will be a far more risky than
updating some downloadable documents.
A risk is something that may happen and if it does, it will have a
negative impact on existing systems. A risk must also have a
probability of occurring that is something above 0% and less than
100%. If there is no chance of it happening, then it is not a risk. If it
has a 100% chance of occurring it is a certainty rather than a risk and
must be factored into planning any modifications.
The second thing to consider is what type of impact it will have. If it
will have a neutral or positive impact, it is not a risk.
There are three stages to risk management planning:
1. risk identification
2. risk quantification
3. risk response
Risk identification
In this stage, you need to identify and name the risks. The best way
to do this is to communicate with users, managers and other affected
staff. Use a combination of brainstorming risks specific to the
planned change and reviewing standard risk lists.
Generic risks are risks to all changes, for example the risk that staff
may not be available to implement the change. Each organisation will
develop standard responses to generic risks.
Risks should be defined in two parts:

the cause of the situation (such as hardware failure,
excessive visitors, etc)

the impact (such as exceeding the budget, system downtime,
etc).
Risk quantification
Risks need to be quantified in two dimensions. You need to assess
the probability of the risk occurring as well as the likely impact if the
risk does occur. For simplicity, rate each on a 1 to 4 scale using a
matrix similar to the one you see below — the larger the number, the
larger the impact or probability.
6
Reading: Change management
© NSW DET 2009
Risk quantification matrix
Note that if probability is high and impact is low then this is a medium
risk, whereas if the impact of a risk is high and probability is low it is
high risk. A remote chance of a system-destroying risk warrants more
attention than a high chance of a small problem.
Risk response
There are four things you can do about a risk:
1. Avoid the risk - do something to remove it, for example,
contract specialist experts for complex changes.
2. Transfer the risk - make someone else responsible. Perhaps
the website designer or hosting provider can be made
responsible for a particularly risky change.
3. Mitigate the risk - take action to lessen the impact or chance
of the risk occurring. Keeping hardware under warranty or
having service level agreements in place with designers and
hosting providers.
4. Accept the risk. The risk might be so small that the effort to
do anything about it is not worthwhile.
Much of the risk involved in changes can be mitigated through careful
risk management planning. There are several fundamental tools you
can utilise to reduce the impact of a failed system change:

Backup- data must be protected throughout all stages of a
system modification. Backups are an integral part of this process.

Roll-back path-how will changes be undone if they are
unsuccessful. Are their sensitive systems, such as website
databases that are not easily restored to a previous version?
Testing of a planned roll-back path is vital to ensuring that it will
work as planned.

Standby operations-particularly for mission critical websites it
may be wise to have standby systems in place if a change fails.
Reading: Change management
© NSW DET 2009
7
This is can be done by running a duplicate website or hosting a
website across several clustered servers.

Optimise the current website -before implementing a website
change is a good idea to optimise the current site. Things you can
do include deleting unnecessary files, performing server
maintenance, installing updates and patches etc.
Document the expected outcomes of
the change
Documentation is vital. Changes can have a flow on affect where one
change leads to many more. It is important to manage this process
carefully to avoid adverse flow-on affects. You need to:

record reasons for changes

document the consequences of a change

make sure the changes are agreed to before they are put into
practice.
When documenting the expected outcome of a change you should
include:

what business problem is being solved

who will be affected by the modification

what systems will be modified

how will these modifications affect other systems

how will website usage and performance change

what resources will have been used to complete the change.
Both the change request form and change log systems should allow
the expected outcomes to be recorded and tracked to measure if the
final outcome and the expected outcomes match.
Inform users of changes
Once you have identified the implications of the change you can
consider if website users need to be informed and how best to inform
them.
The aim is ‘don’t keep users in the dark’. Communicate with users
what the changes will be, why the changes are being made, how the
changes will affect website usage, when the changes will occur and
8
Reading: Change management
© NSW DET 2009
reassure them that the changes are being made to improve their
website usage experience.
You may even be able to get website visitors to assist in the change
process by providing specific feedback about the change etc.
Assign the change to the appropriate
person for actioning.
The role you play responding to recommended changes can depend
largely on your role and the size of the organisation. If you are the
sole website support person in a medium sized company you may
have to receive the change request, prioritise it and respond to it
through to completion.
In larger organisations you may be working with IT support staff or inhouse web designers/programmers.
For simple changes you can probably resolve the issue immediately
and provide feedback directly to whoever logged the change. For
more complex problems will have to escalate the change to better
qualified staff.
Reading: Change management
© NSW DET 2009
9