Abstract
A key area of project communication management is project performance reporting.
Performance reports need to provide information at an appropriate level for each audience. When projects involve several internal and external stakeholders, it is often necessary to prepare and distribute a lot of different reports containing subsets of similar data and information. Moreover, different audiences might require different reporting formats (slides, forms, documents, tables, graphs). Each report needs to be periodically updated (e.g., on a monthly basis) as the project progresses; this manual process is time consuming and error prone.
The paper will propose a smart approach to project performance reporting that can minimize the efforts of preparing and distributing consistent and reliable reports leveraging on a modularization concept through the following ideas:
- a careful initial organization of the reports into units (sections, chapters, slides) that can be incorporated within several reports across different stakeholders;
- a careful initial organization of the content of each report with “live” links to performance data (e.g., CPI, SPI, and milestone dates) from the project planning tools; and
- creation of the performance reports through the composition/aggregation of the most appropriate sections/chapters/slides for each audience.
This approach is easily achievable with the current document and presentation editing tools on the market and can be implemented within any organization.
Introduction
The concept of project performance reporting was introduced in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition within the Project Communication Management Knowledge Area (PMI, 2008, p. 244). It is defined as the process of collecting and distributing performance information, including status reports, progress measurements, and forecasts (PMI, 2008, p. 266). Moreover, the concept of “reporting system” is defined as a tool to consolidate reports from several systems and distribute information to project stakeholders in the forms of tables, spreadsheets, and presentations.
The project performance reporting process has particular importance in an oil and gas organization such as Eni that handles more than two hundred projects, whose investments range from US$10 million dollars to more than US$1 billion dollars for each project. Oil and gas projects are comprised of the evaluation of complex technical data to assess the potential productivity of the field; the drilling of the wells; and the design, construction, and commissioning of the onshore/offshore facilities and pipelines to produce and export the hydrocarbons. Projects are usually split into phases, which are managed with a stage and gate model. Finally, projects are typically carried out within partnership agreements with other oil and gas operators.
Project Reporting Challenges
Large projects involve large numbers of stakeholders with different information needs:
internal stakeholders, including the project team, project manager, functional line managers, top level executives, and assurance review teams.
external stakeholders, including the project partners, national agencies, local government representatives, non-government organizations, media representatives, and authorities.
Based on the information requirements of the specific stakeholders, both the content and the format of the reports need to be carefully defined.
Because most of the project-reporting processes are performed on a periodic basis, a huge effort is required to prepare and circulate all the required reports. Typical reports for oil and gas projects in Eni are prepared using the classic office tools, as shown in Exhibit 1. In the picture, side by side with the report name, a thumbnail demonstrates an idea of the type of information (tabular, graphical, textual) that is included.
Exhibit 1 – Typical reports that are prepared and circulated on a regular basis
In 2010, a project was started at Eni aimed at optimizing the project performance reporting process in order to help the project control engineers who were overwhelmed by this activity. The detailed analysis carried out during this project showed that, in spite of the large number of report types, most of the reports shared common characteristics. In the following sections, the “Executive Report” will be used as an example to describe the outcomes of the analysis.
Descriptive Sections versus Data-Intensive Sections
Many sections across the report are data-intensive, that is, they contain tabular data and graphs that could be automatically extracted from project management software, as shown in Exhibit 2. In most cases, however, these sections cannot be filled by copying and pasting the standard output report produced by project management software, because they often need to be customized both in terms of information content (additional rows and columns in tabular outputs, or additional curves in graphical outputs) and format (customized styles, fonts, and colors). Therefore, an additional effort is required to either reformat or manually re-enter the data into the report. Often the same data need to be entered into many reports, which is an error-prone and time-consuming activity.
On the other hand, large sections of the report consist of descriptive information that is not tracked by project management software, and therefore is manually entered by the user. The description of main project activities and criticalities, as shown in Exhibit 2, is a typical example. Even in this case, the same descriptions need to be entered into many similar reports.
Based on the previously listed considerations, a great improvement is related to the possibility of:
automatically populating the report with data/information coming from project management software, but retaining the formatting/customizations as they have been defined in the Word/PowerPoint report;
allowing the user to manually type the descriptive parts of the report once and reusing them across different reports.
Exhibit 2 – Information within the report versus source of information
Sections in the Report versus Target Audience
Different sections in the report may be appropriate for a specific audience but not suitable for others. The descriptions of project activities and criticalities may be too detailed when circulating the report across an audience of top executives within the company (see Exhibit 3). Moreover, part of the information contained in the report might be company specific (for example, the section related to the strategic plan shown in Exhibit 3), and therefore, it would not be appropriate to circulate it to external stakeholders.
Exhibit 3 – Content of the report versus audience type
Based on these considerations, a great improvement is related to the possibility of composing each report by assembling a set of appropriate sections, which are updated and maintained separately by the project control team. With such an approach, information would be entered once (e.g., the chapter related to “progress”), and then reused for various reports (e.g., internal report, report addressed to external stakeholders, and so forth).
Data-Intensive Sections and Origin of the Data
The data-intensive sections of the report contain data that might be scattered across different company repositories. In fact, some data are specifically focused on the time line of the project itself (e.g., project progress and budget phased on the multi-year project lifetime), and are typically managed within project management software. However, internal stakeholders will also require sections of the report in which project data are compared with company-specific plans and forecasts that are generated outside of the project management process:
project budget versus 4-year strategic plan of the company; and
project economics re-evaluated with the economic scenario for the current year.
This situation is described in Exhibit 4. The data contained in the highlighted sections cannot be obtained from project management software, because they are typically managed through different information systems (e.g., ERP [enterprise resource planning software]).
Based on these considerations, a great improvement would be related to the possibility of having a single reference company repository where project data are consolidated from different applications and databases. In such a case, the chapters of the reports referring to any project-related data could be automatically populated without using a manual, error-prone, and time-consuming process.
Exhibit 4 – Content of the report: Project data and other organization-specific data
Smart Approach to Project Performance Reporting
Eni's project, aimed at optimizing the project performance reporting process, exploits two leading edge technologies, namely office business application (OBA) and master data management (MDM). These technologies have been used respectively to achieve the accomplishments outlined in the sections on: (1) Composition of Reports from Data-Linked Chapters and (2) Integrated View of All Project-Related Data.
Composition of Reports from Data-Linked Chapters
Office Business Application (OBA) is a technology that allows people to use Microsoft Word and PowerPoint (as well as any other MS Office application) as a front end to their specific applications and systems. In the current case, project control engineers can use Word and PowerPoint to interact and get data from the project management software where progress and cost data are stored. The key concepts beyond such an approach are described in the following sections.
Smart Organization of Information
The key units (e.g., “chapters” for Word documents and “slides for PowerPoint presentations) that may be included in a project performance report are organized in an appropriate way, as shown in Exhibit 5. A document repository (e.g., based on SharePoint, or any other document collaboration software) is set up so that:
folders are organized by country and projects;
each project folder is appropriately assigned both a descriptive name for the project and a “project code” that is useful to correctly reference the project data within the database of the project management software; and
within each project folder, both a chapter repository and a slide repository are maintained. Each chapter (or slide) represents the minimum modular element that will be used to compose all the different project reports, trying to avoid duplication/overlapping of information between chapters.
Exhibit 5 – Organization of chapters and slides across projects
Live Link to Project Data
Within each single chapter (or slide), the user can intermix the text and the figures of the document with tags (within Word documents) or tagged shapes (e.g., rectangles, for PowerPoint presentations); in other words, document references that will be linked with the corresponding values in the project management software.
In the Word document shown in the upper portion of Exhibit 6, the tag named “Planned Overall Physical Progress” will be automatically populated with the corresponding numeric value (e.g., 72.45%), depending on the corresponding value associated with the project coded “XXXXXX” in the project management database. In the PowerPoint presentation, shown in the lower part of Exhibit 6, the rectangle shape that is highlighted will be populated with the “Production Start-Up” project milestone (e.g., 05/31/2014).
Exhibit 6 – Chapters containing tags/tagged shapes linked to the data
The periodic interaction of the project control engineer with Word (i.e., his project reporting application) is described in Exhibit 7. OBA is installed as a plug-in of Word (or PowerPoint), and it adds additional menu items: the “Project Report Builder” menu and the corresponding “ribbon” (i.e., sub-menu bar). Clicking the “Chapter Manager” menu item in the ribbon, the “Executive Report” pane is displayed in which the user performs most of his or her operations:
select the Country and Project of interest from the Chapter/Slide Repository;
obtain the available Chapters (“Get Chapters” button);
open, edit, and format each chapter as desired (“Open Chapter” button);
update any Tag in the document, with the values automatically obtained from the project management database (“Update Open Chapter” button).
The interaction between an OBA application and project management software is based on the usage of web services, a flexible mechanism that allows the integration of applications with each other. Most project management software (e.g., Primavera, MS Project) provides web services to expose project management data to external applications. In the case of Eni, web services are used to obtain data from the Project Management Information System called “SIGEP,” a company-specific development on top of the Project Objects software.
The described mechanism can be used to update both tabular data and graphical data within the Chapters of the report. In the case of graphical data, it is only necessary to embed an Excel spreadsheet within the Word (PowerPoint) document, format it as required (i.e., type of the graph, colors, legends, etc), and ask the web service to update the underlying Excel data table, which will automatically update the graphics.
Exhibit 7 – Updating tags with values obtained by project management databases
Composition of the Report
After ensuring that all the chapters are aligned with up-to-date information, the project control engineer can compose as many reports as needed by assembling the pre-existing chapters, as shown in Exhibit 8:
selecting of the Chapters that will compose one specific report (by checking off the corresponding check boxes);
running the “Compose Executive Report” button.
The resulting document will contain the concatenation of all the selected Chapters. Moreover, the resulting document will not contain any data-linked Tag. In fact, the process of composing the report automatically removes all the Tags and keeps only the formatted values that were brought into from the project management database. The resulting report is therefore suitable for distribution to the corresponding stakeholders.
Exhibit 8 – Composing the report
Integrated View of all Project-related Data
Master Data Management (MDM) is a technology that allows companies to have a single view of key “business entities” across different IT systems. In the case under consideration, MDM is used to have a single view of the “Project” entity across Project Management software, ERP systems, and economic simulation systems.
For each project within a company, many internal processes generate their own view of project data, as shown in the upper part of Exhibit 9:
the project management process is focused on the timeline of the project itself, from the project start date (i.e., middle of current year) to the project end date. All project-related data are phased along such a timeline;
the Company Strategic Planning process might be focused on a 4-year timeline. Project data are projected on the corresponding timeline and incorporated into the Strategic Plan;
the Budgeting process is focused on the current year. The snapshot of project data that fits the current year is incorporated in the yearly budget and forecasts.
Because project management process updates project data on a regular basis (e.g., monthly, weekly), it is important to compare the projections of Project Progress/Cost data with the current year's Budget (which is updated quarterly) and with the Strategic Plan (which is updated yearly). Therefore, the corresponding figures often need to be included in the Project Performance Reports addressed to top level executives in the company.
In order to make available additional data to the Performance Reporting framework, which was described above, MDM can be used to consolidate project data across different systems into one single view, called “Master Database,” and shown in the lower part of Exhibit 9.
The key challenge of MDM is the ability to track the same projects across different systems, which may be complicated due to the following problems:
they could use different coding systems and naming conventions;
an entity that is seen as a single project within the Project Management software may be split into different projects within the Budgeting System, or vice-versa;
different data semantics could be used across different systems (e.g., using “current values” versus “constant values,’ i.e., keeping into account the depreciation scenarios).
Current MDM technologies allow the creation of the unified view both:
in a virtual way (i.e., the corresponding data are kept in the original databases, without duplication of data);
in a physical way (i.e., the corresponding data are copied into the Master Database from the original sources), using the ETL (Extract Transform Load) technology to move data across repositories.
Exhibit 9 – Master database management approach
The Master Database can act as the single backbone repository that is linked by the OBA reporting application, as shown in Exhibit 10. With this approach, each section of the Project Performance Reports can be automatically filled with any project-related data.
Conclusions
The smart usage of the OBA (Office Business Application) and MDM (Master Data Management) technologies, along with an appropriate organization of project data and information, allows the optimization of the Project Performance Reporting process by removing a number of time-consuming and error-prone activities.
Project control engineers can:
enter project status data once (within the Project Management Software);
automatically have project status data in their reports;
update textual and graphical information once (within the appropriate Chapters/Slides in the document repository of the project);
automatically have access to the last updated information from other systems (budget, economics);
produce reports by aggregating the appropriate Chapters/Slides directly from the user interface of the Word and PowerPoint applications, to fulfill the information needs of each stakeholder.
Exhibit 10 – MDM and OBA used together to optimize project reporting
The approach was implemented by Eni in 2010 and is incrementally applied to the Field Development Projects within the company.
Acknowledgments
We wish to thank all the personnel who contributed to Eni's “Project Control and Reporting Optimization” project, with special reference to Paolo Rossi and Guido Mattu, who led the internal team. We wish to thank the people who implemented the OBA and MDM approaches, with special reference to Diego Cingolani and his team, Massimo Dossola and Claudia Cavecchi. We thank Giorgio Veronesi and Fabrizio Bonifacio, Microsoft consultants who helped developed the OBA approach. We also wish to thank Eni's management for the permission to publish this work.
