The level of technical knowledge required to read the article: ⭐⭐⭐⭐⭐ (medium) - the article requires an understanding of the project development life cycle

At the end of the implementation phase, when the developed system is deployed and usable in the customer's environment, it enters the next phase of the life cycle, maintenance.
The maintenance phase is the longest of the phases as it lasts from the time the system is delivered to the users until it is decommissioned (it is replaced by a newer version of the software or the business process no longer requires the software), and it is considered that its life cycle has ended.

Maintenance includes three main blocks:

1. Prevention of errors and potential problem situations;
2. Processing of change requests, agreeing on their costs and implementation deadlines;
3. Planning of further system development works, which can be shaped and developed as a separate project.

Maintenance is the system management process, within which it is "looked after" in cases where circumstances arise that were not foreseen or could not be foreseen during the development phase; for example, significant structural changes in third-party solutions, a previously unidentified type of data input, data processing methods different from initially planned, etc. Maintenance also includes Customer and end-user support and consultations, identification and implementation of various Change requests, as well as planning for further development of the system.

When planning the further development of the system, it is important to make an objective assessment of its remaining operating resource - for how long is it useful to continue using the specific solutions? Thus, in case of necessary changes, it will be possible to make reasonable decisions about making changes within the existing solution, updating it, or planning a partial or complete replacement of the solution.

Why is the maintenance necessary

In order for the developed software to operate at the maximum level of performance in the long term and to ensure the continuity of its availability, the system requires constant maintenance after its implementation.

During the software maintenance phase, developers regularly:

• implement various system updates;
• develop and apply security patches, eliminating potential vulnerabilities;
• monitor and optimize performance;
• correct detected errors in the operation of software;
• in cooperation with the Customer, identify Change Requests or functionalities to be implemented, evaluates their labor-intensity and agrees with the Customer on their development. Implementation of change requests is usually an additional paid service.

A short period of software support after the implementation of the solution is often included in the Project Development Agreement. During this period, the Customer must make a decision whether to maintain the system himself, enter into a further contract with its Developer or agree with another service provider who will ensure further maintenance of the software.

What is SLA

When the Customer agrees with the Developer on software maintenance, a maintenance agreement is concluded, the essential part of which is the Service Level Agreement, or SLA.

SLA is a document that defines the level of service provided and its quality criteria. It summarizes indicators, obligations and expectations of the Customer, as well as sanctions in case the agreed service level is not reached.
Minimizing the possibilities of interpretation, the agreement stipulates mutual action in case of need for support, service quality criteria, service availability and obligations of both parties. The SLA states the responsibility of the service provider and also the circumstances in which it does not occur.

An SLA can be thought of as a cooperation manual.

What is included

This manual defines the cooperation terminology, as well as the specific expected actions and speed of action of each Party in the event of an application.

1. Types of service provision that may be included in the maintenance contract:
   • User support - includes consulting services, joint meetings, if the Customer has any doubts about the operation or functionality, use, maintenance of the solutions, etc.
   • Error correction - includes the services of diagnosing and correcting malfunctions of the software, which are performed in case of its incorrect operation and failure of functionality.
   • Monitoring of systems and networks, ensuring the continuity of operation of the solution to the agreed extent (for example, 99.95% availability within 365 days). Software updates and upgrades.
   • Implementation of changes - identification of necessary additions, adjustments and improvements, assessment of labor-intensity, coordination with the Customer on their costs and implementation period, development.
2. The procedure of registration and processing of submissions (who, in which channels, what is the minimum mandatory information, what is the processing flow, etc.), which can be adjusted according to the needs of the Customer or the specifics of the software.
3. Application priority levels.
   Priority is determined based on the impact of a potential problem on the "health" of business processes. Priority levels and their importance are also discussed in detail in the contract. An example of prioritization can be seen in the table:

   Application category	Description of the application	Priority level
   Breakdown	An essential system function cannot be performed or cannot be used at all. Financial losses are caused to the Customer or its partners.	Highest
   Significant	The system can be used in a limited way, and there is no known workaround.	High
   Less significant	It is possible to use the system in a limited way, and there is a known workaround.	Medium
   Irrelevant	Inconveniences or difficulties in using the system have been detected, but critical functionality has not been affected.	Low
   Change request	Request for evaluation and development of additions, adaptations and improvements.	Low
   Consultation	The customer's uncertainty about the operation or functionality, use, maintenance of the software, etc. Statements of problems for which the Parties agree during the consultation that the problem does not actually exist.	Low

4. Response time according to the priority of the application.
   The reaction time determines the deadline in which the Developer accepts the application for consideration and starts its execution, informing the Customer about the potential solution delivery time. Solution delivery time is the moment when a solution to the reported problem is delivered.
   The key is to agree on SLA terms that both Parties find fair and objectively enforceable. For example:
   • The parties can agree that the reaction time of the highest priority application is N hours from the moment of registration of the application, while the lowest is 4xN hours.
   • The time for accepting and processing applications can be negotiated (for example, working days from 9:00 to 18:00).
   • Also, an agreement may be included that the Developer is ready to respond outside of working hours in case of breakdowns, but an increased hourly rate will be applied for this time.
5. Guaranteed volume of work per month.
   The parties can agree on the number of guaranteed hours per month: The Developer guarantees the availability of these hours, while the Customer guarantees the provision of orders in the appropriate amount.
   In such a case, the contract contains reservations about the order and response time of applications that exceed the guaranteed number of hours, as well as what happens in cases where the Customer cannot provide work in the amount of these hours per month.
6. KPIs and metrics for measuring the quality of the fulfillment of obligations (response time, ensuring the guaranteed time, etc.), the responsibilities of the parties for non-fulfillment of obligations.