New Chinooks

[beerdrinker]

Without giving anything classified away, can somebody tell this retired airline pilot what exactly is wrong with the 6(?) Chinooks that have been delivered but not put into service. Something about software. But I thought apart from the FADEC the Chinook is not fly by wire.

Many thanks

[SirToppamHat]

beerdrinker

This has been much discussed in the past on this forum - have you tried a search?

Found this:

http://www.pprune.org/forums/showthread.php?s=&threadid=109805&highlight=HC3

STH

[Brian Dixon]

It's also probably something to do with not making the same mistake twice as well!!

[SASless]

Just why is it the Civvies buy hundreds of helicopters and don't seem to have the same problem?

Just what provoked the reluctance to buy an off the shelf set of kit for the aircraft?

Was it a case of Father knows best?

[The Helpful Stacker]

Just why is it the Civvies buy hundreds of helicopters and don't seem to have the same problem?

Well just a guess (what with me being a humble duvet technician) but perhaps its because Mr Bristows doesn't require a/c that can be operated in a military 3C environment and as such require certain avionics standards to operate alongside a/c already in service.

Just a guess like.

[Safety_Helmut]

THS
Your 'guess' has elements of truth in it. However, it is more to do with the woeful ineptitude that the MoD seemed to have displayed in this particular project.

Safety_Helmut

[RileyDove]

Safety - I think thats a little unfair! The words 'Woeful ineptitude' could be applied to any number of Mod projects!

[beerdrinker]

STH,

Thanks for the link and my apologies for not doing the correct search myself.

Jackonicko's lengthy reply contained all the answers I was after.

[southside]

Are these procurement problems really the fault of the MOD or are they the fault of the requirements? If you make the requirements too stringent then surely there will be problems with the procurement.

[BossEyed]

Who produces the requirements, Southside?

[tucumseh]

"Who produces the requirements, Southside?"



OR / DEC!!!!

[strek]

I.E. THE OPERATORS

[JNo]

Are these procurement problems really the fault of the MOD or are they the fault of the requirements? If you make the requirements too stringent then surely there will be problems with the procurement

If the requirements aren't stringent enough to specify exact requirements (as I beleive was the case with the wokkas in question) then the deliverable simply won't meet the customer requirement. Requirements should be in written down to the most minute of details

[FJJP]

The knowledgable end user [or his equally knowledgable rep] writes the spec. Bear in mind that this exercise alone can take a considerable amount of time.

Then it is staffed up the chain to the PE. That's where the problems start. People with little or no recent operational knowledge start chopping bits out to save money. Despite front end protests, the PE decisions hold sway and the user ends up with a compromise.

I saw this process in operation twice in a major way. The worst was when the front line spoke to the only manufacturer during the writing process to ascertain what was available and workable. The manufacturer, on receipt of the revised PE spec, rang the guy who wrote the original to be told that it wouldn't work. PE was adamant that it would [the manufacturer didn't know what he was talking about and was trying to diddle us - I kid you not!].

Said system was installed at a cost of £X squillion - when we fired it up for the first time in the ac the system promptly crashed and the fix cost £X squillion extra. Total cost = £original + lots more besides.

PE don't like buying off the shelf because otherwise they would have difficulty justifying their posts.

[John Blakeley]

The following quote from the PAC report on Battlefield Helicopters is a good summary (HC 386 dated 18 Mar 2005 if you want to look up the complete document on the Parliamentary website):

"The gap in helicopter numbers has been exacerbated by the fact that the Department cannot use 8 Chinook Mark 3 helicopters purchased in 2001. The Department failed to specify what its requirements were for independently validating the anufacturers’
software codes and therefore are currently unable to assure themselves that the helicopters can fly safely. Only 45 of 100 ‘essential elements’ set out in the Department’s requirement
were actually specified in the contract. This was one of the worst examples of equipment acquisition that the Committee has seen."

The PAC has also again commented in HC 742 published 6 December:

