Using the case study below, answer the following questions:

1. Quality Management Outline: Outline the anticipated quality requirements and standards with which the project will comply.
2. Quality Standards: List the quality standard to be used for compliance in this project
3. Quality Objectives: Quality objectives are the measures that must be achieved by the project or product components to meet the stakeholders' needs. Objectives define the target that you want to meet by Specification and Measures
4. Quality Roles and Responsibilities: roles necessary to conduct quality activities on the project and the responsibilities associated with each role. You may consider a RAM or RACI matrix here.
5. Deliverables and Processes Subject to Quality Review: The key deliverables that have metrics or measures associated with quality objectives. Also include the processes used in the project that require verification or validation that they are being performed correctly or in accordance with quality requirements or objectives.
6. Quality Metrics: Include the quality metrics that will be applied for each product. Justify why these metrics were selected by Measurement Method
7. Quality Management Approach: Describe the approach that will be used to manage the quality process. Include the timing and content per project and product quality audits.
8. Quality Assurance Approach: Describe the approach to be used to manage and assure the quality of the project and product delivery processes. Remember that quality assurance is proactive and sets the quality process guidelines and approach.
9. Quality Control Approach: Describe the approach to be used to measure the project and project performance to ensure that the product meets the quality objectives. Remember that quality control is reactive and tests the quality of the product against the quality metrics.
10. Applicable Quality Procedures: Describe and include procedures that will be used for the project, such as nonconformance and rework, corrective actions, quality audits, continuous improvement. Ensure that these procedures are relevant to the case study, and cite relevant references.

PROJ6002 Case Study - Property Condition Program

Background

The State Government Department (SGD) uses an ERP called BiiP (Building Integrated Information Program) to store details of all buildings across the State Government building assets. New assets are entered into this system upon acquisition (including new builds) and follow a regular annual maintenance program to ensure that they are maintained to the highest possible standards, following regulatory and legislative requirements, with the aim of reducing rebuilding costs by effective and regular maintenance. Maintenance requirements are flagged in BiiP by regular building condition checks. The Building Condition check is currently carried out by internal staff, using a tablet to gather the data and submit directly to the BiiP system.

The Problem

Due to the increase in the number of building assets, and a reduction in the number of staff who carry out the building condition inspections, SGD have outsourced the BC checks and collection of initial condition data to be uploaded and imported to BiiP system.

Existing internal staff members will inspect a specific category of building assets and will continue to use the current tablet and upload directly to the BiiP system. These staff report to the Director of the Property Condition Program (PCP).

As part of the outsource program, an external supplier (WeCheck) has been sourced via a tender process to deliver the following outcomes.

• Develop a property condition data collection app which will be used on a supplier provided iPad tablet.
• Recruit and train external property condition staff who will inspect SGD property assets and collect property collection data including photos of the condition of the property assets.
• Download the collected data and photos to files which will be transferred to the SGD servers for validation and upload to BiiP.
• Check data validity and convert the data to the SGD required format for upload and transfer to SGD servers.

The Director of PCP has requested that the Systems Development Department of SGD develop a protocol and applications that will collect the transferred data, validate it for accuracy, including the ability to view the photos and confirm that these match the data files, and submit the approved file for upload to the BiiP system. You have been appointed as the Project Manager and have been advised that this was initially considered to be an easy solution and did not require a Project Manager. However, since there has been no traction on the application from the SGD end and no confirmation that WeCheck have developed a tool that will convert and upload valid data, the decision has been made to appoint a Project Manager, including a team of developer and testing staff to complete the project from the SGD end and complete testing of data that has been supplied by WeCheck. You have also been told that you will complete the project within 6 weeks, as the Minister is asking for evidence of the costs of maintenance in 2 month's time.

The Developer Team Lead has discussed the requirements with the client team and mapped out the application from the SGD perspective, providing you with the flow of activities and modules. See Appendix 1

Scope

Initial scope is to develop several modules to collect data which has been captured by the external entity and uploaded to shared cloud-based location (SharePoint) using XML format and batches of data. Folders will need to be developedfor data files, image files, data errors, error reports)

