Today Jeff was joined by Randy Syring. A deep dive into how to scope projects from a technical perspective ensued, but also how to map it back to the business needs.

Topics covered:
- Randy's transition from seminary to CEO
- Agile v Waterfall.
- Randy's 100-hour guarantee.
- using Zenhub and "mockup driven development"
- using MOSCOW to get priorities of deliverables
- Fixed Fee vs. Team based projects

Transcript:

Jeff  01:07

Hello there, thanks for listening. As always, this is Jeff really enjoyed this episode I've been trying to get for a while. And it's a real deep dive. You could say from the trenches of scoping, from the technical perspective, but the interesting thing is talking with Randy, see CEO of a dev shop in Kentucky. And as much as you want to get into some of the technical stuff, it really does trace back to the business requirements. And we get into some of the different ways we can flesh those things out Agile versus waterfall in ways that we can guarantee our customers that we're not trying to screw them. Because this is what I mean, I'm never trying to do that. And but sometimes it can seem like we're trying to do that by putting up guardrails or being conservative. So we got into that for a while. And we really took a nice deep dive. And we went into a use case too, which is really nice. Some people you know, are sometimes afraid to go down that that area, but we definitely went deep into it today. So give it a listen. You know, if you listen to it, if you scope products, if you buy products or services, it's definitely it's definitely a well worth watching. I think Randy really knows what he's talking about. And I was along for the ride. So enjoy. Thank you. All right, we're recording. So, Randy, thanks for joining. I appreciate it. Let me talk about my dog there for a minute and why we started Wait, but so why don't you tell me a little bit where yourself where you're located? And then we're gonna get into the topic of the day after that. Yeah, so

Randy Syring  03:05

my name is Randy Syring. I own a software development company called level 12. Our offices out of the Louisville, Kentucky area, but I'm, you know, at least half of our people are remote now. And even the people who are geographically close to us, most of us work out of the office. So we have clients that we have, you know, in the local area, but we also have clients, you know, around the US. I've been doing software development since roughly late 2004. I started out as a freelancer. Just trying to put myself through seminary actually. Oh, wow. Okay. That's it. Yeah, that's how I came to Louisville area. Yeah, round 2009 to get a guy from my church telling me, hey, you really aren't cut out to be a pastor. You probably don't, you probably don't want to do that. You know, go go be faithful in a local church. But don't go be a pastor. And so that was good advice. He don't lie. And I listened. He had some good things to say. And I was finishing up my seminary degree and I never really intended at that time, I had a part time guy working for me doing software development helping me. And I never really intended to run a business I was I never saw myself as a business owner. But I've just been trying to be faithful with what the Lord has put in front of me. And so to the more we had the company, I kind of merged with a partner in 2009. We did some networking and Small Business Computer consulting, as well as software development. At that time. I actually thought the software development stuff was going to die. I had a real hard time finding new work. And then we had a couple of strategic relationships develop. And so I never really went over and helped him with that side of the business. And then in 2013, we realized that software development was really, you know, the better the better business. And so we actually sold off the other part of it. And in 2000, from since 2014, we've focused exclusively on software development. So I've been, I've personally have been focused on software development, building software development for small and medium businesses. You know, throughout that time, although honestly, we have some large enterprises, one of our clients is a fortune 500. You know, another one is, you know, hundreds of millions, not billions. But we do have a prospect in the queue. For an aerospace company, that's, you know, I think, a couple billion in revenue. So we certainly, you know, we certainly span the gamut. In terms of the customer type, the industry and also the size. It's interesting that you can do that, you know, normally you'd segment try to segment but what I found is that, so many different businesses have the ability to have a good ROI on software development. Not all of them, obviously, and you have to be able to afford it because it can get, you know, it can get expensive. The key is really just to make sure that the problem you're solving, you know, has more return on investment than what you're going to spend, you know, to do the software project. And so that's key, you know, a lot of people don't think about it that way. So we try to educate them in that respect, but you know, a lot of them think you're just trying to sell them. My perspective is really like our entire sales philosophy is designed around discoverability. So what is the problem that the customer has, or the client that the prospect has, we try to get, we try to understand the business value of it, because not all of our clients are really willing to adopt that mindset. But we know how quickly software can get complex, we know how quickly the bills can add up. And so we're trying to do the due diligence on the front side to make sure that we're trying to get a sense of scope and in how that impacts the client's p&l to make sure that, you know, we're getting into a project that there really is a good, good. Yeah, yeah. Go ahead.

Jeff  07:09

No, no, absolutely. Because, you know, I, you see this so often, where if people don't have, you know, if they say, Hey, we want to go build some stuff, and then like, six weeks into the project, and be like, oh, we need to go this. Now we've got to do this now. And you and I know, if the project fails, not getting brought back in at all, is a bad, it's a bad mark on, you know, your reference ability. And so, and I'm not gonna say like, we're doing the Challenger sale or anything like that. But when when customer when requirements start going a little sideways, you're like, Well, how is this impacting? Or you pull up the problem statement from the first week? And you're just basically like, you stated, we're building this to be increased XY and Z. I don't know. And then you get a couch. I don't know your business as well as you can you tell them that that is like, Oh, okay. Yeah, this net, before we go down that path a little bit more. So I believe and apologies if I'm, if I'm wrong here, you focus a lot on Python projects. Is there more than that? Are you sort of software agnostic? Or is that sort of a niche that you're you're working on?

