How to Write Strong PEO CBA Work Examples Using Situation, Action and Outcome

A PEO CBA response can describe a genuine engineering project and still provide weak competency evidence. The usual problem is not a lack of experience. It is that the writing leaves the assessor to infer what the applicant personally decided, why the decision required judgment, and what changed because of the applicant’s contribution. A strong work example removes that uncertainty by focusing on one relevant episode rather than summarizing an entire project or listing routine duties.

Situation, Action and Outcome (SAO) turns that episode into a compact evidence narrative. Situation gives only the context needed to understand the challenge, Action makes the applicant’s reasoning and individual contribution visible, and Outcome demonstrates the result or learning. The sections below show how to select evidence, draft each SAO field, preserve personal ownership and revise a PEO CBA work example until every sentence helps prove the selected competency.

Quick Answer: How Should a PEO CBA Work Example Be Written?

The strongest PEO CBA work examples read as short evidence cases, not project summaries. Begin with one incident, decision or project phase that clearly matches the selected competency. Use Situation to establish your role, the challenge and the critical constraint. Devote most of the response to Action, explaining in first person what you analyzed, compared, decided, communicated or verified and why. Close with an Outcome that shows the resulting decision, improvement, effect or learning. Keep every detail relevant, truthful, confidential and capable of validation.

SAO section	Main question	What to include	Common error
Situation	What was happening?	Project phase, role, challenge and critical constraint	Too much company or project history
Action	What did I personally do and decide?	Analysis, alternatives, standards, communication, judgment and verification	“We” statements, passive voice or a task list
Outcome	What changed because of my action?	Result, decision, safety or quality effect, metric or learning	“The project was completed successfully”

PEO’s current P.Eng application form allocates a maximum of 300 characters to Situation, 1,650 characters to Action Taken and 300 characters to Outcome. That distribution is deliberate: the assessor needs enough context to understand the problem, but most of the evidence must show the applicant’s own reasoning and actions.

What PEO Assessors Need to Learn From a Work Example

A work example is evidence, not a career summary. By the end of one response, an assessor should be able to identify:

• The responsibility you personally held.
• The problem, risk, decision or professional challenge you faced.
• The competency-specific knowledge or behaviour you applied.
• The constraints, standards, stakeholders and consequences that shaped your choice.
• The sequence of actions you took and the judgment behind them.
• The result of your work and how it was established.
• Why this example demonstrates the selected competency rather than a neighbouring one.

The distinction matters. “I prepared drawings for a pump upgrade” reports a task. “I compared the duty point against the system curve, identified a cavitation risk, revised the pump selection and verified the operating margin” shows analysis, a technical decision and verification. Both statements may be true, but only the second reveals evidence of competency.

Step 1: Choose the Right Engineering Evidence Before Writing

Start With a Competency-Specific Question

Translate the competency into a question about your own work. For technical risk, ask, “When did I identify a technical uncertainty, assess its consequences and select a mitigation?” For communication, ask, “When did my explanation or document enable a technical decision?” For accountability, ask, “When did I recognize a limit, obligation or public-safety concern and act on it?”

Competency indicators help you recognize relevant behaviour. They are prompts, not sentences to copy and not a checklist that requires every indicator. The example should use project facts and language that reflect what you actually did.

Select One Bounded, Verifiable Event

The strongest starting point is usually a contained event: a design decision, failure investigation, nonconformance, risk review, scope change, stakeholder disagreement, technical presentation, ethical concern or learning need. A bounded event gives the response a clear beginning, decision and consequence.

Choose work that the assigned validator knows well enough to rate. The validator does not need to have watched every keystroke, but must be sufficiently familiar with the example, your role and the outcome to assess the claimed competence confidently.

Test Whether the Event Shows Responsibility

Before drafting, ask:

