Integrify

This week we break down a case study of a workflow automation project that included over 130 tasks with a full time developer over a year timeframe. We get into the details of the requirements for a project this size, common challenges that come up, surprises along the way, and learnings to take forward.

Transcript

Erin Keating:
Welcome to NeoCast. Join us each week as we discuss challenges in government contracting, strategies and solutions for your businesses. We’ll dive into managed IT, cybersecurity, workforce advancement and much, much more. Sharing is caring and we’ve got top shelf advice to help you navigate today’s biggest challenges. Let’s get to it.

Erin Keating:
Okay, everybody. Welcome back to NeoCast by NeoSystems. Marty, I’m super excited. I think this is Episode 7 but I think we’ve lost our rhythm. I think we’re now in week eight of our lockdown. We were tracking with the lockdown for a while but I think we’re past… We’ve all lost our minds and we can’t remember if it’s December 16th or if it’s April 59th. So, here we are.

Marty Herbert:
That’s exactly right.

Erin Keating:
Episode 7, regardless. So, the first five episodes, as you and I talked about, we went all through business process improvement, management, change management, got through all the ABCs. We were lucky enough to have John Bartlett with Integrify come on and just talk a little bit about how you start to engage with your clients in these processes, workflow automation and so forth. And this week we’re actually going to get to bring on someone else from your team, Scott, and someone with Integrify, Roman, to talk a little bit about some specific… semi-specific war stories, if you will, about a real project that was implemented and some of the challenges that you actually came up upon and how you dealt with them.

Erin Keating:
So without further ado, Marty, if you wouldn’t mind doing the honors of introducing our guests today, I would appreciate it.

Marty Herbert:
Absolutely. So Roman comes to us from Integrify. He’s a senior implementation specialist. So he’ll be chiming in with some war stories along the way. And Scott is a senior business process improvement consultant with NeoSystems. So he’s the lead on some of our more challenging clients, especially over the last couple of years. So it’d be a fun time to talk about some of the things that we’ve done and really hit on some of the key pain points that we’ve seen as we’ve talked to some of our clients.

Erin Keating:
Such a lovely way to put it, “Challenging clients”. We’re so excited to have you here. And Roman, thank you for being here as well. Scott, I just want to kick off with you since we’re going to just dive right into a war story. Can you give us maybe a little bit of background, as much as you’re willing, as far as what the project was entailing and then at what point… How did you and the client decide to move forward with working with Integrify as part of the process?

Scott Goldschmidt:
So we were dealing with a large government contractor who was implementing Deltek’s Costpoint for more of their accounting management systems. And part of the workflow that we were building was project setup. How do you get projects set up into Costpoint and how do you deal with adding employees to the projects, setting up the revenue codes, and really building the project from nothing to being fully baked out.

Scott Goldschmidt:
When we first started the project, we didn’t have, or the client rather, didn’t have a tool necessarily in mind. They had gone back and forth, I think, between using Integrify because it was NeoSystems’s go-to, and our recommendation for business process automation. But they also, I believe, had another tool called K2, which is another tool similar to Integrify that is a business process automation workflow tool.

Scott Goldschmidt:
They ended up deciding not to use that tool because it was very challenging to use the tool and to get a lot of developers with their hands inside the tool. Because it was a very much customized tool. Integrify sort of has the… It’s an out of the box, it’s drag and drop, more simple to use. This K2 tool that the client had told us about, their IT team didn’t want to touch it.

Erin Keating:
Gotcha. Now you’ve gone through the process with the client. You’ve looked at K2, they’ve given you all the reasons why it’s too complex. Their IT guys don’t want to touch it. You say, “Well, then great. We’ve got this great partner Integrify. We want to bring them in.” What’s the next step? What’s the overview of how you took on the process, and what did you develop?

Scott Goldschmidt:
Before we started this project, we had already been sat down with a lot of the stakeholders, and some of the [inaudible 00:04:03] standing on their streamline and build out the process map for how they do the work today. So we already have the process maps going into developing an automated process map, if you will, in Integrify. So we sat down with the client and we said, “Okay. Well, we’re going to need a little more information. Because what we have right now is pretty high level.” It’s okay, well the SME gets a project and they need to build one and cost one. Okay, well, what are all the details that are involved?

