By Michael Hermann | Oct 2, 2013
Many years ago we began seeing our Initial Design Engagement (IDE) stages starting earlier and earlier in the overall product development process. Customers often did not have the product architecture and technology fundamentals selected when they started working with us, so we started getting involved in that phase of the design. Eventually we choose to distinguish that initial phase as a separate process.
The concept of Phase 0 is that before you start designing the actual product, you have product design fundamentals to deal with.
Issues we address in Phase 0:
Feasibility
Can the product actually do what the customer wants it to do? Does the state of technology allow for it? Is the desired combination of functionality, cost, and design parameters (such as power and size) possible? And is it possible within the targeted engineering design cost?
Requirements
Have the product requirements been sufficiently articulated? Are they captured in a well-structured and sufficiently comprehensive manner?
Architecture
How will the product be made? What are the main technology choices? Key chips, algorithms, interfaces, and libraries may need to be evaluated and selected.
Program Planning
With large and complex multi-disciplinary projects the planning needs to start early. In what sequence will activities be organized? How much parallelization will there be? What kinds of touch points need to exist between the disciplines? Who’s doing what: what scope do different service providers and the customer themselves have?
Proof of Concept
This goes with feasibility – do we need to do early prototypes of certain circuits, algorithms, or features? Is there anything we need to see operating in real-life as opposed to just analytically evaluating it?
Why "Phase 0"?
People often ask us how ‘Phase 0’ got its name. The answer is pretty simple – it comes before the IDE, which we number as Phase 1, and it was invented as a term years after the IDE process was established. Instead of giving it a name like IDE we refer to it as just “Phase 0” since the content varies so much. There’s quite a lot of diversity; the topics listed above, and many more. The Phase 0 needs to cover whatever isn’t ready for the product to move into the IDE (Phase 1) of the design.
The typical outputs of Phase 0 are architecture/feasibility/requirements documents and a preliminary Project Work Plan (pPWP). Those are the materials, but what’s really the important outcome: decisions and planning. It is critically important at this stage that those decisions and planning activities are done right.
The Phase 0 concept provides a great way for customers to start working with Nuvation Engineering when they’re early in the product development process. We can come in and start getting the technology questions answered, bring rigor and clarity to the requirements, or whatever is needed to get that product development process moving forward at a good clip. Phase 0 can often be completed in parallel with the start of IDE/Phase 1; or more precisely, the IDE/Phase 1 can often start with the Phase 0 still wrapping up. Resources working on the architecture (Phase 0) start handing off elements to the resources working on design (IDE/Phase 1) to get the IDE elements moving forward and the product design rolling.
There’s an underlying message here that’s a common thread in all of Nuvation Engineering’s design and project management approaches – good engineering analysis and planning saves you a lot of time down the road in design execution. A good Phase 0 methodology and execution are part of that approach.
Nuvation’s experienced engineering teams have delivered over 800 electronic design services projects for a wide range of industries and applications. Contact Nuvation Engineering to learn how we can improve the time to market for your products.
