How to WBS and Why You Should Train Your Devs To Do It

07/07/20181 Min Read — In Project Management

You hand your dev team a brief and ask for estimates. Maybe it's just a stack of mocks and a loose assertion of the client's preferred stack. Or maybe you get a proper RFP. Whatever it is, you gotta get estimates and a statement of work out the door and you feel pressure to crank it out immediately.

Refuse to bend to this anxiety. If you aren't doing the due diligence of further interviewing your potential client to squeeze out the complexity, to banish the ambiguities, you think you've seen this all before don't need to do that much confirmation ("oh, this is a brochureware WP build, no problem") then that's a business decision you will have to deal with.

But Friend, do not double down on this bad behavior and also not do a proper estimation. Do not pass off to your already-drowning-from-the-last-time-BizDev-and-Project-Management-did-this-to-them developer and then hold them to estimates that you never gave them enough time or information to realistically provide.

Put a WBS meeting on the calendar and do the fucking work. They aren't going to like it and you have to run it. Use the first one to teach them. Document in. Then it's an Each One Teach One. It's going to be not great but after they do enough of them, the team will get a lot better at them. And they'll have references to review. Instill real grown-up process instead of just hoping that the tech team can divine a perfect answer. They can't. You can't. Together, you can make and follow a process and make it shine.

WBS how-to basics

  1. Describe master task (program level)
  2. Break down into major element tasks (project phase level)
  3. Break down from phase level into features (think Epics)
  4. Break those down into logical chunks (think Story)
  5. Break those down into subtasks (think checklist)
  6. Identify relationships between lowest level tasks (finish to start, start to start, etc)
  7. Sequence to identify predecessors and successors
  8. Item with no successor is end/deliverable
  9. Arranged task level items become your network diagram
  10. Assign tasks durations
  11. Determine critical path
  12. Arrange WBS/Network output into table with durations
  13. This will be your schedule in Gantt format
  14. Check your critical path against slack items
  15. Use your path and slack in schedule to determine staffing/scheduling needs

Now you've got reasonable estimates a project plan mostly ready to go. Look at you!