Randy Syring  08:18

Yeah. So I usually don't go into a conversation talking about the fact that I use Python, because I'm usually talking to people that just a that might not even know what that is, and be they just don't care. Okay. I'm really talking, you know, I solve business problems with custom software. The reality is behind the scenes on the back end, I almost exclusively use Python. And I do that primarily, because I find that the greatest constraint in the software development process is the availability of quality software development. 100%, right. And so because I'm because I'm optimizing for how much my developers can get done, how productive they are, it means that I pick tools that allow us to get a lot of value out of the developer. And so I actually gear my entire process project management, the way we run our sprints, the fact that we use Python on the back end, the fact that we use react on the front end, all of those decisions are made to try to reduce the amount of cruft a developer has to deal with to put business value together in the software. And

Jeff  09:26

I can see that a lot with your small to medium sized customers. I might just what I've bumped into on that I got two things here and purely conversational. When we're dealing with enterprise customers. It seems like when you eventually transition the technology to them. Like we're not even doing rails stuff anymore, because people like we cannot we can't find Rails developers, right. And so if it's not Java or dotnet, most of the enterprises don't want us to build a technology to Python we love, but I'm just laughing because all the Python developers that we have, they're like, no, if we're not doing machine learning stuff now, we don't want to, you know, they don't want to do regular web development stuff. But that's, that's more cultural and where our developers are located and things like that. So they're like, why am I going to be doing like a, you know, a portal when I can go be cranking out? AI and machine learning and stuff like that? So but no, I know, Python is an amazing thing. And there's some, some, there's some really big companies here in Boston that, that they've sucked up all the Python developers in the area. But that's great. And I like how you approach it for the business value and stuff like that. On that note, I wanted to start transitioning into sort of the topic of the day, and it's perfect, because we can paint myself as the sales guy, and I know you do sales and for your company, or help out or you get brought into the process. But as a as a technical resource, there's always a little bit of back and forth, right? Because it's, you know, I would think, for anybody that's listening to this podcast, they're not of the sales type, where they're just trying to use pressure and push people down. It's usually they've got some people that are in a pinch, and they're looking for a quote, like, that's, you know, if you're ever trying to get into the why, if somebody like me, it's, I'm getting asked, like, Hey, I'm in a pinch, I need some people. You know, we're always getting asked cost, right. But I know that's hard. A, I'd love to hear your approach. And then we can get into methodologies and ways to structure projects and things like that. But you know, what's the scenario usually is like, Hey, Randy, I just got off the phone with these people. You they get it, they get this big project starting, you know, hopefully in like two weeks, so they were wondering if we could go into a quick scope, and then you know, get going, don't stop me if this sounds familiar, but now, I come from more large enterprise type projects, where my team is basically say, unless we do eight weeks of discovery, and come up with the software design, and you know, all API structures, and you know, project plan and scope matrix and things like that. We don't get involved. I'd like to hear a where you are in that sort of spectrum and then be how do you solve this, you know, annoying sales guy who's just asking me for a quote?

Randy Syring  12:27

Yeah. So let me say that I think it starts, it starts a step back, maybe even with just the general philosophy of software development. And so, you know, if the listeners are familiar, you know, there's a general debate going on out there about the waterfall method versus the Agile method. Yeah, yeah. So I mean, the difficulty that I have is agile has been commercialized. There was a talk last year, I can't remember the name of the guy right now off the top of my head, a Martin Fowler, who talked about the state of agile, and he basically said, it's become an industrial complex absolutely child has. And so when you hear agile now, it's like you need a team of consultants to do Agile. If you go back to simply the Agile Manifesto, you go back to the principles that they laid out in the Agile Manifesto. Essentially, what they're describing is software as a process that, by its very nature resists a tight scope and tight deadline. This does. And, you know, in business, people hear this and they often they they want to immediately eject from the conversation, because they're, they feel like they're getting sold a bunch of BS. Yep. But the reality is that I would encourage any business person who has to engage either their own software developers or is looking to hire I would, I would say, look, please spend a couple of days reading good resources are not about the industrial complex, agile. What about the Agile Manifesto, and the reasons why it was created the underlying concepts, why they believe that this is the approach to software development. And at its heart, I think what it's boiled down to, to me is you have to recognize that software is fundamentally a discovery process. When we sit down with everybody in the room. And they you know, we get, we start to do scoping. There are things that the software developers will run into, as they start to build this process that nobody in the room could have known they would run into. Because there is hidden complexity. There are things that by their very nature will not be discovered, until you get to actually doing the work I've run into the problem. A great analogy I've heard is it's kind of like trying to build a road. If you're building a road and you'd have to dig through, you know, a hill you know, interstates they often dig through Hills because they don't want much, you know, too much pitch in the road. So you dig through the hill, you think you're in an area where you're mostly going to hit dirt? Well, if you get halfway through and you hit solid rock, and you realize that the dirt, you know, the dirt is not 10 feet thick, like you thought it was, it's actually only two feet thick. And oh, yeah, you did drill some, you know, you drilled some pilot holes, but it turns out, you just didn't drill them in the right place. Well, nobody sitting there knows that you're gonna hit that rock, except the people who actually start the project and then get halfway through and hit the rock. So I'm, you know, thinking about this, you know, in the backend in the in the business context, what this really means is that, as a software developer, I'm sitting there essentially trying to convince people a, I can't really give you fixed cost, fixed estimate, if you want to fix the scope, because I know, I don't know, nobody's built this, like, I'm a software development professional. And I have really good software developers on my team. But what I know is that nobody has actually gone down this particular road and built it for you. Because if they had, you'd have what you need, right? So every custom development project, even if it's very similar in nature to other things I've done, it's going to be, it's going to be new, if it wasn't that way, then there would be a vendor solution available, if what you're out there already, that you would just be able to buy it off the shelf theoretically, or you'd be able to buy it from the competitor, but they're not gonna want to sell it for you to you because they want No, no,

