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.