Mark Tickner said:

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.

This is nothing new, and pervades into other related  disciplines such as QS etc. I was dealing with this back in the 1990's. Long project-lifecycle programmes are perhaps most at risk.

What's worse, is that technology advances at such a pace, that during the lifecyle of the project, standard change .. technology advances .. what the Client wants morphs ... etc etc.

I think it's more than just "systems" though ... certainly including electrical, but extending to renewables, multimedia and AV, telecommunications, etc. etc.

I'd be happy to be involved ... I think this information should be available to PMO, QS and civil claims legal experts too.

Hi Graham,

Many thanks for your response and sorry for not replying sooner.

Yes, this doesn't seem to anything new and others have also identified this issue.

Change is an interesting aspect - even with a relatively short project, change occurs. All projects should really assume that change will happen from the outset. Strong requirements management and traceability can help with change, as it provides a means to identify the impact of changing the requirement. But if you don't capture the requirement that is being changed, it won't help you.

Large and long timescale projects have the issue that you are more likely to have not dealt with the preceding change before the next one comes along. Its very likely that you will have multiple complex changes occurring at the same time. This equally occurs outside of civil infrastructure.

The unique issue for Civils does seem to be that they have a strong siloed mentality. The other issue is that there is a strong focus on delivery and quality, but the "paperwork" is seen as a necessary evil that gets done later and is someone else's problem (to quote Douglas Adams).

The concept that has crossed my mind is a series of short presentation on systems engineering concepts. Yes, it could be expanded to other fields as well, but those are not my specialist knowledge. 

But what I'm struggling with, is where to I pitch it? I don't need to train them in Systems Engineering, there are plenty of MSc's to gain that level of knowledge let alone all the various courses from many providers. I want them to understand, not do.

The temptation for me would be to pitch it at the "Awareness" level of the  INCOSE Systems Engineering Competency Framework. I already assess my staff against the "Practitioner" level for a sub-set of these.

But that still feels a little too detailed for someone you only want to have a basic awareness. Understanding that framework at Awareness level would in my mind be synonymous with achieving the ASEP qualification - and I'm not expecting that. There are also other competency frameworks that I can use, but these are aligned to general engineering. So I'm not keen on these.

Many Thanks.

Mark

In your latest response you mention the problem of change on long term projects but didn't highlight the role of the contract. Was the contract "fixed price" or "cost plus" ? 

I draw your attention to the aerospace disaster called the Boeing Starliner which had a fixed price with NASA.

Boeing has reported a loss close to US$ 1.5 billion, due to design errors (example used tape that was not fire retardant).

Companies that don't price out major changes (defining what is a major change is another challenge) and don't attempt to recover the new costs,  could end up in bankruptcy   

Peter Brooks

Palm Bay 

Peter, they can take many forms depending on the agreement between the employer and the client - for you interest refer to New Engineering Contract - Wikipedia

But in this case, the nature of the contract is not relevant, because I have seen these behaviours in both types of contract.

Of course, configuration and change control is a key Systems Engineering competency.

Hello Mark;

You reference was very interesting.

Maybe I reading it wrong, but it looks like lawyers are not playing a very significant role in big contract creation.

The majority of big US construction contracts usually involve Federal and State funding. They usually have to meet directly or indirectly Military or Federal contract rules.

It should be noted that a lot of high level politicians are lawyers which makes them a very powerful force in contract law and society in general.

Most large contracts that I have worked on had to be accepted by the company lawyers before it could be submitted to the customer.

Peter Brooks

Palm Bay 

Civil Engineers should possess some level of systems thinking, though they may not realize it

I did Electrical/Electronic Engineering in the 60s/70s, then a Masters in Control Engineering at Sheffield University.

They differentiated between systems engineering (i.e. concerned with e system as a whole) and control engineering  (i.e. the dynamics of the system)

We had one lecturer (a mechanical engineer) who told us that civil engineers understood the static forces on a finished box girder bridge but not the dynamics of building one. This was at the time when box girder bridges were falling down during construction.

