WBS is defined as the work that is required to produce products. It is a hierarchical division of work into subparts. It works as a foundation step in project management. According to me these can be broken into two options 1)break down into design product, development product, test product 2)break down into regulatory, marketing, clinical, engineering. So here pitfalls can be using which option, than ofcourse time and communication also plays an important role because if there is no communication the project will take more time and you would not be able to work according to WBS. So for successful WBS person needs hard edge measurements.

For my Senior Design Project, we have to set-up a WBS. We use Microsoft Project Planner to monitor the tasks we have as well to see the critical path i.e(longest path for work to be done). However, this WBS doesn’t specify the actual project plan but rather specific tasks which are associated with working on the project. We know the critical path is the path which is the longest time duration but, the path which has various tasks that need to be done to complete the project. Since we are in school we are at the mercy of various people and their schedules which makes it difficult to follow a WBS since different factors change it. The WBS is a tool& technique which displays the route which is taken to successfully finish the project however, this is the ideal case which does not happen. Therefore, other factors can affect the WBS such as employee vacations, different PM groups etc. .which change the WBS.

I think one of the pitfalls of the WBS could be not breaking it down far enough. We learned that it is important to break down each task into subtasks and so on so that when you are completed, you have each individual task listed out. If you don't list out every individual task, I don't think it will be as effective, because you may miss a task and forget to put it in your network diagrams, pert chart, gantt chart, etc.

WBS is very important for a project. Its the initial planning part that the group performs together.If there is a difficult in properly identifying the WBS, it can affect the remaining part of the PM process.Some of the WBS Pitfalls is as follows:
1.Not knowing When to stop
2.Dealing with Group Dynamics
3.Discussing the sequence
4.Talking about deliverable
5.Not grouping activities

Work break down structure is basically tool used to help schedule,cost estimation and human resource management by breaking down a major work into various small work or thing that will be required to complete the bigger task.
Various pitfalls seen commonly are
1. Neglecting to create a WBS Dictionary
2. Expecting More than 100% from your WBS
3. Why bother with Formal Change Control?
Any update to a WBS, other than an elaboration of details that already exist, should require formal
change control. To ignore this step invites changes in scope that can spell doom for the project.
4. Adding Requirements in Lieu of Tasks
When you place a deliverable on your WBS, you can break down the deliverable into the activities required
to create it. What doesn’t work is breaking down the deliverable into the requirements that describe it.
Deliverables and tasks do belong in the WBS, but requirements do not.
5. Too Many Tasks

WBS does have its pros and cons. However, I feel that the biggest pitfall in this case could be having to do with multiple task all at once.The goal is to break down all tasks so that you can compete the project easily. However like we have learned, other priorities come in the way, the problem is that the your coworkers could end up spending a lot of time on the smaller tasks. This could consume a lot of time your managers are required to track of all the task. This could get put your main work on delay and also achieve poor results.

A WBS should be a break down of every project task and deliverable defined by the project scope. If the WBS is poorly constructed the following can occur: missed deadlines, going over budget, scope creep, confused project team members, project replanning and extensions. A WBS is a way to visualize and organize the scope of a whole project. If this is not done correctly, it is hard to ensure all tasks, deliverables and milestones are getting done. The consequences listed above all cost the company time and money as well as cause frustration among team members. Therefore, making sure there is a well constructed WBS is important.

Does anyone have any first hand experience on what happened because of a poorly constructed WBS?

Accurately breaking down the work breakdown structure is a very important aspect for a successful project, because it breaks down and organizes each task of the project. If the WBS is not well constructed it can cause project delays, missed milestones, overestimating or underestimating the budget based on the WBS. Some ways that a WBS can be messed up is by not correctly grouping sub tasks and tasks.

As stated above, a poorly structured WBS can have multiple undesirable consequences. Such an example would be many delays because sometimes you do not expect a problem to occur until you are actually doing the task and run into the problem itself. Then each problem must be resolved, and some times this simple issue may need many meetings and action tasks in order to resolve it. Sometimes in industry this would delay the project a lot, especially in a slower paced environment.

A project without a plan is a project that is planned to fail. while other documents such as the project management plan might touch on topics that are discussed in the WBS, it will not fully accomplish what the WBS can. Deviations and obstacles will still occur with the WBS in place but it will allow these problems to be solved more efficiently and by the most capable employees.

The WBS is a crucial part of the scope management process, no matter how small the project may be. It is responsible for breaking down all the tasks, delegating work to each team member, and making sure everyone is referring to the same guide. One of the pitfalls, is not knowing when to stop. Tasks should be broken down to reasonable sizes, meaning there shouldn't be so many small tasks that each one lasts less a week or so. Another pitfall is facilitating development the WBS, without excluding any members. The estimated time frame for a task should be determined by the people responsible for completing that task. Since WBS is a team effort, other pitfalls include arguing over amount of resources required, and the budget for each task.

The WBS lays out all the small tasks required to be done for the completion of the overall project. In order to have a plan set for all aspects working together, which is necessary for product development, the WBS is crucial. Like you said, the WBS is not a replacement for other documents necessary in planning phase, but it is a crucial part of planning. The WBS will allow project leads to set timelines for each task, and accurately predict progress and budgetary progress. Overall, the WBS is an essential part of the planning phase in successful product development.

WBS is important for identifying tasks and showing how they relate to one another and I believe one of the issues can be not getting enough in-depth on the tasks needed for the project. If something that task turns out to be 2 or 3 than that not only changes your WBS but everything related to it. Having this happen for one of your tasks should not slow down your project by much but if this a common problem with the first set-up WBS than it can lead to major delays

The Work Breakdown Structure is crucial to for a successful team and a  successful project. It explains the project scope and breaks down the task needed to be completed for the project. This also allows project managers to identify any problems, and provide better leadership and management over the project. However, there are some pitfalls to the WBS. Some of the pitfalls include possible increased work burdens on the project manager, determining the correct amount of detail for the project, and lastly if a project has begun, it will be hard to change the WBS if there is a change within the project.