This month’s edition of the Oil & Gas Measurement Podcast features Dan Nardella of Quorum Software discussing how to stack the deck in your favor for a successful measurement software system implementation.

In this episode, you will learn about what goes into successful planning for a software implementation project, specifically when planning should start, who needs to be involved, and how to set expectations for the project. Weldon and Dan also discuss the importance of clearly defined success criteria, thorough test planning, and team involvement/buy-in throughout the organization.

Measurement Software Implementation: Show Notes, Links, and Insider Terms

• Dan Nardella is the Director, Professional Services, for Quorum Software. Connect with Dan on LinkedIn.
  • Quorum Software connects people and information across the energy value chain. Since 1998, Quorum has helped thousands of energy workers with business workflows that optimize profitability and growth.
• FLOWCAL by Quorum Software is an oil and gas measurement software platform that is used by operators for the back-office validation, processing, and reporting of natural gas and hydrocarbon liquids.
  • TESTit is used to manage gas and liquid meter inspection and calibration results, testing and sample schedules, and conduct field calculations for flow rate and equipment sizing. 
  • PROVEit is a  comprehensive and integrated software package used to prove, track, and manage meter performance data based on the American Petroleum Institute’s Chapter 12.2.
  • myQuorum TIPS manages over 650 plants and over 300,000 physical meter locations daily.
  • myQuorum Field Insights optimize production by integrating end-to-end field data capture, operations management, and production reporting.
  • Quorum PGAS liquids/gas measurement is an industry-leading software solution for gas and liquid measurement. The system is an auditable enterprise data management software solution that serves as a central repository for all volume and energy measurement data.
• MIPS (Measurement Information Processing System) is a legacy measurement software system introduced by Software Performance.
• M&A Activity (Merger and Acquisition Activity) occurs when two like companies merge into a larger company or a larger company acquires a smaller company. Both cases require efforts to efficiently merge and integrate the assets. 
• Shrink-Wrap System or Shrink-Wrapped Software is commercially available software, designed for implementation without customization.
• SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at remote locations.
• Parallel Testing is a software testing process in which multiple software applications or versions are tested with the same input and/or user actions.. The purpose of parallel testing is to determine and evaluate any differences in results or performance between the legacy and new applications.
• Success Criteria are the standards/levels by which to judge whether an objective/goal/ target/outcome has been achieved and is successful.

Measurement Software Implementation: Full Episode Transcript

Weldon Wright:  Welcome to the Oil & Gas Measurement Podcast, episode 5, sponsored by GCI, the Gas Certification Institute, providing training, standard operating procedures, consulting, and field operations software to the oil and gas industry for over 20 years. For more info on GCI, visit GasCertification.com.

[background music]

Announcer:  Welcome to the Oil & Gas Measurement Podcast, where measurement professionals, Bubba geeks, and gurus share their knowledge, experience, and likely a tall tale or two on measurement topics for the oil and gas industry. And now, your host Weldon Wright.

Weldon: Welcome to episode 5 of the Oil & Gas measurement podcast. I have Dan Nardella here from Quorum Software and we’re going to talk today about stacking the deck for successful measurement software implementation. More specifically, the upfront planning that needs to happen before the “real work” begins. But, before we start, Dan, tell us a little bit about yourself and what you do for Quorum and how you got there.

Dan Nardella: Great. First, thanks, Weldon for having me here today. I’m excited to be talking with you again. It’s been a little while since we caught up. My name is Dan Nardella. I’m a director in our professional services group here at Quorum Software and my main task is overseeing a team of project managers and consultants. I’m responsible for making sure that they’re successful in our customer engagements.

So I oversee a team. It’s about 35 people that provide implementation services for a wide array of different types of projects that we do. That can be upgrades; it can be new implementations. It can be migrations to our cloud offering. It can be business process consulting and everything in between, so my team’s really composed of a lot of people that wear a lot of different types of hats depending on the type of engagement that we have and my team also supports a wider portfolio of different software offerings that we have.

Now specifically we provide software for our measurement customers, which would be FLOWCAL and the associated field applications TESTit and PROVEit. I also oversee teams that work with our gathering and processing software which is called TIPS as well as some other products that Quorum offers specifically.

A new product that we acquired is called EC Production as well as a product called Field Insights, which is really a field data capture type application. So, overall, my team is really supporting a bunch of different projects primarily in North America.