Scott Goldschmidt:
So the first thing that we did was we sat down with the subject matter experts or the SMEs. And we said, “What’s the very first thing that starts this process?” In their case they had an integration with another system that they had custom built, which was a contracts management system that sent out a notification when a contracts administrator landed a project, and it was ready to be set up in their system. Which was, I’m not sure what it was previous to Costpoint, but moving on in the future, we knew it was going to be in Costpoint.

Scott Goldschmidt:
So then we had to gather all of the information for what are part of the forms, right? What kind of data that you get when this process starts? Well, you have a project number, you have a PM associated, lots and lots of information. So we said, “Okay. So what happens once you get this intake?” We had to automatically assign it to a person. How do you decide who you’re going to assign this project to?

Scott Goldschmidt:
Oh, well that’s based on the org ID. Okay. So we need to make sure that we have a table that maps the person to the org that we can use to map that to the user login for Integrify. And then let me just take another look at this process map. Because actually it’s enormous. Project set up can be a very simple workflow, but we found that there were over 130 or so tasks involved in this workflow.

Scott Goldschmidt:
But at a high level, we would capture the data that came through from the contracts management system, dynamically assign a briefing analyst, and then the briefing analyst would go through the part one of setting up the project. Which essentially, filling out all the header information. We then had to call a web service to create that header information and then create that level one, or level one through three, project ID.

Marty Herbert:
And I’m just going to chime in for a second too. If you think about building the stew. Right? And that’s really where it all starts with any of these processes. And this one was no different. It’s how do we make something happen in a system that is going to rely on a load of data? Not only are you looking at a workflow at the beginning, kind of like you and I have talked about before Erin, in terms of defining what your workflow is, figuring out where does it best fit and also figuring out where does it need to be? What does it need to do? And what are the integrations with other systems? And things like that.

Marty Herbert:
And especially with this client in particular, and Scott, I know you know this. As they started looking at the processes, it was well, which one hurts the most? And that’s the one they decided to go with.

Scott Goldschmidt:
Very true.

Erin Keating:
Yeah.

Marty Herbert:
Because it really is any new system, and we find this so many times, and I’m sure Roman probably has seen the same thing. We see so many times where we come in for a specific purpose because they know that the system they’re about to go into, or even the system that they were in, was giving so much angst in a certain area. And that’s why they decide to start tackling this one thing. Because, “Oh. This is the one we’re going to need the most help with. We should do that one first.” Sometimes great. Sometimes not.

Erin Keating:
Right. Well when you mention 130 tasks and Scott, you said it was enormous. What is a normal range of tasks in a particular workflow that you would be comfortable with? If 130 is enormous, is it 30? Is it 60? What are we talking about here?

Scott Goldschmidt:
So, well. That’s such an interesting question because it really depends. There’s not like a, oh, on average there’s about 30 or so tasks. Because, and I don’t want to get too into the weeds on this without getting too techie and involved with the dynamics of the workflow and how you build out processes. But I would say most of them are about a quarter of this size.

Erin Keating:
Whoa.

Scott Goldschmidt:
To put an answer. Yes.

Erin Keating:
And this was the most painful one. Okay.

Scott Goldschmidt:
Oh yeah. And what can be challenging, and I’m sure this is where Roman can chime in, is in the initial requirements gathering stage of the process, I like to use metaphors analogies. It’s sort of like asking, okay, well. You want to build a car or buy a car. What are some of the requirements for the car? It’s got to have four wheels. It’s got to be red. And the steering wheel has to be on the left side.

Scott Goldschmidt:
Well, you get all that information in the beginning from the client and you start building out this car, so to speak. And when you’re ready to test drive the car, you’ve had followup meetings to say, “Okay. There’s leather upholstery,” and whatnot. And then you get in the car with the client and you show them and they say, “Well, I thought this had adaptive cruise control. I thought we mentioned that. I thought we mentioned in one of our meetings that it was going to include that.”

Scott Goldschmidt:
And I think that’s a lot of where the challenges come from are, what exactly do they want in ways that the developer and that the analyst can explain to them how this tool works and how they should expect it to work.

Erin Keating:
Right. Well now of course I’m going to just call you out now I know what kind of car guy you are. Because you didn’t even start talking about engines, horsepower. Come on, man. You’re talking leather upholstery.

Scott Goldschmidt:
Oh yeah.

Marty Herbert:
It’s all about the ride.

Erin Keating:
Where’s the V8? The V12?

