SKM Training: A Workflow Investment, Not a Software Fix

On the project screen, the fault looks like duplicated work: you run short-circuit and arc-flash calculations in SKM, then leave the software for load studies, coordination, and voltage-drop calculations. You have two years of operating experience, but you still do not trust parts of the workflow. That is not automatically a software limitation. It is a process gap that training may close.

Start here. Measure whether the gap costs enough engineering time, review effort, or rework to justify formal training. The training fee alone is not the decision; for an A/E firm, time away from billable work can be the larger expense.

Check Which Workflows Stop at SKM

List the calculations used on a typical commercial or industrial distribution project. Record where each calculation starts, where it finishes, and why you switch tools.

Symptom	Likely cause to test	Next check
Short-circuit and arc-flash work stays in SKM, but other studies do not	Your team has a narrow established workflow or limited confidence outside familiar functions	Identify the exact task, input, or result that causes the switch
Load studies are completed by hand	The manual method is trusted, while the equivalent software workflow has not been validated internally	Compare one completed project calculation with an SKM model
Coordination work moves to another application	The alternate tool may be faster, better understood, or embedded in the review process	Measure total time and review effort in both workflows
Voltage-drop calculations are repeated outside the model	Required model data may be incomplete, or the team may not know how to extract a trusted result	Trace the input data and calculation basis in both methods
Experienced users still expect another engineer to perform the calculations	Knowledge is concentrated in one person rather than documented in a repeatable method	Measure handoff, checking, and correction time

If SKM lacks a required capability, training will not create it. Confirm the required calculation exists in the software and in the company’s licensed configuration before building the business case around it. If the capability exists but nobody can execute or review it confidently, continue to the utilization check.

Measure the Utilization Gap

Do not argue that the software feels underused. Convert underuse into a list of blocked engineering tasks.

1. Select several recently completed projects representative of new construction and renovation work.
2. For each project, record which calculations used SKM and which used hand methods or other software.
3. Record the reason for every tool change: missing knowledge, missing model data, client format, reviewer preference, software capability, or license limitation.
4. Separate calculation time from data-entry, checking, correction, and report-production time.
5. Mark tasks that could reuse the same electrical model instead of rebuilding the system elsewhere.

The important reading is not the number of software functions you have never opened. It is the number of project hours attached to repeatable tasks that training could bring into a controlled workflow.

If most tool changes are caused by client requirements or unavailable functions, formal training has a weak return. If the changes come from uncertainty about setup, interpretation, or reporting, training targets the real constraint.

Check Whether Training Solves the Actual Constraint

Compare the training coverage with the blocked-task list. Ask for course objectives or an agenda through the manufacturer’s official channel. Look for direct coverage of the calculations you currently avoid: load studies, coordination, voltage drop, or other work that your projects require.

Previous software use does not make the course redundant. An experienced operator may already know introductory material but still gain faster operating methods, better result interpretation, and exposure to alternative problem-solving workflows. The decision depends on whether those gains apply to recurring billable tasks.

Use this branch:

• If the course covers the blocked workflows, estimate the recoverable time.
• If it covers mostly functions already used confidently, request a more advanced course or a focused syllabus.
• If the course content cannot be mapped to active project work, do not justify it through vague professional development claims.
• If the obstacle is internal review acceptance, add reviewer participation or a post-training validation exercise. Sending only the operator may leave the approval bottleneck untouched.

Buying another application before testing the licensed SKM capability can add duplicate data entry without removing the knowledge gap. Rebuilding the same system in several tools also creates opportunities for inconsistent conductor, equipment, source, and protective-device data.

Calculate the Full Training Cost

Build the cost case from company numbers. Include tuition, travel, lodging, and the loaded labor cost of attendance. Then account for billable capacity that cannot be recovered while the engineer is away.

Use two views because management may evaluate labor differently:

Direct training cost = tuition + travel + lodging + other attendance expenses

Internal cost = direct training cost + attendee hours × loaded labor rate

Capacity exposure = attendee billable hours displaced × applicable billing rate

Do not add internal labor cost and full lost revenue blindly. They answer different questions and may double-count the same time in a company’s decision model. Ask management which measure it uses for training approvals.

Calculate the break-even workload with labeled company assumptions:

Break-even projects = approved training cost basis ÷ expected net savings per project

Expected net savings per project =
(time saved in calculation + time saved in data transfer + time saved in checking
+ expected rework reduction) × applicable internal value of time

Use a conservative savings estimate from a pilot comparison. Do not claim that every available function will save time. Count only recurring work that the course covers and the team plans to adopt.

Test One Project Before Requesting Approval

A small benchmark turns the request into an engineering proposal. Use a completed project so the accepted answers are already available and no live deliverable depends on an unfamiliar method.

1. Choose one calculation currently completed by hand or in another application.
2. Record the existing workflow time, including model preparation, calculation, checking, corrections, and report formatting.
3. Reproduce the calculation in SKM using the same engineering inputs and documented assumptions.
4. Compare inputs first. A matching final number can hide different equipment data, operating conditions, or calculation bases.
5. Resolve material differences before comparing elapsed time.
6. Document the step where knowledge ran out: model setup, calculation execution, result interpretation, or report production.

If the SKM result cannot be reconciled with the accepted calculation, that is a training objective, not proof that the software is wrong. If the result reconciles but the workflow remains slower, determine whether the delay comes from first-use learning, incomplete model data, or a task that is genuinely more efficient in the existing tool.

Do not use a live deadline as the first benchmark. Schedule pressure encourages operators to bypass validation and then blame the application or the course.

Build the Approval Case Around Deliverables

Present management with a short list of outcomes rather than a request to learn more features.

• Calculations proposed for migration into SKM
• Current annual or project-based hours for those calculations
• Expected savings supported by the benchmark
• Course topics mapped to each blocked step
• Total attendance cost and displaced billable time
• Break-even number of projects
• Post-training deliverables and review owner

Professional-engineer continuing education can strengthen the case when the course provides acceptable continuing-education credit and the attendee needs those hours. Verify the course documentation and the applicable licensing requirements before assigning financial value to the credit. Credit does not replace the productivity case, but it can satisfy two business needs with one absence.

Set deliverables before attendance. Good deliverables include a validated calculation example, an internal workflow checklist, a report template, and a short knowledge-transfer session for designers and reviewers. These items keep the acquired knowledge from remaining with one operator.

Complete the Training and Verify the Return

Use the first suitable completed or low-risk project as the controlled implementation branch.

1. Repeat the pre-training benchmark with the trained workflow.
2. Verify that source data, system configuration, assumptions, and study boundaries match the accepted calculation.
3. Compare intermediate results, not only the final report value.
4. Have a qualified reviewer check the model and calculation method before adopting the workflow for routine deliverables.
5. Record total elapsed time, corrections, handoffs, and duplicate data entry.
6. Update the internal checklist with the validated sequence and required review points.
7. Recalculate the break-even estimate using measured post-training time.

A successful result is not simply opening more software modules. You need reconciled calculations, a repeatable procedure, reviewer acceptance, and a measurable reduction in total project effort. If the course improves operating speed but does not resolve result interpretation, schedule a focused internal review before expanding the workflow.

FAQ