We do a lot of different things. There’s never a dull day here. I’ve been at Quorum now for over 12 years. I started off as essentially a project team member. Grew my career as a consultant into a project manager overseeing a team project then from there multiple projects multiple customers and from there within the last couple of years have taken a leadership position where I oversee a larger portfolio in terms of teams and projects that we run here at Quorum. So, like I said, it’s now a team of about 35 people over a wide array of products that we have.

Weldon: That sounds great Dan. That’s quite an operation there and I know your team is one of many that Quorum operates also in the different software areas. My expertise has mostly been with measurement software systems. But I’ve dabbled a little in the TIPS side.

I probably first worked with FLOWCAL sometime in the early to mid-90’s – probably did my first FLOWCAL project as an integrator back in ‘96 or ‘97, then I worked with PGAS. So I’ve installed FLOWCAL. I’ve installed PGAS. I’ve taken out MIPS; I’ve taken out PGAS. I’ve taken out FLOWCAL and put them back in. So I’ve been rolling around this for quite a while and Quorum has some excellent software offerings out there.

While we’re going to talk specifically about measurement software projects, I know that what we’re going to talk about is going to spill over a lot into the other offerings also, but the main thing is that no measurement system software project I’ve ever been involved in was just a “measurement project” in those air quotes, right? So IT, IT systems, security, SCADA accounting – all of those usually are involved in measurement software products in a measurement software implementation project. Whether it’s a new software implementation, whether it’s just an upgrade of an existing system.

Maybe it’s a replacement of a homegrown system with an off-the-shelf product – but you’re going to have lab results that are coming in. You may have lab results being fed back down to end devices. A measurement project can even involve updates or replacements of Flow Computers and field devices. So a lot of things go into this and these projects are really complex and they’re complex even if there’s no custom dev work being done, right?

So what I’d like to talk about, what I’d like for you to visit with us a little bit about, is when should we be planning for these projects? How long in advance should we be thinking about them and who needs to be involved in that on the customer side to help facilitate a successful project in the long run.

Dan: That’s a great question and there’s probably not a single answer to that question. I think a lot of it is “It depends,” which isn’t always a great answer, but typically you want to get as much runway as possible because like you said there are a lot of stakeholders that are, or can be involved in these types of projects and the actual software itself might just be one piece of a larger pie.

There’s also considerations in terms of, like you mentioned, security or hardware if the customer is going to be hosting this software within their own landscape. They need to go through those steps in terms of procurement of the hardware setup and that can take months at a time. So the more lead way we can get on starting a project the better because. By the time you’re actually ready to install the software, it could be two to three months after you’ve conceived the idea of let’s get a project going.

So, really, the more time in advance that you can start a project, in terms of bringing in the right stakeholders into the room – that could be representation not just from the business, it could be their customers making them informed of that. It could be infrastructure groups and security groups. So all these different stakeholders need to play a role in the project. Really, it’s “sooner rather than later,” and an important aspect of that in terms of starting a project successfully is you really want to have a high level of engagement from the start of the project. You really want to bring the right people in. You want to be setting the right expectations. You want to be talking about the success criteria from the very beginning of the project.

How are we going to measure that this project is going to be successful? Defining that criteria upfront and then using that as really your blueprint and your guidance for decision making throughout the next phases of the project really helps in terms of making sure that it’s successful.

Weldon: Absolutely. You know we talk about as much runway as we can before we start these projects but, of course, as you mentioned that kind of depends right, because you may have a project that may be stemming from an acquisition – and I’ve been involved in a number of projects like that, where a major acquisition, sometimes multi-billion dollar acquisitions are made that may have been going on for a year, but, of course, no one can really talk and plan until the inks dry on the dotted line.

Then, all of a sudden it is a major rush to integrate. Sometimes the same system. Maybe you have two FLOWCAL systems or two PGAS systems or two whatever systems that are the same… but more often than not, you have two different vendors products out there, or a homegrown system and a commercial system, maybe two homegrown systems, and you’re trying to merge those together, update them, and install a commercial product. And, that may happen in an environment that has a very very short fuse on it and yet a company that has identified the need to move from their legacy in-house developed and maintain software.

Dan: Yes.

Weldon: On a new system, those people may have a year or even two years lead time in the planning the budgeting states, so it definitely creates a very varied atmosphere you’ve got to work in, but I think the key thing there is probably making the most of the time you do have. Would you agree with that?

Dan: Absolutely and this is something we’ve seen especially over the last couple years with a lot of M&A activity. There have been a lot of projects that have come into our view that really have short turnaround times on them as short as 90 days.

