Taking a high level view of the responsibilities for program management (PM) yields activities that are based on planning, coordination, scheduling and tracking of all the tasks for a given project, from concept to production ramp. PM covers a broad view of the project activities and cannot be expected to be an expert in the details of execution of a project. This concept is key in facilitating a quality relationship between the product development teams and PM’s.

The expertise for the execution details resides within project functional areas that typically include design, test, product engineering, applications/systems, business operations and marketing. Assuming that the PM has the knowledge to define, assess or decide upon a sequence of activities within a functional area opens the project up for contention that will ultimately produce an unrealistic plan. Each functional unit must properly educate the PM regarding their activities and decisions. This is the only means that will allow the PM to produce an accurate plan for the project.

Thorough, honest and detailed input from each of the functional teams is the only means of enabling a PM to successfully plan, track and coordinate activities for a project. As the old saying goes - “Garbage in, Garbage out”. Do you want the project to be a success, the PM pestering to be minimized and your evenings and weekends to yourself? If so, it is essential that adequate time, thought and preparation be spent to ensure that your planning deliverable to PM covers every task that must be completed.

All the functional areas inputs are in, the project plan is developed by the PM and the result is in – the schedule is too long. This begins the negotiation process. What-if scenarios are debated, resources are added (real and imagined) and certain steps are placed on the chopping block. Again, I want to stress that the PM is not experienced at the details and should not be expected to make judgment calls when it comes to whittling down tasks within functional areas of the project. PM will make suggestions that “appear” to help the schedule; the functional areas must bring their expertise into the discussion to permit rational judgment calls about specific tasks. Make your voice heard during this process or face the unpleasant prospect of executing to a plan you do not believe in.

Keep PM well informed and they will surely enable a successful project. Feed them poorly planned activities, milestones and schedules and you will likely end up taking a beating for poor design execution. PM or not, success will result from a well thought out and implemented plan.

PM can enhance design execution only through designs delivery of detailed, accurate execution details for ALL the activities that must be completed. If the design plan delivered to PM includes only the high-level activities such as “capture schematic”, “simulate”, “Layout” or “verify” tasks, there is not enough detail to ensure predictable design execution. Focus an eye on the “supporting” tasks to fill out the details of the plan. I define supporting tasks as items that enable design to efficiently complete schematic, simulation, layout and verification tasks; without the need for later rework.

Below are examples of supporting tasks that must be part of a thorough plan:

CAE support (symbols, flow development, parasitic extraction, characterizations, mixed signal sim capabilities etc.)

ESD strategy

Floor planning activities

Top level validation strategy

Test strategy (DFT)

Engineering spec development

Customer Spec closure

System level validation tasks

IP reuse plans, decisions & validation in required flow

Define chip level configuration options

Risk mitigation strategies

Power analysis tasks

Simulation stimulus development

Design review planning

Design documentation

This list is a sampling of the type of supporting tasks that must to be brought to the surface, planned, scheduled and then provided to the PM as a part of the essential design activities. Dropping any of these support tasks out of the design plan will leave you with work being executed and no means of formally tracking the activity. Even worse, working on unplanned tasks means your not working on planned tasks. This will open the team up to become to a target for “poor design execution”.

Let me focus your attention on the CAE support task from the list above. This item typically has many sub-tasks associated with it that can easily be glossed over in a plan. Consider capabilities that must be in place to complete the design tasks. Where are the holes in the design flow that will keep the team from performing a task or performing it efficiently? Design flow imperfections tend to be buried and dealt with during the execution of a specific design task, resulting in the job taking longer than planned. Having multiple designers dealing with the same design flow imperfection amplifies the project delay by extending it to numerous design tasks. Deal with your CAE issues once by making them a part of your project plan to be completed “before” they will be needed for any specific design activity.

If you fail to sufficiently break your design project down to include and plan all of the supporting tasks I guarantee that there will be surprises, delays and nasty PM conflicts. Do the proper planning and PM will be your friend, skimp on the details and PM is sure to be a foe.