GET THE TRUE REQUIREMENT DEFINED FIRST - then offer solutions
Firstly a very Merry Christmas to all from my mid Pacific location.
Now, to the real issue:
There are myriad examples in the the aviation environment and particularly in Australia, of situating the appreciation rather than appreciating the situation. To put it another way for those whose background may not have covered "appreciations" - work out the problem and the real requirement before rushing into a solution based specification. The Australian airspace mess is a classic example.
In his excellent work "Most Secret War' R.V. Jones cites (on page 78) an excellent example of an overly complex specification which entirely missed the point resulting in a delay in introduction of bullet proof aircraft fuel tanks well into WW II when the technology had been proven late in WWI.
ICAO states the issue very well in C/CAR WG/7 - WP/04 dated 27/03/09 dealing with a performance based approach to requirements definition which avoids the problems of “Technology Driven Approach” and “Solutions searching for a problem to solve” .
In my System Requirements and Operational Requirement roles and later in the days of the AERU I stressed the need to start with an agreed Concept of Operations (CONOPS) before rushing headlong into defining solutions.
Now.... how about we all enjoy a great Christmas Day, relax tomorrow for Boxing Day and then take a few deep breathing exercises before having a serious think about what is the actual problem we are trying to "fix" or if there really is a problem, other than some bent egos and perceived bureaucratic needs to "do something".
MJG
23 years in ATC, 3 years is ATS System Requirements, and then 23 years around the world working on ATM systems and airspace taught a few lessons.