Using the case study below:

• Memo to the Project Sponsor. In the memo, outline the following: a. Recommendations for managing the project - should leverage the scope management plan and scope statement. b. How you would apply project time schedule and cost management tools and techniques to respond to the scenario described in the question in the assigned case study.

Case Study Scenario:

You have just been informed that the Subject Matter Expert has approached the Developer team and asked for additions to the scope of the project. As the Project Manager, you have discussed the scope additions with the Subject Matter Expert and have advised him that additions to scope within the current schedule and budget will have consequences to both schedule and cost. You have advised him that the usual process is to raise the change request, assess the impacts of the required changes and call a Change Control Board meeting out of session, to progress with a decision. The Subject Matter Expert has explained the gap and his reasons for missing the gap until now. You have documented the requirement and the reason for the scope addition in conjunction with the Subject Matter Expert and you will now assess the impact and propose options which will be presented to the Change Control Board who have agreed to meet in three days' time. Both you and the Subject Matter Expert have been asked to present your case and analysis and have been asked to present your case and analyses in writing before the meeting so that the CCB can make an informed decision within the meeting. The attached Change Request (Appendix 5) is the basis of the addition to scope request and will be attached to the memo that you will submit to the CCB. Please choose one and analyse and then write an analysis outcome and recommendations on the basis of the one Change Request you have chosen. You may use the Memo template located under Assessment 3 in MyLearn or create relevant headings and content according to the Assessment 3 Brief. You should consider your recommendations based on the contents of the case study, using the Project activities listed in Appendix 2 and the Resources and costs listed in Appendix 3.

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. SCOPE MANAGEMENT PLAN

Scope Description:

The project includes developing modules for data collection, validation, desktop review, and data approval. These modules will handle data batches, validate records, ensure data accuracy, and facilitate the upload of validated data to the BiiP system. The scope covers the integration of these modules into the existing infrastructure and training for internal staff to manage the new processes.

Project Deliverables:

Playing a key role in this project as these are being created after every step of a project task, which does allow the project manager to keep track of the Project progress and use these to communicate with the stakeholders (Tereso, 2018).

• Data Collection App: A property condition data collection app for use on iPad tablets provided by WeCheck. Which does ensure that the seamless data are being transferred to BIIP.
• Validation Modules: Modules for file pickup, file validation, desktop review, and data approval. These modules agree on collecting data by accuracy, completeness and integrity through systematic validation process.
• Error Logs and Reports: Detailed error logs and reports generated at each stage of the validation process. These logs also provide in transparency through the data validation process and keeps a documentation for communication with stakeholders.
• Training Materials: Training documents and sessions for internal staff on using the new system. Thes materials helps in staff gathering the knowledge transfer, ensuring the understanding in the product knowledge and solving if any issues occur.

Constraints:

Constraints are limitations which are applied to the project which does limits itself in sticking to the allocated and given limit, as these can apply in all different parts of the project such as Scope, cost, schedule and Quality (Steyn, 2001). As these are stages which are needed to be discussed at the early stages of the project such as in the planning stage to avoid further chaos. As this will be a new system which does require workshops and trainings to be given out to work through the system and to do understand how to troubleshoot or reboot the system in case if it's being a bit slow or shuts down. These cost for training, getting in extra server docks and getting in the WECheck to help the staffs upload the assets, these kinds of budgets will be discussed at the initial stage of planning along with the salary packages for the project team for not this cost to interfere with the Actual scope of the project. As given below are the possible constraints which can be looked at in the project

• Scope: Compliance with updated regulatory standards.

Risk involved: Project failure may occur due to Time delay in delivering it or not compiling with policies.

Actions required to Mitigate:

1. Project should be analysed after every step from the initiation.
2. Keeping in not of projects update and recording the updates in a document.
3. Gathering information from previous projects to understand it.
4. Maintaining a project document by having every work being recorded.

• Cost: Limited to a $250,000 budget.

Risk involved: Exceeding the given budget limit which might lead to situation of not reaching the project scope.

Actions required to Mitigate:

1. Getting a detailed budget breakdown and allocating them accordingly to the required teams such as training, WeCheck and salary packages.
2. Monitoring the spendings to keep track of the budget limits.
3. Having the project requirements prioritized to make sure the important needs are being funded.
4. Having a backup reserve funding to make sure if the project goes sideways, we can back them up.

• Schedule: Six-week completion timeframe.

