This is a very important topic to discuss. The work breakdown structure caught my attention when I was listening to the lecture. I have had many projects where communication and time conflict has been a major issue. However, having a successful project was always implemented with two key concepts, the breakdown of work, and scheduling due dates internally for the team. WBS itself is not enough to have everyone put their best into the project. Internal due dates, abide everyone with a certain date that allows a buffer time between that date and the submission date for review and modifications where needed.

This topic is very interesting. I think this is the most common problem while working in team. I have experienced this situation many times due to lack of communication, delay in replying and most important when the team members rely on each other to get things done. While working in company, it is not possible to rely on each other completely because everyone assigned to do his/her own task and expect to finish in timely manner. WBS is created for a reason, for example help explains project more in details, assigning responsibilities, and realizing the time, cost and risk associate with the project.

This point is extremely intriguing. I think this is the most well-known issue while working in group. I have encountered this circumstance ordinarily because of absence of correspondence, postponement in answering and most essential when the colleagues depend on each other to complete things. While working in organization, it is unrealistic to depend on each other totally on the grounds that everybody allocated to do his/her own assignment and hope to complete in convenient way. WBS is made for a reason, for instance help clarifies extend more in subtle elements, doling out duties, and understanding the time, cost and hazard connect with the venture.

You have raised a very good point.

I have to say that WBS is probably one of the top 3 most important aspects when doing a project. The projects I did was for a small company and therefore knowing the due dates for the different stages of the project was very easy because we had great communication between the team members. The advantage of working with a small team is that there are daily reports on the advancement of the project because we all used to work together. However, some weakness that I found was that since the team members were not too many, we had to go out of our knowledge specialization in order to complete the project. For example, a person who knew more about biomechanics had to implement a lot of electronics into the project. Because the electronics person was already busy doing something else. I have to mention that we were all aware of this when the tasks were decided, but since we were not too many we had to go out of our “comfort zone” and finalize the project on time.

I agree with everyone regarding working in the team and using the Work Breakdown Structure(WBS) for assigning the work to the team members. There are few more points i would like to add to the discussion:
1.To successfully use a WBS, the project manager needs to prepare a 'to do list' for the project which is very similar to a grocery list one makes while going out for grocery shopping.
2.He should understand really well the requirements of the client such as the deadline for the project, budget involved, use of any outside contractors or not. And should communicate these specifics to his team.
3.He should give out a clear picture of what a good job should look like to his team members by stating the performance expectations so that there is no confusion later on and the team members are aware of what the client is expecting from them well in advance.
4.He needs hard-edged measures to determine the project progress which is not open to any type of word games.

Like many of the previous replies, a lack of communication and time has been one of the most prolific problems in the projects I've worked on. In one such project we had made an initial WBS that we would have updated as we gained knowledge of the processes we were working on, but as time went on we had forgotten and put it on the back-burner. This resulted in a mad scramble towards the end of the timeline where we kept running into new tasks that we had to do but did not expect. We did end up finishing albeit with much less features than we initially hoped. Really good planning cannot be neglected.

I agree with you jp582. Relying on others can be problematic. An interesting concept that I had learn from my previous class with dr. Simon, was that the entire department in real like examples is responsible for the shortcoming of one of their members. Do you think that is true for all teams ? or can it be troubling in smaller companies where departments are not that big to accommodate such setback ?

In my company, the Work Breakdown structure more closely resembles option 2. I have seen various degrees of success with this. I think one of the problems I see occur is that the people providing input into the work breakdown structur are not the people actually performing the tasks. Often the higher ups don't necessarily know all the ins and outs of how a project task might be run or how to properly break it down. Also by separating by departments it can be difficult to identify interdependence of tasks. For example, one person might be resposible for a change assessment, but Regulatory would need to provide input into that assessment. The regulatory input could take several weeks because they need to get input from associates around the world. A manager in R&D who is usually responsible for changes may not understand why a task takes so long.

Although I have no medical device industry experience, I have worked on team projects in other fields. As a supervising teacher, I have had lead on several projects that have been implemented with varying degrees of success. I believe that those with higher degrees of success were the ones which were most often started with more planning. The best were those where lines of communication were established early on so that any issues that might have come up were readily discussed and dealt with.

In my company, one of the projects I am on closely resembles the second option. The second option is more relatable to a typical medical device product development cycle. One of the main problems is time. Assigned tasks or action items may get pushed back when members are bombarded with multiple priority tasks. This is also an issue of limited manpower. However, hiring more manpower depends on the budget at a given time which changes. To circumvent this, communication and understanding are needed on all fronts. For example, my supervisor may allocate a little more time for some action items if it does not hinder the due date. Otherwise, the action item might get split between a few members of the team.

One experience that I had with this was in my undergraduate research. The research I was doing was in collaboration with another lab on campus. The other group with electrospin PLLA based fibers and then I they would send them to me to mechanically characterize them. Doing a collaboration between two groups like this comes with a number of potential delays. There would sometimes be breakdown in communications. The most common experience I personally would experience would be submitting a request for more materials to test which would not be responded to for a week leaving me with very little to do in the mean time.

During one project I was on at my company, the WBS wasn’t executed well. One particular mechanical engineering team was overloaded with many tasks, the other teams had a more reasonable workload. The reason for the overload of tasks was because of what that team specialized in, which this project saw a lot of what they did best. Delayed progress and lack of communication since they were always in the lab working, caused some frustrating situations during this project. Eventually to help ease off the workload, members were pulled from the other teams and assigned to them for assistance. I was one of the switched members. But even then, we had to brought up to speed before we could have been of any use. So it is very important to develop a well-balanced WBS for a project. If you can see that a particular branch will see a lot of work then it would be wise to adjust the WBS or acquire more resources.

I work at a very small company so they assume that they do not need to complete WBS at all. So this accounts for everyone taking on more responsibility than is needed and certain things falling through the cracks. We manufacture diagnostic tests and every year we have certain tests that we make for only about 2 months out of the year (not a large order and we can fill the entire order in this time). This includes growing and infecting the cells in order to extract the antigen and manufacture the test. However, the testing for the product requires different QC and in process testing materials that we don't use regularly throughout the rest of the year. This all should be covered in the WBS but since we don't use one, there was always a rush for raw materials before anything else started which always used to put us behind. Now the biology department has a new leader that knows that this happened every year and takes in on himself to order everything needed instead of the person who used to do it.

When it comes to the work breakdown structure how you manage and decide the work breakdown can dictate the rest of your project. In one project I had worked on in my undergraduate was dealing with developing a circuit board that can accurately detect heart and apply the necessary filters to it through Biopac. The first day we had 2 people missing and because of that our entire work breakdown was ruined. We had not divided up parts equally based on everyone's strengths. Because we had not broken up the work evenly, everything was delayed in getting completed and we had to rush to finish the project on the last day just minutes before it was due. Also, because of the time delay we had not completed the project to the best of our ability and had submitted faulty results, where if we broke down the work we could have provided statistically significant results. I think work should be broken down into what people specialize in, and then from there break down the work as to who is doing what and when is it due. In addition, I think it should be a group of 2-3 people so that they can communicate and solve problems faster, to keep on track with the time schedule.