"In 2000, our predecessors criticised the procurement by the Ministry of Defence of the Chinook Mark 2 helicopter in a contract worth £143 million. There were significant technical problems with accepting the Chinook into service, which may have contributed to the tragic crash of Chinook ZD-576 in June 1994."

Any similarities of problems or procurement failings between the procurement of the Mk 2 and the Mk3 are, of course, purely coincidental!

[Flatus Veteranus]

If the requirements aren't stringent enough to specify exact requirements (as I beleive was the case with the wokkas in question) then the deliverable simply won't meet the customer requirement. Requirements should be in written down to the most minute of details


The procurement cycle (from AST to entry into service) can take 20 years. In this time the technology moves on. Through Target Definition to Project Development there is an iterative process between the the "Specifiers" ie the customers and the providers, ie the industry. There should be trade-offs - ie, the industry might say "if you can give us a little bit on the spec here, we can give you whole lot of over-spec there at the same price. To freeze a spec for 15 or 20 years would be absolute stupidity and would guarantee an obsolete product years before entry into service. I was involved in OR with the Tornado FCS and cockpit displays during the final stages of development and we had some difficulty convincing the Krauts of this point. They were apt to pound the table and insist on the strict minutiae of specs written years previously. Since they did not at that stage have much experience of indigenous aircraft design and development, that was understandable. And we learnt a bit from their very thorough staff work and preparation for tri-national meetings.

But when buying a foreign, eg American product off the shelf, it would be wise to accept that all the home work has been done and accept what is in the catalogue. I did not follow the Chinook scandal closely, but there was a distinct whiff of grinding axes.

Historically the most successful aircraft have resulted from the briefest Operational Requirements. The Spitfire's was, I believe, only two pages of foolscap. (A4 did not then exist)

[tucumseh]

I won’t try to dissect Jackonicko’s excellent post of 21.05.04, but follow the link above and give it a read.

It says;

“Of the 100 "essential elements" outlined in the requirement, the contract delivered 55. Most of the 45 elements not delivered, could not be included owing to immature technology, but the NAO was unable to discover an audit trail to explain why these remaining elements have never been contracted for”.


To uncover an audit trail, the NAO would have to understand responsibilities and ask the right people for the right documents. (The VCRI in this case).

To me, the main issue with Mk3 is that it couldn’t get through MAR (a safety orientated process) at or near the delivered configuration. A viable contract is essential in the first place, including a contractual link to successful MAR. I can only offer an opinion, and very senior people disagree with me so who am I to argue, but I don’t think a PM should accept off-contract if he knows, or even suspects, that the product won’t get through MAR. And those who condone it should be sacked.

The NAO notes that the 45 undelivered “essentials” were not contracted in the first place. Such omissions can only occur with the express agreement of the Customer. DPA cannot arbitrarily cut requirements out, but can prompt a trade-off process. The rule of thumb is that 80% is ok, but drop below that and the viability of the project is questioned. And, it is not a simple case of trading these out; often they must be compensated for in some way. The NAO cites immature technology but does not mention if the requirement was matched by funding to develop the technology, or what readiness level the technology was at before committing to full development and production. The tracking of readiness levels is a much trumpeted aspect of “Smart Procurement” but like most of the initiative is a complete no-brainer and long-mandated policy.

Also, I think there is confusion over the “Requirement” and the “Specification”. FV is not wrong – a brief “requirement” is a Godsend to a project manager. He can then get on with having a specification prepared and agreed by people who know what they’re talking about and which matches the budget.

[Safeware]

Beyond the initial problems with requirement alluded to above, another big issue is requirements creep, where the MOD keeps going back and asking for (seemingly) little changes. These actually add significantly to cost and time over-runs.

sw

[tucumseh]

Extract from Defence Industrial Strategy White Paper published today.



Assessments are also well underway on the work necessary to field the 8 Chinook Mk3s procured from Boeing in the late 1990s which are not in service as we have been unable to certify their
airworthiness. A decision will be taken next year on whether to proceed.


Also mentions Mk2/2A coherence programme.