Posts

When looking at undertaking a NPD (new product development) it’s always tempting to take short cuts in order make the development more attractive to management or a client. I’ve lost count as to the number of times that I’ve heard,

 If we had the budget and time, of course we’d do it properly.

The problem with this, is that after doing this several times, it becomes the norm, and taking short cuts and in order to potentially save money usually leads to more problems in the long run.

 Follow the yellow brick road

For those of you who remember the Wizard of Oz, following the yellow brick road led Dorothy to Emerald city. The NPD process is the same, and is nicely described on Wiki and many other great resources, so there’s no reason to ignore it. If you can’t get the information out of clients, propose a workshop or private session, where you can discuss all requirements and get a clear picture of the clients vision/expectations. Remember that before taking on any new development, you should undertake the task of defining specifications:

  •  User specifications: a document that specifies what the user(s) expects the product (e.g. software) to be able to do.
  •  Functional specifications: are requirements that define what a system is supposed to do. A functional specification does not define the inner workings of the proposed system, and does not include the technical details of how the system function will be implemented.
  • Technical specifications: based on the Workshops, User and Functional requirements, you can finally construct the technical specifications documentation. This document(s) will contain all technical details of how the system will be implemented, and usually includes tables, equations and sketches of GUI layouts and hardware block diagrams.
  • Review: the specifications and findings with the client, and make sure that they understand what they will be getting (i.e. the deliverables).

Although it’s tempting to ignore these steps and start playing with software, following the aforementioned steps keeps you focused and almost always leads to shorter development times.

About the author: Sanjeev Sarpal is director of algorithms and analytics at Advanced Solutions Nederland BV. He holds a PhD in signal processing and has over 20 years commercial experience with the design and deployment of algorithms for smart sensor applications.

Many hi-tech companies that we have spoken with over the years have struggled to clarify this question, and almost all say that they fall into the D category. Where many say,

we’re not a University.

However, upon closer examination, it would appear that many companies are actually engaged in applied research activities but don’t even realise it or don’t like advertising it. From our experience, research activities can be broken up into two distinct categories:

  • Applied research
  • Fundamental research

Fundamental research is where Universities and research institutes are primarily focused, with the sole purpose of advancing theoretical knowledge in that field via publications and conferences.

Applied research on the other hand, takes the fundamental research findings and applies them to real world application for commercial exploitation. Many companies are constantly on the lookout for new concepts and methods to put them in front of their competition. This could take the form of implementing a radically new scientific method, or even improving their internal processes in order to reduce waste and boost profits.

The latter (also applied research) is currently where many companies are focused (mainly due to the current financial situation), but for the companies who can afford it, there is still some room for the first point.

How do they do it?

Many companies generally hire academics to help them with the translation of these concepts into products, but experience has shown that academics are not the best choice as product developers, so companies tend to use a mix of skills sets, i.e. academic and non-academics in order to get to their products to the finish line.

Academics generally prove to be invaluable at analysing problems and processes and highlighting any areas of weakness, while at the same time taking a pivotal role in the definition of technical specifications.

What about culture and egos?

There are the ego and cultural aspects to consider too, which is especially prevalent with academics. The mismatch with the academic and commercial models unfortunately leads to many focusing on providing the best solution (the academic world), rather than focusing on what the client actually needs (the commercial world).

Many academics consider management as too dumb to understand their fantastic idea.

Good leadership and emotional intelligence are needed to keep the R&D team focused on the big picture, and avoiding the department from turning into a playground for hobby projects. Many engineers and academics struggle with the concept of knowing when a product is good enough, and keep on fiddling with it until it’s perfect.

From our experience, getting clear and realistic customer requirements and then coming up with a careful plan, led by experienced developers is the only way of reaching a successful conclusion.

R, D, or both ?

Whether your company falls into R or D or a mixture of both depends on your business model, but perhaps you actually do more R than you realise. In all cases, selection of a good team that works well together is paramount for success.

Author

  • Sanjeev is a RTEI (Real-Time Edge Intelligence) visionary and expert in signals and systems with a track record of successfully developing over 25 commercial products. He is a Distinguished Arm Ambassador and advises top international blue chip companies on their AIoT/RTEI solutions and strategies for I4.0, telemedicine, smart healthcare, smart grids and smart buildings.

    View all posts