Within a medical device project, “division of responsibility” among project team members is usually the default. “Division of responsibility” enables team members to feel ownership of major components of product design and simplifies accountability for project managers. What’s not to like?
I’ve seen“division of responsibility” work really well on projects. Early at Infraredx, one engineer led the catheter distal end development, another engineer led the development of the shaft, a third worked on the handle, and a fourth on the packaging. The team divided responsibilities by subsystem, and worked closely together to ensure the system-as-a-whole worked as required.
“Division of responsibility” makes life easier for managers too. Project members can manage their own detailed tasks, freeing management time to work on something else.
On the other hand, “division of responsibility” can be a recipe for disaster if one project sub-system has a disproportionate share of the project tasks or project risks. If all the long lead items are in the distal end of the catheter, it surely makes more sense to have several engineers work on distal-end tasks up front, to get all the long lead items on order as quickly as possible.“Division of responsibility” can only work when the workload and riskload is perfectly balanced. This is rarely true, and high priority project tasks can languish while engineers remain focused on their own lower-priority sub-systems.
Further,“division of responsibility” reduces responsiveness to changes in prioritization. If we want our project management to be agile and responsive, we cannot allow subsystem assignments to be inflexible.
Agile software development has done away with “division of responsibility” as a project management technique, and engineers have learned to be satisfied with being a key engineer on the team that developed Software Project X. Tasks are selected and worked according to task prioritization, period. Perhaps the only exception is when there is a key skill required. Only engineers with EE skills can design schematics.
Generally, Critical Action Planning also does away with the “division of responsibility” approach when it comes to task performance and prioritization. The team defines the weekly priority tasks, and the team assigns the best available team members to get those tasks done. However, the Critical Action Plan approach is flexible when it comes to task planning. The team may assign individuals to be responsible for detailed task planning of sub-systems. For example, the electrical engineer may be assigned to define all the tasks and risks around the electrical subsystem designs. But when it comes time to ordering the circuit boards and cable assemblies, the best available team member will be assigned
It’s hard to let go of the “Division of responsibility” approach. Critical Action Planning is a big cultural change for team members, and it forces project managers to get into the weeds of sub-system tasks. It’s easier to keep doing things the way we’ve done them for years. I’ll let you think about that.
Jay Caplan on Medical Devices 
One thought on “Critical Action Planning – Why “Division of Responsibility” Is The Wrong Approach”