Show Notes

01:47 - Context For Discussion
05:13 - Getting That Last Check
08:03 - When Things Aren’t Working Out…
  • Business Value
11:26 - Pricing Features (Billing)
18:20 - “Offboarding”: The Handoff Phase/Transitioning
  • Client Mailing List
  • Screencasts/Video Tutorials 
    • Transcripts
27:30 - Parting Ways on a Good Note
30:44 - Asking For Referrals, Gaining Introductions
37:59 - Horror Stories? Uncertainty Sucks
  • Working With Startups
45:47 - “Offboarding” Cont’d
Picks

Transcript

 

[This episode is sponsored by Hire.com. Hire.com offers a new freelancing and contracting offering that they want you to know about. Hire.com is offering a new freelancing and contracting offering. They have multiple companies that will provide you with contract opportunities. They cover all the tracking, reporting and billing for you, they handle all the collections and prefund your paycheck, they offer legal and accounting and tax support, and they’ll give you a $2,000 when you’ve been on a contract for 90 days. But with this link, they’ll double it to $4,000 instead. Go sign up at Hire.com/freelancersshow]

[This episode is sponsored by Elixir Sips. Elixir Sips is a screencast series that will take you from Elixir newbie to experienced practitioner. If you’re interested in learning Elixir but don’t know where to start, then Elixir Sips is perfect for you. In two short screencasts each week between five and fifteen minutes, Elixir Sips currently consists of over 16 hours of densely packed videos and more than a hundred episodes, and there are more every week. Elixir Sips is brought to you by Josh Adams, expert Rubyist and CTO of a software development consultancy, Isotope Eleven. Elixir Sips, learn Elixir with a pro. Find out more at elixirsips.com]

CHUCK:

Hey everybody and welcome to episode 163 of the Freelancers’ Show. This week on our panel we have Jonathan Stark.

JONATHAN:

Hello.

CHUCK:

Eric Davis.

ERIC:

Hey.

CHUCK:

Reuven Lerner.

REUVEN:

Hey everyone.

CHUCK:

I'm Charles Max Wood from DevChat.tv. And this week we’re going to be talking about how to wind down a project. Reuven, you recommended this. You want to give us some contents or start us off?

REUVEN:

Well, so the contents is every time I have a new fantastic client, and I come home and I gush about it to my wife, she says, ‘well yes, but remember the nature of the business you're in is that every project, even the best, is going to eventually end, and you have to remember that’. And strangely enough, she’s right. Not strangely enough that she’s my wife and she’s right, but I mean it’s true. It’s something that I often have to keep in mind when I’m working on projects.

And so here and there I've had projects where, for whatever reasons, sometimes I fire the client; sometimes they just weren’t interested in doing more work with me; sometimes the schedule or the budgets didn’t match. And I definitely had some experience lately with winding things down and trying to do it on this positive note as possible because they’re both out of self-interest and trying to be polite. And I was wondering maybe if you guys had some ideas about what do’s and don’ts for when you're done with a project. Obviously, the way in which it ended and the type of project it was will have some effect there, as well.

JONATHAN:

Yeah, absolutely. It totally depends on the kind of project for me. Most of my work is retainer-based strategy engagements that are month to month, so usually, what happens is – honestly, those usually go on infinitely until I cancel on it almost – I can’t think of one where the client fired me. But usually, what happens is in one case, I had a conflict of interest between two clients where a potential conflict of interest between two clients, so I told the newer client – the one that I had been with me for a shorter period of time – I was like, ‘I can’t. This is awkward, and I don’t even want the appearance of impropriety, so let’s just part ways here and go about our business separately’. It was totally – they thought it was – they're like, ‘ah, it’s not really a conflict of interest’, and I was like, ‘ah, I don’t know. Maybe it isn't, but I don’t even want to get into that zone’. And the client that I had for the longer time was, for a few reasons, a better client match for me, so it wasn’t too hard of a decision to just walk away from the newer client.

And then, in another case, just like we were going to have our second baby and I had a long-term retainer client that required that I travel once a month, and it was going to be too much for my wife to deal with the kids, so I basically said, ‘look, you guys, this has been awesome. I love you guys, but I got this life change going on, and I got to stop the travelling, so again, let’s part ways’, but it was done super positive note. And in fact, I’m in touch with them now that it’s been a year and a half – almost 2 years; they're talking about having me come back, so –.

But those are – if you look at less something like a software project, it’s much trickier. So if you have a software project, they're like, ‘ok, here’s the scope’, and you're all excited at the beginning, it’s like a new relationship and everything’s rosy, everyone’s going to get back to each other immediately, there's not going to be any delays or anything like that, it’s going to be a perfect project. And you go through it, the project eventually turns into a force march to hell at some point, whether it’s the launch or whatever, there's some rubber-meets-the-road portion of the software project, they get super hectic, and voices sometimes get raised. And it’s right near the end of the project, usually. So that can be – I think that separates the pros from the amateur stages like that. And then at the end – this is part of my consulting practice that really helps me in situations like these where I get paid up-front and not waiting to send that final invoice. So I’m not waiting for the customer to say, ‘ok, we’re finally done and we’ll pay that last invoice’ after [inaudible] [laughter] punchlist of 50 things and change the way the log-in works and all that stuff.

projects:

eventually, it is safe; eventually, it is stable, but you never know exactly at what point it became stable’. And I liken it to a pond freezing; like at a certain point, you know you can drive your car out there, but you’re not sure exactly what day that happened. You just know that it did happen. So the end of a software project for me is this long tail of minor request that’s slowly dribble out and are eventually over, which I think is very unusual because most people who are billing by the hour, weekly in arrears, or something like that, they're desperate to get sign off on the last piece – what of the last pieces, so that they can that final, maybe 50 or 30% payment at the end.

But for me, I avoid that whole thing by just getting paid up-front and letting the client continue to ask for my help as time goes on. They might need a little bit of maintenance, they might need some handholding for the handoff to the new developers, they don’t understand why I did a particular thing in the JavaScript a particular way, so they can just email me if they want. So mine kind of just dribble out.

CHUCK:

Yeah. I have to say that’s the thing I like about the weekly billing or the get paid all of it up-front is that you don’t get into those situations. I've also been in a situation where it was an ongoing hourly billing in arrears where it was ‘hey, we’ve got this, basically, backlog of work that we want you to work on, and we want it all to move ahead’, but then – the team wasn’t managed well, so I couldn’t actually get any work done because it turned out that I’d spent a week working on something that somebody else had been working on. But they hadn’t claimed it, and so I claimed it, and then they came to me and said, ‘hey, I was working on that, blah blah blah’.

Or another client I had a situation where I was taking on their pet projects, and then, again, things just didn’t quite work out as far as them knowing what they wanted me to do next, but they knew they didn’t want me working on the backlog, and so what I should have done is I should have pulled the plug and said, ‘hey look, you're not getting the value that you should be out of me’, but I didn’t, and so then things went weird. So if things aren’t working, how do you have that conversation so that you can either quit or get it back on track?

JONATHAN:

One thing I’ll do is that sometimes during the course or the v1 of the project, all these ideas will come up, that if I wasn’t careful, would turn into scope creep, and instead, I say, ‘let’s put that on the parking lot for version 2’, and when version 1 is done, then we’ll start a new project and work on the version 2 features. And if you're getting sick of the project dribbling out like that, you can say at some point, like ‘alright, seems like everything is stable. The support requests have trickled out. There may be one here and there. Let’s call this done, and I’ll do a quote for the version 2 features that you want’. And sometimes, that will give people closure that v1 is done; everybody agrees that it’s done; that the lake is frozen solid and it’s ok to move on to the next thing.

REUVEN:

It’s rare for me working on a project to have anyone say, ‘ok, we are done with version1. Let’s move on to version2’. [Chuckles] Basically, there's this always because we’re all agile, right? So agile means that we’ve just got this infinite backlog, and every week, we’ll just attack whatever we can and we’ll edge closer to something that is what we want, which is always infinitely in the distance. [Crosstalk]

JONATHAN:

But the interesting thing about that is that that ties entirely of the way that you bill, though. You couldn’t do a fixed bid like that.

CHUCK:

Yeah.

REUVEN:

Right. That’s true, although you could do, I guess, like a – right, it could be a fixed bid, it could be a weekly bid where you just, every week, you say, ‘we’re going to chip off whatever we can’.

JONATHAN:

But when you do that – I agree that you can do that – but when you do that, do you guys find it hard to keep up the value perception in the mind of the client, [crosstalk] or do they start view it – they don’t they just start to view you as a cost?

ERIC:

I think it depends a lot. I've been on some where I make it very clear when I’m talking with them, like ‘ok, this week, what’s the most valuable thing?’ And that could be something we thought about 6 months ago, or could be a new idea we just had. So I always bring it back to ‘where is the business value? How is this going to benefit you?’ And sometimes, they do get stuck in the mud and see it as like ‘we just have some of your time’, but when it starts getting to that point, I start really talking to them and trying to address the ‘ok, maybe I actually have me work on this project isn't the most valuable thing, and we need to take a break for a couple of weeks, months, maybe a year or so, and let you rethink about what you're doing here. Do the version 2 even if it is a weekly billing type setup’.

CHUCK:

Yeah.

JONATHAN:

[Crosstalk] just the work.

CHUCK:

The other thing is that a lot of times, if I can get the client to meet weekly, or at least regularly, which has been a problem for me in the past, but I have had clients where that’s the case, so it’s ‘ok, well, this week, the plan is to do this. Is that worth whatever the weekly rate is?’ And so I’m essentially keeping the value discussion going as if this week is a project. And so it’s ‘you said you want X, Y and Z done on the project, we’re doing weekly billing, is that worth what you're paying for the week?’ And then if things don’t work out that week, then I start having the conversation where it basically works out to ‘ok, this happened, this is what we’re doing’, but that’s the conversation about there was unforeseen stuff.

ERIC:

Yeah. I think – I want to say was on [inaudible] called Basecamp now; 37 signals Signal v. Noise blog. A while back, there was a post; it was basically along the lines of ‘stop giving estimates in terms of hours, and give it in terms of budget’. So instead of saying ‘this will take 10 hours’, say ‘this will take $2,000’. And so that really lets – the idea is that it lets the client actually say ‘this features are worth $2,000, yes or no?’ instead of ‘is if worth 10 hours?’ And even if they have to do mental math in their head with the hourly, I think it’s enough of a disconnect that it’s confusing.

REUVEN:

I’m not sure whether it’s an Israel thing [inaudible] client thing, but basically, every time I've tried to say to them ‘this will cost X’, and then they say ‘how long will it take?’ ‘well, maybe 2 days’, and like ‘urgh! That’s what you're charging per hour? That’s a lot’. Their goal is always to find a way to make it an hourly charge that they can call me I’m calling – charging in a lot.

CHUCK:

Yeah. I think a lot of folks do that because they're getting other bids from other people on a per hour basis, and so they're trying to compare your cost to everybody else’s cost as though an hour of your work is equivalent to an hour of their work, which isn't necessarily the case.

JONATHAN:

Eric raised the notion of pricing a feature so that the business can make a business decision about the value of the particular feature. And I really like that idea because it puts the conversation in the right place. I was liken that to fixing your car, fixing your house; especially the car, though. It’s like when I was younger, I’d always had a junker, and you bring it into a place, and I had this great mechanic that will be like – it is a bunch of things. I’d bring it in for whatever – flat tire or something, and they'd say they'd fix it; maybe like ‘you know, there's some other stuff going on here, but you're better off buying a new car than paying me to fix it’.

And the thing that really irks me about hourly estimates is that it’s like the guy saying, ‘well, this thing is broken. I don’t know how long it’s going to take me to fix it i.e. I don’t know how much it’s going to cost you to fix it. Do you want me to fix it?’ and I can’t – I don’t know. It depends on how much it’s going to cost, right? You don’t want to pay $10,000 for them to fix the transmission on a $400 car; so I feel like it’s a really strong parallel to software development where if you just say, as a developer, ‘I don’t really know. I think it’s going to take 50 hours, but I don’t really know, and I’m not going to let you hold me to it either, but you could start working tomorrow and we’ll see how it goes’. I can’t believe anybody accepts that deal. [Chuckles]