Jeff  16:36

I gotta do you believe in the value of sort of going in there and doing like a four week discovery process? And I'm for discovery, I, you know, I do feel that you do you have to couch it, right? In my experience, unless you do a really long thing. And by the way, on the whole agile versus waterfall, like, if you're building enterprise software for people, you still need to do a little upfront work, right? Because everything my teams have come in and fixed over the last couple of years have been science projects that got successful, and they didn't plan. You know, the metaphor that I always use to for the situation that you're talking about is easy, because my dad was a plumber. And I would say you would never have the plumbers, the carpenters, the electricians, and the painters all show up to the asphalt lot on day one, and just say, get after it, you guys are pros, you'll know what to do, right? That you need a little bit of a plan, and kind of go from there. But I have found that, you know, if you go in even for like three weeks, you know the size of the team, right? You're like, you know what, this is gonna be a problem, you always need a project manager and some type of technical lead, back end front end QA, like, it's not gonna get smaller than that. I think I've said that 10 times this week. But we can find out how long it's gonna take if there's gonna be spikes and resources. But you're right, like, you might uncover just so much technical debt, or missing requirements or stuff like that. So I'd love to hear you sort of know, I've given my take your next steps in that in how you like to go about doing it to ensure sort of happy clients successful projects and things.

Randy Syring  18:23

Yeah. So Eisenhower said, in preparing for battle, I've always found that plans are useless. But planning is indispensable. So I think it's important to recognize a lot of companies want you to come in and do all that work. So you can say, Okay, this is when the software is going to be built, this is when it's going to be done. And this is how much it's gonna cost. And I think the better approach for business person to take is to say, what I'm really doing in that process is evaluating whether or not I actually want to work with this company. Exactly. Do they?

Jeff  18:54

Were the questions that they asked, I hear that constantly now, especially now that everything's going a little bit more commoditized. Like, I love the questions that you asked, you know, so yeah. So you

Randy Syring  19:07

know, you're good. That's exactly right. So my, my, my suggestion to a business person trying to evaluate either the development of software project finding, you know, consultant or whatever, is, essentially do they come out of the backside of that client's initial product or that that the consultants do they come out of the backside of that process, feeling a lot more confident in their understanding of the project and what they actually need? And do they or do they feel like they just got sold for two weeks, you know, like, there should be a tangible difference between I feel really confident that the project's in a better place. And I feel like I don't know anything more than I did that two weeks ago. I just feel like these guys have billed me for two weeks you know, like Yeah, so So I think that's a good you know, that's a good one have a good indicators for the for the You know, potential client or the prospect business person trying to figure all this stuff out, especially if they've not done it before? Yeah, in terms of our process, it really depends on the size of the client and the project. So I actually don't know you described, you know, kind of your team size, your base team size. For our projects, we don't necessarily need something that they, they might not actually need that many developers, we have true full stack developers. And so for some projects, we might actually just put two full stack people in the project, we might realize that most of what they need is basic UI, we have kind of basic UI libraries that we use a lot of our stuff, so that we don't have to involve UI UX people. And so we can usually get a really good 80% solution. That's great for business, you know, a general business

Jeff  20:51

processes like and I'm not terrible, because my company does react, but like, I don't know, what the like the Twitter Bootstrap version of that, you know, react has, but like, Is this good enough? Right? You know,

Randy Syring  21:01

that's exactly what it is. Yeah, it Bootstrap? That's exactly it. Right? And so, and yes, by the way, they do have react, bundling for that. So, so, yeah, so we absolutely try to, you know, shave out some of those things that for nine out of 10, you know, business projects, you just, I personally don't find all of that needed. And then if it is needed, because we're not putting together on site teams, we're actually owning the project, I can just bring in those resources from my team as needed, like, I might go, oh, so this is going to have some custom DevOps stuff, I don't need a dev ops person on the team, right, I just need to bring in that resource from the other part of my, you know, from the other part of my company, schedule them to work to two weeks on the project to get the skeleton in place. And then my full stack devs can take over, you know, actually

