Creating Project Cost Estimates for Clients
A new client wants to talk about his project. After giving you a sketchy outline of what he wants his next question is virtually always, "What will that cost me?" The answer should always be "I don't know yet." One of the most challenging things about being an outsource development company (or contractor) is estimating what to charge for a project. The process is complicated by the fact that your customer may be from a different state - or even overseas. We have seen a dizzying array of approaches to rates, billing and estimating. We have found an approach that works and allows us to avoid unprofitable projects and more importantly make money on the projects we take. It's also an approach that customers find very satisfying because it's fair - and it gives them cost-cutting options. It requires more work than typical estimates however.
First of all, we don't do any estimating without a set of requirements. Make this a hard and fast rule - even if the client is your brother-in-law. Don't ever ball-park and don't ever speak "off the top of your head" about money. Make sure you have some procedure that assures you and the client that you know what it's going to take to get the job done. In our case, we get a requirements document. Sometimes we create it ourselves. We break every project down into component pieces and tasks. When the document is finished, we create a spread sheet where each component or task is a separate line item. We then we assign a minimum and maximum number of hours to the item. Here's a fictitious example based on a rate of $80 an hour.
| Item | Description | Min | Max | Min $ | Max $ |
|---|---|---|---|---|---|
| I.a | User Management Interface | 12 | 14 | $ 1,020.00 | $ 1,120.00 |
| I.b | Group Management Interface | 10 | 11 | $ 800.00 | $ 880.00 |
| II.a-c | Lead Management interface - add, edit and delete new leads. | 24 | 28 | $ 1,920.00 | $ 2,240.00 |
| II.d | Import Utility (import Lead List from various file formats) | 20 | 22 | $ 1,600.00 | $ 1,760.00 |
| III.a | Lead Notification task (notifies Sales of lead status change) | 5 | 6 | $ 400.00 | $ 480.00 |
| ... and so on through all the components and tasks.... | |||||
| - | Debug and Revisions (15% of the hours totals of 320 to 380 hours) | 48 | 57 | $ 3,840.00 | $ 4,560.00 |
| - | Totals | 368 | 437 | $29,440.00 | $34,960.00 |
2 things to note about this example. We have a range to work with. We can say to the customer, "This project will cost you between 29k and 35k." The second thing to note is that last line item. It says "Debug and revision" and it represents 15% of the total of hours up to this point. Both the Range and the debug line item are designed to make us more flexible. We know (from long experience) that the project the customer really wants may still be in his or her head - and it won't come out till they start seeing prototypes, test forms and the like. We want to make sure we have enough wiggle room to satisfy revisions and project creep. The range amount allows us to do that on an individual line item basis.
The line items perform another function as well. Invariably the customer will look to trim the cost of the project. Giving them a line item cost estimate allows them to "strike" features or components that may be unnecessary at this phase - reducing the cost of the project.
One more thing to note about the "range" amount. A careful customer will examine your line items and wonder, "Why is the range for item N so great?" He or she might wonder why you have chosen to indicate "20 to 30 hours" for a particular line item. This is your opportunity to explain the importance of detailed specification. The reason the range is greater is because there are more "unknowns" about that item - and if the client would provide a bit more detail about what he or she had in mind we could narrow the range quite a bit. In this way the estimate becomes a "vetting" of the requirements process. It helps those requirements be more detailed.
What to charge
Don't ever let the fact that a customer can find a contractor at 35.00 an hour to do a project, keep you from charging what you are really worth. We make a great living cleaning up after 35.00 an hour contractors (ha). If you are a guru, charge like a guru. If you devalue your services you will not be there for the big contract when it comes a'calling. In our case, we charge in the top 20% for our area. We are not the costliest, but we are certainly not the cheapest. Analyze your selling points. Do people hire you because of cost? Is that what you want? We want people to hire us because of our advanced expertise - not because they believe it will save them money (except in the long run).
More to the point, that 35.00 an hour contractor might charge you 20 hours for something, and the same task can be done (by us) for 8 hours. This is a point we illustrate frequently. We charge more, but our response time is better and you don't have to pay for us to "figure something out" - we know what we are doing. By the way, if you make that point to your customers, make sure it's true (ha). What you charge also depends on your ability to deliver. If you over-charge for your value it will eventually catch up with you.
Finally, do what's best for the customer. If they can't afford your rate, then find them a contractor who charges less. Yes, I said find them a contractor who charges less. It will benefit you in the long run. That same contractor will run into a project he or she can't handle and refer it to you. Or perhaps that referred customer will grow beyond the original contractor and come back to you for the next phase of his or her business development. Doing what is right for others (yes - even in business matters) will serve you well in the long run. You might make a friend in the process - and friends are far more valuable than clients in the long run.
11 Comments
-
How do you estimate your line items? Do you include delivery dates for stages? -
That's a good question Mike. Ultimately the estimate is based on experience, but we do provide the customer with guidlines that outline typical tasks and components - along with typical charges.
As for timeline, there is a separate timeline that includes advances, invoicing and delivery. Delivery date is almost never "per component" unless it's a special requirement where a component can be used separately from the ap (a data import module for example).
We provide (typically) 3 dates - an estimated date for testable beta code, an estimated date for pre-launch (revised) code, and a deployement date. The last payment is usually tied to the deployement date. -
This is all so true -- Don't ever ball-park and don't ever speak "off the top of your head" about money. I found myself in the "client" role last year (not on a web project) but instead, gathering ideas and bids on a major home addition. We didn't even know exactly what we wanted, yet each contractor we talked to I would ask "give me a ballbark cost". And most would say, we won't know until we know what you and your wife want. I really wanted ballpark numbers just so I knew if I should even put the time in to see if anything would come to reality. If I would have heard $150K and up "ballpark" numbers, I would have probably stopped right there. But once we started hearing $80-150K numbers, I knew this project might be a possibility, let's keep going and see if we can round up our financing, and put together a plan that fits our budget and meets our needs. The lesson here is much of the job of the contractor is really digging out the "hopes and dreams" (aka requirements and wishes in web speak) of the client, and letting them know what is possible at different price points. If you hit a sweet spot with meeting their goals and budget, and gain their trust, you should get the job. -
It seems to me that your range between min and max are pretty darn close together. I've found when estimating that the ranges get closer towards the end of the project. I do a similar estimating process although I do my first estimate for personas, scenarios and wireframes. This range is often huge, easily 50-70% between min and max. The second estimate is for prototyping. The difference between min/max lowers to maybe 20-30%. The last estimate is coding and the difference between min/max is often quite small maybe 10%. This helps reduce sticker shock when the price goes up because they start kicking in a bunch of change requests along the way. Just a thought. :-) -
Steve - you are correct, but this is a dummy example. Also, a great deal depends on the size of the project and how routine it is. We do a great deal of "repeat" work for folks who are familiar to us.
The more tight the specs and the more familiar the customer, the tighter the range. As you indicated the range diminishes as the specification gets narrower and more precise. It sounds to me like you go through 3 phases of estimates - yes? We often do the same - charging for a wireframe or a prototype - or sometimes the spec itself (they DO often require a lot of research and effort). -
Yes. Although I don't think I explained how i do my estimates very well above. I do split my 'official' estimates up into 3 phases i.e. wireframe, prototype and coding. But at each phase I give my clients two estimates. One to complete the next phase and a second for the remainder of the overall project. So for example before I do a wireframe I give them a fairly accurate estimate for just the wireframe and a second estimate of what i think it'll cost to do the prototype and coding. This second estimate is where the min/max varies quite a bit. Then when we move into the prototype i give them an estimate to do the prototype which is often pretty accurate because it's based directly off of the wireframe, and i give them a second estimate for the coding. At this point the coding estimate's min/max is much closer than it was before we did the wireframe because we figured out much more detail about the project. Finally after the prototype is done i give them a final estimate to do the coding. At that point the coding is almost dead on.
Does that make more sense? -
Steve - yes! I get it. You have an increasingly accurate estimate as you are going forward. I like it. For one thing - you don't have to commit to the estimate of the bulkiest part of the project until you are very close to doing the actual work.
How do you handle amounts for revisions? -
I have a similiar strategy, but differs.
- I first, preliminary interview, probe the client about questions on the project. Not just the actual project, but what they want. I ask them to give me a wishlist and email me it (ie i want it in digital format), then i basically will cluster that wishlist (based on initial overview of what the projects objective is) and basically quote on the first phase.
The reason I do this, is clients tend to be like children at times (no offence), but they can't quite seem to get past the initial "i want.." if you lay it out in front of them with a "phase02,phase03" color code, they are more relaxed.
I then, once i've got enough basic specification/reqs aquired, begin to map the data layer / object model out. I pump all this information into a Excel Spreadhseet, and allocate a difficulty rating against each itemized task.
eg:
Security
----------
addUser = Hard
updateUser = Medium
deleteUser = Hard
The key to assigning a rating is not about "whether its actually brain numbing hard" its more to do with allocating a potential for "unknown sub-feature creep" (A term i've coined for unavoidable feature creeping).
Each rating gets pulled from a global time allocation.
eg;
Hard = 2.0 hrs
Medium = 1.0 hrs
Easy = 0.5 hrs
addUser = Hard? (which translates, it should take me a total of max 2hrs to write that one method, which is inclusive of debuging and R&D online about the best DB proof of concepts and all those Zen coder nightmares)
Basicaly by applying this formula you could sort of take away a lot of the clutter and itemize your plan of attack, whilest giving the client a clear understanding of what bottlenecks their project may face and seperation of whats hard and whats not.
Ontop of that, you can then provide an itemized listing of completion vs uncompletion when you actually win the project. -
Scott - I like your approach. You have a way of quantifying the estimate so that it's less objective. Very nice.
-
Be careful when you go to find a cheaper contractor for the project you don't want to take on. You could actually wind up pulled into a dispute if the project goes bad and the customer relied on your professional recommendation. You might be better off passing the lead directly to the contractor you choose. They would be more willing to sign a "hold harmless" clause to get the referral.
Has anybody looked at estimation by use cases? I blogged a few entries a month or two ago about how to do it (http://mrmx.blogspot.com/2005/05/software-estimati...). While it really only works well in the beginning of a project, it is fast and moderately defendable. It takes into account Scott's ranking system as well. I haven't found a way to reliably use it to make interim estimates or enhancement estimates.
You could easily use the number use case estimating comes up with as the basis for pricing your optimal outcome. You could even use it to jam some figures into "Estimate", which you can find at www.construx.com. You could probably get a nice range of estimates as well as some really neat looking deliverables out of it. -
When I say "find a contractor" - I do not mean that they are in any way affiliated with us. Usually I pass a couple of names to the client. The rest is up to them.
Sites to Watch
Aggregators
RSS
