-
Notifications
You must be signed in to change notification settings - Fork 536
On Projects Estimates
Our agency never worked on large scale fixed-cost projects... However, recently we start getting a lot of requests to submit ballpark estimates for some medium or large projects and we want to summarize our view and experience on that here.
Of course, we did some small tasks/stores with a fixed scope where estimates usually over the range of hours or a few days of work maximum. We have built (and still building) many of extremely large scale projects in the past (millions of lines of code, large teams), but in all such cases it was well-financed projects, where the main question was not how much it will cost to build the whole project, but more like: "let's start building it iteratively and optimize costs on the way" (e.g. Agile & Lean).
Of course, we don't want to go into well-known debates about Agile vs Waterfall methodology here. What we want instead is to explain why our agency still can't start on a fixed-cost project. It's not that we don't want it! In most cases, it's because our customers are not ready for that or because we feel that the way customers want it to be working is impossible in practice or not fair. Let's explore the reasons below.
We don't have own examples of successful execution of large fixed-price projects (yet). It's also extremely hard to found any such examples on the internet. Hey, even NASA makes lots of mistakes in estimates and in many cases fails to deliver on time or on a budget! If NASA can't, why we should? They have lots of planning, best scientists and they still fail... Plus lots (really like lots) of projects which get to our agency are actually results of FAILURE by some other agency to execute some project on fixed cost contract terms. We clearly see how big a disaster such projects become for one or both sides of the business and we don't want (can't) afford to do the same mistakes...
If there is an error in the estimates one of the following will happen:
- if an agency underestimates the work, then an agency employee(s) will work for free just to finish the contract (and it's stupid, push business down and have a large negative effect on employees' morale) or even worse an agency will try to compromise on quality to increase delivery speed.
- if an agency overestimates the work, then the customer will pay more than it was possible if they do project on time and materials contract.
Of course, such considerations will push the agency to always increase the size of the proposal cost up to the level till the customer accept it, just to be on the safe side and get more revenue with fewer risks.
In any case, all of those scenarios look not fair to us for one of the sides: it's the agency who will work for free (and be a fool) OR it's the client who will overpay (and be a fool).
We believe that in order to estimate something well, you need to have very good planning (1) OR you need to have experience building exactly the same thing with exactly the same team in the past (2).
The first (1) usually did not happen because customers don't want to pay for such planning before they select an agency or even after they select it for a given project. The customer interest is always to get an estimate without paying and till today we found only a few customers who agree to pay us per hour to do the required research and provide estimates for the whole project (in all cases it was small scale projects... probably because otherwise the research phase will be weeks, not hours or days).
The second (2) is not realistic because almost all software projects are different and even if on the surface projects could look very similar when you Digg inside it becomes clear that it's small changes that lead to huge differences in the timeline and associated costs.
So how can we make it work, we - agency AND client, together:
- the client should do required research and document project requirements/features/user stories well enough before estimation start
- select one agency and pay per hour to help with research and get estimates and the client can make it clear that it's not decided who will execute the whole project later. That will allow the agency to provide real, not fake estimates and still get paid for all that research efforts.
For now, we accept only per hour based projects, unless it's something very simple and we did exactly the same before. We say no to some clients that way, but we stay on the safe side - we work efficiently and bill exactly for how many hours it takes to finish given project, not how much we think it will take (read: lots of $$$) or how much $ clients want to pay for it (read: "made me a clone of Facebook for $100 please").
That proves to be a very successful strategy for us. Our agency https://upwork.com/ag/ever grows to more than 25 developers by now and growth continues exponentially. Think we were able to do it exactly because we say NO to all prospects who describe the project in few sentences ("I need a social network where it's possible to share images, videos, comments, blog posts, have groups, have apps platform, have news feed, scale to 1 bil users, i.e. like fb.com") and want "fixed cost estimate" from 100s of stupid agencies before they maybe select 1 to execute. By saying NO to such clients we were able to focus on great clients who understand what it means to build great software and great products OR who open to learning that from us and, of course, who ready to trust us.