Investing in NPD Excellence

Frequently when an organization identifies the possibility of an improvement to their process the very next concept is one of cost. This then leads to an inability to afford it, or a limited ability in being able to "sell" management on the idea. Almost immediately the improvement concept becomes relegated to the fact that it is solely an expense item and any possibility of a quantifiable net positive is lost. Return on Investment (ROI) analysis is routine for any product related project being considered by an organization. Why does this not typically hold true for an improvement project?

Any improvement project should only be considered if it is expected to bring value, a value that is minimally characterized as a reduction in development time. Compression of the timeline to production release creates two fiscal components that positively impact profits. The first is a decrease in the expense for product development and the second is the additional revenue associated with an earlier production ramp. The total additional income due to a realized improvement becomes the sum of saved development costs plus the early production income. There are also expenses associated with any improvement and these subtract from the saved development costs and early revenue to provide a net additional income that can be described as a ROI.

Obviously to generate an ROI figure there must be a well thought out analysis of the improvement effort to produce an expected timeline savings. This is a complicated endeavor, however I maintain this is essential to properly frame any productivity effort where realization of specific results is the objective. This is the beauty of an ROI driven initiative given that it will inhibit an easy path to fictional end results. There must be quality homework completed to scope both the intended improvements and the expected NPD time reduction, effort that is essential to properly establish objectives and measurement criteria to be utilized for a believable ROI.

Any improvement effort that fails to identify an ROI will be perceived as a pure expense, have weakly framed objectives and be easy prey to cancellation or delays. Tie the effort to a realistic ROI and enable the healthy emphasis, visibility and direction that will result from a project that is defined to positively impact business financial objectives. Include this information in a fully developed business case and you will have created a compelling case for a your productivity improvement, one that gets noticed, funded and supported to completion.

Process Improvement = Cycle time improvement = Increased Revenue

It's worth investing in!

Sampling of PM Practices in use for IT Projects

For your reference I am providing some information about the formal Project Management practices and methodologies being utilized today in IT. I believe there is much to be learned about this industries approach to PM and there is definitely a level of applicability to the projects we support in the semiconductor world. Your takeaway from the information below will be a better understanding of the meanings behind the most common Project Management buzzwords you will find in the literature today.

PMBOK (Project Management Body of Knowledge)
This is the standard implementation of structural project management in the US as developed by the Project Management Institute. There is a certification process for a PMP, PgMP and CAPM levels of project managers. Please see http://pmi.org for more information about this methodology for managing projects.

Prince2 (Projects in Controlled Environment)
Prince2 is the 2nd generation of a structured methodology for managing a project that was developed in the UK. Essentially it mandates that any project must have a controlled start, a controlled middle and a controlled end. There is training and exams much like those of the program management institute. More about prince2 may be found at http://www.prince2.org.uk. Wikipedia also has some good information at http://en.wikipedia.org/wiki/PRINCE2. For literature on this methodology please see http://www.apmg-businessbooks.com/bookshop/bookshop.aspx?catID=3.

Agile
This was primarily developed for software development teams and the premise is rapid spins and delivery of the software throughout the development process. It focuses on multiple deliveries of smaller, fully tested subsets of the final product. This produces end customer sub-set deliverables early while the team continues iterating and expanding functionality until the final product is realized. One key concept of an Agile approach is that the project details are planned out incrementally as the project progresses, allowing a system that is much more capable of adapting to scope change. When in an environment of high innovation this approach may produce benefits over classical Prince2 or PMBOK structured approaches. For more information please see wikipedia at http://en.wikipedia.org/wiki/Agile_software_development.

Scrum
Scrum is a methodology that is typically associated with Agile software development although there is no hard requirement that I can see. It's really more of a PM methodology that employs a scrum master in place of a project manager. The premise of this approach is a series of short 2-4 week sprints to complete a predefined set of tasks. The teams focus purely on the sprint items during the sprint period and have daily meetings that cover what was done yesterday, what you will do today and what obstacles are in your way. There is also an emphasis on risk assessment and mitigation throughout the project cycle. A nice quick guide on this process can be found at http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf.

Contrasting the PM Practices of IT and Semiconductor Businesses

