A dedicated technical staff is not required to perform advanced development activities in most organizations. With integrated advanced development, simply allocate a small percentage -- say, 5 percent -- of each engineer’s time each week to evaluate a technology assigned to them. Assignment should be aligned with a product roadmap, and be based on the engineer’s interests and the needs of the organization.
This approach leverages engineers’ natural curiosity and their desire to learn new things, but keeps the activity aligned with organizational goals. Engineers spend this time gathering information about the technology, conducting experiments, creating concept prototypes, and identifying potential changes needed within the company -- all in an effort to learn how the technology works and how best to incorporate it into new products.
When should advanced development happen? In an ideal world, technology evaluations should be completed prior to the start of a new project. This provides input for planning, and removes the learning curve from the critical path of the project.
When time-to-market is a high priority, and schedule is greatly compressed, advanced development work can be done in parallel with the project. One approach can be to introduce the initial product without the new technology and then have a secondary release once the new technology has been fully integrated. With integrated advanced development, these activities are continually conducted by engineers, in tight alignment with product roadmaps, to ensure that resources are focused on the most immediate and relevant needs of the organization.
Implementing integrated advanced development can help reduce the risks of new technology introductions by improving initial project planning, maximizing scarce development resources, keeping engineers engaged with the latest technology advancements, and promoting cross-functional cooperation and awareness.
I think Bill shines some light on a big issue that doesn't get the due it deserves in terms of advancing the cause of more effective, more efficient product development. Process improvement is one of those necessary evils that people love to gloss over, particularly engineers who often want to cut to the chase of tinkering with and discovering new innovations without being burdened by what they see as boring, institutional boilerplate.
In reality, that mentality couldn't be more wrong. Bill lays out the very strong case for instituting processes within engineering that not only enourage and promote the exploration of advanced technologies throughout the entire engineering team, but also to do so early on in the cycle so potential problems and potential better solutions are found earlier, rather than later when it is too late and far too expensive to make changes.
Beth, thank you for your comments. You have highlighted another topic that I will be writing about soon, and that is the tendency for development teams to stick with only one design concept, which creates a ripple effect of difficulties in later stages of the project.
Bill, I hope companies will pay attention to your recommendation that engineers should be spending 2 - 3 hours a week on advanced development activities. It's absolutely essential for engineers to stay on top of the latest technology -- as much for their own good as for the good of their employers. And it's essential to do your homework before embarking on a new project. To a large extent, the success of a project is determined before the project starts. The best solution is a continuous commitment to advanced development.
Nice article. The 5% recommendation for advanced development time is reminiscent of the old (maybe it's still exists) 10% rule at 3M. As I recall, 3M actually used to allow engineers to set aside 10% of their time to work on any kind of development (advanced or otherwise). I believe that's how Post-It Notes were created.
For most companies, five percent devoted to assessment is a more manageable and realistic goal than the 20% that Google supposedly allows employs to devote to researching stuff that's not part of their job. At the same time, even 5% is a lot in the high-pressure, fast time-to-market, lower headcount world many of us work in. Let's hope they take your advice, Bill.
Oh, please! Management giving engineers or anyone 5% of their hours each week for 'non-productive' (their words) work? The chances of that in today's world? Approximately zero. Sure, there are a few companies (and high 5's to them!!) that do. And probably many more who used to. But today? Hah!
So I am a pessimist - well, I've been around for a long while so I guess I am entitled to be.
In the real world, the drive to efficiency and productivity has firmly shut the door on most (I almost said 'all' but that would be pessimistic) non-funded, tightly controlled projects. In some (most?) companies, the marketing folks have total control over the budget reins and, if a proposed project does not have a specific cost savings, it will NOT be funded. Such an environment (very oriented to immediate and short term financial results) does provide for a healthy and profitable company.
Even 20 years ago, my attempts (even as a manager) at implementing even limited opportunities for projects outside the normal marketing centric world. The answers ranged from a flat 'no' to '..you can spend as much of your time as you want' (sure, when I was already working 60+ hour weeks).
@BobGroh: You're probably right to be pessimistic about this. But if companies want engineers to focus all of their energies only on current projects, they are potentially undermining the success of these very projects. As I pointed out before, a big part of a project's success is determined before the project starts. Companies neglect these "pre-Gate Zero" activities at their own risk.
@Dave Palmer: you are totally right. But it is a very hard sell. And it doesn't stop just with 'pre-Gate zero' activities. At my last employer, they were very big on design reviews all along the design process. A very good thing.
BUT the design reviews were just a meeting in a conference room with 30 or 40 other engineers there for a couple of hours. You talked about your design, got a couple of comments and the meeting done. You then wrote everything up (comments and responses) and, bam, all done.
How much better if the design review had been a real design review where you had 3 or 4 engineers from other departments or projects who spent some real time really digging into your design. Well, I tried doing that one time and got roundly slapped down by the managers in the other department - they were not about to have their engineers taken off their present assignments to 'work' on your project. No way. Anything more than one meeting (couple of hours) - nope. Not here. Not now. Not ever.
Bob, I agree with your comments on design reviews. Early in my career I was with a company that was really good about holding design reviews at multi-levels, inviting the right people and we always got really good feedback. Now most companies I deal with believe "design review" is a dirty word or don't know what it mean.
Some common things I've found are companies don't hold design reviews, material is distributed at the design review or a day in advance, design is given to one independent person to review. Trying to explain that people need time to review the material or even explain the importance of a design review was taking more years off my life they it was worth.
I don't think enough importance is put on design reviews, having the right people, providing sufficient time to review material to get good feedback can save a company time and money. Ideally design reviews attendees are invited because their expertise is needed in a specific area, so what I would do is highlight for each attendee's specific area I would like them to review, if they didn't have time to review the entire package. What I found was most would make time to review their specific area. Otherwise, more times than not they wouldn't review anything. I tell people if you have a review with no action items then most likely they didn't review the material. When will some compaies learn pay me now or pay me later and if you pay me later it will cost you a lot more.
I should have replied to your post, but instead started an independent comment on this article.I should have replied because I'm drawn to your comments as if you read my mind; it seems we have worked in the same places.See my independent post a few paragraphs down the link, entitled, "Advance Dev is a seperate Group." Thanks for your comments!
The 5% rule sounds great!! But like Bob said not in today's world. I've had companies start out with something like that but it soon got lost in the "everything is HOT" so that 5% got eaten up by you trying to put out fires or just keep up with the daily duties.
"This approach leverages engineers' natural curiosity and their desire to learn new things, but keeps the activity aligned with organizational goals. Engineers spend this time gathering information about the technology, conducting experiments, creating concept prototypes, and identifying potential changes needed within the company -- all in an effort to learn how the technology works and how best to incorporate it into new products."
I want to go to work for you, Bill! This is a test engineer's dream. And while I agree with your ideas completely, unfortunately most companies I have observed remain short-sighted in this area. The current economy has caused many companies to run on smaller staffs and people are required to handle larger workloads, especially where down-sizing has occurred. While I absolutely advocate your ideas, I am thinking that we won't see companies operating out of fire fighting mode until the economy gets better, no matter how much sense it makes to do otherwise.
I respectfully disagree with the idea that advance development efforts can be done by the same product group spending 5% of their time on advance research.
I've spent my entire career at big companies (household names you've all heard of) and have logged years in both product development engineering and in advanced R&D roles.The best solution to keep profitshigh (meaning continual new product releases, i.e. cash flow) -- is the one that big companies do – they segregate the two roles.
For the Development Engineering Team, their job is to get the product to market.Their effort is Schedule and Cost driven (aren't they always-?) and they have aggressive milestones and timelines to meet. They cannot afford the risk of obstacles caused by various "unknown's" such as Bill is referencing.
The solution is the Advance Development Team, a separate team who works on bread-board and proto level products to test and characterizes the interaction & behaviors of the desired new feature.For example, to use Bill's example of adding a modem to a product; an embedded modem on a dual transceiver board facespower drain issues, transmit signal strength interference, and cross talk between circuits,-- just three of many problems that can happen, which the Advance Development Team must examine.
There are always solutions – sometimes even easy answers – but the Product Development Team doesn't have the time to mess around with ANY problems.They need to keep their heads down, designing with only "known's," and maintain the sprint toward the goal of the market launch.
To Bill's point of the engineers natural curiosity as the catalyst forsuccess; I do agree with that; but even AdvDev gets routine after several programs. So a good solution is to rotate your staff between the two groups to keep them always fresh.They appreciate the change of pace.
Many companies I have worked with don't have the resources available for a separate group focused on Advanced Development. They barely have sufficient development resources to introduce new products with tight schedule constraints. Therfore, allowing the development engineers a small portion of their time to investigate targeted technologies helps mitigate the risks to schedule and product quality. For Advanced Development to be effective I think it takes the commitment of visionary leadership and a management team who can see the big picture. For those companies that have the ability to support a separate Advanced Development team it becomes crucial that they provide for a smooth transition of the acquired knowledge to the product design team.
Bill, I agree that a segregated AdvDev team takes big bucks – that's why I prefaced my comment with my history of working in giant corporations that are household names. They have the cash to afford that. Further, I concur to your point that transition of AdvDev into the product groups is a critical transition that often has roadblocks.I have lived that, as well.(the "NIH" {Not Invented Here} syndrome drives engineering egos all too often).
All of your points, I have to say, are good valid approaches which I would also encourage smaller companies to try.Except, in reality, the shared-time concept (the 5% idea) is theory not often successfully reduced to practice.
An analysis of what’s needed to implement Design for Disassembly and Design for Recycling results in eight strategies engineers can use to design an intentional end-of-life stage into their products.
Government regulations, coupled with growing consumer sensitivity about data and identity theft, require that data storage organizations demonstrate proper protection and due diligence in protecting sensitive information stored inside datacenter enclosures.
When a crane doesn't have a monitoring system, crane owners schedule service every six months and simply scrap the parts they replace, even if a part has had little use and doesn't need replacing. This can cost thousands.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 3
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
A quick look into the merger of two powerhouse 3D printing OEMs and the new leader in rapid prototyping solutions, Stratasys. The industrial revolution is now led by 3D printing and engineers are given the opportunity to fully maximize their design capabilities, reduce their time-to-market and functionally test prototypes cheaper, faster and easier. Bruce Bradshaw, Director of Marketing in North America, will explore the large product offering and variety of materials that will help CAD designers articulate their product design with actual, physical prototypes. This broadcast will dive deep into technical information including application specific stories from real world customers and their experiences with 3D printing. 3D Printing is
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
5 