Jeff  21:48

deploys. And that's nice and white. I like that. That's good. Yeah.

Randy Syring  21:52

So getting back to the kind of the fundamental, how do you approach the how do you approach kind of the project management discovery process? Well, I've had some clients. So first of all, we offer 100 hour guarantee. So you can essentially work with us for 100 hours. And if you feel like I've sold you something that I'm not, you can ask me for money back, if you ask me for all of it back. If you asked me, for all of it back, you can't keep anything, you can ask for a 50% refund. And I'll let you keep whatever we put together. And hopefully, we'll part is friends just realizing that for whatever reason, it wasn't a good match. So first of all, I have some clients that have relatively smaller projects, or projects that they're really confident they can get ROI in there. But they don't even they don't want to go through the process of a really big scope, like they just want to get moving. And so I've had clients like that, that just say, let's go ahead and start moving. You know, a lot of times those clients have got personal referrals from people we've worked with. So there's a lot of trust initially. And they just say, look, I trust you guys, let's get started. Let's do the discovery process as part of the

Jeff  22:58

work and just get going. Yeah, yeah, like so it's,

Randy Syring  23:01

I'm doing that discovery towards, you know, the, the, the initial delivery, whatever that initial delivery is. And, and so we just kind of get off to the races, as soon as we can put them in our schedule. The complete other end of the spectrum, for me, would be a more enterprise prospect, you know, we have one of those in the aerospace company I mentioned. So what that looks like is we actually, we had a number of video calls with them initially to just even try to understand where they were at is this a good match, we had a couple of tech discovery calls to look at the software, they had some, they had an Access database, essentially, that solution that they had outgrown. They had a they had a guy in house build that. And, you know, it worked, he got them what they needed, but there was obviously there's bugs the guy had moved on, they weren't able to really edit it anymore. And so all that to say they, they were able to show us but it was a really complex piece of software, it sat at the intersection of a lot of the different departments in their business, there was really a lot of there was a lot of business levels, software side, there was a lot of business complexity in what this application was doing for them. So we actually even we flew down to their location so that we could go on site and meet them that was before they paid us anything like we just recognized, this is a good long term prospect. If they can actually use what what we do this is worth investing in the relationship. So we flew down there and spent the day with them and just again, going through the software, talking to the different people in the different departments and what that piece of software meant to them. Because that's, you know, that's really important to get the different types of users in the discussion. They engaged us for a $5,000 You know, engineering phase, which is you know, relatively nothing, but it was just something to demonstrate that yes, they were you know, they had you know, they had a Little bit of skin in the game, we probably could have asked for more or maybe even should have asked for more I had the sense after walking out of the on site meeting with them that that the engineering phase was going to grow usually engineering phase for us, we can usually do it in a week. And I'll talk a little bit more about what that is. But again, just kind of finishing the story. So we went away, we I think we had an additional, maybe three or four conference calls, we actually stood their software up, walked through it, put demo data in, it really got a sense of what it was doing. And then we actually broke down the project into epics and issues in GitHub, put estimates on all those, we use an overlay on GitHub called Zen hub, which allows us to get epics and estimates since GitHub doesn't have that functionality. And then we transferred all of that to an Excel spreadsheet kind of broken down by, you know, major module and functionality in the module did rough estimates on that, you know, had the developers estimate how long they think it would take, I usually take a developer estimate, we have kind of a I'm not sure there's, there's a name for it. But we have like, bands of development effort, you know, so we think he's gonna take one day, we think it's gonna take two to three days, we think it's gonna take a week, basically a week and a half in it, the gaps get bigger, the, you know, the bigger the component gets. And so I usually I take the developer estimate, and I bump it up one level,

Jeff  26:22

exactly. 20%. Yep. And then,

Randy Syring  26:25

and then I add, I usually also add at that early of a stage, I add 20%. So in, you know, in formal project management, there's certain paddings that you add to account for known unknowns and unknown unknowns. So in that project, you know, we worked on it for a month, and I felt like every time we asked a question, we overturned another bit of complexity. And so I actually added 12% For known unknowns and another 12%, for unknown unknown. So I added 25%, not only did I bump up the estimate to that and add another 25%, just because I had this gut feeling that it was going to get bigger. And so

Jeff  27:04

it's positive to see the context. Is your goal while doing this to get to a fixed fee cost? Or is it just to get to a level of effort before you go into attend materials?

Randy Syring  27:13

Yeah, so my goal is time and materials level of effort for time materials. So essentially, the client had told me or the prospect had told me, you know, they thought that the project would be about 75 grand, and I just

Jeff  27:25

knew, just based on everything he told me, I'm like, That's not 75.

Randy Syring  27:29

