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.

Design Team (Best) Same Practices

Design team practices are the "how" of a team's path to production release of a product; key emphasis on production release. Creating product samples has never been a cash machine for the business that a design team supports. A project objective must always be revenue; as a result our vision must always be on production release along with costs that meet the business case. Focus on anything less and any decisions, plans, scope or product requirements will be crippled from the beginning; culminating in an unplanned spin costing several months and lost revenue, just when production was within reach.

OK, off my soap box now and back to practices. Practices are typically called Best Practices because we want the "how" to be our absolute best. Of far more importance than being "best" is that they are the same. Everyone on the team does the same things, delivers the same 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 well, no work will ever need to be redone. That's the litmus test for your practices. If the team is being surprised and reworking deliverables for a given project, they were not doing things the same. The degree of surprises is an excellent measurement of the quality and communication of your practices.

So what needs to be done the same? I guarantee most of the practices problems will be related to the specific deliverable out of a task. If there is a surprise on a project it is because a given task deliverable was not in sync with downstream expectations. The concept of Same Practices means alignment of all of the project deliverables to a consistent and agreed format, content and location. For a list of some common practices note the visual to the right.

If everyone is to deliver to a common practice the team needs to know what they are and they must have participated in the practices development or you have failed at the starting gate. Think Knowledge Management (KM) as the means for aligning your team to Same Practices. There is a plethora of suppliers out there that can make this easy for you. Wiki's, web collaboration tools, web project management tools and so on. If you want a list of suppliers send me an email and I will send you the links I have. One interesting point about surprises is that you may never know they happened. The engineers generally just take what they get and make it right while quietly slipping behind on their task. Implement Same Practices or endure a continuing rash of surprises that will quietly steal away the timeline to product revenue.

Managing Excellence in Design Team Execution

In these highly competitive times everyone is extremely busy, making it difficult to find time to step back and look at how things are being done. At the same time a team that is to approach execution excellence must devote the critical time necessary to define a roadmap and strategy for improving their design processes. We have a workshop solution to kick start the thought process and generate immediate concepts that a design team can implement on their projects thus enabling predictable and productive project execution.

Please follow this link to learn about an 8 hour team investment that will yield a newfound understanding of the path to execution excellence - A one day workshop at your site, with your actual team, specifically developing enhancements to the teams development processes.

"Change nothing and nothing changes"

This workshop makes an excellent kickoff to a process renewal effort.