Risk involved: Project exceeding the given time limit an unable to being delivered.

Actions required to Mitigate:

1. Creating a Timeframe plan with having Deadlines and milestones to keep them in track.
2. Having investigated the project regularly by tracking the process every day.
3. Identifying any risk which might affect the project which might cause in the delays.
4. To make sure the project runs smoothly in the given time keeping track of the fundings and resources required are being not affected.

• Quality: Dependent on the accuracy and completeness of data provided by WeCheck.

Risk involved: The project being not completed or not delivering its objectives will affect the system performance and the guest satisfaction as well.

Actions required to Mitigate:

1. Conducting quality check on the project to make sure the quality of the data being delivered is up to the standards.
2. Implementing of Robust procedures in the Quality check will helps us in data accuracy and delivery speed (Kodamana et al, 2018).
3. Having a loop communication and discussing the feedback and quality updates will does help identify the problem.

Assumptions:

Projects do have their assumptions in which does helps motivate the team and the manager to achieve something which can be beyond the desired outcome possible, these can be either a good assumption or a negative one (Fieggen, 2003). As these do have high factors in affecting the scope and making taking it out of the path of project scope. As some of the actions which can cause major risk is that giving an open firewall for the new System BIIP as in the assumption that it will be able to rectify the error folders by itself, as it is a developing software which may or may not contain some errors which will be easy to access and break through them for hackers who will be able to gain access into SGD server through this which will result in a different outcome.

• WeCheck will deliver data in the specified format and within the agreed timeline.

Risk Involved: Failing to deliver the data in the agreed timeline leading to scope losing the timeframe.

Actions required to Mitigate:

1. Having a documental agreement with WeCheck in identifying what are the delivering specifications such as time, formats, penalties if delay and quick resolution if things go sideways.
2. Having constant communications with WeCheck to avoid any delays or preparing for delays.

• Internal staff will be available for testing and validation processes.

Risk Involved: Staffs being not available for the testing phase.

Actions required to mitigate:

1. Conducting meetings and communicating earlier with emails or text letting staff know about these testing process.
2. Providing the necessary training to all the staffs involved in the testing as to develop a backup in case if any induvial is not being available.

• Necessary technology and infrastructure are in place to support the new system.

Risk Involved: Technology and infrastructure not working properly due to insufficient resource leading to system issues and failure.

Actions required to mitigate:

1. Plan, assess and execute necessary changes and upgrade to the system to based on its requirements and its needs.
2. Firewalls being built tighter and regularly updating them to avoid any cyberhacker in system.

Product Acceptance Criteria or Definition of Done (DoD):

As the product reaches a certain stage, it does help us decide if the product has been completed to be handed over and to make sure it has successfully achieved its objectives. AS once the system has undertaken the privacy control test, user friendly test and working according to the SGD policies, this can be given out for the test run to try to upload some files to database to scan through to filter out the still running error files.

• Data Accuracy: 95% accuracy in data validation.

Criteria Approach:

1. Various tests need to be conducted which does include computerised ones and manual approaches too
2. Compare the accuracy percentage with similar project samples and graphs
3. Documentations are required to keep in track of the results of test, discrepancies and changes needed

• Compliance: 100% compliance with regulatory standards.

Criteria Approach:

1. Checklist will be required to be created for the regulatory requirements.
2. Reviewing the systems feature and its specification along with the regulatory checklist
3. Getting confirmations and signatures on documents with the regulatory officers to make sure it complies with all the legal standards

• Timely Delivery: All deliverables completed within six weeks.

Criteria Approach:

1. Keeping in track of the project deadlines and monitoring the project progress
2. Creating a completion checklist which will help in tracking of completed deliverable so we can move on to next step by within the given project time
3. Keeping the records in documentation to identify if there are any delays and their reasons

• User Acceptance: Positive feedback from internal staff during training and testing.

Criteria Approach:

1. Organising an internal survey among the staffs and stakeholders to collect some internal feedback
2. Conduct testing with internal staffs to understand if they can have it user friendly testing.
3. Getting the final approval from the stakeholders with combining all the tests, feedback and ideas and getting the project ready to go live on the system

Project Scope Exclusions:

As Similar to the scope description exclusions are one of the factors which does helps us to identify the boundaries of baseline project, helping us in not including in the out of scope (not included) to the project. These also helps us stay in our objectives and deliver the desired outcome the project is required to at the given time (Larson, R. & Larson, E., 2009). As SGD server already does run along the previous assets and already has the access to files which are being picked-up by WeCheck Data, it does limits the BIIP to look onto its task of validating and checking the files.Some of the examples of project Exclusions are:

