The Only Estimating Toolkit You’ll Ever Need
TL;DR
- No single estimation method works for every situation; the right choice(s) depend on how much data and time you have.
- Gut feeling is valid but needs to be bounded: consider both the optimistic and pessimistic scenarios before settling on a number.
- The FTE method is reliable for schedule-heavy programs because it maps to how people actually think about time.
- Bottom-up estimating is the most thorough approach and the best at surfacing forgotten scope.
- AI tools can add real value to estimation, but they require structured inputs and ongoing validation to be trustworthy.
This is the third of five blogs in a series about program estimation. In the lead article, we walked through a four-step process from early alignment to getting started. In the second, we talked about using the right type of estimate to ensure you’re investing the right amount of effort.
Here, we will talk about how to build an estimate. These methods work for cost and schedule. As with the other blogs, there are various ways to do this, and as with the other blogs, each method is most suitable for different purposes (see blogs one and two).
Gut Feeling Works Best When You Bracket It
Gut feeling is based on expert experience, which has two important characteristics. First, everyone’s gut feeling is different. Second, it’s hard to account for all the factors embedded in past experience. For example, if I asked you how long it takes to make scrambled eggs, what would be the first number that comes to mind?
Now, ask yourself these questions: are you assuming you already have the equipment and ingredients? Are the ingredients you’re envisioning the same ones the client wants? Do you need to painstakingly discuss the ingredients first? Do you need to write down the recipe so someone else can recreate it? Did you account for cleanup? Did you account for the time it takes to fish the little bit of shell out if you didn’t crack it correctly, or the rare occurrence when the stove stops working?
Now, reassess your number mentally. Is it similar, or have the additional questions changed it?
The point here is that even though this whole exercise happens in your brain, it’s still worth thinking a bit about some of these details.
What helps this work? Striking a balance between pessimism and optimism. Consider the optimistic (what’s the fastest this could be done?) and pessimistic (what happens if everything goes sideways?) ends of the range and adjust if needed.
Past Projects Are Your Best Baseline, If You Have Records
Again, this one can be simple or complicated. In its simplest form, you can reference the timesheets and schedules from your most similar program and tweak as needed.
The trouble comes in when you don’t have similar timesheets, or you didn’t write down the schedule, or you don’t really have a similar program to compare to. What if your resources are different? What if you got better at it?
A couple of helpful hints:
- You can always scale a program (this new one seems like half of project X, but 20% more than project Y).
- You can review a few programs and average them.
- Rather than using whole programs for estimates, you can grab elements of them and combine them.
What helps this work? Don’t zoom in too far: the broader the information, the more that minor variations within your estimate will balance each other out.
The FTE Method Scales Because It Maps to Real Calendar Time
Here, we estimate how much time a person will need to spend to support a program. This is a powerful tool because it scales very easily.
For example, a program might include software, industrial design, and mechanical engineering. I might be able to estimate that the software engineer will need to be fully focused (90% of their weekly time) and will probably require a few months to build and test the code. Meanwhile, the industrial designer and mechanical engineer will have lots of stops and starts, and can work on other projects in the meantime (on average, 25% of their total time). Putting these together, we can sum up the length (months) multiplied by each person’s load to get an estimate. Adding risk contingency due to schedule overruns is also very easy: if the project runs two weeks late, the impact on resources is clear.
You can also vary the amount in chunks. For example, if the first half of the program requires a lot of science, but the last half requires more manufacturing, you might want to have different FTE estimates for those different phases.
What helps this work? Spending time laying out a simple schedule. The schedule really drives this method. It tends to work well because people tend to be better at thinking about calendar time than absolute time.
Bottom-Up Estimating Catches What Other Methods Miss
Bottom-up estimating means planning out all the tasks required to achieve a goal, estimating each one, and summing them to a total. This can be done front to back (start with step 1), or back to front (start at the end and work your way back). The latter is actually quite powerful: if we envision ourselves shipping a prototype, we can also envision the packaging, the testing, the instruction manual, and so on. Sometimes going through both directions is helpful.
The process:
- Lay out the major elements (3 to 10 of them is about right) and define the end point.
- Add a broad schedule to this top layer to aid in the next steps.
- Add sub-items to each of the major elements (3 to 10 sub-items per major element is about right).
- Continue adding layers until you’re satisfied that the scope is well understood. Don’t go overboard with this either. It takes a bit of practice to strike the balance. It works well to define a target size as a guide, for example: bottom-level items should be no larger than two weeks.
- Estimate the time it will take to complete each bottom-level item.
- Create a Gantt chart (or similar) and link the elements together.
- Check for resourcing bottlenecks or issues. For example, if you need 10 people one week and 2 people the next, you’ll likely need to rearrange the plan to address this.
- Add contingency, out-of-office time, and so on.
- Roll up the totals until you get a grand total.
What helps this work? Including people who will do the work, or who are familiar with it, helps ensure fewer items are forgotten. Also, set expectations on optimism ahead of time: are you expecting optimistic, middling, or pessimistic estimates for each item?
AI Can Improve Your Estimate, But Setup Is the Hard Part
This one is simple: just ask AI! But can you rely on its output?
AI is actually a pretty good estimator, and you can help it a lot by providing the right details, including estimate type, meeting minutes or other scope clarifications, and reference projects. Continuously feeding in the results of past estimates is also useful so it can learn how accurate it was and adjust next time. Another strong value in AI is pointing out items you might have missed. Even if the AI estimate is way off, those little tidbits are very helpful. The hardest part is setting up an environment with defined rules and processes, making it accessible to multiple people, training it on best practices and past projects, validating its outputs for accuracy, and ensuring it isn’t sifting through megabytes of data every time (which burns compute costs).
If you want to start using AI tools, use a combination of methods until you’re satisfied with the outputs, and always get it to explain its thinking so you can do a sanity check.
What helps this work? Don’t expect to get anything useful in less than a minute: put aside enough time to properly define the boundaries and details of your prompt(s). This is good value for your time: getting a decent estimate in ten minutes is much better than a poor estimate in two.
Three Add-Ons That Sharpen Any Estimate
The following methods aren’t standalone approaches but can be layered onto any of the above to improve accuracy and account for uncertainty.
Three-Point Method: In a three-point estimation, optimistic, most likely, and pessimistic estimates are prepared and compared (often with 4x the weighting on the most likely scenario). This could be applied to any of the methods above.
Example: if the pessimistic schedule is 12 months, the nominal schedule 7 months, and the optimistic schedule 5 months, then the average schedule projection would be 7.5 months ([5+7×4+12]/6).
Risk Contingency: Here, specific risks are considered, such as a prototype failing testing and needing to be redesigned, or parts being late. Each risk is then given a likelihood and an impact, and a single average risk impact estimate can be produced by summing the product of each risk’s impact (in dollars or time) multiplied by its probability (in %). This can be applied to any of the methods above.
Example: if there is a 50% risk that an item needs to be remade, costing 10 days and $1,000, and a 25% risk that the marketing department rejects your sketches, costing 4 days and $400, then the risk contingency is $600 ($1,000 x 0.5 + $400 x 0.25) and 6 days (10 x 0.5 + 4 x 0.25). This could be added to your nominal estimate.
Combination Estimates: Sometimes the best results come from taking multiple approaches. Try pairing an FTE estimate with a historical comparison. If they are close, average them out. If they are far apart, it’s worth trying to figure out why.
An Example: How Long Does It Take to Design a Bracket?
Gut Feeling: Assuming it’s just an aluminum bracket that no one will see or touch: a few days?
Historical Actuals: I had a look at a few brackets we designed in the past, and they vary from 2 days to 9 days. It seems to depend quite a bit on the requirements.
FTE: 20% FTE over a month seems about right. There will be pauses to ask questions of the electrical team. That would mean about 4 effort days.
Bottom Up: In talking to the designer, we identified a number of steps beyond the design itself. In total, these add up to 4.5 days.
AI: Fed AI the inputs and it thinks it’ll be about 2 days, and reminded me to make sure I define all my requirements first.
Three-Point: If everything goes perfectly, 2 days. Nominally, 3 days. If poorly, we’ll need 7 days. Best estimate is therefore 3.5 days.
Risk Factor: If everything goes smoothly, a day. But if the first draft design is too heavy and we need to perform a finite element analysis and redesign it, add 5 days. There is a 40% probability that this happens, meaning the average schedule impact is 3 days.
Combination: Averaging out all of the above, we’re looking at about 3.75 days to design an average bracket.
Nigel Syrotuck is a StarFish Medical Project Engineer and frequent guest blogger for medical device media including MD+DI, Medical Product Outsourcing, and Medtech Intelligence. He works on projects big and small and blogs on everything in-between.
Images: Adobe Stock
Related Resources
Five methods for building accurate project estimates, from gut feel to bottom-up, plus three add-ons that sharpen any estimate.
Early phase concept development is a weird part of a project lifecycle. It is often the most exciting phase, because the team is exploring possibilities, generating new ideas, and turning a fuzzy opportunity into something real.
Clinical prototypes must not only function as intended, but also be manufactured, documented, and supported in a way that satisfies regulatory expectations and clinical realities.
Choosing the right project estimation approach can make or break a medical device program. Learn when to use a gut feel, rough order of magnitude, or detailed estimate to balance speed, accuracy, and risk.