Yeah, I just. And so what I realized I had prepped them a little bit for that I had told them, you know, but from their perspective, and this makes a lot of sense. So let me finish my story. And then I'll come back a little bit, because it's really important. But so essentially, I ultimately got to a number that was somewhere between 202 150,000 For just the first of four components for that piece of software. Now, it is the most complex, you know, we'll probably be able to do the other three for double that if they decide they want to move forward. But that's ultimately where I tried to get them. You know, I said, it's roughly three to four months, if I put two developers full time on it, if you only want one, because you want to spread out the cost, then, you know, it's going to double that. And we ended up doing, you know, so they had a number of different assets we did, I think maybe 12 UI mock up so that they could see a little bit of what it was going to look like. Yeah, I think that's really helpful for the prospect to see a wireframe mock up. We like to say we do a mock up driven development as much as possible. I bet. You'd be amazed at how often a business person if you put a mock up, down how much more detail and engagement you'll get. Is

Jeff  28:37

that at the Envision level, or is that different level? Using tools for that, or

Randy Syring  28:43

we use a tool called mock ups.com. But it's spelt differently. It's like,

Jeff  28:48

Q so it's all wet. It might be like balsamic or something like that. Like yeah,

Randy Syring  28:51

so we don't use balsamic because not everybody that we that does development uses a Mac. So we like a web based tool that everybody can show his boss talk,

Jeff  28:59

Michael, I didn't realize that okay. Well,

Randy Syring  29:01

I think it I think it is because I've looked at them before and lamented that.

Jeff  29:05

Yeah, it's a good for what you're talking about us. Let's just give you some quick context, right? Because that sticker logo up in the corner. So it just tells you all the world all the difference in the world when you're trying to just conceptualize and get people to understand. Absolutely.

Randy Syring  29:20

So I knew coming into this, the client would be a little bit or the prospect would be a little bit shell shocked by that. But what I put all those assets together so they could see, look, we've done our due diligence, and this was my pitch to them. I realize this is three times more expensive than what you than what you planned. I could have theoretically, I could have made this project come in at around 150,000. That's what my developer estimates would have added up to, but I have your best interests in mind. It's not going to do that every time we do a project this big. We find hidden complexity reason this change

Jeff  29:55

ordering them to death and they're hating you because they have a budget set aside now that you're blocked through it. Yep,

Randy Syring  30:00

yep. And I could have assumed there PMS would do the right thing and add the margins. And I didn't, I showed them look and add the margins for you. This is the project, this is the amount you should budget. And I have, you know, 80% Confidence ish that will be in this budget, because I've added all the padding. So that prospect was not planning on spending that much money. But they appreciated all of the effort that we put in, they understood because I put in all that effort, they understood where the costs were, yeah, they did come back to us and ask us, Hey, can we start cutting stuff out and we said, look, basically, you already have an application that you're trying to duplicate functionality, there's not a lot of room for us to cut things, we really think this is what it's going to take to replace this software for you. And we actually think is to your disadvantage to try to cut things we we did try to cut some things, they gave us a list and amounted to 15 grand, we actually said, Look, you're cutting out some of the things that you said, were the things to why to rebuild it. So we're just going to the 15 Grand will give you a credit. Yeah. And because we don't actually think it's to your advantage to try to, you know, nitpick that amount of money,

Jeff  31:07

you know, and again, and then like, go ask the users how they feel about losing money. Right,

Randy Syring  31:11

exactly. So yeah, we built a lot of rapport with that prospect doing that, and they're currently, you know, they're now you know, having to sell their leadership team on on, you know, on getting the money, but we've given them all the ammunition to do that. So let me come back to the expectation that we had to fight that 75,000. Because I think a great, you know, a great instance of where the business user was really trying to do his due diligence, he's a smart guy, he's close to the top of the organization. He, you know, he runs a relatively large department, he's used to enterprise sales and vendor engagement, he's like, this is not somebody who's uninformed. All point to me was, look, we had a, we had basically, particularly a non software development, pick up access, and build, you know, build this software, in access for us in six months, you know, we think that you're the professionals, you're the professional software builders, you should be able to do it in half of that. And, you know, I put my, you know, I put my numbers on your time, and this, you know, I came up with roughly 75,000. And I feel like I'm even having some padding in there. Well, I get why that makes sense to him. But the analogy that we responded with was, okay, you know, trying to put in the manufacturing context, listen, this is what you this is what you ultimately have said to me, what you've said to me is, we've got this guy who's who's generally mechanically inclined, but he's never built go karts before we gave him the raw materials. And in six months, he put together a go kart that runs pretty well, it can get us out there, we're running about 2025 miles an hour. And considering we had to walk before this, this is fantastic. Now being professional go kart builders, we believe that you can get us a car built in, you know, in roughly half the time that has been and what we said is okay, but look, you're not asking us to build a go kart, we're actually automobile builders, and we're custom automobile builders, at that we don't have an assembly line, everything is put together, you know, by hand, because you have a very custom process that needs a very specific automobile, and none of the off the shelf or nothing in the dealer, parking lots gonna work for you. Otherwise, if it did, you would go out and use that and you you'd spend a lot less money. So you can't buy the $50,000 You know, Toyota SUV, I need to build you, you know, essentially a custom automobile. And we're going to be at the, you know, two and a half, or two and a quarter $100,000 Mark and a $250,000 mark. So, that resonated really well with him, no good, I was gone. And, you know, it went with everybody, you know, some business people are just really locked in this, they, they've always done business a certain way, they don't want to listen to you, as a professional, they want to listen to you as a vendor who's trying to, you know, Bs them and draw them into spending three times more than they need to. And so what they're going to end up with, in this case, if that was the type of person I'd work with, you know, they would end up working with potentially some overseas developers, really bad project management process, and they would invest their 750,000 and then they did you know, invest twice that because they still wouldn't be able to deliver for that and after investing 150,000 They'd probably pull the plug realizing that that type of development shop just cannot deliver for them because he complex and they don't have the content. Yeah,