Weldon: Wow.

Dan: And so that’s not necessarily the time that the contract is signed with us, the software vendor. It’s really 90 days from when the agreement went final so we might actually get less than that.

One of the key things that I think is super important is you need to focus on separating the critical, from the important, or the “nice to haves,” right? You need to understand if we only have 90 or less days to be able to get this software operational. What are those key things that we know on Day 1 that we need to have in place and working?

So maybe that’s making sure that our SCADA feed is connected to just flow into the software, like you can’t do anything without data, right? Or that might be some basic training. But then there might be some other things that are important but can go after that 90 days. Maybe there’s some follow-up training. Maybe there’s some custom reports that need to be tweaked or developed. Maybe there’s some other areas in the application to focus on in terms of new modules. So really kind of trying to keep the scope as simple as possible for what you need, within that timeline and going from there.

Weldon: And kind of at the same time, though, going back to what you said about stakeholders, you won’t know on a short timeline project to keep the scope as simple as possible, but if you don’t have all of the stakeholders involved and you’re not getting input from them, it’s very easy to miss significant, major parts of a scope, even when you’re trying to keep the timeline short. 

The same thing goes if you have that engagement for those stakeholders and they all understand why you’re doing the project, when you’re doing the project in the expected timeline, it’s a lot easier to get discussions around the “Is this needed, or is this a wish list item? Is this imperative to begin with or can it wait a little while?”

Dan: Exactly. So if you don’t have that engagement with stakeholders you might still get to your go-live date on-time, but you might not realize for two to three months later that you miss something, because they’re expecting something to fall, to come downstream, to them and they were left out of the conversations.

Bringing the right people into the room like you mentioned, from Day 1 or as soon as possible, so they’re, at a minimum, informed and have a voice into your overall project is very important for the overall success – not just of the software implementation, but of what they’re doing from an overall standpoint.

Weldon: Exactly, and I’ve seen that on projects so many times, where you get almost to the go-live, or actually to go-live, and say well “Where’s Xx?” “Where’s this export?” Right? Sometimes stakeholders even involve parties outside of your own company, where we have the data exchange, especially on regulated pipelines. We’re exchanging data freely back and forth. You know we need to make sure the other parties understand if our changes are going to impact anything there. So, getting that stakeholder engagement, and really studying it.

That brings me to another question I wanted to ask. To me, I’ve always considered that the scope of a project is very often a project of its own. Would you agree with that?

Dan: Absolutely.  Sometimes customers walk in, with a very limited or defined scope, in terms of “Hey, we just acquired this asset.” We just need to do a lift and shift and move it from here to there, and keep business moving, but other times customers are a little bit more open-ended or they don’t even know what they need or want so that really leads them to wanting to better understand, not just the capabilities of the software, but how they need to optimize their business and that’s where a scoping and planning engagement can add a lot of value where you’re able to really dissect the business upfront and then figure out how to optimize it through a software solution.

Weldon: Exactly. Dan and those guys out there that know me know that I did a little time with FLOWCAL, and then Quorum. There a whole lot of the time with Quorum. I’d probably spent 5 years there prior to that. One of my favorite engagements as a consultant was a scoping type engagement, and we had numerous cases where we started out with the customer thinking they understood the scope of the project and we thought we understood the scope of a project, but then when we turned around and really got into the scoping, we found out that it was an entirely different project in what it looks like.

We had a major energy company that started out with a project that thought they just needed an accounting system and it wasn’t until the scoping section that they found out they needed both the counting and a measurement system to replace their old legacy work. So sometimes that scoping is a bigger deal than, almost a bigger deal than, the end project, because once the scope is defined in black and white, the rest is a roadmap, right?

Dan: Exactly. I think back to my days as a project manager and these types of efforts were also my favorite specifically because the level of engagement from the customers is so high. They are very motivated. They are excited to talk about their business. Their pain points, with their what they want to get out of the system and it’s very much a whiteboarding session and can be very informal dialogue, but it can really brainstorm a lot of ideas and a lot of thoughts, on how they can really achieve more of their overall business drivers and objectives by just talking more about it upfront, solutioning out the next steps, and then different from there.

Weldon: Great point, Dan. I want to loop back to something you said just a moment ago and you were talking about success criteria for a project and making sure you decide and define that. And it becomes the blueprint for your project. And that, to me, is a subset of scoping, but very closely related to success criteria. You need your test plans to be well-defined before you can know what a successful test is.

