Criteria for Accepting Deliverables

What criteria do you use to accept a deliverable? Have you ever even thought about it? I recommend applying more scrutiny to whether a deliverable is complete when closing a task. Here are criteria for deciding whether to accept a deliverable and close project tasks.

• Deliverables have been produced and can be reviewed. You can’t accept a deliverable if it doesn’t exist yet – or you don’t know that it’s ready. The deliverable for a completed task (software code, machine part, installed stovetop, etc.) has to be shared and then validated. If a deliverable product or service can’t be reviewed (maybe the software is complete, but the server is down), then the tasks to produce that deliverable have to be kept open until the review is completed.
• Acceptance criteria are met. The next level criteria is that the deliverable passes the tests and meets the stakeholders expectations. (This is why it’s important to document acceptance criteria before work starts on tasks.) If stakeholders aren’t satisfied, a task needs to stay open or new tasks have to be added to your schedule to correct the deliverable, so it meets expectations.
• Broad stakeholder approval is received. In some cases, deliverables need to be reviewed by other stakeholders after acceptance criteria are met, for example, customer reviews. The customers might not have provided acceptance criteria, but their views on the product’s viability are important. For this broader review, you distribute a sample of a product and collect customer opinions. If issues are raised, the related task(s) have to stay open or new tasks created to complete the work that needs to be done.

Sometimes deeper examination is called for before accepting a deliverable and closing project tasks. Consider the following techniques:

• Does the product contain scope creep items? Scope creep usually occurs when a well-meaning stakeholder shares an idea with a well-meaning project team member. If that idea makes its way into a deliverable without going through the change management process, voilà, scope creep. If you find scope creep in a product, you should consider whether to accept a deliverable or ask your team member to remove the scope creep item and re-submit their product for review and task closure. For example, you might not accept the deliverable with scope creep until it has passed the change control process. Or you might decide that is the result of a broader interpretation of a requirement and does not have to go through change control. Some people might leave it in because “it seems to work,” but the rest of know that is an irresponsible thing to do.
• Complete a detailed quality audit. At times, particularly in regulated industries, products aren’t considered viable until certified personnel have conducted a detailed review or audit, (medical instruments for example.) This activity usually goes above and beyond the acceptance criteria provided by internal stakeholders. When this audit is required, do not close tasks until the audit is complete and results are satisfactory.
• Does the deliverable include appropriate documentation? If you don’t have a separate project task for creating product documentation, documentation needs to be delivered along with its corresponding deliverables before accepting the deliverable and closing the task.
• Does the deliverables support successor tasks sufficiently? This acceptance criteria is often missing: whether the deliverable provides what successor tasks need. Don’t close a task until someone confirms that its deliverable allows successor tasks to proceed. 
• Does the output create new risks? Sometimes, the approach taken to produce a deliverable is different than planned. As a result, downstream risks may arise, even though the product meets all the acceptance criteria.  In this case, consider whether to accept the deliverable. You might want to ask your team to use a different method that doesn’t create new risks.

What do you look at before you accept a deliverable?  Do have any best practices to add to this list? Share with us in the comments section.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 63,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________