This old chestnut keeps rearing it';s ugly head - the customer has to know how much the job will cost, before they'll commit - the devleopers can't say until they know more about what the users want. Big design up front with "sign off" in blood is next to useless - we've all seen that - the one constant thing is "change".
There is an interesting post and related discussion related to this topic on TechRepublic - here. This is more about building schedules and developers estimates.
Recently I had to address this problem yet again. My esimating by gut feel skills are always improving. I had to quote a job for only about a month's worth of development work. I spent quite some time makung sure I understood the requirements as best I could, with input from a couple of subject matter experts and of course 4 senior users from the customer's business. Anyway time came to finalise the spec and quote for this customer. I have pushed a fairly Agile approach in that over those weeks well keep showing you progress, we'll build daily and so on, but there will only be two points in the process where delivery to the customer will be worth-while. The changes will form part of out daily build/test cycle so our feedback loop will be short but not from the customer - we have a commercial product, released quarterly so we can't very well be shipping weekly to a customer.
Anyway, after careful condieration I broke down the WBS as best I could and gave some estimates. Everyone, including the customer was happy with the time frame and related costs.
The developer, ultimately charged with doing this work, was on leave and could not be contatct. He started the work first day back, and was immediately grumpy. Probably at not being consulted and fair enough too - he was stuck with a schedule, he'd had no input into - very unfair and very "non-Agile". However after a few hours work he was making noises about how this first task is going to take a month, let alone the rest! I started to lower customer expectations around the deliver time - subtely. Three days later, he was almost finished that first task, 10 days on the estimate, the one he'd said would take weeks. Now, he quite cheerily says, "I think I'll finish this easily inside those 26 days you've quoted the customer."
This is a great example of a couple of quotes in the discussion on the TechRepublic post I linked to above, firstly, one of the best tools in relation to estimating and scheduling software development, is experience, secondly, team leads and managers tend to build a bit of fat into their estimates, developers tend to under-estimate all the tasks. I have no doubt we won't be finished as easily as our developer now thinks, but I was also unnecessarily worried with that initial concern - my experience has served me pretty well, and the fat I built in originally was about right!
No comments:
Post a Comment