Menu

The Problem

A Known Problem

If employed in the high-tech device industry or similar, you probably have the demand of 100% tracking of the product development process and have to comply to quality standards. These demands are too often incorporated into a “passive” quality system i.e. not automating the tasks and processes in a transparent way. From R&D guy’s perspective the quality system often is working in theory but in practice it is virtually impossible to meet demands unless spending too much time and resources, and loose the competitive edge and/or having the side effect to burn out people.

As a result of this you often will have lack of traceability due to:

Inconsistence
Incomplete information
Missing and broken links

These problems will occur directly in the development process or problems specifically with:

Notes of Decision
Breakdown and execution of requirements
Feature-requests
Notes of Decision
Product structures
Change-requests etc. and mapping these to product-road-map
Bug-reports
Verification/validation-reports
Product Specifications
Test-specifications
Designs
Business process output (deliverables – products, product sheets, manuals, instructions, release-notes etc.)
Change-orders
Work-instructions
Test-reports
Production information like BOM’s
Supporting parts (ex. options, tools, spare parts, etc.) and systems (ex. production test systems etc.)

In addition, there will be a need to cycle through the above over and over again through-out the life-time of the product while keeping 100% traceability in business-processes as well as in product-data, changes to processes as well as deviations caused by projects making exceptions to the quality standards. The product development process is a very complex process.

Finding the Right Information

It is often very time consuming to find and reuse product data, a task which is done very frequent by most people in the company, and when you find what you are looking for then you may not be completely sure that you found correct version, latest version or best version.

Making Changes to the Product

Often people feel uncomfortable contributing to product documentation due to the complexity and burden of the quality system, and the great risk involved. Most of the above process- and product data requirements are not just requirements, they are fundamentals to get the product to the marketplace and thus something you cannot compromise; and unless you have a good system to support process- and product data you regularly will fail to deliver as planned even for the smaller projects. The massive manual work managing process- and product data increases risk that quality problems would sneak into production, especially when an existing product is changed during high volume production.

The Outcome

Typically, the most significant business risk for this type of business is product quality problems introduced into high volume production and thus directly related to process- and product data. Epidemics in production and field may hit with severe consequences. Often too much time is spend keeping track of process- and product data. It feels like walking with a heavy burden on the shoulders instead of driving a suitable vehicle. You will lose focus from the very important matters; the situation drains project management, technical project management and other key-functions from energy. If you feel that the above is a problem in your company only, then please observe that this is not specific to the company; it is a general problem in many companies.

One of the Reasons

The reason to the above problems is often that short term business goals has the highest priority; issues concerning business process reengineering and business systems are subject to long term “political” discussions and typically no decisions for improvements can be made. In addition, the subject is very complex and it may actually be difficult to make the right decisions and execute them successfully. Typically, there is also some resistance to improvements in top management since focus is on short term deliveries rather than improving business systems. Obviously in addition to get priority for this subject the other area of problem is to make people agree on one common direction of action in this subject.

Quality Audits

Whenever there is a quality audit from customers or authorities you probably will have to clean up things to have a good chance to pass the audit. You may be lucky to have “golden” projects for the audit and hope that other projects are not audited. You probably will have to allocate resources for cleaning up to avoid painful deviation reports which would consume even more resources and might not improve the situation substantially, if at all. In some situations, deviation reports, due to the fear of losing the formal quality certificate can be used as a powerful tool to get priority and initiate changes, but history proves that it may also just create another fragment to a quality-system quilt and may not improve the product development process performance or even the overall quality of execution. A failed quality audit may introduce risk of losing orders, customers and even permission for sale on certain markets if for example formal requirements from authorities are not met. There is an obvious risk that such a situation will make your company suffer in the global competition and you will lose the competitive edge, and bring products to the market place too late and/or with too low quality. The above problems may scale up if you are your projects are scaled up in size or complexity, or if your organization experiences positive or negative growth.

Read more about how you can solve these kind of problems