CHUCK:

Yeah. Well, the thing is I see a lot of people boil things down to hours, and I think it’s because the other people they're talking to are quoting them hours. And so they're talking to – if they're shopping around, they're talking to other freelancers that are billing per hour, so they want to boil it down because one of my hours is equivalent to somebody else’s hours, apparently.

JONATHAN:

But it’s not.

CHUCK:

No. I totally agree, and it’s frustrating, but at the same time, ‘well, that guy’s only 30 bucks an hour, ok fine’.

JONATHAN:

So I use that to my advantage. I say ‘yeah’. I say ‘you're going to shop this around, you're going to get quotes from other people, and they're going to give you estimates. And what that means is you don’t actually know how much it’s going to cost, so you get 6 months in, and the budget’s gone, and you're not done yet. Are they really any cheaper than me who’s telling you up-front how much it’s going to cost and won’t charge you a dime over that no matter how long it takes me?’ And I surface the truth of what’s going on, which is, the other people are putting all the risk on the client and I’m putting all the risk on me. And if you don’t bring up the risk, they’ll always pick the hourly because the hourly will always be a lower quote.

ERIC:

Yeah, because they're not paying for the risk.

CHUCK:

Right.

ERIC:

I've been doing weekly and I've been talking to a bunch of clients with that, and sure, they're still taking a good amount of risk because if there's uncertainty, if something takes longer than I thought, I still charge them for those extra time. But the nice way of – I don’t think it’s just the way I’m billing, but I think it’s how I’m doing the work itself is that it’s helping in that – I’m taking on some risks because I’m actually committing to doing something.

And I've had stuff where I might say it takes 4 hours to do, but it takes me 8 hours. Instead of saying to the client, ‘oh, I need more money’, I’ll work at night. I’ll make it up on my own time and because they're buying a week, it still stays within that billing amount. And they also get some of the benefit if I’m faster – we’re talking a different time, Jonathan – I've been really good on my estimates and been actually coming in under on almost everything I’m doing now. And so that actually means I commit to my client for these 5 days for work, but I actually get 6 or 7 done in that time, which I should be able to capture because I’m specialized, but I’m actually passing the benefit on to my client. So even though I might be more expensive than someone that’s charging a flat $30 an hour, they're getting a ton more work for me and more efficiency. They're also getting a probably earlier calendar-wise than the other person.

It’s hard, though, because you have the balance. There’s so many variables and they don’t know, you don’t know; there's a whole bunch of different risks. And I think that’s why there's so many different models because contractor A versus freelancer B versus consultant C – they're all giving the client something actually different, but the client can only compare 1 to 2 to 3, and it’s different even though the risk is at different profiles.

JONATHAN:

Yeah. And different kinds of customers will put up with that more or less, like government and higher ed. They’ve got a procurement process that forces them to compare apples to apples, so they won’t even consider you in a lot of cases if you won’t give them an hourly rate. So I just make sure to go after customers that are not that rigid and can be flexible on their [inaudible] decisions and do my best to say, ‘look, you can hire people by the hour, but realize that you're taking on a gigantic risk’ – for a big project – for a big project, that’s a huge risk especially if it’s a mission critical thing for the company or it’s their product; their key core product is this piece of software. That’s a giant risk. So most – the bigger the company is, the less they’ll like risk, and the more they’ll pay to avoid it.

ERIC:

I think that how you're billing and how that’s a part of its structure really – that’s going to change how you're going to end a project. The hourly, the – I’m going to call them time-based – those are more akin to projects that are just pitter out. Fixed ones, obviously, you have set deliverables, you have set milestones once they're delivered, and maybe signed off for that part’s done, you bill, you have your wind down. You might do a different process for the wind down, but I think the way you're billing it, the way your company does. I don’t know – is there a term for – onboarding is getting the clients started. Is there a term for like out-boarding where this is the stuff we do to pass on a project; Give it to the client’s team or whatever it is?

JONATHAN:

I usually refer to that as the handoff phase, but I don’t think there's a good term for it. Because there's some other things you do besides the handoff, like – I don’t know – ask for your referrals and a bunch of other things, potentially offer them a maintenance offering if there's going to be a low level of ongoing support; maybe you have to train their customer service department on intricacies of the interface, or there's some stuff – it’s a prototype type of thing and there's some stuff where they are going to need the developer’s intervention to really get under the hood and fix some messed up data in the database or something like that. Then you could say, ‘well, here’s a

maintenance agreement’. There's probably a handful of things that would make sense to do at the end of a project, and therefore be, at least in my best interest, not let it just pitter out like that.

ERIC:

Yeah. I know for myself what I try to do is once – almost clients will book maybe 2 weeks seems to be a good amount, but some would book more, some would book less, but usually the – I’ll end on a Friday; the next Wednesday after, I’ll send an email checking out on them, like ‘is there any urgent things that came up?’ And then, depending on the project, maybe a month, 2 months down the road, I’ll do a follow-up just to check in and [inaudible]. A lot of my projects are ‘spike it, launch it’, and then I’ll come back and do maintenance.

One client I've been working before was – I think it was 8 or 9 years now – basically, they started – I think we settled into a pattern of every 6 months or so, I do a week or two for them to clean up stuff, do a little bit of feature work, and just maintain the system. And so it’s really good if you have a process of follow-up for clients that’s – it’s a lot easier to land repeat work with someone you’ve already worked with and it’s in a system you’ve already worked in or a process you’ve already worked in. I think that’s really important, and a lot of people forget that. It actually hurts the client because the client now has to go back out, find someone new, vet the person, bring them into the project, deal with the slow onboarding of a new consultant before the client starts getting value. But if they could just hire you to come do it, it’s so much better for everyone.

JONATHAN:

Yeah, absolutely. Your risk is then – well, for me, if I was going to give them a $4,000 to do that next thing, I’d be able to deliver that so much faster than anybody they’d be able to find, and I, knowing the [inaudible] inside out, I could probably take a really good guess at how long it’s going to take me to do it and charge them less than somebody from the outside, deliver it faster, and do the least amount of work that anybody would ever need to do to do it because I just know right where to jump in, change that one line and it’d be done. And doing repeat business on a system you already built is perfect. It’s a dream all the way around. [Crosstalk]

ERIC:

I've had a case where I've sent a client that I worked with – it’s actually like the next one says something literally, a one sent email to check in on it, and 2 or 3 emails into it, maybe 10 sent total in the entire conversation with a 5-figure project. It’s because we had that trust, we had the support together, we were jailed really good and all that. It’s just short email and you can book – and I think that’s a really good way to wind down a project by basically winding up another one whether it’s right away or in the future.

JONATHAN:

Mm-hm.

REUVEN:

Yeah, I definitely – I’m still billing mostly hourly with my – not the training work, but the consulting work, the project work. And I definitely found that it pitters out so they’ll have me do 10 hours – maybe let’s say 40 hours in one month, and then 20 hours the next month, and then 10, and then 5, and at some point, I just don’t hear from them. And it’s clear from what you guys are saying that I need to remember to be in touch with them on a regular basis, even just the checking with them and say ‘hey, what’s going on?’ And I think I used to be better at that, maybe about 2 years ago when I would regularly – every month – email all the clients from whom I haven’t heard in a while, say ‘hey, I still got some time left next month’, and this was good for me and for them because it would fill up my time and it would remind them that I exist.

And since basically, I filled up and focused on training, that hasn’t happened [inaudible] necessary. But I still have an employee who’s working on projects; that will probably be smart thing to do.

ERIC:

Yeah. I'm taking this idea from someone else. I've had yet to do, but they basically have a client mailing list – not the standard mailing list you see, but this is like people they’ve worked with that actually paid them money. And I think they even filtered it like ‘here’s people we want to work with again’, so if it’s a bad time and they don’t invite them. I don’t know if it’s the beginning of the project or near the end, they invite them to it and it’s very low frequency – I would say probably once a month or maybe every other month depending.

And it’s like giving them value for the industry that that group works in. And it’s in the events – whatever, and there's the soft called action of ‘hey, we have some time coming up in November’ or ‘hey, we launched a new service offering’, but that has some kind of touch points. And from what I understand, it actually has worked very good for them. It’s very, very easy to do. It’s going to be – for most freelancers, I would say if you have 2 or 3 dozen people in there, you're doing bloomy business. It’s going to be a very small list, but it’s going to be a very, very high-value list per subscriber.

REUVEN:

Right.

JONATHAN:

Yeah, that sounds great.

ERIC:

One thing I do – and this is because I still do mostly software development is near the end, I try to launch before the project’s over. So if it’s a multiple-week project, launch a week before so we have a week post-launch to do just standard fixing stuff. But I try to really transition – if I have accounts under my name or my business name transition to the client, if I have access to different places, if I keep access, I make sure that the client has – they have documentation of how to get it basically along the lines of if I disappear whether because I’m busy or something happens to me personally or whatever, the client has documentation written by someone who created the system or worked on it that they can handoff to the next freelancer. So it’s like a transition plan.

I think that’s something important. It doesn’t have to be very much. I might put together a document that’s mostly links and stuff like that that’s 500 words long. But every time I give it to a client, they value it very highly because that’s like ‘here's a good documentation of the system as it stands from a high level’.

JONATHAN:

Yeah. That’s the thing I put in the quote at the beginning to pump up the value perception, and perhaps interestingly, a technique that I use to do the handoff is I’ll record a screencast of me walking through the system and saying like ‘there's some bodies buried over here. Here’s why’. I try to write very self-documenting code anyway, but it really helps to have somebody hold your hand and just walk through the system, see the log-ins, not the passwords, but see where stuff is, see how I had my development environment set up – all that stuff. I’d say, usually, is an hour-long video, which is nothing to sneeze at, but it gives them something to – it gives them some path to, like you said, if I disappear or like I did do, I change the nature of my business to do a lot less software development; I’m not going to go back and start jumping back into this system almost surely. So that gives them something to go to without having to bug me about it when I probably can’t even remember you later.

ERIC:

Yeah. That’s actually a good point. A recent client I did, there's a lot of scheduled problems, so we still had regular meetings, but there's very time constraints on it. So what I ended up doing just of my own choice is I recorded very short, under 5 minutes screencasts of different features as I finished them, like ‘this is how log-in works. Here’s the admin panel, here’s how you do X, Y, Z’. And just basically, it was just like, ‘hey, I just want to show you what I’m working on’, and that ended up through the project becoming the official training documentation that they're going to give to their entire organization now.

REUVEN:

Oh, that’s great.

ERIC:

One thing that came out of it was they're on Heroku, and Heroku is – it’s user-friendly, but it’s still very technical. It’s a hosting environment. And they have their own account, so what I did is I

basically recorded like ‘if you find the applications having problems and you can’t get a hold of me, here's how you log-in to Heroku, here’s how you scale it up if you're getting this errors, here's where to look for errors, here's how to invite another developer if you need to bring someone else in’, and basically gave them and handed it to the office manager, and she was like, ‘oh, this is amazing. We now have the ability and the control over our application, and this organization is very non-technical’. And so for them, that’s like gold. But it took me 5 minutes to record and talk through in stuff I know intuitively.

JONATHAN:

Yeah. Doing those screencasts is huge. I’m surprised more people don’t do it. It’s so easy, too. If anybody has ever tried to type up documentation, it’s torturous. But doing the screencast’s just doesn’t take much time at all.

ERIC:

And here's actually a value add. You gave me an idea, which I’ll probably do. Just do a bunch of screencasts like this, and then pay the 30, maybe 100 bucks to get transcripts of the screencasts.
So they're searchable and they have a written step-by-step document.

REUVEN:

Oh, that’s really smart.

JONATHAN:

Nice.

REUVEN:

