How effectively can you carve up systems engineering tasks and manage them as separate elements?
Sounds like a plausible approach to running a project or setting up contracting arrangements for a large project. Can you do this? It runs against the ethos of a systems approach and the systems engineering practice.
Businesses - which are effectively large systems of systems - these days are floundering towards more flat-open type management structures. This engenders emergent control within the workforce and more fluid problem solving as teams can form quickly and then disperse. Sounds agile - as long as you don't kill it with bureaucracy its an effective business model.
Can this approach be applied to engineering problems? They do tend to be a bit serious though and need project plans and costs and budgets and risk management and the like - which all sound very bureaucratic in the extreme. But, is there no way some of the more fluid principles could be applied without the project running over time and budget - wait - that's what large projects tend to do anyway even with all the bureaucracy!
I have just been involved in a large tender which carved up the engineering disciplines each being bid separately. It was evident that the difficulties of breaking up a system for tighter control led to a very restricted set of responses being asked for. Whether this is what was intended or not I'm not sure - it will certainly make marking the scripts easier - but will you be able to bring all the elements together again to form the fluid project team environments? Maybe there is some more bureaucracy we can call upon to help with that though ;)
Anyway - onward and upward.....