• Development of data collection tools by WeCheck.
• Post-implementation support beyond initial training.
• Changes in the infrastructure upgrades which does not include in the projects objective and might cause a scope creep
• Developing a third-party software beyond the scope objective until been approved by stakeholders or sponsorships

Work Breakdown Structure (WBS):

Projects do consist of various tasks to complete & as well as need different hierarchy spread across the team to run a smooth operation. This helps the team to understand that the total scope of work can be carried out by the assigned project team to accomplish the project objectives and create the required deliverables (Burghate, 2018). The Hierarchy has been scattered across from the Director of Property condition program. As they also do consist of their workloads and the salary packages they will be working under, please refer to the Appendix 1.

Scope Change:

Scope changes will follow a formal change control process, requiring approval from the project sponsor. Scope revisions that do not impact the project's critical path or budget will be managed internally.

• Any changes which are being proposed needs to go through the approval of the stakeholders or sponsors to have the Scope changed. As these approvals do have a major impact in the affecting the changes in the Scope base maintenance.
• Some changes happen to be internally which does not affect the project in any critical path of scop or its budget.

Scope Baseline Maintenance:

Scope changes affecting deliverables, schedule, or budget will undergo formal change control. The scope baseline will be maintained through regular reviews and updates based on approved changes.

• Formal Change Control Process involves in any changes which has the chance of affecting in deliverables, Budget or the time of the Scope will be required to have formal change control. Which involves, Identification, evaluation, implementing and Approval (Brena et al, 2023).
• Regular reviews and Updates having them conducted on the scope baseline helps us to identify that it can deliver the right project requirements and suggestions coming up on the review will be required to go through the Formal change control to get approved.
• Communication will also be one of the seals will help the project baseline stay in its scope such as by making sure all the stakeholders and project team members are informed of scope changes and these changes are being documented after there are approvals, changes and impacts.

Appendix 2

Project Activities list, dependencies and durations

1	PCP DATA COLLECTION AND VALIDATION PROJECT		Predecessor
2	A INFRASTRUCTURE
3	A1 confirm infrastructure requirements	5 days
4	A2 confirm infrastructure availability	5 days	3
5	A3 set up logins and passwords	3 days	4
6	A4 test logins and passwords	2 days	5
7	B DATA COLLECTION AND VALIDATION MODULES
8	B1 confirm requirements and process flow	3 days	3SS
9	B2 File pickup module
10	B2.1 create folders for errors and validation records	2 days	8
11	B2.2 develop batch header test code	3 days	10
12	B2.3 develop error log	1 day	11
13	B2.4 create emails	2 days	12
14	B2.5 system test	5 days	13
15	B2.6 release to test	0 days	14
16	B3 File validation module
17	B3.1 create folders for errors and desktop validation	3 days	8
18	B3.2 develop field data format base	3 days	17
19	B3.3 develop code to test data against field data format base	3 days	18
20	B3.4 develop code for data progression to desktop validation folder	4 days	19
21	B3.5 develop code for rejection actions	5 days	20
22	B3.6 create error logs, errors and confirmation emails	3 days	21
23	B3.7 system test	6 days	22
24	B3.8 release to test	0 days	23
25	B4 Desktop validation
26	B4.1 create folders for errors and upload to BiiP records	3 days	8
27	B4.2 develop desktop review module
28	B4.2.1 develop screens for view of data	4 days	8FS+1 day
29	B4.2.2 develop screens for view of attachments	6 days	28SS
30	B4.2.3 develop code to upload data for desktop validation	3 days	29SS
31	B4.5 develop code to upload accepted data to BiiP	4 days	28;29;30
32	B4.6 develop code to send rejected data to error folder	4 days	31SS
33	B4.7 create error logs, errors and confirmation emails	3 days	32
34	B4.8 system test	10 days	31;32;33
35	B4.9 Release to test	0 days	34
36	B5 DATA UPLOAD TO BiiP
37	B5.1 create folders for errors and confirmations	3 days	8
38	B5.2 develop integration code to upload data to BiiP	3 days	37
39	B5.3 develop code to flag failed uploaded data	2 days	38
40	B5.4 develop code to send failed data to error folder	3 days	39
41	B5.5 create error logs, errors and confirmation emails	5 days	40
42	B5.6 system test	10 days	41
43	B5.7 released to test	0 days	42
44	B6 INTEGRATION
45	B6.1 develop integration code for module 1	4 days	14
46	B6.2 develop integration code for module 2	4 days	23
47	B6.3 develop integration code for module 3	4 days	34
48	B6.4 develop integration code for module 4	4 days	42
49	B6.5 system test	8 days	14;23;34;42;45;46;47;48
50	B6.6 released to test	0 days	49
51	B7 Development complete	0 days	15;24;35;43;50
52	C TESTING
53	C1 Test Centre Setup	2 days	8
54	C2 onboard external test contractors	2 days	53
55	C3 develop test scripts	20 days	54
56	C4 develop test data	15 days	55
57	C5 Acceptance Testing
58	C5.1 test File pickup module	10 days	15
59	C5.2 test file validation module	10 days	24
60	C5.3 test desktop validation module	10 days	35
61	C5.4 test data upload module	10 days	43
62	C5.5 test integration	10 days	50
63	C5.6 prepare final test reports	2 days	62
64	C6 User Acceptance Testing
65	C6.1 User training	1 day	62
66	C6.2 User test file pickup module	5 days	65
67	C6.3 User test file validation module	5 days	66
68	C6.4 User test desktop validation module	5 days	67
69	C6.5 User test data upload module	5 days	68
70	C6.6 prepare final user test reports	2 days	69
71	C7 Live data testing
72	C7.1 acceptance test end to end using live datas	3 days	58;59;60;61;62
73	C7.2 user test end to end using live data	3 days	2;66;67;68;69;70
74	C7.3 prepare final test reports	2 days	63;70
75	C7.4 prepare cceptance reports	2 days	74
76	C8 Testing complete	0 days	75
77	D RELEASE TO PRODUCTION
78	D1 Release plan
79	D1.1 final documentation for support team	3 days	51;76
80	D1.2 final documentation for user training	3 days	76
81	D1.3 Change Control Board	1 day	79;80
82	D1.4 Schedule release	2 days	81
83	D1.5 Release to production.	1 day	82
84	Project completed	0 days	83

