Technical Competency 1.4: Developing Engineering Solutions Beyond Standard Designs

When practicing engineering, solutions are not always straightforward; they cannot always be obtained solely by referencing an approved standard or applying conventional calculations. Often, complex constraints arise from meeting specific environmental conditions, operational requirements, or financial limitations, where standard methods fall short. In such cases, engineers need to think creatively and apply customized engineering that best balances performance, risk, and cost. This forward-thinking capability requires engineers to have a strong understanding of the fundamental engineering principles that drive every aspect of the engineering solution and how each element integrates into the broader engineering system.

Description of Technical Competency 1.4:

The purpose of technical competency 1.4 is to assess the very capability of a prospective engineer to apply a theoretical understanding of engineering concepts to design unique solutions, especially where off-the-shelf approaches cannot be applied.  Technical competency 1.4, as outlined in the Competency-based assessment (CBA) guidelines published by most Canadian professional engineering regulators using the 34-competency framework, is as follows:

“You apply engineering knowledge to design solutions.”

The other regulators that use the 22-competency framework, such as APEGA, Engineers Yukon, and NAPEG, define this competency as follows:

“...ability to use engineering knowledge and theory in the development of engineering designs, process systems, operations, or technical solutions…”

Preparing Technical Specifications: Setting the Foundation for Unique Design

Technical specifications are fundamental to complex engineering projects, bridging non-technical client requirements with rigorous standards to shape engineering design. They should not be viewed as mere checklists derived from past projects but as dynamic documents grounded in theory and tailored to meet specific site needs. A well-written specification guides all project lifecycle decisions and translates end-user expectations into detailed engineering parameters.

Canadian National Master Specification (NMS), a comprehensive framework for writing "specifications," categorizes specifications as prescriptive or performance-based. Prescriptive specifications define the exact materials, components, and methods to be used—requiring targeted engineering analysis to confirm that these predefined choices meet all technical requirements. For example, specifying a particular cable or structural element demands load, voltage, or thermal performance calculations to ensure compliance.

On the other hand, performance specifications focus on the desired outcome, allowing for flexibility in meeting requirements. This approach requires broader engineering analysis to define measurable targets without going into the specifics of the engineering analysis that may be conducted to achieve those targets.

The Specification Development Process:

1.    Requirements Gathering:

The process begins with a thorough understanding of what the system or infrastructure must achieve. This involves identifying the client's goals, safety considerations, environmental conditions, operational needs, and applicable regulatory frameworks. At this stage, stakeholder engagement is critical. Engineers consult with operations, construction, maintenance, and other relevant parties to ensure that the functional expectations of the end solution are fully understood and documented.

2.    Research and Source Review:

Once the requirements are defined, engineers conduct research to identify applicable industry standards, best practices, previous project experiences, and available technologies. Benchmarking against similar systems and/or consulting supplier documentation helps identify technical constraints and opportunities for innovation. This step ensures the solution reflects current knowledge and is informed by practical implementation considerations.

3.    Engineering Analysis:

Knowledge of engineering theory plays a key role at this stage. Using calculations, simulations, and trade-off studies, engineers evaluate performance parameters and refine system requirements. This prevents arbitrary or copied specifications from past projects and ensures that the parameters under investigation reflect the project’s specific needs.

4.    Drafting the Specification:

Specifications are drafted in a structured format, typically beginning with general requirements, followed by detailed descriptions of the required products or systems, and ending with execution and verification procedures. The document must clearly define performance criteria, materials, installation standards, testing methods, documentation requirements, and commissioning expectations. Precision and clarity are essential to avoid ambiguity, minimize risk, and ensure alignment between design intent and execution.

5.    Stakeholder Review and Alignment:

Draft specifications undergo internal review involving procurement, legal, construction, and asset management teams. The goal is to confirm that the specification is not only technically correct but also commercially viable and constructible. Feedback from this stage is critical in identifying potential conflicts, omissions, or misinterpretations that could affect project delivery.

6.    Finalization and Publication:

Based on stakeholder feedback, specifications are refined and finalized. Care is taken to ensure consistency across documents and compliance with overarching project requirements. The final version becomes a foundational part of tender documents, contract requirements, or design packages, providing clear direction to vendors, contractors, and reviewers throughout the project lifecycle.

Bringing it all together - Validation & Verification (V&V) of Technical Specification  

Technical specifications do not conclude upon publication; their relevance continues throughout the lifecycle of the project or product. Each engineering phase—from concept to commissioning—must be traceable to the original specification to ensure the delivered solution performs as intended. The V-model, as shown in Figure 1, is an essential element of systems engineering that formalizes the alignment of each specification development layer with its corresponding verification activity. On the left arm of the V, the process is decomposed into progressive layers, starting from defining user requirements and then proceeding into developing systems and subsystems' technical specifications and designing and building what is specified.

