The Property Government Department (PGD) is responsible for the construction and maintenance of all properties utilized to provide services to the Community. The PGD manages and maintains buildings and assets for the Department of Housing, and Health, and is responsible to the specific Department Ministers for maintenance, budget and reporting of status of the buildings. The PGD uses the BiiP (Building Integrated Information Program) application to store all details of all buildings across these Government Departments building assets. New assets are entered into this system upon acquisition and follow a regular annual maintenance program to ensure that they are maintained to the highest possible standard, following legislative and regulatory requirements. The main aim of the application and maintenance program is to reduce rebuilding costs by effective and regular maintenance. A component of this maintenance program is regular checks of property condition. The Property Condition check has been carried out, up until recently, by internal PGD maintenance staff, who have used a tablet to gather the data and submit it directly to the BiiP application. The Initial Problem Over several years, maintenance staff numbers have been reduced, and the PGD has been unable to employ replacement staff with the required skills, to carry out Property Condition assessments. It has come to light that rather than carrying out assessments and associated preventative maintenance annually, the PGD is now 5 years behind in Property Condition assessments. This has resulted in increased maintenance costs due to the lack of preventative maintenance, and the maintenance requests list is also growing significantly. Risks of fire, due to unmaintained and out of date smoke detectors, and smoke detectors whose batteries have been removed, have increased. Several assets, which were built more recently, have been found to contain cladding, which is not fire resistant, and therefore no longer complies with the updated Building Code. The need to identify and upgrade these assets has added to the list of works which have not yet been assigned, and the Ministers are concerned that this is the “tip of the iceberg”. Ministers have been asked by Parliament to provide a status report, identifying the cost of upgrades to existing assets in each department, and a second report which will provide a Cost Benefit Analysis, determining which assets should be maintained and upgraded, and which should be sold or decommissioned to recoup costs. A decision has been taken by the relevant Ministers to outsource the Property Condition assessment function and an organisation has been selected on the basis of a successful tender process. The selected organisation is Proactive Property Maintenance (PPM). PPM has branches in each State of Australia, and have successful contracts with several State Government authorities, in the condition assessment and maintenance of assets, specifically buildings. Their employees use iPad tablets which are newer technology. These iPad tablets contain an application via which the property condition contract staff gather all of the required condition data and via which they store photos of specific areas and issues which have been identified. The employees are able to connect to a Wi-Fi connection, to transfer this data to the PPM server for further consideration. Once the data is transferred to PPM, it is manipulated and further transferred to the client department for upload to their internal applications for reporting and scheduling of further maintenance. The contract has been signed for three years, with the option of two further extensions of three years each. The contract will only allow for the assessment of property condition and the transfer of data, including photos to PGD in a format which can be used for input to BiiP. Creation of the Data Collection and Data Transfer Project (DCTP) Based on the requirements identified by Parliament, and the concern for quality of data to be entered and maintained in the BiiP Asset Management System, a new project (PCAR or Property Condition Assessment Reporting) has been established, to identify and implement all steps which are required to be taken, to provide the final reports to Parliament. Knowing the depth of the delay in Property Condition assessments, the Project Team have been provided a budget of $6M to carry out all the activities to bring the assessment data up to date, and to develop a series of data transfer and validation applications which will migrate the collected data to the BiiP Asset Management System. Reports for Department Secretaries and Ministers of Parliament will be generated using Power-BI from the data cube available from BiiP Asset Management Property Condition Modules The Project Steering Committee (PSC) and Subject Matter Experts (SMEs) from within the two Departments, met to identify their specific requirements regarding the collection and transfer of data. Several iterations of the requirements were developed, and, in each case, the Project Manager and the Project Team found great difficulty in achieving agreed signoff of the requirements. Each Departmental SME had a different vision of the final report, especially the data it should contain. The PSC members, who also included the SMEs, had their own vision of the flow of processes and timelines required to ensure that the collected condition data was of relevant quality and would not damage the integrity of data in the BiiP Asset Management system. The Project

