In my experience, you can build a project that's "perfect". In general, you will see the cloud of dust your competition has generated from building someting that has bells and whistles and a working core functionality, with bug fixes and other upgrades seen in future iterations. Very good article.
I was in the industrial test systems business for many years, and although requirements would sometimes change a bit, the very first part of the project was always deciding what the actual requirements were. The unknown target is hard to hit unless you are REALLY LUCKY! Everything after that was "just" engineering. And the time to market was at most 18 weeks, from receipt of purchase order to delivery of a perfectly working system. And, to make it more interesting, the only possible way to make money was to get it right the very first time.
I realize that the pressure on consumer products may be more, but only because of the advertising and the need to beat the competition. But for those products it really does not seem to matter if they are unreliable, or if they only last a few weeks, because the common perception is that they are all trow-away junk.
In addition, I would like to point out the underlying conflict that many engineers have with "time to market" vs "build it right the first time".
The sad fact is in a industry based on rapidly changing technology, it is nearly impossible to get a 100% complete product definition/requirement, that will remain stable during the course for even the quickest development cycle.
Simply making it right the first time.. is not good enough, because the definition for the product is generally flawed and will change before you can create it. I have not seen any method that eliminates this. Management/customers simply must have something to be critical of, they cannot completely define product before hand. They only "know" when it is "right" after they have seen when it isn't "right".
What remains is a variation on what has been presented. The importance of not just "time to market" but a pragmatic choice of expected revision cycle time.
During the creation of most teams .. this means less focus on the product , more focus on speeding up the revision cycle time.. basically, assuming the product definition is never stagnate.
AKA .... Learning the mistakes/pitfalls/product re-definitions as fast a possible.
Taken from the software development world.. "RAD" techniques.
Thanks for this very interesting article. It makes you realize that even with sophisticated planning and development tools, there is tremendous value in the team that invests time and resources into complex problems. Gives me new respect for engineering teams involved in complex system design.
I enjoyed the time to market article. In the industries I have bee associated with it was termed "Rapid Commercialization"
In one company we took product developemet time from an average of two years to an average of six months without sacraficing quality. This was accomplished by the extensive use of PTC products, applying FMEA, getting Vendors and Manufactuing involved at the start of the project.
I know that this is not possible with all types of products but developing a system for design, design valadtion and manufactuing/vendor participation is always positive.
The thing to remember is that in the world market it is not only getting there before the competion with new product, but the quality and cost must be there as well.
Or perhaps the worst is the overly anxious marketing VP leaking press releases for the next generation product before engineering has a grasp on the new technologies- like, er, the iPad 6. It hasn't been officially announced yet, as there are a few bugs to be worked out- like the 60" virtual screen, iMax theatre sound, thought control keyboard, and a power cell that runs on bad breath.
But it should be out by Christmas, if the Apple production facility can just keep their key assembly line workers from jumping out the top floor windows...
Cell phone companies announcing products, and they selling them a few weeks later has made everyone impatient with delay. I think there is something fun and worthwhile in waiting. (If it is only the realization, you didn't really need the item after all.)
Great article. It clearly illustrates how the term "time to market" has become so important, especially in electronics. In electronics, the time window is incredibly small and the development effort, especially relative to embedded software, is so hard to accurately estimate. Combine the situations described here with the tendenancy for engineers to be working on more projects than ever, and you realize why engineering is turning into such a pressure cooker.
I find the challenge exciting when it comes time to troubleshoot unexpected problems. Perhaps it is the fact that I was an electronics technician before I became an engineer. Getting one's hands dirty, or as I tell my wife, sweating over a hot transistor all day, is the best part of my job. Sweat dropping on a touchpad causing problems is right up my alley!
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.