In my years of teaching project management, I’ve noticed a pattern with students in my fundamentals class when it comes time to create a work breakdown structure (WBS). Without fail, everybody always jumps to implementing the project as opposed to first identifying what is going into it. Even students who are already certified project managers have this mindset, and when asked, they admit they are not using this tool for various reasons. They may be conditioned by their work environment to skip all the “project management stuff” and just get the project implemented. Some state that they do not have the time or are not able to get their team together at the same time to get it done. Others think that a project manager is supposed to create it all on their own.
For those project managers that feel pressured to skip this important step and push their team straight into implementation, I have found that they experience issues with the quality of their project implementations. No surprise, right? To these people, I ask why they have time to make corrections after the fact, but do not have time to at least create a high-level work breakdown structure. They never have a good answer for this question.
For the ones that state they are not able to get their team together at the same time to create the work breakdown structure, I explain that it can actually be done in phases and that it is a living deliverable that can be amended as needed when new information becomes available. This response seems to surprise students as it never occurred to them to meet with team members separately and collect their contribution to the effort piecemeal. Although it is ideal to have everyone in the same room at the same time, like it happens in a classroom setting, it is not the only way to get it done.
And for those others that think they are supposed to create it all by themselves, I first ask where they got that impression. Then I ask how they intend to accomplish this task when they are not the subject matter expert. I usually get a blank stare from them at this point. I also ask if they have access to documentation from previous projects. I prefer to ask students questions rather than spout a string of “you should do XYZ” statements at them to encourage thinking for themselves instead of just about what someone else told them. Once they ponder what information they have available, I suggest they look for similar projects and research the related documentation to help put a straw man work breakdown structure together and then schedule time with the team to help fill in the gaps.
For some of us old-timers, these suggestions may sound like a no-brainer, but I come across this lack of work breakdown structure usage and accompanying excuses so frequently that I thought it may be helpful to share this information outside of the classroom. Sometimes students even admit that they are not comfortable getting up in front of a group and leading this type of exercise because they are not sure they are doing it correctly. To this excuse, I respond with a reassurance that unless they are getting up in front of a group of certified project managers, their team members probably have not read the Project Management Body of Knowledge and will not know whether it is being done correctly or incorrectly.
In fact, in a fundamentals class, I normally let the students use whatever information they come up with during the exercise because most of them are new to project management and have not quite grasped the concept of a deliverable at this stage. Once they have filled the wall up with an acceptable amount of sticky notes, I point out the differences between deliverables and tasks as well as potential rearrangement of the information to demonstrate options in how best to organize. I also share that in my experience, team members understand tasks (as they are thinking about how to get the work done rather than what needs to be done) more readily than deliverables.
I encourage the students to take whatever their project teams are able to give them during this exercise and then translate the information into deliverables afterward where possible, and not to be overly concerned about a mixture of deliverables and tasks in their work breakdown structure. At this point in their learning, I am more concerned about getting them to think at the twenty thousand foot level first to ensure they do not fall into the trap of tunnel vision in assuming a specific solution for implementation. Because we all know what happens when we assume anything.
Similar Content:
-
No time for risk management? Tips on how to factor risk into a Work Breakdown Structure
-
The implications of skipping scope definition
-
Managing risk: Are you situationally aware?
