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 created 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 created for 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 development of 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.

• Create an error folder for failed batch headers.

• Create a folder for File validation records.
• Create an error log.
• Create a confirmation email.

File validation – open the file validation folder and the records contained in the folder. Create 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.

• Create an error folder for validation error records.

• Create a Desktop validation folder for records which are correct, ensure that the image
files are associated with the passed records.
• Generate errors in the error log.
• Create a 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.

 • Develop a desktop review module.
• Create an error folder for desktop validation errors records and attach image files and
error comments.
• General errors in the error log and include comments.
• Create an 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.

• Create error folder for failed uploads.

• Create email for successful uploads.
• Create 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
creates an error log.

• Create successful upload message in Desktop Review Application log

• Create 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.

Appendix 1
Process flow and associated modules.

WeCheck
WeCheck create files transfer file to
WeCheck validate and
(txt and image for SGD servers
convert data
transfer for pickup and
test

WeCheck
data
WeCheck header
data and files 1
header
and files 2

WeCheck
data
header
and files 3

SGD PCP SharePoint Server

 • Files picked up and confirmed
• Error report generated
File pickup • Confirmation report generated

• data is validated against file and BiiP rules

• Error report is generated
File
validation • PCP notification of success

• data is opened and viewed including images for validation against logical rules
Desktop
validation

• Data is approved
Data • File is submitted for load to BiiP
approval

• Success report emailed to PCP

Reporting
• error report emailed to PCP
Appendix 2
Project Activities list, dependencies and durations
PCP DATA COLLECTION AND VALIDATION PROJECT Predecessor
A INFRASTRUCTURE
A1 confirm infrastructure requirements 5 days
A2 confirm infrastructure availability 5 days 3
A3 set up logins and passwords 3 days 4
A4 test logins and passwords 2 days 5
B DATA COLLECTION AND VALIDATION MODULES
B1 confirm requirements and process flow 3 days 3SS
B2 File pickup module
B2.1 create folders for errors and validation records 2 days 8
B2.2 develop batch header test code 3 days 10
B2.3 develop error log 1 day 11
B2.4 create emails 2 days 12
B2.5 system test 5 days 13
B2.6 release to test 0 days 14
B3 File validation module
B3.1 create folders for errors and desktop validation 3 days 8
B3.2 develop field data format base 3 days 17
B3.3 develop code to test data against field data format base 3 days 18
B3.4 develop code for data progression to desktop validation
folder 4 days 19
B3.5 develop code for rejection actions 5 days 20
B3.6 create error logs, errors and confirmation emails 3 days 21
B3.7 system test 6 days 22
B3.8 release to test 0 days 23
B4 Desktop validation
B4.1 create folders for errors and upload to BiiP records 3 days 8
B4.2 develop desktop review module
B4.2.1 develop screens for view of data 4 days 8FS+1 day
B4.2.2 develop screens for view of attachments 6 days 28SS
B4.2.3 develop code to upload data for desktop validation 3 days 29SS
B4.5 develop code to upload accepted data to BiiP 4 days 28;29;30
B4.6 develop code to send rejected data to error folder 4 days 31SS
B4.7 create error logs, errors and confirmation emails 3 days 32
B4.8 system test 10 days 31;32;33
B4.9 Release to test 0 days 34
B5 DATA UPLOAD TO BiiP
B5.1 create folders for errors and confirmations 3 days 8
B5.2 develop integration code to upload data to BiiP 3 days 37
B5.3 develop code to flag failed uploaded data 2 days 38
B5.4 develop code to send failed data to error folder 3 days 39
B5.5 create error logs, errors and confirmation emails 5 days 40
B5.6 system test 10 days 41
 B5.7 released to test 0 days 42
B6 INTEGRATION
B6.1 develop integration code for module 1 4 days 14
B6.2 develop integration code for module 2 4 days 23
B6.3 develop integration code for module 3 4 days 34
B6.4 develop integration code for module 4 4 days 42
B6.5 system test 8 days 14;23;34;42;45;46;47;48
B6.6 released to test 0 days 49
B7 Development complete 0 days 15;24;35;43;50
C TESTING
C1 Test Centre Setup 2 days 8
C2 onboard external test contractors 2 days 53
C3 develop test scripts 20 days 54
C4 develop test data 15 days 55
C5 Acceptance Testing
C5.1 test File pickup module 10 days 15
C5.2 test file validation module 10 days 24
C5.3 test desktop validation module 10 days 35
C5.4 test data upload module 10 days 43
C5.5 test integration 10 days 50
C5.6 prepare final test reports 2 days 62
C6 User Acceptance Testing
C6.1 User training 1 day 62
C6.2 User test file pickup module 5 days 65
C6.3 User test file validation module 5 days 66
C6.4 User test desktop validation module 5 days 67
C6.5 User test data upload module 5 days 68
C6.6 prepare final user test reports 2 days 69
C7 Live data testing
C7.1 acceptance test end to end using live datas 3 days 58;59;60;61;62
C7.2 user test end to end using live data 3 days 2;66;67;68;69;70
C7.3 prepare final test reports 2 days 63;70
C7.4 prepare acceptance reports 2 days 74
C8 Testing complete 0 days 75
D RELEASE TO PRODUCTION
D1 Release plan
D1.1 final documentation for support team 3 days 51;76
D1.2 final documentation for user training 3 days 76
D1.3 Change Control Board 1 day 79;80
D1.4 Schedule release 2 days 81
D1.5 Release to production. 1 day 82
Project completed 0 days 83
Appendix 3
Resources and costs
Resource Responsibilities Cost Internal/External
Project Manager Manage project and deliver $150 / hr. External
outcomes
Development Manager Manage and coordinate $1100 / day Internal
development activities.
Develop schedule of
development activities
Developer x 3 Development of code according $900 / day External
to specified and
agreed/approved requirements
Test Manager Manage and coordinate testing $1100 / day Internal
activities.
Develop schedule of testing
activities
Prepare final test acceptance
and test management report for
acceptance before hand over to
production.
Tester x 5 Develop test scripts according $1000 / day External
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
Infrastructure Engineer Identify, confirm, and $900 / day Internal
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)
Quality Engineer Prepare quality metrics $1100/day Internal
according to applicable quality
standards.
Prepare quality assurance
approach.
Prepare quality control tools
against test outcomes.
Manage quality audit.
Track and implement quality
improvements
Appendix 4
SGD Reporting and Performance Measurement Standards
Level of accuracy