Scott Goldschmidt:
V8. Yeah. I actually don’t. I don’t own a car right now, so. Sort of outted myself.

Erin Keating:
As Marty knows, I come from a history of automotive industry. So this is giving me palpitations right now, talking about leather upholstery versus whether it’s got a V8 engine. That’s okay. I excuse it, Scott. Let’s get back to the task at hand here. So you were saying that one of the challenges in the beginning was even determining the requirements, is what I think I’m hearing you say is. Is helping the client to understand how to describe what the requirements are?

Roman Pendzich:
Yeah. Some clients will regard their requirements as being so self evident that they sometimes look at you funny when you ask them clarifying questions. Others will drag their feet in providing them for whatever reason, just organizational inertia, cultural resistance to change. And others will provide you with a completely detailed set of requirements. And those are the golden customers that are actually saving themselves money. They will provide you with a detailed, complete thought through set of requirements. Sometimes those are the simpler processes, but not always. I think the more the client can get one of their own champions invested in helping to build the process, the happier they are with the result.

Marty Herbert:
And just remember for everybody who’s listening in to this podcast, that the gold standard is to make sure you have your requirements built out really well, so that we know what they are coming in. And that’s part of the reason that we’re having these discussions in these multiple episodes, is so that the people listening can understand some of the pitfalls, some of the challenges and things like that going into a project in the first place. To be able to really help themselves. That’s really the goal of all of this is. To help you know what it is that you’re doing, and why you’re doing it.

Erin Keating:
Gotcha. So help me better understand a couple more of the challenges that you approached in this particular project. Again, I think you mentioned some of the upfront development challenges. So over 130 tasks, I think, if have my details correct on this particular project. Over 15 forms. Three different databases to pull from. Two different databases to push to. Custom API development. All these kinds of things.

Erin Keating:
So these seem like a lot of challenges that you already have upfront. Or just at least a huge workflow and workload that you have to get this project. We talked a little bit about how requirements are challenging. What are some other things that you faced in this particular project that were real challenges?

Scott Goldschmidt:
The test data that was available in the system. I believe I already mentioned that the client was going live with Costpoint at the same time that they were going live with this Integrify workflow. So the data that they had was all data that was still in migration from their previous system. And there were a lot of fields that would either return as no that were on the backend on the forms required to show.

Scott Goldschmidt:
So if you had a condition where, oh, if the project is direct and it’s federal, then show this section that they need to answer for these questions. And their project data would come back with, instead of being federal, it would say commercial services. And not only was this data coming from another system, but at first it was coming from their contracts management system.

Scott Goldschmidt:
And the language that was used to describe a value or a field on a form was not the same. So we had to create all these crosswalks and these translations to say, “Oh, well, if the value is this, it needs to be translated to this.” And that can really slow down your ability to move forward and test the workflow.

Scott Goldschmidt:
So, missing test data, or having test data that wasn’t the correct value. And all that information ties into developing the XML packets, which on a less technical term is how do you push the information from Integrify into your new system, like Costpoint? Costpoint is very particular about the data that they receive. So if a project number needs to be in a certain string, like five characters dot, two characters dot, one character, your form and your project numbers need to meet those conditions and requirements.

Scott Goldschmidt:
And that’s just one. So if you’re pulling data from another system where you have 40 fields that are not valid Costpoint values, you run into an issue. Or, oh, hey we don’t ask this question on the first form. We know when the contract administrator is filling it out in their database but it gets pushed over, how do we know what the answer is if we didn’t get it from the contracts administrator? Oh, what if there need to be changes to the contracts administrative database before it goes to Integrify? And then you got to have the back and forth and then it affects the APIs. And there were a lot of meetings where we had to sit down with IT to circle and just figure out how do we fix things that needed to be fixed from a different system when you’re already halfway through the workflow, so.

Erin Keating:
Right. So Roman and Scott, I’m assuming this is the type of thing where, Marty, you’re pulled in to help oversee perhaps the project or manage the team that’s running it. But on a day to day, again, not being terribly familiar with this process, Roman and Scott, how are you two interacting through this project? Is it very collaboratively moment to moment? Do you each have assigned roles in how you need to be working through these requirements?