• Did I analyze, calculate, compare, recommend, decide, coordinate, verify, escalate or improve something?
• Was there a meaningful constraint, uncertainty, trade-off or consequence?
• Can I explain why my action was appropriate?
• Did my contribution influence a technical or professional result?
• Can the result and my role be verified without disclosing protected information?

If the answers are mostly no, the event may describe exposure rather than competence. Look for a moment where your judgment changed the direction, quality, safety or understanding of the work.

Build an Evidence Note

Capture the facts before trying to produce polished prose.

Evidence field	Notes to capture
Project and timing	Project type, phase and approximate date
Personal role	Assigned scope, authority and supervision level
Challenge	Problem, risk, decision or conflict
Governing inputs	Code, standard, method, procedure, data or stakeholder need
Options	Alternatives considered and decision criteria
Personal action	Analysis, recommendation, coordination, implementation and verification
Outcome	Technical result, acceptance, improvement, risk effect or lesson
Validator	Person familiar with the work and outcome
Target competency	Capability this event proves most directly

This note prevents two common problems: inventing detail while drafting and forcing one attractive project into a competency it does not actually demonstrate.

Step 2: Write a Focused Situation

Establish Only the Context the Assessor Needs

Situation should identify the project or task, your role, the specific challenge and the constraint that made the event meaningful. The assessor does not need the employer’s full history, the entire project scope or every technical feature.

At 300 characters, each word has to carry context. A useful Situation usually answers four questions: Where was the work in its lifecycle? What was your responsibility? What problem emerged? What constraint or risk mattered?

Keep the Background Proportionate

Remove details that do not change the reader’s understanding of the competency. Contract value, client background or facility capacity may matter when they explain complexity, financial responsibility or risk. Otherwise, they consume space without strengthening the evidence.

The Situation should end with a problem that makes the Action necessary. If it ends only with “I was responsible for the design,” the assessor still does not know what required judgment.

Illustrative Situation Revision

Weak fragment	Stronger teaching fragment	Why it is stronger
“Our company was delivering a large industrial expansion with many disciplines and a demanding client.”	“As the mechanical designer for a process-line upgrade, I had to resolve an undersized relief path before design release while maintaining the shutdown date.”	It identifies role, project phase, technical issue and constraint.

The stronger fragment is invented only to demonstrate the writing technique. It is not a model response for submission and should not be copied into an application.

Step 3: Make the Action Section the Strongest Part

Use “I” to Show Personal Contribution

PEO requires applicants to use “I” so assessors can see individual actions. Replace vague phrases such as “we designed,” “the team reviewed” or “it was decided” with an accurate account of your contribution.

First-person writing does not mean pretending to work alone. You can write, “I obtained the electrical load data from the controls engineer, incorporated it into my heat-load calculation and presented the revised cooling requirement to the project lead.” This acknowledges team inputs while preserving ownership of the analysis and communication.

Explain Judgment, Not Just Activity

Strong Action writing answers the questions hidden behind the task:

• What information did you analyze?
• Which assumptions did you test?
• What alternatives did you compare?
• Which code, standard, calculation, test or professional principle influenced the decision?
• What risk or consequence did you evaluate?
• Why did you select or recommend one option?
• How did you communicate, implement or verify the result?

“I used AutoCAD and Excel” names tools. “I calculated the revised load in Excel, checked the result against the equipment rating and changed the drawing to maintain the required design margin” explains what the tools supported and why the action mattered.

Show the Sequence of Thought and Action

A useful thinking sequence is:

1. Identify the issue.
2. Investigate the relevant facts.
3. Analyze the problem.
4. Compare feasible options.
5. Decide or recommend.
6. Communicate or implement.
7. Verify the result.

Not every example needs all seven steps. Use the sequence to find missing reasoning, not as a rigid formula. A communication example may focus on audience analysis, message design and confirmation of understanding. An accountability example may centre on recognizing a limit, escalating the issue and obtaining specialist review.

Add Technical Detail With Purpose

