In what visual format should I present an estimate for a software project?

Question

What I mean is, do people print some kind of line item form? What data does it contain? What are the line items usually? Otherwise, do you just present a written document describing with a paragraph?

Do you show the number of hours or just a lump sum? Perhaps you only show dollars per hour and an estimate of the hours. Do you give multiple estimates, a high and a low?

Is there any best practice for making sure you don't screw yourself or your client?

Just trying to get an idea of a few samples of what a client might want to hold in their hands or see on their LCD screen so they can authorize the work that is being presented and agree on the cost.

Answer 1

Clients want to see what you will be spending your time on.

I really hope you are using a project management system. The two general points that result in a well-documented project (and, subsequently, client satisfaction) are:

1. Breaking the project into tasks and subtasks - you should end up with documented issues detailing the estimated time required for no more than 4 hours.
2. Logging your time - for each task/subtask and recording the amount of time you spent working on it.

Being diligent about the second point and being able to break down the projects in a sensible manner will provide sufficient information for any client about what you're doing and what they are being charged for. Using this approach also allows anyone looking on to see the overall progress and account for any horribly wrong estimates.

When you present information to the client, it is better to show them more information rather than less. Clients will never doubt you for being thorough about your work - after all, they are financially invested. Provide a medium for them to see each main task and the time/cost estimate easily. Then, also provide a lower amount of detail so they can check for obvious misunderstandings.

Answer 2

It very much depends on your commercial model and what your client wants (so ask them). A few things to think about:

What will help your client make a decision?

The client is making a decision - whether to proceed with the project or not and which options to choose. The information you provide should help them with this and be at an appropriate level to do so.

So what will help them prioritise, what will help them select which functionality doesn't provide value for money?

This is a sales document

What will help you make the sale? How can you make things look most appealing, make things look good value for money? Ideally the things you're listing look should be grouped such that they have clear business benefits and sell themselves.

As part of this think about hiding contention - I've lost count of the number of times I've argued about testing ("your developers shouldn't make mistakes and I certainly shouldn't be paying to have them found") so think twice about task breakdowns like that and steer clear of things they might pick on

Note: I know testing is important and I'm sure you do. You need to gauge whether that's a useful message for your customer though - some are great about it, insist on it and want to see it, others don't get it. You need to work out whether educating them is in your interest or whether you're best off just hiding it. Remember, you're in business, not education.

What are you willing to report back?

If you provide a massively detailed estimate, you're likely to be asked to report back progress and final costs at that level. If you're OK with that then fine but there's an overhead that comes with it (time recording at that level) and it can encourage micromanagement and haggling. Personally I'd keep things relatively high level.

Think about your commercial model

There are two basic models:

a) Time and materials projects

With this you're charging for your time on a strict hourly rate and what you're providing are estimates - that is your educated guess for how long each thing will take. If things over run the client will pay more (you should notify them as soon as you know it's going to go over - never incur an overrun before you've informed them), if something takes less time than you estimated it's cheaper.

Because of the nature of the model you can be as open as you like with them and if you wish can break it down into as much detail as you want - after all this isn't something to haggle over, it's an estimate, your best guess.

That said most clients don't want to see a list of 100 tasks. Broadly speaking for a smaller project (100 man days total or less) I'd list nothing smaller than a couple of days, nothing larger than 15 days, typically no more than 10 line items) . For larger projects these might increase but if you're getting lists of 30 or 40 items you're probably at too low a level plus providing this level of detail positively encourages micromanagement from the client.

b) Fixed price projects

In this model you're charging a set amount for the development of a piece of functionality. If you estimate it's going to take you 100 days and you're done in 10, the price doesn't change and you're laughing. Similarly if it takes you 1000 days, you're screwed and you don't get to increase the price.

In this situation your estimates are none of the client's business - they're buying something akin to a product, a set of functionality for a set amount of money.

What you're providing is basically a price list for them - a list of things you're going to do with a price against each one. The level of detail is largely driven by the client but ideally it will be at the level where they're likely to pick and choose different functions to implement based on the prices you provide.

Personally similar to T&M projects I'd be looking at no more than 10 line items for a project of up to 100 man days and even beyond that you want to keep the total down because aside from anything else the time taken to estimate every little permutation is considerable.

Answer 3

It depends on how you want to be paid (or how your client wishes to pay you). If you're doing a fixed-price contract (and I hope you aren't!), then a good system description with a feature list is probably sufficient. If you're billing per hour, then a feature list with an estimate for each feature is the minimum you should present. If you're going to be paid in installments based on milestones, then be sure to list those and get agreement on what is to be delivered and what is expected to be complete after each one. Don't forget to include "housekeeping" tasks as well (progress meetings, demos, feature reviews, etc) and don't forget things like creating an installer (if applicable), designing/creating the database schema, or any configuration tasks (e.g., if the client needs an app/DB server set up). You can probably lump a lot of stuff into a single-price line item with a sub-list of tasks/activities that apply to that item. Make sure you have a nice bolded statement that this is an estimate only, and invoices will reflect actual time/effort expended.