From desktop tool to enterprise reservoir-planning platform

From a specialist’s desktop tool to an enterprise product

At the company’s digital transformation center, I led projects and products that grew out of employees’ ideas. Departments submitted proposals through an internal competition. Once approved, an expert’s solution needed to become a product available to employees with the appropriate permissions. The people behind these ideas included scientists, safety specialists and other subject-matter experts. I helped them take on the product owner role and work with agile delivery, while organizing development with large enterprise technology vendors. My responsibility covered the whole product, including the vendor’s work.

One project began with a desktop application independently written by a research-center employee. It helped specialists plan how to develop an oil or gas reservoir. The application ran calculations using a reservoir simulator and searched for the most economically viable option within specified constraints. It used a directed algorithmic search, not an exhaustive evaluation of every possible solution.

The tool made work faster and supported better-informed decisions. Most specialists involved in field development planning wanted to use it. But its distribution model prevented wider internal adoption: the application was shared as a file, behaved inconsistently across computers and had no centralized access controls. Bugs had to be fixed separately for each user.

There was also a risk to trade secrets: recipients could copy the file to external storage without authorization. Maintaining many separate copies as one enterprise product was difficult.

Together with the product owner and company architects, I reviewed these constraints and chose to move to a full web version. It would provide controlled access, centralized updates and fixes available to all users.

Building for corporate requirements

I planned the delivery stages and organized vendor selection. We first built a prototype and tested it with a limited group of users, then moved to an MVP. Even after removing nonessential features, the scope remained substantial: the original application effectively had to be rewritten for the web. The MVP therefore took considerable time, with development and validation progressing in stages.

A separate workstream addressed corporate requirements for information security, personal data handling and approved software. Restrictions on available software limited our choice of components and libraries to those permitted under corporate procurement and technology policies. Part of the product ran on servers using Astra Linux, a company-approved Linux server operating system. This was a new set of constraints for me, and I incorporated them into the product requirements and the vendor’s work.

The full version addressed the requirements of IT and other stakeholder departments. Separate files were replaced by a shared web system with permission-based access. Fixes no longer needed to be installed manually on every user’s computer: everyone used the same updated version.

Coordinating users and a team of 34

Internal enterprise products have small audiences compared with widely used consumer services. That does not make deployment simpler, but it changes how user needs can be studied: behavioral metrics alone do not provide enough evidence for reliable conclusions. I worked directly with users, bringing together small, focused groups to demonstrate the product and discuss workflows and feedback.

Developers received tasks through the vendor’s project manager. An analyst worked alongside that manager and also needed a deep understanding of the domain. I invited both to user meetings so they could ask questions directly. This gave the delivery team firsthand feedback rather than relying only on my summaries. I organized the meetings and coordinated the participants.

The product team reached 34 people at peak. Since I was also leading other products, I brought in two managers, delegated some of my work to them and managed their delivery. The product owner combined the project with a regular day job, so coordination remained my responsibility. This included aligning participants, making the case for the budget and resolving disagreements during development.

Production, rollout and continued development

I led the product from the initial idea through a prototype and MVP to a full web version in production. It was then rolled out to interested departments. In parallel, we developed the next version and adapted the product for departments working with other fields, whose needs required more substantial changes.

Alongside the internal rollout, preparations began to offer the product commercially to other oil producers.

Corporate requirements also covered documentation. I wrote it myself, without technical writers. Within the company, the project documentation was regarded as among the best, and the project was used as an example for other project and product managers.

By the time I left the company, the product had moved beyond its initial deployment. Development continued after my departure.

Other products at the digital transformation center

I also led other products that began as approved ideas from subject-matter experts. They addressed different problems and reached different stages.

• Collaborative field development planning platform. This brought together planning, approvals, documents and decision history. I took over early in the project and led it through production deployment and departmental onboarding.
• Geological core sample digitization. No ready-made solution met the company’s requirements. We worked with a machine-learning vendor that trained models on large datasets collected at the fields. The prototype improved digitization performance and provided a basis for assessing the project’s economics. A web-interface MVP followed, allowing the department to carry out digitization and giving specialists convenient access to the data they needed.
• Interactive industrial safety trainer. This product was designed to teach employees to recognize and resolve hazardous workplace situations. We reached the MVP stage. Measuring its impact was difficult: incidents were rare, and the effect of training on their frequency could only become apparent over several years.
• Digitizing historical maps with computer vision. The company had accumulated maps in different formats. We selected a machine-learning vendor, tested a prototype on several map types and assessed how much material was worth processing. After funding was secured, the vendor trained the models and digitized the agreed volume of maps.