Executive Summary
Integrated Production Surveillance Dashboards are gaining wider recognition and adoption in E&P organizations as an effective technology enabler. They deliver key operational data to end-users in the form of meaningful KPIs that drives efficient diagnosis and optimization of production issues. Such dashboards also act as enablers for exception based surveillance which is now becoming an integral part of operating philosophy for E&P companies.
Some of the drivers for wider adoption are-
• Need for better production surveillance
• Improving engineers’ productivity (higher well to engineer ratio)
• Workflow standardization
• Constant push towards proactive optimization through better and faster understanding of the asset performance
A number of E&P operators have initiated projects to implement such dashboards and integrate them into day-to-day operational workflows. Such projects are either part of operators’ Digital Oil Field (DOF) programs or stand-alone business process improvement initiatives. However, not many of these implementations have met expectations.
Based on our experience with many of these initiatives, we have identified 5 common pitfalls along with their impacts which occur with alarming frequency across the organizations. We have also listed some of the leading practices that we have seen being adopted across successful implementations of surveillance dashboards.
This paper describes various pitfalls, their impact areas and leading practices to avoid them as summarized below.
Common Pitfalls
Project Impact Area
Leading Practices
Introduction to Integrated Production Surveillance Dashboards:
Integrated Production Surveillance Dashboards (hereafter referred as Surveillance Dashboard) are seeing a wider adoption in the industry. They are focused on key surveillance processes used within upstream companies in various areas such as well surveillance, reservoir surveillance, facilities surveillance and pipeline surveillance.
Within these broad areas there could be specific sub-workflow. For example, well surveillance may include, rate and phase, gas lift, water injection or ESP surveillance. Following is a sample surveillance dashboard focusing on production monitoring.
Fig 1- A sample surveillance dashboard
The main functionality of these dashboards is to provide surveillance workflow specific multi-disciplinary KPIs to the asset teams through a portal in the form of maps, graphs, trends, tables and charts. Many surveillance dashboards contain workflow functionality to manage different steps and tasks involved in a particular surveillance process.
By allowing sharing of common data, they support collaborative analysis and diagnosis of the production issues. Quality of collaboration is greatly improved with usage of surveillance dashboards which leads to improved optimized decisions.
From a technology perspective surveillance dashboards contain process-centric role-based visualization of operational KPIs with appropriate drill downs through asset hierarchy, exception summary, exception triggered workflows and search functions.
Implementation of these components requires integration with foundational source data systems, business logic layer to perform data validation or apply certain transformations to the data through pre-defined business rules and User Interface to present various KPIs (as shown in fig 2). Since these dashboards tend to be Web-based, surveillance dashboards are easy to access from various end-users devices from any network enabled location.
Figure 2- Typical Architectural Topology of Surveillance Dashboard Project
Common Pitfalls Seen in the Industry
Surveillance dashboard projects in E&P industry tend to suffer from all the typical project management issues such as cost, quality and schedule slip-ups. Industry is replete with examples with failure of seemingly simple operational dashboard implementation projects that became costly and wasteful undertakings.
We have presented an analysis of some of the common pitfalls impacting the implementation of surveillance dashboards. However, it does not mean that the importance of post implementation sustainability aspects of such projects is not recognized. Based on our experience, many of the post-implementation sustainability issues are caused by poor implementation.
Pitfall 1: Centrally-led “push” approach failing to create asset buy-in
Project Impact Areas: Organization buy-in
This is mainly applicable to centrally-led Digital Oil Field (DOF) programs that typically include surveillance dashboard projects as one of the program components. Such programs are driven by central corporate DOF team that is entrusted with defining DOF strategy, standards and implementing the same across business assets.
Different assets have different facilities configuration, operational philosophy and field organization structures. As a result their operational drivers, KPIs and use cases for a surveillance dashboard projects tend to be different. Adopting a one-size-fits-all approach from central team towards implementation of surveillance dashboard systems is met with resistance or skepticisms from the assets.
Also assets are often not clear about how a new solution introduced by the central team would fit into their environment and processes and view them with a “here comes one more” mindset.
Failure to recognize and reconcile these fundamental differences between corporate and asset drivers is known to impact uptake of centrally-led surveillance dashboard solutions.
Pitfall 2: Lack of right level of business participation
Project Impact Areas: Organization buy-in, scope, quality and schedule
Surveillance dashboard projects require continuous and deep involvement of business users throughout project cycle. Unfortunately many surveillance dashboard projects are seen as IT projects managed by the IT project manager and staff with limited understanding of business issues. Another reason cited for limited business involvement is lack of business resources. Either way this results in following ramifications for the projects:
Pitfall 3: Adopting a big-bang approach to deliver large scope of work
Project Impact Areas: Scope, schedule, quality and budget
Surveillance dashboard projects often cater to multiple business processes. One common issue that we have seen is project teams trying to deliver a very large scope of work using traditional waterfall release strategy. In our view such approach is fraught with risks. Scope creep and bug laden delivery are common issues. Even if the project scope is managed aggressively throughout lifecycle, learning that comes with incremental delivery is lost. Many hidden issues are uncovered only at the end of the project. For example data quality issues are commonly seen in production surveillance dashboards. We have seen many dashboard projects where project team discovers bad data issues not known earlier. Likewise in many instances we have seen performance issues because of insufficient network bandwidth or badly tuned PI systems. Fixing these issues is a time consuming process, and leads to further project delays.
Pitfall 4: Failing to address data and IT infrastructure quality issues
Project Impact Areas: Organization buy-in and quality
Surveillance dashboard systems are heavily dependent on underlying IT and communication infrastructure. Given the large and geographically diverse user base, high usage frequency and large volumes of real/non-real-time data transmitted over the network, it is important to pay attention to performance aspects. Typically end-users’ performance expectations are very high and they expect a graph/chart to appear within 2-4 seconds of mouse-click.
Data quality is another important aspect as the key objective of a dashboard is to enable decision making based on data. It’s important for end-users to trust the data that they see on their screens.
Although poor performance and bad data quality are the most commonly cited reasons for failure of these dashboards, unfortunately none of these two factors are paid sufficient attention to. Such issues are known to impact the promised value of surveillance dashboards and if not addressed in time, end users lose trust in these dashboards and go back to their individual tools/spreadsheets.
Pitfall 5: Underestimation of skills required for project execution
Project Impact Areas: Quality, schedule and cost
Skills required to deliver surveillance dashboard projects are greatly underestimated.
Surveillance dashboard projects involve iterative cycles to arrive at final specification. Each iteration involves associated end-user interactions, documentation, business reviews and design modifications.
Reducing the number of iterations and shortening the time scale of each requires superior business analysis skills. Unfortunately, surveillance dashboard projects are often staffed with Business Analysts (BA) who do not have sufficient skills to perform in the dynamic and complex business environments associated with dashboard projects.
The role of technical architects is also very important. Very often wrong technical choices lead to performance issues resulting in end-users’ dissatisfaction.
Example: In one case, a project team designed a technical solution considering a few hundred wells the company had at the time of project; however the same solution could not scale-up effectively when company drilled a few hundred wells more and end-users faced a lot of performance issues. In another case, the project team selected a tool for processing real-time data streams against a set of algorithms. The tool worked fine with a few calculations. However in the later stages of the projects, more calculations were added to the scope and a lot of performance issues were faced with the tool.
Leading Practices for Effective Execution
Having been involved in a large spectrum of surveillance dashboard projects with several E&P clients, we have identified several leading practices to counter the listed pitfalls. We believe that adopting these approaches will help corporate and assets maximize the value from their surveillance dashboard projects.
Leading Practice 1: Central team should establish a mutually beneficial partnership with assets based on common interests
Global adoption of centrally-led initiative highly depends on early engagement of assets in order to demonstrate the value and here it is important to perform real world pilots to test the technology and incorporate the learning. The choice of pilot asset is important. Ideally the pilot asset should have some or all of the following characteristics:
During project execution phase, central team should closely work with assets and proactively identify and address the conflicts between standard blueprint and assets’ IT environment. The focus should be on demonstrating value even if it means changing some of the architectural elements of the system to fit in asset IT environment. Overall central and asset teams should try to strike a balance between brute-force standardization and excessive customization.
A true partnership approach between central team and assets will build assets’ trust in central team and pave the way for smoother rollout across other assets.
Leading Practice 2: Establishing business stewardship through right project organizational design
A surveillance dashboard project should never be allowed to take-off if it does not have involvement and support from key business representatives (functional heads, team leads, process owners etc). Goal of project organization design should be to install right level of business stewardship.
It’s important that key decision makers sitting in important project governance layers are drawn from various asset functions that will be most impacted by the system. They should have vision, leadership skills and motivation to steer the project in the right direction.
Given stakeholder diversity and evolving nature of dashboard projects, project manager should be carefully chosen. Ideally project manager should be from a business-facing group that is tasked with business improvement and new capability development (e.g. Digital Oil Field) within the organization. They should have wider asset operational understanding, demonstrate sound political savvy and possess strong leadership skills. Finally they should have a proven track-record in delivering similar projects.
Project manager should be empowered by the Executive Steering Committee to drive decisions on the scope and schedule and they should be provided necessary access to end-users representatives for regular interactions. If under certain circumstances certain project scope needs to be outsourced, project manager should play a key role in vendor selection process.
Leading Practice 3: Adopting an incremental delivery approach to mange risks and demonstrate value
Project team should focus on delivering a prototype within a short timeframe to demonstrate value. Prototype should allow testing of as many critical architectural components as possible to detect or confirm infrastructure issues at early stage of the project.
Prototype should be kept light with probably one data source and a subset of asset area types (e.g. naturally flowing oil wells).
Once prototype has been delivered and necessary adjustments are made, project team should start building on it by adding more data sources and more number of asset area types (for example, gas lifted, ESPs, water injection etc) in subsequent releases. Once a complete process is delivered subsequent processes can be delivered in batches. A conceptual illustration is shown in figure below.
One may argue that too much iteration may cause delay. However early success is critical in building the confidence of end-users in the system, getting their support and reducing successive change management efforts. Also given that 50-70% of architecture components (data sources, widgets, interfaces) tend to be common across various processes, such approach is effective in verifying performance of these components. Finally scope changes can be better managed as new change requests can be consolidated during first release testing and delivered in subsequent release cycles.
Fig 3- An Illustration of incremental delivery model
Leading Practice 4: Detecting infrastructure and data issues early on and establishing initiatives and funding within organization to fix them before or during project implementation
It’s extremely important that the project team establishes good understanding of IT infrastructure and data quality issues before project initiation to adjust project plan and stakeholder expectations.
If there are any ongoing data management or IT infrastructure improvement projects within asset, it’s advisable for project organization to leverage findings from those projects and feed them into project planning phase.
Before project is initiated, a parallel independent feasibility study should be conducted to assess the state of infrastructure and data management readiness. Here care should be taken to not only consider the current scope but also future growth of system and other similar planned initiatives in the asset. All gaps identified should be prioritized and action plans identified to address major gaps.
Once action plans are approved by executive project steering committee, a task force should be formed to execute the action plans. If action plans require initiation of new projects then dashboard project schedule should be adjusted to align deployment cycle with delivery of infrastructure or data management improvement projects. In case there are ongoing infrastructure or data management projects sponsored by different business function, possible alignment should be established to create synergy with them.
Leading Practice 5: Staffing project with right set of Business Analysts, Technical Architects and SMEs with proven credentials in delivering similar projects; seek outside help if skills are not available in-house
Project BA’s should not only have good understanding of E&P business but also good appreciation of surveillance workflows they are dealing in. They should also have prior experience in dashboard projects and possess skills in rapid prototype techniques that shorten requirement gathering and validation phases.
Technical architects should have good functional understanding of upstream specific third-party software, their usage in day-to-day operations, common data issues surrounding these systems and common integration challenges.
Strategic thinking is crucial in ensuring long term scalability of the system design. Technical architects should have broad view of the data standards and technology offerings focused on upstream industry to help them make well-informed choices during extraordinary situations.
To ensure above, project manager should come up with well defined job descriptions, for different project roles, tailored to surveillance dashboard projects and stick to them ruthlessly while scouting for project resources.
It’s quite possible that assets may not always have access to all the necessary skills in-house. In which project manager should seek the services of outside consultants or service providers.
Conclusion
E&P companies implementing surveillance dashboards should closely watch out for these implementation pitfalls. It is difficult to anticipate these pitfalls, given their nature and they are often known after they have occurred. This is not surprising given that many of them deal with subjective areas of organizational and stakeholder alignment and maturity of internal processes.
We highly recommend conducting a readiness assessment for asset to undertake such a project. This will be useful in detecting these pitfalls early on. Once these pitfalls are known, we suggest that organizations should adopt incremental delivery approach as an overriding leading practice. This would allow building smaller functionalities, understanding the pitfalls, learning from them and making necessary course correction.
Integrated Production Surveillance Dashboards implementation should not be seen by business as just another IT project to be delivered on time and budget. They should be seen as business capability development and the business goal should be on delivering a robust and scalable platform that would accommodate future business growth and accompanying organizational and process changes.