Change management

This document regulates how changes are made to Chemwatch software products. The process applies for the changes bigger than 3 days in size, as well as changes having significant user impact and risks related to releasing them to the public. 

Change authority

Change authority is a person or a group of people responsible for authorizing a change.

Benefit and risk analysis

The following aspects have to be reviewed when allowing a change:

• Benefits
• Risks and opportunities, including security risks
• Impact on existing clients
• Impact on future clients
• Changes required to the operation procedures

Reviewers:

• Stakeholders (must be representatives from CS and domain/account managers if not the same people)
• Helpdesk
• Developers
• QA

Change control

There are two possible sources of changes:

• Internal
• External (customer requests)

Internal requests require CEO approval to be started.

External requests are reviewed every 3 months by Stakeholders to decide whether the change is reasonable to do.

Some changes can be escalated by Helpdesk, Customer support, QA, or Development team. In this case, the CEO's decision is necessary to move on with the change.

Notification

In case when a change can affect user experience, the clients must be notified. We have the following means of notification available:

• Email blast (organized by Marketing and CS teams).
• In-Apps one time notification (organized by IT team).
• Login page notification (organized by IT team).

The timeliness of notification is ad-hoc and decided based on the nature of change and impact. The notification requirements is a part of release and deployment plan, written for every sizable update.

The notification text and images should be created by Stakeholder immediatelly after completing the requirements.

Critical functionality

This includes:

• WebService API 2.0 - which is guaranteed to provide data in 24x7 mode to outer systems.
  
  

Production Environment Change Control

Production change is usually an ad-hoc process, depending on what change is planned. For example, Database upgrade procedure and corresponding risk assesment may be quite different from upgrading OS or .NET version. In any case, each upgrade (change) to the environment happens in these steps:

1. Risk assessment / mitigaiton plans.
2. Implementing change on Dev / then test.
3. Implementing change on Staging / then test.
4. Only if tests passed and risks mitigated the change does to production.

Supporting documents

• Customization analysis and approval flow - covers the details of the process how to deal about outstanding changes required by a client.