Roman Pendzich:
Typically I would have a specific role. As the specialist coming in from the original vendor of the software, I’m often given a specific area of the software to deal with. Whether it be integration with another system at a specific level, usually through an API or something like that, an application programming interface. Scott would be, I would say, call him the sergeant or the noncommissioned officer of the team, where he would be doing the day to day organization of the team, lining up the tasks, knocking them down. I typically am brought in to solve a particular problem or advise on a particular use case that they might not have encountered before. Or maybe we have a best practice that they haven’t dealt with before.

Marty Herbert:
Yeah. And Roman really hit it right on the head too. Because he is specifically in Integrify and because they’re the ones that are building the software, he knows where the bodies are buried. He can lean in on those things that really take a lot of digging. Those things that we just don’t either have the technical capability to do, or that we saw once, but it really helps to be able to have the partnership that we have with Integrify, where, like Scott said, we know all of the Costpoint stuff. We know the government contract and compliance and that kind of thing.

Marty Herbert:
And when it comes time to do something that’s overly technical and overly cumbersome, maybe not cumbersome, but overly code specific to do, we may need to reach back into Integrify and say, “Hey, Roman. Hey team. We need some help because we’ve just not seen this before. How do we create this package? How do we create this JSON object that calls this API through this rest client task? That big, long string.”

Erin Keating:
You’re losing me. You’re losing me.

Marty Herbert:
Yeah. Me too.

Erin Keating:
I don’t know what you’re talking.

Marty Herbert:
I have no idea what I just said, but I know it sounded good, so.

Erin Keating:
I know. You just sound very smart. I love it. Well so then this makes me question, Scott, then if you were the guy in the front lines, how much coordination are you doing daily with the client? Is this something that they’re as heavily engaged with as well?

Scott Goldschmidt:
I’m handcuffed to them, really. No. There’s this constant-

Erin Keating:
Okay. We’ve got buried bodies. We’ve got handcuffs.

Scott Goldschmidt:
There’s constant communication. Because we’re developing one form and we realize, oh, well, what if this whole section that’s required is blank? Or what if it doesn’t apply? It needs to apply in some other way. There are so many functional questions that we don’t know because we don’t know exactly how they would do it without the system. I would say we had biweekly touch points, so. And I know biweekly is such a strange term because is it every other week? Or is it twice a week? But in this case it is twice a week.

Erin Keating:
Twice a week, right? Yeah.

Scott Goldschmidt:
Yeah. Twice a week I would meet with one of the functional sponsors and we would go over any outstanding questions, anything that was due. And anything that I didn’t understand or say, “What’s supposed to happen here. What are the values supposed to be? How do we decide how to map this information? Who should it go to in this situation? Well, what if the dollar amount changes. Does it need to be re-approved? Do we need to build in that additional level of re-approval every time there’s a change?”

Scott Goldschmidt:
So at a high level it’s really easy to put a workflow together. But once you get into the weeds of it and you see exactly how it works, it gets very granular. And you need to know all of the logic at the granular level. Because that’s what you’re really developing.

Marty Herbert:
Yeah. And it kind of goes back, Erin, I think we talked a little bit, a couple episodes ago I think, about that rapid prototyping idea. The idea that you put something together based on what you think it should be. And then you talk to people. Because they’re going to give you the best feedback. And that’s really what we do. And that’s the best way to describe it is, you’re constantly changing something until you get it exactly right with what they want.

Erin Keating:
Right.

Roman Pendzich:
Oh. I was just going to say that often you’re in the position of presenting the customer with two or three alternatives and helping them decide which one is going to fit their use case best. So it often is very much a repeated conversation. Sometimes they need to go back to their own subject matter experts because the person you’re talking to doesn’t know the business, they’re more technical. So yeah. There are a lot of meetings that come up ad hoc in addition to the planned ones.

Erin Keating:
It’s got to be… At least I’m a person who is continually curious. So I would imagine even if it is the same tasks you’re doing for every client, you’re really getting to know how a business operates in a different field. Right? Because you really need to know their secrets. You need to know how they’re processing things. You ended up becoming somewhat of a subject matter in their business on some level I would imagine.

Roman Pendzich:
Exactly. Sorry.

Erin Keating:
Yeah. Yeah. No, no. Go ahead.

Roman Pendzich:
Oh yeah. You do pick up some real tidbits. For example, I worked with one customer in the automobile field. They pointed out that they have an assembly line that moves faster than the human eye can see. So they’ve truly automated the art of making mistakes. They were actually very interesting because they had an engineering… And their organization overall had a very good mental discipline. So they were very good at actually bringing Integrify in house. They use it quite a bit. And they were actually using it for things like managing change within the organization to move things through their catalog.

