Engineering Delivery and Business Value
What a Feasibility Study Should Deliver
Learn what documents clarify buy, integrate, upgrade or custom-build decisions.
You need to size or verify a real system using “What a Feasibility Study Should Deliver”, with units, duty and limits that match the application.
Learn how a paid feasibility study turns an uncertain machine idea into traceable requirements, alternative concepts, preliminary architecture, risks, cost and schedule ranges, and a reasoned buy, integrate, upgrade or custom-build recommendation.
- Select or check first
- Review. Walk stakeholders through requirements, alternatives, evidence gaps and the recommendation; capture disagreements rather than smoothing them away.
- Controlling assumption
- Requirements, exclusions, evidence, responsibilities, acceptance criteria and change control are explicitly agreed.
- Top risk
- A weighted score is not the decision. Mandatory criteria should be checked before totals are compared. Record how scales and weights were defined, test whether reasonable changes alter the ranking, and keep qualitative risks visible. A high score cannot make an unsafe, noncompliant or physically infeasible option acceptable.
- Proof
- Commission the next phase. Issue a bounded scope with deliverables, responsibilities, acceptance criteria, assumptions and change control.
Start with the basics Optional foundation before “What a Feasibility Study Should Deliver”
Engineering-project basics
A build becomes controllable when the need, assumptions, interfaces, evidence and ownership are written before hardware choices become difficult to reverse.
- Requirement
- A requirement states a necessary, testable outcome or constraint. A preferred solution is not automatically a requirement.
- Assumption
- An assumption is treated as true for a decision but still needs an owner, evidence and a plan for what happens if it is wrong.
- Verification and validation
- Verification asks whether the design meets its specified requirements. Validation asks whether the delivered result solves the user’s real need in its intended setting.
- Prototype and production release
- A prototype answers selected questions. Production release additionally needs controlled parts, repeatable assembly, acceptance evidence, service information and change control.
- Scope and change control
- Scope defines included work, deliverables, interfaces and exclusions. Change control records why an approved baseline changes and what cost, schedule or risk follows.
How to use this article: For every decision, record the owner, evidence, acceptance criterion and condition that would force the decision to be reopened.
On this page
A useful feasibility study does not promise a finished machine in miniature. It reduces the uncertainties that matter to the next decision. It should show what problem is being solved, which evidence was examined, what alternatives remain credible, what risks could change the result, and what work is still required. The value is a defensible decision package—not a thick report or a confident-looking rendering.
The study is a decision package with a declared boundary
Diagram description
The pictured pages are conceptual deliverables. Their exact names, depth and contractual status depend on the agreed study scope.
| Deliverable | What it should contain | Decision it supports |
|---|---|---|
| Problem and operating context | Users, product variants, present method, constraints, interfaces and success measures | Is the need understood well enough to evaluate solutions? |
| Requirements baseline | Prioritized, measurable functions, performance, safety, environment, maintainability and acceptance expectations | What must every viable option satisfy? |
| Current-state evidence | Site observations, cycle samples, drawings, utility data, failure history and stated data limitations | Which assumptions are supported and which need measurement? |
| Concept and architecture | Process flow, major subsystems, energy and information paths, interfaces and preliminary layouts | Can the proposed functions coexist as a system? |
| Alternatives analysis | Options, criteria, exclusions, evidence, uncertainty and sensitivity of the ranking | Should the organization buy, integrate, upgrade, custom-build or stop? |
| Risk and validation plan | Hazards, technical unknowns, mitigations, trials and evidence needed before commitment | What must be resolved next, by whom and at what cost? |
| Commercial range and roadmap | Basis-of-estimate, exclusions, likely schedule, milestones, dependencies and next-phase scope | What approval and budget are reasonable now? |
| Recommendation | Preferred route, rationale, conditions, rejected alternatives and explicit no-go triggers | What action is supported by the present evidence? |
The contracted scope should say which of these outputs are required and how mature they will be. A block diagram may be enough to compare concepts; a release-ready fabrication drawing is normally later work. Likewise, a preliminary hazard register identifies concerns but is not the completed machinery risk assessment or validation record. Calling each item by its maturity prevents a concept from being mistaken for a procurement specification.
Bind requirements to evidence before choosing equipment
| Confidence class | Example | How to present it |
|---|---|---|
| Observed | Timed production samples or identified utility measurements | Record date, method, sample, instrument and operating condition |
| Supplier-supported | A model-specific datasheet, quotation or application confirmation | Name revision, configuration, validity and supplier conditions |
| Calculated | Required torque, throughput balance or estimated load | Show inputs, equation or model, margins and responsible reviewer |
| Assumed | Future product mix, staffing pattern or floor-space availability | State the assumption and the decision sensitivity if it changes |
| Unknown | Material behavior, legacy code access or interface timing | Create a test, survey or supplier action with an owner and closure criterion |
Requirements should describe needed outcomes and constraints before they lock in a preferred machine. Throughput, permitted changeover, product range, reject handling, available utilities, access, cleaning, safe intervention and evidence for acceptance can all alter the architecture. A hidden requirement discovered after selection is not merely a documentation error: it can reverse the preferred option.
Compare real alternatives against the same criteria
Diagram description
More filled dots indicate the image's illustrative relative cost, time or fit; they are not universal ratings or quotations.
| Route | Often attractive when | Questions that can overturn it |
|---|---|---|
| Buy a standard machine | The process is common and a supported product meets mandatory requirements | Does the exact configuration handle every required variant, environment and interface? |
| Integrate proven subsystems | Suitable modules exist but must be joined into one line or control system | Who owns interface performance, safety integration and acceptance of the complete assembly? |
| Upgrade existing equipment | The mechanical asset is sound and a bounded control, sensing or guarding change creates value | Are drawings, access, capacity, condition and maintainability adequate for the new duty? |
| Custom-build | The differentiating process cannot be met acceptably by available products | Is the extra fit worth non-recurring engineering, validation, support and future obsolescence responsibility? |
| Do nothing or change the process | Benefits are weak, uncertainty is high, or a non-equipment change solves the constraint | Has the team compared operational, product and scheduling alternatives fairly? |
Use ranges to reveal uncertainty, not to hide it
| Study output | What to include | What not to imply |
|---|---|---|
| Cost range | Included work, currency/date, taxes and freight treatment, assumptions, exclusions, contingency basis and confidence | A binding fixed price for an undefined final design |
| Schedule range | Decision dates, supplier lead times, access windows, approvals, test duration and dependencies | A guaranteed completion date independent of client actions |
| Risk register | Cause, uncertain event, consequence, likelihood/consequence basis, mitigation, owner and trigger | That listing a risk has controlled it |
| Test proposal | Question, representative sample, method, success threshold and consequence of each result | That a convenient demonstration proves the whole system |
| Recommendation | Current best option, conditions, residual uncertainty and next decision gate | Certainty beyond the evidence collected |
Risk work in a feasibility phase should include machinery hazards as early design inputs. ISO 12100 describes risk assessment and risk reduction across relevant life-cycle phases. The study should identify applicable legislation and standards with competent specialists; a generic checklist or the presence of a guard in a concept image is not evidence that safety requirements have been satisfied.
End with an auditable handover and a next decision
Feasibility close-out
- ReviewWalk stakeholders through requirements, alternatives, evidence gaps and the recommendation; capture disagreements rather than smoothing them away.
- DecideRecord approve, revise, gather more evidence, select another route or stop, together with the authorized decision-maker and date.
- BaselineFreeze the reviewed document revisions and retain source measurements, calculations, quotations and decision rationale.
- Commission the next phaseIssue a bounded scope with deliverables, responsibilities, acceptance criteria, assumptions and change control.
A study becomes much stronger when it begins with explicit needs rather than a favored mechanism. Revisit From Machine Idea to Clear Requirements for the operating scenarios and measurable acceptance foundations that feed this decision package.
Selection boundary and evidence to keep with the decision
Treat “What a Feasibility Study Should Deliver” as a selection problem, not only a definition. Record the required result, alternatives considered, the controlling assumption and the condition that would change the choice.
Keep evidence proportional to consequence: Commission the next phase. Issue a bounded scope with deliverables, responsibilities, acceptance criteria, assumptions and change control. Revisit the decision when the load, environment, duty, interface, regulation or maintenance plan changes.
One-minute questions
Questions to answer before you apply this lesson
What should I select or check first for What a Feasibility Study Should Deliver?
Review. Walk stakeholders through requirements, alternatives, evidence gaps and the recommendation; capture disagreements rather than smoothing them away.
Which assumption can change the conclusion?
Requirements, exclusions, evidence, responsibilities, acceptance criteria and change control are explicitly agreed.
What can go wrong if I copy the example directly?
A weighted score is not the decision. Mandatory criteria should be checked before totals are compared. Record how scales and weights were defined, test whether reasonable changes alter the ranking, and keep qualitative risks visible. A high score cannot make an unsafe, noncompliant or physically infeasible option acceptable.
How do I verify the result in the real system?
Commission the next phase. Issue a bounded scope with deliverables, responsibilities, acceptance criteria, assumptions and change control.
Sources and further reading
- NASA Systems Engineering Handbook: Decision AnalysisNational Aeronautics and Space Administration · 2026-10-13Primary handbook guidance reviewed for decision criteria, alternative evaluation, assumptions, uncertainty, sensitivities, recommendations and decision reports.
- NASA Systems Engineering Handbook: Design Solution DefinitionNational Aeronautics and Space Administration · 2026-10-13Primary handbook guidance reviewed for alternative concepts, trade studies, cost, schedule, risk and documentation of design decisions.
- Safety of machinery — General principles for design — Risk assessment and risk reduction (ISO 12100:2010)International Organization for Standardization · 2026-10-13Official standard record reviewed for machinery life-cycle hazard identification, risk assessment, risk reduction, documentation and verification.