Several years ago, while working as an IT Manager for an oilfield services company specializing in well cementing in Venezuela, I participated in migrating our ERP system from Macola to SAP. I served on the development committee and acted as a liaison between the business, stakeholders, and the SAP consulting team. Venezuela served as the pilot implementation site, followed by a rollout to four other countries.
The project involved a vast number of tasks and subtasks, and Excel was our primary tool for planning and tracking. According to the data recorded in the spreadsheets, everything appeared to be progressing normally. However, minor deviations were occurring; as they accumulated, they ultimately resulted in a delay of nearly 30 days.
The most concerning aspect wasn’t just the delay itself. No one could clearly explain why it was happening, and there was no single, go-to source of information to reconstruct what happened.
After several meetings and detailed reviews, we discovered that the delay hadn’t been caused by a single major failure. Instead, it stemmed from a series of small issues: poor communication between an ABAP developer and stakeholders, missing information that hadn’t been provided, meetings where decisions went unrecorded, and a specialized resource being shared across multiple projects.
By the time we finally connected all these dots, the problem had grown significantly and was already having financial repercussions for the project.
We escalated the situation to company management and stakeholders. Approval was granted to hire a new ABAP developer, as the existing resource lacked the capacity to handle all the projects to which it was entrusted to. After onboarding the new developer, we adjusted the schedule, and the team managed to catch up on the backlog in less than ten days.
This experience taught me that we were capable of solving the problem—what had actually failed was our ability to detect it in time and understand how it had originated.
From that point on, we began keeping notes—however brief—and established weekly follow-up meetings. We continued using Excel, but the discipline we adopted allowed us to get the work back on track and successfully complete the project.
Excel remained a useful tool. It could record who was responsible for a task, its completion date, and the reported percentage of progress. However, on its own, it could not preserve the context of decisions, show how a dependency affected other activities, confirm the actual availability of resources, or explain why the project’s status was changing.
Those managing a project do not always have access to the full picture. Problems usually begin with small situations that quietly accumulate: a meeting ends without a record of what was agreed upon; someone requests information and receives no reply; later on, no one remembers why a specific decision was made. A task appears to be completed, yet there is no verifiable evidence of the result. Or a key resource is overloaded, and the project manager cannot identify where the bottleneck is forming. Viewed in isolation, these situations might seem insignificant, but when analyzed together, they reveal that the project is beginning to encounter friction in its execution.
This entire experience subsequently influenced how I developed ProjectOps360. Yet, the platform also originated from a more personal motivation. While completing my training in project management, I was looking for a practical way to consolidate my knowledge and apply every concept I had learned. My background in process mining also influenced the development of “Living Graph” and the intelligence processing capabilities built into the platform.
A clear design concept emerged from those experiences: capture context before it vanishes, link every event to the dependencies it might affect, identify friction before it causes a milestone to be missed, and explain every finding through verifiable evidence.
Artificial intelligence should not be limited to simply replicating the color displayed on a dashboard. Its true value lies in helping leaders understand why an indicator is changing and what evidence supports that alert. A “red” status should confirm a risk that could already have been identified through interconnected signals; it should not serve as the first warning that a project is in trouble.
A project does not go off track overnight. Long before a dashboard displays an alert, the work itself is already generating signals within tasks, meetings, decisions, dependencies, and resource utilization. The challenge lies in connecting these signals while there is still time to take action.
Efrain Prada is the founder and software architect of ProjectOps360. His career in technology began well before the current AI boom and spans software development, database development, data analysis, and business intelligence. He also possesses experience in project management, SAP implementations, and business process mining.
