MD+DI Online is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Five Reasons Your Project Might be Underestimated
Image source: Pixabay

Five Reasons Your Project Might be Underestimated

Here are some tips on how to stay on course when developing a product.

One of the key benefits of being a part of a medical device consultancy is seeing numerous programs through from start to finish. I see how the project predications correlate to actuals, where the common pitfalls occur, and how those pitfalls are typically avoided by expert project managers to maximize success.

There are a lot of reasons medical device projects may go overbudget, but a big one is because the project is underestimated in the first place.1 Having a project slightly exceed time and budget estimations is usually manageable, but significant overruns are not as easy to survive.

Accurate budgeting and scheduling can save the time, pain, and cost associated with gathering additional project funding. Here are five issues I see project managers face and what you can do to prevent them.

Selling a Project

Details: Cited by NASA’s Inspector General as a major reason for NASA’s project overages, there is an inherent desire by project planners to be optimistic while selling their brain-child in order to get it approved. We can see this happening repeatedly with elements of the Olympic Games, which haven’t stayed on budget in decades. Consultants may also feel this pressure in order to win business in the short term.

Result: Stakeholders feel deceived, and the program developer or consultant receives a tarnished reputation. Often, funding for future projects is very difficult unless leadership is replaced.

What you can do to prevent it: Recognize that usually everyone will be better off in the long run if estimates are as accurate as possible up front. If you’re worried that you’ll lose stakeholder approval by coming in with a longer and pricier schedule than expected, you will be better served by explaining the estimate and instilling confidence that your plan is realistic.

Intentionally Aggressive Plans

Details: A schedule or budget is intentionally aggressive in an effort to get staff to work harder than normal to meet targets.

Result: Best case, this leads to high employee turnover within your organization and burn out while attempting to meet aggressive goals. Worst case, this leads to the “we’re already late and over budget, what’s another few weeks on top of that” mentality, resulting in more harm than gain.

What you can do to prevent it: Schedule realistically and remind your team that finishing early and beating their milestones is desired, then reward them when they do. It’s easier to reinforce just how important milestones are when you aren’t missing them all the time.

Insufficient Time for Innovation

Details: When designers are expected to come to a conclusive, innovative solution given only a whiteboard and a limited chunk of time as opposed to allowing them to ideate, prototype, and repeat as often as needed to converge on the right solution.

Result: A hastily designed device can create a poor foundation for the rest of the program and result in overages later on.

What you can do to prevent it: When estimating, put aside enough time to collect unbiased data (site visits), document what the user and business actually need, and re-imagine the product as often as necessary to ensure you’re starting down the right path to make the right device. Don’t forget that as long as you’re collecting data, the design may need to change. Putting aside extra budget for early adjustments will save even more time and effort later.

Misalignment on the Scope of a Minimum Viable Product

Details: Creating a simple “Minimum Viable“ product does not necessarily equate to a big reduction of the required effort. Simpler medical products are certainly easier, but still require full design and manufacturing development, including all documentation and safety testing. They typically are not a fraction of the effort required for a more fully featured product.

Result: A misalignment between the development and management teams on this topic can lead to pressure to significantly (but incorrectly) reduce estimates whenever small features are removed.

What you can do to prevent it: The design team and product owner should clarify and agree during the estimation process on the actual expected time and impact for each additional feature.

Insufficient Understanding of the Testing Process

Details: Where testing is defined to include only running tests, without the inevitable troubleshooting, fixing, and re-testing needed when things don’t go according to plan.

Result: As testing is often conducted at the end of a program, failure to leave adequate time results in a delay at the penultimate moment, when funds and time are running short.

What you can do to prevent it: Test early, test often, and be realistic about your expected testing failure rate and what will actually happen when tests do fail.

Keep vigilant against these five issues to prevent program budget and schedule underestimation. Be sure to manage optimism creep, create an accurate program plan, and help stakeholders distinguish tempered optimism from a lack of commitment or ability. A larger-than-desired program estimate might mean a difficult conversation with your investor or boss up front, but stable projects that stay on track and meet their milestones inspire excitement from their contributors and trust from their stakeholders. These will pay off in spades in the long run.


1. By definition every overbudget project is underestimated, but in this article I differentiate between issues that happen despite the best possible plan and information available at the time versus systemically underestimating effort and time.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.