Choose a first use case that can earn a second

There are more plausible AI opportunities than any utility can pursue at once. The first choice should create useful evidence about what works in your organization. It should also leave behind something reusable: a trusted document collection, connected asset identities, or a dependable review process.

Begin with a specific task. “AI for engineering” is a theme. “Help engineers find inspection records for a selected asset and flag conflicting attributes” is a workflow that can be tested.

Build a shortlist from everyday friction

Ask practitioners which repeated tasks involve searching, reconciling, copying, classifying, or drafting. Look for work with enough frequency to measure and enough consistency to compare before and after.

The source workbook offers candidates such as representative assistance, filing consistency checks, application validation, asset record reconciliation, and inspection status review. Treat these as possibilities. Their value and difficulty depend on your utility’s actual process.

For each candidate, write down the trigger, inputs, proposed output, approving person, destination system, and expected outcome. If those cannot be described clearly, spend more time understanding the work before buying or building a solution.

Assess three dimensions separately

Value: How much friction or risk does the workflow create today? Estimate task volume, active effort, rework, customer impact, and delay. Ask the owner what would change if the task became easier. A shorter task matters less if another bottleneck still determines the outcome.

Feasibility: Are the essential records accessible? Can you identify correct outputs? Will a practitioner help evaluate them? Is there a practical way to integrate the result into daily work? Include review effort and source maintenance; these are part of the system.

Consequences: What happens when the system is wrong or unavailable? Consider safety, service, customer fairness, confidential information, and financial effects. Ask whether mistakes are visible and reversible before they cause harm.

Do not hide these dimensions inside one impressive score. A high-value task with serious consequences can belong on the roadmap while a more bounded workflow provides the first implementation experience.

Compare candidates with a simple worksheet

Question	Strong starting evidence	Reason to narrow the scope
Who owns the result?	A named manager and active practitioners	Interest without operating ownership
Can we measure the current process?	Real examples, volume, and effort data	Benefits described only in broad terms
Can we judge correctness?	Review criteria and representative cases	No reliable basis for accepting output
Are sources usable?	Accessible records with known owners	Essential information is unavailable
Can errors be contained?	Review, clear limits, and fallback	Unreviewed consequential actions
Will people use it?	A natural place in existing work	An additional destination with duplicate entry

Use a low, medium, or high rating for each dimension, with a short explanation and an evidence link. The conversation behind the rating is more useful than numerical precision.

Make the first scope smaller than the ambition

Consider three illustrative options. A document assistant could retrieve approved procedures and show supporting passages. A data assistant could propose matches for one asset class. A storm planning assistant could prepare scenario information for qualified planners.

Each can grow, but they require different evidence and controls. A procedure assistant must manage document versions and access. Asset matching needs a trustworthy review sample. Storm planning needs validated inputs, uncertainty treatment, and a clear separation between support and operational authority.

The best first choice is the one your team can own, evaluate, and operate responsibly. That may be a sophisticated task if the necessary foundation already exists.

Define the decision before the pilot

Write acceptance criteria covering output quality, total effort, user adoption, operating cost, and failure handling. Choose the conditions that lead to expansion, revision, or stopping. Include examples where the system should abstain or escalate.

Reserve evaluation cases the builders have not used for tuning. Ask reviewers to assess the full result, including source correctness and downstream usability. Avoid declaring success because a demonstration handled a few familiar examples.

Once a candidate is selected, use the 90-day roadmap to organize the work. Keep the longer opportunity list visible, but give the first workflow enough attention to produce an honest result.