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

• Centrally-led “push” approach failing to create asset buy-in
• Lack of right level of business participation
• Adopting a big-bang approach to deliver large scope of work
• Failing to address data and IT infrastructure quality issues
• Underestimation of skills required for project execution

Project Impact Area

• Business buy-In
• Organization buy-in, scope, quality and schedule
• Scope, schedule, quality and budget
• Organization buy-in and quality
• Quality, schedule and cost

Leading Practices

• Central team should establish a mutually beneficial partnership with assets based on common interests.
• Establishing business stewardship through right project organizational design
• Adopting incremental delivery approach to manage risks and demonstrate value
• Detecting these issues early on and establishing initiatives and funding within organization to fix them before or during  project implementation
• 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 

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.

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.

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:

• IT staff usually lack awareness  of variations in field specific surveillance practices  and  associated  organization structures.  Any  risks or implications originating from that are not factored into initial project planning leading to several changes in scope later on.
  
• IT staff  do not always have the necessary influence or authority to manage business decisions regarding scope and schedule. As a result project teams often give into the  business demands for frequent changes through excessive modifications in scope and system design.
  
• Project teams try to  compensate for lack of business resources’ availability by hiring external SMEs.  However these SMEs  also lack understanding of day to day operational practices in the asset and internal organizational dynamics.

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:

• Consistent top quartile production performance track record
• Strong change leadership
  
• Entrepreneurial organizational culture
  
• Modern  technology infrastructure closely aligning with  central- prescribed standard
  

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.

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.