Should we be completely honest to our clients about a time frame for a project?

Question

I have been having this experience for sometime now, when a client needs a software product and contacts me, the client usually wants to know the time frame on which this product will be accomplished. Usually as a software developer I might not be able to fully determine how long it will take me to finish the job since I may encounter an error that may take me weeks (sometimes months) to solve.

If I tell the client the expected time frame based on my analysis i.e. no matter how bad it gets, I should be able to finish the job in lets say 6 months maximum (for example). My client usually says NO! six months is too long, I need it urgently, maximum should be one month. If I refuse to accept the time frame given by the client he may give the contract to another developer who accepts the short time frame of the client and yet does not execute the job in time.

On the other hand, if I accept the short time frame of the client and get the contract (knowing fully well that it will be impossible to finish it in time), I will only succeed in getting the contract and then later come up with excuses as to why the job is not completed in time. This now seems to be a norm, but deep down I feel I am learning how to be dishonest in order to get contracts. So is it a bad thing or is it just a business strategy?

Answer 1

You should reason with these types of clients in situations like this.

Instead of giving a single time-frame from start to finish, explain to them that you can have a somewhat production-ready tool in a span of one month.

If you explain to them (using like a piece of paper) the algorithm or steps involved in producing a software product, this will make them understand what software development is. Knowing how people generally may be towards this, you need to highlight the important parts of the production process.

For example:

• Explaining how design requires some time to plan, to ensure that the site is both beautiful and drives more sales/leads for the client
• Explain the aspect of security, as this will matter to site-users, so clients should ensure that their sites are secure (in situations where this is needed)
• Explain about SEO, etc.

I don't think you should charge a fee for explaining this process, unless you can get it done within the allotted time that they're paying for.

The gist of what I'm trying to say is that you need to explain to clients in a way that they can see benefits directly to themselves.

If I ran (for example) a shoe retailing business, the things I'd like to hear most from a software developer is how their work will benefit my business, which is what you need to do.

You can lastly, also explain to them why it is impossible to achieve a good final product in a span of one month.

Then let them decide, based on all the facts you've given, if it is acceptable to have a half-baked product in one month instead of a better solution in a little longer time (also, 6 months is a very long time. You should think of trying to reduce this time to a maximum of 2-3 months, unless you deliver a rolling-product in which a working version is available soon, but you keep updating it until it is production-ready).

Answer 2

• Do not lie. It will only bite you in the end. You will feel much happier doing contracts that are reasonably framed where you aren't fighting the client and your dishonest estimates all the way. After all, the real work happens after the estimates. You'll lose some contracts at first to lowballers, but those customers will come to you after those lowballers overrun their estimates. You'll build up trust and good customers that way.
• Do not try to guesstimate the "absolute worst case" as you seem to suggest you do in the question. The absolute worst case is unpredictable - instead estimate something like "75% chance of finishing in X time" - 100% is impossible - 95% will take much longer and is much less likely than 75%. Doing it like this means that 1 out of 4 projects will have an overrun - that still means 3 out of 4 projects will come in on-time with happy clients, and that fourth one probably has very good explanations why it's late.
• Get "Software Estimation: Demystifying the Black Art" - you'll learn a lot, even if it's only to confirm that nobody really knows :P
• Be very, very careful with clients that come to you with an "urgent" project. That "urgent" project is already late. Success is unlikely because there are two much more likely outcomes that aren't "external person saves the day": the further lateness of the project caused by your development time will be redirected at you (i.e. in their eyes it will become your fault they are late), OR during the time it takes you to develop the project they will find an alternative solution and you'll have trouble getting paid for your work because they don't need it anymore.

Answer 3

Based on the scenario you gave, I question whether the client is being honest with you or the other company. You say it takes six months, but they want it in one. There are excuses for the incomplete project, but the client pays anyway or now they're able to delay it? Something doesn't add up or the client has a loose interpretation of what urgent means.

Both sides seem to be playing a game. Developers pad their estimates and clients arbitrarily set shorter due dates because they know developers exagerate how long things take to build. We haven't even gotten to scope creep yet.

Personally, I avoid dealing with clients in this way. A huge discrepancy in project estimates means something is very wrong. Take the project into smaller parts and give estimates for those. This may give the client a better idea of what is required and the amount of time to do them properly. These can be adjusted and many difficult to estimate projects need some initial trail and error. Your competition may not be dishonest, but unaware of what it takes or maybe they're throwing more devs at the problem, have experience in this area along with some boiler-plate/prefabricated code already in place.