Technical detail is useful when it proves the competency. State the significance of a calculation, test, tolerance, model assumption, standard or design constraint. Define an uncommon acronym and provide enough context for an assessor outside your workplace or exact discipline.

Avoid turning Action into a design report. Detailed equations, equipment catalogues and copied code clauses can hide the decision. The relevant question is what the technical information caused you to conclude or change.

Protect confidential and security-sensitive information. PEO permits generic client names such as “ABC Company” when a non-disclosure agreement prevents identification. You can also describe a system by function, use approximate non-sensitive values or omit proprietary details while retaining the engineering logic.

Illustrative Action Revision

Weak fragment	Stronger teaching fragment	Why it is stronger
“We reviewed the model, held meetings and selected the best option.”	“I checked the model assumptions against field data, compared two valve sizes for pressure loss and controllability, and recommended the smaller option after confirming it met the operating range. I then explained the trade-off to operations and recorded the basis in the design note.”	It shows personal analysis, alternatives, decision criteria, communication and documentation.

The stronger fragment teaches evidence structure only. The method, actions and result in an actual submission must come from the applicant’s own work.

Step 4: Write an Outcome That Proves the Value of the Action

Use the Most Credible Result Available

Outcome answers what happened because of your action. Depending on the competency, that may be:

• A verified technical resolution or performance improvement.
• A safer design, clearer control or reduced risk.
• An approved recommendation, revised specification or accepted report.
• Reduced rework, cost, time, material or energy use.
• Stakeholder agreement or improved technical understanding.
• A corrective action that prevented recurrence.
• A lesson applied to later work.

An Outcome does not need to claim that the whole project succeeded because of one person. It should stay within the scale of your contribution.

Use Metrics Carefully

Numbers strengthen an example when they are accurate, meaningful and verifiable. A 12 percent reduction in pressure loss is useful if the comparison basis is clear. “Improved efficiency by 40 percent” is weak when the measure, baseline and record are missing.

If no numerical result exists, use the strongest documented effect: approval to proceed, closure of a nonconformance, acceptance of a calculation, elimination of a hazard, agreement on an interface, or a change applied to later work. Never invent savings, performance or safety results to make an example sound stronger.

Connect the Result to the Competency

Finish by making the relevance visible without repeating the competency definition. For a technical example, state how verification established that the solution met the requirement. For communication, state which decision or understanding the communication enabled. For CPD, explain how learning changed later practice.

How to Adapt SAO for Different PEO Competency Types

Competency type	Situation focus	Action focus	Outcome focus
Technical	Design problem, failure, constraint or technical risk	Analysis, standards, alternatives, decision and verification	Performance, safety, quality or verified solution
Communication	Audience misunderstanding or decision need	Message design, document, presentation or clarification	Decision enabled, issue resolved or understanding improved
Project and financial	Scope, schedule, budget, resource or change pressure	Planning, forecasting, trade-off, control or escalation	Delivery, cost, schedule, risk or quality effect
Teamwork	Interface, disagreement or coordination need	Listening, facilitation, role clarity or conflict resolution	Alignment or improved multidisciplinary outcome
Accountability	Ethical, safety, legal or professional-limit issue	Judgment, escalation, refusal, consultation or correction	Compliance, safer decision or protection of the public interest
Sustainability	Environmental, social, economic or lifecycle trade-off	Impact comparison and responsible recommendation	Reduced impact or better long-term outcome
CPD	Knowledge gap or performance feedback	Learning plan, activity and application	Improved capability or practice

The structure stays the same, but the evidence emphasis changes.

This adaptation prevents the same technical narrative from being reused unchanged. A project can support different competency types, but each response must foreground the behaviour that the selected competency assesses.

How to Write About Team Projects Without Losing Personal Ownership

Engineering is collaborative, and personal evidence can still include other people. Use this pattern:

