Those seeking to understand the ultimate root cause of the debacle at Heathrow's Terminal 5 this week, might perhaps wish to consult British Airways' 'Baggage Handling Project Management Manual'. The key sentence can be found on p5:The [project] process has a similar structure to the systems engineering principles used throughout industry.
Systems engineering is a top-down approach to large, complex engineering projects, which expends great time and effort in codifying and formalising the blindingly obvious, usually in the form of UML (Unified Modelling Language) diagrams.
The fundamental fallacy of Systems Engineering is the tacit belief that complex engineering systems are best managed by defining, often in very abstract terms, top-level requirements, capabilities and stakeholders, and by then breaking those top-level entities down into sub-requirements, sub-capabilities and sub-stakeholders, all considered in abstraction from specific technologies. Systems Engineering often requires systems houses to expend large amounts of time and money before crucial procurement decisions are made, and therefore constitutes a form of institutionalised procrastination. And, crucially, the top-down dogma has a tendency to produce systems lacking in practical operational effectiveness. True, practical, rapid and effective engineering uses both top-down and bottom-up approaches, in combination, and without any of the wasteful and vacuous formalising used by systems engineers.
Intellectually, Systems Engineering has never progressed beyond the facile observation that complex engineering systems are really 'systems of systems'. On Friday's edition of Newsnight, Allen Fairbairn, Systems Engineering Manager for the Channel Tunnel Project, offered the useful, and entirely non-specific diagnosis that large engineering systems often fail at the point where the various subsystems interact. This is the self-sustaining aspect to Systems Engineering: when it is responsible for the failure of a project, it provides generalised diagnoses of why the project failed, and prescribes more Systems Engineering as the solution.
3 comments:
Dear Dr McCabe
It is disappointing to find a person of high intellect such as yourself making public statements in abject ignorance. I am referring to your piece "Terminal 5 and Systems Engineering".
It is not the statements themselves that concern me - people have been making statements in ignorance since the beginning of human life. My concern is the potential detrimental effect on value delivery to the intended beneficiaries of projects, to the extent that your views have any influence.
Your thinking and actions remind me of the expert opinion proffered, on national television, by a lawyer, that a ship grounded off the east coast of Australia would never be moved. Four weeks later, the ship was refloated.
Let me try to correct your misrepresentations and misunderstandings. I have interspersed below, within your text, points for your consideration.
Terminal 5 and Systems Engineering
Those seeking to understand the ultimate root cause of the debacle at Heathrow's Terminal 5 this week, might perhaps wish to consult British Airways' 'Baggage Handling Project Management Manual'. The key sentence can be found on p5:
The [project] process has a similar structure to the systems engineering principles used throughout industry.
RJH: For the last three years I have been using the Heathrow Terminal 5 project as an example of poor systems engineering practice, and predicting the outcome that has occurred.
Systems engineering is a top-down approach to large, complex engineering projects, which expends great time and effort in codifying and formalising the blindingly obvious, usually in the form of UML (Unified Modelling Language) diagrams.
RJH: “Systems engineering” is certainly a top-down approach, in that it is problem-driven. No problem, no need to engineer anything. But “systems engineering” is also bottom up, in the sense that it must reconcile the problem with the pool of knowledge of existing relevant technologies, potential non-developmental components, reusable design, and the laws of physics.
The application of “systems engineering” is not limited to complex systems. In fact, some of the most effective applications that I have encountered have been to small product developments by companies who have to produce excellent products in order to survive, let alone to prosper.
Your reference to the use of UML diagrams is factually incorrect. The use of UML diagrams in systems engineering is uncommon, because of the lack of logical rigor of the language, its redundant content, and, most importantly, its inability to express explicitly the relationship between logic and structure.
The reference “which expends great time and effort in codifying and formalising the blindingly obvious” is a misrepresentation, since a driving principle of “systems engineering” is to decide on a rational basis to do things, or decide not to do things, for exactly the same reason – producing, on the balance of probabilities, a better result. However, “systems engineering” certainly can be described as applied common sense. I add that most project failures can be traced to departure from applied common sense.
The fundamental fallacy of Systems Engineering is the tacit belief that complex engineering systems are best managed by defining, often in very abstract terms, top-level requirements, capabilities and stakeholders, and by then breaking those top-level entities down into sub-requirements, sub-capabilities and sub-stakeholders, all considered in abstraction from specific technologies.
RJH: Your statement “all considered in abstraction from specific technologies.” although an overstatement, does describe a misconception occasionally found amongst practitioners of “systems engineering”. The misconception has its origin with a particular person in the United States Department of Defense, who was a key author of an influential standard on systems engineering (without having done much of it). In the meantime, nobody with any common sense who has thought about the issue has held that view, or tried to engineer systems by maintaining logical design independent of specific technologies.
Your reference to “systems are best managed” is puzzling. Systems are designed, built and used. Their design and development, construction, use, sustainment and evolution are managed.
Systems Engineering often requires systems houses to expend large amounts of time and money before crucial procurement decisions are made, and therefore constitutes a form of institutionalised procrastination.
RJH: IMO, this is a facile statement. “Systems engineering” doesn’t require anybody to do anything. The aim of a systems approach to the engineering of systems is to make the best decisions at the best times. “Best” means decisions and times which maximise value delivery to stakeholders. When uncertainties are factored in, this means that maximisation of expected value is the objective.
And, crucially, the top-down dogma has a tendency to produce systems lacking in practical operational effectiveness. True, practical, rapid and effective engineering uses both top-down and bottom-up approaches, in combination, and without any of the wasteful and vacuous formalising used by systems engineers.
RJH: If I may paraphrase your first sentence, you have said “And, crucially, the approach which emphasises satisfaction of stakeholder imperatives and maximisation of value delivery tends not to do so”. I am reminded of the expert opinion of the lawyer mentioned above, regarding ship recovery!
Intellectually, Systems Engineering has never progressed beyond the facile observation that complex engineering systems are really 'systems of systems'.
RJH: I am astounded at the ignorance, and apparent prejudice, reflected in this statement. You have, in one sentence, dismissed the contributions to mankind of hundreds of thousands of people, and a body of knowledge built up over thousands of years.
On Friday's edition of Newsnight, Allen Fairbairn, Systems Engineering Manager for the Channel Tunnel Project, offered the useful, and entirely non-specific diagnosis that large engineering systems often fail at the point where the various subsystems interact.
RJH: Although Mr. Fairbairn, if accurately reported, might have chosen his words better, he has made an accurate and (to engineers) useful observation. The history of technology-based projects demonstrates clearly that, on average, the most numerous problems experienced in a system integration phase are interfacing problems (incorrect/inconsistent between the two ends of the interface). Accordingly, an emphasis on correct and consistent interface definition, and associated management effort to ensure that this occurs, is appropriate.
This is the self-sustaining aspect to Systems Engineering: when it is responsible for the failure of a project, it provides generalised diagnoses of why the project failed, and prescribes more Systems Engineering as the solution.
RJH: I know of a few projects where inept application of the principles of the engineering of systems contributed to a worse result, than had the “anarchy” project approach been applied. I know of a few hundred projects where the systems engineering could have been better, but it did more good than harm. I know of scores of projects where a systems engineering approach contributed to excellent outcomes. Some of these last two groups were my own projects. What is your project experience that qualifies you to make a sweeping accusation like that above?
Kind regards
Robert Halligan
Managing Director, Project Performance International
__________________________________________________
Robert Halligan rhalligan@ppi-int.com
Managing Director Phone: +61 3 9876 7345
Project Performance International
PO Box 2385, North Ringwood, Vic 3134
Australia
Brazil Liaison Office: +55 (41) 3296 2179
New Zealand: +64 4 499 6155
United States +1 888 772 5174
Helping projects succeed ...
www.ppi-int.com
__________________________________________________
Project Performance International is a registered trading name of
Project Performance (Australia) Pty Ltd.
Thanks for writing that response, Robert.
I've noticed over time that Systems Engineers are always most sensitive to criticism of their discipline, and I think this insecurity stems from the fundamentally insubstantial nature of the discipline.
Twice in your response you refer to Systems Engineers as providing 'value delivery' to 'stakeholders'. You think of yourselves as delivering 'value', and you do so without any apparent trace of irony. Well, delivering anything else other than 'value' would just be solutionising, wouldn't it?
To take an example, when Systems Engineering is used for procurement in the UK Ministry of Defence, (and UML most certainly plays a pivotal role in this), one cannot speak of tanks. Tanks, after all, are solutionising. Instead, one must speak of 'platforms' with certain amounts of mobility, lethality, and survivability. After some years of specifying requirements, capabilities and stakeholders in a military procurement project, work is then farmed out for a few years to systems houses such as WS Atkins. This is the institutionalised procrastination to which I refer.
You claim that you have for some years been using Heathrow's Terminal 5 project as an example of poor Systems Engineering, but this simply demonstrates my point that when a project fails, Systems Engineers will claim that it simply failed because of bad Systems Engineering, and the remedy proposed is more, and better, Systems Engineering.
Revealingly, you admit that "My concern is the potential detrimental effect on value delivery to the intended beneficiaries of projects, to the extent that your views have any influence." If Systems Engineering were a solidly founded discipline, whose effectiveness was demonstrable and incorrigible, then there would be no case for you to answer, and it would be impossible for such as myself to undermine the reputation of Systems Engineering.
The fact that a modest individual such as myself, is potentially capable of damaging the reputation of Systems Engineering, derives from the fact that Systems Engineering is an edifice built upon fragile and soluble beliefs in the minds of politicians, civil servants, and senior industry managers. Systems Engineering is the Emperor's New Clothes, and you have hoodwinked government and industry for long enough.
McCabe,
Stumbled on your blog, you do go on. I've not met you yet mischaracterization is one pitfall endemic of dogmatists in aggrandizing 'pure' physics thru attempts at fault-finding within the engineering community; if so, shame on you.
Your supposition has points of merit, but simply suffers the same flavor of psuedo-intellectual syncretism which Halligan attempted to draw into focus in his rebuttal. Specialization does have its drawbacks. US Systems engineering rarely uses UML even tho created here; perhaps you meant SOFTWARE systems engineering and/or systems SOFTWARE engineering contributing (factors) within the project; not clear what perceived versus actual terminal 5 issues relate to UML.
I also would encourage a re-think: systemically (sic) it is not the practice of systems engineering (fundamental nature) which is at fault, but how systems engineering is practiced within (inept/insubstantial) bureaucratic organizations found within governments and certain multi-national corporations.
I suggest that these organizations are self-serving and self-perpetuating, and hence the procrastination so observed ensures the constancy of cashflow 'on the dole' (as it were).
Can you say Halliburton? I knew you could...
Classic example: We DO have a space station...no its not CERN...that would have required the wealth stolen thru hedge funds to do so...said greed superceded humanities need. Meanwhile a multitude of factions portended altruism whilst competitively elevating their communities relative merit over another communities, these attempts to be established as the recognized 'leader' merely modalities for fame and pride.
Now if IN FACT UK systems engineering uses UML...the (bilthering idiots) problems would then be self-perpetuating as you suppose, particularly if the project methodology was taken to be classic 'waterfall'. To those same Colleagues I recommend consideration of ISO/ANSI/IEEE12207 in preference over that UK ITIL, and do consider agile/scrum approaches over waterfall/spiral project plans for both hardware and software products.
Systems are merely abstractions to deliver a product. You lose sight of that fact, you have problems. The next US nuclear power plant would best be out-sourced to the French for reasons which parallel concerns McCabe has cited.
Regardless, good read.
Post a Comment