Approach to ensuring alignment of deliverables with requirements
Deliverables are part of the contract and requirements are the actual needs from a system implementation. Usually, the two components of the project are aligned. However, you will be surprised by the number of times this is not the case. This article talks through practical steps to align them.
Business requirements explain why a goal is worth achieving and what the "future state" of the project may look like. Functional requirements specify, in detail, how the goal will be achieved. Deliverables typically combine related functional requirements into something tangible that must be accomplished. This can be project deliverable or a process deliverable. A project deliverable is a result. A process deliverable is a route you take to achieve that result. Our goal on projects will be align deliverables with requirements. To do accomplish this, we will implement the following processes:
Implement Traceability
The first step for us is to review the details within the specified deliverables and implement traceability for the functional and business requirements. We will categorize every requirement into applicable project or process deliverable. We will do this with the agency stakeholders to ensure the traceability is understood by all stakeholders by using the following key questions in guiding the implementation of the traceability:
What does this deliverable achieve?
What are this deliverable’s dependencies?
When does this deliverable need to be completed?
Agree on Definition of Done
Following the completion of the mapping the requirements into deliverables, we will work with the agency stakeholders to agree on definition of done for the deliverable. We will use the following key principles in building a common understanding of this amongst our team and the agency staff:
Are all requirements under the deliverable complete?
Was a demo of the product deliverable completed?
Was a sign off on the unit testing results completed?
Was a sign off on the functional testing results completed?
Was a sign off on the UAT results completed?
Was a sign off on the code review completed?
Was the necessary documentation provided?
Implement Frequent Reviews
Once there is an agreement of the definition of done for the deliverables, it is important that there are frequent reviews of the work product to ensure compliance with this definition. We will therefore schedule regular review sessions to ensure the agency staff is informed of our progress and we are able to make necessary modifications to align with the said objectives by focusing on the following areas:
Flowcharts to demonstrate the overall understanding of business processes
Details within the implementation specifications
Data Model to support the implementation specification details
Applicable wireframes to demonstrate key or complex functional components
Data flow processes to demonstrate how data is handled within the different system components
Data conversion documentation to ensure the agreement on what must be converted and how
Leave Room for Small Deviations
One aspect of systems integration projects that we have learnt is that is there always a possibility of changes or deviations from the agreed to deliverables. This can be a result of change in legal mandates supporting the system or a result of an operational change. Our design will allow for minor deviations. This is explained in section under technical design. We will add the additional requirements or modify existing requirements and implement them as part of the deliverable
Closeout Deliverables
Following the completion of a project deliverable or a process deliverable, we will go through the agreed to definition of done for the deliverable and formally close them. The closeout process will include creating a folder within the Project Management Site and uploading all relevant documentation associated with the deliverable in it