How do you set limits on client feedback?
March 11, 2018 11:56 PM Subscribe
I am the art director at a small design agency. Part of my job involves project management, and I am really struggling with keeping client feedback at a reasonable level/pace. How do you handle this at your company?
We make apps for clients of all sizes. Regardless of whether I am doing a fixed bid or time and material approach, I have 3 rounds of wireframes for every project plus 2 rounds of visual designs. Right now a round consists of two week sprints of production plus a third week of receiving and implementing feedback from the client. The goal with each round is to lock in screens so we can move them into development. (I hate agile/scrum.)
Every. Single. Client. Has a hard time with this. They have 48 hours to review the deliverable we send per round. We then implement that feedback to the best of our abilities and send screens back to the client for review. They have 24 hours to review those changes before we lock in screens and flows.
This is the point where things go wrong. The client will continue giving feedback on the deliverable after that second review because they change their mind or decide my team has made a mistake that we need to fix before we can lock screens in. We end up giving clients unbilled hours to keep them happy because I don't know a good way of halting feedback on Deliverable #1 so we can move on to #2 without a fuss.
Wtf is the missing link here? This is partially due to all my projects being under scoped for design, but I gotta deal with it anyway even on projects that do have reasonable design hours built in to their fixed bids. How do I say no when a client says they aren't happy? Obviously we do make mistakes sometimes and we fix those, but everything else we do according to the scope of work the client signed. Ultimately I want to be in a position where I can firmly say, hey, either we move on and add these items to your wish list, or I bill you for additional hours so we can add new rounds for review and adjustments. I'd also like to be able to say, I need to bill you for additional hours period because you've gone over your allotment and we can't move forward at all.
Things I have tried and am improving on with every client:
My boss backs me up and supports me, but it is still on me to learn how to develop this skillset and enforce it within the limited number of design rounds I have so I can stop bleeding hours.
Thanks for your input.
We make apps for clients of all sizes. Regardless of whether I am doing a fixed bid or time and material approach, I have 3 rounds of wireframes for every project plus 2 rounds of visual designs. Right now a round consists of two week sprints of production plus a third week of receiving and implementing feedback from the client. The goal with each round is to lock in screens so we can move them into development. (I hate agile/scrum.)
Every. Single. Client. Has a hard time with this. They have 48 hours to review the deliverable we send per round. We then implement that feedback to the best of our abilities and send screens back to the client for review. They have 24 hours to review those changes before we lock in screens and flows.
This is the point where things go wrong. The client will continue giving feedback on the deliverable after that second review because they change their mind or decide my team has made a mistake that we need to fix before we can lock screens in. We end up giving clients unbilled hours to keep them happy because I don't know a good way of halting feedback on Deliverable #1 so we can move on to #2 without a fuss.
Wtf is the missing link here? This is partially due to all my projects being under scoped for design, but I gotta deal with it anyway even on projects that do have reasonable design hours built in to their fixed bids. How do I say no when a client says they aren't happy? Obviously we do make mistakes sometimes and we fix those, but everything else we do according to the scope of work the client signed. Ultimately I want to be in a position where I can firmly say, hey, either we move on and add these items to your wish list, or I bill you for additional hours so we can add new rounds for review and adjustments. I'd also like to be able to say, I need to bill you for additional hours period because you've gone over your allotment and we can't move forward at all.
Things I have tried and am improving on with every client:
Showing them our design tools during kickoff and explaining what they will and will not be able to see during each phase.How do I stand firm on this? What is the diplomatic way to tell clients when their feedback is also a setback? What do I say when they tell me that it is my fault I am not getting things right so why should they pay for additional hours when really, truly, I swear to God it is them that is going overboard?
Telling them what kind of feedback we need during each round
Showing them a calendar of when things are due on their end and what will happen if they don't stay apace with us.
Crying (privately).
My boss backs me up and supports me, but it is still on me to learn how to develop this skillset and enforce it within the limited number of design rounds I have so I can stop bleeding hours.
Thanks for your input.
I have had the same problem so I’m hanging on the replies to this.
Designers / artists take pride in their work and are particularly susceptible to getting hung up on negative or indifferent feedback. But it sounds like you’ve got a lucid and sensible system in place, and you sound pretty confident in your delivery. So there should be no problem, but that clients are a species that loves to make changes for the sake of making changes, and won’t stop until they’re forced to. If they didn’t like your finished work they presumably wouldn’t have come to you in the first place, right?
The only technique I’ve seen work is to be really transparent with the contract conditions (it sounds like you are) and, if they get unreasonable, shove that contract in their face as many times as necessary. Be friendly about it, but not a people-pleasing pushover (this is coming from a stellar pushover). Make it sound like your hands are tied, it’s a shame but them’s the ropes, and pit them against the boring legal mumbo-jumbo rather than against you.
posted by youhavedeadedme at 1:25 AM on March 12, 2018 [1 favorite]
Designers / artists take pride in their work and are particularly susceptible to getting hung up on negative or indifferent feedback. But it sounds like you’ve got a lucid and sensible system in place, and you sound pretty confident in your delivery. So there should be no problem, but that clients are a species that loves to make changes for the sake of making changes, and won’t stop until they’re forced to. If they didn’t like your finished work they presumably wouldn’t have come to you in the first place, right?
The only technique I’ve seen work is to be really transparent with the contract conditions (it sounds like you are) and, if they get unreasonable, shove that contract in their face as many times as necessary. Be friendly about it, but not a people-pleasing pushover (this is coming from a stellar pushover). Make it sound like your hands are tied, it’s a shame but them’s the ropes, and pit them against the boring legal mumbo-jumbo rather than against you.
posted by youhavedeadedme at 1:25 AM on March 12, 2018 [1 favorite]
The keys to this are being less open about your work process and limiting feedback.
In your list of Things I have tried only the third is helpful to you.
If you tell them everything about all your design methods and what kind of feedback you need, what do you think they'll really hear?
They'll hear "You have every option at your disposal to do anything, and you can give feedback on everything and it'll just change, and..." etc.
Show them that calendar of when things are due on their end and what will happen if they don't stay apace! (THEY WILL BE BILLED!)
(And don't cry. If they could do this stuff themselves, they wouldn't need to hire you.)
posted by mdrew at 1:28 AM on March 12, 2018 [9 favorites]
In your list of Things I have tried only the third is helpful to you.
If you tell them everything about all your design methods and what kind of feedback you need, what do you think they'll really hear?
They'll hear "You have every option at your disposal to do anything, and you can give feedback on everything and it'll just change, and..." etc.
Show them that calendar of when things are due on their end and what will happen if they don't stay apace! (THEY WILL BE BILLED!)
(And don't cry. If they could do this stuff themselves, they wouldn't need to hire you.)
posted by mdrew at 1:28 AM on March 12, 2018 [9 favorites]
If at all possible, don't just leave the designs with the clients and wait for their feedback to come through by email or phone or whatever. They will show the designs to people who aren't involved and who have no understanding of what was agreed in previous stages or even of what you're trying to achieve, and then you client will agree with those people for god knows what reason (I blame an unfeeling, chaotic, entropic universe).
Instead, if you can, send the designs to be reviewed a couple of days before an in-person workshop. If the client wants their cousin who once designed a flyer for his school talent show in 1997 to review the designs, great, but that feedback has to be shared with you in the workshop. Make it clear from the beginning of the project that you receive the feedback in these workshops and that you leave the workshops with a list of changes that will be implemented. If you tally up the estimates for making those changes and it vastly outstrips the hours you have available, then you tell the client that and ask them to prioritise (unless it's clear that the reason they want so many changes is that you got it totally wrong, which happens sometimes- that's when you should be 'eating' hours, not when the client is just asking for changes because they can) . Be clear in the contract that any changes fed back outside of these workshops are chargeable, and you can't ask for changes for phase 1 during the workshop for phase 2., etc.
This is obviously a time-suck, because you have to plan the workshops and run them and get people to attend them, but the costs around this can be built in from the start and will get easier as you get more efficient. You can run them remotely with screen-sharing if you need to.
It's the only thing that's ever worked, in my experience.
posted by cilantro at 1:51 AM on March 12, 2018 [21 favorites]
Instead, if you can, send the designs to be reviewed a couple of days before an in-person workshop. If the client wants their cousin who once designed a flyer for his school talent show in 1997 to review the designs, great, but that feedback has to be shared with you in the workshop. Make it clear from the beginning of the project that you receive the feedback in these workshops and that you leave the workshops with a list of changes that will be implemented. If you tally up the estimates for making those changes and it vastly outstrips the hours you have available, then you tell the client that and ask them to prioritise (unless it's clear that the reason they want so many changes is that you got it totally wrong, which happens sometimes- that's when you should be 'eating' hours, not when the client is just asking for changes because they can) . Be clear in the contract that any changes fed back outside of these workshops are chargeable, and you can't ask for changes for phase 1 during the workshop for phase 2., etc.
This is obviously a time-suck, because you have to plan the workshops and run them and get people to attend them, but the costs around this can be built in from the start and will get easier as you get more efficient. You can run them remotely with screen-sharing if you need to.
It's the only thing that's ever worked, in my experience.
posted by cilantro at 1:51 AM on March 12, 2018 [21 favorites]
Have you ever considered creating a master checklist of elements common to all the Websites you do, to hand off to clients at the same time you ask for feedback to help guide the conversation? I don't think (most) clients are the problem, so much as the turnaround time is fast, and most people most of the time don't know what they're looking at or how to begin to parse and describe it. So what if you wrote up something like ...?
Title — Satisfied/Not satisfied
Subtitle — Satisfied/Not satisfied
Visual — Satisfied/Not satisfied
Buttons — Satisfied/Not satisfied
Food for thought, anyway. Good luck!
posted by Violet Blue at 3:10 AM on March 12, 2018 [3 favorites]
Title — Satisfied/Not satisfied
Subtitle — Satisfied/Not satisfied
Visual — Satisfied/Not satisfied
Buttons — Satisfied/Not satisfied
Food for thought, anyway. Good luck!
posted by Violet Blue at 3:10 AM on March 12, 2018 [3 favorites]
This isn't a project problem it's a contract problem. At my work they bill for variations. Every contract gets a certain number x of variations and then you work by the hour on top of the agreed fee---otherwise it's just the client getting free revisions.
posted by Fiasco da Gama at 3:28 AM on March 12, 2018 [13 favorites]
posted by Fiasco da Gama at 3:28 AM on March 12, 2018 [13 favorites]
I am currently your client. Not literally obviously, but I am currently in a similar design review process with misunderstandings between the designer and me.
If you were my designer, things that could have improved our cooperation:
- Kick off meeting to create an agreed upon timeline at the start. How are we going to work? What is my role? What is yours? What timelines are we going to use?
- Update during the process (e.g. this is feedback round 1/3 for the design of site xyz.).
- Per round, specify what kind of feedback you need. A design can be overwhelming. I am no expert, I don't know what needs to be reviewed right now and what can be changed later. Help me focus on the key points. If not, I will focus on the image you are using that can easily be replaced (content vs structure).
- Ask me to write down the feedback, but call me to discuss it (or organize a workshop as cilantro suggests, which is the best suggestion but not always feasible). Are you sure my feedback is specific enough and you understand what I mean?
- Keep me focused. Your work is very important to me, but if sometimes my own clients call me I prioritize that. I don't say that is good, but it's how it sometimes goes.
Hope this helps. PM me if you have specific questions you don't want to ask your clients.
posted by eau79 at 3:39 AM on March 12, 2018 [5 favorites]
If you were my designer, things that could have improved our cooperation:
- Kick off meeting to create an agreed upon timeline at the start. How are we going to work? What is my role? What is yours? What timelines are we going to use?
- Update during the process (e.g. this is feedback round 1/3 for the design of site xyz.).
- Per round, specify what kind of feedback you need. A design can be overwhelming. I am no expert, I don't know what needs to be reviewed right now and what can be changed later. Help me focus on the key points. If not, I will focus on the image you are using that can easily be replaced (content vs structure).
- Ask me to write down the feedback, but call me to discuss it (or organize a workshop as cilantro suggests, which is the best suggestion but not always feasible). Are you sure my feedback is specific enough and you understand what I mean?
- Keep me focused. Your work is very important to me, but if sometimes my own clients call me I prioritize that. I don't say that is good, but it's how it sometimes goes.
Hope this helps. PM me if you have specific questions you don't want to ask your clients.
posted by eau79 at 3:39 AM on March 12, 2018 [5 favorites]
They have 48 hours to review the deliverable we send per round. We then implement that feedback to the best of our abilities and send screens back to the client for review. They have 24 hours to review those changes before we lock in screens and flows.
Like your clients, I don't fully understand your processes and so apologies in advance if what I'm suggesting is obviously impractical. Putting myself in their shoes, those time scales seem short. Not only are you design experts, you've been devoted to this project and have thought through all the issues over two weeks, but I only have a few hours to get my head around all the tradeoffs you've made as well as relating what you've produced to my original needs. I'll do my best to put together the feedback you want in the time available, but then I'll sleep on it and think of something else. Is there any way to give the clients more thinking time? Previews before the deliverable?
posted by Busy Old Fool at 3:47 AM on March 12, 2018 [14 favorites]
Like your clients, I don't fully understand your processes and so apologies in advance if what I'm suggesting is obviously impractical. Putting myself in their shoes, those time scales seem short. Not only are you design experts, you've been devoted to this project and have thought through all the issues over two weeks, but I only have a few hours to get my head around all the tradeoffs you've made as well as relating what you've produced to my original needs. I'll do my best to put together the feedback you want in the time available, but then I'll sleep on it and think of something else. Is there any way to give the clients more thinking time? Previews before the deliverable?
posted by Busy Old Fool at 3:47 AM on March 12, 2018 [14 favorites]
Seconding that 24 hours, or 48 hours, isn't enough. What if they have a business mini-crisis right when you send the designs to them? You know, that's incredibly likely. Also, they're not trained designers; it might take a few days for them to wrap their heads around the stuff you send them.
Plus, they'll see things in an entirely different way from the eventual end users of your design, who are their clients and/or bosses -- that takes time to process, in fact, the difficulty in seeing things this way is one reason you are valuable professionals.
They not only need a lot more time to process what you've sent them, they also need you to explain it to them. That takes time. Setting up meetings for you to walk them through takes time, too.
posted by amtho at 4:11 AM on March 12, 2018 [4 favorites]
Plus, they'll see things in an entirely different way from the eventual end users of your design, who are their clients and/or bosses -- that takes time to process, in fact, the difficulty in seeing things this way is one reason you are valuable professionals.
They not only need a lot more time to process what you've sent them, they also need you to explain it to them. That takes time. Setting up meetings for you to walk them through takes time, too.
posted by amtho at 4:11 AM on March 12, 2018 [4 favorites]
Scrum is a contract between the team and the client. The team agrees to get the agreed work done in the time allotted so the client has reliable estimates, and the client agrees not to mess with work that's already in-flight, so the team isn't dancing on quicksand.
In theory, it's obvious that the client isn't living up to their side of the contract here. But dig deeper, and I bet there are two reasons for this: (1) You're not adapting the process to the client's needs (2) You're picking up after the client so there's no cost (for them) in late changes.
I suggest you throw your 24/48 approach out the window, and make the client aware that work will not even be scheduled until they sign off the designs, and once the designs are signed off there will be a cost associated with trying to change them - basically, that work will get pulled out of the current sprint and rescheduled for the next sprint.
In exchange for that, you need to spend more effort explaining the design to the client up-front. I don't have a clue how you'd do that because design's not my thing, but I would guess either dynamic mock-ups or longer conversations.
posted by Leon at 4:21 AM on March 12, 2018 [7 favorites]
In theory, it's obvious that the client isn't living up to their side of the contract here. But dig deeper, and I bet there are two reasons for this: (1) You're not adapting the process to the client's needs (2) You're picking up after the client so there's no cost (for them) in late changes.
I suggest you throw your 24/48 approach out the window, and make the client aware that work will not even be scheduled until they sign off the designs, and once the designs are signed off there will be a cost associated with trying to change them - basically, that work will get pulled out of the current sprint and rescheduled for the next sprint.
In exchange for that, you need to spend more effort explaining the design to the client up-front. I don't have a clue how you'd do that because design's not my thing, but I would guess either dynamic mock-ups or longer conversations.
posted by Leon at 4:21 AM on March 12, 2018 [7 favorites]
I've been in this situation many times myself, and there are two solutions, neither of which are particularly pleasant:
1. Set extremely limited and much more specific rules about what can be changed in a project or design. We've gone so far as to limit the scope of change by setting up templates that we literally cannot change. This is clearly impractical for some projects, but there you go.
2. Putting aside the questions of potentially insufficient review times mentioned above, your boss, or whoever is ultimately responsible for the contract, needs to just say "No" when the client asks for something out of scope. They should be as polite and as diplomatic as possible, but they need to say no. Usually this works out fine, although it can be stressful.
posted by adrianhon at 4:34 AM on March 12, 2018 [2 favorites]
1. Set extremely limited and much more specific rules about what can be changed in a project or design. We've gone so far as to limit the scope of change by setting up templates that we literally cannot change. This is clearly impractical for some projects, but there you go.
2. Putting aside the questions of potentially insufficient review times mentioned above, your boss, or whoever is ultimately responsible for the contract, needs to just say "No" when the client asks for something out of scope. They should be as polite and as diplomatic as possible, but they need to say no. Usually this works out fine, although it can be stressful.
posted by adrianhon at 4:34 AM on March 12, 2018 [2 favorites]
I like where Leon is going with their suggestions.
We recently went through a design process for a PowerPoint template. Your deadlines would have given us too short a turnaround time for our feedback. We also struggled to give feedback because what we were receiving back was so incredibly off from what we had talked about in the design phase -- not saying that this is necessarily your problem. As non-design people, your clients may struggle with the vocab to give you good feedback which makes it take longer. Also some explanation of why you made the choices you made might be helpful. For example, "We chose X functionality for this poor execution because option Y would have had this bad result."
If every single client has a problem with your process then you might need to change how you do this in order to support limited hours and "eating" hours only for your mistakes. I would try to talk to some of your clients to understand what caused problems on their side so you can build more time or communication tools into your process.
posted by emkelley at 4:56 AM on March 12, 2018 [3 favorites]
We recently went through a design process for a PowerPoint template. Your deadlines would have given us too short a turnaround time for our feedback. We also struggled to give feedback because what we were receiving back was so incredibly off from what we had talked about in the design phase -- not saying that this is necessarily your problem. As non-design people, your clients may struggle with the vocab to give you good feedback which makes it take longer. Also some explanation of why you made the choices you made might be helpful. For example, "We chose X functionality for this poor execution because option Y would have had this bad result."
If every single client has a problem with your process then you might need to change how you do this in order to support limited hours and "eating" hours only for your mistakes. I would try to talk to some of your clients to understand what caused problems on their side so you can build more time or communication tools into your process.
posted by emkelley at 4:56 AM on March 12, 2018 [3 favorites]
Forty-eight hours is not enough time for me to get sign off by all the stakeholders who need to see a thing. And 24 hours for visual design! No way can I make that work. I wouldn't be getting feedback for three or four days from some people and it will be at odds with what the other guy said, and we'll riff off the changes that Jim proposed and the guy who didn't give feedback the first time will suddenly come in to the picture as well. I'm in meetings seven hours a day, and so are all the people I'm trying to track down.
That time-frame could potentially work if you provide a strict checklist as suggested above. I have built forms for feedback that work similarly for other projects when I need to get feedback and it works much better to help people focus on what u need them to focus on, plus I have a record that they supposedly gave these things a thought at some point in the past, so when changes come up I can decline them.
posted by peanut_mcgillicuty at 5:27 AM on March 12, 2018 [2 favorites]
That time-frame could potentially work if you provide a strict checklist as suggested above. I have built forms for feedback that work similarly for other projects when I need to get feedback and it works much better to help people focus on what u need them to focus on, plus I have a record that they supposedly gave these things a thought at some point in the past, so when changes come up I can decline them.
posted by peanut_mcgillicuty at 5:27 AM on March 12, 2018 [2 favorites]
If the client isn't pushing a specific due date, I wouldn't push a response within 24-48 hours. I barely manage to reply to basic emails in that timeframe, much less something that 1) I will be looking at every day forever, 2) That I have little vocabulary to critique, 3) That, because of #2, probably looks nothing like I'd expected it to because I described it very poorly in the initial meeting. They may also need to get ok's from higher-up folks who have few open meeting slots. I'm in a totally different field but also sometimes have some iterations, and I tell clients that the timer starts from when I get their feedback and not from when I first get the order.
posted by tchemgrrl at 5:28 AM on March 12, 2018 [1 favorite]
posted by tchemgrrl at 5:28 AM on March 12, 2018 [1 favorite]
Coming at this from a design perspective, clients tend to absolutely demand adherence to the final deadline, which frequently necessitates the fast turnaround time for feedback on revisions, which they then ignore!
First piece of advice is to try and come to terms with this to some degree... much easier said than done, but in my experience, this is just the nature of the client beast. People in general will also take as much as they possibly can get out of you before the deadline.
In my freelance work, you get x number of revisions rounds, and if you go over, you get charged additional fees. Another way to handle this is by making clear that you can implement the changes, but unfortunately it will no longer be possible to meet the original deadline, which will have to be pushed to XYZ. (And also charge more!) Clients do this because they want the best thing possible and they generally have no idea how much work they’re actually asking for, and unfortunately, no matter how much you educate them on the actual process, they don’t really care and it doesn’t mean anything to them. It’s not their wheelhouse, they just want App for agreed upon $X by XYZ date. Your recourse to limit them running roughshod over you is to state up front that additional charges are incurred for these things and then follow through as needed.
This is where the contract comes in and youhavedeadedme had good advice. In my freelance contract I specify project milestones with target dates of completion so everything is spelled out as specifically as possible. My contract also specifies what happens if revisions go over that, or if the client starts pushing to broaden the project scope — it all usually boils down to pushing back the deadline and billing for more work done.
posted by caitcadieux at 5:56 AM on March 12, 2018 [4 favorites]
First piece of advice is to try and come to terms with this to some degree... much easier said than done, but in my experience, this is just the nature of the client beast. People in general will also take as much as they possibly can get out of you before the deadline.
In my freelance work, you get x number of revisions rounds, and if you go over, you get charged additional fees. Another way to handle this is by making clear that you can implement the changes, but unfortunately it will no longer be possible to meet the original deadline, which will have to be pushed to XYZ. (And also charge more!) Clients do this because they want the best thing possible and they generally have no idea how much work they’re actually asking for, and unfortunately, no matter how much you educate them on the actual process, they don’t really care and it doesn’t mean anything to them. It’s not their wheelhouse, they just want App for agreed upon $X by XYZ date. Your recourse to limit them running roughshod over you is to state up front that additional charges are incurred for these things and then follow through as needed.
This is where the contract comes in and youhavedeadedme had good advice. In my freelance contract I specify project milestones with target dates of completion so everything is spelled out as specifically as possible. My contract also specifies what happens if revisions go over that, or if the client starts pushing to broaden the project scope — it all usually boils down to pushing back the deadline and billing for more work done.
posted by caitcadieux at 5:56 AM on March 12, 2018 [4 favorites]
I agree with a lot of what has been said already:
posted by adamrice at 6:21 AM on March 12, 2018 [2 favorites]
- Your contract should spell out charges for the unpaid work you're doing.
- 24/48 hours is not a long time for client review. I've had clients-of-clients say they need something "as soon as possible" and then give feedback a month after delivery. It's not hard to imagine Mr. Important Boss-Man not bothering to look at the intermediate work until way after your feedback deadline.
- You need to lie. I mean, you need to build some elasticity into your deadlines. If I need something in two weeks, I tell people I need it in one week. They'll still get it to me after the two-week deadline, but they'll be merely late, not catastrophically late.
posted by adamrice at 6:21 AM on March 12, 2018 [2 favorites]
I wonder if your pre-design discovery phase is not doing a good enough job of understanding and documenting the requirements that are driving design and IA? In theory, coming out of discovery there should be broad agreement on the project., so wireframes and visuals are expressions of stuff that have already been agreed upon to a certain extent. If you aren't getting that agreement before starting to create stuff your first wireframes and designs won't be close enough to the solution to limit revisions because nobody has agreed on what that solution is.
posted by COD at 6:23 AM on March 12, 2018 [2 favorites]
posted by COD at 6:23 AM on March 12, 2018 [2 favorites]
I do this with my clients. One thing I've learned is that clients don't like doing written homework and since they're paying me they put it on a low priority and put in the least amount of effort possible. I've seen this enough times that I really can't blame clients; they're busy people.
What I do instead is set up a phone call with screen sharing and let them walk through what I've built and talk out loud. We'll have multiple calls if there are multiple stakeholders. It's less work for them because they don't have to craft a written response and it's better for me because the feedback usually has a lot more depth. I usually have an additional engineer on hand and record the call so we can review it later. It takes time, but usually much less time than email back-and-forth.
posted by Alison at 6:46 AM on March 12, 2018 [12 favorites]
What I do instead is set up a phone call with screen sharing and let them walk through what I've built and talk out loud. We'll have multiple calls if there are multiple stakeholders. It's less work for them because they don't have to craft a written response and it's better for me because the feedback usually has a lot more depth. I usually have an additional engineer on hand and record the call so we can review it later. It takes time, but usually much less time than email back-and-forth.
posted by Alison at 6:46 AM on March 12, 2018 [12 favorites]
> You need to lie. I mean, you need to build some elasticity into your deadlines. If I need something in two weeks, I tell people I need it in one week. They'll still get it to me after the two-week deadline, but they'll be merely late, not catastrophically late.
This is what scrum's supposed to obviate. You can be honest with your client if you can make accurate predictions. You can make accurate predictions if WIP doesn't get messed about with. Just don't schedule the work until after it's signed off.
posted by Leon at 6:49 AM on March 12, 2018
This is what scrum's supposed to obviate. You can be honest with your client if you can make accurate predictions. You can make accurate predictions if WIP doesn't get messed about with. Just don't schedule the work until after it's signed off.
posted by Leon at 6:49 AM on March 12, 2018
I don't have time to read all these responses right now, so sorry if this has been said --
We roll revisions into the next round of work. That means that the client never sees a deliverable that's *only* got their revisions until the very final delivery of the project. When we get to that point, we couch it this way: "Here is your final build. Did we tick everything off the list of final revisions you sent, and/or did we misunderstand anything?"
It sounds like you're delivering something, getting the revisions list, making changes, delivering the revisions, and only then are you moving on to the next phase. When we've done it this way, it's always been a disaster exactly like what you're describing.
posted by nosila at 8:34 AM on March 12, 2018 [4 favorites]
We roll revisions into the next round of work. That means that the client never sees a deliverable that's *only* got their revisions until the very final delivery of the project. When we get to that point, we couch it this way: "Here is your final build. Did we tick everything off the list of final revisions you sent, and/or did we misunderstand anything?"
It sounds like you're delivering something, getting the revisions list, making changes, delivering the revisions, and only then are you moving on to the next phase. When we've done it this way, it's always been a disaster exactly like what you're describing.
posted by nosila at 8:34 AM on March 12, 2018 [4 favorites]
p.s. We decide on a per-client basis whether a call/screenshare, in-person delivery, or email delivery will work best. Some clients are uber-organized and prefer to just send a tick list; some clients would prefer to just give us their off-the-cuff feedback on a call.
posted by nosila at 8:36 AM on March 12, 2018 [1 favorite]
posted by nosila at 8:36 AM on March 12, 2018 [1 favorite]
It sounds like your contract/workflow don't provide strong enough "if/then" consequences for the client. i.e. If a client ABC, then the client is responsible for XYZ. Consequences aren't punishment, just a way to encourage the client to consider how much they really want ABC & make sure you're being fairly compensated.
The way many firms handle excessive change orders or material changes to a project's scope is by requiring clients to sign off on each proof. Any revisions list must be provided in it's entirety before work on the next proof begins. Changes made after such work begins, or changes that affect the material scope of the project, can be incorporated into the project but are billed at an hourly rate rather than under a flat fee/initial quote. Going back multiple rounds of proofs to squeeze out more work in another direction definitely qualifies as a scope change.
The contract needs to spell this out and as account manager, part of your job is to communicate it kindly but firmly. Walking through the agreement at the start of the job and calling out this section of the agreement in particular plants the seed in the client's mind that you will be firm in upholding this policy. Watch the client's reaction so that you can plan ahead for trouble.
As you're working on the project, be proactive about checking in. Also, try to make non-electronic contact with the client every now and then as well if you're not already doing so. Sometimes a phone call or face-to-face meeting goes a really long way in heading off any issues that may be starting to simmer. You can get a feel for any uncertainty or weirdness that email just doesn't allow.
The great thing about having an if/then policy in the agreement is that you, as AD, can simply fall back on that agreement if there's trouble down the road. "Great, thanks for this list of changes! I can see why these are important to you and I want to make sure we incorporate all of them into your final files. Because these requests will trigger the XYZ policy in your agreement, I'll need to send over an invoice to cover the additional requests. What's the best email to send that to? Happy to get started as soon as we receive your remittance."
posted by muirne81 at 9:35 AM on March 12, 2018 [1 favorite]
The way many firms handle excessive change orders or material changes to a project's scope is by requiring clients to sign off on each proof. Any revisions list must be provided in it's entirety before work on the next proof begins. Changes made after such work begins, or changes that affect the material scope of the project, can be incorporated into the project but are billed at an hourly rate rather than under a flat fee/initial quote. Going back multiple rounds of proofs to squeeze out more work in another direction definitely qualifies as a scope change.
The contract needs to spell this out and as account manager, part of your job is to communicate it kindly but firmly. Walking through the agreement at the start of the job and calling out this section of the agreement in particular plants the seed in the client's mind that you will be firm in upholding this policy. Watch the client's reaction so that you can plan ahead for trouble.
As you're working on the project, be proactive about checking in. Also, try to make non-electronic contact with the client every now and then as well if you're not already doing so. Sometimes a phone call or face-to-face meeting goes a really long way in heading off any issues that may be starting to simmer. You can get a feel for any uncertainty or weirdness that email just doesn't allow.
The great thing about having an if/then policy in the agreement is that you, as AD, can simply fall back on that agreement if there's trouble down the road. "Great, thanks for this list of changes! I can see why these are important to you and I want to make sure we incorporate all of them into your final files. Because these requests will trigger the XYZ policy in your agreement, I'll need to send over an invoice to cover the additional requests. What's the best email to send that to? Happy to get started as soon as we receive your remittance."
posted by muirne81 at 9:35 AM on March 12, 2018 [1 favorite]
Response by poster: What do you do when the feedback clients are giving is totally valid, logical feedback but it's happening outside of their allotted hours and neither they nor I understand why their feedback has to qualify as a change request and/or we have to bill more hours?
What about when you just *know* a project has been underscoped and you are upfront with a client about how they will need more hours but you can't 100% explain why other than to privately think to yourself, "client, you are high maintenance,"?
Can you tell I am miserable right now because I am having multiple clients tell me these things in the past 3 hours and I am at the cry somewhere private stage of coping
posted by Hermione Granger at 12:05 PM on March 12, 2018
What about when you just *know* a project has been underscoped and you are upfront with a client about how they will need more hours but you can't 100% explain why other than to privately think to yourself, "client, you are high maintenance,"?
Can you tell I am miserable right now because I am having multiple clients tell me these things in the past 3 hours and I am at the cry somewhere private stage of coping
posted by Hermione Granger at 12:05 PM on March 12, 2018
Go back to your SOW. Are there two rounds of revision specified in the SOW? If so, then additional rounds are out of scope. You're not being mean (or NOT gentle) when you remind people about scope.
So, #1, stick to your scope. Make sure that the client knows where you are in the process at all times so that they understand, they have two rounds of revision and this is round 2. Any further requested revisions after this feedback is received will be ADDITIONAL SCOPE.
#2, the turnaround times are really tough here. I don't think you can expect to get complete feedback in those time frames. I'd revise my turnaround times so that they have longer to work on feedback. You're going to get piecemeal feedback like this when your clients have not had enough time to socialize the designs throughout their org.
posted by Medieval Maven at 12:09 PM on March 12, 2018 [2 favorites]
So, #1, stick to your scope. Make sure that the client knows where you are in the process at all times so that they understand, they have two rounds of revision and this is round 2. Any further requested revisions after this feedback is received will be ADDITIONAL SCOPE.
#2, the turnaround times are really tough here. I don't think you can expect to get complete feedback in those time frames. I'd revise my turnaround times so that they have longer to work on feedback. You're going to get piecemeal feedback like this when your clients have not had enough time to socialize the designs throughout their org.
posted by Medieval Maven at 12:09 PM on March 12, 2018 [2 favorites]
What do you do when the feedback clients are giving is totally valid, logical feedback but it's happening outside of their allotted hours and neither they nor I understand why their feedback has to qualify as a change request and/or we have to bill more hours?
A lot of this is the 48 hour timeframe. For a design company, approving designs is core business. For a client, they have a core business they are running and then they have to approve something they may or may not feel comfortable with, not to mention run past key people who are also involved in core business. At most orgs I've worked with, we would need closer to a week. And that weirdly goes double for smaller businesses because people's roles are so all-encompassing.
Do you have the power to halt work while waiting for feedback? In that case, make it clear to the client that this is final non-additional-hours feedback and ask them not to send it until it is complete, then hold up production until the feedback is back.
I was on a project that was fairly doomed for a wide variety of reasons, but one way that the Agile/Scrum process continued to make it worse was that very tight feedback cycle. We would get a feature set on Tuesday and have until Thursday morning to gather feedback before (the idea was) it would be finished off Thursday + Friday.
The issue with that cycle was that it really, really assumed that as a client, we would just have minor changes. But the requirements gathering/user stories part was not robust enough. So we just ended up in unhappy places where the dev team was sort of like PLS SIGN OFF 'K? and we were like NO CAN DO.
Sorry to rant here but for me, this is where there's a huge difference in project methodology designed for an in-house iterative project where features are going to be released incrementally all the time, but everyone is on the same page about what the core product is, and projects where there's an external client with a Final Payment coming along. I feel like you are getting caught in the system as I was on the client end last year. Hang in there.
posted by warriorqueen at 12:59 PM on March 12, 2018 [5 favorites]
A lot of this is the 48 hour timeframe. For a design company, approving designs is core business. For a client, they have a core business they are running and then they have to approve something they may or may not feel comfortable with, not to mention run past key people who are also involved in core business. At most orgs I've worked with, we would need closer to a week. And that weirdly goes double for smaller businesses because people's roles are so all-encompassing.
Do you have the power to halt work while waiting for feedback? In that case, make it clear to the client that this is final non-additional-hours feedback and ask them not to send it until it is complete, then hold up production until the feedback is back.
I was on a project that was fairly doomed for a wide variety of reasons, but one way that the Agile/Scrum process continued to make it worse was that very tight feedback cycle. We would get a feature set on Tuesday and have until Thursday morning to gather feedback before (the idea was) it would be finished off Thursday + Friday.
The issue with that cycle was that it really, really assumed that as a client, we would just have minor changes. But the requirements gathering/user stories part was not robust enough. So we just ended up in unhappy places where the dev team was sort of like PLS SIGN OFF 'K? and we were like NO CAN DO.
Sorry to rant here but for me, this is where there's a huge difference in project methodology designed for an in-house iterative project where features are going to be released incrementally all the time, but everyone is on the same page about what the core product is, and projects where there's an external client with a Final Payment coming along. I feel like you are getting caught in the system as I was on the client end last year. Hang in there.
posted by warriorqueen at 12:59 PM on March 12, 2018 [5 favorites]
Agree with the others. Your 48/24 timeframes are the sources of the problem. The short window makes the client react with feedback too quickly to have had a reasonable chance to evaluate it completely. This is why you're getting more feedback after the 48/28 deadlines. They've had more time to evaluate and recognize issues that weren't immediately apparent due to them having to hustle through review in order to meet your deadlines.
posted by Thorzdad at 1:22 PM on March 12, 2018 [4 favorites]
posted by Thorzdad at 1:22 PM on March 12, 2018 [4 favorites]
Just had a thought I wanted to add: are you running retrospectives? That's where all this stuff should be shaken out and fixed.
posted by Leon at 8:19 AM on March 13, 2018 [1 favorite]
posted by Leon at 8:19 AM on March 13, 2018 [1 favorite]
Response by poster: Thank you for all your input.
I agree that the 48/24 rule imposed on me and my clients is the issue. (Along with the fact that my design hours are always shortchanged to fit someone's budget.) This is endemic and even though I bring this up in every retrospective, nothing changes. I will have to keep trying to shoe horn hours in and make it work while I look for other options.
posted by Hermione Granger at 8:33 AM on March 14, 2018
I agree that the 48/24 rule imposed on me and my clients is the issue. (Along with the fact that my design hours are always shortchanged to fit someone's budget.) This is endemic and even though I bring this up in every retrospective, nothing changes. I will have to keep trying to shoe horn hours in and make it work while I look for other options.
posted by Hermione Granger at 8:33 AM on March 14, 2018
This thread is closed to new comments.
posted by Hermione Granger at 11:58 PM on March 11, 2018