Why we’re talking about this today is that when we show this to people they really like it. We’re getting a lot of responses about this. This is really just a small part of what ProjecTools does for engineering and design projects, but when we show it to engineering groups, they just love it.

These system to system interfaces are traditionally managed through emails and spreadsheets and little interface matrix apps to manage the collaboration among the different groups. Those don’t work, they definitely don’t work well because there’s no control and conversations aren’t pointed. There’s no real end point and it’s hard to log the conversations back to the project or the system. Beyond those very high level problems that are systematically there, there’s more in depth problems that we should talk about before we get into system to how system interface management should work.

When we talk to people about system interface problems, occasionally smaller engineering companies who are putting a lot of effort into segmenting conversations correctly come up with a question, “Is what we’re doing right?” It comes down to the distinction between inter discipline or intersystem communication. Inter discipline is really if you have a small shop, that might work well for a while, but if you’re working on a big project or have a big team, intersystem communication is really what needs to be tracked.

You need to figure out who’s talking to who on which teams regarding which systems. If you can track all of those conversations, log them to the project and make sure that they happened so you can go back and reference them and so forth, that’s a huge plus. The other question we get is, “Who drives the interface management?” We deal a lot in oil and gas, EPC, engineering, capital construction and so forth.

Usually it’s the EPC contractor, whoever is in charge of the project, maybe not the owner, but one level down, the contractor that’s responsible at the end of the day for delivering an asset or a deliverable. If your butt’s on the line and you face the big penalties if systems fail or don’t properly integrate, you’re probably the one that needs to drive interface management. You implement the process and make sure that everything’s tracked.

The other topic that comes up is traditional interface matrix apps, they break down because they don’t get specific enough and they don’t track the conversations back to the project, so things are just floating out in the ether, the internet of things. Emails get shot out and they copy the wrong people or people that don’t matter and people chime in that shouldn’t be chiming in and it just gets messy. You also have offshoots, where the email chain gets forwarded to someone for sidebar conversations and then try to bring that sidebar back to the group. This fragments the conversation and derails the progress that the larger group has made. I should point out here that this problem is not specific to engineering groups, it is a systematic flaw in email communication used to form a consensus or align teams. It just doesn’t work well.

Having to go find all of those branches of conversations and then wrap them back up to the project, which is often becoming a deliverable on it’s own, gets very hard to do. It’s very time consuming and oftentimes people can’t deliver complete, properly segmented because it’s just so far gone and so confusing. The other thing we hear is that most interface management tools that are even specific to engineering system interfaces, they’re incomplete and they don’t provide the specific interface points.

What I mean here is that true engineering centric system to system interface – the underlying thing that we’ve kind of talked about are traditional systems, they aren’t effective. These ad hoc interface management systems, emails, spreadsheets, Skype, phone calls, et cetera, they don’t get the engineering groups systematically logging and tracking these communications, which can lead to one, design issues and two, confusion.

Both of those things can cost you serious cash down the road, especially if you can’t defend the work that you’ve done or if providing system interface communication is a deliverable for you, so you could end up running into a bunch of trouble. The best solution for system interface management is one that provides interface points by system and there’s a workflow that will enforce that.

The system needs to aggregate system interfaces into a single place so you don’t have to track down a bunch of emails and ask people, “Hey, where did all this correspondence go? Where can I find it?” It should be found in a single place have a workflow that bounces around to the appropriate parties depending on the disposition of the last correspondence until there’s a definitive acceptance of the conversation or it’s closed. The system would prevent the logging of these conversations prematurely so requests end up resolved and other teams can go back and reference the conversation.

The ideal system to system interface management tool has accountability built in so things get done. Things are in tasks so if I get an interface request, I have to respond to it by the due date or my name is going to show up on a Late Action Report.

The system to system interfaces should be set up so that systems communicate with other systems. Moreover, system owners talk with other system owners. Your engineering groups should be able to define the systems that need to interface and how the systems interface. Then they can automate that workflow.