Design Phase Product Integration Management- A new GA Aircraft 6

[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

 

[MintJulep]

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

Possibly. However the "basic form" isn't close to good enough to run even a moderately complex project. This line of thinking leads to trying to do it with Excel, and that never ever works out.

Flashback 25 or 30 years: There was DOORS. Vastly capable. Highly expensive. Frighteningly complex.

When used, the typical implementation was to get a few seats, turn them over to the project engineering team and tell them "figure it out and use it!". No training, no support staff, an expectation of MAGIC by upper management based on the flashy marketing demos.

Unsurprisingly, this approach only results in the tool not being used.

These days there are many requirements management tools on the market. Unfortunately most of them focus almost exclusively on software development projects. There are a very limited set that can properly deal with complex projects involving tangible objects.

The direction that OMG (Object Management Group) is moving SysML towards is tremendously exciting. It's opening the door having "executable requirements" and doing away with functional definition documents written in words, replacing them with functional definitions defined with unambiguous models that can be directly validated instead of just verified.

You could start here: https://www.omg.org/sysml-directory/vendor/list.htm and work down to see the big name players that offer the latest and greatest tools that are actually capable of handling complex projects, and work up to see the foundations and aspirations for SysML.

I really wish that I was 25 years younger and could have the opportunity to lead a project that takes advantage of these possibilities from the very beginning.

Even so, none of this is magic. It's a tool, and like all tools it must be used by people with the right skills and training. It's also not a "responsibility" of the already over-worked system engineers. It needs a dedicated full-time team.

Doing it right requires up-front investment in tools, people, training and time. The MBAs see the up-front cost, and because no companies actually review completed projects to understand the failures and successes it's nearly impossible to make a quantifiable business case for the up-front expense.

Add to that the voice of the old-timer upper manager: "We tried DOORS 30 years ago and it didn't work."

Rinse and repeat.

 

[jaceb]

most important question which comes to my mind - you would like to execute project or play in project menagement game? this two things are on the two most different poles of the globe....

 

[SWComposites]

Even so, none of this is magic. It's a tool, and like all tools it must be used by people with the right skills and training. It's also not a "responsibility" of the already over-worked system engineers. It needs a dedicated full-time team.

Doing it right requires up-front investment in tools, people, training and time. The MBAs see the up-front cost, and because no companies actually review completed projects to understand the failures and successes it's nearly impossible to make a quantifiable business case for the up-front expense.

Yep, agree 110%

 

[rb1957]

I echo your upper manager ... "we tried (insert s/ware name here) and it didn't work".

design is not deterministic, newtonian; because you can never Know Everything. Like I said above, the mountains of communications these days (who has an empty in box, having read and understood every email they get ? and teams messages, and ...) we'd spend all our time reading communications that don't involve us, to catch the 0.1% that do affect us. And the design data is continually changing, and so things are inherently out of synch.

Having a disciplined approach to the development of a design is crucial to a successful outcome. As crucial is having experienced engineers who can make decisions in the absence of data.

Of course, vastly expensive programs can (have to ?) afford expensive program/project management because the project is so vast. A FAR23 plane shouldn't (can't ?) afford this "luxury", and so relies on a less rigorous approach ... cheaper mgmt tools (like excel instead of dedicated PM tools) that require more manual involvement.

 

[IRstuff]

Flashback 25 or 30 years: There was DOORS. Vastly capable. Highly expensive. Frighteningly complex.

Actually DOORS is still being used, but at barely 10% of its potential, not unlike Excel for most people. DOORS' capabilities are woefully underutilized, even by it's "experts", since most of them are basically data entry operators, and haven't even tried to do traceability and requirements analysis. Even vaunted systems engineering houses like Boeing have blown contracts because they didn't trace all the requirements through all the documents.

Nevertheless, the process does not ensure you know what you are doing and does not ensure that everyone reads and understands the requirements. And that's the crux of the problem, you need to USE THE TOOLS as intended, and you need to thoroughly UNDERSTAND THE REQUIREMENTS and you need to HAVE A PROCESS. Fail in any of the three and you have either product failures or contract failures or just plain disasters.

 

[GregLocock]

At big automotive OEM we have a well defined implementation of the Product Development V, but there's no particular software involved. There is some sort of Gantt chart generator as our timing charts at a birds eye view level always look similar, which is not surprising as they have to coordinate multiple simultaneous programs across many facilities. But you then extract the relevant stuff from that (mainly the dates of gateways for each program) and jam it into whatever format keeps you happy. FMEAs and DVPRs are mostly done in Excel, developed by the design group for that system, preferably copied from the previous generation.

 

[MintJulep]

Actually DOORS is still being used

Right. I meant 30 years ago DOORS was pretty much the only dedicated requirement management tool available.