Making accurate time/cost estimates

Complex site. I charge by the hour. Client wants accurate estimates.

[graeme_p]

I have been working on this site for nearly an year, doing something on it most weeks, but because it has a lot of components I have not touched large chunks of it. The existing code is far too complex for the functionality it delivers and hard to understand. I can go into more details if it will help, but its unnecessarily complicated and on top of that obsolete files have not been removed. The functionality is mostly heavily customised - a purpose built booking system, for example.

The client is a nice guy and there is a lot of work there so I would not like to give up the work, but he wants more accurate estimates of completion dates and time/cost. At the moment I charge by the hour (which I do for most clients). I find it hard to explain the difficulties of accurate estimates for software development - he has said things like "if I need my car repaired I can get an accurate estimate".

The client gave up on the original developer because of high cost - when he realised that most of the work was being done off-shore he hired an off shore shop directly and they were slow to deliver. He eventually gave up on them and I got the work.

He says he is happy with my work but wants accurate completion dates and time/cost. I am struggling with this. It is more difficult than it is with a site I did from the start because I never know when I will run into an unexpected difficulty with the existing code. Just last week I thought I was nearly done with a major block of functionality and then found some form processing code that worked in a way I never expected and had to be rewritten to work with my changes.

If I take the time to look at what it would take to do a particular bit of work, I then find that I have spent so much time checking everything will work as expected that I am half way through the work required to do it.

Are there better alternatives? I cannot find a way of estimating time required that is not a time sink itself. It also does not help doing the work on the basis of the client adding issues to a ticket tracker (which is better than what many clients do), that fall well short of being an requirements specification.

[not2easy]

You could explain the defective reasoning in their idea that "if I need my car repaired I can get an accurate estimate" should translate equally to your work.

A car is a known commodity, this one is the same as that one other than a few options. The manual for any car is available to any mechanic and the time for completion of any given task is usually included in the manual.

Their site is an unknown work the same as a manuscript. Until you have completed editing chapter one, you have no idea what might be in chapter two. At the end of each chapter there is additional editing to ensure that the completed chapters don't change course, that they will fit seamlessly together. The parts are not pieces of a puzzle to be put together, each part is being made to their specifications to fit together. There is no way to predict the time you will need to complete an unknown task.

It is understandable that they would like time/cost estimates, but just as a prefab house is very predictable in every way, a custom made home with decisions on landscaping, fixtures and materials along the way cannot be quite so predictable.

In other words, their expectations are not realistic and you may need to be creative in how to make that clear without being offensive. It is clear that they do not understand what you are doing and why it isn't as cut and dried as repairing a physical object might be.

Edited to add - you are not alone, see this discussion: [webmasterworld.com...]

[engine]

I went through this once with a client that employed a developer that wasn't up to the task, but was cheap. He couldn't finish the job, and the client asked if i'd take it on and get the site working.
I explained that fixing what's been done so far was going to be more expensive than developing an entirely new site. I suspect the client was more exasperated with the previous developer and himself for choosing him in the first place. He bit the bullet and we developed a new site. The advantage with that was we were able to quote for our own work - we knew our capabilities.

Your situation might be a little too far down the line for a switch to a newly developed site.

As for costs on an existing site, you must have a better idea by now as to the challenges of finishing the site. Ask the client for a clearly defined expectation of timescales: What does he expect?
Consider breaking it down into stages to work to, with dates and cost estimates per stage.

[Leosghost]

Walk away..politely..before it ends in tears and recriminations..and possibly lawyers at dawn..

[graeme_p]

@not2easy I have tried explaining. I will try your analogies - it may work better than the mine did. Thanks for pointing out the other thread too.

@engine Yes, we are too far down the line to redo from scratch. The situation here is not that the site is unfinished but that the client needs a lot of additions and changes. We have agreed to break it down into individual items - which will also stop the client adding new requirements as we go.

A lot of the problems also stem from lack of communications as the client is busy running the business and I think he feels the website is a bit of a distraction - I think as its his only sales channel and he is an intermediary to a large extent the website IS his business (the rest is marketing the website and doing the fairly complex admin around passing bookings on to suppliers).

