Failure to launch - Embedded.com

Failure to launch

EDN magazine conducted a survey of the electrical engineering profession recently. Most of the data is proprietary, but in his May 11 column Editor-In-Chief Maury Wright revealed that, worldwide, only 59% of our projects reach the market. In Europe only a meager 45% get shipped.

I don't know how much effort goes into the average cancelled project. Are these abandoned at the 50% completion level? 80%? Is all of the engineering complete but then marketing decides they don't like the product's look and feel, or do the recurring costs give accounting migraines? Presumably the amount of wasted engineering is staggering. In an average high tech company engineering represents 10 to 20% of costs. If about half of that is wasted, well, that's about equal to most outfits' after-tax profit.

Now that's a number that should give accounting and the CEO gas.

Cynics might call this a full-employment program for engineers.

Where does the fault lie? Have we developers so missed the schedule that there's no need for that wonderful widget anymore? Has marketing so misread customers' needs that we've built a white elephant? Or did funding dry up, or the company go bankrupt?

If one studies airplane incidents one finds there's never a single proximate cause of the disaster. Several factors develop, sometimes each quite small, but all synergistically contribute to the tragedy. Perhaps these cancelled projects are subject to the same sort of complex drivers.

Sometimes I'm called by management in various companies to give insight into a troubled project. It's amazing how many of these suffer from the same general sorts of problems. Typically engineering has responded to too many needs, too many disparate directives from too many stakeholders.

The projects tend to look the same: lots and lots of middleware layered on top of many components in an attempt to abstract out every sort of behavior. Engineering hopes against hope that this layering will let them toss in all sorts of additional functionality as it's discovered during the project's evolution.

Pretty soon it's a hopeless hodgepodge no one understands that runs too slowly and does too little. All too often the only recourse is to start over or just give up.

Yet never do these companies study what went wrong to create a model of behavior to avoid. It's amazing how many ultimately repeat the same dysfunctional process, with the same disheartening result. None of these are small projects; they typically burn tens of millions of development dollars.

With CEOs cutting wages, benefits, tools and even stationary in an effort to squeak out just a bit more profit, wouldn't you think that they'd be all over this level of wasted expenditure? There's so much we do know about building complex products, and so much we can learn from our mistakes and those of our peers. Yet such “lessons learned” evaluations are rare.

What do you think? Why are your projects abandoned?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at . His website is .

Reader Response


The costs to a failed project are more than just money. A failed project can cost a company good employees, who may quit when the recognize a project is failing.

On at least 1 failed project I was involved in, we were aware the competition had a similar project with similar technical problems. By the end, the goal was to outlast our competitor. We did. One day after the competitor's project was abandoned, we shut down our project.

In addition to all the money spent on the abandon project,two good engineers left the company when they realized the project was not going anywhere.

Looking back, there was no post-mortem on the project. In this case the reasons were most of the project team involved were no longer available and everyone was so tired of the project, no one wanted to look at it again.

– Bob Bailey
Arlington Heights, IL


I think a quick review of your previous articles sums it up pretty well. Embedded projects are so cost sensitive, safety critical, or tightly kept national/corporate secrets that the decision makers just keep trying to make anything in house. In defense industry they do not have a choice. In other fields of embedded world the proper startup of a project including scheduling, tools, and design validation seems to be just too expensive. The unfortunate fact is that those expenses spared in the early stage of project will amount many times more in terms of wasted work hours while developers try cope with non-uniform developing platforms etc…

Another issue is the lack of the art of engineering in embedded projects. We don't build systems, we try to create them.

– Jussi Vnsk
Tampere, Finland


ok…Try this one on for size:

According to experience, and many discussions with VC's, we may ascertain the following, (anecdotal numbers):

1. For tech-startups, (whose sole purpose by the way, is to create new technologies for sale to a very large markets); The acceptable VC-success rate, (not-going-bankrupt), is about 1 in 5.

