One of the facts of capital construction projects is that different software applications will be always used to manage the everyday project information. Whether those software applications were specified by the contract or preferred by the project owner, each software has its own specific purpose to fulfill. Although, there might be an information overlap when it comes to capturing data, nevertheless what is more important is what can be done to give project stakeholders the ultimate 360-degrees, real-time, single version of the truth reporting they always seek to have.
The costly and time-consuming option of data integration is not the right answer. Not only are the data sources for those applications usually not at the same location, but the data captured in those applications many times is not allowed to be transferred to other applications. Therefore, the right answer should be how can we get the needed reports by just extracting, associating, and blending the data from those different data sources.
Of course, when it comes to using multiple applications on a project, there are few minima but yet very much logical requirements that need to be enforced. Those are the requirements to have a standard format for data fields that are common to all those applications. For example, those could include the project name, entity’s name, cost breakdown structure (CBS) levels, work breakdown structure (WBS) levels, business processes name, status name, date format among others. All of those data fields are usually defined in the project management plan (PMP) or project execution plan (PEP) as it is a must to have a single communication language on the project.
For projects that have selected PMWeb as their Project Management Information System (PMIS), the data for the different business processes managed in the PMWeb MS SQL database can be accessed with the right credentials and access permission rights. This will be done by creating a link to the database to enable data query, extraction, and loading into the desired reporting tool, for example, MS Power BI. As for Aconex, data extraction will be done by using Aconex – SQL Transfer Tool developed by PP Consult. This tool will continuously transfer Aconex document, mail, and workflow metadata to a database where Aconex database tables will be created. Similar to PMWeb, this data will be consumed by MS Power BI to create the needed reports.
Project dashboards must incorporate the different project reporting requirements. For example, there might be a need to limit the data association to the project level where PMWeb and Aconex data will be consumed and presented. In this case, the displayed visuals for each data source are not associated with the data of the other data source.
Of course, there is also the extreme report separation for which although PMWeb and Aconex will be on the same MS Power BI application, nevertheless, there will be separate report pages for PMWeb data and Aconex Data. In this case, the report reader needs to select those different pages to view the desired information.
Another option would be to have the in-depth data analysis for which the data association will be done at the transactions level for both PMWeb and Aconex. In other words, in addition to the standardized project, business process, and other data fields, there should be a data association at the transaction level, that is the transaction record number. For example, the RFI reference number “COM-RFI-00000” will be captured in PMWeb in the “REF #” field, whereas in Aconex, it will be the “Mail Number”. Of course, other data fields to associate the PMWeb and Aconex data can be also considered for further data modeling and analysis.
The association and blending of the Request for Information (RFI) data captured in PMWeb and Aconex provide the report reader with an improved insight that was never available or possible before. For example, in addition to RFI mail details captured in Aconex, the report will also display the reason for the RFI, question and answer fields captured in PMWeb as well as the other fields for whether this RFI had a scope, time, and/or cost impact and the project schedule activity associated with this RFI. There are no restrictions on what data to display as long as the data has been captured. For example, an additional field could have been added to provide details of the change order record generated in PMWeb as a result of this RFI.
Another important feature of this report is that the report reader has the option to drill down to both the Request for Information (RFI) mail-in Aconex as well as the Request for Information (RFI) transaction in PMWeb. This will also enable the reader to view more details as well as documents attached to those transactions.