• State the team’s objective or the input you received.
• Define your assigned scope.
• Use “I” for your analysis, decisions, communication and verification.
• Identify approval by a supervisor, client or authority accurately.
• State the outcome attributable to your contribution.

For example: “The structural engineer supplied the allowable equipment loads. I checked three skid layouts against those limits, identified that the preferred arrangement exceeded the local load, and coordinated a revised support location. The supervising P.Eng. approved the revision after reviewing my calculation.” This shows collaboration without claiming the structural limits or final approval as your own work.

Can the Same Project Support More Than One Competency?

Yes. PEO permits the same project or work example to support more than one competency when each entry is tailored to that competency. One plant modification might demonstrate technical analysis, written communication and project risk management.

The technical response should centre on the analysis and verification. The communication response should centre on the audience, message and decision enabled. The project response should centre on scope, schedule, resources or change control. Replacing a few competency words in the same paragraph does not create distinct evidence.

Create a project-to-competency map before reusing evidence. Viewing the 34 competencies across seven categories helps reveal where one project contains distinct evidence, where examples are becoming repetitive and where another project is needed to close a gap.

Also Read: PEO 34 Competencies Explained: The 7 CBA Categories and Evidence Applicants Need

Before-and-After Editing Checklist

Weak pattern	Revision question
“We completed the design.”	What exactly did I analyze, decide, communicate or verify?
Long project background	Which facts are necessary to understand the competency challenge?
Software or task list	What engineering judgment did the tool or task support?
“I followed the code.”	Which requirement affected my decision, and how?
“The outcome was successful.”	What changed, how was it established and why did it matter?
Unverifiable claim	Can my validator confirm my action and the result?
Copied indicator language	What real behaviour from my work demonstrates this competency?

Read the edited response once without the competency title. A technically informed reviewer should still be able to infer the capability from your actions. If the evidence works only because the competency phrase is repeated, the response probably needs more substance.

Common PEO CBA Writing Mistakes

Writing a Job Description

A résumé bullet explains responsibility in general. A competency example isolates one event, decision and result. Replace “responsible for reviewing designs” with the specific design issue, review method, finding and consequence.

Letting “We” Hide the Applicant

Use team language for context and “I” for your contribution. Do not claim another person’s calculation, decision or approval.

Giving Situation More Space Than Action

The current form gives Action more than five times the space of either Situation or Outcome. Mirror that emphasis in the substance of the response.

Describing Tasks Without Decisions

Words such as prepared, attended and assisted may show participation but not judgment. Explain what you analyzed, why you chose an approach and how you checked it.

Using Jargon Without Relevance

Acronyms and specialist detail should help an assessor understand complexity or reasoning. Remove anything that does not affect the competency evidence.

Naming a Standard Without Applying It

Identify the requirement that mattered and the decision it influenced. “I followed CSA requirements” is less informative than explaining the limit, check or change produced by the requirement.

Inventing or Stretching Metrics

Use only recorded or defensible results. A precise unsupported number can weaken credibility more than a clear non-numeric outcome.

Reusing the Same Action Repeatedly

One project may support several competencies, but the central behaviour and result must change. Duplicate narratives make the evidence appear generic.

Ignoring Validator Knowledge

Choose events that the assigned validator can rate with confidence. Resolve factual uncertainty before submission; applicant self-ratings and validator ratings are submitted independently.

Copying Sample Language

Samples can teach structure and depth, but their facts, phrasing and outcomes belong to another context. Use a blank page and your evidence notes when drafting.

Writing Toward a Desired Rating

Do not add responsibility or complexity to justify a score. Describe the real work accurately; the evidence should support the self-rating naturally.

Disclosing Protected Information

Remove client names, proprietary values and security-sensitive details when required. Preserve the engineering logic through generic identifiers and non-sensitive context.

A Practical Drafting Workflow From Notes to Final Example

