I'm on the faculty at Boston University in the computer science department, where I teach software engineering, intro courses, and application architecture and development. Also a bit of a Deadhead.
Most projects, especially in large companies, really aren't all that innovative and are often just an extension of what's already there. In those cases you can use metrics to crunch most of the numbers to provide a fair estimate. Moderately complex database tables are 30 hours, DB triggers are 10 hours each, integrating a new data feed is 80, and so on. Once you have a large enough set of requirements you can just extract the pieces and do the math.
On the business side it gets even more interesting. We do projects to make money (why else do them?) and so companies want to run as many projects as possible to maximize profit. In a given year there might be 100 potential projects, but resources to run only a few...which ones? We use high-level estimates and ROI analysis to prioritize the projects. One company I worked with required a 10x ROI to fund a project.
Those high-level estimates also give an indication of how many resources you need. If it's 10,000 hours of work and I have six months, I'm gonna need ten devs minimum (roughly 2,000 man-hours in a year so 1,000 hours in six months). If I'm billing devs internally at $200/hour, I get a rough budget, too, in this case $2m. I know that the up-front phases (requirements and design) are typically 10% of the project, and QA another 20%, plus 10% contingency, and so I have a rough budget of $2.8m. That's enough to let me compare projects and prioritize them, and if a project gets green-lighted I can refine the estimates during the discovery phase.
The flip side is that if you grossly overestimate, all hell can break loose. If I'm managing that $2.8m project and get it done early and under budget, that is not necessarily good news! Let's say I brought the project in at $1.75m. Great! I just saved the company $1m! Unfortunately C-level management (CTO, CEO, etc) sees that as $1m tied up that couldv'e been used to fund other projects (and recall that more projects means more profit). Hence, a $2.8m project miraculously always comes in at $2.8m (unless there are issues that drive the number up, which is another story).
A truly unique endeavor would probably be funded out of an R&D budget rather than operations or product, treated as high-risk, and would be estimated / managed differently.
BTW that's just for internal projects. If it's being done by some other firm (consultancy, vendor, etc) there are additional costs, and the type of contract (fixed cost vs time-and-material or cost-plus, for example) will drastically change the quoted price. If I'm in a T&M situation there will be a cap on spend and schedule, beyond which requires C-level signoff, and if it's fixed-cost I'm going to add ANOTHER 10% to cover my risk (the risk is that it'll take longer, which means more spend on my part, even though I'm getting a fixed price). I love fixed-cost since there's an opportunity to work hard, finish early, and keep the extra dollars.
Next time you'r grabbing some ice cream at Gray's, keep going down main road about a mile, and on the left you'll see the old Friend's Meeting House. Across the road from it is the John Irish house, which my ancestor Jonathan attempted to burn down in the late 1600s. John Irish is buried on the property...I stopped at the grave once to apologize for Jonathan.
For small shops, startups, and the like there aren't a lot of competing projects (often just one), and so the budget is the internal cost of dev times however long it takes. There isn't a lot of overhead and requirements can be revised as you dev and learn.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Most projects, especially in large companies, really aren't all that innovative and are often just an extension of what's already there. In those cases you can use metrics to crunch most of the numbers to provide a fair estimate. Moderately complex database tables are 30 hours, DB triggers are 10 hours each, integrating a new data feed is 80, and so on. Once you have a large enough set of requirements you can just extract the pieces and do the math.
On the business side it gets even more interesting. We do projects to make money (why else do them?) and so companies want to run as many projects as possible to maximize profit. In a given year there might be 100 potential projects, but resources to run only a few...which ones? We use high-level estimates and ROI analysis to prioritize the projects. One company I worked with required a 10x ROI to fund a project.
Those high-level estimates also give an indication of how many resources you need. If it's 10,000 hours of work and I have six months, I'm gonna need ten devs minimum (roughly 2,000 man-hours in a year so 1,000 hours in six months). If I'm billing devs internally at $200/hour, I get a rough budget, too, in this case $2m. I know that the up-front phases (requirements and design) are typically 10% of the project, and QA another 20%, plus 10% contingency, and so I have a rough budget of $2.8m. That's enough to let me compare projects and prioritize them, and if a project gets green-lighted I can refine the estimates during the discovery phase.
The flip side is that if you grossly overestimate, all hell can break loose. If I'm managing that $2.8m project and get it done early and under budget, that is not necessarily good news! Let's say I brought the project in at $1.75m. Great! I just saved the company $1m! Unfortunately C-level management (CTO, CEO, etc) sees that as $1m tied up that couldv'e been used to fund other projects (and recall that more projects means more profit). Hence, a $2.8m project miraculously always comes in at $2.8m (unless there are issues that drive the number up, which is another story).
A truly unique endeavor would probably be funded out of an R&D budget rather than operations or product, treated as high-risk, and would be estimated / managed differently.
BTW that's just for internal projects. If it's being done by some other firm (consultancy, vendor, etc) there are additional costs, and the type of contract (fixed cost vs time-and-material or cost-plus, for example) will drastically change the quoted price. If I'm in a T&M situation there will be a cap on spend and schedule, beyond which requires C-level signoff, and if it's fixed-cost I'm going to add ANOTHER 10% to cover my risk (the risk is that it'll take longer, which means more spend on my part, even though I'm getting a fixed price). I love fixed-cost since there's an opportunity to work hard, finish early, and keep the extra dollars.
Next time you'r grabbing some ice cream at Gray's, keep going down main road about a mile, and on the left you'll see the old Friend's Meeting House. Across the road from it is the John Irish house, which my ancestor Jonathan attempted to burn down in the late 1600s. John Irish is buried on the property...I stopped at the grave once to apologize for Jonathan.
For small shops, startups, and the like there aren't a lot of competing projects (often just one), and so the budget is the internal cost of dev times however long it takes. There isn't a lot of overhead and requirements can be revised as you dev and learn.