https://peachytutors.com/challenges-in-project-management-navigating-stakeholders-needs-for-success/ had to remind the Project Steering Committee of the need for data integrity and that maintenance activities were based on the existing data which needed to be confirmed when new property condition data was uploaded. Project Steering Committee members included SMEs from the Departments, and they readily accepted any increase of scope stating that there was “plenty of budget”. The Project Manager constantly needed to remind the Steering Committee members of the overall budget constraints for the data transfer applications project, and the projected costs of report development. The budget allocation for the total project was $6M, which included the data collection contract with PPM and the development of the reports after the data had been collected and transferred to BiiP. The IT data transfer application project (DCTP) was afforded $200K and was to be completed within 6 weeks. While the DCTP budget was $200K, the PSC was very ready to allocate further budget from the PCAT budget, where DCPT scope increase was concerned. After some time, the requirements for the data transfer application (Data Collection and Data Transfer Project – DCTP) were agreed and signed by all parties. The Project Manager circulated the agreed and signed requirements to the Development and Testing Team as well as to the PSC and the SMEs. The Development and Testing teams estimated the effort and duration of development and testing. Based on these detailed requirements, estimates were accurately completed, and a schedule was created. The schedule determined that the work would not be completed within the required six weeks, without additional development and testing resources. As a result, three additional testing resources and two additional development resources were added to the Project Delivery Team. These contract resources added to the cost of the DCTP project. The Development Team began the development of four modules of DCTP, while the Testing Team began the documentation of Test Scripts based on the Requirements Traceability Matrix which had been developed by the Project Manager and which was based on the agreed and signed Requirements. The Validation Module validated the batch id and number of records for each batch of data transferred from PPM to a secure ftp server. The Download Module downloaded the data from the secure ftp server and transferred it to a holding application. The holding application checked all data for validity of codes and data, so that the correct codes were entered, and so that the data that was transferred matched the expected data for each field. This application produced a list of batches with outcomes, which allowed the Department Staff to spot check the data and then approve it for transfer to the Final Staging module. The Final Staging Module allowed staff to open a full record and to check the photos that were transferred with the records. At the completion of these validation checks, the staff member would approve the valid records and release for upload to the BiiP Asset Management Property Condition module. The Upload Module created the new record in BiiP and created a history record, containing the previous data, and an audit of the creation of the new record. Photos were uploaded and attached to the Asset record under the Property Condition Module, and the Asset was classified according to its current status. The Testing Team continued to create the test scenarios and test scripts relying on the agreed Requirements document and the Requirements Traceability Matrix. Since there was no data from PPM at this stage, the Testing team also created test data based on current data in the BiiP Asset Management System and the previous Property Condition system used within the Departments. They stored their test scenarios and scripts in the Mercury Test Director application. The schedule for development, testing and delivery was very tight, and only allowed the allocated six weeks for development, testing and implementation. The Project Manager checked the work performance daily, using EVA to ensure that the visual checks on performance were validated. PSC Steering Committee Meetings were held weekly. The modules were developed concurrently, in order to shorten the development time, with the intention of writing the transfer code that would link each module, once each module had been individually tested and passed. The specifications of the batch including codes, xml layout and validation rules, were provided to the vendor (PPM) to ensure that the data they collected and the format in which it was uploaded to the transfer protocol, was compliant and would pass validation tests in the newly developed module of the DCTP. Specifications of the batch load header and process were also agreed and supplied to PPM who would carry out the property condition inspections and upload the data and photos. See Appendix 2 for the collection, transfer, and load process using the combined applications. Problems within the Data Collection and Data Transfer Project (DCTP) Testing began as soon as the first completed module was available. The first tests failed with many test cases not achieving the required results. The data that was tested should have passed the validation tests, however, this was not the case. This outcome caused consternation amongst the project team. During the team meeting including the Project Management team, the Testing Team and the Development Team, it became obvious that the test cases were not aligned to the module that was developed. The Project Manager checked the signed and agreed Requirements Document and the Requirements Traceability Matrix and found that the Test Scripts and Testing Requirements fully matched these. The Development Team however spoke up and advised the entire team that the module that was developed did not align to the signed Requirements Document. Therefore, the test scripts were not testing what had been developed, but what had been initially agreed. Further investigation identified scope changes that had been requested directly by one SME. It was discovered that this SME was on good terms with the Development Team members, and regularly came into their area, carrying a box of Krispy Kreme donuts. He would sit down and discuss the development process, how they were tracking, and when the Developer showed him the current application, would ask for changes to what had been developed. Due to the short and constrained timelines and budget, the Department had chosen a Predictive Delivery approach and had included, within the Project Management Plan, a rigorous Change Control Process. Thus, all requested changes to the project scope, schedule or cost had to be logged with the Project Manager and approved by the Change Control Board. Members of the Change Control Board were also members of the Project Steering Committee. In this case, the additions and changes to requirements had bypassed the Change Control Process, as neither the SME or the Developer had logged the changes or notified anyone in the Project Team. The initial solution was to require rework via redevelopment of the IT code to comply with the signed Requirements. However further discussions and investigations, using the Change Control process, resulting in testing rework via which the test scripts and scenarios were redeveloped to comply with the new requirements. The Requirements document was also updated and signed again. The vendor, PPM, developed test data for transfer to the first module of the Data Transfer module. These data transfer tests failed, initially due to incorrect validation of the batch header. Once the headers were corrected, the data failed due to data validation tests in the first module. At this point, the project was three weeks into the six-week plan, and the Project Management Team needed to consider solutions which would allow satisfactory completion of each module, management of continued scope creep, and a different approach to the test cycle. The outcomes required different processes, which resulted in changes in which the Project Team, and the Stakeholders would need to work differently. The PPM IT development staff required a better understanding of the requirements of the transfer protocol and more effective validation of data prior to generating the batches of data for upload. The Department Staff required changes in the process of validation of the data that was transferred. As a starting point, the Project Team assigned one Departmental Development Team member to the PPM IT development team to solve their technical and data transfer issues. However, the Project Management Team and the Steering Committee were still at odds regarding scope management, change control processes and how to maintain the budget. The Project Manager had three weeks in which to complete the development, testing and delivery of this project and needed to reassess the Project Management approach. Identify all the issues that will impact the success of the project delivery and propose changes that will resolve these issues. (Remember that changes considered should include those changes within the project (Integrated Change Control) and changes impacting stakeholders, as well as stakeholder readiness to accept the changes noted.) Critically evaluate the impacts of your recommended changes on the project processes and development approach/lifecycle. Select three (3) changes PREVIOUSLY IDENTIFIED IN THE CASE STUDY and propose a change management approach to ensure the delivery of value by the project. Discuss how you would ensure that the changes are accepted by the stakeholders, as well as how you may need to tailor any processes or development approach/lifecycle.