Subjects · Engineering & Technology
Engineering & Technology: Stakeholder simulation
Defend a design to the people who will pay for it, build it, maintain it and regulate it, which is the conversation engineering actually consists of and which coursework never rehearses.
What you'll be able to do: Defend a design to the people who will pay for it, build it, maintain it and regulate it, which is the conversation engineering actually consists of and which coursework never rehearses.
The absent people
A coursework design ends at the calculation and the drawing. In practice, that's where it starts being argued about.
The client wants it cheaper and sooner. The contractor wants to know whether it can actually be built with available plant and skills. The maintainer: the most systematically ignored stakeholder in engineering education, has to service it for thirty years, often at height, often in the rain, often having lost the drawings. The regulator wants to know which clause you're claiming compliance with. The user will do something you didn't plan for.
Every one of them will find a problem you didn't. And a design that's optimal on the calculation and unbuildable, unmaintainable or non-compliant is not a good design, it's an exercise.
How to run it
- Present the design and the reasoning, not just the outcome.
- Take one stakeholder at a time, in character, pressing on what they actually care about.
- Defend or concede explicitly. Saying "you're right, that's a real cost" is a legitimate and professional move.
- Find the conflicts. Cheap conflicts with maintainable; fast conflicts with safe. Naming the trade-off is the engineering.
- Revise, and say what you traded.
Here's my design and my reasoning: [..]. Play [stakeholder] and press me on what they'd actually care about. One objection at a time. Don't let me answer a different question from the one you asked. Then tell me which of my answers were arguments and which were assertions.
What each stakeholder asks
Client / cost. What does this cost, what's the cheaper option, and what do I lose by taking it? Whole-life cost versus capital cost is the argument, and students almost always optimise capital cost without noticing they've chosen.
Contractor / buildability. Can this be built in this sequence, with this plant, by people with these skills, in this weather? Tolerances that are fine on paper and impossible on site are the classic finding. "How does someone get their arm in there to do up that bolt?" ends a lot of designs.
Maintainer. How do I get to it? What's the inspection interval? What happens when this part is discontinued? Can I replace it without taking the rest apart? This is the stakeholder whose absence causes the most avoidable misery, and a student who has never been asked these questions will design for installation rather than for service life.
Regulator. Which clause, and can you show me? What's the justification for this departure? Documentation isn't bureaucracy here, it's how the argument survives you leaving.
User / operator. What happens when I do the wrong thing? Designs that assume correct operation are a failure mode (article 01), and "someone would notice" is an assumption rather than a control.
Environment / community. Noise, disposal, decommissioning, embodied carbon. Increasingly a live constraint rather than a footnote.
The exercise that changes designs
Play the maintainer in year fifteen. The drawings are incomplete, the original engineer has left, and something has failed. Tell me what you find and what you wish I'd done.
This one produces more design changes per minute than any other prompt in the subject, because the maintainer's world is completely absent from a student's model and completely determines whether a design is good.
Across the disciplines
Civil and structural. Buildability and inspection access dominate.
Mechanical. Serviceability, spares availability, and tolerance stack-up in assembly.
Electrical. Isolation for maintenance, discrimination, and what happens during a fault while someone's working on it.
Chemical. Operability (startup, shutdown, upset conditions) which is where most incidents happen and which steady-state design ignores.
Software. On-call is the maintainer. "What does the person paged at 3am see, and can they act on it?" is the same question and equally absent from courses.
Industrial. The operator, and whether the process survives being run by someone tired at the end of a shift.
Pitfalls
- A polite stakeholder. If they accept your first answer, ask for someone harder.
- Answering a different question. The classic evasion under pressure. Have it called.
- Conceding everything. Defending a justified decision is the skill.
- Skipping the maintainer. The most commonly skipped and the most valuable.
- Treating trade-offs as failures. Every design is a trade. Naming it is the professional act.
- The tell: your design survived every stakeholder unchanged. They were too soft.
Try this today
Take your current design. Play the maintainer in year fifteen, incomplete drawings, original engineer gone, something's failed.
Write down what they'd say. Most students find at least one change they'd make before the end of the first paragraph.