Product Development

Approach

Much of what is to be discussed here may seem very familiar to you, but some of it will not be because we believe in telling customers the truth, as we view it, at all times. We believe in always being honest and open with customers.

Retainer Required

We are interested in helping serious customers. Our time is valuable, just as is the customer's time, so we insist on customers paying a retainer before we will engage our team to help solve the customer's problems. This retainer will be 10% of the expected total project cost. Project startups do require some considerable time and we cannot hold team member's interest unless they know that the customer is serious and willing to pay for what they get from the RACE team. Naturally, the retainer will be applied toward the total project cost.

Partnership Relationship

RACE believes in forming a partnership of equals with a customer when developing a new product. Our team is very experienced in product development and we only want to work on successful projects, so we insist on being decision-making equals with a customer in the following sense. We will do everything in our power to satisfy our customer's product development needs and wants, but we will not assist a customer in "going over a waterfall", no matter how much the customer might desire to meet that end and no matter how much money might be offered to facilitate taking that ultimate "bath". Customers usually love their new product ideas and may not see problems with getting them successfully to market. This is no small point because there are many businesses which will cooperate with a customer in creating a disaster for them, so long as they keep getting paid.

We will not spend a customer's money on a product concept which we have no faith in. The customer must have done some level of market research so that he knows approximately how many units can be sold and approximately what the price target should be. Please see the section on Guidance for New Entrepreneurs for more suggestions on how to do market research. The customer needs to convince us that he will end up making money from marketing our work product. Once he has done this, then he knows that there is a very good chance that the project will be profitable for him and he has a pretty good idea how much he can afford to spend on product development as well as how much the product should cost to be successful. If market research hasn't been done, that needs to be done by the customer before we start product development.

Once development starts, charges accumulate quickly, so the market research needs to be done first.

Similarly, if we believe that the specifications are impossible to achieve in a reasonable time and cost, we will not continue with the project until the specifications are changed so that they are achievable and so that the market will also continue to desire the product.

Finally, if we join a product development effort in mid-stream, we will want to review the market assessment and product specifications before continuing on the project.

Project Management Required

Every product we would work on is complex enough to warrant using project management to control cost and schedule so it will always be used. Other projects may be done without project management if they are expected to be short such as a week long.

Development Phase 0

Development is attacked in pieces. At the start of a development project, a comprehensive plan for the entire project is put together to get an idea of the number of people and the skills which will be needed and how long they will be needed. This gives an early approximate snapshot as to how much a project might cost and how long it will take to perform. However, before work has really started, the exact resources needed for all aspects of the project cannot be predicted with accuracy, unless this is very close to another project which has been done. At RACE we do keep records of past projects and we do learn from them. Still, it is rare to do a project which is close enough to a previous project to allow a precise early plan.

As we work through a project, we will redo the project plan for the phases yet to be done so that the project plan will gradually become firm as it is executed. At RACE we prefer to not work on a fixed cost contract, but to only work on a time and materials basis with regular cost and progress accounting to keep the project cost and schedule in control. This minimizes exposures to both parties and delivers the lowest cost project to the customer.

One of the first things which needs to be done in a new project is to develop specifications for the new product. This cannot be done in a vacuum. It is extremely important in this phase to work closely with the customer's market research people so that the RACE development team has a thorough understanding of who the intended customers are and what their desires and needs are. Nothing kills a product at a worse time than developing a product for the wrong market, because almost all of the development cost has been spent before the error is discovered. None of the time spent on getting the product defined properly will ever be wasted. RACE reserves the right to stop a project if it doesn't agree with the customer's market assessment.

Once product specifications have been defined, then we are in a position to develop a conceptual product design. This may include considering several competing designs through some early level of evaluation, but this approach would only be used where it was not possible to make clear choices. Evaluating multiple competing designs is more costly, so the quicker that selections are made, the better. At the end of Phase 0, all component approaches will be selected, and an overall conceptual design will be completed. This would include word definitions of the system and it's components, sketches of custom parts and possibly solid models of some of the parts.