[graeme_p]

@Leosghost, I have considered that. I even told him that might be best.

I have walked away from clients before but he is very keen I continue.

[engine]

the client needs a lot of additions and changes.

Especially if they keep changing it: All the more reason to document it.
If they are busy, drive the project for them, they might appreciate that.

[lucy24]

It may not be comparable to car repairs, but it should be analogous to larger-scale contractor work. When you bid on a project, you are responsible for figuring out how long it will take and what supplies you will need. If it turns out you underbid and you lose money, that's on you. (If instead you overbid, Whee! You get a vacation, owner is SOL and should have looked at more bids.) But you need to make sure the contract includes exceptions for unforeseeable (not just unforeseen) circumstances. If the attic joists are rotten and you didn't know, that's your problem because they were in plain sight and you just didn't look. But if the foundation is termite-eaten in places you couldn't see until you'd torn up the floor, then you renegotiate.

Changes requested after the beginning of work will be charged extra in any contract worthy of the name.

[iamlost]

You both, contractor and client, need to follow a two step process:
Step 1: develop a combined RFI/RFP/RFQ so that everyone is on the same page with what is required, when, and for how much. Given that in this instance the work may be a series of smaller jobs rather than one large one this would allow each to proceed within a coordinated whole end goal.

Note that this is NOT done for free. It should be billed at your normal webdev rate because it takes expertise to do correctly. This is not a cheap process but it is absolutely necessary.

Step 2: contract separately for each identified step as requested by client as per your usual rates based on the information developed in Step 1.
Note: to minimise disagreement I always recommend a proper contract (I've commented on this in many WebmasterWorld threads over the years) that includes a change order clause (I wrote specifically on this over a decade ago here).

There is no easy simple cheap solution. Indeed I'd go further and say that not even one of them is possible. There is, however, a viable route to a great finished site.

Best wishes!

[tangor]

Remind them you can have:

Cheap
Quick
Right

Pick two, can't have all three. As for your time, you know your ability, bill it correctly, fair, and fair to yourself, too.

URGE the rewrite/move to a more logical framework/function than the hodge podge you have been presented by showing EXACTLY how such change will be both cost AND time effective. Secondarily, you can at the same time stress privacy, global compliance in that regard, future expansion/maintenance, etc.

What you have described is a nightmare. If you wish to continue, then do so in small bits specifically enumerated with known start and end goal before moving on to the NEXT project in need. DO NOT LET THIS TURN INTO AN OPEN ENDED fiasco!

[graeme_p]

Thanks for the tips. One good thing about this client is that he is not fussing about total cost, but wants more predictability, so he is not expecting cheap.

URGE the rewrite/move to a more logical framework/function than the hodge podge you have been presented by showing EXACTLY how such change will be both cost AND time effective.

How to present that is worrying me. I can give examples from recent work that went slower because of less than good practice in code being modified. I need to think about this.

@iamlost, I think that is the ideal solution from my point of view. The biggest difficulties are going to be persuading the client he needs to pay for step 1 (and there is no way I can do it for free) and having a coordinated end goal - its a new business and the end goal is in flux (e.g. when a deal is done to sell a new line).

[graeme_p]

But you need to make sure the contract includes exceptions for unforeseeable (not just unforeseen) circumstances. If the attic joists are rotten and you didn't know, that's your problem because they were in plain sight and you just didn't look. But if the foundation is termite-eaten in places you couldn't see until you'd torn up the floor, then you renegotiate.

That favours the approach iamlost suggests: I need to spend the time to find the equivalent of rotten attic joists.

[graeme_p]

Thanks for all the helpful suggestions. It looks like I have finally got through to the client about the difficulty of giving accurate estimates. I gave him a couple of options based on the suggestions above. We have currently agreed a new set of terms for future work based on fixed hours a week - so he knows how much to expect to pay me each month which solves his biggest issue.

Thanks again.