How to Write EGM CBA Competency Examples Using Situation, Action and Outcome

Many Manitoba P.Eng applicants have enough engineering experience but still struggle when the EngGeoMB CBA portal asks for concise competency examples. The problem is usually not the project itself. The problem is turning a real project into evidence that shows the situation, the applicant’s personal engineering action and the result clearly enough for validation and assessment.

The Situation, Action and Outcome method gives that writing a simple structure. It helps you avoid a resume-style job description and instead present a specific work example that connects to the selected competency, the indicators, your self-rating and the validator who can confirm the work.

This guide focuses on engineering applicants using the EngGeoMB CBA process for Manitoba P.Eng registration. P.Geo applicants should use the geoscience framework separately, because this article is written around the engineering CBA example fields and engineering competency wording.

Important compliance note: your examples must come from genuine workplace experience. The safest support is structure, clarity, editing and evidence mapping. AI tools or third parties should not create, invent or embellish workplace examples for you.

Quick Answer: How Do You Write an EGM CBA Competency Example?

To write an EGM CBA competency example, choose one specific engineering situation, explain what you personally did using first-person ‘I’ statements, and finish with the outcome your action produced. The action section should usually carry the most weight because it shows engineering judgement, technical decision-making, responsibility and the evidence behind your self-assessed rating.

• Situation: identify the project context, your role, the timeframe and the engineering problem or constraint.
• Action: explain your own technical analysis, decisions, calculations, standards, checks, communication and responsibility.
• Outcome: state the result, approval, improvement, risk control, design decision, lesson learned or measurable impact.
• Validator fit: assign the example to someone with direct knowledge of that work, not only a senior title.

What Is the Situation-Action-Outcome Method in EngGeoMB CBA?

Situation-Action-Outcome, often shortened to SAO, is a practical way to organize a competency-based assessment example. It separates the background from the applicant’s personal contribution and from the result. That separation is useful because EngGeoMB CBA examples are reviewed as evidence, not as storytelling.

A good SAO example reads like a compact engineering case note. It does not need drama, inflated language or a long project history. It needs the right facts in the right order: what problem existed, what you did as an engineering applicant, and what changed because of your work.

The Engineering Applicant Guide identifies Situation, Action and Outcome as separate fields in the competency example. That is why applicants should plan each example before entering it in the portal.

Before You Write: Choose the Right Competency Example

The best writing method cannot rescue the wrong example. Before drafting, check whether the project actually gives you enough evidence for the competency you selected. For example, a design-calculation example can work well for technical competence, but it might be weak for oral communication unless the communication itself affected an engineering decision.

Start with one competency, then choose the project moment that proves it most clearly. A broad project summary often becomes too vague; a smaller decision point is usually easier to validate and assess.

1. Identify the competency number and category you are writing for.
2. Read the indicators and interpretation statement for that competency.
3. Choose a project or task where your own role was visible and significant.
4. Confirm the example sits in your engineering discipline and matches the experience claimed in your employment history.
5. Check that a validator can confirm the work from direct knowledge.

Step 1: Write the Situation

The Situation section sets the context for the evidence. It should tell the reader where the example happened, what the engineering issue was, what role you held and why the work mattered. Keep it short. The Situation is there to frame your action, not to retell the whole project.

What to Include in the Situation

• Employer, position or project role at the time of the work.
• Month/year or approximate timeframe that matches your employment history.
• Project type, asset, facility, system, study, design package or field activity.
• The engineering problem, constraint, risk, code requirement, design issue or decision point.
• Your responsibility boundary, especially if you worked as part of a team.

What to Avoid in the Situation

Avoid long company background, generic project descriptions and copied job duties. If the Situation becomes half the example, the reader has to hunt for your competence. Keep the background lean so your Action section has enough room.

Situation Writing Prompt

Use this planning prompt before drafting: During [timeframe], while working as [role] on [project/system], I was responsible for [scope] because [engineering problem, constraint or requirement] needed to be addressed.

Step 2: Write the Action

The Action section is the centre of the EGM CBA competency example. This is where you show your engineering judgement, not just your attendance on a project. The assessor should be able to see what you personally decided, calculated, reviewed, checked, communicated or recommended.

Why Action Matters Most