We all have a moderately good knowledge of formal Project Management and most of us will answer positively if asked about the use of a formalized management process on projects in our organizations. My observation is that most mature semiconductor business units have embraced formal Project Management at the business level but it is much less practiced, or even acknowledged in the engineering teams themselves. This is a key difference between the semiconductor and Information Technology worlds. IT businesses largely embrace all aspects of formal Project Management for New Product Development while the semiconductor businesses typically have a PM system in place, although the level of implementation is usually far less. In fact most of the new project management philosophies have their roots in the IT industry, further strengthening their position as a PM driver and innovator.

Why would there be such a gap in the level of formal Project Management commitment between these two industries? Is it the size and complexity of the projects? Is it management's commitment to Project Management? Is it that engineering team resistance is greater in the semiconductor business? Good questions, although the answers are of little relevance. Of major importance is that IT teams believe in fully engaging formal Project Management techniques as the best path for their projects success. This fact is something that those of us in the semiconductor business should take note of, as the demands for faster and better product releases (revenue generation) drives us down a path of continuous improvement.

We must candidly assess the effectiveness of formal Project Management for our businesses. If projects are honestly exceeding the needs of the business then it is a safe assumption that the PM implementation in place is working well. However, if projects exhibit a level of unpredictability and delays I suggest a serious look at the depth of Project Management practices in your organization. By depth I mean how far the formal Project Management reach is into each of your NPD team disciplines. If an organization has formal Project Management in place at the business level while the planning and tracking of projects for product engineering, design, test and so on does not fully embrace formal PM practices, then it is improbable that a business level Project Management implementation will be successful. Garbage in, garbage out type of analogy would best describe this scenario.

Ideally there must be an individual that understands formal Project Management practices within each of your disciplines; someone who is experienced in the principals and knows both the technical activity flow and the technical tradeoffs. This individual would ask the tough questions and can visualize the sequence of tasks along with the required deliverables/receivables for each. Essentially you are looking for a project manager type mind set within each discipline that can properly identify and frame the project activities for that group. Either there is a project manager that has the exceptional background to properly assess and plan the activities for all disciplines, or that talent must be developed within each discipline to deliver accurate project planning and tracking data to the project manager.

Six Obstacles to Design Team Victory

Here's my list of items that are sure to ruin a victory for a design teams project, even with a harrowing effort by the team. These are the biggies and if you conquer them, your team is sure to enjoy repeat project victories.

1. Lack of Best (Same) Practices - Enough said on this subject from the previous posting on practices dated Jan 31, 2008.
   
2. Lack of Scope Control - Things change and they always will. The big question is "are you in control of when something is changing or even if something might be changing?" Keep a watchful eye on your internal team also. Things come up on a project and are declared a no-brainer thus grandfathered in with minimal fanfare, if any at all. I have yet to see a no-brainer change that does not end up causing some problem downstream due to lack of proper assessment and communication. On a project, a change is never free!
3. Lack of Requirements Closure Management - Requirements closure can take longer than the design project itself and I have seen this happen more than once! Project execution may get kicked off early 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. If you want that project in the shortest amount of time you need an early focus on the requirements, not on getting your designers busy. Capturing schematics, doing layout and running simulations feels like progress but it's only real progress if it is not 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 electricals, functional, verification and test plans/modes. Design Guides work well as the engineering information containers for the lower level requirements breakdown.
5. Lack of a Plan - Statements such as "it will take us about 6 months", or "we need it in 6 months" do not constitute a plan and it will never work for you. Plan out how you will get there, what are the risks and their mitigation strategies, what each of the tasks are and who is going to do what. Follow this by identifying the task lengths and build up the plan in a project plan tool (see our Plan template). Once you have it in the planning tool you can then do what-if tradeoffs to see how resources or de-featuring can improve things. Do your homework and then commit to the plan only when there is a means to get there. This becomes the Plan of Record for the project. Change anything about requirements or resources and the plan must be updated. Remember, nothing is ever free.
6. Lack of Full NPD Team Participation - CAD, TE, PE, packaging, customer, PM, Biz Ops, Marketing are all part of the New Product Development team and must be assigned at project kickoff. Don't pull in your product and test people a month before tapeout; engage them at the project start for their input on design requirements for test and production worthiness. Leave them out and you are likely to have a silicon spin purely to support production issues; again several months delay and lost revenue that did not need to happen! Include a program manager that knows design and can manage the design related details and ask the tough questions; the ones that pull the design team into the planning process. Include CAD resources as part of the project. If you have holes in your tool flow you must plan the fixes as part of the project and track them just like any other project task.