Skip to content

Six ways to be a better client for your developer – Point 4

Point 1 – Understand that you alone know the problem
Point 2 – Understand that they probably know the best solution
Point 3 – Don’t be sold a solution

Project 365 #299: 261010 The Sands Of TimeDear Reader,

Are you a good client for your freelance programmer? I hear both sides of this conversation from different friends. Freelancers complain that clients and potential clients just don’t have a clue. They feel the need to figure out what the client needs instead of listening to what the client wants. Clients complain that no matter how much they explain what they want, the developer is rarely listening and is usually just waiting to speak.

For the purposes of this article series, I will use the word developer when I mean freelance developer, internal development team or external development company. Most of these points apply to all three.

Don’t set a deadline, set milestones

Regardless of whether it is a large or small project, don’t set one final deadline, set regular milestones. If it’s a week-long project, figure out what will be delivered each day and set daily milestones. Larger projects will have them spaced out more but either way, make sure that you have them at regular intervals and that all major deliverables are assigned a milestone.

A single deadline won’t let you know if the project is on track. Regular milestones will help you keep a handle on the project and where it stands. With regular milestones, if the deadline has to slip, you know it sooner rather than later.

Make sure your developer is reporting back to you on a regular basis. At the very least you should have a status meeting at each milestone to make sure it was hit. For larger projects you will need meetings between the milestones to make sure the project stays on track.

Programming is not an exact science. Deadlines and milestones will slip and you need to be flexible to the extent that you can. However a project that has gone off the rails and is regularly pushing back is a sign that the developer did not understand the problem properly and did not estimate it correctly.

Until next time,
I <3 |<