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.
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.
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.
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).
Does that make more sense?
How do you handle amounts for revisions?
- 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.
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.