Energy Competency Frameworks: Building Skills for Energy Teams
An energy competency framework gives a team a shared way to describe the skills needed to plan, evaluate, approve, and implement energy projects. Rather than starting with a list of courses, leaders can start with the work: what decisions are made, who contributes, what capability each task requires, and what evidence shows that someone can do it. The result can guide hiring, project assignments, coaching, and training without pretending that every team member needs the same expertise.
What does an energy competency framework do?
A competency framework is a practical description of capability connected to responsibilities. In energy management, it can cover technical understanding, data use, project economics, communication, approvals, contract awareness, and follow-through. Its purpose is not to create impressive labels. It helps people understand the work expected of a role and helps managers decide what support will make the work more reliable.
Three elements need to line up:
- Work:
the task, decision, or handoff the organization needs, such as checking energy data, comparing project options, or explaining an approval request.
- Role:
the person or group that performs, reviews, approves, or contributes to the task.
- Capability:
the knowledge, skill, judgment, and work habits needed to complete the task at the expected level.
For instance, an engineer may prepare assumptions for a project analysis, an operations representative may confirm schedules and constraints, and a finance reviewer may challenge the cash-flow assumptions. All three contribute to a sound decision, but their competencies are not identical. A framework makes those boundaries visible and reduces the risk of treating a complex project as the responsibility of one generic “energy expert.”
Think of the framework as an operating aid, not as a new layer of bureaucracy. It can be a few pages or a well-organized spreadsheet. If it takes more effort to maintain than it saves in unclear assignments, duplicated work, or avoidable learning, it is too elaborate for its purpose.
Why define competencies around project responsibilities?
Statements such as “the team needs more energy training” do not identify the task that is difficult, the role that needs help, or the kind of help that will work. The issue may be unfamiliarity with a technical concept. It may instead be poor data access, an unclear review path, a missing template, or uncertainty about who can approve an assumption. Those problems call for different actions.
A role-based framework lets leaders ask more useful questions. Can the person identify missing inputs before a project analysis begins? Can the analyst distinguish a measured value from an assumption? Does the reviewer know which assumptions to test? Can the project lead explain operational trade-offs to a decision-maker? Each question relates a capability to an actual piece of work.
This distinction is valuable because energy projects cross functional lines. A technically promising opportunity may depend on operating schedules, maintenance constraints, utility charges, capital criteria, procurement steps, and the way benefits are explained. When those contributions are not explicit, a team can discover late in the process that nobody owns a necessary check.
Use a framework to:
Set repeatable expectations for recurring work and project handoffs.
Separate technical, analytical, financial, communication, and coordination capabilities.
Identify where an individual needs practice and where a team process needs repair.
Assign work according to capability, authority, and available support.
Choose learning based on a real need instead of selecting a course simply because it is available.
Plan review and escalation boundaries for specialized engineering, legal, financial, or other professional questions.
Support knowledge transfer when work is shared across departments or with outside specialists.
It is a management tool for developing capability. It is not a substitute for engineering review, legal advice, an organization’s approval rules, or a professional credential. A person’s framework rating should never be presented as a license to perform work outside their authority or competence.
Start by listing the decisions and tasks
Begin with a planning horizon and a defined slice of work. A team might focus on a recurring project type, an annual opportunity review, or the process from initial screening through approval. Avoid trying to document every energy-related activity at once. A narrow pilot gives the team a chance to test whether the language is clear and whether the framework helps with a real decision.
Write each task as an action that someone could observe. “Understand energy” is broad and hard to assess. “Check a monthly electric bill for demand charges and note questions for review” describes an output. So does “prepare a first-pass comparison of two project options using documented assumptions.” These descriptions help a manager identify who does the work and what evidence might show capability.
Depending on the organization’s work, a task inventory might include collecting and checking energy-use data, reviewing utility bills, identifying relevant equipment and operating conditions, estimating project costs and benefits, comparing alternatives with an appropriate economic method, preparing an approval brief, coordinating procurement questions, understanding project-agreement obligations, and tracking implementation actions. These are examples, not a universal job description. Include only tasks that connect to actual responsibilities.
For each task, record the point in the process when it occurs and the decision it supports. “Review data” is not specific enough if no one knows whether the review occurs during opportunity screening, detailed evaluation, or post-implementation follow-up. Add a short context statement: what information is available, what output is needed, and who uses the output next.
Then check the task list with the people who perform the work. Ask them to describe the last time the task was completed. What inputs did they need? What slowed them down? What checks did they make? Which issues required escalation? This conversation often reveals that a task title hides multiple activities or that a process depends on knowledge nobody has documented.
Choose a manageable set of competency areas
Group tasks into a few related areas. Too many headings create a catalog that is difficult to use. Too few can hide important distinctions, such as the difference between calculating an initial estimate and reviewing someone else’s financial assumptions. Use categories that match the organization’s work and are understandable to the people expected to use them.
Technical and operational understanding
Describe the systems, operating conditions, and technical concepts relevant to the role. Depending on the work, this could involve audits, lighting, motors, HVAC, steam, controls, or utility-bill interpretation. The framework should specify the needed level of involvement. Does a person need to recognize when a topic matters, collect the right information, perform an initial analysis, or lead a detailed evaluation within a defined scope?
That distinction prevents a list of equipment topics from becoming a demand that every person know everything. A finance partner may need enough technical context to ask informed questions and understand uncertainty. A technical analyst may need a deeper capability to examine operating information. A specialist may need to validate work in an area that is outside the team’s usual experience.
Data, analysis, and uncertainty
Specify how people gather, check, interpret, and document information. A useful competency might require a person to identify the source and period for a data point, distinguish measurement from assumption, flag a missing input, and state how uncertainty affects the conclusion. These practices make a calculation easier for another person to review and update.
Economic analysis belongs in this area or in a separate project-economics category, depending on the work. Avoid describing spreadsheet operation as the competency. Define the judgment around the tool: selecting an appropriate method for the question, using consistent assumptions across alternatives, recording boundaries, and explaining what the result does and does not establish.
Project economics and approvals
Energy projects compete with other uses of time and capital. A role may need to prepare an initial economic comparison, check assumptions in an existing analysis, or explain costs, benefits, timing, risks, and alternatives to an approval group. Be clear about who prepares the case, who challenges it, and who has authority to decide.
Do not assume that every project requires the same financial method or that a framework can set an organization’s investment criteria. It can say that a person must apply the method selected by the organization, document assumptions, and identify when finance review is needed. This keeps the competency tied to responsible work rather than implying that a single formula answers every investment question.
Communication and coordination
Project work involves operations, engineering, finance, procurement, leadership, customers, and external specialists. Include the ability to request relevant information, give a concise recommendation, explain trade-offs, record decisions, and follow up on unanswered questions. Communication is not decorative. It is part of helping the next person make a decision or complete a handoff.
Make the audience and output explicit. “Good communicator” is not assessable. “Summarizes the recommendation, key assumptions, operational constraints, and open questions in a decision brief” is closer to observable work. The expected format can vary by organization; the framework need only name the capability and point to the relevant local process.
Contracts, measurement, and follow-through
When a role encounters a project agreement, define the expected level of contract awareness. One person may need to recognize topics that merit review; another may coordinate questions for qualified legal or technical review. A framework should not suggest that a general energy manager interprets every legal term or assumes responsibility for obligations beyond the role.
For measurement and verification, state whether the person needs to understand a plan, collect specified evidence, check reported results, or oversee a defined scope. These are different responsibilities. Assigning them clearly helps the team understand what evidence is needed and when a specialist or other reviewer must be involved.
Set proficiency levels people can use
Proficiency levels help only when they describe observable work. A four-level scale is often enough to begin. Adjust the labels if your organization already has a useful model, but define each level in plain language and apply it consistently.
- Awareness:
explains basic concepts, recognizes when a topic matters, and knows where to find the relevant procedure or ask for support.
- Working knowledge:
completes a defined task with guidance, uses documented methods, and raises questions when information is incomplete.
- Independent practice:
completes routine work within the role, documents assumptions and decisions, checks the output, and knows when to escalate.
- Review or coaching:
reviews other people’s routine work, handles more complex cases within the assigned scope, or coaches colleagues in a defined method.
Not every role needs the top level in every area. A procurement specialist may need working knowledge of project economics and stronger capability in procurement steps. A technical lead may need more analytical and review capability. A manager may need to understand an issue well enough to make assignments and ask useful questions without doing the analysis personally.
Use concrete examples to distinguish the levels. For utility-bill review, awareness might mean pointing out where demand charges appear and knowing when to ask for help. Working knowledge might mean checking a sample bill with a guide. Independent practice might mean performing a recurring check, recording findings, and flagging exceptions. Review capability might mean checking a colleague’s analysis and explaining why an unusual charge needs further investigation.
Avoid labels such as “expert” unless the organization has a precise definition and a legitimate reason to use one. Do not make proficiency a proxy for years of service, confidence, course attendance, or job title. The level should refer to work that can be demonstrated, not a personal quality that is difficult to verify.
Map capabilities to roles and project stages
A framework becomes useful when it shows which capabilities apply to which roles and at what stage. A spreadsheet can work well: list roles down one side and competency areas or tasks across the top. For each relevant intersection, note the expected level, the evidence to consider, and the boundary for review or approval. Leave cells blank where a role does not need that capability.
For every competency, document a short set of details:
The task or decision it supports.
The people who perform, review, approve, or provide input.
The expected proficiency for each role that has a responsibility.
Examples of evidence, such as a completed analysis, an observed task, a reviewed brief, or a documented project contribution.
Required data, procedures, templates, and tools.
Any condition that calls for specialist, legal, engineering, finance, or management review.
Consider a hypothetical project opportunity. A facility representative describes operating schedules and constraints. An analyst organizes energy-use information and prepares a first-pass comparison. A finance partner reviews the assumptions against the organization’s decision process. A manager decides whether the opportunity should advance. The framework should describe each contribution, rather than rating all participants against the same broad phrase such as “project development.”
Role mapping also exposes gaps in ownership. If the analysis depends on information that no role is assigned to gather, the immediate problem is not necessarily a training need. If one person is both preparing and approving the same output without an agreed check, the team may need a review step. Make those structural findings visible instead of assigning an individual a low score for a process that does not support the work.
Keep authority and capability separate. Someone may understand a project agreement but have no authority to approve it. Another person may own a decision but need a technical review before making it. Document who contributes information, who recommends, who reviews, and who decides according to the organization’s established rules.
Assess current capability with evidence
First agree on the expected level for each role. Then compare current evidence with that expectation. Self-assessment is a helpful starting point, but a confidence rating by itself does not demonstrate capability. Combine perspectives where possible: employee reflection, manager discussion, sample work, observed tasks, and feedback from people who receive the output.
Use a consistent process:
- Explain the purpose.
Tell participants that the review is intended to support project work and development, not to label people or create an all-purpose ranking.
- Show what the competency means.
Use examples of acceptable outputs and explain the boundary between levels.
- Ask for evidence.
Discuss a task the person completed, the inputs used, the checks made, and the outcome or handoff.
- Compare with role expectations.
Assess against the agreed requirement for the role, not an idealized professional who is expected to do every task.
- Record uncertainty honestly.
If nobody has seen the person perform a task, mark capability as unverified rather than assuming either strength or deficiency.
- Agree on the next step.
Select practice, mentoring, a process change, focused instruction, or scoped specialist review according to the evidence.
Evidence should be proportional to the task. A short, low-risk recurring activity may be demonstrated with a sample output and a brief conversation. A complicated analysis that informs an important approval may require documented assumptions, review comments, and evidence that the person can respond to questions. The framework should not create an elaborate test for every competency.
Separate an individual skill gap from a team capability gap. One person may need practice preparing an analysis. A team may have several capable analysts but no shared method for recording assumptions. The first points toward an individual development action; the second suggests a process or governance action. Both matter, and neither is solved automatically by enrolling everyone in the same course.
Prioritize gaps by the work they affect
A long list of differences between current and desired capability can feel urgent without helping the team choose. Prioritize according to the work at stake. Consider whether the gap affects an upcoming decision, the quality of a financial comparison, an operational constraint, an approval handoff, a contract obligation, or the ability to verify a result. Give priority to issues that can block a near-term project or make its evaluation unreliable.
A simple prioritization conversation can use four questions:
What decision or task depends on this competency?
When will the work be needed, and how often does it recur?
What is the consequence if the task is incomplete or misunderstood?
Can the issue be addressed through practice, process clarification, better inputs, or a qualified review?
For example, suppose the team has a project review next month and its analyst is unsure how to document assumptions. That issue may need prompt attention because a reviewer cannot evaluate an undocumented calculation. The same team may also want broader familiarity with a system it rarely encounters. That learning can be planned, but it may be less urgent if no current decision depends on it.
Do not reduce assessment to one score for a person or department. A team can have strong technical capability and a weak approval handoff. An individual can communicate a recommendation clearly but need support with a particular analysis. A single average can hide the difference and lead to the wrong intervention.
Choose an intervention that matches the gap
Training is one option, not the answer to every gap. If the issue is unfamiliarity with a concept, instruction may help. If people understand the method but cannot obtain usable data, the remedy may be access or a clearer data process. If responsibility is disputed, define ownership. If a task requires expertise the team does not have, arrange an appropriate specialist review rather than treating a short course as a substitute.
- Concept gap:
use focused instruction, reading, or a guided explanation, followed by a check that the learner can describe the idea in the context of the work.
- Application gap:
provide a realistic project exercise or supervised assignment, then review the person’s method and output.
- Experience gap:
use mentoring, shadowing, or a bounded assignment with clear review points.
- Process gap:
clarify ownership, revise a template, document a procedure, or establish a handoff.
- Access gap:
identify the data, tools, permissions, or time the person needs to complete the task.
- Specialist gap:
scope qualified technical, legal, financial, or other professional input for the question at hand.
Customized organizational instruction can be built around a team’s responsibilities and learning objectives. Topics may include project economics, audits, utility rates, equipment, approval processes, and related energy-management subjects. The energy management training page describes this training path. PGS training is educational; it does not award CEM certification or another professional credential.
Self-paced resources can support narrower learning goals. The Simplified Energy Concepts lessons address foundational energy topics, and the Selling Energy Projects lessons focus on communicating project value. These are educational resources, not certification programs. Select a resource because it addresses a defined competency, then plan how the learner will apply the material.
Professional associations can be another reference point for the wider energy-management field. The Association of Energy Engineers provides a professional-association context for energy professionals; it is not a substitute for defining the responsibilities and proficiency expectations of a particular organization.
Connect learning to an actual assignment
Before learning begins, identify where the person will use it. Assign a task that fits the role, define the expected output, specify what support is available, and schedule a review. Without this bridge, course completion can be mistaken for demonstrated capability even when no one has seen the person apply the material.
For example, after learning about project economics, a participant might prepare a first-pass comparison of two options using assumptions supplied or approved for the exercise. The assignment can ask the learner to list data sources, separate measured values from assumptions, identify missing information, and explain what additional review is needed. A reviewer can assess the reasoning and documentation, not just whether the spreadsheet contains a result.
A task should be neither too easy to reveal learning nor so consequential that an untested learner is left without support. Start with a bounded assignment and a named reviewer. As capability is demonstrated, the manager can adjust the level of supervision in line with role authority and organizational controls.
After the assignment, discuss questions such as:
Could the person complete the task with the expected level of support?
Were data sources, assumptions, boundaries, and open questions recorded?
Could the person explain the result to the next decision-maker?
Did the handoff become clearer or more timely?
Which part still needs practice, a process change, or specialist review?
Record the answer in practical terms. “Completed the sample analysis and documented three assumptions” is more useful than “improved confidence.” If the person struggled because a required input was unavailable, note that limitation. If the learning worked but the template was confusing, improve the template rather than repeating the training without change.
Use a worked example to test the framework
Suppose an organization wants to compare two possible energy projects before its next capital review. This is a hypothetical example, not a claim about a particular PGS client or project. The team’s first step is to state the decision: which option, if either, should move to a more detailed evaluation? That question gives the competency framework a clear boundary.
The team then defines the work sequence. An operations representative provides schedules and identifies constraints. An analyst checks the available energy and cost information, records assumptions, and prepares an initial comparison. A finance partner reviews the method and alignment with internal criteria. A manager decides whether the opportunity proceeds and what additional review is needed. If technical questions exceed the team’s scope, they are assigned for qualified review.
Next, the team describes the capability required at each step. Operations needs to communicate relevant conditions and flag changes that could affect the comparison. The analyst needs to organize the data, label assumptions, and explain uncertainty. The finance reviewer needs to test whether the comparison is internally consistent and identify missing decision inputs. The manager needs to understand the recommendation and the unresolved questions without being expected to reproduce the detailed analysis.
Assessment may reveal that the analyst can calculate a basic comparison but rarely documents where inputs came from. The operations representative knows the process but is not asked to confirm schedules until late. Finance can review a complete case but receives inconsistent formats. These findings suggest three distinct actions: coach the analyst on evidence and assumptions, add an early operations check, and standardize the handoff format. A general course for the whole team would not address all three as directly.
Finally, the team tests the changes on the next appropriate assignment. It checks whether the information arrived earlier, whether assumptions were clearer, and whether finance could review the case without requesting routine missing details. The result is not a universal measure of a person’s worth. It is feedback on whether the team’s capabilities and process support the decision.
Build a simple framework record
A useful record does not need to resemble a complex competency database. A row for each task can capture the information needed to make the framework actionable. For instance, a row might name “prepare initial project comparison,” list the analyst as responsible and a finance partner as reviewer, state the expected level for each role, and give examples of evidence such as documented assumptions and a review-ready brief.
Add a column for dependencies. A capability may rely on a data source, a standard template, access permission, or a decision rule. This helps managers avoid describing a person as deficient when the organization has not supplied the conditions needed to perform the task. Add another column for escalation boundaries so that the framework shows when a question should go to a qualified specialist or authorized decision-maker.
Keep the language short enough to scan. Detailed procedures belong in the relevant procedure or work instruction; the framework can link to or name them. If the framework repeats every step in every process, updates become difficult and users may not know which document is authoritative. The goal is to connect capabilities to work, not to replace all operating documentation.
It may also help to note whether evidence has been observed, is self-reported, or remains unverified. This prevents a self-rating from being treated as equivalent to reviewed work. Use evidence labels consistently and explain them at the start. Do not collect more personal information than is needed to support development and assignment decisions.
Keep the framework fair and useful
People are more likely to engage when they understand how the information will be used. Explain whether the framework supports development planning, project staffing, training choices, or some combination. Do not quietly repurpose a development conversation as a performance decision without explaining the process and expectations.
Use the same definitions for people doing comparable work, while recognizing that roles may differ. Ask multiple reviewers to discuss examples when ratings have significant consequences. Where evidence is incomplete, say so. Confidence, communication style, access to high-visibility projects, or time in a role should not silently become substitutes for demonstrated capability.
Make accommodations for learning and demonstration methods where appropriate to the organization and role. A framework should describe the required work outcome, not impose an irrelevant preference for how someone learns or presents. For example, assess whether the person can explain a decision clearly in the format the role requires; do not equate one particular presentation style with capability.
Protect the usefulness of the framework by keeping ratings in context. A developing capability is not a permanent label. Note the evidence and agreed action, then revisit after relevant experience. If the person has not had a fair opportunity to perform a task, do not treat the absence of evidence as proof that they cannot do it.
Review and maintain the framework
A framework should evolve as work changes, but it does not need a large redesign every year. Assign an owner to maintain it and identify when a review is triggered. Useful triggers include a change in project types, technology, organizational responsibilities, approval routes, or applicable requirements. Also review the framework when users repeatedly interpret a competency in different ways.
Keep a version date and a brief record of significant changes. Remove competencies that no longer support a real responsibility. Add a new one only when a change in work or a recurring gap justifies it. Ask people who perform the tasks whether the wording still describes what they do and whether the evidence remains realistic.
Measure usefulness by looking at the work the framework is meant to support. Are roles and review steps clearer? Can managers choose development actions more specifically? Are recurring gaps being addressed at their source? Are assignments better matched to capability and authority? These are more meaningful checks than counting the number of competencies or training hours alone.
Use the existing energy resources and articles to support a specific learning objective. A reading list can help someone prepare, but it does not replace a practice assignment, feedback, or a clear process. Connect each resource to a task and decide what evidence will show that the learner can use it.
Common mistakes to avoid
- Starting with a course catalog:
define the work and the gap before choosing instruction.
- Making every role responsible for everything:
distinguish performing, reviewing, approving, advising, and supporting.
- Using vague labels:
describe observable tasks, outputs, and boundaries.
- Confusing attendance with competence:
look for application in relevant work rather than relying only on course completion.
- Ignoring organizational barriers:
check data access, time, tools, authority, and procedures as well as knowledge.
- Using one score for a team:
separate technical, analytical, communication, and process issues.
- Setting every role at the highest level:
define only the capability the responsibility requires.
- Assigning work beyond authority:
show where management approval or qualified review is required.
- Claiming credential outcomes:
internal capability levels and educational lessons are not professional certifications.
- Leaving the framework unused:
connect it to project assignments, coaching, and decisions about development.
What should energy leaders do next?
Choose one project type or recurring responsibility for a pilot. List the tasks and decisions, identify the roles that perform or review them, and write a few observable competency statements. Set only the proficiency levels that the work needs. Ask the people doing the tasks to test whether each statement describes a real responsibility and whether the proposed evidence is practical.
Assess current capability through examples, not just confidence ratings. Record what is observed and what remains unverified. Prioritize gaps that affect upcoming decisions or handoffs, then select an action that matches the cause: focused learning, supervised practice, a clearer process, better access to information, or specialist review. Give the learner a real assignment and feedback so the framework leads to changed work rather than another document.
A useful energy competency framework links what the organization needs to accomplish with the work people can demonstrate and the support that will help them do it reliably.
Comments