Quiz: Do You Really Understand Requirements Gathering on Hardware Projects? (New PM Edition)

Ten questions that test the requirements habits hardware projects pay for

Ten multiple-choice questions on requirements gathering for hardware and construction projects. Each has one correct answer. The right answers reflect what works retrospectively across enterprise hardware programs — not necessarily what feels intuitive from a software background.

Work through them honestly. Score yourself: 8-10 correct means strong practice; 6-7 means typical for a new PM transitioning into hardware; below 6 means several habits worth revisiting before your first hardware project gets too far along. Rationales are provided for each answer.

Question 1

A hardware requirements document is signed by procurement, the PM, and the sponsor. Whose review is most often missing?

A. Legal B. The operations team that will run the system C. Finance D. The vendor's project manager

Correct: B. Operations team review is the most often missing review on hardware requirements documents. The team that will run the system has knowledge that procurement and project don't, and their absence from the review process produces requirements that procure correctly and operate poorly. Many enterprise programs treat operations review as optional; on hardware projects, it should be mandatory.

Why not A or C: Legal and finance reviews are typical and usually present. Why not D: The vendor's PM reviews the procurement contract, not the requirements document; their input is captured in the contract.

Question 2

A specification reads: 'The HVAC system shall maintain temperature within 2°C of setpoint.' What's missing?

A. A specific setpoint value B. The reason 2°C tolerance was chosen C. The measurement methodology D. All of the above

Correct: D. All three are missing. A specific setpoint value is needed for procurement. The reason for 2°C tolerance is needed for change conversations (if the vendor proposes 3°C, can you accept it?). The measurement methodology is needed for acceptance testing (does 2°C mean instantaneous or averaged?). Each absence creates a different kind of dispute.

Why each individual answer is incomplete: Specifications written without intent and methodology produce documents that satisfy procurement and fail operations.

Question 3

A hardware requirement says 'system shall be installed in Building 5.' What additional context should the document include?

A. Floor plan with dimensions B. Site access constraints (delivery routes, working hours, neighbors) C. Existing utility capacity D. All of the above

Correct: D. All three are part of site context. Floor plan is necessary but not sufficient — site access constraints can prevent delivery of equipment that fits the floor plan, and existing utility capacity can prevent operation of equipment that's been installed. Each is a distinct category of risk; each belongs in the document.

Why each individual answer is incomplete: Site context is multi-dimensional. The most expensive site-related surprises usually come from the dimension the document under-addresses.

Question 4

When should regulatory permit requirements be integrated with project requirements?

A. At project initiation B. When permits are submitted C. As an appendix to the main requirements document D. Only if regulators flag concerns

Correct: A. Regulatory requirements should be integrated at project initiation, not deferred. Late integration produces project plans that don't account for permit timelines, inspection cycles, or compliance requirements — each of which can stop the project entirely.

Why not B: Submission is too late; the project's design is already locked. Why not C: Appendix treatment signals 'less important' and produces requirements that don't get incorporated into design decisions. Why not D: Regulator flags arrive after the project has already been designed wrong.

Question 5

A stakeholder asks for a feature mid-procurement. The vendor hasn't been selected yet. What's the best response?

A. Add it to the requirements document. B. Note it as a 'nice to have' for the vendor to consider. C. Ask whether the feature is essential or preferred, and document accordingly. D. Defer to post-procurement change order.

Correct: C. Mid-procurement requests need classification, not automatic addition. Essential additions go into the requirements document and become part of the procurement; preferred-but-not-essential additions go into a separate evaluation criterion that lets vendors compete on it without being required to deliver it.

Why not A: Adding without classification can over-specify the procurement and exclude qualified vendors. Why not B: 'Nice to have' is the most common cause of inconsistent vendor responses. Why not D: Post-procurement change orders are the most expensive way to add features; pre-procurement integration is much cheaper.

Question 6

The vendor's proposal exceeds your specification. What's the best response?

A. Accept it; better than spec is a win. B. Ask the vendor to explain the trade-offs of the higher specification. C. Reject it; deviations from spec are non-compliant. D. Negotiate the price down.

Correct: B. Higher specifications usually have trade-offs — cost, delivery time, maintenance complexity, energy use. Asking the vendor to explain the trade-offs lets you make an informed decision rather than accepting an apparent benefit that may have hidden costs.

Why not A: Apparent over-delivery often hides downstream costs. Why not C: Rejecting compliant deviations as non-compliant is procurement bureaucracy that wastes opportunity. Why not D: Price negotiation is appropriate after trade-off understanding, not before.

Question 7

When is the right time to review requirements with the operations team?

A. At document drafting B. At sign-off, before procurement C. During design freeze D. At commissioning

Correct: B. Operations team review at sign-off catches operational concerns while changes are still cheap. Earlier (at drafting) is too early — the document isn't yet stable enough to review productively. Later (at design freeze or commissioning) is too late — changes at those points are expensive or impossible.

Why not A: Reviewing in-progress drafts produces feedback on items that may not survive the next iteration. Why not C or D: Operational issues identified at design freeze require re-baselining; identified at commissioning, they require live workarounds.

Question 8

A requirement reads: 'The system shall integrate with the existing SCADA infrastructure.' What's the most important question to clarify?

A. Which SCADA software the existing infrastructure uses B. What 'integrate' means in this context C. Who owns the SCADA infrastructure D. When the integration is required

Correct: B. The word 'integrate' is doing a lot of work. It can mean 'send data,' 'receive commands,' 'be visible,' or 'be controllable from.' Each meaning has different technical requirements and different costs. Clarifying the integration semantics is the highest-leverage clarification.

Why not A: Important, but secondary to integration semantics. Why not C: Ownership matters for handoffs but not for technical specification. Why not D: Timing matters for scheduling but not for requirements specification.

Question 9

A hardware requirements document is finalized and signed. The project takes 18 months. How often should the document be re-validated?

A. Once, at project handoff to operations B. Quarterly C. At major milestones (design freeze, fabrication, delivery, commissioning) D. Continuously, with every change order

Correct: C. Re-validation at major milestones balances thoroughness with overhead. Quarterly is too rigid; continuous is too noisy; once is too rare. Each major milestone has different validity questions: design freeze validates that the design matches requirements; fabrication validates that fabrication is to spec; delivery validates that what arrived matches what was ordered; commissioning validates that what was installed performs to requirements.

Why not A: Once at handoff catches problems too late to fix cheaply. Why not B: Quarterly is calendar-driven, not project-driven. Why not D: Continuous validation creates overhead without proportionate benefit.

Question 10

What's the single most important practice that distinguishes hardware projects that finish on schedule from those that don't?

A. Detailed specifications B. Strong vendor relationships C. Early integration of operational and regulatory requirements D. Aggressive change control

Correct: C. Across retrospectives on hardware projects, the practice most strongly associated with on-schedule completion is early integration of operational and regulatory requirements with technical specifications. Detailed specifications matter, vendor relationships matter, and change control matters — but the single biggest variance driver is whether the document the team works from accounts for operations and regulation from day one.

Why not A: Detailed specs without operational and regulatory context produce procurable documents that operate poorly. Why not B: Vendor relationships matter but cannot compensate for missing requirements. Why not D: Change control catches changes; integration prevents them from being needed.

The quiz is a 10-minute diagnostic. Its leverage is in the practices the questions point at, particularly operations team review (questions 1, 7) and early regulatory integration (questions 4, 10). For the corrective on the most common mistakes, see ten requirements mistakes on enterprise hardware; for the delivery-lead version of this same diagnostic, see the delivery lead version; for early detection on software, see spotting requirements problems early.