Interview with Chad Modad about Selecting a New Vendor

Chad Modad: My name is Chad Modad. I work for Entrance, which is a software consulting company in the Houston area.

Trevor Lohrbeer: OK. And so what I wanted to ask you today is about some recent decision you’ve made–could be an old decision, too, actually. Pick a decision and tell me about a decision you’ve made.

Chad: I’ve made quite a few. Director level, I have a handful of them, so this could be a staffing decision, it could be a technology choice decision, a process decision.

Trevor: Let’s go with technology choice since that’s a common one that people have.

Chad: OK. So we recently–recently as in about three or four months ago–made a change from one type of professional services automation tool to a different one.

And that decision was fairly complex because it touched on a lot of different things. Does it support our process today? Will it support our processes tomorrow? What kind of technology change is it going to be?

We were already using one that was software-as-a-service. And so we wanted to keep that model, but was the user interface going to change so drastically? I’ve got 30-plus users, and do I have to go train them all? What’s the impact going to be when I move projects from–I have history of tracking projects in one. Now I have to move that to a different one.

And so, that was one decision, I thought it was fairly complex. And we took about–uh, let’s see when did I start? Started about March–so we took from March until … May is when we made the final decision.

And then, when we made the final decision on which one and then presented the decision to the owner of the company. And he went back and said, “Did you do all your homework?” And we said “yes,” and he goes, “I have four others I need you to look at.” (Laughs.)

Trevor: OK.

Chad: So we went through that process, so we did that, and then we narrowed it down to two. One was a little more comfortable for everybody because it worked on the same technology stack that we as a consulting company work with, and the pricing was going to be better.

And then we went ahead and we said, “OK, here’s what we’re going to do to mitigate our risks in this area. We’ll take out a trial license and we’ll pay their professional services company, or their professional services department, to implement for us as if we were a real client.”

And so we did that and we used it for a month, and we hated it. And then we threw it out the window, and, um, but we went with this other one in the meantime, while we had the professional services implementing in one product, in Product A, we were using a trial version of Product B, and they extended the trial for us for the three-month period.

So we were using both simultaneously, and then when Product A fell apart, we went with Product B, and we then implemented in record time, and we were off and running.

So that’s kind of the short story of how it worked.

Trevor: OK. So I’ve got a couple questions around that. One, it sounds like there was something that caused that–what triggered that decision? Right? Because you were going along with the product. So this is almost, sort of like, I could, you could keep using the existing product or you decide to change to a new product. So what was that inflection point that caused you to change?

Chad: That’s a good question. So I think when it comes to software and business and business processes, it’s always a question of, I’ve got a business process. Is the process that I’m using today the one I want to use? And the answer was “no.”

We weren’t managing our resources correctly as a services company. I couldn’t tell you beyond a week from a given day where a particular resource, what project they were going to go work on. So I couldn’t then tell you how many people I need to hire or let go, right? If sales came back and said, “We’re going to start a project,” I couldn’t tell you when we could actually start it.

So that’s one side, so the process had to go. So if my processes have to go, now you look at the software. Is the software going to allow me to change it–the process–and what kind of flexibility is there?

And in this particular case, this product was not going to allow me to do it. It was really better suited for an IT infrastructure company that had tickets coming in, working installation projects rather than software development projects. And so we couldn’t do that.

And then in terms of things I wanted it to go do, things like resource management and project tracking, we went back to the company, this Product A, where we were before, and we said, “OK, this is what I’ve got to go do. How do I do it?” And they completely missed the ball. They were like, “Oh, well, it sounds like you’re missing these three things. Would you like to talk to our professional services department and have them implement these three things” that are not related to what I’d asked for?

And so, all of those things put together, I said OK, I need to make a different decision about software, and I need to pick something else.

Trevor: Got it, got it. And then once you did that, you then were looking at like a list of different factors that went into that decision. So tell me a little more about that process. Did you document all your factors? What was that process? You were talking about, what was the impact on your processes? Obviously it sounds like cost was a factor in there. How did you decide?

Chad: So, what I did was, we put together a kind of a matrix, an evaluation matrix. I said, “OK, these are the things that are important to us.” Some were functionality, some were performance based. Some had to do with reporting. I need to be able to answer these 10 questions. If I can’t answer these 10 questions easily, then the software’s not usable.

And so we looked at it from that perspective of, how do I manage my day to day as a professional services organization, and is the system going to support that information all the way back to the time when I create a project to the time that I finish that project out and go into maintenance?