Appendix 3

Resources and costs

Resource	Responsibilities	Cost	Internal/External
Project Manager	Manage project and deliver outcomes	$150 / hr.	External
Development Manager	Manage and coordinate development activities. Develop schedule of development activities	$1100 / day	Internal
Developer x 3	Development of code according to specified and agreed/approved requirements	$900 / day	External
Test Manager	Manage and coordinate testing activities. Develop schedule of testing activities Prepare final test acceptance and test management report for acceptance before hand over to production.	$1100 / day	Internal
Tester x 5	Develop test scripts according to RTM. Prepare test data. Carry out tests according to test scripts using test data. Carry out tests according to test scripts using live data	$1000 / day	External
Infrastructure Engineer	Identify, confirm, and orchestrate infrastructure requirements, including: SharePoint solution and set up. Access for Client and Vendor teams Access to Property Management Database for client team, testing team and development team (test environment)	$900 / day	Internal
Quality Engineer	Prepare quality metrics according to applicable quality standards. Prepare quality assurance approach. Prepare quality control tools against test outcomes. Manage quality audit. Track and implement quality improvements	$1100/day	Internal

Appendix 5 Change Request

Project Change Request	CR1
Project Name	PCP DATA COLLECTION AND VALIDATION PROJECT	Requestor	Simon Townsend, Subject Matter Expert
Request Name	Add screens to Desktop validation	Date Requested	15th July 2024
Change details	The desktop validation screens do not allow attachments to be downloaded and saved outside the application. Please add an option to view the attachments within the application and to download and save the attachments to User PC.
Reason for change	Often the photo images need to be checked against photos of previous inspections. The current solution requires the application to be open alongside the BiiP application and requires switching between the windows to confirm that the photos are relevant and valid.
Impact if the change is not approved	Inefficient use of the application, User needs to open both applications and needs to switch between windows to view the photos and attachments. Currently data is loaded directly to BiiP and Users can see the photos in one location.
Date required	Agreed project completion Date
Authorised by	PCP Director
Project Manager completion of Analysis of Change Request
Analysis of change	Date		Name of analyst	You name
Schedule impact	Date		Checked with
Cost impact	Date		Checked with
Scope impact	Date		Checked with
Quality impact	Date		Checked with
Notes and comments
Change request outcomes
CCB Meeting # & Date		Members
CR outcome
PM further actions

