which goes back to the circle of debate that the technology sets and designs are done by and subsequently certified by various engineers – project managers can’t. the users don’t necessarily know the difference between a microwave and flat screen TV (being excessively unkind, but reinforcing a point)

anything that comes out of the “good idea fairies workkshop” has to get through the engineers before it can even be considered part of the project.

Again, you only provide perfect examples of what I was talking about earlier.

You cannot get accurate results with experimental (i.e. non working) tools and incomplete coupon tests.

The engineers are not allowed to halt the program to complete things like fundamental model validation or coupon testing. Instead the thing has to go half-cocked to meet some bloody deadline on some irrelevant spreadsheet.

Any engineer will tell you, if the program doesn’t start right, then it’ll fall apart. No foundations = f**ked. Yet the program managers will sacrifice everything to keep the program on track, particularly at the start – even though it is at that point where most of the big unknowns are encountered and have to be shook out. Therefore the foundations get sacrificed and as time progresses, with the program lagging behind time and budget, they get ever more desperate to make the program “appear” on track so cut even more corners. Right up until the point where they can hide it no longer.

You cannot even seem to differentiate between design, technology, hardware and software. As usual, the engineers will get blamed for not being allowed to run the program as they see fit, but instead must ram everything into someone else’s idea of how it should be (even worse, that someone else doesn’t have a clue).

when I refer to concurrency I am referring to the parallel build and development of mechanical and software solutions. eg plane frame, flight system

When the rest of us refer to concurrency and its problems, we refer to building production airframes while the prototypes are still flying around and finding problem after problem!

It is natural for the design to evolve with all parties working simultaneously. Indeed it is ridiculous not to. This not something that has not been done before – working on flight controls/aerodynamics/airframe/engines etc at the same time was ongoing long before there were ever program managers on the scene!

the processes successfully used by BAE are whats being used by LM for concurrent development of things like the the ewarfare/combat system deelopment…

And for the airframe.

The bit that is gonna give them the most headache in the long run.

Back to knowing what is important and what is not.

Hold on, thats why the F-22 also has multiple Blocks and where Block 1 is basically an orphan. A mature platform which is still demonstrating technical quirly bits. (accredited and approved by engineers)

Yep. Software and avionics updates.

Things that don’t fall off the damn aircraft, things that don’t require a fundamental redesign of the airframe.

If you want to play the game of the sanctity of engineering over all other elements in a project I’m up for giving more real life eaxmples of where its failed – but as I stated earlier, its a convenient and somewhat demonstration of intellectual indolence to travel that path.

You do realise how many lines of code are in the P8 – and that they’re using similar concurrent deveopment and engineering processes? Boeing also appear to be misguided. As were EB with the Virginias etc…. The latter being regarded as the gold standard on how to build a completely new platform entirely around the digital process and with a minimum of grief.

The P8?

You mean the same airframe as has existed for ohhh… how many years now?

Again…. knowing what is important and what is not.

[There is a common theme here]

there is no single controlling authority over the project. The project managers and the engineering managers have to work together. At a TRA level the engineering team can kill work immediately. Thats the whole purpose of the TRA

The engineers do not come up with the schedules.

The engineers are not allowed to halt the program to complete things like fundamental model validation or coupon testing. Instead the thing has to go half-cocked to meet some bloody deadline on some irrelevant spreadsheet.

thats nonsense. the program schedule has to be approved and validated by all – its not just the project management vision.

It pretty much is the project management vision. It bears no resemblance to reality whatsoever.

changes to scope, changes to load are immediately put through change control processes and have to be blessed by the approp review group

Yeah, changes. I’m not talking changes – I’m talking the initial **** up in schedules and the inertial of the program team preventing a total stop until fundamental ground work is complete.

and yet its not just the project managers who develop and initiate the timelines.

Yes it is.

They can’t “fudge” dates even if they wanted to.

ha ha ha.

How do you “pass” a CDR without any stress results – none – not a thing?

I know this has happened. I’ve seen it for myself.

Except project management isn’t done in isolation of the engineers.

It pretty much is. They live in a f**king dreamworld.

and no changes to how production can be made without the endorsement of the engineers, project sponsors (eg Government) and the Capability managers (who has to approve any production or build issues in consultation with the user/principle stackholders – ie Govt)

When the dreamers dream up the program schedule and the resulting ridiculous deadlines without pausing to consider what will need to be investigated – then changes are inevitable as production cannot begin due to late delivery of design.

Your approaching it **** about face…

in fact its the engineers who identify rapid changes that can be made and then propose them for review and endorsement.

Yep – the subsequent changes required to get the program technically ready. Changes (incurring additional expense and more time) that would not be required if the proper time was allocated up front to the task.

I can’t do squat without my engineers blessing every change, and they have the authority as they ARE the technical regulatory authority which I have to ensure that I comply with. As the TRA they are independant and can stop the project at ANY time. and I have seen it done.

You make the program timescales.

We cannot meet them as you don’t know what youse are doing when you dream them up.

It eventually gets to a point where the engineers say – stop, its simply not gonna work, this plan is getting too ridiculous. Then the whole thing goes through the “pain” of “delays” till it gets out the door… in a botched fashion with subsequent (expensive) fixes through production.

But, for much of the project, the engineers are powerless to stop stupid short cutting to meet deadlines.

One thing to keep in mind is that concurrency was a DoD plan put in place to save time and money. While there will always be increased “upgrade” costs associated with early LRIP fighters, the overall cost is kept down.

Sorry, that is bull.

Concurrency is a scheme advocated by project managers who think their stupid little Gantt charts and even more stupid little excel sheets with red, yellow and green boxes actually mean anything. The A350, B787, A400M and A380 all used concurrency and all suffered greatly for it.

By and by large, every project manager I have met has virtually no grasp on even the fundamentals of the technical issues they are “managing”. They are mostly clueless and as a result mostly place emphasis on the unimportant.

Any engineer will tell you, if the program doesn’t start right, then it’ll fall apart. No foundations = f**ked. Yet the program managers will sacrifice everything to keep the program on track, particularly at the start – even though it is at that point where most of the big unknowns are encountered and have to be shook out. Therefore the foundations get sacrificed and as time progresses, with the program lagging behind time and budget, they get ever more desperate to make the program “appear” on track so cut even more corners. Right up until the point where they can hide it no longer.

Ridiculous.

Concurrency is a complete waste of time, money and energy.

If the DoD wanted a cheap way of replacing their fighters on time, they would have started the F-35 program earlier. Its not as if it crept out of nowhere – how long was JAST/JSF running?

While there may be many reasons for good Frenchmen to rejoice that they left the Eurofighter programme, it seems self evident that the French share of costs of a five nation Typhoon programme would have been much less than the 100% share of a single nation programme

You’d be surprised at how non-linear the scaling would be.

It also meant the French got the aircraft they wanted and are not as a result drawn into the JSF debacle.

Now, the Brits only wish they were as forward thinking as the French were when they insisted on a carrier capable aircraft when the ECA was being drawn up.

So is it a strengthening measure – rather than aerodynamic ??

Wing fences are not strengthening.

The wing-tip pod may have its weight biased forward, which may help to alleviate aero-elastic effects somewhat by moving the local flexural centre forward.