A competency is demonstrated through observable work behaviour. That means the Action section should show evidence of competence rather than simply naming a competency. If the example is about risk, explain how you identified and reduced the technical risk. If it is about codes and standards, show how the requirement changed your engineering decision.

For technical competencies, the engineering interpretation statements are helpful because they show the kind of specificity expected for codes, constraints, risk, theory, solution techniques, safety, quality control and documentation.

Use First-Person ‘I’ Statements

Write as the person being assessed. Use ‘I’ when describing the work you owned, even if the project involved a team. ‘We designed the system’ hides the applicant’s role. ‘I checked the load assumptions, revised the equipment schedule and recommended a larger feeder size’ gives the assessor something specific to evaluate.

Show Engineering Judgement, Not Just Activity

Weak Action Wording	Stronger Direction
I was involved in design review.	I reviewed the design against the applicable standard, identified the non-compliant clearance and recommended a layout revision.
I participated in safety meetings.	I linked the hazard to the engineering design, checked the safety requirement and changed the design/control measure accordingly.
I used software for analysis.	I built the model, checked inputs, compared output with hand calculations and used the result to support a design decision.
I helped with documentation.	I prepared the drawing markups, coordinated discipline comments and updated the issued package so the design intent was clear.

Step 3: Write the Outcome

The Outcome section closes the evidence loop. It explains what happened because of your action. A useful outcome does not always need a dramatic result or a large cost saving. It can be approval, reduced technical risk, a corrected design, a verified calculation, a clearer decision record, safe installation, improved quality control or a lesson that changed later work.

What Counts as a Good Outcome?

• A technical issue was resolved or reduced.
• A design, report, drawing, specification, review comment or recommendation was accepted.
• A code, standard, safety or quality requirement was satisfied.
• A stakeholder decision became clearer because of your analysis or communication.
• A project risk, cost, schedule, reliability, maintainability or public-safety issue was managed.

Make the Outcome Specific

Specific does not always mean numerical, but numbers help when they are accurate. If you cannot quantify the outcome, name the decision or change that resulted from your work. ‘The client accepted my recommendation and the revised drawing package was issued for construction’ is stronger than ‘the project was successful.’

Tie the Outcome Back to the Competency

The outcome should make the selected competency easier to see. For a communication competency, the result should show what the communication achieved. For a technical competency, the result should show how the engineering decision affected the work. For professional accountability, the result should show responsible action, ethical judgement or protection of the public interest.

How to Link SAO to the Specific Competency and Indicators

A common mistake is writing a good project story that does not answer the selected competency. Before finalizing the example, compare your Action section against the competency wording, indicators and interpretation statement. Then remove details that do not support that competency and add missing evidence that does.

If the competency is about…	Your Action should show…
Codes and standards	Which code or standard applied, how you interpreted it and how it affected the engineering decision.
Risk identification	The technical risk, why it mattered, how you analyzed it and what mitigation you selected.
Solution techniques	The method, model, calculation or test you used and how you independently checked the result.
Communication	The technical message, audience, method, decision influenced and result of the communication.
Project management	How scope, schedule, cost, resources or change control connected to engineering delivery.
Professional accountability	The duty, ethical issue, limitation, escalation, public interest or responsible decision involved.

How Much Detail Should an EGM CBA Example Include?

Use enough detail for a competent reviewer to understand the evidence without asking basic follow-up questions. The example should not become a full technical report, but it should include the engineering facts needed to verify the competency.

Section	Practical Length Direction	Main Purpose
Situation	Short; usually a few focused sentences	Frame the project, role and engineering issue.
Action	Longest section	Show personal engineering judgement, responsibility and competency evidence.
Outcome	Short to moderate	Close the loop with result, impact, approval, learning or risk control.

If the portal field feels tight, prioritize Action evidence. Remove background details first, then remove repeated wording, then tighten the Outcome. Do not remove the engineering decision itself.

How Validators Should Influence Your Writing

Validators should not write your examples, but they should be able to recognize and confirm the work. That means your example needs enough project context, dates, role information and specific actions for the assigned validator to connect the example to what they actually observed.

In validator and assessor review, the strongest examples are the ones a direct-knowledge validator can confirm and an assessor can evaluate without guessing. This is why vague phrases create risk even when the applicant did the work.

