Work Packages Are The Unit Of Control
You do not assign work packages to people. You assign tasks, and then you bundle those tasks into work packages for tracking purposes. Most people get this backwards. They create a work package and slap a single owner on it, then wonder why nobody knows who is actually doing the work inside that package. I have seen this in so many projects it is not funny. A work package is the smallest piece of a WBS where you can reliably estimate cost and duration, assign ownership, and measure progress against. That is the textbook answer. The real answer is simpler: it is the chunk of work small enough that someone who knows the domain can look at it and say whether it is done or not done without needing a meeting to figure it out. There is a threshold most project managers miss. If a work package is too big, it becomes a black hole. You check on it two weeks later and it still looks half done because nobody broke it down further. If it is too small, you end up with hundreds of packages and spending more time updating status than actually working. I usually aim for work packages that fit in roughly 8 to 80 hours of effort, depending on the project type. Eight hours for a software build. Sixty for a construction milestone. Adjust based on your team's reporting cycle.
The Breakdown Process
Start with the deliverable, not the activity. This is where people mess up. They open their scheduling tool and start typing tasks like "write documentation" or "conduct testing." That is a work breakdown, but it is not a work package yet. A work package needs a deliverable at the end. "Completed API documentation for service layer" is a deliverable. "Write documentation" is a verb. Verbs do not get delivered. Nouns do. So you decompose the project scope into hierarchical deliverables until you reach the bottom level. That bottom level is your work package. Every work package should satisfy three conditions. You need to be able to assign a single cost account. You need to be able to estimate duration with reasonable confidence. And you need a clear acceptance criterion that a stakeholder would recognize without arguing about it. I built a quick template most of my teams use. It is basically a spreadsheet with columns for WBS code, deliverable description, acceptance criteria, estimated hours, cost account, responsible owner, and dependencies. The WBS code matters more than people think. Something like 3.2.1 tells your team exactly where that work sits in the hierarchy without requiring them to read a paragraph of context. You can generate these automatically from most scheduling tools if you configure the outline structure correctly.
How It Actually Feels On A Project
Here is a specific case. We were running a phased facility relocation for a mid-size logistics company. The WBS had a work package labeled "Warehouse shelving installation." Sound straightforward, right? Two weeks in, we realized three different subcontractors were working in that zone, nobody had cleared the electrical conduit route, and the shelving supplier had ordered the wrong beam spacing. The work package was thirty people-weeks of effort, unassigned to any single accountable person, and our burn rate was completely unreadable because costs were bleeding across three cost accounts. The fix was brutal but simple. We broke that one work package into four separate packages: demolition and debris removal, electrical conduit rough-in, shelving supply and delivery, and shelving assembly and leveling. Each got its own WBS code, its own owner, and its own acceptance criterion. We also stopped tracking it as a single percentage complete and started tracking it with earned value. The confusion dropped almost immediately because each package now had a clear boundary. What used to take weekly war-room meetings to untangle took fifteen minutes per package during the daily standup.
Get the Full Details
Common Mistakes That Waste Time
The biggest one is creating work packages that cross organizational boundaries. If your package requires coordination between the IT department and the facilities team, you now have a communication problem disguised as a planning problem. Split it differently. Keep work packages inside a single responsible org unit whenever possible. Another mistake is treating work packages as permanent. They should evolve. When scope changes, you either modify existing packages or split them. You do not just add more work to a package that is already at eighty percent because then your estimates become meaningless and your earned value data turns into garbage. I have watched projects where the schedule was six months old and the work package durations had drifted so far from reality that the whole baseline was unusable. That usually traces back to not revisiting the bottom level when scope changed. There is also the issue of resource leveling creating phantom work packages. You split a package because you cannot staff it all at once, but splitting it does not change the actual work content. It just changes when you do it. Keep the work package tied to the deliverable, not the resource calendar. Use your scheduling tool's resource assignment feature for that instead.
When Work Packages Do Not Work
They fail in environments where scope is genuinely unknown. Research and development projects, exploratory product design, anything where you do not actually know what the deliverable looks like at the start. Work packages require you to know what done looks like. If you cannot define acceptance criteria upfront, you are not doing work packages, you are doing story points or something else. Do not force it. Agile teams handle this by using increments instead of work packages, and that is fine. Just be honest about which approach fits your situation. Small projects also tend to overcomplicate this. A project with three people and two months of work does not need a formal WBS with work packages. You will spend more time maintaining the structure than managing the work. One shared task list with clear owners is usually enough. I see this happen constantly when project management certifications tell people to apply enterprise-level processes to everything regardless of scale. The other hard limit is when your organization cannot agree on what constitutes a deliverable. I worked on a government contract where the contracting officer and the engineering lead had fundamentally different definitions of "completed integration testing." One thought it meant unit tests passed. The other meant full regression. That disagreement made it impossible to write an acceptance criterion for the work package, which made the whole thing useless for control purposes. No amount of better planning solves a stakeholder who does not know what they want.
