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.

Position	Level of authorization
CEO	Ultimate change authority.
Stakeholdes	Can pre-approve a change, but require CEO's review and sign off.
Everyone else	Can suggest 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.

For some parts, a change cannot be made until the form and date of it is agreed on by the client. Check Supporting Documents section for more information

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:

Risk assessment / mitigaiton plans.
Implementing change on Dev / then test.
Implementing change on Staging / then test.
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.

Browser not supported