Development Estimate - How to dig deeper?


I have engaged a very good Indian company to build a marketplace. A small scale micro ebay you can say.

Development is underway and I asked for a feature that is outside the original scope. The hours that they quoted me looks way out of whack, particularly in a world where we have frameworks, code snippets and sub-routines. I need some advice on how I can dig deeper into that estimate. When I asked for a breakdown, they gave me something like (UI Design, UI Coding, Report etc) all adding up to the original estimate.

The feature is quite simple in my view. For members to list products for sale, they need to buy credits. So, the feature should have the following

  • a screen where people can buy credits.
  • when they list a product, it should automatically subtract a credit.
  • it shows the credit bought/used/remaining in a shop admin screen
  • it shows an overall summary to the super-admin

I need your help in two aspects

  1. What would be your rough estimate, in hours, for a feature like that? Ranges should work as well.
  2. How do I go about double clicking on this estimate. What would I ask them?

Thanks for your help.

Without having a background in how the existing site is being developed, it’s hard to gauge how much time it’ll take. Plus, there’s the matter of scope and how they earned the business.

  1. They may have given you a discount for the initial workload to get the business, and what you are now seeing is the maintenance/upgrade costs, which very well may be higher. In fact, maintenance is often where contracted companies make their money.
  2. You see this as a single feature, credits. What they (and I see) is a whole new series of features:[LIST=1]
  3. The ability to buy credits, which may require a different method through whomever your CC processor is (physical products vs non-physical products can be treated differently). Not necessarily true, but the possibility exists.
  4. The ability to use credits on other purchase
  5. Ability to track credit balance
  6. Administration of credit balance by admins (which also means refunds).
  7. A different way of paying for listings - if it was a money based transaction to get listings, then having to convert that over to credits instead is an entire new method of business which may not have been planned for.

[/LIST]So where you see one feature, I see at least four new UI elements, the time to design, code and support those UI elements, plus DB development time. Plus there might be a time factor involved. If they’ve got a hard deadline looming in the contract, they might be hedging their bets on cost overruns, additional scope creep, etc.

Plus, to be honest, they might be imposing a higher premium to discourage the additional work during the initial development phase. I’ve worked for companies that have done that - hit the client with a sticker shock price tag to prevent additional scope creep - only those features they really want are what they’re willing to pay for it.

If I had a dollar for every time I’ve heard a client state that ‘it’ll be a simple change’, when in fact it requires complicated changes of code…

Your view that it’ll be simple is presumptuous, unless you are a coder yourself you have absolutely no idea what needs to be done to create the required new functionality (if you were a coder you’d likely not be paying somebody else). They have supplied a breakdown of where the time is being spent, unless you supply more info about that it’s hard to say, but the fact they’ve provided a breakdown shows they’ve priced it with justification rather than picking a sum out of the air.

If the original system is based on an off the shelf product, then changes such as this can seem expensive in comparison to what you’ve received for your original fee, i.e some modifications and adding a skin to masses of existing functionality, versus spending time to discover where to alter the code and database, and then new code to be written and integrated.

If the entire system is original bespoke code then it should be easier to alter, but in most cases of cheap outsourcing the economics point towards implementing an existing product.

I live by this rule: when someone who is not in the industry refers to something as simple or explains it following the word “just” its going to be the exact opposite. That is what I have come to learn.

we would just…

  • Oh god, you have no idea what you want.

It should be a simple…

  • It never is.

DaveMaxwell hit the nail on the head. What you refer to simple I refer to as countless hours of programming, design and likely changes to an existing architecture that was never meant to support the feature.

When I am working on something I usually do the following:

How long I think it will take + 50% of that = How long it will really take

When it’s a client I typically double their estimate. It’s a simple rule that is typically always correct.