Demoralised
A good first post, if I may say so. I’d take issue on a few minor points but the thrust is excellent.
almost everyone assumes that the fault is with the aircraft engineering
That may be the view of Joe Public or elements of the press, but the real cause was predicted almost immediately and came to pass with depressing inevitability. The question never asked is why corrective action was not taken at this time.
The fact is that too many people have had their fingers burnt with the Chinook FADEC software analysis and certification issues, the crash, and all the subsequent enquiries. No-one has dared make the pragmatic decisions for HC Mk3 that have been taken on other
I agree the Mull experience is a large factor here, but believe one should look deeper at the very obvious breakdown in relationship between Boscombe and elements within MoD(PE). (I say “elements” because, as I’ve said above, other programmes of greater complexity were, and continue to be, delivered with effortless competence. The question “Why” is never asked).
In very simple terms, you engage with Boscombe from Day 1, not as an afterthought. That they were once MoD and are now QinetiQ matters not, the principles are the same. It just costs more now. You adopt a JOINT approach to trialing, validation, verification, acceptance etc. You agree boundaries of responsibility. That is, you place both industry and Boscombe under contractual obligation to work together from day 1, thus eliminating as far as possible any nasty surprise late in the day, for example if Boscombe are forced to regress, catch up or are faced with software which they cannot verify in accordance with the standards imposed on them. Ask anyone who has worked at Boscombe what their biggest problem is. They’ll say, lack of communication, we’re engaged too late in the day, the bane of our existence is project offices who ignore our advice and insist on accepting unsafe aircraft or equipment – and so on. But they’ll temper that with the fact many project managers know the score and never experience a single problem with Boscombe, ever.
Crucially, you make sure you adhere to the regs covering feedback. If the project office doesn’t agree with Boscombe, you talk. You offer reasons why you don’t agree or are not accepting their advice. What you DO NOT do is blank Boscombe and leave them seething. It leads to toys being thrown. If you drill down through Mull and Mk3 you’ll eventually narrow it down to a small number of boneheads who couldn’t stand the thought of some jumped up Boscombe type highlighting the fact the simple regs weren’t followed. And, given the timeframe, you’ll find the same names crop up.
None of this is new and it wasn’t new in 1995.
One other cause of the problems that seems not to have received much comment is that if most of the people on a project change part way through, through retirement or whatever, key aspects of their approach may get lost too
.
It’s certainly an inconvenience but I go back to what I said. Others managed fine. Why? Achieving a seamless transition is easy if the basic groundwork has been robust and the correct people are selected. Eliminate the fixed problems (by early Risk Reduction), use your resources to manage the variables.
There is more, but I just wanted to concentrate on the breakdown of relations between PE and Boscombe. It’s crucial to both this and the Mull case.