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.
| 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.