What is a Service Level Agreement

• The Service Level Agreement (SLA) defines the basis of formal understanding and communication between the developer and the client.

Service Level Agreement (SLA)

• reduce the risks of project failure and strengthen customer relationships.

• An SLA exudes professionalism - publishing and living by acceptable standards suggests a company understands its business and customers.

What is an SLA?

• The SLA Information Zone Web site describes an SLA as -a document which defines the relationship between two parties".

• The SLA sets benchmarks for the elements of the development process considered important to the relationship between the development team and the customer.

• While not officially a contract, the SLA can be used as part of a formal deal.

The difference between a contract and an SLA is in the intention and

tightness of the document.• A contract aims to formalise a

relationship and is binding in law; an SLA seeks to improve a relationship and is not legally binding. However, failure to deliver on the terms of an SLA and you will damage or break a relationship as effectively as any breach of contract.

Why implement an SLA? • Software development has a poor reputation for delivery. The

Standish Group's 2003 CHAOS report showed that over half of all IT projects were -challenged", facing difficulty in achieving requirements and budgets.

• The reasons for project failure vary but studies consistently identify criteria important to project success such as user involvement and clear requirements. An SLA is a vehicle for taking these principles out of the textbook and dropping them into real-world projects.

• Just as important is strengthening the relationship with the customer. Writing an SLA requires an understanding of professional software development and a real commitment to the customer. You are giving the customer reason to believe in your ability and knowledge.

What should an SLA include? • Include the major project success factors which are:

choosing a project methodology, customer involvement, formal project management and requirements management.

• It is also important to add items that the customer thinks are important. You may not always agree, but it is important to ask, listen and negotiate if you have to.

• Remember that the SLA defines a relationship; it is based on agreement and understanding. By getting the customers input you are strengthening the relationship and improving the entire process.

Customer involvement

• -Release early, release often" is a maxim often preached but rarely practised. The underlying lesson is that the customer should not receive any unpleasant surprises during the project: things like -we're 50 percent over budget" or -it's will take at least an extra two months".

Strategies for keeping the customer involved include

meetings, a shared workspace and formal issue management.

Meetings

• Regular, preferably weekly, meetings are often bemoaned by developers but can be the backbone and saviour of a project. If conducted well, they help flush out problems, strengthen relationships and deepen the team's knowledge of the customer's requirements. Run badly, they waste time and erode confidence.

• The SLA must specify the frequency of meetings and what will be done to make them effective. This includes having a standing agenda, appointing a chair person, time-keeper and record-keeper and distributing action items and minutes.

Issue management • This is one of the most important and least practised areas of

customer relationship management. During the course of any project many questions, problems and suggestions arise.

• It is essential to capture, store, prioritise and address these to run a project that the customer agrees is a success.

• It is possible to deliver what the customer said they wanted and still be seen to fail. Perhaps the requirements changed or were not fully expressed in the documentation.

• By listening to the customer and acting on issues as they arise, we maximise the chance of success.

• It is said E-mail is an extremely poor tool for this job. Professionals have often seen relationships degenerate into slanging matches over the supposed contents of e-mails. A single, central register of issues could be maintained, perhaps on the extranet.

• The technology is not that important but the register should be accessible to all parties and be constantly monitored and reviewed.

Requirements management • Understanding what the customer wants is an

essential part of delivering value. This is complicated because in some cases the customer may have only a rudimentary idea of what they want. In all cases, they are reliant on the technical expertise of the development team to advise them. Approaches to requirements management are the basis of software development methodology. For example, agile methodology typically assumes that the customer does not fully know up-front what is required. The so-called waterfall method starts with a formal and static set of well-defined requirements. Requirements management is therefore intimately linked with project methodology selection.

Requirements management (cont)

• The SLA must nominate the approach to requirements management and how changes to the requirements during the course of the project will be handled. This could include a change control process, adding the requirements to the features of a second release or re-quoting the entire project.

Requirements management (cont)

• Not all of these items will need to be included in every SLA; it depends on the project, the customer and the skills, experience and creativity of the project team. Don't be afraid to try new ways of doing things‚¬"success is a creative process.

SLA in practice

• Like most forms of performance measurement, an SLA should be SMART: Specific, Measurable, Achievable, Realistic and Time-bound.