And so once we had this big matrix, and we listed all of the vendors that we were going to go look at and we looked at their marketing material, and we were able to quickly see yes or no for some things. Some things we needed a little more information, so we phoned them. When we had a pretty good list, we narrowed down from—there’s a lot of professional services automation software out there—when we narrowed it down from a dozen to three or four, then we started scheduling demos.

And the important part for me was that I was not going to be the only one that made the decision, for a variety of reasons. One, it puts a big bull’s-eye on my back. And then two, I’m not the actual user of the system. I’m the user of the reporting side of the system, but the day to day, that’s project managers, that’s individual consultants, and so they needed to be part of that decision-making process.

So they got to see all the demos, and they got to comment, and they got to say this was important to them, and this was not important to them. And that’s why the process took so long, because I feel like I knew the right answer. I knew the right answer early on, but that wasn’t going to get me what I really wanted, which was a high level of user adoption.

Trevor: So did you, with your initial list, did you go and do demos of that entire list?

Chad: Not the dozen, no.

Trevor: Not the dozen. OK, so you did filter down first. And did you fill out your entire grid for that entire list or did you use some questions as gateway questions?

Chad: We used some questions as gateway questions.

Trevor: OK.

Chad: So if you can’t answer the 10 questions that I want, right, then probably this isn’t the right kind of software.

And they’re not hard questions. They’re like, When is the scheduled delivery of this project? What is the actual delivery of this project? What were the hours required? What were the estimated hours? Just real basic questions that you would expect out of any kind of project management/professional services software.

And surprisingly not a lot of them met that initial list. So then once we filtered it down to the four, then we put some priorities on the other ones. So, this is high priority, this is low priority; this is nice-to-have, this is got-to-have. And then that helped inform the rest of the decisions.

And when we came down to the two, it was comparing apples to oranges. How do we even compare these two things? One was Microsoft based, and it wasn’t multi-tenant, so basically they hosted our instance for us. And then they had it so that you could stay stagnant and never change your software. Or they could upgrade you. Versus one is a multi-tenant, and it’s based on the LAMP technologies, not Microsoft. One had a really great user interface, one had a crappy user interface.

Trevor: Got it. So how did you all wind up, what was the key factor in that decision then at the end of the day that drove the apples-to-oranges comparison? How did you ultimately wind up making that?

Chad: So it was the combination of the team. What I did was I had them pull up our existing solution. And so I pulled four project managers into a room for two hours. Had them pull up our existing solution. Had them pull up choice A; had them pull up choice B.

And then we went through a list of capable functionality that we’re going to use, basically workflows. “I want you to create me a project in each one of these, and the project has to have these characteristics: It’s a time and materials project, with this rate, we’re using these resources.” And so they sat down and they did it.

And within first 45 minutes of this two-hour meeting, they had already made a selection.

Trevor: Got it. It became very clear.

Chad: It became very clear.

Trevor: And it’s interesting to me that you’re bringing up the old software for two reasons. I didn’t think about this, but when you’re doing that type of selection process, it’s nice to compare functionality to the software you have already to kind of see, am I losing features? At the end of the day, your old software should also be one of the options in some cases.

Chad: That’s exactly right. And so there was a switching cost, which is hard to factor. You can easily say, “Well, I’m going to need this much training. I’m going to need this. But then there’s productivity loss. And when you’re moving to a new software package, ’cause it’s not familiar, the way that you created a project isn’t the same. The way that you track time isn’t the same. And so, how do you calculate that productivity loss? It’s a guess.

Trevor: So at the end of the day, was this a successful decision?

Chad: It was a successful decision. We’re off and running in the new software. We moved over at the halfway point of the year. It made sense, you close out second quarter, start the third quarter, and we haven’t looked back since. Now there are, we do have our share of, man, this really sucks. Right? The old system did this better, but the new system does this better.

So I think the most important thing for me about the entire process was, because I had the thought leaders in the company, the project managers on board, and these were the ones that were going to be heavy users of the system, ’cause they’re using all the capabilities, not just time tracking, then when a problem arises, they’re like, “Yeah, but this was the best solution we had at the time.” Instead of, “Chad chose that and screw that guy.”

Trevor: So because of the collaborative process, and also because what you’re doing, it sounds like you’re weighting toward the heaviest use cases, as far as the functionality. So rather than taking all stakeholders’ opinions equally, you say, “OK, you guys are the heavy-use users, we’re going to weight your input more than others.

Chad: Yeah. I’ve got 30 people entering time, but I’ve five got people that are managing projects.

Trevor: So those five people are the ones that matter. OK, great. Is there anything else I should have asked that I should’ve asked?

Chad: No, those were good questions.