Thanks for sharing your thoughts on the matter. I’ve just started a new web design company. Aside from having two great clients I’ve also done freelance site programming for another designer in town. Not only did they refuse to work with anything other than simple table based layouts, but they also removed my ‘Site programming by’ line from the job I had just completed for them. Of course I had a look at the code, and low and behold, it was mine line-for-line. Another red flag was that this person only wanted to communicate via email. It’s very hard to effectively communicate that way and especially so when trying to review a project. As a result after just two jobs I decided to look for work elsewhere. In the end it simply wasn’t worth the headache and aggravation.
dealing with a client now that didn’t have a clear visionof what she wanted, didn’t fill out the questionaires, brought in her partner that didn’t like the first draft, changed several templates halfway through, and expects her site to be done in one month.
Sadly, even when you have been in the selling game for awhile (I’m in for 5 years), you find that with all your best efforts and methodology in place, a bad seed falls through the cracks and becomes the thorn in your side that you compare others to for some time to come. I’ve learned that sometimes it just isn’t worth it to continue a bad relationship with a client. While I have not had to walk away during a redesign/design project, there are a few that I would not work with again. The drain on time, resources, and our mental health is not worth it in the long run.
…and I think a pre-project questionnaire is a good idea. But I have to say that I think it should be delivered in person so that you can adequately explore any answers that surprise you. I also think that it’s a mistake to make this pre-project exploration too problem-focused. In my experience, many, many problems with web development projects come from problem areas that just would not be unearthed from a project-focussed review. In this article, I make a list of six areas that I think it’s worth exploring with a client before the start of a project – “Six things you really need to know about your customer”:http://www.agile-lab.co.uk/2009/06/six-things-you-really-need-to-know.html .
Small clients tend to be more flexible on accepting a “no” from the Project Manager for the sole reason is that usually they’re not sure of what they want, and they’re looking for advice.
On the other hand, large clients (usually) have a pretty good idea of what they want, and asking for more things along the road is very normal as their internal requirements change. Although these “changes should be controlled”:http://www.pmhut.com/how-to-control-change-requests , failing to control change requests will result in a scope creep.
I have people asking me why it takes 6 months (sometimes longer) to complete a website. I tell them that this is normal, because I am usually awaiting client feedback on a proof or other information. This can take a day to a week for a client response to come in. The person I talk with usually understands.
We need to think about our projects as game-like situations. What do I have to bring in – so that I can deal with the challenges of the project? Do I need help, and if I do, does it makes sense to ask for advice and support, given the actual time and budget limitations? How do I need to prepare myself for it? A realistic evaluation of your own resources helps: it makes you understand if the benefits of getting involved in a project balance out the eventual investititon required from your side and your client’s. If there is a balance that you are both happy with, or – then Yes or “getting to Yes” is the best option.
Otherwise “No” should be the permanent or temporary resolution to it. In the end, we all need to figure out how and why we should contribute to or work on something, and “No” is part of that process too.
Could not agree more with the second point. You know when you’re reading something and you’re instantly reminded of a quote? “A camel is a horse designed by a committee” – which then led me to: “too many cooks spoil the broth”. I think most people would agree that the fewer the number of people who need to be involved in a project, the better.
38 Reader Comments
Back to the Articlecrazywebfoo
Thanks for sharing your thoughts on the matter. I’ve just started a new web design company. Aside from having two great clients I’ve also done freelance site programming for another designer in town. Not only did they refuse to work with anything other than simple table based layouts, but they also removed my ‘Site programming by’ line from the job I had just completed for them. Of course I had a look at the code, and low and behold, it was mine line-for-line. Another red flag was that this person only wanted to communicate via email. It’s very hard to effectively communicate that way and especially so when trying to review a project. As a result after just two jobs I decided to look for work elsewhere. In the end it simply wasn’t worth the headache and aggravation.
bsmbahamas
dealing with a client now that didn’t have a clear visionof what she wanted, didn’t fill out the questionaires, brought in her partner that didn’t like the first draft, changed several templates halfway through, and expects her site to be done in one month.
lot’s of lessons learned.
pamgreiner1
Well written and very true.
Sadly, even when you have been in the selling game for awhile (I’m in for 5 years), you find that with all your best efforts and methodology in place, a bad seed falls through the cracks and becomes the thorn in your side that you compare others to for some time to come. I’ve learned that sometimes it just isn’t worth it to continue a bad relationship with a client. While I have not had to walk away during a redesign/design project, there are a few that I would not work with again. The drain on time, resources, and our mental health is not worth it in the long run.
Thanks!
Mark_Stringer
…and I think a pre-project questionnaire is a good idea. But I have to say that I think it should be delivered in person so that you can adequately explore any answers that surprise you. I also think that it’s a mistake to make this pre-project exploration too problem-focused. In my experience, many, many problems with web development projects come from problem areas that just would not be unearthed from a project-focussed review. In this article, I make a list of six areas that I think it’s worth exploring with a client before the start of a project – “Six things you really need to know about your customer”:http://www.agile-lab.co.uk/2009/06/six-things-you-really-need-to-know.html .
projectmanagementhut
Small clients tend to be more flexible on accepting a “no” from the Project Manager for the sole reason is that usually they’re not sure of what they want, and they’re looking for advice.
On the other hand, large clients (usually) have a pretty good idea of what they want, and asking for more things along the road is very normal as their internal requirements change. Although these “changes should be controlled”:http://www.pmhut.com/how-to-control-change-requests , failing to control change requests will result in a scope creep.
adamant
I have people asking me why it takes 6 months (sometimes longer) to complete a website. I tell them that this is normal, because I am usually awaiting client feedback on a proof or other information. This can take a day to a week for a client response to come in. The person I talk with usually understands.
Catalina Butnaru
We need to think about our projects as game-like situations. What do I have to bring in – so that I can deal with the challenges of the project? Do I need help, and if I do, does it makes sense to ask for advice and support, given the actual time and budget limitations? How do I need to prepare myself for it? A realistic evaluation of your own resources helps: it makes you understand if the benefits of getting involved in a project balance out the eventual investititon required from your side and your client’s. If there is a balance that you are both happy with, or – then Yes or “getting to Yes” is the best option.
Otherwise “No” should be the permanent or temporary resolution to it. In the end, we all need to figure out how and why we should contribute to or work on something, and “No” is part of that process too.
thomasorourke
Could not agree more with the second point. You know when you’re reading something and you’re instantly reminded of a quote? “A camel is a horse designed by a committee” – which then led me to: “too many cooks spoil the broth”. I think most people would agree that the fewer the number of people who need to be involved in a project, the better.