Yeah. I definitely find that even when I fire the client, and even when I find them to be annoying, slimy, treating me poorly, I still really try to put a good face on it and say, ‘well, I don’t want to work with you anymore. It’s not working out’ and all sorts of different things, but I always feel like it’s this small technical world, especially in Israel, but just in general, and if I treat them poorly, if I just – if I let my anger show, then it’s just going to bite me at some point. And maybe that I do that to a fault. Maybe they can see through it [chuckles]. Maybe they know that I really annoyed that they paid me late or whatever it was, but several times, I've been really tempted to serve – slam the door [inaudible] ‘you – I don’t ever want to work with you again. It was terrible’, but I figure one of these days, it’ll come back to haunt me.

ERIC:

I think the worst client parting experience I've had was we finished a project like it was – not a fixed bid or a fixed scope or something, but we finished it up, there's a lot of arguments, they were actually cussing at me, which basically went over the line, and I told them, I’m like, ‘look, I've delivered what you needed. You were satisfied with the version 1. I don’t think we’re a good fit. I

don’t want to do version 2 for you’, and basically parted ways.

I myself, will never work with them again, and if I hear anyone who’s working with them, I just shy them away from it because it’s a people problem; it’s not so much a software we’re working with, but even then, if I gave them what they wanted, they paid me on time, everything was delivered, they had all the code, all that; the project was a success, but basically, because of circumstances of a repeat project was a no go. But other than that, everything’s been great – passing off to clients.

One thing I've ran to a little bit is a month after the project’s done, having the client come back to you and want some changes here and there, even if they pay for it or not, and that’s a hard thing to balance just with scheduling, like ‘how do we get that in and is hat enough work to actually put it on my calendar or not?’

JONATHAN:

Right. I hardly ever do it, but I have recently done maintenance-type stuff where we knew there's going to be a lot of that, so I just came up with a price and it was cool. They would just put ‘To do’s’ in the Basecamp, and I just fix stuff. But it is hard because you don’t know if the volume is going to be there or not, and you want to hook them up because you know there's going to be more work in the future; it’s a little tricky there. [Crosstalk]

ERIC:

Some clients is I’ll have them start a list of what they want in v2, and then when it gets closer, we’ll get on 30, 60-minute sales call, but it’s more of a roadmap; very high level of like ‘what could we fit in? What makes sense to fit in?’ And book another week or two weeks or however long they need at that point. But yeah, if it’s just like minor piece of work, it’s very hard to make them commit to a full week, or try to bump a client around – it’s a hard balance to make and especially if it’s small work, but it’s business critical, the pressure gets pretty high there.

JONATHAN:

Yeah. If possible, I like the idea of collecting all of the – let’s just let these things collect for 6 months, and then do a project in like pick the ones that has the highest business value, so we’re not just doing some low-value stuff today and high value stuff comes up next week. But if it’s business critical, then there's no way on that.

[Crosstalk]

REUVEN:

You’ve mentioned before that when you finish up a project, you try to get referrals from people. So obviously, you have – because the nature of your billing practice, you have very clear ends to these sorts of things. But how do you do that? As you say, ‘well, I going to go say, well I guess we’re finishing up and I’m going to give you some screencasts walking through things. You said you know other people who could use my help’. Do you just ask them straight up ‘please give me the names of people’? Do you ask for introductions?

JONATHAN:

Yeah. I’m not really good about it at the end of the project. When I was bringing that up, I was like ‘oh, that would be good’ because then I would be better about it if there was an off-boarding process that had in place. Usually, what I do – I have approach with referrals that’s a little bit – I guess I’d call it very soft sell-ish, but I just reach out to past clients or colleagues who are aware of the kind of work that I've done, and I’ll just hit them with ‘hey, something fell out of my calendar and I've got unexpected opening next month. Do you know anybody who might need my kind of assistance?’ Then maybe it’s somebody I know. Usually, what happens is they will spin up a project that’s more like Eric’s email of ‘hey, I just wanted to check in’ 6 months later and see how it’s going, then in actual, ask for a referral.

Although I will say with coaching – not so much with my main strategy stuff, but with coaching, I

have been better about asking for referrals. ‘Hey, do you know anybody that’s in a situation like the – think would benefit from this?’ It’s a lot easier because it’s a little bit more productized, and it’s very easy for people to recognize other people who are in the same boat they're in where my strategy clients, the type of businesses they are is really wildly varied. Even though I try and target specific ones, I still get leads all over the map for some reason. So it’s – I don’t know – it doesn’t feel like as great a fit. Maybe I’m just being lazy, but it’s just always feels – I feel like they’d be like ‘I don’t know who to refer you to’. The only other people we know in our business are competitors [chuckles].

REUVEN:

I was going to ask that. If you're working with these large retailers; what is Walmart going to say: ‘well, we hear that Target would be a great customer for you’ [chuckles].

JONATHAN:

Right. Yeah. It feels – maybe I’m just imagining it, but that’s the awkwardness that I feel which has prevented me from going down that path. And to be honest, the retainer clients, they are all multiyear clients I hadn’t really needed to. I’ll probably still be working with the one that I – if I didn’t keep – I want to use the word ‘fired’; I don’t want to use that term, but if I didn’t stop working with that one that I mentioned when Maggie was born, I probably still have 2 more years of 5-figures a month from them that – it just go on forever. I was basically – I was almost an employee they should have hired; they should have filled the position with someone and they had me on for 5 years.

ERIC:

One thing you can do in that circumstance is – I don’t know if it works with your case, Jonathan, but for others is if you did a work for one company, you might ask if they have another apartment that could use your work. So you stay on for the company, say you don’t get that competitor problem, but you go and work with someone else and you can get a direct – probably if you're good to the decision-maker to the person you're [inaudible] check of that other place, and so it works like a referral or almost even a repeat client at that point. And that might be a good way to move along. You just have to be careful that all of your work isn't coming from one actual company itself [inaudible] different divisions.

JONATHAN:

Right. That’s a great idea. That’s actually straight to analyze [inaudible] too, so that I’m sure that will work great. I’m thinking to the specific situations, like all of that stuff makes sense on paper, but I’m thinking this specific engagements and just one I can’t imagine it happening.