Teaching civil and other engineers the importance of understanding the system as a whole is worthwhile and probably achievable.

Teaching nonlinear dynamics a different ball game altogether.

My PhD was in mathematical modelling of interacting biological systems. There was no way the surgeons and biologists could be taught enough to do it themselves.This is why, when it comes to the dynamics of complex systems the preference is for multi-disciplinary teams

The danger is that civil (or any other discipline) engineers might not know what they don't know, but should know.

As the saying goes "It Ain’t What You Don’t Know That Gets You Into Trouble. It’s What You Know for Sure That Just Ain’t So"

quoteinvestigator.com/.../

Hello Bernard:-

I was very interested in your comment about doing your PhD in Mathematical modelling of interacting biological systems.

Was this taken before or after the discovery of the impact of the gut bacteria?

With the rapid rate of finding new biological (feedback) pathways -- According to the medical journals I read every day (JAMA, NEJM etc) they announce one new significant pathway nearly every week- I think that it must be an impossible task to keep modelling up-to-date.

Then there is the problem associated with long term effects of external factors (examples taking medicines) on biological systems. I try and keep up with the negative effects of commercial medicines (FDA black box warnings) which are sometimes very important (example a very highly requested drug which can result in thyroid cancers).

I would be very interested in knowing if you are currently employed in the medical field!

Peter Brooks

Palm Bay 

Bernard, 

I agree.

The issue I suspect is that they don't recognise it because they understand the concepts using different terminology. Therefore the way to explain the concepts is to use phrasing they recognise. My issue here is that I am not familiar with their phrasing since my background in definitely not Civils.

We were taught several aspects of maths using both mechanical and electrical terminology (sprung, mass damper, RCI circuit) to demonstrate the the maths was the same, just the application was different. I suspect its the same concept.

But beyond thinking as a whole system. I think that the Civils need to have a better grasp of why configuration control is useful (do you know what you were building that to), why requirements management when its done properly can add value, and why leaving it all the end (the right shift) is actually a bad thing.

Regards,

Mark

Peter Brooks said:

Was this taken before or after the discovery of the impact of the gut bacteria?

I started my PhD in 1970, which was well before any knowledge of the role of gut bacteria.

It was before much was known about large populations of interacting non-linear oscillators.

I modeled the electrical activity in the human small intestine which is created by ion activity across cell membranes.

My big finding was the way the oscillators would move into and out of phase and a cause a group of them to synchronise and move down the gut - a possible cause of peristalsis.

If you are interested, this is the paper that got published.

https://www.researchgate.net/publication/18699018_A_mathematical_model_of_the_slow-wave_electrical_activity_of_the_human_small_intestine

The whole area of intestinal dynamics is much more complex then we ever imagined and in now known as neurogastroenterology 

Peter Brooks said:

I would be very interested in knowing if you are currently employed in the medical field!

I never was. I've worked in a variety of engineering areas but I've always been interested in nonlinear dynamics. I am retired now but much of my latter work was on the dynamics of project and system development in government and large corporations.

Mark Tickner said:

The issue I suspect is that they don't recognise it because they understand the concepts using different terminology.

That's a common complaint.

 I worked in government IT for many years and they have a totally different approach and language from engineers.

I found that you have to learn their language, they won't learn yours. Unfortunately things get lost in translation and there''s also the problem of the tender process.

A tender has solution requirements, but what is really important is the problem. Many vendors I have worked for were not much interested in the problem, only what was written in the tender. If the solution didn't solve the problem, it was the client's responsibility.

Which is why, when I talk about the system as a whole, I include the problem requirements as well as the solution requirements, they are two different, but connected domains.

e.g. it doesn't matter how good a bridge is if it is in the wrong place.

which is why I wrote this:

www.researchgate.net/.../260624035_Beyond_the_Zachman_framework_Problem-oriented_system_architecture