Bringing Control and Traceability to AECO Projects

Two speakers talking about requirements and traceability in the AECO industry.

In this blog, we recap our recent webinar. Watch the entire presentation here, Requirements Under Construction: Bringing Control and Traceability to AECO Projects

Build Better AECO Projects: Overcome Misalignment, Rework, and Scope Creep

Architecture, Engineering, Construction, and Operations (AECO) projects are large, complex, and increasingly regulated. Yet many teams still manage owner requirements, design intent, and change decisions using disconnected documents, spreadsheets, and siloed repositories.

The result is misalignment between stakeholders, costly rework, scope creep, and limited traceability from early owner requirements through design, construction, and handover.

Join Dale Brown, Director, Infrastructure at NSI Advisory Services, and Jama Software experts, as they discuss the real-world challenges of requirements management in AECO projects.

What You’ll Learn:

Why document- and spreadsheet-based approaches fall short on complex AECO projects
How poor requirements visibility leads to misalignment, rework, and scope creep
Practical ways to manage change while keeping stakeholders aligned
How to maintain traceability from early owner requirements through design, construction, and handover
What modern AECO teams need to support audits, compliance, and delivery confidence
A look at how Jama Connect^® supports requirements traceability across AECO project phases

THE VIDEO BELOW IS A PREVIEW – WATCH THE ENTIRE PRESENTATION HERE

TRANSCRIPT PREVIEW

Requirements Under Construction: Bringing Control and Traceability to AECO Projects

Dale Brown: Thanks for inviting me to the conversation. Yeah, a lot of those folks probably really are doing systems thinking, or as we call it, systems engineering, but it doesn’t have to be engineering. It’s just using that system’s view of the world. So I’ll just try to explain it in a fair way, using lay terms as opposed to a lot of tech speak. I mean, we live in a very complex world in our daily lives. We’re surrounded by a complicated environment. Our cars, our phones, our homes, our offices, schools, trains, and planes. And we ourselves are pretty complex creatures.

And we’re part of a community, usually which is part of a town or a city, which is part of a state, which is part of a region, part of a country, and part of the planet. So that’s kind of the way all these parts, you can see how they aggregate. And that’s really what systems thinking is. It’s thinking about where I fit into a bigger picture, potentially, a bigger environment. So in the case of an infrastructure project, you would know that there are local codes of practice, state and national codes, and maybe even international. So where do I fit into all that?

And especially for the architects who are looking at the bigger picture to see how their design, what is the look and feel of what they’re trying to accomplish, both internally to say it’s a structure, or externally, if it’s a cool new stadium or anything really, does it fit? Maybe it’s not intended to fit, maybe it’s intended to stand out. So all of those external things affect their system thinking, and that’s it in lay terms. Hopefully that makes sense.

Joe Gould: Yeah, it definitely does. It’s a great perspective, Dale, great way of thinking about it. So thank you for that. So let me ask you then, where do you already see systems engineering principles showing up in AEC, even if we don’t call them that?

Brown: Yeah. And I mean, the terminology is such a big thing, Joe. But yeah, I see it all the time because you’ll get civil engineers who know they have to think outside of their particular part. And if we think that, again, using the word systems in defining what it is, it’s a collection of parts, or the more formal definition is a group of elements that form a system. But if you think of it just in parts, what’s their part in it? What is it that they’re designing? And so they’re already understanding, okay, they probably, if it’s the foundation person, they probably have to talk to the soils engineer.

And at some point, the civil and electrical guys have to talk, or the conduits are going to be put in the wrong place in the concrete. And that sort of thing, they’re already thinking about the system, even if it’s just the aesthetics, the look and feel. So they’re doing this, and they have been doing it for, well, I guess 6 or 7,000 years. So it’s not new. But I think what’s new and what’s kind of crept up is a new terminology related to aerospace, and actually, software has been the big push.

RELATED: Five Key Challenges AEC Project Owners Face and How to Solve Them with Jama Connect

Gould: Sure. No, that’s great, Dale. I’m hearing systems engineering more and more inside AEC firms. We have some large construction companies that we work with that are using systems engineering practices, for lack of a better term. Let me ask you then, so what are the most critical issues facing AEC companies today from, say, a delivery and risk perspective?

Brown: Yeah. What I’ve seen on a lot of big multi-billion dollar projects is that at some point, you have to provide a defensible audit trail of all the decisions, not all, but the critical decisions you’ve made, and especially if it’s a change order or something like that, why did you make that change? How is it documented? And where can I see that evolution of things in the design and then ultimately in the actual build? And if you can’t show that to either state safety oversight or a local building inspector, or the client, you’ll probably not get permission to occupy and use the facility for revenue service, which just means that from that point forward, all you’re doing is damage control.

You’re burning cash, you’re sadly probably also burning reputation, both of the owner, especially if it’s public money, and the state authority, whoever’s involved in it. So that’s the big risk: you build this thing and you either can’t use it because you’ve made some sort of an error partway through, or you’re not allowed to use it, which is almost kind of worse because you’re there, but you can’t provide that assurance.

Gould: Right. Yeah. I mean, you definitely answered my question. It’s like, what happens when you can’t answer those questions? And it sounds like it’s pure damage control, is what it is. And I think you nailed it, Dale. Can you talk about the financial and organizational impact of this lack of, and I’ll use the word traceability, and if you could just quickly define what traceability might mean, I think I know what it means, but I’ll ask the expert. What impact does that have financially and organizationally?