On the right arm of the V, the model mandates corresponding validation and verification steps that mirror the original specification hierarchy. For example, if a performance-based specification defines a substation’s thermal dissipation capacity under worst-case load, this must be validated through a defined test method or simulation that confirms compliance under those exact parameters.

Figure 1: Simplified V-Model (adapted from Clark, 2010, Northrop Grumman)

The V-model ensures that each engineering decision made during design, procurement, and construction remains consistent with the documented requirements, thereby preventing scope drift or misalignment between design intent and delivered function. This closed-loop is particularly useful in complex and innovative engineering designs, where performance assurance must be earned through disciplined traceability and rigorous engineering confirmation.

When Standard Designs Don’t Fit - Unique Solutions from Practical Examples

There are scenarios where engineers must go beyond minimum standards or responsibly deviate from approved norms to address specific project needs. Standards provide a baseline for safety, performance, and code compliance, but they are not always sufficient to meet the demands of complex environments, site limitations, or stakeholder expectations. In such cases, engineers rely on advanced simulations, detailed calculations, and empirical data to demonstrate that their custom designs are technically sound, safe, and suitable for long-term use. Exceeding minimum standards may be necessary to enhance durability, reduce lifecycle costs, or accommodate environmental factors. Similarly, a deviation from approved norms—though it must follow rigorous validation and approval processes—is often justified when space limitations, integration constraints, or operational needs cannot be met using standard configurations.

Civil Engineering Example –

In Ontario's Highway 407 East extension design, initial pavement structures were developed using the 1993 AASHTO Guide for Design of Pavement Structures. To ensure long-term performance under high traffic volumes and varying environmental conditions, these designs were further evaluated using mechanistic-empirical methods, including the Shell BISAR program and asphalt concrete fatigue damage models. This rigorous analysis led to enhancements in the pavement design, surpassing standard requirements to achieve greater durability and sustainability. 

Electrical Engineering Example –  

Due to space constraints in Toronto Downtown’s urban core, Toronto Hydro, a local electricity distribution company, opted for an underground design for the Copeland Transformer Station, marking it as only the second underground transformer station in Canada. This decision necessitated a departure from traditional air-insulated transformers to gas-insulated transformers (GITs), which are more compact and suitable for confined spaces. To ensure the safety and reliability of this deviation, engineers conducted comprehensive analyses, including load flow studies, fault simulations, and thermal performance evaluations. These studies validated that the GITs would meet or exceed the performance of conventional systems.

Additionally, the station's underground location near Lake Ontario required innovative flood protection measures. Engineers designed a "bathtub" structure with caisson walls, waterproof membranes, and reinforced concrete to prevent water ingress. Redundant sump pumps with emergency power supplies were also installed to manage potential water accumulation. 

Guidelines on Demonstrating Use of Engineering Theory and Calculations

1.    Clearly Define Your Technical Contribution

Specify the engineering problem you addressed, your role in the analysis or design process, and how your work differed from standard practice. Avoid describing general project outcomes—focus on the unique engineering challenge you solved.

2.    Explain the Analysis Conducted and Its Necessity

Identify the specific calculations, simulations, or design studies you performed (e.g., harmonic analysis, thermal loading, structural modeling), why they were necessary, and how they informed the design or specification choices.

3.    Justify Alternatives and Design Decisions

Outline the options you considered—including standard methods—and explain why they were insufficient. Describe how your analysis supported a more effective, safer, or cost-efficient solution, especially if it involved exceeding or deviating from typical standards.

4.    Demonstrate Risk Management and Compliance

If your design deviated from established codes or norms, explain how you validated its safety and performance through engineering judgment, modeling tools, or peer reviews and how the solution was reviewed or approved within the regulatory or quality assurance process.

Conclusion

Technical Competency 1.4 emphasizes an engineer’s ability to move beyond routine applications of codes and standards to develop innovative, technically sound, and context-specific solutions. Demonstrating this competency requires more than showing project involvement—it involves articulating how your engineering analysis led to decisions that addressed unique constraints, improved performance, or mitigated risks. Whether specifying non-standard equipment due to spatial limits or refining a design based on advanced simulations, your contributions must clearly apply engineering theory and critical decision-making rooted in professional judgment.

Disclaimer:

The information provided in this blog is for general informational purposes only. While every effort has been made to ensure the accuracy of the content, the author does not guarantee the technical precision or completeness of any project details mentioned. The views expressed in this blog are based on publicly available information and personal insights and may not reflect the latest developments or technical changes. Readers should verify all technical information and consult relevant professionals before making any decisions based on the presented content.