So talk to us a little bit about what the process looks like for developing success criteria and then what those subcategories are in that they are geared around test plans or possible parallel testing, and those sort of things.

Dan: First, for success criteria, I’m a big proponent of making sure that that’s something we flush out as a joint exercise, between my team and the customers team, at the very beginning of the project. So ideally, we’re doing this even before kickoff.  We’re asking the questions: Why are we here? Like what are we trying to get out of this project? What does your company, your business, your users need at the end of the day that makes this a valuable project and worth their time and their money for my team to come in and work with them? Typically, you know that can range from a lot of different reasons on why customers do projects.

Some of the reasons might be that you know, they’re doing a lot of manual things and they want to optimize their business further or automate their business further. They want to be able to incorporate more enhancements that play benefits to all their users in terms of reporting, maybe? They want to basically be able to move more gas and drive revenue higher. It can be a lot of different reasons and a lot of drivers behind these projects, so understanding why you’re doing the project and then lining up.

Well, how are we going to? How are we going to measure success at the end of the day? Very important at the beginning of the project and it’s really the customer that needs to help paint that picture, but we need to be in agreement with them on moving forward with it. We should always be looking back to these success criteria as we’re going through the steps of the project to say, “You know if we’re at a decision point on XY and Z, how does this align with what we talked about at the very beginning of the project in terms of how we were going to measure success?”

Weldon: Absolutely. I’ve been involved in projects myself Dan, where success criteria was something that was not defined and not documented at the beginning of a project. “We needed a measurement system installed, and it needed to work the same,” was the success criteria. And, you get into a project and you have a project, that’s really been a pretty successful project by most measures, and yet you get toward the end and you find out because there wasn’t documentation of what that criteria was and how you were going to meet it, how you’re going to define it.

Because you lack that definition, you end up with one or more stakeholders fairly frequently – it might be a stakeholder that felt they were slighted in the process – that refuses to agree on relatively small details. I know you’ve probably seen that.

Dan: Absolutely.

Weldon: Looping back, I want to talk a little bit more about the actual test plans and how customers define testing. And I know that’s another, that’s it’s a piece to success criteria, correct.

Dan: Absolutely. I’d love talking about test planning, so this is a subject right up my alley.

Weldon: Because you know if you don’t have that plan put together, many times multiple iterations of testing are needed especially if there’s a software development project, right? Or if you’re moving from a legacy system over to a shrink-wrap system, right? You may have multiple renditions.

Well, one of the most frustrating things that I found in a project is because there were was not a well-defined test plan, with well-defined and thought-out test scripts, that you have a section of the project that passed one time through, but you’ve repeated again by someone else a month later, and they get a different result. So, talk to us a little bit about developing those test plans, how you document them, and who should be involved in that.

Dan: You mentioned a good word there in terms of “plan.” It’s not a test case; it’s a plan. A lot of times when we initially start talking about testing with our customers, they’re just thinking about, “Oh, we’re going to go into the system. We’re going to hit on the keyboard. We’re going to execute some test cases and we’ll be good.” And you know that’s very shortsighted because it really is a plan.

There are a lot of considerations in terms of what users are you going to bring in, at what phases of the project, which environments are you going to be doing this, and how are you going to layer in your enhancements? How are you even going to write these test cases? Is that something that you already have? Is it something you need guidance on how you’re going to measure success of your testing? What’s asked and what’s your criteria to move from one test phase to another or from test phase, to go live? What’s that criteria that needs to be met? How do you handle issues that come up during testing? 

Weldon: Exactly.

Dan: So, what does your issue tracking system look like and what’s the process for how those issues are reviewed and triaged and resolved and deployed? There are a lot of factors that play into testing in general, which is very important, and why you need to have a plan on testing well before testing even starts.

Weldon: Yes. That was quite a list of “Whats” and “Hows” you went through there, Dan. We could dive into that list and make another 30-minute conversation probably out of it. I think you’re exactly right and you’ve hit a lot of great points. But, one of the biggest points there is, there’s a lot of questions and, if you start your project without answers to those questions, you’re putting yourself in a situation that success is going to be either more difficult than it could have been, or near impossible right.

Dan: Exactly.

Weldon: You know, as we’ve talked about testing and test plans, one of the things I’ve seen in the past, Dan, that has been at the same time, one of the most misused parts of a test plan has been parallel testing. And I’ve been in projects where the customer’s only intent was “I’m going to parallel test for a month and we’re either going to be good or not good,” with no idea what parallel testing was going to mean.