Jeff  34:44

and those those shops are good for certain things, but unless unless they're used to doing some really custom boutique type work, which just you know, caveat aside, we do that but like, you know, that's that's a value prop that we have In that not too many other agencies base where we are do that they're like half of our rates. And they'll come in and say like, oh, well, we'll just go in and start doing it for whatever dollars an hour, like what my daughter would make doing it, I think and, you know, and and it never winds up well, right? Like, I admit, yeah, totally, like, if you need a quick web portal just cranked out in like 15 days, go for it, like, you know, but if you need something where there's some thoughtfulness going on, and some requirements elicitation and understanding of users, you know, in more things aren't tightly SPECT and defined, it doesn't really work that well. I got it. Well, that was awesome. I really appreciate you kind of telling a story, because we all know stories help sort of prove those things out. And is that more of is that a snare that happens more than often? Or was this particular one or so your,

Randy Syring  36:02

your bigger your enterprise clients, like you've said, your enterprise prospects, they really have their a lot of times they're, they're more rigid, even if they can do what you're saying they might have purchasing requirements that require them to get fixed costs. The other thing I can do there is when I have somebody who's kind of in the middle, which so at the end of the day, I just simply won't do business with somebody who says, I need fixed time fixed costs fixed scope, I say, hey, look, I'm sorry, this doesn't work. Yeah, you can get somebody who will say they're going to do that for you. And you will recognize why 70% of IT projects fail. Fail to meet their guidelines. Because

Jeff  36:43

yeah, I know, I hear you I got I just, it's so funny. I feel like I've had these conversations all I was gonna say all week, and then it's like, all last 20 years. And it's funny, because I think where I've kind of wound up now is, it sounds a little bit like you're doing please know if I'm wrong, which is, we think it's in this area, right? Like, let's just say for your example, we think it's like 250 300 for this component, it would take a team size that looks like this, and probably this long. But we're gonna find some stuff out along the way. And we will let you know if it alters that. But I usually say we can't sign up for this fixed price. This is basically your monthly team cost, they are your adjunct product team. It's just like they work for you, you're gonna get in scrims and or Sprint's and talk things out. And you would think with those types of honest approaches, and this is how it works. And this is how software works. It doesn't go over as well, every time it gets down to like, well, let me see your rates. And I'm just like, Oh, my God, I just don't see I'm like, my head is in my hands right.

Randy Syring  37:51

In from their side, it's understandable. You know, a lot of those people, they do have fixed budgets, they're, you know, they're trying to take fees from certain things, or they have some kind of, you know, you know, procurement process where they know, if it goes over $100,000, then it's gonna blow up on them, and they can't even get, you know, they might internally they know, they're only gonna get get somebody's attention for three months or whatever. So, you know, some of those things, we're just dealing with people, sometimes called an organizational policies, they can't even get out if they want to. So one of the other things that I've been willing to do when I'm when I'm kind of stuck like that, where I think the person I'm working with, I can actually work well, like they will adopt that process. I'm stuck in kind of, you know, a paperwork, jam where I've still got to make it look

Jeff  38:37

like a fixed behave. Yeah, exactly. That and then you've got all the Asterix and Weasley lawyer words and your SW and everything like that. But like, Yeah,

Randy Syring  38:48

I actually don't do it that way. I there's there's a there's a project management process called Moscow,

Jeff  38:56

and oh, yeah, yeah, absolutely. I, yes. I had not used this term. But when somebody explained to me recently, I want to say like, within the last month, I was like, oh, yeah, that's absolutely that's what yeah. Tell them tell people what it is. So, so I don't have to.

Randy Syring  39:11

Yeah, so Moscow was essentially must have should haves could haves and won't have South, and it's a way to break down the priorities of a project into, you know, priority of deliverable. And one of the things that we have found able to do is if we have a prospect or a client, who really has to have a fixed cost project, like they have to have

Jeff  39:33

just the way their organization and their procurement process works. I think probably I don't know if it's the same one, but I had a large AV company near your where you are, as well, too. And it was like, listen, that's just like, you can't get anything through procurement unless it's fixed costs. And I'm like, Oh, boy. So how are we you know, yeah.

Randy Syring  39:50

