In the project cost management section of the lecture, Dr. Simon talked about two different ways to come up with a budget: analogous estimating (“top-down”) and bottom-up estimating. Analogous estimating is much faster, however, less accurate because it is tweaking results from a similar project or eyeballing it. Bottom-up is more time-consuming, but also more accurate. It was mentioned in the lecture that the bottom-up is not always possible especially when you are doing something for the first time; it would be difficult to know how much that costs. Top-down could get your project funded, however, a cap might be placed on the budget based on this estimate. This estimate could have been too low if the project becomes significantly larger than anticipated. On the other hand, bottom-up could give you too high of an estimate and result in a lack of funding for the project. These examples show that these two can be used for different situations, but has anyone used either of them or prefers one to the other?
In an ideal world the bottom up approach should be preferred. In my mind, the only major limiting factors to a bottom up approach is securing funding and hard project deadlines, which is what an "ideal world" would eliminate. As you have mentioned, a bottom up approach allows the project to be more accurate which should always be the number one priority. The top down approach is best when the aforementioned limiting factors are present because it sets preliminary restraints on a project that has not be fully started yet.
I agree with @anthonynjit . Although the analogous approach is quicker and less costly, its downfalls include being less accurate, considering little detail and understanding in preparing estimates, and caps on overall project costs. On the other hand, the bottom-up approach offers a more accurate estimation requiring the project to be defined and understood. The bottom-up approach would be ideal in most instances. In the event that there's a smaller project or a project that introduces new concept to the company, top-down estimating may be used. I have not personally had the opportunity to witness these methods firsthand but would prefer the bottom-up approach over top-down. Top-down infers uncertainty whereas bottom-up offers deliverables.
If I was in charge of the budget I would mostly use a top down estimate and have a factor increase that is calculated depended on the largest investment. So if the top-down budget is $10 Million dollars and the largest investment is $1 Million, then I would increase the budget by at least 10% or more. This may over budgeted but I think it a better option compared to simply estimating dependent on loose information gathered from analogous projects. The budget can also be updated as the project goes along it's life cycle as in many case that it what happens when under budgeting occur. The bottom up approach would be very time consuming and well be less attractive of a project budget as it will have to account for every single purchase.
I agree with what everyone has said so far, where the bottom-up budget is ideal, but certain situations require top-down budgeting. I wanted to open the floor to more nuanced conversations regarding budgets themselves, since the way the budget is used at the beginning of the project versus the end is different. At the beginning of the project, the budget is used as more of a negotiation tool than an estimate since the budget is a part of what is supposed to convince the stakeholders to take part in the project. Thus, teams may intentionally or unintentionally shape the budget to be more appealing for the stakeholders, making the project look more viable than it actually is. This can play a role downstream when the budget is not enough to continue funding the project, leading to disaster.
Additionally, there may be misalignment between the person who creates the budget and the person who uses the budget. Leadership will approve a top-down budget, but the engineers now have to work with a cap to finish the project. This can lead to engineers cutting corners or making changes that will cause issues downstream. The unrealistic expectations that come from the top-down approach can lead to frustration amongst the engineers and those working on the project. Additionally, cost estimates are prone to ignoring learning curves, as it takes a little while and some resources for teams to learn what is happening in the project and how to navigate the different aspects of the project. Later on, efficiency improves, but the beginning could cost more than the estimates. Neither top-down nor bottom-up can fully capture this shift, but bottom-up is more likely to account for this when the planning is cognizant.
Do you think that budgets are created to reflect reality, or are there some tweaks to make a project seem more feasible to leadership? Do you think tighter budgets lead to more innovation? Who do you think should have more control over the budget, the leadership, or the engineers who are actually doing the work?
I think your point about budgets acting as a negotiation tool early on is really interesting, and it raises an important question about whether budgets reflect reality or strategy. In many cases, especially early-stage projects, I think budgets are partially strategic narratives rather than purely accurate forecasts, they’re shaped to secure buy-in. This can be useful for getting projects started, but it creates risk if teams don’t revisit and recalibrate those assumptions as real data comes in.
One approach that might help bridge this gap is using a range-based or probabilistic budgeting model instead of a single-point estimate. For example, presenting a best-case, expected, and worst-case cost range could give leadership a more realistic picture of uncertainty while still supporting decision-making.
In terms of control, I think budgets work best when there’s shared ownership. Leadership sets constraints, but engineers and project teams continuously inform adjustments based on execution realities. This creates a more dynamic system rather than a fixed constraint that teams are forced to work around.
To Dev's first question, I think it's rarely a matter of intentional deception but rather displayed as a form of optimism bias that gets integrated into most layers of the project. The team pitching the project genuinely believes in it, so uncertain costs get rounded down while projected benefits get rounded up. This is compounded by the planning fallacy, where people systematically underestimate time, cost, and risk even when they have historical data suggesting otherwise. In the medical device space, this is particularly dangerous because of regulatory hurdles where findings are difficult to price up front, so they are underrepresented in early budgets to keep the overall project as appearing more viable than it actually is.
On the tighter budgets = more innovation point, this is something that can be proven and disproven depending on the situation. The idea of frugal innovation, where resource constraints force creative problem solving is a very real application that can occur depending on a situational level, but in a heavily regulated industry for development such as medical devices, cutting corners on verification & validation, clinical testing or design documentation (Which would be the "resource constraint") would only prove to create more problems down the line, which we have explored many times in earlier chapters, simulations and discussions on this forum. Rather, something like a tighter budget is more likely to produce technical debt and downstream remediation costs than a breakthrough solution.
@anthonynjit agreed that the bottom up would be the ideal. However, it unfortunately is often not the case in the real world. In my company, for example, the top-down approach is usually what's done. My company is able to do this due to having extensive experience in building other medical devices in the past. But this approach can sometimes fail too. For example, we once had a project where the costs ended up growing way beyond what was expected and we ran out of capital before development could be completed. This was due to the top-down approach missing many nuances of the development and costs that would actually be needed to get the project to the completed stage.
Both of these method are very useful, but when it come to which is better, they really dpend on the situation that is happening. When looking at when they are used in practice, they are both used together. Commonly a project would start with the top down approach and help to estimate the budget early and help to secure initial approval. Then as the project begins to gain traction and getting going, it switch to to a bottom up method as the number begin to refine and improving the accuracy. The helps to balance speed and realism. If I had to choose one, I would prefer bottom u[ when possible as it more defensible and detailed as well. Especially for a complex projects it can be very useful. In the early stages of a project or when there is a lot of uncertainity, the top down becomes he more practical option.