Phase 1

Phase 1 is the detailed design phase. Purchased components will be selected and incorporated into the system design. All component parts and higher level assemblies will be designed. This includes all electronic components. Software programs will be designed during this phase. At the end of this phase, solid models of all components will be completed and prints will be done for all components which need to be fabricated or sourced.

Phase 2

Phase 2 is the prototype build, test and design refinement phase. All mechanical and electrical hardware will be built in prototype form before the end of this phase First pass software will be written or purchased and will be available for testing before the end of this phase. By the end of Phase 2, enough preliminary system testing will be done to determine all major design problems, and component designs will be redone as needed to solve the major problems. All component parts and systems will be ready to source at the end of this phase.

Phase 3

Phase 3 is the component sourcing, design refinement and manufacturing preparation phase. Final system testing will be done during this phase to find any remaining significant system problems. All component designs will be redone as needed to solve these remaining system problems. Such problems must be minor so that they don't adversely affect sourcing schedules. At the end of Phase 3, the product and all of it's supporting documentation is released to manufacturing for the start of production ramping. All long lead time production tooling must be done by the end of Phase 3 so that production can start.

Project Control Documents

The basic information used to direct and control a product development project includes a market assessment document, a product functional specification, an overall project plan and checklists for each product phase including the deliverables for each phase.

During project execution there will be regular (usually weekly) tracking reports which include summary reports plus detailed progress versus the plan. This last control document provides regular feedback to the customer and helps to keep the project on track.

The market assessment is the total responsibility of the customer to create; the rest of the documents are the responsibility of the project manager, with review assistance from the customer, to create.

The product functional specification is developed to meet the customer needs which are identified in the market assessment document. The overall project plan includes work activities which support all phase deliverables, and the phase deliverables are intended to provide a product which satisfies the functional specification.

Avoid Scope Creep

During project execution there are always times when the customer (or a project team member) thinks that there should be improvements made to the product that weren't in the original product functional specification, and there can be truth in this assessment. Sometimes this will be an innocent realization and sometimes it will be the customer desiring to get more product function for no cost increase. If this new work increases the project cost or delivery schedule, then the customer and the project manager need to review the proposed improvement and decide whether to include it or not and who pays. If there is no impact on cost or schedule, then it is very likely that it should be included, so long as it is a real improvement to product function.

Despite the temptation, never ignore scope (or mission) creep, but always bring it to the customer's attention. They would rather hear it immediately rather than wait to hear bad news later, when it will be far worse. It might be obvious, but to make sure that it is possible to know when there is scope creep, the product functional specification must be complete as early in the project as possible. In fact, the product functional specification really must be completed before a reasonably accurate project plan can be set. We need to know what must be done before we can estimate the labor required to get the job done, before the project plan can be completed.

Creativity

The group members have considerable experience with a wide variety of technical areas, both through work and through hobbies. As we have found out, hobbies can be a source of new products and new businesses, so both business and hobby activities are presented.

This shows a brief sampling of RACE group member creativity. Unfortunately for our non-mechanical design members, it's much easier to show creativity in mechanical design than creativity in electronic or software design, but rest assured that all team members are creative.

Proprietary Products

RACE has been actively developing a number of proprietary products and we will continue doing so in the future. These products are in various stages of patent filing so we can't show many of the products which we are working on. Some of these products are hinted at in the creativity PDF file. These products are either patented or in the process of being patented.

For prospective customers, we can review some of our proprietary products with you once a two-way CDA (Confidential Disclosure Agreement) has been signed by both companies. Naturally, we will not take on a customer with products similar to our propriety products, and we will not use any proprietary information obtained through a contract project to develop a competing product.

Rules Of Engineering Projects

Some time ago I discovered this very true and often humorous comment on engineering projects in Analog Magazine. Remember to revisit this when you are facing seemingly insurmountable obstacles.