Supporting project management processes with integrated software tools and databases
Eni E&P Division
Eni Exploration and Production, the Italian Oil & Gas Company, has recently reengineered the internal processes to carry out Field Development Projects, covering the full lifecycle from the discovery of a hydrocarbon reservoir up to the construction of wells, pipelines and facilities to sustain the production. Eni's Project Management processes are mostly based on PMI concepts.
An integrated IT environment (including software applications and databases) has been designed in order to provide each project team with comprehensive support throughout the new PM processes. New tools have been developed and existing tools have been adapted and plugged into the environment so that all PM views (from WBS definition to cost control, from risk management to lessons learned) are consistent with each other.
The presentation will show an example usage of the environment across a subset of selected PM processes and knowledge areas:
- building the project WBS by assembling default project components from a “WBS template” database;
- building the initial Cost Breakdown Structure, and linking it with WBS components;
- building and managing the Risk Register and Risk Management Plans, and maintaining a company-wide risk database;
- managing communications among stakeholders through a web-based document sharing system with distribution lists and email notifications;
- managing progress status using the Earned Value method;
- managing reporting to top executives through a web-based dashboard;
- supporting the collection and distribution of lessons learned throughout a company-wide database.
The presentation will finally describe the challenges that were faced in developing the IT environment, as well as the integration approach that was adopted.
The environment has been used to support more than 130 projects.
Eni Exploration and Production, the Italian Oil & Gas Company, has recently reengineered the internal processes to carry out Field Development Projects, covering the full lifecycle from the discovery of a hydrocarbon reservoir up to the construction of wells, pipelines and facilities to sustain the production. Such processes are documented within the “DMS” (Development Management System”).
Eni's Project Management Processes
Eni's reference life cycle for a Oil & Gas Field Development Project is based on a stage-and-gate concept (Exhibit 1), named “OPDS” (Opportunity and Project Development System), including five phases: “Evaluation”, “Concept Selection”, “Concept Definition”, “Execution” and “Commissioning, Start-up and Performance Test”;
- within the Evaluation phase, the Project Team assesses the value of the opportunity and the alignment with business strategy based on preliminary reservoir scenarios and development concepts;
- within the Concept Selection phase, the Project Team generates concept alternatives, selects and optimises the preferred concept based on technical, economics and risk evaluation;
- within the Concept Definition phase, the Project Team refines selected concept, completes tendering and produces a Project Execution Plan which allows project sanction;
- within the Execution phase, the Project Team executes the project to achieve a fully operating system meeting cost, time and quality targets;
- within the Commissioning, Start-up and Performance Test phase, the Project Team ensures that the facilities are fully operational and can be handed-over to the operating personnel.
Exhibit 1 – Eni's Reference Process for Field Development Projects
At the end of each phase the Project Team prepares a Decision Support Package (DSP), which is a set of documents summarising the project achievements up to that moment and the plan to afford next phase. This DSP constitutes the basis for the Assurance Review (AR), a mandatory, independent review examining all the aspects of a project before accessing a Gate. Decision Gates are milestones placed at the end of the first three phases, where a Decision Making Body decides the course of action (e.g. proceed to the next phase; rework -insufficient work to support the recommendation-; change the project scope to make it more attractive; hold the project because it is currently not attractive; kill the project, because it will not be attractive even in the future).
Gates are important because they can properly identify value drivers, risks and uncertainties prior to committing to major expenditures. In fact, uncertainties decrease as the project moves from one phase to another, both in terms of revenues (i.e. better accuracy in the expected production profiles from the reservoir) and in terms of accuracy in the estimates of capital expenditures.
Oil & Gas Field Development Projects need the integration of different technical disciplines: geoscientists and reservoir engineers to analyze seismic and well data in order to build a subsurface earth model and to provide simulations of expected oil and gas flow rates from the reservoir; drilling and completion engineers to design and drill the production wells; facility engineers to develop the oil and gas processing facilities and pipelines; Health, Safety and Environment specialists to minimize the environmental impact and to enforce health and safety standards. The complexity of such activities and their interrelations with one another have been described within the TMS (Technology Management System) subsystem in terms of inter-related technical workflows. Workflows are grouped together into “TMS workflow maps” (Exhibit 2, upper part), one for each project phase; within the maps, interrelations of the workflows and their deliverables are highlighted. Each workflow (Exhibit 2, lower part) has been designed with a hierarchical structure of steps and tasks with a granularity which is:
- suitable to describe the methods, techniques, software tools and databases, as well as the suggested input and output data, which should be used to optimally perform the activity from the technical point of view;
- often suitable to be used as a base for the planning of Field Development Projects.
Eni specialists of different disciplines have developed 26 TMS workflows to support the technical activities of Field Development Projects; a total number of 152 steps details the workflows, while 619 tasks further details the steps. Within the tasks, more than 500 technical applications and databases have been described in order to perform the technical activities.
In addition to the TMS subsystem, the Value Management System (VMS) provides methods to identify, maximize and maintain the value of the project throughout the entire lifecycle, introducing a Value Assurance process and including risk management, guidelines for decision making, and collection of lessons learned.
Finally, the Project Management System (PMS) has been designed in order to provide a mechanism for defining, managing and controlling activities within the Development Project phases, thereby ensuring that all personnel has a clear understanding of what they are required to do, how they have to do it, and by when. The PMS therefore provides assurance to the Company and Shareholders that the activities of the Project Team are being properly controlled and that risks are being effectively managed. PMS principles are largely based on PMI's Body Of Knowledge concepts.
In order to afford the development projects with the new processes, Eni adopted a strong matrix organization. A new department includes all the Development Project Managers, each dedicated to a specific geographical area. Each project manager can leverage on a set of discipline managers (project reservoir manager, project drilling & completion manager, etc) within his own organizational structure, while the specialists are assigned to work on a project directly from their own functional units (e.g. reservoir department, drilling & completion department, etc). Project teams may be geographically distributed across Eni Business Units, from Australia and Indonesia to US and Brazil, from Norway and UK to Nigeria and Congo.
Exhibit 2 – Map of the technical workflows within the Concept Selection phase of a Development Project
Software Tools and Databases
In order to better exploit the above described project management processes, the technical IT department of Eni decided to rationalize the set of tools and applications that were used to support Development Projects. Such tools originally included different mail-boxes, shared disk drives, Lotus Notes archives, MS Project, Excel and Access files, and all of them were used decoupled from one another.
The new IT environment has been designed around four main applications, which were already used within Eni with a limited scope: Project Diary, a web application based on Lotus Domino which provides the ability to share documents and send email notifications across groups of people; Team Workspace, a web application which provides the ability to launch technical applications and databases without the need of having them installed on the local PC (or even in the local Intranet of the Business Unit); Technical Know How Portal, a web application based on SAP Enterprise Portal 6, which provides the ability to model technical workflows and to provide a workflow-oriented collaborative environment to perform project activities; RGM SIGEP, a web application which integrates MS Project but complements it with advanced functionality of project planning, schedule and cost control.
Such applications have been integrated with one another with the following approach:
- back-end integration: when a new Development Project is officially started, the project is assigned a unique corporate-wide code within the company Oracle database. Such project code is automatically propagated to Project Diary, Team Workspace, Technical Know How Portal and SIGEP, so that a suitable working environment is automatically initialized within each application;
- front-end integration: when a user logs into the environment and selects the project of interest, he can navigate from one application to another without being asked again for his credentials or for the project of interest. The Technical Know How Portal has been selected as the main entry point of the environment, as well as the tool which collates together all the others. Moreover, each user is assigned a specific role within the project, and this role is consistently propagated across all the applications.
All the applications have been designed so that their specific pieces of information are stored into the same Oracle database. This way, all the tools can easily exchange the information they need to share in a seamless way. Wherever the tools did not support a direct connection to the database, a Websphere Process Server implemented the integration by exchanging XML data among the applications.
From the user's point of view, the availability of project data in the same database has the following advantages:
- different pieces of information can be cross-referenced from each other (e.g. it is easy to find the risk register of the project, jump from one risk to the affected activities in the WBS, and then jump to the project deliverables that document the work performed on the activities);
- the data of previous projects can be analyzed in order to find useful information that can be applied to the current project.
In the following paragraphs, practical examples of the integration and synergies that have been achieved will be referenced to some key A Guide to the Project Management Body of Knowledge (PMBOK® Guide) knowledge areas.
Scope Definition, Schedule Development, Cost Management
Field Development projects are different from one another, but they often include a common set of activities, as described by the workflow maps of Exhibit 2. Moreover, they are finalized to the development of similar products, e.g. offshore platforms with oil &gas processing facilities and export pipelines. Standard Activities and Products are stored within the Eni's Oracle database as Activity Breakdown Structure (ABS) templates and Product Breakdown Structure (PBS) templates. The SIGEP tool allow to integrate ABS and PBS (Exhibit 3) in order to initialize the project-specific Work Breakdown Structure (WBS). A WBS based on the composition of standard components provides a set of advantages:
- ABS and PBS templates can be used as checklists, in order to ensure that no key activities or product components are forgotten from the project plan;
- different projects can be (at least to some extent) compared to each other, therefore helping in the estimation of durations and costs of future projects.
Exhibit 3 shows an example usage of the IT tool: activities from the TMS workflows can be imported from the left part of the window into the WBS (middle part of the window). Same way, product components can be selected from the right part of the window. In the example show in the Exhibit, the “J – Facilities Study Preparation” workflow can be targeted to the development of a “F01 – Conventional Platform”.
Exhibit 3 – Building the project WBS by assembling Activities and Products
After the WBS is initialized, it is possible to use MS Project in order to perform Activity Sequencing, Duration Estimating (the Palisade @Risk tool is sometimes used to provide probabilistic estimates for the duration of activities) and Schedule Development. The schedule is saved in the Oracle database, not as a “mpp” file. The base schedule can then be processed with additional tools in order to:
- plan the physical progress of the activities. The physical progress can be defined either to be linear with the time progress (e.g. a 30% time progress corresponds to a 30% physical progress), or can follow a “S-curve” (i.e. physical progress is slower than time progress in the initial and final phase of the activity), as well as other progress criteria (front loaded, back loaded, milestone based, etc);
- define the relative weight of each activity in the WBS, so that an overall physical progress for the project can be computed by propagating the weighted average of each progress element along the WBS tree.
Finally, the tool allows the definition of a Cost Breakdown Structure (CBS). Cost elements are stored in the Oracle database and can be linked to the account codes of the SAP R3 Enterprise Resource Planning system. On a monthly basis, both budgeted and actual values of the cost elements in the CBS can be automatically updated with the values from SAP R3. Finally, each cost element can be referenced to the corresponding element of the WBS.
Exhibit 4 shows two examples of the top level aggregation of Cost Breakdown Structures templates within the Oracle database.
Exhibit 4 – Example of Cost Breakdown structures
Another key element in the project planning is represented by the preparation of the project documentation plan. Some way as the project's WBS is automatically initialized with the workflow maps of the Technology Management System, the Project Diary component is automatically initialized with the suggested set of documents that need to be produced within the scope of the project. Such documents include the deliverables that are used by the Decision Makers at the Gate, as well as the key deliverables that are exchanged among the technical workflows of different disciplines in order to build a shared, multidisciplinary view of the project.
Documents are automatically initialized with predefined permissions (i.e. suggested authors, readers, verifiers and approvers of the document) and notification policies (i.e. who should receive an email with the link to the document when it is changed, marked as completed, verified or approved). Moreover, some of them are also automatically initialized with predefined document templates containing the Table of Contents or the suggested structure of the document.
Project risks can be fully documented within Eni's Oracle database. Each risk is classified by category (e.g. technical, legal, environment, etc) and is associated with the probability/impact values which derived from the qualitative risk analysis. Multiple revisions of the same risks can be maintained, together with the evolution of the probability/impact classification along the time. Since both risks and the WBS are stored in the same database, risks can be tracked against the WBS activities they have impact on. Moreover, risk response plans can be developed and assigned to the corresponding risk owner. Quantitative risk analysis is supported with the integration of Palisade @Risk tools.
The availability of a company-wide risk database is particularly useful because:
- in the risk identification phase, the analysis of the risks in the database can stimulate the team members to focus on risk types they did not originally consider for the project;
- the analysis of the risk response plans of other projects and their effect on the mitigation of the risk can help the risk owners in selecting effective actions for the management of their own risks.
A detailed description of Eni's Risk Management process can be found in Rossi (2007.
Manage Project Execution, Distribute Information
When working on specific project activities, each project team member can connect to a web page (Exhibit 5) where he can find the suggested methods, techniques, software tools and databases, which can be used to optimally fulfil the tasks. Exhibit 5 shows a user dealing with a technical activity (the “J.2 – Main Process and Utilities Design” step within the “J – Facilities Study Preparation” workflow): the web page integrates the Project Diary environment (lower-left part) where the user can create, update or read documents related to these tasks, as well as share them with the other team members; the Team Workspace environment (upper-right section: “Related Applications”) where the user can launch technical applications (like process simulators and CAD packages); the Lessons Learned database (lower-right part: “Related Knowledge”) where all the Lessons Learned which can be related with the current activity are automatically proposed to the user; and the database of best practices, providing both the optimized decomposition of the step into further sub-tasks (upper-left part of the Exhibit, where the “J.2.1” task is described) as well as company standards (middle-right part, “Useful links”) which can be applied.
Workflow maps, steps and tasks are “live” elements when they are included in a project: the following colour codes are consistently used across all tools (e.g. Exhibit 2 – workflow map and workflow steps-, and Exhibit 5 –task “J.2.1” and documents “Process schematics” and “Discussion about dehydration units to be used”): green means “completed”, yellow means “in progress” and red means “not started”.
Exhibit 5 – working on project activities
Monitoring and Controlling Processes
Schedule and Cost Control
SIGEP includes the ability to integrate the start/end dates of activities (which are read from the embedded MS Project tool) with the indication of their physical progress, which can be computed with sophisticated phasing curves. Exhibit 6 shows an example of a typical “S-curve” phasing of the cost of an activity.
Moreover, the application of the “Earned Value Method” is supported: Exhibit 7 shows an activity where the original budget (BAC, Budget At Completion) was 800 K euro and the value of work done (AC, actual cost) was 100 K euro. However, the Earned Value (EV) is 112 K euro, and therefore the Cost Performance Index (CPI) is 1.12. The expected final cost (EAC, Estimate At Completion) is computed based on the projection of the remaining work being performed at the same performance index, and therefore it is estimated as 714 K euro.
Earned Values and EAC can be propagated along the nodes of the CBS, therefore obtaining global estimates for the overall project (Exhibit 8).
Within Oil & Gas Development Projects, stakeholder management is a key process that must be carefully planned and controlled. Stakeholders may include other Oil Companies of the Joint Venture, as well as National Authorities that can have a major effect on the success of the project. For these reasons, project Stakeholders can be tracked within Eni's Oracle database and they can be analysed in terms of their influence/disposition towards the project. Finally, stakeholder management plans can be developed and assigned to the corresponding owners.
Exhibit 6 – comparing planned (blue), forecast (green) and actual (red) costs
Fig. 7 – Application of the Earned Value method
Fig. 8 – Global Indicators for two projects (VOWD = Actual Cost, EFC = Estimate at Completion)
Since all project related information are stored in the database and cross-referenced with each other, communication and reporting are mainly based on a set of web pages which provide a high level overview of the whole portfolio of projects (Exhibit 9) and allows to drill down into project specific information (Exhibit 10).
Exhibit 9 – overview of the project portfolio
Within Exhibit 9, the colour codes show that Project 1 has completed the Concept Selection Phase, the Assurance Review 2 and Gate 2 (all marked in green), and the decision at Gate 2 is “proceed” (small green arrow below the gate symbol). The Concept Definition phase is in progress (yellow), and the underlying progress bars give an indication of the current progress both in terms of schedule (upper bar: current progress vs. planned progress vs. overall duration) and costs (lower bar: actual cost vs. planned cost vs. Estimate At Completion vs. Budget At Completion). Assurance Review 3 has already been performed (green) while Gate 3 has just been planned (red).
Each symbol on the web page is clickable, and brings up contextual pieces of information: clicking on a Gate symbol, the subset of documents that have been considered by the decision makers is displayed; clicking on the “Proceed” arrow symbol, an extended comment about the Gate result is visualized; clicking on the “Authorization Level” symbol (left part of the Exhibit), the overall Investment on the project, as well as Eni's share and working interest in the project, are shown. Clicking on a phase (e.g. the Concept Selection of Project 3) displays the web page shown in Exhibit 10. From here, it is possible to access all project-related documents, as well as project deliverables, schedule data with full details on the WBS and Gantt chart, cost data with full details on the Cost Breakdown Structure, risk register and risk response plans, stakeholder register and stakeholder management plans, and lessons learned. Finally, a link to access the technical workflow maps and the online working environment of Exhibit 5 is provided, and major project milestones are reported.
Exhibit 10 – details about a project
The Lessons Learned collection process has been designed in order to maximize the possibility of reusing the key learnings in future projects. For this reason, Lessons Learned are not collected within unstructured documents (like Word reports), but rather captured and stored into Eni's Oracle database, where they are organized and classified in the following way:
- each Lesson Learned is organized in four descriptive sections: what was supposed to happen; what happened instead; why the difference occurred; what we can recommend for the future;
- Lessons Learned are further classified on the affected functional areas (e.g. project management, environment, reservoir, etc);
- technical Lessons Learned can be classified on the workflow/step of interest;
- Lessons Learned generated in other projects can be imported and contextualized in the current project.
Such approach has the following advantages:
- the specialists of each discipline can easier find the Lessons Learned of their interest without being cluttered by Lessons Learned of other disciplines;
- technical specialists are automatically shown the Lessons Learned affecting the processes (i.e. workflows and steps) they are working on even if they do not explicitly search for them (see Exhibit 5);
- the analysis of the Lessons Learned which are imported and adapted from other projects is important in order to identify common patterns that may affect multiple projects (e.g. a Lesson Learned could be: the project team was not adequately staffed; a key stakeholder was involved too late in the project; the lack of a procurement strategy introduced delay in the project).
Overall System Architecture
Eni's database architecture is summarized in Exhibit 11. The Exhibit shows the section of the database dedicated to templates (left hand side), where workflow maps (i.e. Activity Breakdown Structures), Product Breakdown Structures and document templates are maintained; and the section of the database dedicated to the projects (right part), where WBS are instantiated and maintained, progress elements are computed, costs are tracked (optionally from SAP R3 account codes), risks, stakeholders and lessons learned are collected and categorized. The Technical Know How Portal is highlighted as the main entry point for the users; it seamlessly integrates the functionality of SIGEP, Project Diary and Team Workspace.
Exhibit 11 – Overall Database Architecture
The synergy between the project management processes and the integrated set of IT tools and databases has proved to be extremely effective in enhancing the quality of the work of the people involved in Oil & Gas Field Development Projects within Eni. The approach is consistently used throughout the organization, and more that 130 projects are currently managed within the system.
We wish to thank all the personnel who contributed to this work, with specific reference to Gioacchino Gaudioso (RGM Consultants). We wish to thank Eni's management for the permission to publish this work.
Marini, F., Zarri F., Salvaneschi, L., Rossi, P., Bedarida, S., & Garbujo, C. (2005, March). An Integrated System for E&P Development Projects supported by Advanced Information Technology Tools. OMC 2005, Ravenna Italy.
Piantanida, M., Rossi, P. & Gaudioso, G. (2006, June). A Web-Based Integrated Project Management System supporting Teamworking and Decision Making on Field Development Projects. SPE EUROPEC 2006, Vienna.
Rossi, P. (2007, May). How to link the qualitative and the quantitative risk assessment. PMI EMEA Global Congress 2007, Budapest.
© 2007, Marco Piantanida, Paolo Rossi
Originally published as a part of 2007 PMI Global Congress Proceedings – Budapest