Oh, I can think of a training gig; maybe Reuven, this is good for you. Training people aren’t typically in competition with each other the same way that strategic engagement would be. And I've definitely gone to people who have done just one off internal private talks or training workshops and ask for referrals. It hasn’t really gotten me anywhere, but it’s a better fit product fit.

REUVEN:

What I did earlier today – this is merging to what the two of you have said – I worked with a lot of these large companies, so today I was training on site of SanDisk in a [inaudible] Israel. And I’m talking to the head of training there, and she mentions something about ‘oh, yes, we’re in charge of training in Europe as well’ and starts talking about some story about the people she [inaudible] in Europe. I was like ‘well, you know, I don’t mind doing training in Europe’, not mentioning to her that I know the budget is 4 times per day what they pay in Israel. But there are budgeting for that, so they don’t care and I do. So she said, ‘oh, that’s good to think about. I’ll definitely keep that in mind’, and just raising this possibility them starts the ball rolling. I figure if I remind her in a month or two that it might still be an interest, so all of these people are either in-charge of working with other departments where they see it as a benefit to their company.

JONATHAN:

I would’ve gone one step farther in that situation: ask for a name.

REUVEN:

Well, she’s the name. She’s in charge.

JONATHAN:

Oh. Ok, great. Perfect.

REUVEN:

But yeah. With Cisco, for instance, I’m in touch with a woman who does training for everywhere else outside of the US. So she’s been fantastic and I said to her, ‘so, can you introduce me to the person in charge of US training?’ And she said, ‘no. I’m keeping you for myself’. [Inaudible] she keeps me so busy and happy and I’m happy to work with her that I really [inaudible].

JONATHAN:

That's good.

ERIC:

I have one point I wanted to get to actually was looking earlier and found a – I don’t use this, I forgot about it, but it’s a process document of how to close a project. And one thing I do is I've done this a little bit informally, but you handoff the project, wind it down for the client, but you need to do stuff for yourself too. There's a standard if you think about make sure the bills are paid and all that.

But one thing I was looking at is – one thing is to think about what you like about the project, didn’t like about it, and what will you change about it. and I have 3 facets for that, both for the client, for the project itself like what you're doing or building, and then if there's any technical aspects, you always should # use this library or whatever. I think that’s really interesting because then you can really get perspective and figure out ‘ok, this was a good project, but the client didn’t fit very good because of X, Y, Z, so the next client I look for, I need to watch for that thing’. And that was interesting. One thing I do – I do a lot of is make a To Do item where – try to rewrite stuff down while the project’s still fresh and I’ll put them in my portfolio, or if I'm going to try to get testimonial where I’m going to put it – all that stuff to build up my own reputation outside of the project.

JONATHAN:

Kind of a post-mortem just for yourself.

ERIC:

Yeah. And this part doesn’t apply to me as much anymore, but if there's parts of the project or even the project itself – if it could be open source, I would do that because I used to have my contract that all the code will be open source, so once I was done, deliver and the client was happy, I would open source it as a v1 and then use that feedback into my marketing machine that I had going around it.

REUVEN:

DO you guys ever finish your project in a way that you thought was bad that you don’t want to return to?

ERIC:

The pittering out was really bad for me; just the uncertainty of ‘ok, can I schedule more client work or are they going to come back with a full week of work come Monday?’ I always like the start, stop, or ‘here’s the end date’ – that works good for me. You guys know I’m very structure and organized; that fits for me. If it’s ‘hey, we have some stuff. We’ll get to you later’ – I can’t work under that environment.

JONATHAN:

Yeah. I can’t think of one that was a train wreck, but maybe I’m just blocking [chuckle], but I usually have another either client or a project for another client starting up after the projective end of the first one, or another project for that same customer. So I’ll let them know if it’s just rambling on too long and it’s really disrupted to my schedule like Eric was just saying. I’ll be like ‘ok, you guys, the project’s over and I've got other stuff on my calendar that’s ramping up. So my response to this is going to be lower. I’ll get to this stuff, but my response is not going to be as good. And it’s almost like you're [inaudible] them off of you. So they're like, ‘oh, I can’t just pick up the phone and get an instant answer anymore’. Now I have to wait a week, and then the calls get farther and farther between.

REUVEN:

Right. And I definitely feel like – thinking back even over the last 6 months, and even just last week, I met with a client 2 weeks ago, I met with a client to talk to them about doing some training. And I've been doing some consulting for them. And I was meeting one of the managers and we said hi, I said hi to one of the engineers and the engineer was like ‘oh, Reuven you're around. We have some questions we want to ask you about’. And the manager said, ‘well, you know, we have a budget. Why don’t you just call him in?’ I’m thinking to myself, ‘huh. So they’ve got these problems’. I didn’t think about it. And because I didn’t remind them, because I didn’t wind things down with the previous round in the right way, we were all just waiting for each other or waiting for lightning to strike. And I definitely could have pushed that or – by having a, I guess, off-boarding experience more formalized, it would’ve avoided that.

CHUCK:

I think the worst endings that I had to contracts basically boil down to ‘we get done, everybody’s smiling, I give them all the information that I think they need about the code, and then they never do anything with it. That just drives me absolutely crazy. And so then, you're too down the road. It’s like ‘oh, we started using your thing and aaahhh!’ [chuckles] I don’t remember what I did, or they just never ever actually launched it.

ERIC:

So wait – like you built them an app and it never launched, or you did some stuff and it never was integrated, or –?

CHUCK:

Both. I've got both.

ERIC:

Wow.

CHUCK:

So I've got – I've built several custom social networks for people. I've only had one of them actually launch. And then I built a library that tracks changes across different versions of, basically, epubs – the ebook format – and yeah, I see those guys on occasion because they're a local company based in Salt Lake, and every time I talk to them, I get a ‘we’re super happy with your work, but we haven’t hooked it up anything yet’.

REUVEN:

[Chuckles] Yeah. That’s really kind of annoying.

JONATHAN:

I was on a project where it was a team of people doing a front-end for a website and it was going to get handed off to a back-end team to integrate with – what is it called, Wordpress VIP. So that one was interesting because there was a lag time between when the back-end people started working on it, and so we we’re like ‘ok, we’re done’. We handed it off, ‘here’s all the stuff; a couple of weeks go by, nothing. And then we got this flurry of questions about the integration and then once it went live, we got another flurry of questions about basically bugs that – someone’s fault, probably ours, but it could’ve been the integrators – who knows. But we were definitely the ones getting the fingers pointed at us.

So that was probably one of my least favorite situations if we’re talking about winding down projects because it got really busy after everybody had moved on. The team – it was a virtual team; not that we disbanded, but we all went off onto our separate ways and all of a sudden, the client was like ‘aahh hair on fire’. Anyway, Chuck’s story – that reminded me of Chuck’s story when somebody implement something way after the fact that they never actually tested it.

CHUCK:

Yeah.

ERIC:

Yeah. It’s hard for me – I’m trying to think almost all of mine have been launched or success as far as the project is. The business success might fail for other reasons, or it might fall down or whatever. [Inaudible] when I talked about earlier where it’s just – it wasn’t a good fit for the second version of the project and we just went our separate ways.

I think part of it is I’m very – I just try to be – try to be very, very careful when I’m working with someone who has just this idea like ‘I want to build a startup’ or I’m working with a business? And so I select for people who either have a revenue, have existing businesses, or basically, where I can – not guarantee, but it feels like the project’s success is going to be a bit better of a chance than a startup idea that’s just trying to launch and hit a certain atmosphere.

JONATHAN:

Ditto. I’m the exact same way. I feel like startups are in a situation where they're either playing with monopoly money or they're not experienced enough to make a good business decision even if I'm giving them fixed fees. So it scares me because – not confident that I’m going to be able to deliver great ROI. I don’t know if I can satisfy this customer, so it makes me nervous to get involved with either new businesses or just startups in general that are trying to do like ‘ah, I need you to do a prototype for – we’re going to go get funding’. I’m like ‘I don’t know, man’.

ERIC:

Right. And that’s like I said earlier is I try to value these features to – by just the cost of the feature to the value of the business, and if it’s – if there's so many unknowns and there's no history there, it’s really hard to figure out what’s the value of letting users like a friend or whatever. [Crosstalk]

JONATHAN:

A million dollars, apparently. [Chuckles]

ERIC:

But I mean it’s harder to figure out for me. Like I said, I don’t like a lot of uncertainty that I think there's enough uncertainty in software projects as it is. Bringing business uncertainty is like a nice little stew pot of disaster. And so if I can make twice in my business to make it more certain, I’ll do that. and I think I've selected for clients that work that way, too.

JONATHAN:

Yeah. Same here. Identical.

REUVEN:

Yeah. I've worked with a lot of startups over the years, and they definitely seem – I don’t know – strangely price-sensitive and value-insensitive, so I just – I’m stiill working with them, but this is a business client of mine where they're great, they’re nice, they're fun to work with, and they're on the financial markets, and I ask them ‘so how important is this product to you’, and they said ‘oh my god. We have clients who said they would pay for it yesterday. They must actually have this’. I was thinking to myself: great! They're in finance. Their clients [inaudible] they had. They have paying clients already. And so I mentioned my billing rate by the hour, like on a daily rate, and they were like ‘what? You want to charge us how much? We could hire an engineer for a month for your 3 days’. I said ‘yeah, but you’ll get it done soon’. ‘Oh, no no no no no’. And then we negotiate a little bit, and then they finally said, ‘forget it. We’ll just call you in a few hours here and there’. And sure enough, that’s what they’ve been doing [chuckles]. And sometimes – and sometime I’m around and sometimes I’m not around. But, right, I think if they just said ‘let’s go for it for a week, and we’ll bring you in’, I think they would’ve already shift as close to 2 months later not having shift.

JONATHAN:

Yup. Opportunity cost.

REUVEN:

Right. But they were really nice. And it was spectacular view of Tel Aviv, so it’s something [chuckles]. And they have really fancy coffee machine, which is, of course, [crosstalk] necessary. It’s very important for the function to start up – for [inaudible] coffees [inaudible] speaking of winding things down. [Laughter]

ERIC:

[Inaudible] off-boarding part of it.

REUVEN:

[Chuckles] yeah.

CHUCK:

I know that we couldn’t talk about this a little bit, but I do want to cover one more thing, and that is if the relationship isn't going well, are there still things you can do to off-board it to make sure that things come out of the best light? So if they're not happy with you?

ERIC:

It depends on what parts aren’t going well. I've had some projects where it’s not going well because I don’t have availability, which just means they should find someone else or bring in another person. [Inaudible] that fits, not their – I can do the work, they're a great client, but we’re not just matching; it feels like conversations are still [inaudible] that sort of idea.

Once again, try to refer. I usually have probably have a dozen other freelancers, developers, consultants at different spectrums of what they can do, what their rates are. And so I’ll refer either a specific person if I know it’d be a good fit or give them the list, like ‘here’s people I know that are good and I've done a bit of vetting. You can talk to them, and whoever you bring on, I’ll help you transition to that’.

Sometimes, especially if it’s budget or whatever, it’s – we just transition it and try to make it where maybe we cut the budget, maybe we cut the features back and do more minimal project and try to just end it – end it early just by not doing this much work, or even passing it off like an internal team if they have it too.

REUVEN:

Yeah. I always tell clients, even the ones that I fire or that I’m unhappy with – I say ‘listen, I’m committed even though I don’t want to put – even though I don’t want to work with you anymore’ – I think I phrase it a little better – ‘but I’m committed to making sure that you succeed and I want you to succeed, so we can definitely – we will work with whoever you hire to hand things off and make sure things work well with them and there's a smooth transition’. And rarely do I actually hear from them asking me to help with such a transition. I think they're just so ticked off. But I feel good that, at least, I’m offering and I’m honest about offering it, too. In some cases, I even want to see them succeed.

ERIC:

Yeah. I've had that couple where it wasn’t in a bad situation; it’s more of they wanted their team to know and I've taken, I think, a couple of dev days and made it hard training days for their team and showed them ‘here’s how you deploy. Here's how if you want to change the code’, and did an impromptu training session of they’d go off for 2 hours, come back, I review their code with them, all that, just to get them comfortable so that they could basically support themselves as a business without me being around. They actually can back and hire me to do some other heavy feature-work while their team was supporting the lighter stuff. So that’s been a good one. It’s the problem solution. Once the problem # a bad situation, and then how would you actually solve it.

