In this podcast transcription, host Geoffrey Cann and guest Jordan Kyriakidis Ph.D., discuss the importance of writing effective technical requirements. They examine real-life examples where technical specifications led to multi-million-dollar mistakes and delays. Plus, explain why improving and standardizing the process and quality of requirements became even more evident as the world moved to remote work.
As standards in the energy sector increase, well-written, consistent, and error-free specification requirements need to capture clear, current, and compliant intent.
Lasting Effects of the Pandemic
Jordan – I would say one of the lasting effects of the pandemic is that it has accelerated digital adoption by 5 to 10 years. A huge leap forward!
Geoffrey – Yeah, I think it’s one executive oil and gas I interviewed for my next book that’s coming out in a few months. He estimated it was 20 years in the space of two. Yeah, huge shift! But let’s hop into the podcast! The meat of the conversation if you like Jordan.
Who is Jordan Kyriakidis
Geoffrey – So let’s begin with a little bit about your background. Where you’ve come from and what you do. If I’m not mistaken, if I remember from my notes, it involves physics.
Jordan – It is! My background is indeed theoretical physics. For about 15 years, I was an academic contributing to the body of knowledge of quantum computing and quantum theory, generally. So, I was an academic theorist, complete with leather elbow patches and everything. And so, I call myself an accidental entrepreneur. My current path started when the chief scientist of a large aerospace company reached out to me with a problem they were having. One thing led to another. I followed my nose, and here I stand before you today.
Solving a Problem
Geoffrey – An entrepreneur in technology! So tell us about QRA Corp and a little bit about what it does!
Jordan – Sure. We can talk about what business problem we’re trying to solve?
Geoffrey – Yeah, that’s probably the right place to start.
Jordan – Let’s take oil and energy companies as one typical example which may be relevant here. All energy is a very large segment for us. The question we try to answer; help our customers, is how can you ensure that what you build is what you intend to build? Not only are you building it correctly, but also are you even building the right thing? Now, that seems like a simple question, but global supply chains, a tremendous number of people involved, development time measured in years, and new technology all the time. Capturing your intent in a clear, correct, and compliant manner is quite difficult. For most companies, the intent is captured in requirements and technical specifications. So, the problem we solve is to make sure that our customers’ requirements and the technical specs are clear to everyone with no ambiguities and that they conform to best practices.
Geoffrey – Now, why is this hard to do? The Egyptians, for heaven’s sake, were building pyramids to specifications two thousand years ago. Surely this problem has been solved, yet you stand before me today asserting that it is not solved and there’s still ample room for improvement. Hence, there’s all business around it. So, what’s not solved here? Or what is it that companies struggle with?
Jordan – Companies struggle with writing things in a very clear and concise way. So, if you take the Egyptians example, building pyramids, every pyramid was basically the same thing, and it was not very complicated to build. You just stack one on top of the other. Compare that to modern oil fields or modern technical development; now it’s very complicated. Lots of people involved, lots of new technologies, and lots of moving pieces. By its very nature, it’s not easy to change directions if you uncover a problem later on that you could have uncovered earlier on.
Some of these projects have momentum on their own, and once you go down this path and you find you made some kind of mistake in the way you expect it, or even a misunderstanding or misalignment between the suppliers, you can’t go back and fix it. So now we have to start talking about workarounds and how you’re going to incorporate this, and these errors start compounding, and a lot of times, it’s because the initial specs had an error or some kind of ambiguity that was interpreted in different ways by different people and companies and it wasn’t caught early enough.
Geoffrey – Yeah, can you give me a real-life example where somebody called you to help them fix this? Like, just tell me the story.
Jordan – Well, there was an oil company.
Geoffrey – No names. (chuckles)
Jordan – No names, no names, I’ll be careful of what I say. (laughs) So, an oil platform out in the ocean. They wanted to have some fitting that they wanted to put down at the bottom. They found out they had the wrong size of this part. They found out that when they had it right there, ready to install, that’s when they found out the error. The supplier who supplied it delivered the right thing, but they just ordered the wrong thing.
That’s an example that probably started life in a document or a database. If that was caught right away, then the person who wrote that could’ve just said, “Oh, that’s a mistake, lemme just fix that.” If there was a little red light that came on the computer screen right then and there, it would have cost them potentially two or three minutes. But now, it ended up being a month delayed because a lot of these parts are specialized, they’re not stocked, not off-the-shelf parts. So that’s one example of the kinds of errors we are talking about.
Geoffrey – Yeah, I can see that can happen as a transcription error somewhere. Where can you use an example where “ambiguity”; because you’ve used that word two or three times, and it just strikes me as a really important element to the story here? Someone would say, “This is ambiguous.” But someone else can just easily misinterpret it as something else.
Jordan – Yeah. So, a simple example could even come down to the level of individual words you use. Words like “immediately” or “quickly” or “sufficiently.” Oftentimes when you write this in a requirement, especially if you’re a tier-one supplier or even an OEM (Original Equipment Manufacturer) who put something out to tender; people bid for it, looks good, what they’re generally trying to build it to specifications. But the specifications are not quite wrong, but it’s not quite what they intended to deliver, so there is some kind of ambiguity. Oftentimes, it could be some non-functional requirements like the performance or the weight; they’ll say they won’t specify.
I’ll give you one specific example again, no names. There was a control system and when the control system had something wrong with it: there’s error detection, and the control panel would light up saying, “Hey, there’s an error in this piece of component, you got to fix it.” Now, how fast would that component come on if you say it should be immediate? For some people, immediate could mean a microsecond. In some cases, “immediate” could mean just that day. So, if you’re a bidder bidding on something, that can be a huge difference in the price of what you want to deliver. Whether it’s a millisecond or whether it’s a day, these are things that oftentimes when you’re writing the requirements, the person writing doesn’t know at that point. So, I’ll leave it till later, we’ll catch it as you go along. So that gets slipped, whereas if they use a tool like ours, QVscribe, it’ll just flag it. It has a set of markers that detect, “Hey, there’s a missing piece, you got to fill this out eventually before this becomes an ambiguous term.” So, you can imagine a big document can have hundreds of these types of things in there.
Geoffrey – Oh yeah, for sure! Well, I’m writing a book as I mentioned earlier. I can tell you that ambiguity is even in the author, book world. Ambiguity is a critical problem. I generally resort to words like “generally true” as opposed to “precisely accurate” because precision is a real problem. When you try to be super precise, when you don’t know the answer, you can put yourself into some considerable constraint I would think. That would be very true in an industrial setting where you’re buying some assets I would imagine.
Jordan – That’s right, and these types of things are becoming more important now for several reasons. One is that new technology is being introduced all the time. So the people who are either procuring or developing these systems are relying now more on the specs than they were before because they don’t have the personal experience that they had before.
Geoffrey – Yeah, that’s true!
Jordan – If you were a master pyramid builder and you built 100 pyramids, all of a sudden you got some specs where some kid wrote the specs wrong. You look at it and it’s like “I don’t know who wrote this, but I know how to build pyramids, and what’s wrong. I’m going to build it correctly.” But now if you’re building a chariot; the analogy may be wearing thin now (chuckles). You don’t know anything about chariots, so you’re going to rely on the specs. It’s like “Well, I don’t want to build it, but here are the instructions, here are the requirements. Yeah, I’ll just build it according to these requirements from the specs.” Now, you’re relying on those. It could be that the specs were always terrible, but your master build starts developing and you rely on both, that’s one factor.
Another factor is all the senior engineers are retiring, so they’re leaving the company, and this knowledge is kind of leaking away. There’s another issue where requirements are becoming more and more important. The third factor is a general move. Like we were talking on top of the show about the pandemic, a general move being remote. This means things become more asynchronous, which means that the written word is becoming more important now because it is the official record of notes. Because it is the artifact that you refer to all the time. So now, all these requirements are becoming more and more important.
Geoffrey – Yeah, I’d throw one other into this mix which has been going on for the last 25 years, but supply chains have been globalizing. When it used to be, if you were making something in North America, the fab shop, the engineering company, the design outfit; they’re all down the street. You can pull them together and talk about what you’re trying to build. But now, you’re dealing with international companies; English is not always the first language, might not even be the third language, so interpretation of the language becomes critical.
Geoffrey – If you don’t have the specs crystal clear, it should be no surprise that some sort of misinterpretation or error starts to creep in even back in the design stage.
Jordan – That’s absolutely true! In fact, it is a big use case for us in these global supply chains that people with English are not their first language. There have been these templates that have been generated. One of them that is fairly common, especially in aerospace and a bit in automotive, we’re seeing it now in energy companies as well. It’s called EARS (Easy Approach to Requirements Syntax), and they’ve identified six or seven patterns of requirements. One that is always true, true sometimes, true if only features are present and categorized and said, “For each class of these requirements, here is a template structure that you should write your requirements in.”
Geoffrey – Oh right, so I’m just giving you the sentence layout like “Actually, here’s how you would write the sentence so that you get the requirements.”
Jordan – Yeah, it’s always a passive voice, no. It is always a subject-verb. Object, observer, and actor; these things are all present. The good thing about that is it makes it uniform, so as you’re reading requirements, it’s all in the same kind of format, so you have less brainpower to interpret the requirements.
Geoffrey – Yeah, maybe faster!
Jordan – Also, you enable tools to do the analysis, so now tools can come in and say, “You know you’re missing the actor here; you’re missing the system here.” So, the requirements can be always true, or only sometimes true; you can capture all these very quickly. So, what a lot of companies are doing is adopting those standards as well.
Geoffrey – Yeah, that’s really important, it’s an extension of where natural language processing, AI tools, meets in engineering specifications, supply chain, or manufactured goods. There’s no question there’s a considerably used case lurking in there.
The Value Prop
Geoffrey – Can you share a little bit about when companies set out to solve this challenge, what results are they telling you that surprised them? You know what I mean? When you pitch or share this concept with somebody and they say, “Hey, this technology will give you this.” What do they tell you when they say, “What, we didn’t anticipate that benefit, but it showed up too.” Did anybody give you something like that?
Jordan – Yeah, the initial benefit that they find after using the product for say, several months, is that they find that their review meetings go by much more smoothly. They spend a lot of time talking about the syntax or the meaning of requirements and they’re able to elevate the discussion to a more strategic conversation like “Are we building the right thing?” As opposed to “What does this even mean? What did this person write to you about this? Is he here? What did you mean when you wrote this?” You have all this wasted time in these meetings. Review meetings are generally expensive because oftentimes, you have ten to twelve people around; it could be multiple days, it’s your senior engineers there as well. What they find is a lot of the drudgery goes away.
So, the way some companies have started using our tool in their process is when you write the requirements before it even goes to a review meeting, you have to run it through our tool, and you have to have a certain score. We score according to the various metrics of ambiguity. If you don’t meet a score of at least ⅗ or ⅘ (60% and 80% respectively), it’s not ready to bring to review so don’t even bring it, work on it again.
So previously, it would be another human being who does that, and they’d read it and say “No, what do you mean? This is not clear, this doesn’t conform to standards, you can’t run it this way, go back and rewrite it.” So those cycles don’t completely go away, but they are greatly reduced, so the review meetings get better.
Geoffrey – So what’s hidden in here, Jordan, is human capacity gets freed up. It allows a company that has constraints on the human capacity to improve the productivity of those resources by an order of magnitude. So that’s what’s really going on and as I would see, you could save a few minutes of an engineer’s time, and maybe they don’t in a meeting as long as they would. But, if you can free up months and months of engineering cycles because of this, you expand the business to grow without having to wrestle new resources, like that’s the price.
Jordan – I completely agree Geoff! That is a huge free up of time to do that, and if you talk to a lot of engineering leaders, not just oil and energy, but across the world, they will say a big issue they have is they have a lot of high-value engineers doing low-value drudgery. It’s a terrible thing, so anything we can do to free them up from that we should do because the human value should be put on deciding what to build and how to build it. Not on “Did I cross all my T’s and dot all the I’s.”
Geoffrey – Reminds me of a funny joke which escapes me at the moment, but something about teaching pigs to sing opera. Not only is it hard on the ears, but the pig doesn’t like it either (chuckles). You can see this; you take your most senior people, trap them away for days at a time. Think about a 12-person meeting, how much time are you talking or thinking during that time stretch? Are you 100% utilized? Are you contributing all the time? Are you just kind of listening while one person talks and the other eleven just listen in? The ability to improve the capacity of that resource to achieve its maximum potential is amplified here, no question about it.
Jordan – Yeah, I think it was bad before. But now that these meetings are also remote, where you’re sitting in front of a screen, we have twenty-four other windows open, and the attention span is even worse now.
Geoffrey – Yeah, how do you even do that when you’re staring at documents. I mean it’s diagrams, it’s taxed; it’s been mind-bogglingly numbing. I can understand why young people kind of look at engineering now and go, “Hmm, I don’t think so.”
Jordan – Yeah, so the good news is there is a technology that can alleviate some of that need. So, you know, going through hundreds and hundreds of requirements, you can look at the ones that identify as potentially risky, and so you can focus on the high-value ones first.
Geoffrey – Now that engineering is shifting to pure and not hard technology, as in steel, cement, process and wires and the like. But to soft technology; software and coding, there’s more code in the Ford F-150 than there is in the large hadron collider in Switzerland. It’s very code-heavy. Can you use this technology to do things, like fixing your code requirements because of a big chunk of the delays? Just thinking about the Canadian government, there’s a phoenix payroll system that has been delayed for years. The system doesn’t work probably because the requirements weren’t clear. I mean, can you apply it to that domain too?
Jordan – You can! Yes, it really is a tool that’s suited for technical requirements and engineering.
Geoffrey – Regardless of what the domain is if it’s just technical requirements.
Jordan – Regardless of what the domain is, that’s right. Engineering is engineering, and if you have any kind of complex engineering project, you want to undertake. You need to do things in a certain way so that software at that high level is not different. I would say software requirements traditionally have even been worse than hardware requirements because, for a long time, people understood that hardware requirements are a big cycle. It’s very expensive because you can’t iterate very quickly.
Geoffrey – Yeah, like “Take care, let’s get it right.”
Jordan – Yeah! In software, you can do that quickly. But now, if the software is integrated into the hardware, the software is becoming more like hardware as an engineering discipline than it ever has before. So, you need to apply that level of – let’s call it fastidiousness.
Geoffrey – Yeah, fastidiousness, love it!
Jordan – So we’re seeing that well. It can equally apply to software or hardware, but it still needs clear requirements.
Geoffrey – What’s the reaction when you rock up to some outfit that’s been doing this for a hundred years. They pride themselves on their ability to get it right. They don’t have budget overruns or schedule overruns and you say, “I can do this 10% better, faster, cheaper, more correct.” What’s the reaction? Do you have a lot of change resistance or a lot of initial reaction?
Jordan – I can give maybe two kinds of answers. One, why would they call us if they had no problems. Calling us means that they do have a problem, to begin with.
Also, we do hit obstacles, we do get resistance to change. We try, I think above all, to be empathetic to our customers and our users. Part of it is not just forcing change on them but trying to understand the resistance to change.
The way I describe it is that it’s not enough for us to solve the problem, we have to also solve for them the path. By that, I mean we need to provide a solution that not only solves their problem but also solves it in a way that can work for them as well, so in a way that integrates with what they’re already doing. By being empathetic, we try to listen to their concerns; we hear a lot about disruption, and I’m very happy to disrupt our competitors. Our product and technology are newer and better, but I don’t want to disrupt our customers, they have enough problems already. Our job is to lessen their burden, not to replace them with other burdens.
Geoffrey – Yes, very true!
Jordan – We try to be empathetic with our customers. We listen to their objections carefully; we have our support team. Often, our product team speaks directly with our customers. Usually, if you have initial resistance, we try to probe “Where’s the problem? Why don’t you like the solution? What is the actual issue that you have?” In some cases, I always say the problems we have are problems that we can solve. We’ll say, “Oh I see, that’s your problem. Okay, maybe we can do it this way.” Our product development has evolved by listening to the cantankerous engineers telling us what they don’t like and getting down to it. They’ll say “Actually, that’s correct, that’s not a good way to solve the problem, we’ll go back, and we’ll try it again in a different way.” That’s one advantage of being a small company. We can be quick and very responsive to our customers.
Geoffrey – Yeah. You know a lot of engineering requirements are highly repetitive, like if you were putting on a compressor, or in the power world some sort of transmission asset, or a step-down voltage device. But the requirements; there seems to be a fair level of repetition work here, where the same requirements get written over and over and over again. Is that real? Because that leads to the concept of “Well, I could have a library of predefined, very clear specifications that I can pick and choose. Now, I can start to design my requirements not from scratch every time, but grab this module, etc.” It’s like LEGO bricks if you know what I mean.
Jordan – Yes, I do know what you mean. That is definitely where the energy industry is moving.
If companies can see their requirements not as documents or a narrative, but rather as a database or a library of specs and intent, an asset in its own right, then productivity will increase tremendously. Thus, fewer mistakes will be made.
Geoffrey – Yeah of course!
Jordan – As you said, these things like compressors, or step-up voltage transformers, are very common. If that’s all you were doing, you wouldn’t need a special tool to manage analyzing your requirements. The problem is two-fold. First, no one writes requirements from a blank page, they usually take something that they already have, and they modify it. So, the question is, do you have crud in your requirements now that don’t need to be there? Are you missing some stuff that ought to be there? That’s one element of having this copy-and-paste sort of mentality.
Another aspect is the innovation agenda: when you’re doing something new or changing management. So, you have an oilfield, and it is a brownfield now. You want to start doing things with it. Right now, what you had before is kinda relevant, but not exactly. What is relevant and what is not relevant. That’s where now, describing what you have and what you want, and what your intent becomes very important.
Geoffrey – Much more important, yeah that’s very true. Reminds me of another funny story of the refinery in Newfoundland, on Come by Chance harbor. That refinery design goes back to the 70s or 80s when it was built. I don’t know if you heard the story; the design of the refinery came from a similar refinery in Hawaii. Because Newfoundland is an island, Hawaii is an island, so for whatever reason, practically the same place. Why don’t we just build the same refinery in two places? So, they hauled the diagrams off the shelf for Hawaii and they built that refinery in Newfoundland, without considering the fact that Hawaii is at the equator, and Newfoundland is not. So, the Newfoundland refinery was built without insulation. It’s now a major problem in Newfoundland’s climate. A great example of where requirements were simply skipped over; just taking yesterday’s document and dressing it up and calling it “Today’s new refinery.” Probably not a good strategy.
Geoffrey – So you’ve been at this for a while, what lessons have you taken away? I mean, when young people join your company – if you had two or three Jordan life lessons that you pass on, which ones come to mind?
Jordan – (Chuckles) I would say that most of my lessons would be about our company, on our own internal development, and I would say what I’ve learned is that:
- People are generally good. They care even though our customers are detractors, they care about their work. They want to do a good job. If they don’t like what you’re doing, it’s because they think it’s not going to improve their job. I mean, there are some bad apples, but that’s very few.
- Empathy is very important. Trying to understand other people.
- Another thing I’ve learned is it helps to empower your team. Having an empowered team makes all the difference in the world. It makes it more fun as well. For example, our software engineers; I try whenever possible not to give them features to build out but give them problems to solve and let them go about and solve the problem. I introduce them to the business needs and have them talk to our customers and say, “Look, speak to this person yourself. You’ll see he’s not some disembodied voice. It’s an actual human being who’s doing work, who wants to use something that you’re building. So, help them. Understand them.
- So, I would say those are the main things.
Geoffrey – Yeah, talk to your customers and be empathetic. Those are two skills that are not going to be replaced with robots anytime soon. (laughs)
Jordan – They’re not, I agree. (chuckles)
Geoffrey – This wave of automation is not gonna attack, it’s not gonna address empathy anytime soon. (Chuckles) Jordan, it’s been great to talk with you today, and very much appreciate you coming to Digital Oil and Gas. If people want to learn more about QRA Corp and the toolsets that you’ve got in hand, where do they go? What’s your website?