So what we have done is usually they don't have to have fixed costs, they have to have an upper limit. So usually the contract has to have an upper limit. So by the time I'm I'm working with somebody like this. Normally, I've earned their trust they have, they understand why software has to be built the way that I've proposed. And essentially, what I've done is I've said, look, here's what I think the project is going to cost, but we're going to do Moscow, we're gonna do Moscow. And I'm only going to guarantee the must haves, and the must haves can only account at maximum for roughly 50% of the upper limit. And so what you and I are agreeing with is, with the recognition that if that upper limit that if we get close to that upper limit, and we can't get more money, because a lot of times these bigger organizations, they have to have a fixed upper limit, but then they can if they can show cause then they can. But you know, so it, but I tell them, Look, the reality is that contractually, if we get close to that upper limit, the only thing that I'm on the hook for is the must haves. And this gives me flexibility. And you know, by that time, well, they might think you're trying to screw me, you know, you're kind of, but usually by that time I've laid out the process, I've provided them with external resources outside level 12 That will testify to how we work, right what we do.

Jeff  41:11

Sorry,

Randy Syring  41:13

by all that time, usually, sorry, you need to go back,

Jeff  41:15

you know what, I'm gonna No, no, no, I'm gonna stop the video for a quick second, just so just so we can keep talking.

Randy Syring  41:24

Okay, so, you know, so when I'm when I'm working with a prospect like that, or client, usually trust is developed. And contractually, I'm saying, Look, I will give you the upper limit amount, but then I'm not going to be on the hook for fixed cost deliverables beyond whatever these Moscow's have. Because again, they're not going to say, Well, you can't have any, you know, fix, you have to give me some type of guarantee about what I'm going to get contractually insure, I understand that. So look, I'm willing to meet you halfway, I'm leaving enough margin in here that should give us room for, you know, unknown complexity. But even then, I usually when I've used that successfully, I really only need it once, once I do it, and people start working with us, they just don't need it again, now I have I have had one fortune 500. And that, essentially, what we would do is we would just put, you know, she would give me a really rough estimate of what she thought the project wanted. But part of her difficulty was she often didn't have the time to really go through a project, you know, valuation phase like discovery phase, she would just give me rough ballpark, like sometimes even rough meeting. And I would come and basically say, okay, my gut is this is going to be x, and then I would triple it, and then I would upper limit on it, and we do a really rough sculpt. And the reality is that we were really just getting a pool of money. Because Because our contracts, even though they had a fixed upper limit, they were still materials, she knew we weren't going to try to screw or like we're not, we're not going to bill you for things that we don't do. It's all time the materials, you know, every time or that I give them has notes, what did we do that day. And so if they want the validation, it's there, but honestly, by about, you know, three months in, none of that stuff mattered anymore, they loved us, we got more done for them, then they're 27 person. All of it today, dare you know, that was devoted to their department?

Jeff  43:22

Well, that's a subject for maybe our next podcast. But you know, what I'm hearing here, which is great, it's really pulling in sort of all the true values that I sort of, espouse are the core values that I espouse, which is, you're building up trust, you have empathy for them. And and you eventually get to show that your team can do the work. And you know, and so I tell my team, sometimes when these, these hoops, guard rails start coming up as like, just get through it, all we have to do is be who we are. And this will all work out. And everybody gets all, you know, risk adverse and things like that. And it's like, what do we have to worry about? If we just do what we say we're gonna go do, right, and you have enough protection in there to make sure if the unforeseen comes up?

Randy Syring  44:09

Yeah. And I think the big picture here is if I find somebody who buys into the way that software has to be built, ie agile, and they have contractual organizational constraints that require a contract that doesn't look very agile, are flexible to work with them in in contractual terms, as long as they are willing to abide by our actual agile delivery process. IE, we're, this is going to be an iterative process. We're going to strive for deliverables every two weeks, you're going to be very involved in this. And if the scope needs to change, we don't care. So you mentioned change requests to us. None of that is ever contractual. It's almost always just send me an email or we're going to have a disability. Right, from my perspective, a change request in the software development lifecycle is exactly what you want. What it means is you've delivered some software, or you've delivered something for the user to look at and go, Oh, you know what, that's not exactly what I wanted. And instead of that, making that a contractual issue, where now I'm concerned about development costs, and now we've got to figure out how much it's going to cost. It says, go through all that rigmarole and that adversarial relationship, I can now create a synergistic relationship where when the software needs to change because of legitimate insights that the user now has, that is a plus for my business, too, because I want the software to fit you like a glove. And I'm not concerned about who's going to pay for that addition. And that that whole dynamic of the relationship, that's what ultimately gets software built really well. It's not that as, as the client, you can put your screws into me in terms of this was the cost and this was the scope, and why isn't it done yet? You know, you if you have a relationship like that with a software vendor, you've already lost.

Jeff  46:10

And I like, oh, go ahead. Yeah, yeah. No, I was just gonna say that I, I hate doing change requests. The only time I try and do them, if we're doing an agile project is, you know, you know, obviously, if you're doing a fixed fee, fixed scope, and then part of that fixed scope changes, you need to kind of document that because, you know, things can happen once you say that, but I typically don't like to do change requests, unlike its unless it's suddenly like, Hey, we've found something new, or we're getting asked to do this other piece of functionality. And let's say it's like an additional 500 Sprint points. And you say, like, well, we can take 500 off the current board and replace it with this. No, no, no, we still need all that. And it was like, Okay, well, then, then maybe we need to add another developer to to this to get that done. And they're like, Okay, I'm like, so Are you Okay, with that cost? And I'm like, Sure. And that's really the only time I like to do change orders, if like you're adding on to the team or extending out the time that they're going to work on it. Sure. Otherwise, your raises should be you're agreeing on these things in an iterative process, you're doing your, your sprint previews and your sprint planning, and deciding what to work on and, you know, maybe moving things around and pushing it out.