Each batch contains a header record containing the batch id, the total number of records. Each recording within the batch contains the batch id concatenated with the record id, along with output of a data collection tool exported in xml format.

Scope includes the following modules.

File pickup- Module should check the batch and test the batch header to ensure that the same batch id is used within the whole batch and that the batch contains the correct number of records. An error log is generated for all error batches and the file is flagged as rejected. A confirmation email is generated and sent to PCP team as confirmation of successful batches. Move all error batches to an error folder. Move all successful batches to File validation folder.

• error folder for failed batch headers.
• folder for File validation records.
• error log.
• confirmation email.

File validation - open the file validation folder and the records contained in the folder. Develop a module which will test the records in each batch to match the field data formats for compliance.

Reject the full batch if data format errors are found.

Generate an error report containing record id and data format error details.

Move the rejected batch to the error folder.

Move the accepted files to the Desktop validation folder.

• error folder for validation error records.
• Desktop validation folder for records which are correct, ensure that the image files are associated with the passed records.
• errors in the error log.
• confirmation email.

Desktop validation - Develop a desktop review module which lists all records ready for desktop review. The screen should be in similar format to BiiP view of Property condition. Allow records to be opened individually and allow open and download of associated photos.

Provide an accept or reject option, with comments for rejection.

Generate error report and upload error batches to error folder.

• desktop review module.
• error folder for desktop validation errors records and attach image files and error comments.
• General errors in the error log and include comments.
• accepted log for validation against records uploaded to BiiP

Data approval- User selects the Approve option and schedules the file for upload to BiiP.

Files are uploaded overnight. Confirmation report is generated on successful upload of records to BiiP. Confirmation report is emailed to PCP team. Error log is generated and emailed to PCP team for failed uploads. Failed records are returned to Error folder for further review. These records should be available in Desktop Review module as Failed Upload records with error message attached.

• folder for failed uploads.
• email for successful uploads.
• email for failed uploads.

Reporting - Successful transfer generates a confirmation message in Desktop Review Application, failed transfer generates a failure message in Desktop Review Application and develops an error log.

• successful upload message in Desktop Review Application log
• failed upload message in Desktop Review Application log
• Further reports to be specified and generated post implementation.

Quality

Quality of data captured by external entity, ensuring that it matches the key attributes of the new database into which the data will be uploaded.

Quality of data transfer protocol, ensuring that batches of data uploaded and collected match the header record identifying the records to be collected.

Process quality - ensuring that data collected is valid, data capture is efficient and results in zero batches rejected, quality of data and associated artefacts, e.g. photos, correct data formats, data has been completed correctly, data is valid (set auto and manual checks)

Quality control requirements

Test team will develop a Requirements Traceability Matrix (RTM) to track the requirements and the test scripts.

Test team will develop Test Scripts for all modules.

Test team will develop test data for testing data validation in preparation for final test using live data. Final test prior to go live requires all records to be correctly captured, validated for file correctness, validated for data correctness, viewable within the desktop view, including attachments, allowing acceptance or rejection, and accepted records need to successfully be uploaded to the BiiP application. Error reports are to be generated, emailed to a test email address and reports to be loaded to the relevant SharePoint folders. Acceptance is based on a defined number of correct records processed end-to-end and confirmed by the PCP team.

Final testing must include live data collected from WeCheck to ensure that the data is collected and transferred by WeCheck passes all validation tests. SGD and the project are not responsible for creation or development of the WeCheck data collection tools, but will provide WeCheck with the data validation rules and the xml layout that must be used for data collection and transfer.

Schedule

The schedule is based on the Work Breakdown Structure developed from the list of activities and needs to ensure that the project is developed and tested ready for hand-over within the required six-week timeframe.

Cost

The allocated budget for this project is $250,000 including development and testing of the modules as identified by the SGD Development Team lead.

Please see Appendix 3 for resources, costs and responsibilities. Internal resources are excluded from the Project Costs and Budget as they are employees and charged to the SGD cost centre. External employees are included in costs for the project and are costed at daily rate plus 15%. External employees are invoiced weekly.

Costs should include external resources and contingencies.