Way off the ballpark! – 10 reasons why you cannot compare quotes for your outsourcing project

Image from Flickr / TxBlueEyedGal

Image from Flickr / TxBlueEyedGal

If vendors in app development were like products on a shelf in the supermarket, they wouldn’t all be priced the same. Right from what they offer to the kind of quality they promise, from the expertise and experience they bring to the table, impact pricing.

Estimating what you are expected to pay is a pivotal part in your decision making process when it comes to choosing an appropriate vendor. As important as it is to understand that estimates can and do vary, it is important to understand the rationale behind the variation. Here are ten reasons why estimates vary dramatically between two vendors, when you seek quotes for outsourcing:

  1. The Sales approach (let’s quote as less as required) vs. Delivery approach (let’s quote as realistically as possible): The focal points of every vendor’s business endeavour underlies the way they perceive a task. A sales approach is oriented towards bringing in more customers, and the easiest way to do that is to promise the best at the least cost. The idea they labour under is driven by their motivation to raise the number of customers, as opposed to focusing on the demands of the task. Usually, such vendors operate from an understanding that there are many needs, but not enough budgets to make those needs a reality.

On the other hand, a delivery approach looks at the task and quotes an estimate as it sees fit for the task and its demands. A more realistic and pragmatic point of view, the delivery approach is a what-you-see-is-what-you-get option. They perceive a task, understand the challenges they are working with, and identify themselves with what they want to deliver, rather than focusing on widening its customer base. Typically, the latter is a wiser choice if you have a rigid budget and would rather not wing it.

  1. Non-tech person estimating (templated know-how) vs. Tech guy estimating (burden of knowledge): When a non technical person estimates for a software development project, s/he relies more on thumb rules or experience of seeing things done before. Everything s/he estimates for has to fit the template of what they’ve experienced before.

On the other hand, a technical person estimating for software development is burdened by the curse of knowledge. S/he knows something too well that alternate or out-of-the-box perspectives won’t occur.

  1. Guy who has done an app like it before vs. Guy who has not done it before: It is inevitable that many occasions might see an overlap between a new idea and an already charted path. On occasion, it is possible that a vendor may have drawn up a similar app earlier: in the event that the new idea is not a mere repetition and the vendor agrees to work on it, he will be able to offer an estimate after a precedential understanding of what went into the process of developing the app the last time. The estimate is usually sounder when someone who has had experience, shares it, after understanding where there maybe increments, and what kinds of contingency plans need to be in place to translate it into reality.
  2. Has code to reuse vs. Has to start from scratch (may not tell you they are re-using but factors it into estimate): When there is a vantage point of prior experience, or perhaps a preparatory standpoint to begin development from, a vendor may already have had the suitable prerequisite in place in the form of a code. While not many may be so frank as to say so, and may factor in a cost into the estimate, a vendor who has no code in place may wind up charging you more to develop it from scratch.
  3. Mis-understanding of scope: The scope of an app and the functionality it aims to achieve within that scope play a significant role in determining the estimate. While most work proceeds only on clarity and proper communication between the vendor and the customer, in the event of a misunderstanding – over estimation or an under estimation, as it may be, the estimates may vary. This usually needs a little playing-by-the-ear, because it is difficult to assess what rationale goes into the evaluation of an estimate – and the misunderstanding of a scope may not always be easy to glean.
  4. Law of averages: The math that underlies estimates is that they generally tend to gravitate towards a number that the estimator is either used to or is comfortable with. Regardless of the nature of each project, if the prior ones took a certain number of hours, it is likely that the next one will also follow suit – with an appropriate costing.
  5. Overcompensating vs. Undercompensating for uncertain portions: There are always grey areas when it comes to developing an app. What works and does not work can remain an idea in a vacuum until it is worked upon, and as the effort builds towards bringing it into fruition, there is every chance that the obscurity will become clearer either for the better, or for the worse. In preparing for such contingencies, estimates are drawn with a fair amount of conservativeness. Experience can help one assess exactly what amount of contingency should be in place, but sometimes, tipping the balance by overcompensating or under-compensating can shift the estimates accordingly.
  6. Estimating based on who’ll be on the job: Expertise that goes into the development makes a difference in the estimation for the task. A junior who has less experience and perhaps less exposure may have a longer work time as opposed to someone who has been in the field, soaking up experience and expertise and bringing it to the table. It is hard to say which can cost more than the other, given that there is a general possibility that the time multiplied by the per unit charge can still amount to a similar figure.
  7. Assuming and buffering for scope creep: The scope creep, or the uncontrolled changes or continuous growth in a project’s scope, should also be factored into an estimate. As the development proceeds, different possibilities become clearer, and the scope of the project may have to, or may discretionarily be changed. Assumption of this possibility and building appropriate buffer times can change the estimate.
  8. Mis-reading of the context: The context surrounding a given development requirement is a very vital element in determining the estimates in a project. While the vendor might look at it as an estimate for the prototype, the customer might be on another tangent, expecting a prime time launch and / or scalability. The estimates will vary accordingly: and may lead to a difference of opinion of the miscommunication continues to thrive.

Now, think of a factor of 5% variation on one direction for all these 10 points. That’s a 100% variation if the other vendor deviates by 5% on all the points in the other direction. That’s why you get estimates that don’t concur at all.

While we’ve shared just ten potential parameters that can cause the difference in estimates, you might have experienced more! Do drop a line in the comments with some of your own!

Building an app? Tell us about your project

We'll connect you with the right team for your project, for free!