Transcript: Difficult client... or me?
You can listen to this episode on Anchor
Here is a full transcript of this week’s podcast.
Baz Baruah – host:
This is All Work, No Pay, a show that answers real questions that consultants, freelancers, and business owners have asked.
So, this is All Work, No Pay, where we discuss real questions that have been asked by consultants, freelancers, and business owners. We get a panel of experts to come in and answer those real, real questions. So, today, I’m being joined by Nathan Thomas, who is a web developer from Coded4.
So, Nathan, hiya.
Nathan Thomas:
Hello! How’s it going?
Baz Baruah – host:
Very good, thank you. So, tell us a little bit about what you do before we begin.
Nathan Thomas:
Yeah, so, I basically sit on my computer all day being a geek, building websites and digital solutions from scratch.
Baz Baruah – host:
Fantastic. So, actually, I think today’s question is probably going to be something that you are quite aware of because today’s question is – someone’s saying, ‘Is this is a difficult client, or is just me?’ And we’ll just run through their little story. So, they got this new piece of work in building a website for someone, and the client basically keeps moving the goal posts, saying, ‘Right, can you put this in? Can you do that? Can you add this in? Can you do that?’ The person asking the question has tried to put some boundaries in – has got a contract in place – tried to put these boundaries in, but the client keeps saying, ‘Well, I’m paying you to do what I want, even if that means me changing my mind.’
Now, I know that from my background as a software developer. I recognise that situation. I’m sure that’s something that you’ve come across, as well, Nathan. So, how would you approach this?
Nathan Thomas:
Yeah, no, that’s definitely a situation we’ve encountered before. And it’s a solution that you kind of change and adapt to throughout your experience running your business and offering your services, really.
When we first started up, we fell into this situation countless times, and it was always the mindset of, ‘The client is right. We need to do the best job possible. We need to do everything they want to continue to make them happy.’ But as time goes on, and as you get more projects on, and you’re getting busier, you start to realise, ‘How am I going to manage all this? I don’t have enough time to keep everyone happy by adding to all of these different projects,’ and it can become a real problem.
I think the first way we started to kind of gently approach this topic is just in the way that we are issuing our contracts and issuing our proposals to clients. We’re making them very, very clear on exactly what is included as part of this project, with a full-on itemised list of everything, and that way, you’ve got something that you can present to the client. You can say, ‘Right, you’ve asked for this. This is exactly what this covers, all of these different points in here,’ and that gives you the opportunity to say, ‘Do you need a bit more wiggle room than that?’ or ‘Are you happy with exactly what’s in this brief?’ And once they’ve signed that off, you’ve got that first pillar to lean on if those kinds of situations do come up in the future. You can just gently say to them, ‘Oh, well, this wasn’t included as part of our proposal,’ and then take it from there.
To try and minimise friction with clients – because obviously a lot of clients don’t understand what’s involved in website development, so they might not be aware that they’re asking for a lot; they might think it’s just a minor thing – generally what we do is if it’s the first time they’ve asked for something extra, or second time, and they’re a nice, decent client (you know, paying on time and everything like that), we might take that into consideration but definitely make them aware of it, so just say, ‘This wasn’t something that was included as part of our proposal, however we’re happy to do this one extra piece or this other extra piece for you. That’s fine. We’ll let that slide,’ because I think that kind of mentally sets the client up to be aware of, ‘Ooh, I am asking for a bit extra here.’
And that’s actually been really fantastic because we have had clients in the future come back and say, ‘I know I’m asking a bit more here. Do you mind doing us a separate proposal for this, or can we approach this in the future as a separate project?’ Because they realise that they are asking for extra questions.
Baz Baruah – host:
Yeah, yeah. So, that’s kind of – it’s almost like expectation management, then.
Nathan Thomas:
Yeah, absolutely.
Baz Baruah – host:
Yeah. So, there are a couple of things that spring to mind, then. So, when you’re – does that mean that your proposals are quite detailed, then, and take quite a long time to put together?
Nathan Thomas:
No, not at all. Obviously, it’ll vary from person to person, agency to agency. We generally like to itemise our workload anyway for how we’re dishing it out to the team, you know, who’s going to work on what, and what particular tasks need working on first. So, we can literally just use all of that as the itemised list that we present to clients. We’ll do a little bit of a write-up, but we won’t go massively into detail about every single piece on there.
So, I think it’s more once you’ve got that workflow set up, you can be pretty quick in producing those proposals.
Baz Baruah – host:
Right, okay. And then the other thing – and I think you’ve touched on this already – but the thing that springs to my mind is what happens when there’s a misunderstanding? I’ve got a specific example from my background here. So, I had a client that wanted a timesheet system putting together…
Nathan Thomas:
Yeah.
Baz Baruah – host:
… and the actual spec – and I agreed this spec because I thought it covered everything – came to about 12 lines of text describing how it was going to work. But when we sat down and actually went through and I wrote the code for it – obviously a computer needs everything explained to it explicitly to understand what’s what – it ended up taking about 12 weeks to implement those 12 lines of spec, and that’s because there were so many combinations of cases.
So, how do you deal with that situation where something that on the surface seems really, really simple turns out to be much, much bigger than what you first expected, or the client was expecting something different to what you eventually ended up delivering?
Nathan Thomas:
Yeah, that is a really difficult one is that, and it’s still a problem that comes up every now and then. I think, to a certain extent, for a developer in particular, if you’ve mentally thought, ‘Oh, yeah. This is a dead straightforward task. It’s only a 12-line brief. It should only take me two seconds to do,’ and then it ends up taking a bit longer, that’s more future learning than anything else. There’s not really anything you can do about that.
Baz Baruah – host:
So, you have to suck it up?
Nathan Thomas:
A little bit, yeah. There’s loads of situations where a client will ask me a request and I’ll code it in my head, and for some reason, I think my computer works the same way as my head. So, putting code to keyboard doesn’t always translate the exact same way.
But again, it does kind of have an effect on how your courting procedure or how your scoping procedure works. The way we do it is we’ve got some – we use the Fibonacci sequence to basically say the difficulty of a task. So, we’ve got 1, 2, 5, 8… I’m showing my terrible maths skills at the moment, but it goes up and there’s clear, clear, big breaks between stuff. So, if somebody’s asked us a task and it’s quite involved, rather than just saying, ‘Oh, yeah. It’ll take an hour or so,’ we’ll normally say, ‘Ah, well, that one because it’s so involved and so complicated, it’s a 21-pointer,’ so you’ve got kind of some leeway either side. If you get it done quicker, fantastic! If it takes you a bit longer, you’ve still covered – to an extent – all of the work involved in that particular task.
Baz Baruah – host:
And actually, there – both of us have the software background – so, we’re getting into something that’s a bit software-specific to some extent, but this is something that works really well for estimating with software.
I quite often hear people say, ‘Right, when I’m planning out my workload, I’ll put stuff into my diary and say I’m going to work on this on Monday morning, and work on this on Tuesday afternoon,’ and stuff like that. And for me – and I guess for you – that doesn’t really work a lot of the time because you might say, ‘I’m going to work on this on Monday morning,’ and then find that it actually takes all of Monday to Wednesday to get it done.
Nathan Thomas:
Yeah, definitely.
Baz Baruah – host:
And then, you might think, ‘Right, I’m booking out all of Thursday to work on this,’ and find it takes five minutes to get it done, which is less common, but it does happen.
So, yeah, I just wanted to run through this because you mentioned there this idea of ‘points’, and I guess – do you do velocity as well then?
Nathan Thomas:
We probably should, but we haven’t much been tracking that.
I’m a bit weird in terms of business owner because we track the productive time that every member of the team has, and we try not to put any real pressure behind it because, like you say, things can take various amounts of times. I could sit there quite easily as the business owner and say to my team, ‘Right, this needs doing today, absolutely, it’s the deadline,’ stress them the heck out, and then it probably won’t even get done because they’re just too busy stressing about it.
So, we don’t do any velocity tracking. We track our productive hours; everybody monitors their time, and we can see who spent time on development, on emails, admin tasks, all that kind of different stuff. But we do use the difficulty of a task to kind of set expectations of roughly how long things should take.
Baz Baruah – host:
So, just to explain the story point thing, so the idea is then each piece of work instead of being given an estimate in terms of hours is given an estimate in terms of points. So, if it’s an 8-point piece of work, then it’s going to be twice as hard to do as a 4-point piece of work, but it doesn’t necessarily mean that that means it’s going to take twice as long.
Nathan Thomas:
Yeah, definitely.
Baz Baruah – host:
And then, so just to explain the idea behind the velocity, then, is you measure how many points you complete in a week or in two weeks, and then you can use that to then estimate how long something’s going to take further down the line. And the idea behind that is we’re taking in evidence. So, if we have a project that is actually really, really difficult to do, and every 4-point feature takes three days to complete, then our velocity is going to drop right down, but we can see that happening and then we can deal with it. So, that’s just a little side line for the non-software developers listening about how the story points and stuff like that work.
So, in this particular case – so, we’ve got a client here who is basically moving the goal posts all the time, changing what’s required, and they’re saying, ‘Well, I’m actually paying you, and it doesn’t matter what I say. If I’ve changed my mind, then that’s it. I’m paying you for that.’ Part of me is thinking, right, that client then immediately goes onto basically an hourly rate and gets charged for every single thing they do. However, if they’re an arsehole, then they probably won’t accept that.
Nathan Thomas:
Yeah.
Baz Baruah – host:
That touches again, then, on pricing. So, when you put together a proposal like this that’s itemised in that way, does that then give you enough to be able to price it, to give a fixed price for it?
Nathan Thomas:
Yeah, for us, that’s been one of the biggest things that has helped us out because we actually use the story points for all these tasks to give us our price. So, the end number – say if the total ends up being 112, for example – we’ll run that through a little formula that then just gives us the final price for that piece of work.
The beauty about that is if you realise that are you starting to quote less than you should for jobs, or more than you should for jobs, you can just change one figure that you’re multiplying it by, for example, and adjust your prices on an ongoing basis until you hit that sweet spot. But it does mean for projects that are X amount of points, you’ve got a fixed price to give that client for that piece of work.
Baz Baruah – host:
Okay, so, if the client does come back and say, ‘Right, I know I asked for this, and this is what it is, but now I’ve seen it, this isn’t the way I need it work, and I need it to work this way,’ how do you respond to that?
Nathan Thomas:
It will, again, depend on the situation and what the client’s like. If in your mind, you’ve started thinking, ‘This client’s a bit of an arsehole, and I don’t want to deal with them,’ that’s probably a point where you would be best kind of putting your foot down a bit and saying, ‘Okay, I’ve taken in what you’ve said. You’re wanting this changing. Can we finish the rest of the project first, and then approach this as an additional task at the end of it?’ Because then, you’re keeping to your original contract – your original proposal with them – you’re completing the work that was agreed upon, and then future discussions about that change can be a completely separate item, a separate piece of work.
Baz Baruah – host:
Right, yeah.
Nathan Thomas:
If they are, again, one of these nicer clients and maybe they’re realising that they are asking additional extras, or it is just the first one, it just depends on the scope of it, really, I’d say. You do need to make a bit of a judgement call of, ‘Is this going to be a complete refactoring of the entire project? Do I have to redo everything again, or is it just a couple of hours’ extra piece of work that maybe I can just absorb?’ That’ll be entirely dependent on your pricing altogether, like whether you are pricing what you should be pricing.
Baz Baruah – host:
Absolutely. So, that’s kind of interesting. So, a big part, then – just to recap: so, if you’ve got this difficult client, the one who’s changing their mind, who’s being a bit of an arsehole about stuff, the reason you probably got there is because you set the expectations wrongly right at the start. And that comes right from your proposal or however you put together the job bid in the first place. So, if you can get the proposal correct, and you can set those expectations correctly – as well as your pricing – then, actually, it doesn’t matter if the client is being an arsehole further down the line because well, they’re less likely to be an arsehole anyway, or you can deal with it, and they can deal with it because they know what to expect further down the line.
Nathan Thomas:
Yep.
Baz Baruah – host:
Okay. So, that’s really, really useful. That’s a fantastic way of looking at things. So, if anyone needs any web development or any online systems building, what’s the best way for people to get in touch with you?
Nathan Thomas:
The best way for people to get in touch would be via email, so emailing nathan@coded4.co.uk.
Baz Baruah – host:
Fantastic! Right, I will stick that in the show notes, as well, so anyone who needs to get some digital work done can get in touch with you. So, thank you very, very much, Nathan. This has been really, really useful. That’s another episode of All Work, No Pay completed. See you next week.
I’d be really grateful if you could leave us a review in your podcast app. And if you’d like a transcript of this episode, and to join on Fix-It Fridays, head over to clientrobot.com/allworknopay.
Struggling with your business? Get profitable - free 15 minute consultation: https://calendly.com/clientrobot/15-minutes
