Planning and estimating large-scale software projects
tomrussell.co.uk
Planning and estimating large-scale software projects
1–10 of 138 posts
Re: Planning and estimating large-scale software projects
#2Author here. I've been lucky enough in my career to hold some senior positions, and I thought I'd give a step-by-step on an approach I took with an "enterprise-scale" software project, and how I stole some techniques from university project management courses to meet with some success. Happy to answer any questions :)
Re: Planning and estimating large-scale software projects
#3I have to admit I popped a monocle when I saw the estimate for what is described as a rudimentary ecommerce website without even basic features like authentication and payment come down to 43 team-weeks, or in other words 12,040 team-hours. Even at one person per team being billed as $20/hr this works out to almost a quarter million dollars.
I understand the numbers are given as an example but I think the problem is that the scale of the task hardly justifies the complexity of the planning and using "teams" and "weeks" as sizes instead of "developers" and "hours/days".
Re: Planning and estimating large-scale software projects
#4I have to admit I popped a monocle when I saw the estimate for what is described as a rudimentary ecommerce website without even basic features like authentication and payment come down to 43 team-weeks, or in other words 12,040 team-hours. Even at one person per team being billed as $20/hr this works out to almost a quarter million dollars. I understand the numbers are given as an example but I think the problem is…
I think I would have popped a monocle too, had that been the real example and estimate from a team!
I tried to think up an accessible example that didn't require too much context on the part of the reader, so obviously, as you correctly point out, all the numbers are made up, and I'm trying to use it solely to demonstrate the workflow :)
Re: Planning and estimating large-scale software projects
#5I have to admit I popped a monocle when I saw the estimate for what is described as a rudimentary ecommerce website without even basic features like authentication and payment come down to 43 team-weeks, or in other words 12,040 team-hours. Even at one person per team being billed as $20/hr this works out to almost a quarter million dollars. I understand the numbers are given as an example but I think the problem is…
The thing with software is that it takes two weeks to get to 90% finished, then two years to get from 90% to something 100% production ready. Having worked over 5 years with ecommerce software I could write a fully working e-commerce site in two weeks, but then the marketing teem want to have it all integrated with 50 different tracking systems, and support 10 different payment systems in 30 countries, and have the correct VAT handling as well comply to local laws, integrated shipping systems, and of course 30 different versions of the site in all languages. And integrated with business software. And every moth the marketing team want to start a new compaign, buy 3 and get 20% off, buy only milk and get 30% off, buy a red shirt and get 25% off, discount codes, discount codes that includes shipping, etc. Did you know that different products have different VAT in different countries and within the same country as well? And shipping should use the average VAT from the products ordered - depending on country...
Re: Planning and estimating large-scale software projects
#6I have to admit I popped a monocle when I saw the estimate for what is described as a rudimentary ecommerce website without even basic features like authentication and payment come down to 43 team-weeks, or in other words 12,040 team-hours. Even at one person per team being billed as $20/hr this works out to almost a quarter million dollars. I understand the numbers are given as an example but I think the problem is…
Instead, we as an industry prefer to adopt magical thinking where we pretend that software projects aren't hard and lengthy and risky (even when the domain and tech are well understood), then we act surprised when the project "overruns".
Re: Planning and estimating large-scale software projects
#7I have to admit I popped a monocle when I saw the estimate for what is described as a rudimentary ecommerce website without even basic features like authentication and payment come down to 43 team-weeks, or in other words 12,040 team-hours. Even at one person per team being billed as $20/hr this works out to almost a quarter million dollars. I understand the numbers are given as an example but I think the problem is…
> I popped a monocle
This is why I don't bother with estimates any more - not because I think it's impossible, or even necessarily too hard, but because I've observed (consistently over a 30 year career) that it's pointless. Even if you could estimate with perfect precision exactly how long a software task was going to take, they would just push back, say, "that's too long" and argue with you until you told them what they wanted to hear.
Re: Planning and estimating large-scale software projects
#8This is a great breakdown of your process. I've seen many quite like it and have also been asked to make these kinds of estimates myself on projects for many of the same reasons: someone made a promise to another person, signed a contract, planned a release date for something they just made up, etc.
What I find frustrating about the whole situation is that no matter what process you use for making these estimates you have a roughly 30-some-odd percent chance of being right. It almost never has anything to do with the process you used when it does go well. If it did estimating software projects would be trivial, wouldn't it? Everyone would use this process and we wouldn't have 60-some-odd-percent of large enterprise software projects going over time and budget.
In reality people have used this very process, I'm sure, and have been in the 60-some-odd-precent. People have been studying this phenomenon since before I was a nerdy kid hacking on my Amiga.
Having a roadmap or a plan to get from A to B is good. It will need to be readjusted as you explore the problem space and navigate the waters so to speak. But the only real guarantee we can make as engineers is that we'll make progress in my experience. I'm only giving really rough estimates in the beginning and those estimates improve as we get closer to our end goal. I only start talking about actual release dates when we get close to being finished and are mostly polishing out the rough corners and have already done a few iterations internally.
If someone makes a promise they can't keep or have no business making -- in my books -- that's their mistake and they've made it a problem for everyone else.
Re: Planning and estimating large-scale software projects
#9I have to admit I popped a monocle when I saw the estimate for what is described as a rudimentary ecommerce website without even basic features like authentication and payment come down to 43 team-weeks, or in other words 12,040 team-hours. Even at one person per team being billed as $20/hr this works out to almost a quarter million dollars. I understand the numbers are given as an example but I think the problem is…
I think I would have popped a monocle too, had that been the real example and estimate from a team! I tried to think up an accessible example that didn't require too much context on the part of the reader, so obviously, as you correctly point out, all the numbers are made up, and I'm trying to use it solely to demonstrate the workflow :)
> all the numbers are made up
Well... have you actually applied this process successfully? If so, wouldn't you have some actual numbers to point to from a past project? Names and details changed a bit to protect the innocent, of course.
Re: Planning and estimating large-scale software projects
#10> Estimates are one of the hardest parts of software development.
And also fundamental. When I was directly estimating big software projects the key, for me, was to trust developers recommendations but apply a different multiplier for each developer. Multipliers ranged from x1 to x3. Those rare devs with x1 were, of course, a blessing. And those with x3 were not necessarily bad; they were often the ones working on the really hard problems. Of course, it meant getting to know those developers and a prior (which we set at x2, for new starters).
Individuals were remarkably consistent in terms of their actual performance; so a x1 developer would almost always be a x1; a x1.5 would almost always be x1.5.