Construct a Service Level Agreement

Service Level Agreement (SLA) is used to manage the performance of a service. While it may not yet be common as part of your development project, an SLA can improve the quality of the development process, 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. This article examines SLAs in software development: why you might consider one and tips for creating one.

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 nailing your colours to the mast, 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.

Depending on the project size, budget, schedule and risk you will also want to consider software development best practices like quality assurance and unit tests.

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.

Choose a project methodology
At first, selecting a project methodology to suit the project seems almost perverse. Instinctively perhaps, we seek one true way, the perfect methodology that will deliver project success, efficiently and gloriously. Listen to the rhetoric of any process evangelist for long enough and you too will start to believe. The nagging doubt remains, though â€" if their process is so good, how come there are so many others?

It is important to ignore quasi-religious arguments and focus on the customer and the project. Each customer and each project is different â€" no single methodology can accommodate all permutations.

There are many alternatives and you should adapt one to fit your specific requirements. Scott Ambler, a pioneer of agile methodology, points out in his article 'One Size Fits None' that doing this requires an understanding of the project and of the strengths and weaknesses of a variety methodologies.

The SLA must state the project methodology selected and the associated features and performance standards. A customer may not care much what methodology is selected but they will care about how it affects the project.

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.

For ideas on running a good meeting, drop in on your local Toastmasters. These meetings have defined rules; for example, they start and finish on time and speakers are kept to their schedule. As a result, they don't descend into the interminably boring monologues we loathe so well.

Shared workspace
Projects generate a lot of information â€" documents, discussions, issues registers, contacts lists and events. Centralising and sharing these is a useful way to co-ordinate key aspects of the project and keep the customer involved.

To really be useful, the entire project team must be able to access the resources from wherever they areâ€"the office, home or on-site. A Web-based extranet is a good solution.

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. E-mail is an extremely poor tool for this job. I have often seen relationships degenerate into slanging matches over the supposed contents of e-mails. A single, central register of issues should 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.

Formal project management
In general, project management requires different skills to software development. Despite this, senior developers are frequently asked to not just lead the development effort but also manage the budget, schedule resources, be responsible for recruitment, manage the customer relationship and walk on water. This is not just unreasonable; it is frequently deadly to the relationship with the customer.

Project management involves an additional cost that customers are sometimes unwilling to meet, especially if they have had poor results from project management in the past. An SLA that defines the outcomes and standards for project management will go some way to alleviating their concerns.

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.

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.

Software -best practices"
These are practices specific to software development; properly applied they can improve quality and productivity. They include nightly builds, feature reviews, sign-offs, defect count tracking, code commenting, documentation, quality assurance, variations, peer reviews, unit testing and user acceptance testing.

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. I'll use specifying a benchmark for feature reviews as a practical example to demonstrate these in action. The first cut of the benchmark is pretty simple: -We will do feature reviews of the software."

Some fairly obvious questions are raised by this statement: What is a feature review and why is it necessary? Who will do the review? How will it be done? When will it be done? This is definitely not a SMART standard â€" it leaves too much open to interpretation.

To improve it, first make the statement more specific, addressing what is to be achieved, why and how. -A feature review checks the completeness of the software against the documented requirements, and the requirements against the business need. This ensures that the software delivered meets customer expectations.

Before the first review, the provider will deliver a version of the requirements summarised into point form. This will be reviewed and agreed by the customer.

A feature review will consist of a meeting of the full project team â€" that is, the combined development and business teams. During the meeting, the development team will show how each requirement has been implemented in the software, using the latest build of the software to demonstrate.

The customer is responsible for deciding whether each feature has been correctly implemented." That's much more specific. Being specific also allows the development team to check that the standard is achievable and realistic. These measures depend largely on the capabilities of the development team â€" skills, knowledge, experience and time.

The statement is still not entirely SMART: it does not have a timeframe or provide a basis for measuring performance. More detail is required:

-Three feature reviews will be conducted: the first at 50 percent code complete, then at 75 percent code complete, and the final review will be a condition of the software entering formal testing (QA). Of the features said to be addressed, 90 percent will be accepted as being complete by the customer."

In this case, the schedule is based on milestones in the build phase. More concrete dates could be provided by relating these points to the project plan. There is also a clear, measurable standard expressed. Anything less than this may point to problems in development, specification or communication.

This is now a goal for the project and an early warning system. It will re-assure the customer to know that they will be asked whether the requirements have been met and give them confidence that you will deliver software that is of value to them. By including it, you have demonstrated an awareness of a common problem in software development â€" incomplete or inconsistent requirements â€" and shown the determination to address it.

An SLA a day
You certainly do -get what you measure", but an SLA is intended for much more than simple measurement. It is a tool for improving software development and customer relationships by setting achievable and realistic benchmarks. While the quality of software development has improved in the last 10 years, there is still much to be done; an SLA is part of the answer.