Erin Keating:
Now I’ll try not to think you were just buttering me up by mentioning automotive.

Roman Pendzich:
No.

Erin Keating:
But I would agree with you that if you’re already in a field where it requires highly automated tasks and precision and engineering, that you’re probably… Those are your dream clients because they understand why you’re getting into the engineering of something. And they’re excited to see you break some eggs to figure out what you’re making.

Roman Pendzich:
Yeah. The flip side is that they can often be quite demanding because they know what’s possible.

Erin Keating:
That’s fun. Well let’s talk about some positive things that came. Or, well, I’m sure the whole project was positive obviously. I think you guys got these guys up and running and doing the right things. But Scott or Roman, what were some of the lessons learned out of this?

Scott Goldschmidt:
Some lessons learned. Definitely start with reviewing all of the XML packets and your web service information before you get started on developing and sitting down and developing forms that are involved in the workflow. Because you start with, oh, what do you think you need? And then you end with what you actually need. And what you should really start with is, what do you actually need? And then let them know if they actually need it or not, because of the integration.

Scott Goldschmidt:
Definitely a lesson learned and something that we actually have taken on to other clients and to other projects that we’ve taken on. Which in my experience has been so much more helpful in starting the workflow, in getting these things started. Because you can come to the client with a solution rather than saying, “All right. You tell us your problem and then tell us what you want. And then we’ll build to that.” And hope that everything that you included was everything that’s actually included for the integration.

Scott Goldschmidt:
On a more technical aspect, when you’re dealing with a process that’s 130 tasks or so, you need to have a lot of really good control measures in place. Like being able to reset tasks. Like resetting data on forms. In Integrify there are multiple ways for you to go back in the process as a developer when you’re going through unit testing. Placing milestones in between forms and in between tasks allow you to reset data, and go into forms and actually make the adjustments, rather than having them get pushed forward in the process without you being able to go back and change them.

Scott Goldschmidt:
So there were a lot of small learning experiences like that, that I probably don’t need to get into on this podcast. Another big thing was having a really good PM. Understanding how to manage client and consultant expectations and deliverables on a timely basis. And to be able to communicate all of those changes and updates on a regular basis is very important. Because when you have a project that’s this large and you said, “Okay, we’ll get it done in six months,” or, “In this many months,” you need to hold yourself accountable. Both parties need to hold themselves accountable to executing all of their deliverables in time. And when things slip or when there’s additional decisions that need to be made in a timely basis that will affect development, both parties need to be held accountable. And so, one of the big lessons learned is, make sure that when you’re choosing your PMs, to have a lot of confidence in them.

Roman Pendzich:
Yeah. And also the consultant, and more often, even more so the PM, needs to have the boldness to be able to push back and explain to the customer why the particular revision that the customer may have just offhandedly requested, radically changes the schedule. I had a colleague who referred to that as having the customer hand you a piano and want you to move it. And so you have to explain to them that this is not a simple task, the other interdependencies in the system that you’ve already specified make this new change much more difficult than it would appear on the surface.

Roman Pendzich:
So that can be an issue of communication, forthrightness, and just bringing that up just as soon as you recognize that this situation’s occurring, to bring that back to the customer. And also have management have your own back and back you up when you say that, yes, you can have this, but it’s going to push back the delivery date by some period. And there’s going to be additional expense.

Scott Goldschmidt:
Well, and I would add to that Marty, and I think NeoSystems in general, does a really good job at maintaining and setting those expectations upfront when we start these projects and we’re in our war room saying, “Okay. Well, this happens and then what?” To make it very clear that if we have changes that are outside of the documented requirements that we have, it may impact a build, right?

Scott Goldschmidt:
Some changes are easy. But if you have a hundred easy changes, it can have a much bigger effect. And you may have a client say, “Well, I thought everything was running fine.” It’s like, well, it was until all of these things ended up having a larger impact that we couldn’t foresee because it wasn’t one thing. Over-

Erin Keating:
Death by a thousand paper cuts.

Scott Goldschmidt:
Exactly, exactly.

