Deliverable Acceptance Criteria. Contractor, in collaboration with the County development team, shall provide Sprint Status Reports and complete Release Notes, and demonstrate a functional Tally System able to perform all functions described in Task 5, which shall be reviewed and approved by the VSAP Program Manager.
Deliverable Acceptance Criteria. The Deliverable Expectation Document (DED) will be used for Critical Deliverables and for other deliverables at DIR’s discretion to document mutually agreed-upon deliverable descriptions and applicable standards, and to more clearly define acceptance criteria. The Service Provider and DIR will develop and mutually agree upon the DED. Deliverable acceptance will be contingent upon material compliance with the DED and any rejection of a deliverable must be accompanied by a description of the material non-compliance with the DED. Any changes to the DED will be approved through mutual agreement between DIR and the Service Provider. DIR, in its sole discretion, may choose to forgo the creation of the DED. DEDs will not contradict nor alter the contract acceptance criteria requirements set forth in the Agreement. In the absence of a DED, the acceptance criteria for a Milestone/Deliverable would be material compliance with the requirements as set forth in the Agreement. The following requirements will be documented in the DEDs:
Deliverable Acceptance Criteria. Agile Software development: Provide professional SCRUM Master to bring leadership to the other members of the wider team. The SCRUM Master’s roles will include, but not be limited to: Assisting with the decomposition of potential projects into work packages so that business benefits can be delivered at speed Quality assurance and guidance on producing effective user stories Effective management of project backlogs Running daily stand-up meetings Organising and running Retrospectives at the end of each sprint Producing planning and other documentation in line with agile methodology for each sprint Provide a development team who are capable of delivering production-level code iteratively. Whilst the team members may typically be only 3, 5-9 in number they will have cross-functional skills and be responsible within each sprint for producing the actual work (aspects of analyse, design, develop, test, communication to architecture teams etc.) Each engagement will be centred on a two-week sprint using SCRUM, Kanban or other methodologies such as scrum-ban depending on the underlying product under development. Where a new product or epic is to be started a development spike/tracer bullet will be delivered as one of the sprints in order to assure that the current architecture, methodology, technology and development frameworks are suitable and will provide quick feedback to the product owner that the approach is sound. Product owners will be sourced directly from the HMCTS business community and will be expected to provide business leadership within the team. Technical Product Owners will be provided from the incumbent technical teams. Output approved by the Business Product Owner and Technical Product Owner Knowledge Transfer: In the event of a change in supplier mid-project or the introduction of new parties to the project (business or delivery side) this should be estimated to provide an appropriate amount of documentation, briefing and knowledge transfer activities on work undertaken Approval of approach and outputs by Project Manager and relevant Technical Lead
Deliverable Acceptance Criteria. Contractor shall carry out the activities and produce the documentation described in this task, which shall be reviewed and approved by the VSAP Program Manager.
Deliverable Acceptance Criteria. All concluded work shall be submitted for review and acceptance or rejection to the HCD Project Manager through the use of the Deliverable Acceptance Document (DAD). The Contractor shall provide an approved DAD, which will be signed by the HCD Project Manager upon completion of a deliverable as listed in Exhibit Q D Deliverables Table. Signed acceptance is required from the HCD Project Manager and Contract Manager before submitting an invoice for payment. Refer to Section 11.0 Contractor Roles and Responsibilities, for identification of the individual required to sign for acceptance of deliverables under this Agreement. Deliverables rejected by the Contract Manager will be governed by the Corrective Action Plan.
Deliverable Acceptance Criteria. [Insert detailed description of deliverable acceptance criteria under the Agreement.] Commented [MN5]: When subcontracting on a fixed price basis, Palladium is paying for the final outcome being successfully completed. Palladium is not paying for interim reports or other items (such as work plans) – the final output is what we need delivered, not the various steps required to get there. However, we may deem it appropriate to allow for progress payments, particularly for subcontracts with an extended period of performance. This language provides basis for progress payments towards the final outcome. This may be applied to all or a subset of the overall deliverables.
Deliverable Acceptance Criteria. Contractor shall develop a Project Control Plan document as described in Task 0, which shall be reviewed and approved by the VSAP Program Manager.
Deliverable Acceptance Criteria. Contractor, in collaboration with the County development team, shall provide Sprint Status Reports and complete Release Notes, and demonstrate a functional VBL Application able to perform all functionality described in Task 14, as prioritized by the County designated Product Owner, which shall be reviewed and approved by the VSAP Program Manager. Task 14 – VBL 2.0 Build Xxxx 00 will focus on the continuing collaborative development of the VBL Application. During the period, and utilizing the resources specified in the Project Schedule, Contractor will initiate implementation of the Project utilizing the then-current Product Backlog. Prior to each sprint (typically a two-week implementation cycle), County will prioritize the user stories and activities from the then- current Product Backlog. Using the prioritized Product Backlog, Contractor will assign story points to a set of user stories and activities to be implemented during the upcoming sprint. For this reason, it is possible not all specified user stories will be implemented. Task 14 consists of development activities to produce continuing enhancements to existing features, as well as new epic features listed below: ● Box Card Generation – This epic involves the generation of box cards through VBL. ● Support for Full Face Ballot Vote at Poll – This epic involves adding a full-face ballot type to ballots generated by VBL, so that there is the option to provide the full-face ballot during election day.
Deliverable Acceptance Criteria. Contractor, in collaboration with the County development team, shall provide Knowledge Transfer Status Reports, which shall be reviewed and approved by the VSAP Program Manager.
Deliverable Acceptance Criteria. All concluded work must be submitted to Covered California for review and approval or rejection. Payment for all tasks performed under this Agreement will be based on hourly rates. It will be Covered California’s sole determination as to whether any tasks have been successfully completed and are acceptable. Throughout the contract, Covered California will review and validate services performed. In addition, the Covered California Representative will verify and approve the Contractor’s invoices. Signed acceptance is required from the Covered California Representative to approve an invoice for payment. Deliverable acceptance criteria consist of the following: Deliverable-specific work was completed as specified and the final deliverable product or service was rendered. Plans, schedules, designs, documentation, digital files, photographs and reports (deliverables) were completed as specified and approved. All deliverable documentation and artifact gathering have been completed. All deliverables are in a format useful to Covered California. If a deliverable is not accepted, Covered California will provide the reason, in writing, within ten (10) business days of receipt of the deliverable. Project Representatives Covered California Representative: Contractor Representative: (Representative’s Name) Covered California 0000 Xxxxxxxxxx Xxxx. Xxxxxxxxxx, XX 00000 (916) XXX-XXXX T (Email Address) (Representative’s Name) (Contractor’s Name) (Address) (City, State and Zip) (916) XXX-XXXX T (Email Address) The representatives for this project, during the term of this Agreement, shall be:
