Chandler, AZ (PRWEB) February 11, 2008
IC design teams are typically giving projects maximum effort, with the best information and practices available at the time. Nevertheless teams exhibiting great passion and energy are not necessarily destined to meet the business objective for product design cycle times. Certain teams are inherently more productive and consistent than others in meeting timeline commitments to the business.
Jeff Jorvig, President of Jorvig Consulting says, "The differences in team performance are found to be in the practices of the team, how they approach a project." Jorvig continues "Teams that broaden focus beyond tools by including a greater emphasis on process and procedure have been found to attain a higher level of productivity, while more predictably meeting goals." In recognition of IC design teams passionate efforts in supporting business cycle time demands, Jorvig Consulting has compiled six common obstacles that teams should consider in the quest for recurring project victories.
1) Lack of Best Practices - Design team practices are the "how" of a team's path to production release of a product; typically known as "Best Practices" due to a misplaced intention of being the absolute best approaches. Of far more importance than being "best" is that practices are the same across all team members. Everyone on the team performs identical activities, delivers the items in the same format, captures the design the same way, uses the same verification strategies and so on. If the "same" practices are done effectively, no work will ever need to be redone. The level of rework on a project is an excellent litmus test for the quality of team's practices.
2) Lack of Scope Control - Product features change throughout development and they always will. A team must continuously take steps to be in control of any feature or requirement that will change the span of a project. Scope control must also include keeping a watchful eye on the NPD team itself, as they may affect a localized feature change that is driven by risk, testability, cycle time or simply because it's deemed better. Changes may come up on a project and are declared a no-brainer, thus grandfathered into the project scope with minimal fanfare, if any at all. It is rare that a no-brainer change does not end up causing some problem downstream in the project due to lack of proper assessment and communication. On any project it is unusual that a change is ever free.
3) Lack of Requirements Closure Management - Requirements closure can take longer than the design project itself, when not managed well. Even worse, project execution may get kicked off prior to requirements closure due to a sense of urgency, allowing the team to go down a dead end, return and then go down another path or two; wasting precious time and pushing out the product revenue stream. If the shortest possible amount of time is a project objective then an early focus on requirements closure is essential. Capturing schematics, designing layout and running simulations feels like progress, however it's only real progress when it does not need to be redone later.
4) Lack of Design Breakdown Requirements - The chip level requirements must be broken down into engineering requirements at the sub-block level. The design is a system that must formally spawn the lower level block requirements. Lower level engineering requirements include electrical specs, functional specs, verification plans and test plans/modes. Design Guide templates work well as the engineering information containers for the lower level requirements as well as guiding a team through the creation of the essential and agreed upon information for each sub-block.
More about Design Guides
5) Lack of a Plan - Statements such as "it will take about 6 months", or "it is needed in 6 months" do not constitute a plan and will never work for a team that must be consistent and predictable. Plan out how the team will meet the objectives; identify each of the tasks and task owners. Recognize the risks and the risk mitigation strategies. Once this groundwork is completed identify the task lengths and build up the plan in a formal project plan tool. Once the project is entered into a planning tool the what-if tradeoffs should be completed to identify how resource balancing or product de-featuring can improve things. Do the homework and then commit to the plan only when there is a means to get there. The finalized plan becomes the Plan of Record for the project. Change anything about requirements or resources and the plan must be updated to create a new Plan of Record.
6) Lack of Full NPD Team Participation - CAD, TE, PE, packaging, customer, PM, Business Operations and marketing are all part of the New Product Development team and must be assigned at project kickoff. Don't pull the product and test people into the project a month before tapeout; engage them at the project start for essential input on design requirements for test and production worthiness. Without early project engagement of test and product members the project is likely to have a silicon spin purely to support production issues; again several months delay and lost revenue. Include a program manager that knows the design process and can manage the design related details, asking the tough questions. Queries that will pull the design team into the planning process. Also include CAD/CAE/DA resources as part of the project from the project launch. If there are weaknesses in the tool flow, fixes must be a part of the project and they must be tracked just like any other project task.
About Jorvig Consulting, Inc.:
Jorvig Consulting provides consulting and coaching services that target compression of time to revenue for New Product Development efforts. The solutions jointly developed with our clients enable NPD teams to experience a newfound freedom from surprises during project execution, thus compressing time to revenue via productive and predictable project execution. http://www.jorvigconsulting.com