Project Change Request	CR2
Project Name	PCP DATA COLLECTION AND VALIDATION PROJECT	Requestor	Simon Townsend, Subject Matter Expert
Request Name	Desktop validation records selection	Date Requested
Change details	Current option requires the Desktop validation to be carried out for all records in the batch. Desktop validation is a spot check and Users should select a number of records for validation, with the option to select more if required.
Reason for change	Assumption that the option to select records would be available. Discussion of requirements did not call this requirement out at the time, and we have only discovered that the solution will require desktop validation of all records before the batch can be approved for upload.
Impact if the change is not approved	Additional time and unnecessary work in validation of records prior to approval for upload. Generally, the desktop validation should identify errors in the records via a spot check approach, but it is required to be able to select all records in some cases.
Date required	Original agreed project delivery date
Authorised by	PCP Director
Project Manager completion of Analysis of Change Request
Analysis of change	Date		Name of analyst	You name
Schedule impact	Date		Checked with
Cost impact	Date		Checked with
Scope impact	Date		Checked with
Quality impact	Date		Checked with
Notes and comments
Change request outcomes
CCB Meeting # & Date		Members
CR outcome
PM further actions

Project Change Request	CR3
Project Name	PCP DATA COLLECTION AND VALIDATION PROJECT	Requestor	Simon Townsend, Subject Matter Expert
Request Name	Provide development support to WeCheck	Date Requested
Change details	WeCheck require SGD development assistance to develop batches and files for upload in the correct format
Reason for change	WeCheck have not been able to provide valid data for testing of File pickup module. Internally created data has passed File pickup testing, however WeCheck created data fails all tests.
Impact if the change is not approved	Significant delay in the implementation of WeCheck component of the project, resulting in delays to PCP data validation component of the project, and inability to provide required reports to the Minister.
Date required	Immediate
Authorised by	PCP Director
Project Manager completion of Analysis of Change Request
Analysis of change	Date		Name of analyst	You name
Schedule impact	Date		Checked with
Cost impact	Date		Checked with
Scope impact	Date		Checked with
Quality impact	Date		Checked with
Notes and comments
Change request outcomes
CCB Meeting # & Date		Members
CR outcome
PM further actions

Project Change Request	CR4
Project Name	PCP DATA COLLECTION AND VALIDATION PROJECT	Requestor	Simon Townsend, Subject Matter Expert
Request Name	File validation module addition	Date Requested
Change details	The current file validation module will reject the full batch and return all batch records to the error folder. Only errors should be returned to the error folder and the remainder of the batch should progress to the accepted Desktop validation folder for Desktop validation.
Reason for change	Clarification of approach and agreement with WeCheck to return individual error records but not the full batch from File Validation process.
Impact if the change is not approved	Significant rework on the part of WeCheck in recreating the full batch for the sake of some errors. Delays in completion of validation and upload, resulting in delays to required reporting.
Date required	Agreed project completion date
Authorised by	PCP Director
Project Manager completion of Analysis of Change Request
Analysis of change	Date		Name of analyst	You name
Schedule impact	Date		Checked with
Cost impact	Date		Checked with
Scope impact	Date		Checked with
Quality impact	Date		Checked with
Notes and comments
Change request outcomes
CCB Meeting # & Date		Members
CR outcome
PM further actions

Project Change Request	CR5
Project Name	PCP DATA COLLECTION AND VALIDATION PROJECT	Requestor	Peter Lake, Test Manager
Request Name	Error code details	Date Requested
Change details	Create full details of record errors in error reports
Reason for change	Current error reports display a numeric error code which is difficult to decipher. Error code descriptions describing the cause and impact of the error are required
Impact if the change is not approved	Current error reports are meaningless and do not demonstrate the reason for rejection. Current outcome requires additional clarification of the reasons for the rejection of batches and errors, delaying resolution of the errors.
Date required	Urgently as part of testing
Authorised by	Test Manager
Project Manager completion of Analysis of Change Request
Analysis of change	Date		Name of analyst	You name
Schedule impact	Date		Checked with
Cost impact	Date		Checked with
Scope impact	Date		Checked with
Quality impact	Date		Checked with
Notes and comments
Change request outcomes
CCB Meeting # & Date		Members
CR outcome
PM further actions