PGMT170
Let's talk about WBS! A Work Breakdown Structure (WBS) is a way to break a project into smaller, manageable pieces of work.
It helps you organize the project by showing:
~the major parts of the project
~the smaller tasks inside each part
~what work has to be completed to finish the project
Think of it like taking one big project and turning it into a step-by-step hierarchy.
Simple way to think about it:
If the project is “Set up a fundraising event”, the WBS answers:
~What big sections of work need to happen?
~What smaller tasks belong under each section?
~How can we organize the project so nothing gets missed?
Key idea of a WBS
A WBS is usually organized from top to bottom:
Level 1:
The entire project
Level 2:
The main deliverables or major work areas
Level 3:
The smaller tasks/subtasks under each work area
Sometimes it goes even deeper if needed.
Deliverable vs Task vs Schedule
- Deliverable = thing/result
- e.g., “Final survey questionnaire”, “Clean response dataset”, “Member feedback summary report”
- Task = action
- e.g., “Draft survey questions”, “Send survey emails”
- Schedule item = action + time
- e.g., “Send survey emails on March 3”
WBS focuses on deliverables + the work that creates them, not on dates or who does it.
Good WBS elements (what “good” looks like)
- Deliverable-based: named as a thing, not a verb string
- Better: “Survey instrument finalized”
- Weaker: “Work on survey questions”
- Clear and specific: someone can tell what is “done”
- Estimable and assignable: small enough that you could (in theory) estimate it and give it to a person
Analogous estimation = using a past, similar task (analogy) to guess how long a new task will take.
One catch: with analogous estimation, we usually stay close to the past number unless we have strong data.
So instead of cutting it in half right away, we might say:
- Last time: 4 hours
- This time: maybe 3–4 hours, unless we have proof it’ll be much faster
Three-point estimation says:
“Instead of just one guess, let’s think about three versions of reality for the same task." And this is how PERT factors back into this system. However when factoring in our estimates we also have to look out for three big problems that show up over and over:
- Optimism bias – “Everything will go smoothly.” We imagine the best case and quietly treat it like the normal case. Example: “We’ll draft the survey in 2 hours, no rewrites.” Then stakeholders… rewrite everything. We picture smooth progress, no interruptions, no rework — so our estimates are too low.
- Stakeholder pressure – “Can you make it faster?” A boss, client, or partner pushes for a smaller number. We give a number that makes them happy, not one that’s realistic. We give a number that is politically safe or pleasing, not actually realistic.
- Missing tasks – “Oh… I forgot about that step.” We estimate the big task but forget little things:
- chasing approvals
- fixing formatting
- writing reminder emails
Those small steps add up and blow the original estimate. Each one is small, but together they blow the original estimate.
Three-point estimation helps fight these by forcing you to think about bad days (P) and not just perfect days (O). This also leads into the next point, planning fallacy: The planning fallacy is our tendency to underestimate how long tasks will take, even when we have past experience that shows they usually take longer. We focus on a best-case or ideal scenario and ignore delays, rework, and small hidden tasks.
Here’s how you can push back without a fight when someone (say, a gym owner) wants a smaller number:
- Separate estimate from commitment
- You: “My estimate is 6 hours. If we need it sooner, we can cut scope or accept more risk.”
- You’re not changing the reality, just being clear about it.
- Anchor in facts
- “Last time a similar survey took about 5–7 hours including feedback. This one is similar, so I’d keep it in that range.”
- That’s using analogous estimation as backup.
- Use ranges, not single points
- “I’m 80% confident it will land between 5 and 8 hours.”
- Sounds calm and professional, and harder to argue with.
- Offer trade‑offs instead of “yes”
- “If it has to be under 4 hours, we can skip X or reduce Y. Do you want to make that trade?”
When you see a WBS task like:
“Send first survey to members”
Hidden underneath that might actually be:
- export/update member email list
- test the survey link
- write email subject + body
- send test to self / Maria
- schedule send
- confirm it actually sent
If you estimate “send survey” as 1 hour but you’re really doing all of that… your estimate will be wrong.
Instead of exploding your WBS into 6 smaller rows, you can do this:
Keep the main task as one row
In a notes column, write a short checklist like:
- “Subtasks: update list; draft email; test link; schedule; confirm send”
Now, when you estimate O / M / P, you’re mentally including all of those, not just “click send.”
Below I'm going to have a link included to show what an example WBS chart looks like with task times and some "costs" attached to it pardon any small math errors you may see, it has been a terribly long day.
3
7 comments
PGMT170
powered by
skool.com/maestro-students-9927
Maestro Engineering Hub 🚀 Serious students. Real collaboration. Coding, AI & discipline. We don’t just study — we execute.
Suggested communities
Powered by