Disagreement on software time estimation

Question

How do you deal with a client who has different time estimates for the software product than yours?

I am going to describe a scenario that is not mine, but that captures broadly the same problem. I am working as a subcontractor to a large company that has a programming department. The software project we are working on is in an area that the department believe they have a handle on, but because their expertise and mine are very different we tend to get different results.

Example: At the start of the project I suggested one way of development which they rubbished as being unrealistically difficult and suggested integrating a different framework (one they are familiar with) with the programming language we are using (Python) to get more or less the same result.

• Their estimate for this integration: less than a week (they haven't done the integration before).
• My estimate for the integration: above two weeks.
• Using my suggested way to get the result needed (including using matplotlib among other libraries used elsewhere within the project): 45 minutes. This is not an estimate, the bit was actually finished in 45 minutes.

Example: for the software to be integrated with their internal system, they needed to provide a web service for me to use. They provided a broken one, though it does work with their internal tool (doesn't work with .Net or Java mainstream packages among other options). They maintain that it is my fault that the integration has taken longer than the time estimated.

The problem is not that they don't know, the problem is that they have enough knowledge about programming to be dangerous (in my opinion). Is there some guidelines for how to deal with this type of situation? A way for expectation management? Or may be I shouldn't get involved in such projects from the start and in this case what are the telltale signs?

Answer 1

If a client isn't happy with a time estimate, don't do the work. If they think they can do it better or faster, tell them to go ahead.

The one thing I never allow is for my estimates to be modified. That's something that caught me out early on in my career but we learn our lessons.

If clients were so good at doing the work, they wouldn't be hiring me. I'd simply point out that they hired me for my expertise so why are they disregarding that expertise. Of course, if they were to allow the scope of the project to change (i.e., less work), that would be another matter, and one up for discussion.

If you didn't lock in exactly what they were meant to provide as part of the deal, then it's a "he says, she says" situation and, unfortunately, the customer controls the purse strings. However, often, the greatest power you can have is the ability to just walk away.

No-one says you have to do the job.

---

Of course, all that advice above is worth every cent you paid for it :-)

I don't know your specific circumstances.

Answer 2

Or may be I shouldn't get involved in such projects from the start and in this case what are the telltale signs?

My answer for sure. If you can avoid those projects, do it.

Some signs : people thinking they know how to do things when you can guess they can't. The "oh no let's not use this perfectly suitable tool because I don't know it" is a major indicator that the person is technically challenged.