Every major utility transformation begins with lists. There is a list of requirements, a list of processes, a list of integrations, a list of risks, and eventually an expanding collection of decisions, dependencies, interfaces, reports, roles, and deliverables. Considerable effort goes into making these lists complete because completeness creates confidence. If the requirements have been captured, the risks documented, and the decisions approved, the program can reasonably conclude that it understands what it is building.
There is, however, another list that rarely appears in the program plan. It contains the questions nobody asked because nobody knew there was a question to ask. It contains capabilities the business did not request because it did not know they existed, operational consequences that were invisible during design, assumptions inherited from the current environment, and decisions that appeared entirely sensible until someone with a different kind of experience looked at them.
Call it the fourth list: what the transformation team does not know it does not know.
For utilities undertaking large SAP S/4HANA, Enterprise Asset Management (EAM), GIS, mobile, work management, and broader operational transformations, this may be one of the most consequential sources of risk in the entire program. And unlike many transformation risks, it does not necessarily appear on a risk register.
The Problem With a Risk You Cannot See
The idea of the “unknown unknown” is not new, but its implications for transformation are easy to underestimate. Research published by the Project Management Institute on unidentified project risks makes an important distinction: many risks that initially appear impossible to identify are not actually unknowable. They simply have not yet been discovered. The practical objective, therefore, is not to predict everything. It is to convert as many unknown unknowns as possible into known unknowns early enough that they can still be managed.
That distinction matters enormously in a utility transformation because the cost of discovery changes over time. A question discovered during design may require a conversation. The same question discovered after configuration may require rework. Discovered during testing, it may affect interfaces, scripts, training, data, and schedules. Discovered after go-live, it may become an operational problem affecting thousands of employees and potentially millions of assets.
Consider a future-state maintenance design workshop. The process has been documented carefully. The diagrams are polished. Business representatives are in the room. The implementation team understands the technology. The proposed design follows accepted practices, known requirements have been addressed, and several important exceptions have been discussed. After a productive conversation, the process is approved.
There may still be a problem. Nobody asked what happens when a crew arrives at a remote location with limited connectivity and discovers that the physical asset does not match the asset record. Nobody follows the scenario through what happens when the material requirement changes, one operation can be completed but another cannot, and the resulting information needs to move correctly through work management, inventory, GIS, scheduling, finance, mobile applications, and the asset record itself.
This omission does not necessarily mean the team performed poorly. The utility may have brought its best people. The systems integrator may have followed a disciplined methodology. Every question on the agenda may have been answered.
The question simply was not on the agenda.
Transformation programs are generally very good at organizing known complexity. Requirements workshops identify needs. Fit-to-standard sessions identify gaps. Architecture reviews identify dependencies. Risk registers identify threats. Testing identifies defects. Governance processes escalate decisions. These mechanisms are essential, but they share an important limitation: they are considerably better at managing what has already been identified than discovering what nobody has thought to identify.
That is where experience begins to matter in a very different way.
Requirements Describe the World You Already Understand
Requirements gathering is one of the foundations of enterprise transformation, but requirements have an inherent bias toward the present. When people are asked what they need, they naturally describe the world they know: existing processes, existing frustrations, existing reports, existing exceptions, and existing workarounds.
A maintenance organization will explain how maintenance is performed today. A planner will describe the information needed to plan work. A dispatcher will describe scheduling constraints. A field employee will identify frustrations with the current mobile experience. IT will identify integrations and technical dependencies. The resulting requirements may be extraordinarily detailed and entirely accurate.
Yet accuracy is not the same as completeness.
The customer can only request capabilities it knows enough to imagine. The implementation partner, meanwhile, interprets those requests through the technology, implementation patterns, methodologies, and project experiences it knows. The result can be an extremely competent conversation between two groups that nevertheless leaves important territory unexplored.
That territory exists between how the organization operates today, what the technology is capable of today, and how the organization could operate tomorrow.
At AlphaOak, we have previously described a related problem as the “white space” of utility transformation: the handoffs, dependencies, and operational blind spots that exist between systems and organizational boundaries. The unknown-unknown problem goes one step further. Sometimes the gap is not simply something nobody owns. Sometimes nobody has recognized that the gap exists.
That is precisely where transformation should be happening.
If a program simply documents the current operating model and recreates it in newer technology, it may modernize the platform without meaningfully transforming the business. Conversely, if it applies generic best practices without sufficient appreciation for utility operating reality, it can produce an elegant system that performs poorly when exposed to actual field conditions.
We explored that tension in From Fit-to-Standard to Fit-for-Reality: SAP in the Utility World. The principles behind Fit-to-Standard and Clean Core are important precisely because utilities need sustainable architectures rather than another generation of deeply customized environments. But standardization cannot become an excuse for failing to interrogate operating reality. A process can be technically standard and still be operationally wrong.
The harder question, therefore, is not simply, “How should SAP support this requirement?” It is: “What should this utility now be capable of doing that it could not reasonably do before?”
That is a fundamentally different transformation question.
Expertise Is Not Merely Knowing the Answer
Organizations often evaluate transformation expertise by asking whether someone knows SAP, EAM, GIS, scheduling, mobile, asset management, integration, or utility operations. Those capabilities clearly matter. But one of the most valuable characteristics of expertise is harder to capture in a résumé, methodology, or resource plan.
Experts know where to look for problems.
An experienced utility operator can hear an apparently minor process decision and immediately think about storm restoration. A scheduler may recognize that a seemingly reasonable maintenance rule will create an entirely different problem in the backlog six months later. A GIS specialist may hear a discussion about asset attributes and ask which system actually owns the information. A finance specialist may hear “simple work-order change” and immediately consider settlement, capitalization, or cost allocation.
A maintenance expert may recognize that a process that works elegantly for a plant becomes impractical when applied to hundreds of thousands or millions of geographically distributed assets. A field technician may look at a perfectly designed mobile workflow and ask whether anyone has attempted to execute it outside, in poor weather, with gloves on, under time pressure, and with inconsistent connectivity.
None of these people necessarily understands the entire transformation better than everyone else in the room. They simply see consequences that others cannot see from where they are standing.
This is one of the underappreciated forms of value that experience brings to transformation. Experience does not merely provide more answers. It produces better questions.
Reasonable Assumptions Create Expensive Problems
The most damaging transformation decisions rarely begin with obviously bad ideas. More often, they begin with perfectly reasonable statements: the standard process should handle it; that exception does not happen very often; we can resolve the data issue during conversion; the business will adapt; reporting can come later; SAP should own that; GIS should own that; we do not need to design for that yet; we can solve it after go-live.
Any one of those statements may be correct. The risk is whether the organization has enough knowledge in the room to recognize the occasions when it is not.
A seemingly small assumption made during design can travel surprisingly far through an enterprise architecture. It may affect master data, integrations, mobile execution, planning, scheduling, analytics, controls, reporting, or downstream financial processes. By the time the consequence becomes visible, the original assumption may be buried underneath configuration, interfaces, training materials, testing scripts, and organizational decisions. At that point, what would have been a productive question six months earlier becomes a change request.
This is not simply a theoretical project-management concern. McKinsey’s work on complex, large-scale transformations specifically emphasizes the need for mechanisms that anticipate hurdles and enable course correction, including formal program reviews and premortem exercises. The underlying idea is deceptively simple: sophisticated organizations should not wait for problems to become visible before creating the conditions to discover them.
For a utility transformation, this changes an important governance question. Leadership should not limit itself to asking whether all known questions have been answered. It should also ask: How confident are we that we have asked the right questions?
Those are not the same test.
How Do You Find Something You Do Not Know Exists?
It is impossible to eliminate unknown unknowns from a complex utility transformation. Utilities are too interconnected, operating environments are too varied, and enterprise systems contain too many dependencies to anticipate every consequence. In fact, PMI’s research into complexity has long recognized that as project complexity increases, interactions between elements and participants can create increasingly difficult-to-predict outcomes.
The goal should therefore not be perfect foresight. The goal should be to create a transformation program that is unusually good at discovering its own blind spots.
One way to do this is to deliberately introduce productive friction into important decisions. Before a significant future-state process, architecture choice, or scope decision is approved, the program should examine it through multiple perspectives rather than simply verifying that it satisfies documented requirements. Ask what happens when the process reaches the field. Ask what happens during the exception rather than the happy path. Ask who owns the information at every stage of its lifecycle. Ask where the consequences appear if the underlying assumption turns out to be wrong.
Scale deserves the same examination. A design that works perfectly for 100 assets, 20 planners, or 1,000 work orders may behave very differently across a large utility operating environment. So does the future-state perspective. Is the organization making a decision because it represents the best future operating model, or because years of working around limitations in the existing environment have made that constraint feel permanent?
Finally, demand evidence. Has the proposed process actually been demonstrated from beginning to end, including the difficult scenarios, or has everyone agreed to a diagram?
This is also where AlphaOak’s earlier argument about designing for the spaces between systems becomes important. A work order may appear to belong to SAP. A map may appear to belong to GIS. Scheduling may have another home and mobile execution another. But the utility employee performing the work experiences none of those as independent systems. They experience one process. Looking at that process end-to-end is often what exposes the questions that application-by-application design misses.
These questions do not represent another layer of requirements. They are a way of interrogating the requirements that already exist. Sometimes that interrogation confirms the design. Sometimes one question changes it entirely.
Ask Your Systems Integrator a Different Kind of Question
Utility executives have become increasingly sophisticated about the questions they ask systems integrators. They ask about experience, methodology, staffing, accelerators, Clean Core, integration, data, testing, change management, and increasingly AI. These are appropriate questions, but they still tend to focus on what the customer already knows it needs to evaluate.
There is another question worth asking: “What aren’t we asking you that you think we should be?”
A good answer should not be “nothing.” Push further. Ask what other utilities discovered too late. Ask which assumption in the current design makes the team uncomfortable. Ask where similar designs have broken under real operating conditions. Ask what the utility is requesting that the implementation team would challenge if it were their own organization. Ask what capabilities exist that the business requirements suggest the organization may not know about.
Then ask perhaps the most revealing question of all: “If we called you two years after go-live and said, ‘We wish somebody had told us this during design,’ what do you think ‘this’ would be?”
The answer may reveal more about the depth of the team than another presentation of credentials ever could.
It is also a natural extension of a question AlphaOak has raised before about how utilities should evaluate the partners responsible for transformation. Selecting an SI is not merely a test of whether a firm can answer today’s RFP. It is a test of whether the people sitting across the table possess enough experience, curiosity, and conviction to identify tomorrow’s problem before the customer knows to ask about it.
Your SI Should Not Be the Only Source of Challenge
There is also a structural issue worth acknowledging. In many large transformations, the organization responsible for implementing the solution plays a significant role in helping the customer determine what the solution should be.
That is not inherently problematic. Strong systems integrators challenge their customers constantly, and experienced implementation teams can provide enormous value. But utility leaders should recognize that no single organization, methodology, or group of experts is likely to see every dimension of a transformation.
The practical response is not more bureaucracy. It is greater diversity of perspective. Bring operators into architecture discussions. Bring field employees into design earlier than feels necessary. Allow maintenance to challenge IT and IT to challenge maintenance. Let GIS challenge SAP assumptions and SAP practitioners challenge GIS assumptions. Let finance follow operational decisions downstream. Bring experienced utility practitioners into conversations where generic industry practices are being proposed.
For the highest-consequence decisions, there is also value in independent challenge: people whose responsibility is to represent the utility’s interests rather than simply deliver implementation scope. AlphaOak’s broader Enterprise Integration and Transformation approach is built around a similar premise: successful transformation depends on what happens across field operations, finance, planning, technology, and the handoffs between them, rather than simply whether individual applications have been configured correctly.
The objective is not to create more opinions. It is to create more angles of observation. Blind spots become considerably harder to maintain when knowledgeable people are looking at the same decision from different directions.
Create the Fourth List
Most utility transformation programs already maintain some combination of a requirements register, decision log, risk register, issue log, and dependency tracker. Perhaps they need one more: a “What We Might Be Missing” register.
Its purpose should be fundamentally different from a conventional risk register. A risk register usually documents something the organization already knows could happen. The fourth list should capture uncertainty that has not yet matured enough to become a defined risk. This is consistent with the insight from PMI’s research on unknown unknowns: identifying an uncertainty changes its nature. Once the unknown becomes visible, the organization can begin to investigate, quantify, test, mitigate, or consciously accept it.
Put uncomfortable questions there. Put unverified assumptions there. Put areas where experienced people disagree. Put processes that have never been demonstrated end-to-end. Put dependencies that appear suspiciously simple. Put decisions being justified primarily because “that is how it is usually done.”
Pay particular attention whenever a transformation conversation contains words such as should, probably, typically, standard, or we’ll figure that out later. Those words are not evidence that something is wrong. They are signals that something may deserve another question.
Most importantly, do not require every entry on the fourth list to arrive with an answer. Doing so defeats its purpose. Some uncertainty needs to remain visible long enough for the right person, scenario, prototype, or piece of evidence to resolve it. The objective is to acknowledge uncertainty before uncertainty becomes architecture.
The Question Behind the Questions
There will always be things a utility does not know at the beginning of an SAP or EAM transformation. That is not a failure of preparation. It is the natural condition of undertaking something sufficiently complex and consequential to deserve the word transformation.
The more dangerous assumption is believing that enough workshops, requirements, experienced consultants, and governance meetings can make those unknowns disappear. They cannot. What a strong transformation program can do is develop the institutional habit of searching for them.
That changes the role of expertise. The best transformation partners are not simply the people who arrive with the largest collection of answers. They are the people who recognize when an apparently settled conversation deserves another question. They know where similar programs have discovered problems before. They understand the connections between decisions that appear unrelated. They can distinguish a genuine requirement from a historical constraint, and a best practice from a convenient default.
For utility leaders, that may ultimately be the more useful way to think about transformation risk. The question is not whether your program has unknowns. It does. The question is whether the people, governance, and operating model around the transformation are capable of finding enough of them while they are still inexpensive to address.
Because there is something considerably more expensive than discovering that you do not know the answer.
It is discovering, eighteen months into the program, that you never knew there was a question.