Note Canvas is a web application where you can store all your notes! Click the button below to sign up; registration is instant!
Sign Up For Free Here!
Posted 4 months ago
Go Back

What should you do if a client asks you to implement something "extra"?

If you've ever done freelance work, or worked at a job where clients are billed by the hour (or per milestone), then you have very likely been in this situation before.

Uploaded Image

Imagine:

You make the last round of presentations, and the project/spec is just pending final approval.

Everything worked fine (within objective interpretation), and the client probably even said so themselves. But then they suddenly ask you to make modifications in some part of the process (that you worked on) that was not really part of the original spec, or something can be reasonably deemed as "fixing errors in the functionality". In other words, they're asking you to do something that is undoubtedly extra.

Now doing something extra is fine if it's something that can be done quickly; however, there are times when their additional request can take hours, even though it looks simple to implement in their eyes; that and/or they're out of budget. One common response would be to just suck it up and do it anyway. You just want to get it over with, and don't feel like going through the process of asking the client for more money or telling them that it's too much to do.

It's easy to say that we should put our foot down and tell the client to respectfully fuck off, but that might not be possible without ramifications on your job status or the cordiality that you currently have with your client. Or perhaps you just don't know how to say no professionally. Well this is not the article for that.

Instead, what I want to do here is to point out some possible ways to minimize the chance of a client asking for extra modifications--not so much with the politics, but more with the understanding of technical details.

Keep in mind that these pieces of advice below might not always be possible, or don't apply based on the type of work that you'll be doing. It might not be possible because of the timeline of your project, or the type of software development approach that your current team is using (i.e. scrum, agile). Rather, this serves as a general advice to people who regularly interact with clients regularly on websites or apps, and get their input on your work. 

Here are the pieces of advice:

  • Clarify as much details in the spec as possible during the initial conversation regarding said spec.

    Some details in the spec get lost in translation, or are loosely interpreted (detail-wise), based on some idea of what the client wants the final product/modification to look like. If some wording seems vague, ask whoever you can, be it a higher up dev or the client themselves. This seems like pretty obvious advice; however in my experience, this is not really done as often as it should be, and some detail on the final product ends up not looking like what the client had in mind. Clarifying, in this case, helps tremendously in reducing the chance of the client asking for additional changes.

  • If this is possible, ask the client to go over the UI with you, and adjust your project/spec's timeline to accommodate for the approval of a mock UI.

    Results in the web development/mobile development world, at least as far as the client is concerned, is more based on what it looks like (or the UI), as opposed to how the code is. Unless the clients were former developers themselves, they are very likely to not care about how the interface is programmed as long as it works to their standards when they tested it. 

    The UI being correct, in their minds, is the metric of whether it "works" or not, and the 
    vast majority of "extra" changes are with regards to some change in the UI.

    Assuming this wasn't part of your project timeline already, perhaps one way to minimize this chance (of them asking for some change in the UI) is to ask the client to review the final mock UI with them. This does several things:

    - If the client understands that it is a mock UI, and they gave the approval, they are implicitly agreeing to a degree of satisfaction with the UI. (If the client is not particularly tech-savvy, make sure to clarify that it's not the final result though.)
    - This minimizes the chance of them asking to change some aspect of it later. If they did end up wanting to change some aspect of the UI in the end, it's very likely that they didn't think much about that aspect of the UI the first time around.
    - As a bonus, if no more changes will be asked of later, then anything you need to implement in the backend is set! The chance of you having to adjust (or God forbid, create) some API endpoint that you were working on just to accommodate for some extra detail the client wants is substantially reduced, as they already saw all the details that they wanted to the first time around.

In summary, those are some pieces of advice that I think can save a lot of developers time in the process of development if they work with a client, and I hope it helps. 

Everyone from your clientele, to sometimes even your project manager, underestimates the time that it takes to properly implement a spec and then test it. While the ideal thing to do is to just tell your client/boss that additional modifications are not possible given limited time/money, more often than not, that is not a possible scenario. If so, those are some things you can do to minimize that chance of the client asking for additional modifications from happening.

Comments

Notice: you can comment as a guest. Just click "Name", then check the "I'd rather post as a guest" option.

Note Canvas is a web application where you can store all your notes! Click the button below to sign up; registration is instant!
Sign Up For Free Here!
(Close)