8. Read the competency and use its indicators to identify relevant behaviour.
9. Select one specific event that a validator can verify.
10. Record factual notes under Situation, Action and Outcome.
11. Identify the personal decision or judgment that proves the competency.
12. Draft in first person within the 300, 1,650 and 300-character fields.
13. Remove unrelated background, passive phrasing and generic team activity.
14. Add the technical or professional detail needed to explain why you acted.
15. Confirm that the Outcome is accurate, proportionate and linked to the competency.
16. Review confidentiality, dates, role descriptions and consistency with the experience record.
17. Confirm that the assigned validator is familiar enough with the work to rate it.

PEO permits point form, so complete sentences are not mandatory when concise bullets make the logic clearer. Whatever form you choose, the response should read as one connected evidence narrative rather than disconnected notes.

Applicants remain fully responsible for the truth, accuracy and authenticity of every work example, including material prepared with AI-based or other drafting tools. A tool may help organize notes or improve clarity, but it cannot supply experience, judgment, results or validator knowledge that did not exist.

Why Professional PEO CBA Writing or Review Support Can Be Valuable

Applicants are often too close to their own projects to see what an assessor cannot infer. They may know why a decision was difficult but omit the alternatives, constraints or standards that made it significant. They may also repeat one familiar project across too many competencies, understate their individual contribution, or lose credible engineering judgment in unclear wording. Professional review is most valuable when it identifies these evidence gaps across the application, not merely when it corrects grammar.

Good support works from the applicant’s real project record. It can draw out missing facts through focused questions, map different experiences to suitable competencies, strengthen SAO structure, improve consistency and edit the language without changing ownership. The applicant must confirm every action, result and validator relationship; a reviewer should never invent a project, metric, decision or code application.

Frequently Asked Questions

1. What is an example of a good competency statement?

A good competency statement identifies a specific challenge, explains the applicant’s personal analysis and decision, and records a credible result. For example, an applicant might state that they identified a design constraint, compared options against a governing requirement, recommended a justified solution and verified the outcome. The actual project facts must be personal and verifiable.

2. What is the SAO method for PEO CBA examples?

SAO means Situation, Action and Outcome. Situation gives concise context and states the challenge. Action provides the detailed first-person analysis, decisions and implementation. Outcome explains the result, effect or learning produced by those actions.

3. Should I write “I” or “we” in a PEO competency example?

Use “I” for your contribution because PEO requires individual actions to be clear. Use “we” only when describing team context, then identify what you personally analyzed, recommended, communicated or verified.

4. How much technical detail should I include?

Include enough detail to explain complexity, method, judgment and verification. Name the relevant calculation, standard, test or constraint and explain how it affected your decision. Remove details that do not strengthen the selected competency.

5. Does every PEO CBA outcome need a metric?

No. Use a metric when it is accurate and meaningful. Otherwise, a documented approval, verified performance result, closed risk, resolved issue, accepted recommendation or learning applied to later work can provide a credible outcome.

6. Can I use one project for multiple competencies?

Yes. The same project may support several competencies when each response focuses on a different behaviour and outcome. Do not repeat one paragraph with swapped competency terms.

7. Can I use an overseas engineering project as a work example?

Yes. PEO does not require Canadian experience. Explain the jurisdiction, applicable standard or international equivalent, your personal responsibility and the outcome clearly enough for an Ontario assessment audience.

8. What if my validator did not observe every action directly?

The validator must be sufficiently familiar with the work to rate the assigned competency confidently. They may know the example through supervision, technical responsibility, reviews, records and direct interaction; they do not need to have watched every task occur.

9. Can I copy the structure of a PEO CBA sample?

You can learn the SAO order, evidence depth and first-person style from a sample. Do not copy its wording, decisions, standards, metrics or project claims. Draft from your own evidence note and confirm every fact.

10. How do I know whether my example shows enough responsibility?

The example should show more than attendance or routine task completion. It should identify a problem or decision, explain your reasoning, show how independently you acted, state the consequences you considered and record a result consistent with your actual role.