Erin Keating:
I think all of our project managers listening are like, “Well, hallelujah, you’re finally knowing what we do,” right? But it is a unique skill set. And I’ve had to be a project manager before and I’ve been the representative for the client as well as the vendor. And it is a difficult position to be in. Because on one side you want to keep that client happy and you got to sound like you’re their big champion. But then when you go in house, you have to have enough expertise to know when your people are telling you what they know. You have to have trust that they’re telling you what they know. And then you’ve got to have that respect and modicum of, how shall I put it? The way in which you communicate with your client needs to be careful, deliberate, but also not get you into drowning by a thousand paper cuts. Because yes, salespeople love to go ahead and say, “Yep. We’ll get that right done for you. Yep. We’ll get that done for you too. Oh yeah. Nope. That’s should be an easy fix.” Right.

Marty Herbert:
Yeah. I live by the modicum of under promise and over deliver.

Erin Keating:
Yes. Measure twice, cut once. I feel like we’ve just gone through all the idioms in this entire… Is idiom even the right word. I don’t know, but. Awesome. Well, I know that this sounds like a crazy big… Again, the very first thing you said, Scott, was this enormous task list. 130, that sounds insane to me. Sometimes on these projects, when you all go through this, this is a question for you. If it starts out at 130 tasks, are you ever through this helping them get that down to 80? By process of elimination and helping them see how they’re doing it? Is that part of the work that you’re doing or no? You’re getting 130 and you’re helping them stay at 130.

Scott Goldschmidt:
No. Well it always starts with 80 and then it becomes 130. Or it starts with 20-

Erin Keating:
Right. Scope creep.

Scott Goldschmidt:
… and then there are a lot of permutations that happen like, “Oh. Yes. Yes.” It can be a very hard thing to manage within the projects, so.

Erin Keating:
Well, I always enjoy these conversations because I feel like I’m just going to jump on board, Marty. I’m going to give up my day job and come be a project manager, I guess maybe it sounds kind of fun. It sounds kind of cool. I’m kind of geeky like that though. I like to know how everything works. I don’t actually want to have to do all that work. I just like to see how it all works. Maybe I’ll just keep interviewing you guys and learn more about it, but.

Roman Pendzich:
Never turn a hobby into a job. That’s right.

Erin Keating:
That’s true. That’s true. I’m doing it right now, but. That’s true. So, well, any parting thoughts on big and difficult war stories? Or this particular project, some surprise learnings that maybe you got out of it. Or just surprises, doesn’t even have to be a learning that you got out of the project. Anything you’d like to leave our audience with?

Roman Pendzich:
I would say the relationship with the customer is key. I’ve been accused of being too honest with the customer. But I find it buys me leeway when I make a mistake or something unexpected comes up. Perhaps there’s an aspect of the system that no one really thought through fully. It’s more often a failure of imagination than a failure to perform. But sometimes you just get these, what if this happens? Well, you all look at it and you go, well, we never thought of that. So having that relationship with the customer helps get you past those moments. And the moments when you realize that maybe you’re not going to make the deadline when originally promised, for whatever reason.

Erin Keating:
Good advice. How about you Scott? Any surprises out of this or any parting words?

Scott Goldschmidt:
Yeah. I would just piggyback right off of that and say the relationship with the client is probably the number one most important aspect of any project. Because if they’re late on providing deliverables to us, we can work hard to make sure that we meet those deadlines. But just like Marty likes to say, under promise and over deliver. If if we over promise it can affect our relationship, not only with the people who we work with on a day to day basis, the subject matter experts, but when they have to report back to their leadership, it’s a bit of a different dynamic.

Scott Goldschmidt:
And I would also say personally on this project, it was a huge learning experience for me because it was where I really got my hands on Costpoint. I learned all about the backend and how the backend isn’t actually just like the front end. And I learned a new language. I learned a new computer language. I learned XML. Which can be a lot of fun in a very nerdy way. Well. Marty’s raising his eyebrows.

Erin Keating:
Were all nerds here, Scott. We’re all nerds here, don’t worry.

Roman Pendzich:
Can you spell XML?

Scott Goldschmidt:
Yeah.

Erin Keating:
That’s good. Well, that is exciting. That’s what I was thinking about earlier when I was saying you either get to learn a new industry. But in this point I hadn’t thought about it. But, yeah. You got to learn an entire new quote unquote language, an entire new program, which not only helps you be more efficient with the next customer that comes along and has that type of integration, but also personally and professionally it helps you. So that’s awesome. Yeah. Got to love that.

