Bridging Systems Engineering in Civil Projects

I work as a Systems Engineer on a predominantly Civil Engineering project. A recurring issue is that the Civil Engineers don't fully grasp Systems Engineering. While I can guide them through the correct processes, merely following a process doesn't equate to understanding it. This often leads to a superficial, tick-box approach that lacks comprehension of the underlying rationale.

Civil Engineers should possess some level of systems thinking, though they may not realize it. The Accreditation of Higher Education Programmes (AHEP) document stipulates that accredited courses should include an integrated/systems approach, incorporating some systems engineering principles. The design element also encompasses a broader perspective of the design process.

For professional registration via UK-SPEC, Competency B1 focuses on project requirements. Competency C addresses various project management aspects, which are closely linked to Systems Engineering.

Effective communication often requires speaking the audience's language, particularly when reporting to senior leadership. Establishing shared concepts and values across different disciplines is crucial.

I am considering developing a "Systems Engineering for Non-Systems Engineers" training course. This wouldn't aim to fully train them as Systems Engineers—a process that typically takes 2-3 years through a Master's program—but to provide them with an understanding of the key principles and their importance.

Earlier in my career, while working in aerospace, new graduates were encouraged to attend a course by the aerodynamics department to understand the critical aspects of aerodynamic design. I still remember some of the aspects taught to this day.

I am interested to know if others have attempted similar training initiatives, whether in Systems Engineering or other disciplines embedded within another field, and what their experiences were.

  • Hello Bernard:- So you are a OAP like me!

    It appears that you are interested in Modeling Astronomical systems like Galaxies.. I see that the latest data suggests the center of our galaxy has less mass than previously thought and that means we have more dark matter on the outside of the arms. 

    I am more interested in what is dark matter and dark energy, the strong force, virtual particles, the discontinuous nature of spacetime, and the rapid formation of early Galaxies.

    Peter Brooks

    Palm Bay 

    P,S. Another one of my interests is the negative effects of drugs on the human body as one ages.  

    .  

  • Thanks for that paper, another one for me to add to my collection regarding architecture frameworks.

    This comes into one of those requirements management concepts, the stakeholder requirements should be written in the language of the customer and in the problem domain. Systems Requirements should be elicited from those stakeholder requirements and should ideally be in the solution domain and written in the language of the company providing the solution.

    But.... depending on the complexity of the problem there may be a few more levels of system requirements in the problem domain before you get to the solution domain. And yes, depending on the nature of the project, you can have more abstract needs in the business domain that led to the stakeholder requirements. Some of this is handled in newer frameworks, such as the OMG UAF and Magic/MBSE Grid.

    Customers/Stakeholders don't always play fair - and many a time I've seen stakeholder requirements in the solution domain and even a specific implementation!

    So yes, Systems Engineers are used to providing that translation between different groups. But it is a good point for me to consider that I should be using their language to explain the concepts rather then to teach them my language. Its a bit like a STEM presentation, you are always told to keep your language to what they (the children) will have experienced and understand. But its much harder to do in practice.

  • Hello Mark:

    Some years ago I had a problem with operating documents which were exclusively written by production engineers.

    However they had to be used in training operators with a limited education, who couldn't understand the jargon.

    I discovered that the US Navy had a similar problem where again the operating training documents were written by equipment engineers but they were way above the heads of the lower rank navy personal.

    The US Navy developed a computer program that allowed the creator to lower the educational level to that of a 13 year old person by suggested replacement wording.

    I attempted to get a copy of this application but it was government property.

    Peter Brooks

    Palm Bay  

  • The US Navy developed a computer program that allowed the creator to lower the educational level to that of a 13 year old person by suggested replacement wording.

    When I consulted to the Australian government/public service on strategy I was told to make the reading age of written documents (as determine by MS Word) no more than 12 years. And short - 2 pages max.

    It required more than word replacements - the sentences had to be short and simple.

    Bernard

  • The provision of clear, easy to follow instructions is an art in itself, and an under-rated one. This is not really a system engineering problem, its wider than that - you only have to look at almost any piece of UK legislation.

    The campaign for plain English has been railing against this for years, and publishes its worst examples of golden bull...

    If you wish to use a computer program to proof check things and don't mind java, there is

    https://www.plainenglish.co.uk/drivel-defence.html

    Mike

  • From both Bernard and Mike's points, this is why I try to encourage engineers to get involved in STEM work, particularly in primary schools. It is fantastic training in getting your point across clearly (and, incidentally, in holding an audience's attention).

    This is all great fun in functional safety documentation. On the one hand the safety evidence has to be written to a legal standard of preciseness and completeness, which frankly can sometimes make it, at the very least, tedious to read. On the other, in giving formal written safety instructions it is as you've all said above - they must be brief, clear, and intelligible to all - including non-native speakers. It's been interesting seeing the rise in appreciation in the safety community that old process of saying "we covered that by writing it down" is not only not adequate, it can even make the situation worse. One that particularly winds me up (and winds the Office of Road and Rail up too) is signage at level crossings - past projects have tried to cover themselves by adding huge numbers of verbose signs, which we know are simply not going to be read, and even if they are can be confusing.

  • ah yes

    Beware 3 eyed alien space craft landing in field, low loader grounding risk, fence and historic railway....

    But I always liked the idea of a switch in the car for waving a flag. Its actually wipers.
    Mike

  • Hello Mike:-

    You obviously don't remember when cars used to have a right or left signal arm indicators that used to raise up from the side of the car body,  controlled by the driver when turning.

    Peter Brooks

    Palm Bay 

  • Hello Mike:

    Regarding worst examples of golden BULL.

    Have you ever listened to the audio recording by Peter Sellers - Party Political Speech (1958)- on youtube?.

    By the way I used to attended some BBC recordings of the GOON SHOW in my youth.

    Peter Brooks

    Palm Bay 

  • trafficators - I've seen them, I'm far too young and never driven a car with them ;-)

    Seemed to spend a lot of time getting stuck or bent/ unbent if i recall correctly, but those cars were old even then. My parents cars always had 'winkers' as we used to call the orange flashing lights..

    Mike.