2. This 'VC-success rate' includes any of the 'take-out' strategies: buy-out, sale of assets, limping along in burn-out purgatory, somehow avoiding chapter-11 to chapter-7, and of course going public…> (the home-run). In all of these take-outs the investors will somehow recoup their investments and get something a little extra

3. Of course, the home-run encompasses about 10% of the 1 in 5. This yields an approximate 1 in 50 chance of success!

4. And again, after the 1 in 50 of going public, most of these entities are not going to yield the true home-runs, (ie, the greater than $250M/yr company). Maybe about 5% of the 1 in 50 go this route. This leaves us a .1% probability of this level of success! or roughly 1 in 1000 success rate!

Now…The reasons for not hitting the 1 in 5, or the 1 in 1000 for that matter are usually as follows:

1. poor chemistry within the core management team
2. unfortunate timing of the technology, (usually too-early, sometimes too-late)
3. unrealistic expectations of schedules
4. unrealistic expectations of dependant/support technologies
5. unrealistic expectations of cost and delivery targets
6. poor execution, (both marketing and engineering).

Note: I placed poor execution last.

How's that for failure to launch??

Couple this with working 80+ hours/week startup mode! It is no wonder that my VC-friends say to not contemplate doing a startup if:

1. You are having troubles at home, (sick relative, marital problems, teen-problems)
2. Having financial difficulties, (out-of-work)
3. Having any kind of health risks, Believe me…any indication of this is a real deal-killer both to new customers and investors!
4. Starting a family, (unfortunately, this one is too true, and I have to put this one out there).

– Ken Wada
Sr Embedded Systems Consultant
Aurium Technologies Inc.
San Jose, CA


Here's one for ya!

Our company was building a Collimator with a 6.8 meter highly polished mirror for a major aerospace company. It was going to be used to test the imaging properties of SAT's before they were put into orbit. They didn't want another “Hubble”. We were subcontracted under a major university to do all of the big steel and control systems. Our company had to “stop work” because the major university violated the contract. Basically, they wanted changes and refused to pay for those changes. We were roughly 75% complete with it. If I recall correctly, it was a $34 million contract. What is 75% of $34 million? The case was taken to court and the jury awarded our company the win… just a few weeks ago.

– Steve King
Tucson, AZ


I think the primary reason for engineering project failures has to do with the industry's inability to understand the true nature of computing. Unfortunately, the Turing Computing Model does not shed a proper light on the matter. As Daniel Hillis recently pointed out, we need a new general theory of computing. The TCP is not it.

Consider that a software program is a behaving machine in the same sense that a biological brain is a behaving machine. The essential nature of any behaving machine is that it is a distributed system of elementary signaling objects at its core. That is to say, communication is a major part of the essential nature of computing. By adopting a signal-based, synchronous software model, we will, in effect, eliminate the data and event dependency problem that afflicts so many complex projects. This is the silver bullet that will slay the software unreliability wherewolf once and for all.

– Louis Savain
Software Engineer
Miami, FL


I agree with all your points. I'm sure you've realized that it seems that non-technical career advancement ( product managers, segment managers, accountants, sales ) are often not tied to successful product development cycles. The current project I'm working on, while having all the typical problems you describe, has also had 4 different product managers who are suppose to be our continous ear to the customer's requirements. And guess what, their 'visions' don't all align…..

– Todd Batzler
Sr Staff Engineer
Appleton, WI


The designs I do are not as software intensive as those of most of your readers, but I have seen a consistent pattern that results in projects that just sort of “fade away”, rather than get canceled. That pattern is a combination of feature creep and lack of committment to providing resources to do timely development and, in particular, testing. We also have had projects that were designed and given to production, but were never advertised or marketed, so the few that we built just sat in inventory. Eventually, they become outdated. Sometimes, we can do software upgrades, but not always. I believe that this is because of the lack of understanding of how engineering is really done, especially electronic designs (as opposed to purely mechanical designs) and a mindset that views engineering as money-wasting overhead.

– Dave Telling
Carson City, NV


