Service Level Agreement (for software development

project)
www.builderau.com.au
The Service Level Agreement (SLA) defines the basis of formal understanding and communication
between the developer and the client. Simon Jackson investigates why you need one for your project.
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 Groups 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 were 50 percent over
budget or its 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 teams
knowledge of the customers 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 dont 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 arethe
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. Dont be afraid to try new ways of doing thingssuccess 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. Ill 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. Thats 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.