Hello, my name is Josh, and I used to put tasks on my WBS.
Whoah, it felt good to get that off my chest.
When I first began managing small projects, I used a task list to plan. I was making a mistake, and it showed because conversations about scope immediately turned to how, who, and when (tasks/schedule) instead of what (deliverables).
I discovered later that a work breakdown structure can be great if used properly. A WBS gives you this focus for initial planning and scope control throughout the project. A task list has no levels of decomposition that clearly show how smaller pieces of scope will come together and produce the final output of your project. With a task list:
- My teams would lose sight of what the scope of your project really was
- We missed things because we were jumping into solutions before even defining basic scope
- Managing scope change was a nightmare!
Even for simple and small projects, I always use a work breakdown structure now. The WBS forces me and the team to focus on the output and start with the end in mind. When I used to throw tasks in it, it changed the whole function of the tool and it wasn't nearly as effective.
For me it's exactly the same with Agile projects. As long as the WBS stays focused on what, it doesn't get in the way much when figuring out how. I'm still trying to figure out the best way for the product backlog to interact and have traceability with the WBS, but I would never take the step of throwing either of the two out.
Now, I only work about how to get to done after I know what done looks like.
Josh Nankivel is the founder of pmStudent.com, a site dedicated to helping new and aspiring project managers succeed. He has over a decade of project management experience in several industries, a Bachelor of Science degree in Project Management, and is PMP certified.
Josh is also the instructor of WBS Coach, a work breakdown structure training program.