ENGINEERING STORY 004
The engineering was easy.
Getting permission was hard.
Knowing what needs to be done is only half the job. You also have to get the organisation to act on it.
The engineer knew there was a problem.
Not a catastrophic one.
Nothing was on fire. No alarms were sounding. The project was still reporting green and the delivery date was still proudly displayed on the programme plan.
But something wasn't right.
THE PROBLEM
Each part worked. The system question had not been answered.
A change made late in the programme had affected an interface between two parts of the system.
Each part worked. The individual tests were passing.
But nobody had properly established what the change meant at system level.
The engineer went back to the requirements. He examined the architecture, traced the interfaces, reviewed the verification evidence and looked at the outstanding risks.
His conclusion was straightforward. More work was needed before the system could properly be considered ready.
THE ANSWER
"We haven't got time."
Technically, his argument was difficult to fault.
So he produced more evidence.
Requirements traces showed where assumptions had changed. Interface analysis showed where behaviour had not been demonstrated. Verification evidence showed what had been tested and, more importantly, what had not.
He explained the systems engineering process.
He explained why further analysis was necessary.
He explained why the existing evidence was not enough.
The programme listened politely.
Then it carried on.
HE WAS RIGHT
But being right wasn't enough.
The delivery date mattered.
The customer was waiting. People had been promised things. Money had already been committed.
Every additional piece of engineering sounded like another reason why the project could not deliver what it had promised.
The engineer was becoming increasingly frustrated.
He was right. Why couldn't they see it?
THE QUESTION THAT CHANGED IT
"What decision do you actually need them to make?"
An experienced engineer looked through the evidence.
He did not find a new technical problem.
He did not discover a missing requirement or produce a cleverer model.
Instead, he asked one question.
What decision do you actually need them to make?
That changed everything.
THREE CHOICES
The next meeting contained no lecture on systems engineering.
There was no explanation of lifecycle models, requirements methodology or verification strategy.
There were three choices.
Option one: do the additional work now. It would cost money and move the programme by two weeks.
Option two: do a smaller piece of targeted work that would answer the most important questions, accepting some remaining uncertainty.
Option three: deliver on the existing date and formally accept the identified risks.
CONSEQUENCES
Now management had something it could use.
If the concern proved unfounded, the programme would have spent some additional time and money gaining confidence.
If it proved correct after delivery, the consequences could include rework, operational disruption and a recovery considerably longer and more expensive than the work being avoided now.
Nobody was told what decision to make.
Management was given something much more useful.
A decision it could understand.
WHAT CHANGED?
The engineering hadn't changed.
The requirements were the same.
The architecture was the same.
The interface problem was the same. The verification evidence was the same. The risk was the same.
What changed was the engineer's ability to translate engineering into the language of the people responsible for the programme.
Cost. Time. Consequence. Choice. Risk.
THE REAL SKILL SET
Knowing the methods isn't enough.
Systems engineers are expected to master an extraordinary range of disciplines.
Systems thinking. Requirements engineering. Architecture. Modelling. Risk. Verification and validation. Configuration management. Lifecycle processes. Trade-off analysis. Interface management. Integration and testing.
Then there are the so-called soft skills: communication, critical thinking, stakeholder management and technical writing.
All of them matter.
But there is another capability that is harder to put into a competency framework: judgement.
JUDGEMENT
Good systems engineering is not doing everything.
It is knowing which methods matter for the problem in front of you.
It is knowing how deeply they need to be applied.
It is knowing when more analysis will genuinely reduce uncertainty and when you are simply producing more paperwork.
Systems engineering is about doing enough. The difficult word is enough.
THE OTHER SIDE
Sometimes management should say no.
Engineers can over-engineer.
Following every process to its maximum extent regardless of consequence is not engineering excellence.
If £100,000 of additional analysis is proposed to reduce a well-understood £10,000 exposure, management may be entirely correct to refuse it.
Managers have a system to operate too. They have budgets, contracts, customers, resources and delivery commitments.
Good systems engineering recognises those pressures as part of the system, not as an inconvenience outside it.
THE MISSING SKILL
Turn engineering into a decision.
Here is what we know.
Here is what we don't know.
Here are the choices.
Here is what each choice costs.
Here is the risk you accept with each one.
Now we can make a decision.
COMPETENCE
Knowing what needs to be done is only half the job.
A competent systems engineer needs the technical foundations.
Experience eventually adds something else: the ability to judge what is proportionate, explain why it matters and persuade an organisation to act.
Because knowing what needs to be done is only half the job.
You also have to get somebody to let you do it.
Engineering you cannot get implemented is just a very well documented opinion.
Competence is not just knowing the engineering. It is getting good engineering turned into action.
DISCUSSION
What do you think?
Engineering gets better when ideas are challenged. Share your view, experience or disagreement.
ENGINEERING STORIES
Leave a comment
Comments are reviewed before publication. Your email address is optional and will never be published. How comments are handled.