> For the complete documentation index, see [llms.txt](https://monasheng.gitbook.io/zerotohero/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://monasheng.gitbook.io/zerotohero/cots-parts-zero-to-hero/cots-principles/project-risk.md). # Project Risk The engineering design process is fraught with *risk*. Here, this term extends well beyond the obvious connotations around safety. Every decision - from initial concept selection to detailed component specification - introduces uncertainties that can upend a project, inflate its cost, extend its timeline, or compromise its performance. Poorly managed risk can derail schedules, exhaust budgets, erode stakeholder confidence, and in serious cases, create safety hazards. ## Categories of Risk Engineering projects are exposed to a wide range of risks, many of which are interrelated. #### Safety Risk Safety risk is the obvious use of this term, and concerns the potential for harm to users, operators, maintainers, or manufacturers. Poorly considered designs can introduce hazards ranging from mechanical failure to electrical shock, fire, or environmental exposure. Beyond the human cost, safety failures expose designers and organisations to legal liability, regulatory scrutiny, and loss of trust. It is very common that inexperienced designers produce parts which include burrs or sharp edges, pinch points, or other hazards, as a result of a poorly-considered manufacturing pipeline. #### Technical Risk Technical risk is the next most obvious - and the one that engineers tend to fixate on. As engineers, we often worry about underdesigned components failing under load or systems not meeting performance targets, yet many projects are derailed by more mundane issues: parts that do not physically fit together, incompatible connectors, ambiguous requirements, incorrect assumptions about interfaces, or 'unassembleable' assemblies. Apprentice mechanics love to bemoan 'amateur' mechanical engineers who place oil filters or bolts in impossible-to-reach locations, requiring bespoke "special service tools", for example.

This "special service tool" is required to lock the crank for service of some Mazda engines. Sometimes, the need for these tools is well-considered as part of the design process. Often, they are a band-aid fix put into place once servicability issues are discovered. From: https://www.maruhamotors.co.jp/miata/parts/sst.php

These seemingly minor technical oversights frequently cascade into timeline delays and financial consequences. #### Financial Risk Financial risk arises whenever engineering decisions influence cost - e.g. via design errors, rework, warranty claims, or production inefficiencies. In some contexts, the client bears the direct financial impact of mistakes. In others - especially publicly-funded or fixed-price projects - cost overruns can transfer liability to the engineering firm or trigger broader reputational damage. A common logical fallacy that new designers fall into is assuming project or technical risk via the in-house design or manufacture of parts in order to avoid the financial outlay associated with using a COTS solution. Adam Savage (of Mythbusters fame) [said it best](https://www.youtube.com/watch?v=en7deA6dE7Y\&t=903s): > ## Not enough money to do it right, but plenty of money to do it twice." #### Timeline Risk Timeline overruns are not merely inconvenient; but compound rapidly. Most engineering projects are structured around staged development with limited contingency, and delays in one phase can propagate into subsequent stages. Project management tools, like Gantt Charts or Activity on Arrow (AOA) diagrams can help illuminate these dependencies, but even the best laid plans can quickly come unwound when unexpected delays occur.

A simple AOA diagram for building a house. Any delay in the critical path (e.g. milstone 2) will affect multiple subsequent processes. From: https://images.wondershare.com/edrawmax/article2023/network-diagram-aoa/pert-network-diagram-for-house-construction-template-3.png

Missed milestones often result in idle labour or wasted machine time, as well as potential contractual penalties and lost market opportunities. These consequences frequently translate timelines risk into financial exposure. #### Reputational Risk Reputational risk extends beyond the success or failure of a single product. High-profile engineering failures, such as [the battery fires that led to the global recall of the Samsung Galaxy Note 7](https://www.theguardian.com/technology/2017/jan/23/samsung-blames-faulty-batteries-for-causing-galaxy-note-7-fires), or the [design and certification failures associated with the Boeing 737 MAX](https://apnews.com/article/boeing-plea-737-max-crashes-b34daa014406657e720bec4a990dccf6), demonstrate how technical decisions can escalate into worldwide scrutiny, regulatory intervention, and long-term damage to public trust. {% embed url="" %} Trust, once lost, is difficult and expensive to rebuild, and the reputational consequences of such events can far outlast the immediate technical and financial impacts of the original failure. #### Maintenance and Lifecycle Risk Engineers remain responsible for what they ship long after it leaves the factory floor. This responsibility may be formal, through warranties, service contracts, or regulatory obligations, or informal, through an ongoing reputational covenant with customers and stakeholders. Poor decisions during design can create long-term maintenance burdens, spare parts challenges, and lifecycle costs that far exceed initial development savings. ## Derisking Managing risk in engineering projects requires deliberate, structured action. This includes early and sustained stakeholder engagement to clarify requirements, structured design reviews to challenge assumptions, rapid prototyping to expose weaknesses, and disciplined documentation to ensure traceability of decisions. Projects that surface uncertainty early are better positioned to respond while options remain inexpensive. The [MacLeamy curve](https://www.danieldavis.com/macleamy/) describes this phenomena, which holds true in range of industries and applications:

From: https://www.danieldavis.com/macleamy/

Take note that: * Invariably, as one moves through the [Product Development Life Cycle](/zerotohero/cots-parts-zero-to-hero/cots-principles/product-development-life-cycle.md), from concept toward execution, and as design decisions are made, suppliers engaged, funds expended, and time committed, the ability of the project team to effect change is reduced. * At the same time, changes made late in development come with an exponential increase in cost. * A well-executed project will invest the most effort in the early stages of design - through rigorous review and revision of the concept and early prototypes, failing early, often, and cheap. * A typical project fails to do so, and bears the inevitable high-costs associated with late-stage changes. One of the most effective strategies for reducing technical and schedule risk is to minimise unnecessary innovation. **While innovation is essential in areas that differentiate a product, it is rarely justified in subsystems that solve well-understood problems.** {% hint style="info" %} :man\_mage: **Key Point:** Utilising COTS components allows engineers to leverage existing validation, manufacturing maturity, and field experience. Deliberate integration of COTS parts reduces the number of variables under active development and concentrates effort on aspects of the system where bespoke work genuinely adds value. {% endhint %} ### Risk Tolerance The degree to which innovation is balanced with risk will vary project-to-project, organisation-to-oganisation, and industry-to-industry. A venture-backed startup may accept higher technical risk in pursuit of competitive advantage, whereas a defence contractor or medical device manufacturer may operate under stringent regulatory and safety constraints. The acceptable level of risk also depends on who bears the consequences; whether you are designing as a contractor with fixed deliverables, an employee within a larger organisation, or a researcher exploring uncertain territory. Importantly, the more uncertain the underlying problem, and the more constrained the available resources (time, funding, personnel), the more risk-averse a project should be in its architectural decisions. When timelines are tight or budgets limited, introducing avoidable technical uncertainty through bespoke component development is rarely prudent. In such contexts, deliberate reliance on COTS solutions is not conservatism, but rather sound engineering judgement.