R&D projects are occasionally cancelled. This means that a company’s money, talent, and time was spent on R&D, and no product was ever invented that earned money back to the corporation. Can a cancelled project ever be considered a success?
But how can that be? The company lost money on this project. Yes, that’s the case. But it is successful if it prevented a much larger loss. Let me explain.
We all know what a successful project looks like: A product meets all of its development time and cost goals. It is then released to manufacturing, meeting its cost and capacity goals. In the market, it meets its revenue and profit goals. Its profits recoup all its development costs, and then some, it delivers growth for the corporation. This favorable return on investment is the very definition of a successful product development.
But there is another successful project as well. It starts as a tender young idea. In the early investigation phase all aspects of feasibility are considered: technical feasibility, schedule feasibility, business feasibility. This early investigation discovers a serious problem going forward. It is cancelled before too many of the organization’s resources in people, time, and expense are incurred. This is a successful product as well.
Of the two successful projects above, only the first makes money for the company. But if we don’t accept the second project as a success, we are doomed to create worse failures, trapped by our own definition of success and failure.
Oh, I can hear you say, “But isn’t it better to never start a project that won’t be a success? ” Of course it is, and in the parallel universe where we accurately know the development costs, schedule, gross margin, and sales profile of a product without any study at all, yes – that would be the best strategy. But back on Planet Earth, we don’t know any of those things when we start. Oh, we have a guess and some hope, but not much more.
That’s what the early investigation phase of a project is all about – feasibility. The point is to estimate whether this project meets the time, cost, and revenue standards for a successful project for that organization. What are the technical breakthroughs and advancements needed? What are the risks, and can they be mitigated? What are other key success factors? What talent must be deployed for success? What are market and competitor risks? How does this product impact the revenue of other products?
The goal of the investigation phase is to determine whether the product will be a success. Ideally, it is laser focused at answering that question, so the organization can make a speedy determination to go forward, or not . The product may be dependent on several breakthroughs, are they all feasible? It is not necessary to be precise about the business return on investment; that comes at the next phase. However, it must be determined to enough precision to know that it will exceed the threshold of viability, even if we don’t know by how much it will exceed that threshold. Obviously, it must identify any showstoppers as early as possible, or come up with the creative solutions to get around them.
It is not sufficient to predict a profit. There is an opportunity cost whenever you deploy a company’s finite resources. In our sister publication, EETimes , I once wrote a column Engineers Should Study Finance: 5 Reasons Why. There I showed that engineers and engineering managers constantly make business decisions as they contemplate tradeoffs. At the very end of the column I asked what metric is a better ranking metric for projects: NPV (Net Present Value) or ROI (Return On Investment). It’s something that even finance people occasionally get wrong, assuming an equivalence of the two. The answer, which I later gave in the comments, is ROI.
The reason I bring this up, is that an organization has more ideas than resources. There is an opportunity cost to pursuing any project- could you have invested in a better one? Here’s a way to determine that threshold. Rank each project by ROI from the best ROI to the worse. Start at the top and go down the list until you run out of resources. The ROI of the last funded project is the threshold the company should use for any projects going forward. In theory, that last project in the list is the one that would be sacrificed for the new project. That is why sacrificing it is the company’s marginal opportunity cost .
There’s a dozen caveats to this technique. We’ll ignore those for now. But over time, an organization learns what ROI is needed to be viable and meet their growth goals. If a new project can deliver superior ROI – do it. But if it can’t – cancel it quickly and move on to the next better project, perhaps that last project on your list. This is particularly true if there are technical or cost issues that can’t be solved.
Technical feasibility is paramount. If a breakthrough technology is needed, give your teams time to creatively try to solve the issue. But if they report the project is not overall viable, that's a successful outcome too. Cancelling a project quickly in these cases is a success. If you keep that in mind, you may be positioned to take more risk, and explore more options, as you feel comfortable cancelling or redirecting an investigation early. Make your teams know that this considered success too.
However, if you are trapped in a definition of success that only completed projects are successful – you will complete whatever you start, whether good or bad, no matter what resources and talent are removed from other projects.
And more likely than not – that truly is a failure.
Originally posted on Embedded's sister site, EDN: “A cancelled product development – success or failure?.”