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.

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