Kyle: Okay. Greg, on this episode of the podcast, we're going to talk about, you know, as you're planning projects and you're kind of gathering requirements, how much do you think you should be setting all the requirements up front? Kind of like a, as a waterfall method versus evolving over time. Kind of like in an agile method. I might be misusing those terms, but that's kind of how I think of them is, you know, should he be gathering everything up front and then building or do you think you should be constantly tweaking and evolving?
Greg: Yeah, so good question. I mean, I think there they're definitely arguments from both sides. I think you'll probably have a different opinion than me. I think for me, I would prefer that everything is set up up front before we start working. That's not always super realistic. So I would say generally the kind of method of communication that we communicate to our customers is this-- the specificity of requirements and detailed requirements should match the expectations around the timeline.
And what I mean by that is if you're the kind of person and you're the kind of company where it's like, hey, we have everything documented, here is everything we need. If you just deliver this we will be super happy. Then I'm totally fine with that. And then let's say like, hey, this is going to take a month or this is going to take two weeks and we will hit that deadline. If you're of the opinion of like, hey, like we don't really know like this is like a good start but we try to need to see it and play with it. That's also totally fine but then we can't be super stringent on deadlines and the reason for that, and this is top of mind for me because I'm dealing with this with a client right now where we have scoped out a project, put in all the requirements, everyone reviewed it on their side and like, hey, this is exactly what we need. This is great and cool. Like no changes needed and we're like, great, this will take three weeks. Then one weekend we kind of show like a preview and they were like what about this or what about that field or like it also needs to do this and we get all these other requirements that weren't there initially.
So we like add those in and then after we two we do the same thing where we show, okay cool, here's what we do and we get a whole another slew of requirements and so then we have to have a conversation with them. We're like this is not going to come out on time or like these other things are going to get de-prioritized. So we probably could have done a better job communicating the timeline piece, but I think it puts ops people in a really tough position when requirements and scope expands. But the timelines do not expand.
Kyle: I was just reading Hacker News last night and I saved this quote into a doc. It was, be conservative in what will be delivered and liberal when it will be delivered. So I really liked that idea of like not committing to so much cause this is a challenge that I have personally where you know, customer says, Oh can you add this in? And I'm like, yeah for sure we're already on track, let's just do it. But I think that it's reasonable to push back and say we scoped this out and gave you an estimate. Now you're making changes that's really gonna push this out a significant amount other than just like adding a field or something. So my impression, where I'm going to disagree with you is that I don't think most customers, and the reason that I think that they work with us, you may have a different customer base or how they work with you, but they're working with us because they don't know what to do.
They know that they have a problem, we're making recommendations and we're guiding them on what needs to be done. But to an extent, I need to see how it'll work before I commit to how it will like. I need to be able to play with it. As you alluded to, like imagine you were trying to describe Salesforce to a person who's never used it. You've got to say, well, what do you want your stages to be? They're like, I'm not quite sure. Like we haven't ever had stages before. And if you're building a CPQ implementation, there's just so much that goes into it that you can't know on day one, which is why they're contracting with us. Maybe I'm in the wrong, I'm definitely down to hash that idea.
Kyle: Yeah, oftentimes we'll do that. Yeah, we'll, we'll begin work because, we do something different where all of our customers are on time and materials basis. We don't do fixed bid projects, so that changes things. Most big consulting firms will do very fixed bid projects. I have a friend who worked at a big one and I was asking, and he was a project manager and I asked him, you know, when a customer says, hey, can we make this little change? How do you handle that? And he said, I forward it to the sales team. I was like, you don't even talk to the customer about it. He goes, nope, we just forward it to the sales team. They deal with it. If they want a change order the sales rep will loop me in and confirm those things. But that's outside of scope and that feels like a poor experience from a customer perspective.
Like I want the ability to be dynamic in a lot of situations and I don't like the idea of the only way we can do this as another change order. So that's why we've taken that tack with our business. And it's not a way to pitch my own business, but just show that I think I would want to consume consulting services in that way more than I would want to outline everything. I'm a big person of like jump in and start to build it before I sit down and spend five hours scoping it out. So that's probably my personal bias.
Greg: Yeah, I think that's fair.
Kyle: Yeah. So like every good answer, it depends. It's a fair question and we try to give our customers a range. We'll say, you know you want this done, it's going to take about 10 to 20 hours. You may make a hundred changes and we're not good. I mean we do document all of the changes but you know, it does happen at times where customers come back and they're like, this project has taken three months. We thought it was a month-long project and you know, our response is it was, but you've changed it a hundred times. And so that can be a poor experience from the customer if we don't do a good job of setting expectations as well. But that's part of our pitch to them is that you don't know everything today and I don't want to spend two months scoping it out.
I want to start building and start getting traction. Like in my mind, let's get to value as quickly as possible. And for them, if they start to see progress, that feels more valuable than if we're just sitting in meetings talking about what do you want this picklist value to be before we can start building. Well, do you handle it differently on your end?
Greg: No, I think it's pretty similar. Like we'll all say what I'll give them like an idea of what I think it's going to cost them. It could be 10 grand, it could be 20 grand. But I think what I don't do and what I don't really want to have to do is every time there's a change to be like, okay, that's going to be like another hour.
Kyle: That's to change order.
Greg: Yeah. Like I don't want to deal with change orders and so like the downside of that is if I say it's going to be 10 grand and then they get an invoice for 20, they're pissed.
Part of that is, you know, and even if you set the expectations up front, I'm like as the exchange it's going to take more time, it's going to cost more money. Sometimes startup people have a short term memory for warnings around bad news.
Kyle: Yeah. One thing that I'd heard someone that a person I refer to that worked at a bigger consulting company he told me that oftentimes he'll take some of these little ticky tacky changes and just do them, but he would note them so that when they have to go back to the customer and say, look, we're overrunning, we're going to overrun budget, and they pushed back. He can say, look at the 30 things we did for free. It's reasonable for us to start charging for this change that you want. Like we've already done a lot of things pro bono.
Like we let it slide, we can't let it slide anymore. And it's easier to make that case I think to the customer when you can actually show them what you've done versus just saying I have the abstractly, we'll remember those things we tried to do a couple of months ago, but he said he was very diligent about documenting anything.
Greg: Both, I mean we're pretty upfront with like here is what dev hours cost, here is what project management hours costs, here's what like analyst hours cost and then we will just, we'll give an hour estimate and then give some estimate around like, hey, like this is going to cost 20 hours, 10 of it's going to be dev hours, 10 will be like analyst hours.
Kyle: Yeah. So you can give them kind of a target dollar amount, but it could flex left or right. Depending on if they go easy on the dev stuff or if they go heavy on the dev stuff or something.
Greg: Yeah. Correct.
Greg: I've been doing this long enough to where I can generally scope, like pretty accurately with very little information. So this project that we just rolled out, I think I'm going to end up billing like 24 grand. I told him it would cost 25 grand and I told them that like after like half an hour.
Kyle: Yeah. Most of the time you can get a sense of what they're looking to accomplish and you can take the experience that you've had and all the projects that you've done and say, this is going to be kind of a window and you're going to get pretty close.
Greg: Yeah. And, also like every startup thinks they're unique, but they're really not. Like everyone's trying to do the same thing. So that helps a lot too. And I'm like, hey, cool, you want to do this project? You're like forgetting about these five things. Oh yeah, that's a good idea, we should totally do that too.
The scoping piece is fine. I'm not like, I feel like I haven't found a great way to handle the constant changing. And I think this like a topic we'll discuss on another episode, but I think a lot of times there's this idea around flexibility and like, hey, you're a startup. Like you're moving fast, you gotta be flexible. But I think with a lot of people that, I don't know about your experience with a lot of people that we work with, that mandate around flexibility, flexibility really just covers up poor planning.
Kyle: Yeah. They don't want to be disciplined. I do agree with that. It is true because I'm not a super disciplined person and I really enjoy that. I call it flexibility, but the reality is I don't want to follow a process. I want to do it how I want to do it. Which is not a solid way of operating. So I will agree that that's a bias that I have. The solution is you need a project manager who's hyper disciplined and will follow a process and you need to be able to be comfortable with that. Cause I think you see this a lot with startups where they say this is how we're going to do it going forward until they're like, we're not gonna do that. Right. When a deal comes in at the 11th hour, right before the quarter closes, every sales rep or every sales leader says we'll never cave again. And then they'll cave again.
It's just hard to be disciplined when you have these competing priorities and deadlines and pressure coming from all different directions to always be consistent. So you almost need someone who's got that mentality to be your project manager almost.
Greg: Yeah. I think like one thing that I say a lot to our team is like to be good at consulting, you either need to be hyper-creative or hyper-organized.
Kyle: That's good. I like that a lot. So you'd said that you'll oftentimes give a customer an estimate after about 30 minutes of talking to them about the project, which I think that we're not dissimilar in how we do it as well.
Greg: It depends on how much I trust the people I'm working with. So like most of the time, we do not because most of the reason that we're getting called in most of a lot of the time is because like there are issues around operations. So I will do it if it's somebody that I've worked with a lot and that person and I have an understanding around like expectations.
Kyle: Yeah, because one thing that's nice about giving an estimate is you can say, look, this will cost 20 grand, but then at the end of the project, if you're efficient and you come in and say, look, it only costs us 15 grand, you should be happy about that. Like, hey customer, we estimated 20 but we're only charging you 15 not because we over scoped it. We just became very efficient for you. And so that gives you credibility for when things run over a little bit. So there's gotta be that balance of, you know, I think it's easy for the customer to be frustrated because things have gone over but they're never like high five you because it came in under.
Greg: Yeah, exactly.
Kyle: So yeah, I think that scoping things out ahead of time can be super valuable to give the customer an expectation for what it's going to take to get it done. But in my mind, I really pushed back on one customer say I need a fixed bid and I can't exceed this because I just know that I've either got to spend a month scoping this out and charge you a bunch of money for our time to do that. Or we need to have flexibility because what you want today is going to be different than what you want tomorrow.
Greg: Totally. And I will actually like, I will say this and this will probably get some push back for this, but most of the time when people are saying they must have a fixed cost thing, it is because that is what their finance team is demanding. And to me, it says something about you if your own finance team doesn't trust you to like spend money correctly.
Kyle: That's it. Yeah, that's right. If they don't trust you, then that's a big concern. Right?
Greg: Yeah. Cause like I know like the companies I know where someone's like, dude, my CFO needs a fixed bid. I'm thinking like, yeah I would too because I don't think you know what you're doing.
Kyle: Fair. I don't want to throw any of our customers under the bus.
Kyle: Think of, if you're coming in to do a CPQ implementation, you're working with a person who's never done a CPQ implementation, so they have no context for what it really takes. They may have kind of hope for it, but they don't really know. CFOs certainly doesn't know. So when you come in and guide them, they're paying you to guide them to an extent. Right?
Kyle: They're paying that insurance to be tucked in at night to know that you're going to cover their ass and make sure that the product is delivered on time and on target.