Does that mean they want every meter on their system to import through the old system and the new system, and they want to see the exact same answers out six decimal places? I worked on a project like that once. It wasn’t fun, because it wasn’t defined beforehand. While a test plan, in my opinion, should usually include parallel testing, and parallel testing needs to be well-defined.

It needs to say, “Hey, we’re going to take 10% of our meters which we randomly select are maybe not so randomly. But based upon a cross-section of our meter types, we’re going to take 10% of all of our meters. We’re going to distribute that work between x number of analysts. Those analysts are going to do 100% of the work on those 10% of the meters in both systems and then our success criteria is we have to be within x percent of the same value when we get through or x percent the same number of exceptions or x percent the same, or the amount of missing data.” 

But I see all too often that a company thinks they’re going to do a parallel test plan and they don’t allocate the resources to it. A parallel test plan takes a lot of manpower, or womanpower.

Dan: The thing that people don’t always appreciate with the parallel test, is you’re asking your users to do the same thing in two systems for some amount of time. So, some customers have the intention that we’re going to do a full month parallel or I’ve even heard multiple months parallel, and by the time you get into it and you’re asking your users to make that kind of commitment. We’ve also seen that over time users can get kind of careless because they’re having to just do essentially twice as much work.

So, I think it really comes back to that point that you made, Weldon, about identifying what is the scope of your parallel testing, if that’s something that you’re going to use to measure the success of the test cycle. To go-live, you need to identify what the scope of that is and maybe that’s a subset. Maybe that’s tying out to within a certain threshold.

There’s a lot of variables that can come into play with parallel testing, as well, so you need to be careful there and also appreciative of recognizing the amount of effort that it can take to do a parallel test. Coming from a FLOWCAL system on one version and going to a FLOWCAL version on another system is kind of apples to apples. So, yes, you can do a parallel test there because there’s not going to be a whole lot of differences. If you’re coming from a homegrown system to a commercial software system, you can spend a lot of time trying to figure out which system is right and which system is wrong, and trying to compare the data. You really need to ask yourself if this is worth all the time, versus how do I get comfortable that the new system is the right answer?

Weldon: Right? If you’ve got an existing legacy system that hasn’t been updated, hasn’t been refreshed, in 10, 20 years in some cases. I’ve been involved in literally hundreds of hours of proving to the customer that your legacy system answer has been wrong all these years. In which case many, many hours sometimes, months, can be burned in that kind of scenario.

So you’re exactly right about having that at the beginning of the project and defining what those expectations are. Defining that success criteria. That success criteria may not involve parallel testing. It may involve parallel testing, but make sure you define what the expectations are for that testing and what you’ll be comparing to.

Dan: I think you also need to assess your risk. I think that’s an important part as well. If your business is drastically changing, in terms of using one system to another, like that’s probably pretty risky and so you do need to think through like how do you get comfortable?

Weldon: So important.

Dan: The new system is the right answer versus, if it’s more of a small build or patch upgrade then you’re probably doing maybe a smaller subset or something just to verify that the system is working like it used to.

Weldon: Yep, I think that rings very true Dan. I think you’ve made a lot of points here. We’ve talked about a lot of things that, taken in their totality, can help, or can sink, the success of a project.

You mentioned a couple of things there. Probably the most important thing that I think you mentioned in your discussion is “these projects have to be a team effort.” A team effort from the software vendor, a team effort from the end users, and a team effort from IT, from management. You know, all of them working together. Now that doesn’t mean that every decision has to be decision-by-committee, correct, but having team involvement and buy-in is critical. Anything you want to add Dan?

Dan: I don’t think so. It’s been great talking to you and I appreciate the opportunity to catch up with you and share some of my experiences and thoughts.  I’d welcome the opportunity again.

Weldon: Well thanks so much for your insight, Dan, and I appreciate you being on the show with us. Thanks a lot and have a great day.

Dan: Thank you.

Weldon:  Thanks for listening. If you like your podcast, please leave us a review on iTunes, Google, or wherever you get your podcast fixes from. A full transcript of this podcast is available at PipelinePodcastNetwork.com along with definitions of any geeky terms we may have used here.

If you have comments, suggestions, or if you’d like to offer yourself up as a guest, drop me a note on LinkedIn or click the Contact button on the bottom of the PipelinePodcastNetwork website. Thanks again for listening.