It's a confluence of many things, as you said. Management and customers typically start out with fuzzy product requirements. The customer wants the product of the century for under $50. Management wants to land the deal, so they agree to deliver. They then turn engineering loose to hack it into existence in record time to meet the market window or the customer's arbitrary deadline (usually unrealistic). Engineering, as you correctly point out, attempts to devise the universal API which will accomodate any feature the customer wants or needs in the future. With this approach, how can any project succeed? What is needed from all parties is a more disciplined, focused effort. Customers must accurately determine their needs and articulate them clearly. Management must have the discipline to discourage feature creep. Engineers need to design and implement what is needed to do the job; no more, no less.

– Rick Walsh
Mt. Laurel, NJ


I work at a small company with an engineering staff of 4 to 5 that are predominantly younger and have less experience, myself included. Our workload includes about 15 projects or so per person. The projects come to us from our sales staff who rarely get complete description as to the application and required product.

I feel that the lack of knowledge and experience of our engineering is partly at fault but that sales is equally to blame as they promise results without delivering the necessary information needed to create the solution to customers' problems.

I would say the success rate of projects that I have worked on is around 5%, as the projects I work on are more of the “grand slam” applications for us and are killed due pricing or delivery issues.

Engineering is often frustrating because I feel I put my best work into something, customers say it works great and we never hear from the customer again. I will keep stepping up to the plate and keep swinging. My only wish is that sales would take better look at the application and go after the project that looks more like a sure thing than going after anything and everything.

– Josh Blackann
Design Engineer
Canfield Connector
Youngstown, OH


I think the process is more complex.

The decisions in a project are taken by the management. Their decisions have to give a profit in the long term, but there's a catch. It also has to generate a profit for them personally, money or career wise.

The decision to sometimes scrap good projects or grant money to hopeless projects can be based on incompetence, but also it could be a brilliant showoff off the famous “social competence”. Why you ask. One famous management method is divide and conquer. If there's a profit you win, if there is a loss, use it to get rid of opponents. Now what to do about it, that is if you look from the stockholder's view.

1. – Hold management accountable.
2. – Have competent managers. (Technically)
3. – Socially educated programmers that have integrity and social competence not to “buy” everything told to them.

When everyone is pulling in the same direction, then, I think it is easier to address other issues. Of course there are MANY other factors but I think this is one of the more important ones that stockholder should consider. Oops, do I talk too much. Can't help it, I want practical results. Canceled or failed projects won't cut it.

– Martin Lundstrom
Stockholm, Sweden


Hi,

I worked for couple of product development companies and my observations are:

I'm thinking that the need of a particular product may vanish and the management loses interest over further developemnt of the product.

To mitigate this, the absolute need of the product should be worked out initially. There should be demand for the product if the product is launched. This creates interest for management and in turn engineers. And more chances of launching the product.

– bhaskar p
Engineer
Hyderabad, India


41% of project failure rate does warrant some serious discussion. But does this mean there are a lot of incompetent managers, sales persons and engineers all around the world? Maybe. But if this is the only reason for failed projects, then it indicates that there are more incompetent managers, sales person and engineers in europe than anywhere else. HMMM… , can this be true? Maybe we should also look at other factors beyond human incompetency.

– Joe Zhou
software engineer
delphi
Kokomo, Indiana


Hi,

I worked for couple of product development companies and my obersvations is:

Thinking that the need of a particular product may vanish and the management loses interest over further developemnt of the product.

To mitigate this, the absolute need of the product should be worked out initially. There should be demand for the product if the product is launched. This creates interest for management and inturn engineers. And more chances of launching the product.

– bhaskar p


It's interesting reading, but it seems a bit different in Automotive. Generally speaking, there are two types of project that get canned: those that were leading to a bid, and so were expected to be either short lived or to run on to a 'proper' project; and those that are 'in-house', or just a research project. I can only recall one project in 17 years in Automotive that was canned by the customer. But I can't tell you what it was, or I'd have to shoot you…

– Paul Tiplady


How many of these projects start at the quotation stage? If you have 5 bidders on a project, then there is a guaranteed 80% failure rate.

– Don Cazenovia

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.