Industrial & Manufacturing
›
Energy, Utilities & Sustainability
›
Grid Modernization & Distributed Energy
Grid Management Software
Long-cycle programs where regulation, capital, and grid reliability define the pace.
OSIsoft (AVEVA)
GE Vernova
Oracle Utilities
Itron
Inside this journey
-
Pre-Discovery
Align the room on outcomes, decision process, and constraints before deeper discovery.
-
Stakeholder Alignment
Confirm decision roles, timelines, regulatory constraints, and what ‘good’ looks like for each stakeholder.
Alignment Questions
Starting Together: Who’s Actually in the Room?
- Which people or roles from your organization will actively participate in decision-making for this program?
- For each person or role you listed, what is their single biggest objective or concern for this initiative? (Please name role and their primary objective)
- Who holds final capital approval and who signs off on long‑term vendor commitments?
- Who will act as the day‑to‑day program owner and primary point of contact for vendor coordination?
- Are there external stakeholders who must be involved (state PUC, ISOs/RTOs, DER aggregators, county emergency management)? Please list and explain their required level of involvement.
If Something Breaks, Who Will Be Held Responsible?
- When outages, compliance misses, or schedule overruns happen, which stakeholder historically bears the blame or political fallout?
- Tell the story of one recent incident where stakeholder misalignment caused delay, risk, or reputational harm—what happened, and who lost credibility?
- How long has this misalignment or friction been affecting projects like this in your organization?
- How do current KPIs, incentives, or budget rules push teams toward short-term cost savings rather than long-term reliability or resilience?
- When pushback emerges, what typically convinces reluctant stakeholders to change their position? (data, pilot results, regulatory pressure, executive mandate, vendor guarantees, other)
Timelines That Will Make or Break This
- If a regulatory deadline or a major reliability event forced action tomorrow, could your organization meet the needed milestones?
- What is your target go‑live window for an initial deployment, and why is that timing important?
- Which external or internal deadlines drive that timing (regulatory orders, grant milestones, rate cases, retirements of legacy systems)? Please list and attach dates if possible.
- What is your typical internal approval cycle for capital and contracts (time from initial business case to signed contract)?
- What’s the maximum schedule slip you can tolerate before the program becomes politically or operationally untenable?
Regulatory Red Lines and Hidden Constraints
- Which regulatory, compliance, or audit requirements would stop this project immediately if not explicitly satisfied?
- Are there scheduled audits, rate case filings, or compliance milestones during your planned timeline that we must coordinate around?
- What documentation, certification, or evidence will regulators or internal auditors insist on (e.g., change logs, cyber attestations, test results)?
- Do you have constraints about data residency, cloud vs on‑prem deployment, or vendor background checks for contractors?
- Has your organization previously failed an audit or faced enforcement around IT/OT projects? If yes, what were the pain points we must avoid?
What Would Make Each Person Say, ‘That’s a Win’?
- For operations, IT, cybersecurity, finance, and executives—name one measurable outcome each would point to as proof we delivered value (e.g., SAIDI reduction, faster restoration, audit pass, TCO reduction).
- Which single KPI would convince executive leadership that the investment was justified?
- What operational changes would frontline operators need to see to feel the system is genuinely easier and safer to use?
- What evidence would your cybersecurity team require before signing operational go‑live (e.g., penetration test, architecture review, NIST mapping)?
- Is there a stakeholder group whose success feels secondary today but could become critical later? Who are they and why?
Hidden Dependencies & Deal‑Breakers — Tell Me the Truth
- What’s one integration, contract clause, or legacy constraint you suspect could derail the program if we don’t address it up front?
- Which legacy systems or vendors are non‑negotiable to integrate with (SCADA vendor, OMS provider, AMI vendor, DER aggregator)? Please name systems and versions where possible.
- Do you have existing SLAs, warranties, or vendor lock‑ins that limit how we can modify operational architectures?
- How available are your OT/field crews and SMEs for cutover, testing, and rehearsals—do you expect capacity constraints?
- What single technical or organizational risk would cause you to pause negotiations until it’s resolved?
Decisions, Governance, and How We’ll Work Together
- If our teams disagree on a go/no‑go, which decision model would you trust the most to avoid paralysis?
- How frequently should governance checkpoints occur (steering committee, technical reviews, executive updates)?
- Who must have explicit veto rights for scope, security, or change control decisions?
- What change control and risk‑acceptance process do you expect us to follow (e.g., documented exceptions, joint risk register, sign‑off thresholds)?
- Which communication channels and cadences will make stakeholders feel informed without overwhelming them (email summaries, dashboard, weekly syncs)?
The Smallest Step That Builds Trust — What’s It Gonna Be?
- What is the smallest, fastest milestone that would materially reduce stakeholder anxiety and prove progress (e.g., integration demo, scoped pilot, security architecture review)?
- Would you be open to a time‑boxed pilot or PoC that focuses on one measurable outcome first? If yes, which outcome?
- Who must sign the mutual commitment to start that pilot, and what approvals (budget, security, legal) are required?
- Assuming the pilot meets its acceptance criteria, what is the expected decision window for moving to full deployment?
- What would make you say yes to the pilot within the next 30 days—what do we need to show or guarantee?
-
Current State Mapping
Document existing SCADA/EMS/OMS architectures, DER penetration impacts, failure modes, and integration gaps.
Current State
Start with a Straight Snapshot
- In one sentence, how would you describe the current state of your operational control systems and the single thing that worries you most?
- Which of the following systems are currently authoritative for real-time grid operations in your environment?
- Where are those core systems hosted today?
- Who is the primary day-to-day owner of these systems (select one)?
- Approximately how many substations, field devices (RTUs/IEDs), and DER endpoints currently feed telemetry into your operational stack? Please specify counts or ranges.
If We Keep Doing Nothing, What Breaks First?
- If DER penetration doubled in the next 12–24 months, how confident are you that your existing architecture would maintain safe, reliable control?
- Which DER types are material today and expected to grow fastest at your utility?
- How much real-time visibility and control do you currently have over DER resources (pick best match)?
- What protocols and data channels do your DERs and field devices primarily use today?
- Where do you see the biggest latency or data-quality gaps when DER events occur (e.g., meter-to-ops latency, missing fields, stale data)? Give specific examples if possible.
- And how long has your team been living with those visibility/control gaps?
Where the System Fractures When Stress Hits
- When the grid is under stress (storms, sudden DER swings, circuit faults), which part of your stack usually trips up operators first?
- Tell us about a recent incident where system behavior deviated from expectation—what happened and what was the immediate operational impact?
- How long does it typically take your team to detect and isolate such incidents from first sign to operator awareness?
- Which failure modes have you seen repeat (select all that apply)?
- When a failure happens, what is most frustrating emotionally for operators or engineers—fear of outages, blaming systems, lack of tools, or something else?
Who Really Decides—and What Keeps Them Up at Night
- If executive leadership had to sign off on a multi-million dollar control-system change tomorrow, what single unresolved issue would make them pause?
- Which stakeholders must be satisfied before a change moves forward (pick all that apply)?
- What regulatory or compliance milestones are critical to your roadmap (e.g., NERC CIP, state modernization orders, rate case timelines)?
- How risk-averse is your leadership when it comes to vendor-managed cloud services vs on-prem systems?
- Which measurable outcomes would comfort your decision-makers (examples: max control loop latency, percent of DERs under direct command, time-to-isolate), and which one matters most?
Where the Technical Gaps Hide (and Why They’re Hard to Notice)
- What critical integration did you assume would just 'work' but has repeatedly required manual fixes?
- Which middleware or data-normalization layers do you have in place (select all that apply)?
- How complete is your asset inventory and data model for control purposes (e.g., accurate naming, connectivity, device capabilities)?
- Where do data model mismatches create the biggest operational risk (e.g., breaker statuses, topology, DER capabilities)? Provide an example.
- What internal processes exist to onboard a new integration or DER fleet—who signs off and how long does it usually take?
What Success Looks Like in a Crisis
- Imagine a high-DER volatility event—what exact outcome would make you say the platform prevented an outage and justified the investment?
- Which of these operational metrics do you expect to move as a result of improved visibility/control (select all that apply)?
- What hard acceptance criteria would you require for a pilot to be considered successful (examples: control latency < X sec, DER compliance rate > Y%)?
- How quickly do you need to see those results in a pilot before recommending broader rollout?
- Who must sign the pilot success certificate (names or roles), and what approvals afterward are non-negotiable?
Practical Constraints and the Costs That Hide Under the Hood
- Which hidden cost surprises you most when modernizing operational systems?
- What are your typical maintenance and staffing constraints for supporting new operational capabilities?
- How much scheduled downtime per year can you realistically allocate for integration cutovers and tests?
- What internal budget or procurement constraints typically slow a project (e.g., capital approval cycles, procurement rules, vendor pre-qualifications)?
- Which cybersecurity or compliance controls will add unexpected scope to an integration (select all that apply)?
Small First Steps That Prove Big Value
- What is the smallest, lowest-risk pilot you would accept that, if successful, changes the budget conversation?
- What data access and permissions do we need to run that pilot (SCADA read, limited control, historical data export), and who grants them?
- How long would you permit a pilot to run before making a decision on scale (select one)?
- What operational or cybersecurity gates must be cleared before a pilot can even begin (examples: vulnerability scan, control authority paperwork, table-top exercise)?
- Who will be the day-to-day point of contact for a pilot and who has final sign-off to proceed to a broader rollout?
-
-
Outcome Discovery
Define target reliability, operational KPIs, cybersecurity requirements, and regulatory success signals.
Discovery Questions
Quick Check — Tell Us Where You Stand
- Who are you representing in this conversation (select one primary role)?
- In one short paragraph, describe your utility/system (service territory size, customer count, transmission vs distribution focus).
- Which of these best describes your current DER penetration at peak (approx % of peak load)?
- What are the top three outcomes you hope a new grid platform will deliver?
- Who else must be involved to make a decision (names or roles) and how do they prefer to be engaged?
If We Don’t Change, What Breaks First?
- When DERs increase, what single failure mode worries you most—and why would that failure be hard to fix with your current stack?
- Tell us about a recent operational incident that felt like a preview of the future grid—what happened, who noticed it first, and what was the root cause?
- How often are you seeing DER-driven events that require manual intervention (e.g., reverse power, voltage excursions, islanding)?
- Which reliability KPIs do you currently miss or are trending in the wrong direction (pick all that apply)?
- If you could change one operational habit today to avoid those failures, what would it be and what’s stopping you?
Hidden Constraints That Kill Projects
- What internal or external constraint do you think will surprise vendors and most derail a procurement or deployment effort?
- Which of these constraints apply to your program (select all that slow decisions or block pilots)?
- Describe the hardest integration point you’ve faced (SCADA historian, field device protocols, meter data, vendor API) and the timeline it actually took to resolve.
- How long does a typical vendor security assessment or legal review take before a PO can be issued?
- What single policy or legacy requirement would cause you to rule out a candidate solution outright?
What Would 'Reliable' Actually Feel Like?
- Imagine your control room six months after deployment—what observable change would make you say, 'This is working'?
- Which specific operational KPIs should we measure to prove reliability improvement (choose up to five)?
- What latency and determinism requirements do your control actions need to meet (telemetry, alarms, DER commands)?
- Which stress scenarios should a pilot demonstrate to convince operations (select all that apply)?
- How will operators and field crews know to trust automated actions—what visibility, rollback, or approval controls are required?
When Cybersecurity Isn’t Optional — Tell Us Your Bar
- If you had to draw a hard line today, what security requirement would instantly eliminate a solution (e.g., no remote vendor access, must meet NERC CIP baseline)?
- Which cybersecurity frameworks, standards, or audits must the platform align with for acceptance?
- What minimum technical controls are non-negotiable (pick all that apply)?
- Who owns SOC / 24x7 monitoring in your organization—internal team, MSSP, or vendor—and how would you like that responsibility split?
- How quickly must you be able to revoke vendor access or isolate a component if a compromise is suspected?
How Will Regulators Say You Won
- What regulatory outcomes or evidence would justify your investment in this platform to commissioners or governing boards?
- Which of these regulatory signals are most important for your filings or incentives (select up to three)?
- What types of deliverables do regulators expect from pilots (modeling reports, field test logs, third-party validation, customer impact analysis)?
- What timelines are you working against for regulatory filings or capital approvals?
- Who are the regulatory stakeholders we should brief and what concerns do they typically raise?
Small Bets to Build Confidence — What Would You Pilot?
- If you could run a focused pilot with minimal disruption, which scope would most accelerate your decision (pick one or combine)?
- What measurable acceptance criteria would make a pilot a clear success (name up to five concrete metrics)?
- Do you have the data and connectivity needed for a pilot (historian access, meter data, field device comms)?
- What training and operator change management would be required to accept automation from a pilot?
- Realistically, what budget range could you allocate to a 3–6 month pilot (ballpark)?
- What would be the fastest acceptable timeline from kick-off to pilot decision?
-
Solution Experience
Use customer scenarios to validate how the platform handles bidirectional flows, DER orchestration, and stress conditions.
Experience Meetings
- Solution Experience Pre-Read Alignment
- Scenario Walkthrough — Bidirectional Flows (Customer Feeder)
- DER Orchestration & Control Sequencing Workshop
- Stress Conditions — High DER Penetration & Failure Modes
- Validation Review & Acceptance Criteria Sign-off
- Measure platform performance vs agreed acceptance thresholds under stress.
- Prove the platform detects and represents bidirectional flows using customer data.
- Validate that control responses meet the customer's operational acceptance criteria.
- Collect explicit customer confirmations and list any functional or data gaps.
- Document any behavioral deviations and classify as bug, gap, or configuration.
- Owner to update scenario script and re-run schedule for any failed validation.
- Host to deliver a short report mapping demonstration steps to the customer's future-state outcomes.
- Restate Orchestration Objectives
- Validate orchestration logic meets deterministic expectations under both normal and contingency conditions.
- Ensure conflict resolution and priority rules behave as the customer requires.
- Agree on acceptance criteria and any required product/configuration changes.
- Update orchestration rule config per customer feedback and schedule patch or config change.
- Customer to provide any additional DER metadata or aggregation mappings needed.
- Host to produce an updated runbook excerpt showing operator steps for orchestration events.
- Test Plan & Roles
- Introductions & Objective
- Identify and prioritize any performance, stability, or functional failures.
- Agree remediation plan and retest schedule for any critical findings.
- Host to deliver test logs, dashboards, and a pass/fail matrix for each stress scenario.
- Assign engineering owners for each high-severity defect and set retest dates.
- Customer to confirm any regulatory reporting needs triggered by test results.
- Executive Summary of Test Outcomes
- Obtain customer sign-off on which acceptance criteria are met and which require remediation.
- Agree a prioritized remediation plan with owners and retest schedule for any failures.
- Confirm readiness items to transition to Solution Scope and Mutual Commit stages.
- Finalize acceptance criteria document with measured results and signatures.
- Publish remediation plan with owners, severity, and target completion dates.
- Prepare executive summary and recommendation for the Mutual Commit stage.
- Elicit and lock a one-sentence Current State that all stakeholders agree on.
- Quantify the consequences of the current state in operational and business terms.
- Define a one-sentence Future State outcome that will be the target of validation.
- Agree on concrete scenarios, success metrics, required datasets, and test environment readiness.
- Customer to deliver one-sentence Current State and consequence numbers (costs/risks) in writing.
- Customer to upload test datasets and provide test credentials/access to the sandbox environment.
- Host to prepare scenario scripts, success metric dashboard, and test runbook.
- Assign owners and finalize schedule for hands-on scenario sessions.
- Recap Objectives & Success Metrics
- Current State (one sentence)
- Stress Test A: Rapid PV Ramp & Reverse Flow
- Review Orchestration Ruleset from Customer
- Scenario Setup Review
- Acceptance Criteria Walkthrough
- Consequence Quantification
- Live Walkthrough: Detection & Visualization
- Risk, Security & Regulatory Implications
- Demo: Normal-condition Orchestration
- Stress Test B: Telemetry Storm / High Telemetry Rate
- Stress Test C: Comms Loss & Fallback
- Operational Readiness & Training Needs
- Demo: Contingency Orchestration & Conflict Resolution
- Live Walkthrough: Control Response
- Future State Outcome (one sentence)
- Mapping to Operator Workflow
- Tie Behavior Back to Consequences
- Scenario Selection & Mapping
- Metrics Review & Root-Cause Triage
- Decision & Next Steps
- Data, Integration & Environment Readiness
- Acceptance Criteria & Runbook Updates
- Validation Checkpoint
-
Solution Scope
Define modules (EMS, DMS, DERMS, OMS), integrations, deployment model, and measurable acceptance criteria.
Scope Configuration
- SCADA data ingestion connector deployment
- Field device protocol adapter deployment (IEC 61850/DNP3/Modbus)
- Real-time state estimator and model activation
- Automated FLISR sequence deployment
- Volt-VAR optimization control deployment
- DERMS aggregation and dispatch engine deployment
- Load and distributed generation forecast model deployment
- AMI/smart meter data integration and metering interface
- Outage management and crew-dispatch automation integration
- Cloud and hybrid platform provisioning
- Time-series data migration and replication setup
- Operator simulator training sessions for real-time ops
- Role-based access control and audit logging implementation
- NERC CIP–aligned patch management and endpoint hardening
Scope Questions
SCADA data ingestion connector deployment
- Which SCADA vendors/historians are currently in your environment?
- How many SCADA points/tags will be ingested initially (approx)?
- What is the required end-to-end latency for SCADA updates to the platform?
- Do you require hot-standby or high-availability ingestion connectors?
- Are there specific network segmentation or DMZ restrictions for SCADA connectivity?
- Describe any custom tag naming conventions, transformation rules, or derived signals required.
Field device protocol adapter deployment (IEC 61850/DNP3/Modbus)
- Which field protocols are present on your feeders/substations?
- How many field devices (RTUs/IEDs/relays) will require adapters?
- Do devices use secure transport (e.g., TLS, secure DNP3) or plaintext?
- Will adapters be deployed on-premise near the devices or centrally in the control center/cloud?
- Are there any custom protocol dialects, mapping tables, or vendor-specific profiles required?
- List any constrained network links, bandwidth limits, or latency constraints between field devices and adapters.
Real-time state estimator and model activation
- Do you currently run a real-time state estimator or powerflow model in operations?
- What network models are available for ingestion (CIM, PSS/E, Synergi, custom)?
- What is the geographic/single-bus area scope for initial model activation (e.g., one substation, feeder, service territory)?
- What update cadence and convergence SLA do you require for the state estimator?
- Are real-time telemetry sources (PMUs, SCADA points, smart meters) synchronized and time-stamped consistently?
- Describe any model validation, contingency analysis, or supervisory checks you require prior to activating models into control.
Automated FLISR sequence deployment
- Do you currently have functional FLISR sequences in your DMS/OMS or are you building them from scratch?
- Which devices/actions should FLISR sequences control (reclosers, sectionalizers, breakers)?
- What acceptable customer outage restoration time improvements are you targeting with FLISR?
- Do you require coordination with protection settings and relay vendor configurations during FLISR deployment?
- Is automatic operation allowed in production or only simulated and operator-approved?
- Provide any region-specific safety, regulatory, or operational constraints that must be enforced by FLISR sequences.
Volt-VAR optimization control deployment
- Which VVO control elements are available (OLTC, capacitor banks, voltage regulators, smart inverters)?
- What objective should VVO prioritize (loss reduction, voltage profile compliance, VAR balance, hosting capacity)?
- Do you have feeder-level voltage limits and regulatory bounds that the VVO must enforce?
- What cadence is expected for VVO decisions (seconds, minutes, hourly)?
- Are there customer-level constraints (e.g., selective voltage bands for critical customers) that VVO must respect?
- Describe telemetry availability (voltage/current points, inverter telemetry) required for VVO on target feeders.
DERMS aggregation and dispatch engine deployment
- What classes of DER assets must be supported initially (rooftop PV, community storage, EV charging, BESS)?
- Do DERs connect via DERMS-ready gateways, AMI, or third-party aggregators?
- What dispatch/use-cases are required (voltage support, peak shaving, islanding, frequency response)?
- Are there existing enrollment, telemetry, or telemetry latency SLAs for DER telemetry?
- What market or tariff signals (time-of-use, demand charge) must the DERMS incorporate for dispatch decisions?
- Describe security/credentialing model for DER device control and any certification requirements.
Load and distributed generation forecast model deployment
- Do you currently use load/solar forecasting models in production?
- What forecasting horizons are required (real-time seconds/minutes, intra-hour, day-ahead)?
- What input data sources are available (weather APIs, satellite irradiance, AMI, inverter telemetry)?
- What accuracy or error tolerance targets do you require (e.g., MAPE %) for forecasts?
- Do you require forecast model retraining cadence and on-site data pipelines for continuous learning?
- Are there internal data privacy or retention rules that govern meteorological or customer-derived inputs?
AMI/smart meter data integration and metering interface
- Which AMI vendor/communications stack is in use (Landis+Gyr, Sensus, Itron, Silver Spring, Custom)?
- What data cadence is required from meters (near-real-time, 5-min, 15-min, hourly)?
- Do you require meter-to-customer mapping, billing data reconciliation, or revenue-grade interfaces?
- Are there existing APIs, message brokers, or file-exchange processes for AMI integration?
- What scale of meters will be integrated initially (number of meters)?
- List any regulatory meter data retention or privacy constraints we must follow.
Outage management and crew-dispatch automation integration
- Do you currently use an OMS/crew dispatch system and which vendor?
- What level of automation is desired for trouble detection to crew assignment (automated ticketing, manual review)?
- Do you require integration with mobile workforce apps and real-time crew status tracking?
- What outage detection inputs will be used (AMI outage flags, SCADA alarms, customer calls)?
- Are there preferred SLA rules for outage prioritization (critical customers, service criticality tiers)?
- Describe any integration constraints with existing crew payroll, work planning, or asset management systems.
Cloud and hybrid platform provisioning
- Which deployment model do you prefer for production (on-prem, cloud, hybrid)?
- If cloud, which cloud provider(s) are allowed (AWS, Azure, GCP, other)?
- What compliance or data residency requirements affect where data and services are hosted?
- Do you require disaster recovery RPO/RTO targets and cross-region failover?
- Are there existing virtualization/container standards or IaC (Terraform/Ansible) preferences for provisioning?
- Describe network connectivity constraints (MPLS, VPN, SD-WAN) between sites and cloud.
-
Mutual Commit
Finalize commercial, security, and governance terms, and confirm capital approval and implementation triggers.
Agreement Modules
- Statement of Work (SOW)
- Master Services Agreement (MSA)
- Pricing & Commercial Terms
- Service Level Agreement (SLA)
- Security & Privacy Addendum
- Data Processing Agreement (DPA)
- Compliance Evidence & Audit Rights
- Acceptance Criteria & Final Sign-off
- Implementation Schedule & Milestones
- Capital Approval & Funding Trigger
- Governance & Steering Committee Charter
- Change Order Agreement
- Termination & Exit Plan
- Software Licensing & IP Agreement
- Source Code Escrow Agreement
- Training & Knowledge Transfer Plan
- Third-Party Procurement & Hardware Supply Agreement
- Insurance, Indemnity & Liability Schedule
- Regulatory Approvals & Permits Confirmation
-
Deployment
Operationalize rollout with readiness checks, enablement, and outcome validation.
-
Pre-Deployment Readiness
Confirm data migration plans, test environments, access, cybersecurity controls, and operational owners are in place.
Readiness Questions
Getting Comfortable With Going Live
- What is the single primary objective you want this deployment to achieve?
- What is your target go‑live quarter or date range?
- Who is sponsoring the deployment at the executive level, and who will be the single decision authority for go/no‑go?
- Thinking about past launches (if any), what emotion best describes how your team felt after cutover: relief, exhilaration, exhausted, anxious, or mixed?
- Is there anything—political, regulatory, or organizational—that would cause you to pause this deployment at the last minute?
What Could Trip Us Up on Day One?
- If something critical fails in the first 72 hours, who inside and outside your organization will be blamed or held accountable?
- Which parts of your current stack do you believe are highest‑risk during cutover (select up to three)?
- How often do you experience unplanned operational incidents that we should model during acceptance testing?
- When failures happen today, what manual steps does your operations team take that we must preserve or automate in cutover?
- Who outside your core team (vendor support, field crews, third‑party integrators) must be available during the first week, and what SLA do you expect from them?
Is Your Data Ready to Be Trusted?
- How confident are you that migrated data (topology, network models, meter mappings) will match what operators expect on day one?
- Which data sources are in scope for migration and reconciliation (check all that apply)?
- Do you have a single data owner for each source who can approve mappings and sign off reconciliations?
- Describe the reconciliation process we will use to validate migrated records—what samples, acceptance thresholds, and who signs off?
- Are there historical data quality issues (missing timestamps, incorrect phasing, meter drift) we must remediate before cutover?
- Which transformation rules or business logic are likely to change during migration (example: topology aggregation, DER aggregation rules)?
Who Will Actually Run This When It’s Live?
- If the operator console alerts at 02:00, who is the named owner who will take first action?
- Which teams must be trained and certified prior to cutover (select all that apply)?
- How many hours of hands‑on simulation or scenario training will your operators accept before they feel ready?
- Are there union, regulatory, or roster constraints that limit who can perform critical actions after cutover?
- What ongoing operational support model do you prefer post‑go‑live (vendor run, co‑managed, fully internal)?
- Tell us about a time your team solved an operational surprise—how did roles and decisions actually play out?
Can We Prove It Works Before We Flip the Switch?
- What would make your testing team say the system is “production‑ready” — and what have you seen vendors over‑promise on in tests before?
- Which kinds of acceptance tests are required by your governance (select all that apply)?
- How closely must the test environment mirror production for you to trust the results?
- What pass/fail thresholds do you require for critical tests (examples: failover <30s, FLISR isolation time <X, DER control response <Y)?
- Are you willing to conduct staged live stress tests (off‑peak) with vendor oversight before full cutover?
- Who must sign acceptance certificates for each test category, and what is your desired timeline for sign‑offs?
Locking Down Access and Cyber Confidence
- What would your security team point at as the single biggest unresolved risk that could block deployment?
- Which security frameworks or controls must we demonstrate alignment with before go‑live?
- What is your preferred model for operator and admin access (RBAC, role‑based with MFA, permanent service accounts, ephemeral certificates)?
- Have you completed or scheduled an independent penetration test or purple team exercise for the deployment stack?
- What incident response and forensics capabilities need to be in place on day one (logs, packet captures, playbooks)?
- Are there cross‑department SLAs for security incident escalation we must embed into the cutover plan?
Field Integration: Will the Grid Cooperate?
- If a local relay or RTU behaves differently than expected post‑cutover, do we have immediate fallback controls in place?
- Which field protocols and vendors are in scope for integration and testing (select all that apply)?
- Do field devices have firmware or certificate requirements that need staged updates before connecting to the new platform?
- How will you validate telemetry integrity from field to platform (sample rates, timestamp alignment, loss tolerance)?
- Which third‑party field teams must be physically present during cutover (vendor engineers, contractors, OEMs)?
- Are there geographic/seasonal constraints (storm season, planned outages) that affect which feeders we can cut over when?
Cutover Playbook and Rollback: Who's Got the Gloves On?
- If we need to stop and roll back mid‑cutover, what is the single go/no‑go trigger that will stop the switch?
- How long is an acceptable rollback window (time from detection to complete revert) for you?
- List the top five sequential actions in your ideal cutover runbook (owners, approximate durations, checkpoints).
- How many full dress rehearsals (complete runbook practice) do you want before the live cutover?
- What communications cadence and channels must be used during cutover (war room, mass notifications, NOC/ops bridge)?
- Who has the authority to call an immediate rollback and how will that be documented in the runbook?
Success Gates and Capital Triggers
- What hard metric or gate will stop capital or trigger the next phase if not achieved (examples: <X% DER control success, <Y sec failover)?
- Which approvals are required post‑acceptance to release remaining funds or move to the next contract milestone?
- How long of a stabilization window do you require post‑go‑live before declaring success?
- What KPIs will you measure during stabilization (select up to five)?
- Who will own the post‑go‑live issue backlog and enhancement requests, and how often should we meet to triage them?
- If success criteria aren’t met during the stabilization period, what remedial actions or governance steps do you expect?
-
Deployment Enablement
Schedule tasks, assign owners, run cutover rehearsals, and coordinate SCADA/field device integrations and support.
-
Validation Checklist
Execute acceptance tests for failover, FLISR/volt-var behavior, DER control, and NERC/NIST-aligned security validation.
Validation Questions
Setting the Table: Quick read on why we're validating
- Briefly, what triggered this validation phase for your program right now?
- Which of the following validation outcomes matter most to you today? (pick all that apply)
- Who will be the primary sponsor we check back with about validation decisions and tradeoffs?
- What is your target timeframe for completing the full validation checklist?
- Are there regulatory or board deadlines driving this date? If yes, please name them and the deadline.
Do we really trust our protection & failover logic?
- If a primary SCADA master fails during peak, what is your tolerance for recovery time (RTO) and data loss (RPO)?
- Which failover modes must we demonstrate during acceptance testing?
- Describe any historical failover incidents (what happened, how long to recover, root cause).
- Which monitoring and alerting signals would you consider a failed failover test?
- What maintenance windows or operational constraints limit when we can run disruptive failover tests?
When DERs push back: are our controls actually reliable under stress?
- Imagine a rapid cloud cover event with high rooftop PV—what DER behaviors have you seen that surprised operators?
- Which DER control modes must be validated end‑to‑end during acceptance?
- Do you require injected fault/stress scenarios (Hardware‑in‑the‑loop, field switching) or simulated scenarios only?
- How should DER vendor variability be handled if different device models respond differently during the same test?
- What operator behaviors during DER anomalies would you count as acceptable vs. concerning? (share examples)
Security: is compliance a checkbox or a compass?
- Which standards must the validation evidence map to for you to sign off?
- What level of evidence is required for each control test (artifact, test log, signed witness, third‑party attestation)?
- Are there specific cybersecurity tests you will insist on during validation (e.g., role‑based access, MFA, patching verification, secure key management)?
- If we uncover a security control gap during validation, what remediation SLAs do you expect before full acceptance?
- Who from your security team will be the point of contact and required approver for security evidence?
If this test fails, who pays the cost and who decides the next move?
- What is the financial or operational impact threshold that would force a roll‑back during validation?
- Do you have an agreed rollback plan and pre‑approved triggers for aborting a test? If yes, summarize them.
- Which stakeholders must be notified immediately if a test triggers a rollback (select all that apply)?
- How should impacted customers be handled in the event of an unintended service impact during validation?
- Describe any non‑negotiable safety or service constraints that would prevent certain test types.
Who’s actually running the tests — and who will own the outcomes?
- Which internal teams will be hands‑on during tests (pick all that apply)?
- Will you require Vendor/System integrator personnel in the control room for witness and remediation?
- Who has final sign‑off authority for each test category (operational, security, compliance, customer impact)? Please name roles.
- Do you want operator training/role play built into validation so staff demonstrate procedures during tests?
- How will we capture and timestamp operator decisions during tests (logs, recordings, witness forms)?
What success actually looks like — be specific
- For failover, what exact metrics must we hit for you to mark the test 'pass' (e.g., RTO, telemetry convergence, command latency)?
- For FLISR / VVO, what KPIs define acceptable behavior? (choose up to three)
- For DER control, which acceptance criteria are critical (select all that apply)?
- What level of test repeatability do you expect before accepting (single successful run, 3 consecutive runs, statistical confidence)?
- How should we present pass/fail evidence — executive summary, detailed runbooks, raw logs, or all of the above?
Running the tests: logistics, windows, and dependencies
- What test environments are available and designated for which tests (dev, staging, pilot, live with mitigations)?
- Which external dependencies must be scheduled or validated in advance (telemetry providers, DER vendors, third‑party comms links)?
- What pre‑validation checklist items must be completed before any disruptive test (backups, patch levels, spare hardware, comms checks)?
- What calendar constraints or seasonal restrictions affect when we can run tests (peak season, maintenance windows, regulatory blackout periods)?
- How should we coordinate live test notifications to field crews, ops, and customers (channels and lead time)?
After the smoke clears: remediation, lessons, and guarding the future
- If a test uncovers a defect, what remediation cadence do you expect (immediate patch, 2‑week fix, deferred backlog)?
- How do you want post‑test artifacts organized for audit and regulator review?
- What lessons‑learned process will you use to convert test findings into policy or config changes?
- Which recurring validation cadence would make you confident the system stays compliant and resilient over time?
- Are there KPIs or dashboards you want updated automatically after validation so executives see ongoing health?
Decision moment: what evidence do you need to greenlight deployment?
- What combination of test results, artifacts, and approvals will constitute your formal acceptance package?
- Does your organization require regulator or third‑party witness for final acceptance? If yes, name the party.
- What are your hard go/no‑go criteria (list the dealbreakers we must avoid)?
- Finally, are you comfortable committing to a validation schedule now, and if so what single week works best for a dry run?
-
-
Success
Review measured outcomes against success signals and maintain a shared channel for issues and enhancement requests.
Success Reviews
- Quarterly Success Metrics Review
- Operational Readiness & Handover Review
- Enhancement Prioritization & Roadmap Workshop
- Security & Compliance Post-Deployment Review
- Shared Channel Governance & SLA Kickoff
Issues & Enhancements
- Agree incident response cadence and next tabletop exercise date.
- Review Consolidated Enhancement Log
- Produce a prioritized enhancement backlog with clear business rationale for each item.
- Assign owners and tentative delivery windows tied to vendor release plans and customer budget cycles.
- Identify items requiring additional scoping or commercial decisions.
- Create prioritized backlog entries in the shared project tracker with business-impact notes.
- Assign PMs for top 3 roadmap items and schedule scoping sessions.
- Prepare cost/benefit briefs for any items needing capital approval.
- Security Test Results Summary
- Ensure all critical security findings have owners and remediation timelines.
- Confirm the system meets required NERC/NIST evidence standards or capture remediation steps.
- Welcome & Objectives
- Assign remediation owners for critical/high findings with target completion dates and verification plan.
- Publish compliance evidence package location and owner contacts for upcoming audits.
- Schedule next incident tabletop exercise and invite cross-functional attendees.
- Purpose & Scope of Shared Channel
- Establish a clear governance model and SLAs for the shared channel to manage expectations.
- Standardize submission templates to reduce triage time and improve data quality.
- Agree on reporting cadence and dashboard access for transparency.
- Provision the shared channel (Teams/Slack/Jira) with access lists and onboard participants.
- Publish the severity matrix, templates, and triage workflow to the channel and intranet.
- Set up automated weekly SLA and backlog reports and share with stakeholders.
- Verify which success signals are met and which are not with documented evidence.
- Quantify operational and regulatory consequences for any unmet signals.
- Assign owners, deadlines, and acceptance criteria for remediation actions or confirm formal acceptance.
- Owner-assigned remediation plan for each unmet signal with target close dates and KPIs to re-measure.
- Publish metric snapshot and meeting minutes to the shared channel within 48 hours.
- Schedule follow-up checkpoint meeting focused on top 3 gaps within 4 weeks.
- Operational Ownership Roster
- Confirm operational owners and ensure runbooks are complete and approved.
- Tune monitoring and alerting to reduce noise and ensure actionable notifications.
- Create a short training plan to address any operator competency gaps affecting outcomes.
- Finalize and publish updated runbooks with versioning and owner sign-offs.
- Adjust alert thresholds per agreed settings and document rationale.
- Schedule operator refresher workshop and record attendance.
- Severity Matrix & Routing Rules
- Open Findings & Remediation Status
- Recap Success Signals & Acceptance Criteria
- Runbook & SOP Review
- Business Impact Scoring
- Measured Outcomes Dashboard Walkthrough
- Submission Templates & Required Evidence
- Technical Feasibility & Effort Estimates
- Access, IAM & Segmentation Review
- Monitoring & Alerting Validation
- Gap Analysis: Where We Meet / Miss Targets
- Training & Competency Gaps
- Triage & Escalation Workflow
- Compliance Calendar & Audit Readiness
- Prioritization & Roadmap Mapping
- Reporting Cadence & KPIs
- Risk & Consequence Discussion
- Decision & Funding Triggers
- Incident Escalation & Postmortem Process
- Incident Response & Notification Procedures
- Decision & Next Steps