One of the important components of project management in medical device development is Project Scope Management, and at the heart of this lies the Work Breakdown Structure (WBS). The WBS is more than just a list of tasks; it’s the foundation of planning, cost estimating, scheduling, and communication. It decomposes high-level deliverables into manageable work components that can be assigned, tracked, and measured.
Each WBS element should have a unique identifier and be listed in a WBS dictionary to clarify what is and is not included. This boundary-setting is critical for reducing scope creep where extra features or tasks are added without proper evaluation. Projects could fail due to vague scoping and lack of WBS clarity, especially when cross-functional teams had differing understandings of deliverables.
For medical devices, where regulatory, clinical, and technical tasks are tightly interwoven, a WBS ensures that nothing gets overlooked and that all team members understand their role. Additionally, having a well-structured WBS supports more accurate cost and time estimates by tying resource needs directly to work packages.Defining scope clearly upfront, supported by feasibility studies and stakeholder input, prevents downstream confusion and ensures that the project aligns with business and clinical goals.
How can we ensure the WBS is detailed enough to be useful, but not so complex that it becomes unmanageable?
To ensure the Work Breakdown Structure (WBS) is detailed yet manageable, project managers should focus on striking a balance between granularity and simplicity. Start by defining clear, high-level deliverables and progressively break them down into smaller tasks, ensuring each task is specific enough to be actionable but not overly detailed to avoid complexity. Regularly review and update the WBS with input from cross-functional teams to capture all necessary details while maintaining clarity. Utilizing a WBS dictionary can help standardize definitions and prevent scope creep. Additionally, leveraging project management software can streamline the process, making it easier to track and manage tasks without overwhelming the team. How have you seen effective WBS implementation impact project success in your experience?
The concept of Progressive Elaboration can simplify the work breakdown structures.
Progressive Elaboration is a method of continuing to provide further details of the planning process as it becomes available. The goal is to help the project team manage with greater accuracy, control the process more effectively, and achieve greater success with project delivery. The concept of progressive elaboration takes into account that an initial project plan is usually developed at a very early point in a project lifecycle. Detailed requirements and potential impediments are not yet known at that stage.
Flowcharts are great for depicting workflows that are sequential and without too many interdependencies or decision points.
Different types of WBS can be used like,
Phase-based: The project can be broken down into sequential phases using this approach. The project phases are divided into project deliverables and work packages.
Deliverable-based: Here, the flowchart structure is based on the deliverables. A deliverable-based WBS first breaks down the project into all the major areas of the project scope as control accounts and then divides those into project deliverables and work packages. Each task is assigned to a specific team or individual responsible for completing it.
Responsibility-based: In this method, the project is divided based on team functions and responsibilities.
The work breakdown structure can be either in tabular form or graphical form. In tabular, it's divided into primary and secondary. In graphical, WBS may be made through a drawing, which, in this case, also results in a tree diagram.
The level of detailing of each attribute in a WBS can significantly vary based on the project's complexity. Simpler projects are structured as outlines or flowcharts, but complex projects are shown as spreadsheets. Complex projects also have a detailed breakdown of costs and timelines, while smaller projects may have a hierarchical list of deliverables.
To simplify WBS,
1) Keep Tasks Mutually Exclusive: Ensure that tasks within the WBS are mutually exclusive, meaning that each task is distinct and does not overlap with others unnecessarily.
2) Go Just Deep Enough: When creating the WBS, strike a balance between detail and complexity. While capturing necessary tasks and subtasks is essential, avoid excessive granularity that may lead to confusion or inefficiency.
3) Clarity and specificity: aiding in understanding and communication among project stakeholders.
Ref: https://www.rmci.ase.ro/no17vol1/06.pdf
https://www.jmirs.org/article/S1939-8654(12)00154-3/pdf
https://www.projectmanagement.com/
In addition to balancing detail and simplicity for the WBS, I think it's also important the WBS structure has clear traceability between work and regulatory paperwork, like design inputs, outputs, verification and validation. If the WBS is too high-level, it may miss those key steps like testing or creating documents, if it's too detailed, it can get confusing and hard to manage. One way to handle this is by mapping WBS work to a specific section of the Design History File. This not only keep the scope focused, but also makes sure you're building your regulatory files as part of the natural workflow process. Do you think the WBS should always be tied directly to regulatory documents in highly regulated industries?
WBS should be closely aligned with a company's risk management planning. Different deliverables like the change history are effective in a WBS, but incorporating a risk-perspective into the WBS as well can make areas with more uncertainty more visible to the team and stakeholders. Incorporating risk management plans, like pre-submission meetings and timelines for testing protocol can make sure that a project stays within the scope without venturing too far off track. At the same time, incorporating the risk features into a WBS can make it feel congested and complicated. One other factor that was mentioned before was incorporating lessons from previous projects into the development of a WBS. By using a database of past lessons learned, a project manager can incorporate those lessons onto a present project's WBS to achieve better and more streamlined product development. By looking back at projects that were successful and identifying key features of the WBSs can be beneficial for future projects as it could show where efforts are most important.
That’s such a relevant question because finding that balance with the WBS can really make or break a project. To make sure a WBS is detailed enough but still manageable, I think the key is to focus on deliverables, not just tasks. Each level of the WBS should break the project down into smaller, clearly defined outcomes that are meaningful and measurable—but only to the point where they can be realistically planned, assigned, and tracked. If you go too granular, you’ll end up spending more time managing the WBS than doing the actual work.
One good rule of thumb is to stop breaking down a work package once it can be completed by one person (or a small team) within a reasonable time frame—like a few days to a week. In medical device projects, that might be things like “develop risk management file” or “complete usability testing protocol.” You also want to involve the actual team members who’ll be doing the work when creating the WBS—they can flag when something’s too vague or unnecessarily complex. Keeping it practical, focused on outcomes, and closely tied to the scope helps ensure the WBS supports the project rather than overwhelming it.
