Let’s first focus on understanding what are acceptance and success criteria from a project perspective and then delve into its differences. Clear communication plays the key role in defining both acceptance and success criteria. As per PMBOK5 “Acceptance criteria are a set of conditions that is required to be met before deliverables are accepted”.
Success Criteria on the other hand is more of project management practice where success factors like cost, schedule, customer satisfaction, cost benefit analysis, ROI etc. are evaluated.
Acceptance criteria are part of the work to be done and is used to evaluate the deliverables. Once the deliverables are accepted at each stage of the project, the project officially moves to the next stage.
Acceptance criteria are part of the requirement document and the project scope document. Acceptance criteria are more of a set of statements or in other works checklist which should be answered with clear Yes/No or Pass/Fail and is applicable for functional and non- functional requirements. It has been observed many times that the team end up writing the acceptance criteria post the development work.
This will only ensure whether the product is working fine. But the goal of having acceptance criteria is more to do with meeting the user requirements and expectations. Different organizations follow different formats to write the acceptance criteria. Basically it should contain the given condition, action being done and the consequence of the action.
Some of the examples of acceptance criteria are:
- If a user is able to submit the filled form in a website.
- Whether a particular financial transaction is completed.
- User is able to order a particular thing over an e-commerce site.
- Invoice is created for a particular order.
The above examples do not discuss how the functionality is done and talks more on what is to be done and it is more likely to be at high level.
Acceptance criteria bring everyone in the project, including the stakeholders on the same page and thus removing any ambiguity in the requirements. Acceptance criteria should be testable. Before we say a user story or a requirement is done, all the criteria should be met or fulfilled. These have to be written and agreed upon by all the stakeholders before the development starts.
Success criteria are more of an introspection to check how well the project has been executed in terms of ROI, cost benefit, profit margins etc. Measurable criteria can be established at the beginning of the project which will define the project success rate later. Measurable criteria would have both qualitative and quantitative aspects of the project. The scope of the success criteria is larger compared to acceptance criteria as one is done at stages and other at the overall project level. The target audience for both are different
The scope of success criteria has been changing since its inception. The scope was limited to the implementation of the functionality, meeting the deadlines, maintaining the cost etc. The scope has been increasing since then to have quality metrics also to be part of it. The success criteria would be judged from the eyes of the stakeholders.
Few examples for the success criteria are:
- Whether the customer is happy
- Did we deliver on time and within budget
- How well it helped the client to expand their business
- How reliable and available the system is
- How secure the system is.
The project charter should have the success criteria defined in terms of
- How are you going to measure the success criteria
- Who is going to measure the success
- When and how often it should be measured.
Success criteria can be measured in a simple yes/no approach or with more descriptive method. Yes/No is a very discrete way of measuring where we say if the particular activity is done or not. Descriptive or continuous measures are for a range of values which vary with time and are always better over a period of time. We can take the leaf from some of the successful projects from the past to draft out the success criteria for the current project. It has to be as simple as possible without any jargons. Go through the success criteria ‘N’ number of times to make sure it is readable, not ambiguous. Split the criteria wherever required to remove ambiguity.
Some projects have Key performance indicators or KPIs which help in measuring the project performance against the success criteria to help us know where we stand at any given time.
In the real world, most of the projects fail. It is easy to call the project as failure when we don’t know how the success looks like and the definition of success is not discussed or documented. If success criteria are not defined, it is difficult to say on what ground the project failed.
How do acceptance criteria differ from success criteria?
Based on our understanding of acceptance criteria and success criteria from the above discussion we observe
- ULTIMATE GUIDE for Preparing PMP® Certification Exam PMP®
- Self Study Training – Project Management Professional (PMP)® Certification
Having a clearly defined acceptance criteria and success criteria would benefit the team in achieving success with clearly understood vision by all the people involved in the project. And this can be achieved by proper project planning and clear communication.
Clear and crisp definition of these criteria’s is important and it ensure right evaluation. In absence of these criteria project will always suffer in its evaluation. It’s something like, work is accomplished but team and management struggling to identify whether it’s acceptable or not and whether it’s successful or not. This is the very reason why these criteria is required.
- What are Scrum roles and why it’s needed? - August 12, 2017
- Stakeholder Analysis – Is it required? - July 28, 2017
- Project Manager – An integrator, how? - July 28, 2017
- Different PMI Certifications – Which one to choose? - July 28, 2017
- What is the importance of Change Management in Project Management? - June 23, 2017
- What’s important to know to build a career in Agile? - June 23, 2017
- Agile Basics, Manifesto & Principles - June 23, 2017
- Scrum – Is it mandatory to learn in today’s IT market? - June 2, 2017