REUVEN:

Yeah. Trying to figure out how the situation got bad and how not to get into it in the future is probably a good thing to do at the end.

CHUCK:

Alright. Well, I think we better wind down. Reuven, do you want to start us off with picks?

REUVEN:

Sure. I've got one fun pick for this week. You might have heard that the US is entering the presidential election season, which I think is the same length as all other countries elections put together. [Laughter] So there's a new podcast done by some of the folks in Slate and other places called the Podcast for America, which is – it’s definitely liberal leaning, but it’s so so so incredibly funny. If you're into political analysis or anything, it’s just great.

These reporters, these 3 reporters basically get to a let loose with all of the things they really believe about presidential elections and politics and what people are saying and not saying and just hysterically funny analysis. So I would definitely recommend it to our politically-minded listeners out there.

CHUCK:

Alright. Eric, do you have some picks for us?

ERIC:

Yeah. I have one. I might’ve picked it before, but this is a repeat because it’s really that good. It’s an app – iOS app – I don’t know if for Android, but it’s called HRV4Training, short for Heart Rate Variability for Training. The short thing is Heart Rate Variability is your heart rate, your pulse, but it’s a bit different. You can really use it to see if you are exercising too hard on the training aspect – all that. But lately, I've actually found that it’s correlating very well with how good I’m sleeping. Or actually, the lack of sleep that I'm getting meaning that it’s telling me that because I'm not sleeping, because I’m working so much, I’m actually pushing it and my body’s getting stressed out a lot more. And I would back out a little bit – it’s actually predicted that I was going to get overwhelmed recently, and actually that I had to take a whole day off this weekend just doing nothing.

It’s a really good app especially if you exercise. If you don’t, it might be overkill, but it’s really interesting. So if you're like the – what’s that called – not productized self whatever – yeah quantified self. It’s really good for that. The killer feature of this version is it uses your phone’s camera to detect your pulse in your finger, which is actually works really, really well. It’s accurate and I actually think it’s a lot better than an actual full on heart rate monitor, at least in this case. So I've actually been doing it for, I think, over 6 months. I think it might be close to a year now. Got some really solid data, and like I said, it correlates with my sleep and also my training levels and then just stress in general.

CHUCK:

Very cool. Jonathan, do you have some picks for us?

JONATHAN:

Yes. The first is – I don’t know if people know, but I do a tech podcast with my co-host Kelli Shaver, and just called Terrifying Robot Dog [chuckles]. It’s a weekly audio podcast where we talk about the way technology’s changing the way we interact with the world. So we’ll do gadget episodes, and really futuristic gadget episodes, usually stuff from Kickstarter that got funded, but we also talk about things like the rise of conversational computing and what might that do to literacy in the world, what that might do for accessibility for people emerging in colonies, and we really try and be a little bit – it’s not too sci-fi. We try to think a little bit into the future and try to make predictions about what we can do now to – or how that will affect society and what we can do now to get ready for that or even steer that a little bit. So I’d love it if you can check that out.

And speaking of Kickstarter, I've got a great one. I suppose everybody knows what a Keurig is, right – one of those pod-based coffeemakers.

ERIC:

The pod people make it?

JONATHAN:

Pod people – I believe pod are small people that [chuckles] – but there is a booze version that is called Bartesian. And it looks just like an espresso machine except for it’s got 4 glass containers attached to the base on each side for the 4 major types of booze. And then they’ve got these pods that you put in to make different flavors. So you make – it’s basically just like Keurig for cocktails and it’s a funded Kickstarter. They started 2.99, which seems pretty inexpensive to me, and they look really nice. They look like a really nice espresso machine. So check that out in Kickstarter; it’s pretty hilarious. For people that [inaudible] likes cocktails.

ERIC:

They really missed a naming opportunity. I could’ve called it the [inaudible].

[Laughter]

JONATHAN:

That really rolls off the tongue, isn't it?

CHUCK:

Alright. Well, I've got a couple of picks here. The first one is – so AJ O’Neal on JavaScript Jabber was harassing Mandy about her fiancée’s inability to buy video games because they just moved and he’s on a spending hiatus for video games. So if you want to go help him out, she’s the one that edits the podcast and makes things run around here at a certain degree, so if you want to go help his game fund, he’s setup an Indiegogo campaign for that and I’m sure he would appreciate any donations you want to make.

I’m also going to pick Downcast. I know I've picked it before, but I just got a new iPhone 6 plus and I really am enjoying having Downcast sink everything up between all of my different places where I listen to podcast. So I’m really liking that.

And then the last one I’m going to pick is the Blue Aftershokz 2 or Bluez 2 Aftershok – I don’t remember; I’ll put a link in the show notes, but basically, it’s – you’ve seen the kind of behind the head band headphones – well, these ones are bone conducting and so I can actually hear stuff going on around me while I’m listening. So if I’m driving down the road with my kid or something like that, then I can hear them ask for treats while I’m listening to my podcast. So anyway, I really like them. I found that they don’t work super well for things like mowing the lawn or anything like that, but other stuff they're awesome. And I where them running and stuff and they're more comfortable than the in-the-ear ear buds because my ears tend to get a little bit sore when I have them in for days on end, and so this is a nice option for other listening.

So those are my picks. And yeah, I guess we’ll wrap up, and thanks for listening.

[This episode is sponsored by MadGlory. You've been building software for a long time and sometimes it gets a little overwhelming. Work piles up, hiring sucks and it's hard to get projects out the door. Check out MadGlory. They're a small shop with experience shipping big products. They're smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter @MadGlory.]

[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net]

[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more]

[Would you like to join a conversation with the Freelancers’ Show panelists and their guests? Wanna support the show? We have a forum that allows you to join the conversation and support the show at the same time. Sign up at freelancersshow.com/forum]

Album Art
163 FS Winding Down a Project
0:00
55:52
Playback Speed: