Design Phase Product Integration Management- A new GA Aircraft

[Casilero]

I need to answer a question about a practical thing in aircraft design management...maybe you could help?

Here goes......during the design phase, for PDR, all the systems have to be integrated into the wing, engines, fuel lines, landing gear, wiring, flight controls, the whole lot that bolts onto the wing. The question is what interface project systems are used in reality to make sure for example all the integration checks are carried out. By system I mean an ISO or EASA AMC or perhaps SAE ARP4754 protocol to list out what should be done to check the matching of parts for all the reasons from galvanic action to vibration to interface gaskets, safety analysis, etc. I refer to the US or EU environment here to try to establish what compliance requirements might be cited in a compliance review for a Design organisation in the civil aircraft sector.

What to you do in reality to manage this? I used to use Do178 for avionics, mainly specifies the connector socket.

Any tips come to mind?

Much appreciated.

 

[SWComposites]

Please accept my thanks for your many interesting contributions.

Why don’t you answer the questions posted above?

 

[jaceb]

are you talking about ELFLY?

 

[IRstuff]

Did your project skip its system requirements review (SRR)? You're not supposed to start the preliminary design UNLESS you've nailed down all the requirements, which includes test, validation, and verification. If you're changing or adding requirements at PDR, that's a serious scope change, which affects cost and delivery. At PDR, the contractor is expected to present their test, validation and verification plan, and it's up to the customer to ensure that the presented plan represents the agreed-upon scope.

By the way, in-person meetings can reveal things, even when not discussing the matter at hand; I once had a lunch with someone, and they couldn't find a parking spot, other than a handicap space, but they whipped out a handicap parking placard, laughed, and I stopped paying attention to anything they said.

 

[jaceb]

Project execution is pretty much endless topic - equation with many possible solutions but with very few correct ones. Two most common are:
1) execution within well established organisation - "we are doing everything according our standards, nothing really can surprise us" pros - low skilled menagement can't really hurt process, cons: time consumption eceeding acceptable levels - this is just theory only somehow succesfull organisation working similar fashion i've seen in action is/was GEAE
2) leader heavy - really skilled guy running the game - this is extint species - gone with WWII era engineers
My advice is to pay attention on planning - poor plan is far better than having none and, as mentioned by our respected colegue IRstuff, track any change analyse effect of this on your plan, most important prepare schedule corresponding with your plan as well budget. It may not help you but it is great tool to find out when your project is no go and time to bail out....

 

[Casilero]

Again interesting comments and I hope the upcoming organisation has done all the high level specification, road maps and so on and system requirements. And you are right, some companys do this during in advance of design, don't do it or treat it as admin activity.

In the Project Management Institutes vision of how a project is run, you start with Inaugural docs like the Charter, the mission and high level empowerment statements, but often times these are missing even on billion dollar programmes. (yes I know PMI is not much used in aero)

My role is to be an independent eye (at least that what I think i am doing!!) and advise on the adequacy of project management, its design reviews, its current state of risk, etc. The original question came with the nuance that it was the project management would be operating to the latest project methods. Like any big project, the mistakes may have been made already, be in progress and out of control and nobody knows until there is direct experience of the work in hand. ON the other hand, if it has been well guided, then its worthwhile.

Like the story with the railway wheels, you can shout, scream, write, complain until the cows come home and nothing changes the direction of the juggernaut organisation on a big spend. Imagine a project where all the main management knew the project was a failing morass but choose to 'turn the other way' letting the capital burn rate increase for another 2 years. Around 30 years ago, I was invited in to look at such a project run by a non aviation company put together by consulting houses, my role was to provide 'aviation industry knowledge'. Within a couple of weeks, it was clear the project was in deep trouble. Its system (I cannot say what it was except it was avionics) was failing gloriously costing over about 0.75 billion USD at the time. I went globally doing audits on design sub contractors, cable makers, you name it. The technical boss did not know what a 'wiring loom' was, imagine an avionics company boss bringing that question up at a meeting-'what is a wiring loom'! We tried to explain. There were 3 others design managers from an aviation background but we were outnumbered by about 10 to 1 with general industry engineers. The flying test bed was due for a flight test, a jet twin. One engine was out, fuel pump leak. Boss came round, raging about flight test not going ahead, after all it had two engines, one is a reserve-should be plenty of power. We (i had to ) explain that they had to use both engines and it was kind of a law-ask the pilots of you dont believe me (I'm not kidding). They thought we were full of it. And that was a small project. A passing child could have guessed the project was in trouble. The engineers were quite young. The bosses who were kind of non techies but with good tech qualifications, trivialised the role of expert aviation advice over the project plan decision criteria. The project failed of course.

My question started with a concern that I had missed some really important project management system (during the years I worked back in stress and design ) or method in the digital era whereby 'interface management' might now be a bygone worry of the past that is managed by some new software widget or knowledge that everybody should know about. Its just is not true. Dont be dazzled by latest internet 2nd hand experience or education industry promoting their vision of how it should have been done. Most experienced aerospace engineers can develop the project management system in its basic form by just going back to brass tacks and thinking it through. I have done a few project managements (DO's)plans in my time, working on a few terrible projects and worked on some very goods ones. In the terrible ones, the very early stages of the job was often not thought through, or persons who were inappropriate to the command of the project were in charged. The project plans could be good in their own right or sometimes so elaborate that nobody could understand them. (over academic leanings) In the good ones, strong corporate governance seems to be characteristic and these are not pop up companys. Personally speaking, keep the project management plan simple, meaning keeping it down to earth and understandable to the people who will use it. This might means translating it downward so it the relevant bits to the section you deal with are all that is used day to day). One airliner section, I did the plan in pencil, gradually digitised it, kept it simple, it worked. Make it actually useful and keep it as simple as you dare knowing the risks. Implement it by empowering people according to their skills and interests, start them with the basic bones of the job (rqmts), make it interesting, leave them at it and don't breath down their necks. As the subcontractors who are doubtful, help them over the challenges if they are on a learning curve but get these type of risks identified right at the start and have back up plan naturally. What to do with the lobby of persons from a non aviation background undermining the 24/7 persons from industry, quite common in certain new projects these days, sometimes you cannot do anything. As a company lawyer said one day, you might be the project leader but you don't own the project, you advise and the owners can do what they want.

Anybody remember Learfan, had a spot of bother with the gear box mixing both engines. It was the heart of the project, two turboshaft engines feeding into a single prop, great innovation but.....if I recall correctly, it was an adapted marine unit with loads upped substantially, the authority wanted assurance that the prop shaft-gear tooth failure would be proven by test to a high requirement naturally. It made 20% of the test required value only.
Deloran push all the way, the gearbox.

This conversation has wandered a long way from 'Interface management'
.

That is my tuppence worth, many tanks for your contributions.

 

[rb1957]

run ! don't walk, run from where ever you are !

and running a single prop from 2 engines is not new ... several examples from WW2 (He177, Brabazon, et al) ... not stellar successes, but the concept is not new.

 

[SWComposites]

you start with Inaugural docs like the Charter, the mission and high level empowerment statements

these things are completely useless rubbish. if upper management doesn't know what the "mission" and purpose of a project is after spending at most 5 minutes on it, then there is something seriously wrong.

 

[IRstuff]

My question started with a concern that I had missed some really important project management system (during the years I worked back in stress and design ) or method in the digital era whereby 'interface management' might now be a bygone worry of the past that is managed by some new software widget or knowledge that everybody should know about.

There is a process, albeit, not cast in stone; many aerospace organizations use a system engineering management plan (SEMP) that contains the basic steps of how to manage a development project, but it's not prescriptive, since the SEMP can be applied to anything from a hobby shop development to a multibillion dollar system of systems development. Nevertheless, developing a SEMP will at least codify the framework process for a system development