Over the past few weeks, I have been focused on the leadership aspects of Project Management…the power of saying No, the importance of integrity and delivering the tough message, and a guest post on motivating employees. This week, I am going to talk about a more specific role of the project manager….developing a work breakdown structure (WBS). Don’t get me wrong, this is a ‘team sport’ and will require your leadership skills to motivate, negotiate, etc but it is really a function (in my mind and on my blog, so I get to be right)
The WBS is a collaborative commitment that helps keep the project on track. So before we get started lets take a look at another method of keeping people on track…here is the video of the week.
I hope you enjoyed that, now lets get into this WBS stuff. When a PM receives the Project Charter document, they have a list of deliverables or objectives that a client needs developed as part of the initiative. Realize that project management maturity will differ across almost every organization, so below is more of a high-level explanation that I believe can carry across industry, initiative, and client’s project management ‘aptitude’.
- First, I ask the project sponsor (Business analyst, marketing rep, etc) to join the the team and discuss the project requirements/deliverables. This provides the team an opportunity to ask for clarification on the deliverables and reduces the opportunity for things to get lost in translation. In my experience, the project sponsor leaves with a confidence that the team understands and the team feels confident about what their marching orders are. *While projects have been called progressively elaborate, my experience tells me to get it right (as right as you can) out of the gate. If you change your mind too often, you will frustrate the team and lose their confidence.
- Next, I make sure I have the appropriate resource associated with the deliverable.
- I then setup an interview schedule with each resource owning a deliverable.
- During the interview I ask them to think of the final product/service and work their way back, thinking of the step that must occur immediately before this one. Lets just say the deliverable is employee training…
- The final product is an instructor standing in front of a class teaching a class
- Immediately before that we send a reminder email to the participants
- Before that, there is final confirmation of facilities, equipment, material, etc
- Schedule class/facility
- Right before that we close registration
- ….enable a registration
- Train instructor
- Secure instructor
- Finalize Course Material
- 2nd draft of Course Material
- 1st Draft of Course Material
- Review End to End process
- Begin Process
- As the PM, I then take their list and flip it into an MS Project plan/Schedule…
- Conduct Training
- Review & Document End to End Process
- Capture screens shots, schema, etc needed for course material
- Create Course Material
- 1st Draft
- 2nd Draft
- Secure Resource
- Train Resource
- Conduct Training
- Enable Registration Portal
- Close Registration Portal
- Schedule/Secure Facility
- Confirmation of facilities, equipment, etc
- Reminder Email sent to attendees
- Execute training session
- After creating the WBS in MS project, I then send that to the appropriate resource and ask them to review the list…make sure I captured the efforts correctly, add a task if we missed it, update the verbiage if it doesn’t make sense, etc.
- I then ask them to think about the best case and worse case in terms of how long it will take each task
- I ask them to list any dependency they can think of (I can’t start until so and so finishes in department x or task 1 can’t start until task 2 finishes, etc etc etc)
- I then take their input and develop the durations, create the start/end dates, and link the dependencies in the MS Project file
- Finally, I host a full team meeting in which I review the schedule from top to bottom (I often bring lunch). This lets others provide some input, dependencies to talk it out, and the overal team to provide some insight that we may have missed during 1 on 1 interviews.
- Lastly, I send the WBS out for the team to review and provide their official sign-off on.
The schedule is set…the experts provide lead on their respective sections, the team has collaborated on the schedule, and commitments has been made and buy-in achieved. We can officially move to the change request process :)
I certainly realize there are some other ways to do this, but this has been a solid method for me through the years. I have had project team members very comfortable with creating a WBS for their activity and still enjoy the interaction this provides. You can tailor this to meet the experience of your specific team members (more hand holding for newbies, ‘micro-managing’ for that resource that likes to keep it in their head, and loose for those trusted resources you have worked with in the past.)
Below are some great resources on Work Breakdown Structures (WBS):
How To Create a WBS With Microsoft Project – The PM Hut
Work Breakdown Structure: Purpose, Process and Pitfalls – Project Smart