In general companies do a good job recording problems and issues about their products. In specific industries elaborate problem records, trend analysis and resolutions are mandated by regulators. They may operate a Failure Record and Corrective Action – Preventative Action register. However what commonly fails is a formal register regarding Ideas for improvement i.e. not driven from failures. Ideation as a process is more than a box for personnel to deposit their thoughts about products. I once worked with producer/retailer company that claimed that out of the 1000 innovations per year 70% of their new product introductions flopped and failed to yield results they had planned for. Can you imagine the revenue potential this represents. If there was a way to half this flop rate, it would make a big difference to the bottom line. How much would this equate to.., take for example the lost aggregate potential revenue of specific products or categories that failed to reach the sales ramp-up phase in the last two years.

What would be the solution…. Today companies, with little effort and cost, can introduce a collaboration platform that would register ideas. Suppose you could populate this platform with (process-to-follow) templates i.e. how to move this idea further, see what earlier projects had similar patterns and above all can you imagine the potential that you could reports an internal ideation pipeline the same as you do with your sales forecasting.

Not to embark on Microsoft marketing, but SharePoint is an example of a capability of such collaboration technology. With again little effort companies can build a complete (hosted) ‘environment’ around the Ideation process. Personnel that generate these ideas can be those directly involved with marketing or product (sustainment) engineering or even those that are in the field, for example trend scouts, all would find a single source of information to record their observations but also share opinions regarding marketing potential. Operating such Ideation framework, you can would support the formal innovation process from internal surveying, reviewing and analyzing the potential and challenges and risks you may encounter and need to consider. Some level of Quality Function Deployment may be completed and recorded also. So basically you can easily address the information management needs and establish a foundation to drive a Structured Ideation process.
As companies hit a specific Ideation maturity stage/gate, more personnel and financial resources may be allocated and a formal ‘gated project’ may be decided. Here comes Schedule Management into the equation that I talked about in other posts. Companies may want to operate specific new product introduction work breakdown structures and schedules for specific product categories. And here is the crux, these ‘standardized’ gated schedules then become success teamplates and the base for continuous improvement. It would make new production introduction process structured and predictable which should ultimately have a positive influence on the right product for the right market and corresponding sales success.

Lastly, as an idea moves forward and reaches maturity, marketing and product development start to exchange product requirements causing ‘requirements engineering’ to kick in. As more requirement information is generated, the need for requirements management is imperative and as more aspects of the product are being defined (project brief) we then gradually transition into the formal Product Lifecycle Management defined processes.

Many companies implementing PLM consider workflow to be the panacea to many process related challenges. In the past when PLM was a relative new phenomena we tried to model  company process in a series of workflows. The abstraction that was needed was a far cry from the real processes and engineers were by-passing the implemented workflow functions. Also we found, specific processes for specific categories of products were needed and further that specific ‘organic’ processes were common regardless of these different product categories.

We ‘flowed’ deliverables through these workflows rather then the triggers that define the items that are expected from the process. The abstracted trigger objects are in fact different types of ‘Requests’ for example; work request, change request etc.. Requests regarding a task may have supporting items… you may call these requirements or specifications, in fact to which the deliverables need to comply with. Now.., how do you structure the right flow of events to trigger the execution: A schedule…, not a workflow. Yes; you would use the workflow to route the schedule trigger items but the schedule in itself is a Work Breakdown Structure.

The schedule assures that the right disciplines at the right time receive the Request (and authorization) to commence with the work (task). You may call it the engineering variant of the kind of functions that are common in manufacturing i.e. the Manufacturing Execution System (MES) and in this engineering case the Engineering Execution System (EES). It is my experience that the maturity of EES’s that companies operate is low. Usually it is a combination of enterprise and desktop applications. Consistent usage across projects/programs, process integration and technological interoperability are major challenges.

So basically the schedule is the structure of events that need to take place.. you could call it a work breakdown structure (WBS). So for different product categories there are different ‘project’ schedules and WBS’s. In principle you would have schedules for new product development and its introduction, change schedules initiated by ‘change introduction boards’ as well as ‘product sustainment’ schedules.

What they all have in common are these ‘organic’ processes, for argument sake let’s call these verification and release processes and surprise….; these are the processes that are usually regulated per industry or defined as best practices for example your internal procedures as defined by regulators or derived from ISO standards or better CMII.

In highly regulated environments you may see these implemented even as ‘V-models’. The WBS, going down on the V,  determines the full design process by the different disciplines i.e. the product system breakdown from low to high fidelity. Going up the V the verification and the release processes.

As stated earlier there will be different WBS’s for different purposes. Probably defining the first set of WBS’s are a challenge but the reward will be huge. As it becomes a standard approach for doing specific things, it would then form the basis to gradually apply Kaizen and the 5S’s campaign you would apply to Gemba i.e. the (work) place where it all happens. As companies get smarter defining and optimizing these processes the cost and schedule outcome would also be better predicable and it would provide an opportunity to ‘front load’ such WBS structures with all product related system engineering templates and required documents. Lastly these WBS’s would also form the basis of your project management with or without your management approaches such as earned value management.