Brown: Yeah. So again, traceability is one of those terms that have become quite popular throughout aerospace and software design and development. And really, what it means is a defensible audit trail showing that this part must do the following things in the following ways in a certain environment. So you have to be able to show the relationship between all of those, which we call requirements. They can just be needs, but whatever terminology you want to use, you have to show that it’s linked and it has to be a repeatable thing. It has to be something that you can consistently show the linkage to, and that’s how we refer to traceability.

Also, if you’re doing tests, if you’ve built it or you’ve partially built it, and you need to show evidence that you’ve actually designed and built it to whatever requirements or codes of practice that are needed, then you need to show, again, that defensible linkage, and it has to be done consistently. So that to me is kind of a long definition of traceability, but hopefully it works.

Gould: Yeah, no, that definitely works. The impact of change, obviously, in the world of AEC, it’s not if it’s going to change, it’s when it’s going to change.

Brown: Yeah, yeah.

Gould: And having that, again, for lack of a better term, traceability or defensible audit trail, whatever we want to call it, is just absolutely huge. And really when we look at project management tools, I feel like they’re great for managing a project, use many of them across the board, but when you need to get granular on something and we need to understand impacts and decisions and have that audit trail like you spoke of, I mean, that’s just gold and financially not having it can just have a huge impact on the profit margin of that project. So thanks for that, Dale. So have we seen, I mean, I can speak to this, but have we seen real projects go sideways because of a lack of traceability?

Brown: Yes. Often, the old adage is that systems fail at interfaces, and if you don’t understand where something is connecting to something else, basically an interface, then that’s probably going to fail. And it can be as simple as the control rack doesn’t fit in the room, or the air conditioning that was designed for the room, the person designing the HVAC unit didn’t realize what the heat load was from that rack of electronics. And so there’s an example. Another more common one that I see sadly in almost every project is that the conduits were buried in the concrete in the wrong location, or they were the wrong size, or an assumption was made that you could mix the high voltage or even medium voltage with low-level signals. So those are examples of what happens. And some of those can get pretty expensive because the concrete’s still green, and already you’re breaking out the jackhammers.

Gould: Yeah. I mean, that’s such a huge impact on projects, and so thank you for that. Let me ask you this. If systems engineering or traceability is so valuable, then why has AEC been so slow to adopt these practices? I don’t understand.

RELATED: Buyer’s Guide: How to Select the Right Requirements Management and Traceability Solution

Brown: Yeah, it’s been a frustration and a passion of mine for a couple of decades now, almost, seems like 15 years anyway. And what’s happened is I think a lot of it is the words matter discussion we had earlier, where if you present it the wrong way and try to deploy it as if building a new train station or a new skyscraper or anything is the same as writing software. So if you use all the code terminology and try to ram that down the throats of people that have got, as I said earlier, thousands, if not hundreds of years of expertise backing up their education and they’re used to doing things a certain way and having a certain terminology guide them, they may not refer to requirements, or maybe in their mind, requirements means contract requirements only, and it’s not the same as a formal technical requirement, those sorts of misunderstandings in words.

But when you start throwing so much new terminology, and you force them, and you say, “You must do things this way. You have to get all the system requirements first.” And the civil guy, or maybe the architect on the project, is saying, “What do you mean? What are these words?” And they may or may not be familiar with it, depending on their age and their experience. And if you’re not communicating to them that you’re really just looking for what the user needs, what are the local codes of practice, what’s the basis of design? What are going to be the exceptions to the code, and maybe those are the ones that we have to really focus on because the rest of the stuff is already covered through normal building practices.

So now we’re kind of getting into a point of a side discussion, but a really important one on efficiency. So what’s happened is the industry has seen a lot of bureaucracy foisted on them through some words in a contract document that says, “You shall incorporate ISO 15288 systems engineering.” And they’re not familiar with it or the terms in a lot of cases. That’s changing slowly, but it’s also, you can’t apply it directly out of the software world into the AEC world. It just doesn’t make sense. You have to tailor it, you have to make it make sense.

So if you end up with making them do work twice, which is what happens in a lot of cases where they’ve already done a basis of design document, but now they have to deal with requirements in a separate requirements document or tool that was very expensive and they don’t understand how to use the tool and it’s been prescribed to them in the contract, sometimes they even put the tool in the contract and it gets very frustrating. So there’s been a bad history of this over the past few 15 years anyway, and we’re trying to turn a corner on that and really address maybe it’s just the exceptions to code that we really need to show extremely good traceability, extremely good audit trail evidence.

We don’t have to show every single nuance of every single design because it’s just normal practice. It’s going to be checked through and accepted through local building codes anyway. So let’s not do it two or three times. And I think that’s the distaste, and it’s created the resistance, in my opinion.

THIS HAS BEEN A PREVIEW – TO WATCH THE ENTIRE WEBINAR, VISIT:
Requirements Under Construction: Bringing Control and Traceability to AECO Projects

Author
Recent Posts

Joe Gould

Senior Account Executive at Jama Software

STRATEGIST | STORYTELLER | RELATIONSHIP ARCHITECT |

"In the ever-evolving sales world, I am the catalyst for transformation. With a proven record of turning 'no' into 'yes' and 'good' into 'great,' I thrive on uncovering the unconventional avenues that lead to sales success. My journey in sales has been a masterclass in adaptability, where I've embraced technology as a powerful ally and championed creative solutions that challenge the status quo.

I'm not just a sales professional; I'm a strategist, storyteller, and relationship architect. My career has seen me navigating diverse industries, forging connections, and orchestrating deals that redefine what's possible. I've harnessed the power of data, psychology, and innovation to craft winning sales narratives that resonate with today's discerning buyers.

My secret sauce lies in my relentless pursuit of understanding customer needs and my ability to position solutions as game-changers.

[Webinar Recap] Requirements Under Construction: Bringing Control and Traceability to AECO Projects