Product Development Planning

Planning may be the most critical activity to any single project. Planning a product development project is no exception. I’ve worked on projects that had little to no planning and others where planning was the only activity accomplished. The trick is to plan just the right amount.

When many people think of a project plan, the first thing that comes to mind is the project schedule and timeline (usually in the form of a Gantt chart). The project schedule is an important aspect to the plan but often is given too much importance and priority. A project plan considers everything that needs to be done during the course of the project, who is going to do the activities, and of course, when these activities will take place. Planning should not determine how these activities will be completed. Determining how to do an activity takes place once the plan is ready to execute.
Planning should coincide with a product development process. Typically, such a process is segregated into phases. Each phase should have an objective or purpose. The activities required to accomplish this objective are then identified; this is often referred to as a work breakdown structure, or WBS for short. It is also important to determine linkages between activities. For example, does activity A have to be completed before activity B? Or can A and B be completed at the same time?

As I mentioned above, planning should incorporate the right amount of detail. This is easy to say but difficult to put in practice. My experiences and observations are that plans often include too much detail. Try to identify the high level activities. Try not to define all the sub-activities or how the activities will be accomplished. Planning is somewhat of an art and becomes easier with practice.

Planning should start at or near the initiation of a project. Of course it’s hard to plan a project without knowing a little bit about the project scope. After determining a rough idea of what the project really is, project planning is ready to begin. Planning is somewhat of a discovery process. Planning is most definitely a dynamic process. Things will happen during the course of a product development project that cannot be predicted. Some of these events will be pleasant surprises. However, many can and do throw product development efforts completely off track. When these surprises happen, be sure to incorporate this knowledge into the project plan.

All too often, a product development plan is created and then filed away, never to be seen again. Plans have to be visible and usable. A good plan should have enough detail to execute the current phase of development. A good plan should also incorporate a decent amount of detail for the next phase of development. As the current phase nears completion, the next product development phase should be reviewed, revised, and define enough detail for execution. During initial planning, project plans should include more details and definition about earlier stages of product development and should be somewhat ambiguous about late development stages. For these later stages, key deliverables and milestones should be captured but not much else. Build and refine the plan as product development progresses.

Often a product development team is given the project due date before any research or planning occurs. Despite this obstacle, planning will be critical to the success of a project. Many executives have difficulty understanding why planning is so important. These executives often view planning as a waste of valuable time. Planning does not lead to immediate feedback and response. It is difficult to see actions resulting from planning. No deliverables are achieved. Be prepared for these views. Convincing upper management of the value of planning is a difficult task.

Project planning should also weigh risks–both from a project and a product standpoint. What tasks can be done in parallel? Which tasks have to be done in series? Every project plan must consider this. A plan with all tasks in series is lower risk than a plan with tasks performed in parallel. However, the lower risk plan will have a longer lead time. In many industries, especially within medical devices, some tasks cannot be done in parallel. For example, verification testing cannot occur until design input requirements and acceptance criteria are established (I’ll go into detail about these topics in a future post).

So who develops a product development plan? Many treat planning as a solo activity, often created by the project lead. This is the wrong approach. Planning is a cross-functional, core team activity. As mentioned, a good plan will take some time. One approach is to tackle planning in stages. Use the product development process as a guide (if you don’t have a defined process, let me know–I can help). Break down each phase by deliverables and milestones. Determine the functional owner of each deliverable and have the respective team members define the tasks to accomplish these activities. Another thing to consider during planning are templates, previous project plans, and of course experience of the core team. Use these tools as an advantage.

Product development planning is somewhat tedious. Planning takes time. Planning requires compromise. Planning is a dynamic, project lifecycle activity. Teams develop plans; not individuals. If these suggestions are followed during the course of product development, the project will go smoother. The team will bond, learn to rely on, and support one another. Upper management will be surprised. And, ultimately the end customer will receive a better product.

Good luck in your planning efforts. If you have questions, comments, or need a little bit of help, please contact me at jspeer@creoquality.com.

Speak Your Mind