Deliverables in Software Development
Project deliverables are essential to everyone on a project, not just the project manager. They are a way to measure the project's success or failure. Deliverables can be as large as a milestone or as small as an email, but all deliverables should be treated with the same quality standards. So, what is a deliverable, and why is it essential to ensure it meets the standards of success?
Deliverables are project outputs. As a project manager, you may have multiple types of internal and external deliverables. You may have milestones, a group of deliverables required for the success of a specific portion of a project’s completion. You may also encounter reporting deliverables, which track the success, failures, and progress towards the project delivery.
Let’s refine the scope of deliverables now. In my experience, anything that goes to someone outside the team, whether your organization or a client, can be considered a deliverable.
This is important because anything you deliver should be treated with the same level of expertise and quality. I have worked at several places that did not treat their deliverables the same.
Example:
At one organization, we received client requests for database queries. The query request was often delivered directly to the client, but the client was dissatisfied with the results. Sometimes, it was due to the client not requesting the correct information. Other times, the database administrator did not understand the request and delivered improper results. The client complained that they wasted time and money fixing these query requests.
Once we discovered this was a problem, the project manager and I agreed to make a few changes to the client request process. First, we ensured the client adhered to a request process. They told us the needed information, and we helped define the query needs alongside the database administrator. Second, all query results were subjected to quality testing. We were not as worried about the data results, but rather that the content was what was requested.
These changes added a little overhead to the process but improved the success rate of the requests. Fewer came back to the team for refinement, and the clients were more careful with their requests.
The relevance is that we began treating these requests as deliverables and enforced our quality standards. The team had already implemented these standards in their regular feature work. It wasn’t difficult to implement it on query requests as well. When user stories came in from the client, we would refine the acceptance criteria before development began, and we always tested the final product properly.
Note that anything that is being delivered can fall under these rules. You don’t need to do quality testing on an email, but having someone else look at it before it is sent doesn't hurt. If you treat all deliverables as crucial to your project’s success, you will find that you gain better client satisfaction, which leads to a happier and more productive team.