• Choose the validator while choosing the example, not after all examples are drafted.
• Assign each example to the person who directly knows that work.
• Write the example so the validator can identify the project and your contribution.
• Do not assume the validator will see unrelated examples or fill missing gaps for you.

Common SAO Writing Mistakes to Avoid

• Writing a job description instead of a specific competency example.
• Using ‘we’ throughout the Action section so the applicant’s role disappears.
• Explaining the project background but not the engineering decision.
• Listing software, meetings or documents without showing how they were used.
• Adding an outcome that does not connect to the action or competency.
• Trying to answer too many competencies in one example.
• Choosing a validator who cannot confirm the specific work.
• Submitting examples with implied evidence, unclear dates or unexplained responsibility.

Also Read: EGM CBA Examples: What Strong Evidence Looks Like and 12 Mistakes to Avoid

Safe SAO Planning Template

Use the template below as a planning tool. It is not copy-ready wording. Replace each prompt with genuine details from your own engineering experience.

SAO Section	Planning Questions	Target
Situation	Where did this happen? What was your role? What engineering problem, constraint or requirement made the work important?	Brief context
Action	What did you personally calculate, assess, design, check, decide, communicate, verify or recommend? Which standards, tools or engineering principles shaped your decision?	Main evidence
Outcome	What changed because of your work? Was a risk reduced, design accepted, issue resolved, decision made, quality improved or lesson applied?	Result and impact
Validator fit	Who directly knows this work and can confirm your role?	Verification readiness

Weak SAO Plan vs Stronger SAO Plan

The comparison below is intentionally fictional and incomplete. It shows planning direction only, so applicants do not copy a ready-made example.

Section	Weak Plan	Stronger Plan
Situation	Worked on a pump project.	During a 2025 plant upgrade, I supported pump selection for a cooling-water loop where the operating point changed after a process revision.
Action	Used calculations and talked to the team.	I recalculated flow and head requirements, checked the curve against NPSH margin, compared two pump options and recommended the model that reduced cavitation risk.
Outcome	The project was completed.	The selected pump met the revised duty point, the recommendation was accepted by the lead engineer, and the design package moved to procurement with documented assumptions.

Final Self-Review Checklist Before You Save the Example

• Does the Situation identify one specific project, task or problem?
• Does the Action use first-person wording and show what I personally did?
• Does the example show engineering judgement, not only attendance or participation?
• Have I named the relevant code, standard, calculation, tool, process, risk or decision where it matters?
• Does the Outcome show what changed because of my action?
• Can my assigned validator confirm the example from direct knowledge?
• Does the example match the selected competency and rating level?
• Have I removed implied evidence and generic claims?
• Have I avoided invented, embellished, copied or third-party-created workplace examples?

Conclusion

The Situation, Action and Outcome method keeps EGM CBA competency examples focused on evidence. Start with the right competency, choose a verifiable project, keep the Situation brief, make the Action specific and personal, and close with an Outcome that proves the value of your engineering decision.

The best examples are not the longest ones. They are the examples that help validators confirm your work and help assessors see the competency without guessing.

Frequently Asked Questions

1. What is the SAO format for EGM CBA?

SAO means Situation, Action and Outcome. Situation gives context, Action explains what you personally did, and Outcome explains the result or impact of your work.

2. How long should an EGM CBA example be?

It should be long enough to show the competency clearly without becoming a full project report. The Action section usually needs the most detail because it carries the evidence.

3. Can I use the same Situation for more than one competency?

Yes, one project situation can support more than one competency, but each example should have a different Action focus that matches the selected competency.

4. Should I write EGM CBA examples in first person?

Yes. First-person wording helps identify your own responsibility and contribution, especially when the project was completed by a team.

5. Can I use bullet points in my CBA example?

Point form can work when it is clear and complete. The key is not paragraph style; the key is whether the evidence shows Situation, Action and Outcome without gaps.

6. What should I avoid in the Action section?

Avoid vague wording such as participated in, assisted with or involved in unless you immediately explain the exact engineering work you performed.

7. Can AI write my EngGeoMB CBA examples?

No. AI or third-party-created workplace examples are not appropriate. Safe help should be limited to organizing, editing and clarifying genuine applicant-owned experience.

8. Where can I get help with EGM Manitoba competency report writing?

You can get support with structure, clarity, evidence mapping and review of your applicant-written examples through EngGeoMB competency report writing support, without replacing your own work history.