Project costs are reported in dollars to the nearest dollar.

Durations are tracked and reported in days to the nearest day.

Work is reported and estimated in hours based on 8-hour day and the daily rate for each
external resource.

Threshold – Schedule and Cost.

This is a short project with a high impact and high importance.

The threshold for schedule delay is limited to 5 days. Tasks will need to be tracked at task level
and reported at task level. Where the task is delayed by less than 5 days, it remains within the
scope of the Project Manager to resolve the delay. Where the task or the overall project is
delayed by 5 or more days, it will be escalated to the Project Steering Committee for further
action.

Cost threshold is 10%. Where the actual running cost is up to 10% over the approved baseline
budget, the Project Management is responsible for resolution and bringing the Cost back to
baseline. Where the current cost is 10% over the approved baseline budget, the issue will
escalate to the Project Steering Committee and Senior Management for decision.

Reporting cycle

Due to the duration of the project, the Steering Committee will meet weekly and will invite the
Project Manager. The Project Manager will provide a status report demonstrating the status of
the project deliverables and track costs against the approved baseline.
Assessment 1
Please review the Assessment Brief and the details of the case study above.

Step 1.
Critically analyse the Assessment 1 question outlined in the Case Study and conduct research
related to the topics outlined in the question. Submit a 500-word discussion post answering the
following question, analysing the question and the key issues

How may scope creep affect the quality of project deliverables and how
should a project manager communicate and validate these variances to
project stakeholders?
Please illustrate with hypothetical examples from the case study to support your discussion.
Your discussion should include an example of how this may happen and its impact on the
assigned case study. Cite all sources used to inform your post, including learning resources and
academic and/or industry literature. The reference list is not included in your word count.

Please ensure that you have explained the background of the tools and techniques you have
discussed and use relevant academic citations to support your explanations.

Please use the Reply button to post your initial discussion post (500 words) by the end of week
3

Step 2.
You should then read the posts of other students and select at least one post. consider their
post and compare it with the research you have conducted. This approach will allow you to
"critique" their view. You can do this by highlighting your agreement and/or disagreement with
their post. You must justify and explain your critique. You will cite industry and academic
literature. Your response must be 250 words not including the reference list. Please include the
name of the student to whose post you are replying.

Respond to that student by clicking the Reply. This response must be submitted by the end of
week 4.