Randy Syring  47:24

Yep, that's right. And, and really, the change request, whether it's adversarial or not completely depends on how the contract was written and what the nature of the contract is. Because, you know, as you described it, it doesn't have to be adversarial. But sometimes it is because as soon as you deviate you as soon as soon as the user or you know, the business person asked me for a change, I have to go look at the contract and say, well, was that actually in the scope? And Right,

Jeff  47:47

right? What's the point took that example of, you know, it's this procurement thing, and they make you have these like, must have, and you're gonna go to build over the must have, and then somebody said, oh, you know what, we're not going to do that module anymore. And it's in like, there's a chance you might not get paid if you don't deliver that. And that's the only time I ever like to get into that, as we discussed before. We don't like to get into those types of tracks, just because it's a little non agile and things like that. So it's kind of like, okay, well, if we're gonna sign up for that, then we're going to, unfortunately have to be a little bit more diligent about scope management and change order processes, which is just, you know, for me, just not my favorite part of the business. So I agree with you completely. So that's awesome. Listen, I mean, we could probably talk for hours, and I were both I know, busy. And I'm trying to keep these podcasts under under an hour. Because I don't think people like hearing my voice that much. But that's me, I can't edit these things are like a straight record and go, but let me let me do this. What are what's the current sort of big thing that you're working on with your team as in, you know, we can kind of get caught up in the day to day and cranking stuff out and everything. But if are you able to pause and say like, this is what we need to do next year. And this is an initiative that you're working on in the background? Yeah, so we

Randy Syring  49:03

usually do a SWOT analysis, strengths, weaknesses, opportunities, threats at the end of the year. And we've actually got that coming around. Next week, actually, since all of our developers are since most of our team, much of our team is remote. We have on site, just work week, and the next week, everybody's going to come in and fly and so we'll we'll be getting to some of that stuff. I already kind of know what's on the agenda. It really depends on the team I'm working with. You know, from a company wide perspective, I don't think there's any single one agenda item, the development team we stay, we stay really busy. Productivity is really important to me. So you know, cutting out fluff and really just focusing on getting the work done is important. One of the things that that has done to us though is it's it's made it more difficult for us to get internal work done to get internal open source

Jeff  49:53

your fuel efficient for your customers. If you're too efficient for your customers exactly right

Randy Syring  49:59

Yeah, exactly. So we have some internal projects that really could use better documentation, you know, we've got issue lists that could get done. And the thing that currently keeps us from doing that is just, you know, really being focused on customer work all the time. So we've got some discussions on the table about, you know, maybe we need to pull, you know, a week out once a quarter for internal processes and that type of thing. So I think that's the biggest thing. There are other, you know, more technical oriented items on our list, like, we really want to get our even though we know we're using React, you know, you got to get reactive Webpack. And you got to figure out all the other libraries you're going to use with React. And we really would like to get kind of a standard front end,

Jeff  50:40

put together, which is what again, winds up being more efficient for your customers, and you can have a faster solution to them, like, because you're not always customizing everything. So

Randy Syring  50:48

exactly. So that's the development side of things, the more of operations and then, you know, on my mind is always business development, we're in a very crowded market. To be honest with you, we've just never done well at Business Development. I'm an engineer by trade, I don't particularly like anything to do with software development. And so that's still, you know, top of focus for us to figure out how to fill the top of our funnel with people who buy in, because you know, our model, it sounds like it's a little bit different than yours. We don't typically hand off our projects, we want to build them, we want to own them, we want to be there for the foreseeable future, doesn't mean that a project can't end, you know, we sometimes write

Jeff  51:29

was a we do so customers usually ask, I'd say 80% of the time, hey, do you have a team that could do maintenance and support on this, but, you know, they usually do that, as the end of the project. And the beginning of the project is like, we're gonna transition this internally and everything like that. And then they're like, Oh, we don't have the people to be able to consume this. But like, there, but there are, you know, there are some projects where we've worked on and we've got a, we forked the code, there's one, you know, there's one or two support types of people, as in support engineers that can, you know, maintain and report the bugs. And, you know, again, you get into some complexities there, like, who works on that is that the people working on the new stuff? Do they work on the old branch and fold it into the new ones? And, you know, so those are all a little bit? You know, client specific, so, sure, yep. Yeah, that's great. So listen, I super appreciate it. Have a I love to get in on this. So I'm going to actually stop the recording a second, then I'll turn the video back on. We can chat for an extra quick second. But where can people find I'm going to link up to your LinkedIn in the website for your company is what

Randy Syring  52:38

it is WWW dot leveltwelve.io.

Jeff  52:43

Awesome. Awesome. Don't miss it. Stop on the recording. And Randy, thanks so much. And I'm sure we'll put some agenda items us to go over in the future.

Randy Syring  52:51

Okay, sounds good. Thanks, Jeff.