Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
1  
I've added the tag estimation which is a good thing to look through. Software estimation is a Black Art. –  MichaelT Feb 19 at 16:26
1  
There's not quite enough information here to adequately answer your question, because you're not telling us anything about the team, how well the team works together, if requirements change during development, stuff like that. –  Zeroth Feb 19 at 17:17
    
Do you guys run regular per-sprint retrospectives? Do you have code quality or testing issues(IE, are the devs not testing completely enough before turning over the code?) –  Zeroth Feb 19 at 17:18
    
@MichaelT Not sure it is a black art exactly but certain things make it more difficult: external factors and changing/poorly defined requirements –  Robbie Dee Feb 19 at 17:34
    
@RobbieDee that black art is a reference to a book written by Steve McConnell of Code Complete who wrote a book (that is considered one of the better ones) titled Software Estimation: Demystifying the Black Art. –  MichaelT Feb 19 at 17:39

1 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

share|improve this answer
    
Also note that as you complete it once its been delivered use that information to feed back into the correction on the next estimate. –  MichaelT Feb 19 at 19:31
    
Yes, sprint retrospectives (or PIRs in old money) are crucial. –  Robbie Dee Feb 19 at 23:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.