3 ms·

On the other side of this, I've had clients that can't provide needed information, want me to wait for some other contracted individual to finish part of the jo

by delinka 14y ago

On the other side of this, I've had clients that can't provide needed information, want me to wait for some other contracted individual to finish part of the job or provide information, then can't understand (after the two week project has run to six weeks because of their own delays) why I can't now give them 100% of my attention and blame me for the delays. Now that they've pushed this whole thing so late that it's interfering with other projects, or plans that existed prior to taking Delay Client's project. They had me three weeks ago and chose not to utilize me. Why's that my fault? (not directed at parent - directed at Delay Client)

jordanb 14y ago
I've been contracting for several years and I think perhaps enough time to emphasize with my clients even when they can't tell me what they want, so permit me to offer the other other side. People can't provide a spec because they don't really understand what they want. Sure. And certainly, part of that in many projects is poor communication between stakeholders and a refusal to make decisions. But especially for public facing sites it's often difficult to impossible to figure out what behaviors or workflows are effective and which are not. Prototypes have to be built, put before the public, A/B tested, etc. This process is time consuming and often results in fundamental changes to the spec that can affect large amounts of code. A spec can't really be written, handed over, implemented, signed off on. So communication and flexibility really has to be built in to the relationship between the stakeholders and the developers. The thing that I found is really essential to a good relationship with clients is instant messaging. All developers and stakeholders need to work regular hours and be available on IM. Projects where everyone is on IM, in my experience, go much more smoothly than projects where IM isn't used or is only used by part of the team. The real magic behind IM is that it's a communication method that doesn't necessarily demand immediate attention when a message is sent, so it doesn't interfere with a developer's day the way the phone does. It just changes the status icon color and allows you to respond when you get to a stopping point. But then when you do respond it seamlessly turns into a two way conversation. I've gotten to the point where "is everyone on IM?" is my principal litmus test for deciding if a project is going to be a pleasant one to work on or not. This is far more important than pretty much anything else, including the quality of the initial spec.
ErrantX 14y ago
You have to deal with that sort of situation proactively. Ring them up and explain their delays have pushed the project into a period where you have other commitments. Ask how long it will take them to resolve their delays etc. and offer to reschedule the contracted time after that. If they screw you around later politely decline their work. If you don't respond to the blame they are giving you then they will continue to heap it on you. And that is not a working relationship.

by delinka 14y ago

jordanb 14y ago

I've been contracting for several years and I think perhaps enough time to emphasize with my clients even when they can't tell me what they want, so permit me to offer the other other side. People can't provide a spec because they don't really understand what they want. Sure. And certainly, part of that in many projects is poor communication between stakeholders and a refusal to make decisions. But especially for public facing sites it's often difficult to impossible to figure out what behaviors or workflows are effective and which are not. Prototypes have to be built, put before the public, A/B tested, etc. This process is time consuming and often results in fundamental changes to the spec that can affect large amounts of code. A spec can't really be written, handed over, implemented, signed off on. So communication and flexibility really has to be built in to the relationship between the stakeholders and the developers. The thing that I found is really essential to a good relationship with clients is instant messaging. All developers and stakeholders need to work regular hours and be available on IM. Projects where everyone is on IM, in my experience, go much more smoothly than projects where IM isn't used or is only used by part of the team. The real magic behind IM is that it's a communication method that doesn't necessarily demand immediate attention when a message is sent, so it doesn't interfere with a developer's day the way the phone does. It just changes the status icon color and allows you to respond when you get to a stopping point. But then when you do respond it seamlessly turns into a two way conversation. I've gotten to the point where "is everyone on IM?" is my principal litmus test for deciding if a project is going to be a pleasant one to work on or not. This is far more important than pretty much anything else, including the quality of the initial spec.

ErrantX 14y ago

You have to deal with that sort of situation proactively. Ring them up and explain their delays have pushed the project into a period where you have other commitments. Ask how long it will take them to resolve their delays etc. and offer to reschedule the contracted time after that. If they screw you around later politely decline their work. If you don't respond to the blame they are giving you then they will continue to heap it on you. And that is not a working relationship.