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 Paolo Wittan. Hope I got that right. And it is, what should I include in my deliverables with my consulting services? So, I mean, it depends on what kind of consultant, what your consulting business is. I mean, is it financial? Is it technology? Is it photography? Is it architecture? I mean, who knows? It could be blueprints. It could be a lookbook. I have no idea. Depends on what you do. So to answer the question in general, though, I want to call out a couple of terms here that are important. So if you're offering a consulting service, what you're selling, if it's real consulting, what you're selling is advice. People come to consult with you. And that, you know, if you're not an English speaker, you might not know. That means I need to have a consultation. I need to talk with you about a problem that I'm having or a decision that I need to make. I'm the client and I want to hire a consultant to advise me about this decision that I need to make. I need to take some action and I don't know which action to take. So I might go to a consultant who's an expert in that field to point me in the right direction based on my unique situation. So another way to look at it is the best practices, general rule of thumb advice that exists in the industry are not specific enough for my situation because the risk seems too high. I want specific advice from someone who I trust as an expert. So I'm going to consult with an expert. So consulting is basically getting paid to answer questions. Questions are not, I mean, you could call that a deliverable, but it's not like, you know, an 8 by 10 glossy. It's not like a code repo. You know, it's not something that's more tangible like that. Somebody asks you for advice, you give them advice. That said, sometimes in a consulting arrangement, there are gray areas where, you know, I have to get specific to give you examples. But as someone who was an expert at mobile web development, which I would count myself as, then I would say some deliverables that I've created in the past would be things like a system architecture. So I get called in because client has some, my client has some outside development firms that are building APIs and another one's building front end stuff. And they're not happy for a variety of reasons and they feel like they need a real mobile web expert. So they call me. So I come in. One of the things I deliver might be, here's an architecture for the API that's going to be more friendly on the mobile side because we can control the size of data getting sent over the 3G connection. Or what's another deliverable? Another deliverable would be like a migration plan. So someone, you know, I've worked with the team, consulted with the team, not built it, but consulted with the team to create for them to create a new application, let's say. Now there's this old application. Well, how are we going to get the data from the old application and the new application? I would probably write up a timeline, a document with a timeline to have them go through. You know, here's the path to go through that will get the data from the old system and the new system. Maybe there's, you know, there are all sorts of details can happen with something like that. So you could consider it a deliverable because it's like a report or a plan, but it's me giving them specific advice. It's like a medium for me to give them specific advice. What are some other things? They're always, they're usually not something I promise in advance. It's usually something that crops up. They ask a question and they say, well, how should we secure this? How should we secure this endpoint? We need to be kind of public, but we don't want people to be able to steal it. All right. So, and I don't have an easy answer. I might have to go do some research and create a proof of concept and say, here's a proof of concept. You can't use this in your shipping code. It won't work. It might not even be running code. It might be like just a pseudocode or something like that. But I can, okay, here's what I would do. Let's have a meeting with the dev team. They can kind of validate that it does make sense. Everybody can agree. Everybody's nodding. Okay, great. Now that's the plan. Now run with it. So you can call all these things deliverables and I could go on if I could probably come up with a dozen more. These kind of random one-off things where I had to create something that seems like a deliverable, but really it was just a vehicle for me to get my advice across. So what you should include in your deliverables, if I was going to answer, you know, this is a general question. If I was going to give you a general answer, I would include as deliverables things that are required.

To communicate the advice in the most effective way. So whatever the thing is that you want to communicate, you do whatever the deliverables need to do that, to successfully do that, then that would be the deliverables you should include. Sometimes you can know these in advance because if you're, say somebody came to me for a strategy workshop. They've got this project that's imminent. It's still, it's not really, it's just getting into the planning phases, very high level, you know, all the high level people are involved. Maybe it's the board of directors, the managing director or CEO, and they're like, okay, we really know we need to tackle mobile next year because we're getting killed by Bank of America or whatever. Then okay, so I know that what I'm going to do is I'm going to do some discovery. I'm going to have to interview a bunch of people. I'm going to have to perhaps even talk to some of their clients or their members or their partners. So I know that I have to do, I'm going to have to do that so I can put it in as a deliverable, you know, like 25 interviews and blah, blah, blah, blah. And then I know that I'm going to have some findings and what am I going to, I'm going to deliver the findings either as in a meeting off a slide deck or I'm going to deliver them in a report form. Those are usually my two go-to choices. And based on the situation, I'd probably pick one advance and say, yeah, and then I'll deliver the findings in a report to your board on a date of your choice or location of your choice. So I know I'm going to have to do it. So that's, you could think of it as a deliverable, but the important piece is that you're transferring your knowledge to them so that they can make a bunch of what they believe to be very critical decisions for their business. So it's consulting, but it does have these artifacts that, you know, would be considered deliverables. Okay, so don't focus on deliverables too much. You'll probably have to have them in there. If there are obvious ones, include them in the proposal. It makes it feel beefier because people do like to hear about deliverables, but really focus on the results and the outcomes that you're going to be delivering to them. That's the real deliverable, positive ROI. That's the real deliverable. Okay, hopefully that helped. I hope I didn't just confuse the issue. I'm Jonathan Stark, and you can, if you have a question for me, you can hashtag AskJonathan on YouTube, Twitter, or LinkedIn, and we'll add it to the queue and get to it as soon as we can. See ya. Hey, Jonathan again. The next time someone asks for your hourly rate, I want you to stop what you're doing and go to valuepricingbootcamp.com to sign up for my free value pricing email course. That URL again is valuepricingbootcamp.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. That URL again is jonathanstark.com. Hope to see you there.