How do you work out timings for larger projects?

Question

I work for a small company that hasn't done much work in bespoke development. It's something we're growing into. With all our projects, whether a bespoke development piece of work, or a simple brochure website, we plan out how long we expect the job to take us and then multiply that by our daily fee to give us a quote for the customer.

That has always worked well for us with the smaller projects, the CMS sites, the eCommerce sites, where we know the systems well and don't come across many issues. We have timings down well and can predict costs accurately.

However with these larger bespoke projects we're starting to find that no matter how much we plan ahead, no matter how much we nail the specifications of the system, our timings are always out. We've started adding in a considerable buffer for bespoke pieces of software, but even then a couple of nasty bugs can really set things back and push us beyond what we expect by quite a long way.

How do you quote for these larger projects? Is it simply a case of keep going and eventually we'll get it right? Or are we missing something here as it seems almost impossible to nail pricing down for bespoke websites that fall outside our standard CMS or eCommerce site.

---

Update

As @Zeroth pointed out there's probably a few things missing out about the team. We don't run sprints. We have one large project on the go and have milestones and just set goals based on our estimates of how long things should take.

As for the team, currently it's made up of 4 people, although 2 new people are being trained up at the moment. The 4 people make up a salesman and designer (he's also the office manager), a designer and website builder, a website builder who also deals with content for the sites and day to day customer facing issues, and me, the developer. I deal with development of custom projects and improving / fixing our CMS and eCommerce platforms. The two people being trained up are another designer and website builder, and a junior developer.

Once a project reaches certain milestones, everyone pitches in to test it as thoroughly as we can. I always put in as much logging and debugging information as I can think of to help track down the inevitable bugs as quickly as possible, but no matter how much we do, we can't test every situation.

I understand this is a complex and widely varying answer, I guess I'm mostly after some advice and also some pointers to resources (thank you @MichaelT for the link to the book) that can help us improve. We need to be able to pull a profit from custom work as we're currently fully booked until June for development work and we need to make this work for us. Over the last year, it just seems no matter how much we learn from each project we work on, we still get it wrong with our estimates.

Answer 1

The elephant in the room is the large bugs you mention that set you back. Your estimation could be spot on until you encounter a few of these. That however is a separate question.

Perfect estimation is based on knowing precisely the amount of work ahead of you. However, the more time you spend on this, the more you'll be looking at increasing levels of detail and the longer you'll spend estimating instead of getting started.

Start at a very high level and then iteratively look at each deliverable until you get down to the level where work needs to be done e.g. coding, specification etc. Then estimate for each of the leaf nodes. Then add a contigency (we use 20%).

Use experts in the area to estimate the effort required. It is pointless having a BA look at DBA tasks if they don't understand what is involved. The closer to the action you can do the estimation, the more reliable they'll be.

This will give you the effort (man hours, man days etc) which can be used to quote for the work. Note that effort doesn't give you a delivery date. This would be decided on by your resource allocation (other projects, holidays etc). Depending on how your company is set up, you may bill the same for all man effort or you might have a split structure depending on grade. At a former company we charged £1000 a day for DBAs, £500 for Analyst Programmers etc. You'll need to factor all this in.

For each project of a given size you complete, review it once it has been delivered. Which areas overran? Also (and this is critical) fully understand why each major issue came about otherwise you risk coming across the same problems again and again.

If a few people are doing the estimations, you'll get a feel for which people's estimates are reliable and which are way off. This isn't a stick to beat the staff with, the important thing is to understand why. Was a piece of work missed off the plan? Was a piece of work poorly understood? Did the requirements change? etc etc etc