Erin Keating:
Marty, any parting thoughts from you?

Marty Herbert:
What I take away from it too is, really from a client side, you don’t want to be the ones that everybody’s talking about. So take the words of wisdom that we’re sharing now and the ways that you can prepare and the ways that you can avoid these same pitfalls. Because you don’t want to be in a situation where Roman’s standing over you and telling you exactly what you don’t want to hear and being very honest and upfront about it. And hey, you’re going to overrun the budget by 25,000 because of all these different changes.

Marty Herbert:
So know what you want and be willing to communicate and over communicate to your consultants too. Because that back and forth, again, it all comes back to that relationship. That back and forth and that communication really is what makes the project more successful, is making sure that you know what you want, when you need it and how you need it within the process flow.

Scott Goldschmidt:
Sorry, I was going to say, and to kind of continue off of that point, so, trust. A big issue from what Marty said. And trusting your consultants and trusting the vendor to provide exactly what you are looking for. And allowing them to work in an agile way, or in an agile mindset. You can probably have an entire new segment and discussion on what agile is and how we use that and new systems in the entire pie. But not getting bogged down with too many cooks in the kitchen and having several different, what do they call it, not stakeholders or groups or line of businesses involved in making all the decisions for this, for your workflow. Because you will learn eventually as you move forward in the project, how your workflow touches other workflows. And that’s when you can bring them in.

Scott Goldschmidt:
But in the beginning answer questions, develop. Answer questions, develop. It is the most efficient way to build a workflow. And in marketing, we can speak to that with experience. We had a client where we built 40-some workflows in, I think, three months. And they weren’t as large as project set up, but it was employee onboarding, employee offboarding, security requirements, NDAs, TAs. Hit multiple streamlines just by sitting down with the people who have their hands in the workflow and who work in it every day. Because those are the people who are most effected by the tool, are the people who are actually using it on a day to day basis. And they know the answers to all of the questions that we’ll have and that may be involved within the workflow. So definitely have a lot of trust and let the build of the workflow be iterative.

Erin Keating:
That is great advice. And again, this whole series has been so informative to me. And I hope it’s been informative to our audience. Because really what we’re trying to do is to help those out there considering process improvement, automation, managing the change they’re going through. We’re trying to, from the other perspective, prepare you for what those projects look like and prepare you for what you really might need to consider on your end as the client, what you want to have developed upfront.

Erin Keating:
Everyone’s always trying to say, “I don’t want to pay gazillion dollars to consultants and things like this.” Well, one of the ways you can avoid that is listening to these shows to hear a little bit more about how sausage is made, so to speak, so that you’re better prepared when you’re coming into the situation with your requirements, with all of your data in the right place, with having had the stakeholder conversations before you get there, and then be iterative.

Erin Keating:
I agree with you. There’s nothing better than being able to quickly and easily approach, break, figure it out, go back. Approach, break, figure out, go back. And most people actually, I would think, would be more engaged in that process because it’s exciting. It’s kind of interesting. You’re not just going, “Here’s my entire assignment. Come back in a few months and, oh, wait. I don’t like this bug.” And everything’s for naught. So no one wants to waste their time doing that, so.

Erin Keating:
We really appreciate you all being here. Thank you so much for participating in the conversation, Marty. I hope we get to have these folks or other folks from your team on for at least one or two more episodes to talk about some other war stories. But Scott and Roman, thank you so much for giving us your time today and Marty as always great to talk to you.

Marty Herbert:
Thank you.

Scott Goldschmidt:
Thank you.

Erin Keating:
Yeah, absolutely. Talk to you guys soon. Take care.

Scott Goldschmidt:
All right thanks Erin.

Erin Keating:
Thank you.

Erin Keating:
The NeoSystems difference. We specialize in serving organizations of all sizes.

Erin Keating:
In today’s fiercely competitive market, is your organization constantly searching for ways to gain the advantage over competitors? Smart organizations are paying more attention to their strategic back office operations. NeoSystems offers scalable back office services and solutions to improve your organization with a team of industry experts, industry leading information technology tools, and an advanced technical infrastructure. From software hosting and security solutions to managed accounting services, NeoSystems custom build solutions and services that are tailored to fit your organization’s needs. Check us out on the internet at NeoSystems C-O-R-P, dot com. That’s neosystemscorp.com.