One of the biggest pain points in contract work, for both sides of the aisle, is time and monetary estimates. On the client side of the work, it is hard to trust someone’s estimates especially when working with a new contractor. On the contractor end, it is always a long road of creating, explaining and detailing why a particular piece of work costs a certain amount.
Assuming you are working with a no-bs, highly trusted consultant, let me dive into two major ways an estimate can be structured. The first approach is to provide a detailed description of each task, technology, feature, etc. that is required for the project, break it down into to functional pieces and estimate the work down to hours. This approach gives us the benefit of a highly accurate estimate and brings the client more confidence in the description of the monetary value. On the opposite end, it takes quite a bit of time and communication between the two parties to put together – before any work on the project begins and before the consultant receives any compensation for the work.
When this approach is requested by the client, many consultant firms require compensation for the time it takes to communicate with the client and work out a proper requirements guide. However, for solo consultants, the request for compensation of this period is tough since many start-ups or individual clients simply do not understand the need for this phase whit the goal of simply getting to the estimate. I urge my clients, however, to go through this process as, for one, it is a good way to gauge your consultant on their knowledge, communication skills and thoroughness. Compensating your consultant for a start of a few hours will allow you to gauge the mesh of the working relationship. There is no requirement to get to the completion of this process if you are not meshing with your consultant. However, if you get to the end of the process you will end up with a detailed spec of what it will take to build your project that you can share with any other consultants in the future.
The other approach is to provide a rough estimate for the completion of the project, usually in chunks of $1k for small projects and $10k for medium to bigger ones. This of course takes much less time, but does not offer the client as much confidence as the first approach. There are no details to explain why the work will cost a certain amount and the amounts thrown around by different consultants could be drastically different.
It is important to interject here and chat about WHY these types of estimates are so drastically different. At first glance, when a client looks at such proposals they might come to think that a proposal which is much higher than others, or any proposals higher than the lowest, could be a scam and is just a way for a freelancer to get more funds than needed for the project. In the work that I have done, and in all cases where my colleagues have made estimates higher than others, never have I seen this to be the case. Most of the time, when dealing with highly esteemed web development shops and freelancers they provide higher estimates because they have much more experience working on similar projects and know what it would take to do the job. Lower estimates could be a sign of many things including: lower level of experience, desire to gain a client and the fact that the work could be outsourced oversees to lesser experienced teams.
To unpack these reasons, let’s take “lower level of experience” first. A client might decide that “hey, I know this guy has less experience, but at least I’ll get a working app out of it.” That might be your first thought, however be sure that you are ok with a hugely error prone app, grossly miss-estimated timeframes, a challenging level of communication both on the status of the progress and on the details of the features, unreadable code and code that has to be re-written before the project hits any real production clients. In most of these cases, you will end up paying much more when hiring a cheaper developer from the start due to the lack of understanding on the part of an junior developer what it would take to build the app and the fact that the application might need to be completely redone once new bugs continue to emerge and more experienced developers discover intertwined logic and highly inefficient.
The “desire to gain a client” and therefore offering a much lower estimate speaks to the deep lack of integrity on the part of the consultant. Many times such engagements end up costing much more than initially proposed as costs are added at each milestone and vaguely justified. This arrangement also has the huge potential of costing the client more than some of the higher estimates provided from credited freelancers. This further does a lot of damage to the industry for both freelancers and clients. It completely undermines the work that good freelancers do while providing accurate and honest estimates and puts a client in the position of mistrust of the accurate estimates due to the higher price. You will always have these poachers in any industry. The only thing for us honest consultants to do is to help educate our potential clients on the work needed to be done and why it is impossible to achieve great applications with the low estimates provided by such shady consultants.
The approach of “outsourcing oversees to lesser experienced teams” is a highly blown up version of the “lower level of experience” approach while adding the huge business disadvantage of not knowing any of the developers working on your application and the additional burden of differing cultures with differing styles of coding ethics. It adds the huge pain of lack of communication, not being able to speak directly to your developers, missed deadlines, spaghetti code.
Because of the difficulties that both approaches bring, many freelancer move towards simply working hourly. This, of course comes with it’s own set of problems, mainly the inability of the client to know how much a set of work will cost. To mitigate that problem many freelancers work out an agreement with the client on the cap of hours a given task will take.
The approach I have found to work the best is a mix of the ones mentioned above.
To begin with, I create a high level architecture spec including: the language best suited for the nature of the project, best hosting options, security needs, API integrations, etc. As my proposal, I do provide an invisioned estimate for the project, however this is aimed for my client to have an idea on the possible price. Any contracts signed between me and my clients from the beginning of the engagements deal with pre-determined mislestones which range between a few days and two weeks. Each contract only deals with the next milestone ahead and details all the necessary components and estimates for that milestone. My clients do not sign off on a full monetary estimate of the project, instead they sign off on the detailed estimate of the next milestone.
This approach has many benefits to it. First, it gives both parties the ability to get to know each other in a real work capacity without any long term commitment. It assures the contractor that their work will be paid for when all the outlined details have been completed to specification even if they are let go at the end of the first milestone. It gives the client the ability to gauge the working relationship with their new contractor and eliminates the possibility of a nightmare scenario where the contractor becomes undependable right after the contract is signed.
Now, this type of an arrangement limits us to the possibility of wasting a small amount of time, say one week, on a shifty contractor. Let’s try to reduce that amount of time even further – and that would need to take into account the interview process. Which takes us to the next topic: Vetting A Technical Consultant – The Integrity Interview
