Ditching Hourly

Hello and welcome to Ditching Hourly. I'm Jonathan Stark. Today I've got an audio excerpt from an answer I provided on my YouTube channel. You can check it out at thejonathanstarkshow.com and it'll redirect you to YouTube if you're into watching videos. Otherwise, you can just listen to the audio here on the podcast. Enjoy. Hey, Jonathan here. I've got a question from Ali Ramatula. Man, I'm sure I messed that up, sorry. And the question is, what are the major events on your timeline with the client from initial sales call to delivery? For example, discovery strategy sessions, UX design meetings, progress reports, updates. Also, how do you go about budgeting the time for a project? This is hard to answer. It's really, it differs greatly depending on the nature of the engagement. So for something like, you know, I'm going to just go in and do, just do a sort of roadmap where I do an in-depth discovery. I compile my findings and create a report with recommendations in it. I mean, it doesn't really take that long. Maybe a few hours across a couple of weeks, you know, like might have to schedule a few meetings, meet with different people. Maybe I have to travel to a location. I'm assuming this question must be around longer projects. And so if we imagine that it's a long project where it's going to start off with some discovery like that, and then it's going to move into maybe some implementation where, okay, we've come up with these recommendations and now me, you know, I'm going to implement, you know, for me it would have been like creating a design and code repo and maybe a staging environment and testing and doing weekly design reviews and those sorts of things. It's funny. I don't think of it as, I guess there's some major events. So, but it's really different from project to project. So usually what it would look like is the initial discovery phase and then there'll be some sort of status meetings, probably weekly. And just to make sure that we're touching base. I think client communication is critical, constantly keeping people involved because I don't want any surprises at the end. I want to make sure we're on track all the way through. And in my initial proposal, in the sales interview and in the proposal, I'm going to have established some metrics that we can look at while we're working to make sure we're on the right track. So then I'm going to want to catch up with people on a regular basis to sort of confirm with everyone that yes, we're hitting the sort of numbers that we're expecting at the particular stage. So yeah, so there's gonna be a lot of communication, probably some sort of daily update in a project management system, at least daily, and then probably a short weekly status review, maybe 15, 20 minutes. And with me, there would be phases where the initial phase would be like a lot of exploratory stuff, maybe some research, maybe picking some frameworks, kind of deciding which is which. We might have to bring on a few contractors or there might be some training upfront. And then it would move into a phase where actually building, there'd be a QA process established. So that's a new phase where we've kind of got all of our environments set up, and then we're into a repetitive routine of cranking out, you know, like in sprints, we're cranking out features or whatever. And then it gets to a phase where testing becomes pretty serious, pretty intense, probably start to get beta testers in there, whether clients or internal users. And then at a certain point, there's a launch. And then after that, there's always surprises. So that would continue, you know, to iterate to make sure that the ultimate goal is achieved, or at least the piece of it that I'm responsible for. And then there'd be, you know, for a software project, I'd have some period of time where it was like, I would give a bug-free guarantee where anything that cropped up, I would just fix it. Honestly, I never put a time limit on that, but, you know, it usually petered out after a month at the most. There also might be a phase toward the end there where I'm doing handoff to their internal team. Like, here's the code base. Here's where all the important pieces are. This other stuff is all boilerplate. You never have to look in those directories. So when it comes to... So, you know, that's a software project. It would be different for other things, but those are the big pieces. And when it comes to budgeting time for a project, as a solo operator, I would only... I don't think I ever had a maximum of two projects like that happening at the same time. If I'm actually doing implementation, in other words, I'm writing code or I'm writing CSS or HTML or JavaScript or whatever, or PHP or FileMaker, whatever it was. If I was actually building stuff, I could only do one at a time and do a really good job. Maybe I'd have...

two at a time with one of them is ramping down and one of them is ramping up. I don't remember ever doing two big ones at the same time, but I still would have other things going on that were revenue generating, and especially after I stopped doing implementation. But let's just say you still do implementation. You can have other projects going on where you're not doing implementation. You're just doing like the roadmap piece, the strategy, or the UX, or the initial design phase, or you're offering oversight for a project that someone else is implementing. So you're not actually doing the work. Maybe you're reviewing pull requests, or maybe you're sitting in on design reviews, or maybe you just go to the status meeting to make sure that things are on track and that the business goals are being met by the development team and the development team of the design team understands the business goals and that you're sort of facilitating communication between those two parties. So you can have a bunch of those going on at the same time. I've had as many as three or four of those at the same time once I started doing less and less implementation and outsourcing that to other people or having the client outsource it to other people. Then you could just focus. I could just focus on the high value things and you could do lots of them at the same time. And they pay really well, so you don't need to have that many. And it becomes, it's not even, you don't even have to think about your time commitment. It's like very low compared to doing implementation. This is why I say implementation is low profit because it brings in big checks, but it also costs you a ton of time. So I'll just close on this idea. If you are doing implementation work and you want to move into more high profit realms of engagement like strategy, design, oversight, advisory retainers, that kind of thing. You're not like coding. You're not like doing the labor part. What you want to do with whatever implementation work you're doing now, you want to try to get it down to not full-time work. You want to try and do like maybe, it depends on, let's say you work 40 hours a week. You want to get your implementation stuff, those projects down to like 20 hours a week. So you've got 10 or 20 hours left over for you to be working on your business and be designing and selling these other more profitable engagements. Because if you're, you know, usually if you're on the clock and you're doing implementation, the client wants it done fast because A, they want the thing done so that they can start selling it or using it. Two, they want to get their employees, you know, their employees are collaborating with you on the project. They want to get that over with so their employees can get back to their normal jobs and be focused 100% on their normal jobs. And three, if you're charging by the hour, the longer it takes, the more money it's going to cost them. So they want to jam it all in as quickly as possible and there's a lot of pressure on you to get things done quickly. So it's hard to kind of say, okay, well, you know, we're doing 20 hours a week for you maximum and, you know, this other time you're going to be working on your business to build new things that are non-implementation. So from a budgeting time standpoint, if you can limit your billable hours work to 20 hours a week, that'll give you enough time and energy left over to try and ditch hourly, disconnect time for money, sell your smarts and not your labor, your head, not your hands, and try and make that transition. But if you're just slammed all week with billable client work, you're never going to get out of that, never going to get off that hamster wheel. All right, hopefully that helps. I'm not sure. It felt like a very specific answer to a general question. Anyway, so follow up in the comments if I didn't do a good job and I'll take another whack at it. Anyway, that's it for now. I'm Jonathan Stark. If you have a question, just hashtag AskJonathan on YouTube, Twitter, or LinkedIn, and I'll get to it as soon as I can. See ya. Would you like to learn how to get paid what you're worth? How about selling your expertise and not your labor? We work through all of this together in the pricing seminar. Pre-registration starts soon, and you can sign up to be the first to know when early bird pricing is announced at ThePricingSeminar.com. That URL again is ThePricingSeminar.com. Hope to see you there. Hey, Jonathan again. Do you have questions about how to improve your business? Things like value pricing your work instead of billing for your time, or positioning yourself as the go-to person in your space, or maybe productizing your services so you never have to have another awkward sales call or spend hours writing another custom proposal? Book a one-on-one coaching call with me and get answers to these questions and others in the time it takes you to get ready for work in the morning. Best of all, you're covered by my 100% satisfaction guarantee. If at the end of the call you don't feel like it was worth it, just say the word and I'll refund your purchase in full. To book your one-on-one coaching call, go to JonathanStark.com slash call, C-A-L-L. That URL again is JonathanStark.com slash

Hope to see you there.