We have a very efficient way of tackling this dilemma. Every two weeks each team sits in a room and looks through the work needed to be performed for the following two weeks. Based on this, we write tasks for about 45 minutes to an hour. Then, after everyone is done writing their tasks, we discuss them one by one. We give an hour estimate to how much each task is worth and the entire team has to be in consensus. If even one team member doesn’t agree with the estimate, we review the task and reassess the time allotted. This helps us in the long run because it verifies the time for each task and we most likely end up finishing it on time, unless an unexpected scope growth pops up.

It is very important to have all the team members on board with the same timeline and to have regular updates on tasks. While estimating workloads may not be exact, it is important to be very vigilant to estimating and updating as closely as possible. It can be detrimental to animal studies if timelines are overestimated. Animal tissue should not be kept frozen for long periods of time and if clinical trials are waiting for scaffolds to be developed, there can be serious consequences to the data collected.

For the project manager to come up with an ideal time for each task has to come after research on this specific task and then answer some questions like if this has been done before and if yes how long did it take, ask some people who have done something similar to see what could be an appropriate time frame for this specific task, or maybe ask the team member who will be responsible for this task to see how much time is needed for it. As we experienced from the mini-simulation 2 from this week that when the manager assigned tasks to people without doing the appropriate research on how long will the animal study should take there was an issue of delay because the time frame needed for this task was more than what was assigned. Regarding the second question, there should not be much extra time for a task. Yes, I agree with the idea of overestimating time for a task to prevent getting behind on schedule but at the same time, it is not wise to overestimate by much. Adjustments could be made on the schedule if there is a task that was finished at the earlier due date. I think the next task or milestone should be approached right after but it is wise to see if this could be an issue for another team member. Also, it depends on how these tasks are overlapped with each other if they are dependent or independent of each other. From my experience, when there is a task was completed earlier than the estimated time it is better and wise to use the extra time to work on missed milestones or probably to fix an issue with the completed task or maybe modify something in the process.

It is true that managing duration in a project is one of the hardest tasks for the PM to handle ideally. Even though all task durations were arranged and planned precisely, some out-of-control issues could appear at one point and require a timeline rearrangement. Therefore I agree with the initial statement that having every manager from each discipline to meet and discuss time estimation for each phase is an essential step in the planning process. On the other hand, I think everyone involved should optimize the simultaneous tasks that can be achieved from each department and each phase. This will enforce a more rigid framework for the project. Also providing strong communication channels in order to get periodic updates on the work process, this would allow working on different tasks while modifying the failed one.
However, I think finishing early should not be a concern but if it happens I think more time should be devoted to the product validation.

I belive that the measurements and control meetings are are great way to keep everyone updated. There are updates to every chage in design, documents and also the work done is discussed. This are the controls of the changes and a way to measure those changes. This also keep telling the people about their timelines, tasks and their completion. Thus can be a good source to estimate and complete work for given timelines

I agree with most of what you've said, but it seems you haven't addressed setbacks, major or minor. Weekly planning meetings, from my experience, deals with changes to the schedule and accommodates any issues that may come up. There may be some setbacks that you can't account for. Let's say a vendor had problems with an order that your entire plant needs, not just your project. That delay will set not just you back, but your whole facility. If your project isn't up and running, while the rest of the plant is, your project is going to be at the bottom of the priority on who gets the first shipment. You can't account for stuff like that happening. You can leave some leeway in your project but that might not be enough. One issue that may be increasing is cyber attacks that cripple your systems. You had no way of seeing that issue coming up and building it into your schedule.It's best to have a schedule as a guide but not be too beholden to it. Flexibility allows survival.

For effective project management, accurate time estimation is crucial. The team member and their logs must be updated at each and every milestone for clarity and proper completion of the project. In order to achieve that goal, all team members of the group should meet up and discuss their time estimations for each step and their reasons. Furthermore, communication is important in project management.

Personally, I don't see this strategy as an actual situation. In my company, each team posts each task on a virtual project management board. Some tasks depend on others and are therefore linked with yarn and stickers. By carefully developing this VPM board, the entire team comes up with a realistic estimate for the project completion. At the end, the teams are asked to estimate their best case timelines and the best case deadline for the project is determined. Of course, on top of all of this, contingent risks, along with their outcomes if they were to occur, are clearly outlined and posted on a separate board. This gives upper management an understanding of where the project stands in terms of timelines and what to expect. Perhaps focusing on only the worst case for timelines would be the safest course of action that will avoid providing everyone with a wide range of timelines. However, this would likely prompt upper management to urge the team to compress timelines to meet stakeholder expectations.

I don't quite see the difficulty in designing a timeline, more than I see the difficulty in executing that timeline. I should be important to identify tasks that are most likely going to be either/or time consuming and complex to execute, and provide a larger time frame for those tasks. Moreover, the timeline should be updated as the project progress to account for any early ( than scheduled) task and incorporate the remaining of those hours into the most challenging tasks.

@vcf3

I disagree as I think designing the timeline is the hardest step if there is no prior successful timeline with a related project to compare it to. The PM must be cognizant of his/her team member's capabilities in completing their tasks on time and this can prove difficult if it is a completely novel task as the team might not have experience dealing with it. Thus, an important step - if team members do not have knowledge on a task they are assigned - is estimating time for learning tasks. This would prevent missing timelines due to incongruencies in knowledge. 

Executing the timeline is not as difficult from my perspective as proper communication, scope management and leadership can deal with any obstacles that come. 

Learn from previous experience, project are different but the main idea in planing and managing are the same. Feedback to see the progress of the tasks is necessarily in every step in the project and this can lead to a better understanding of the time that each task is taking and its sub-tasks.

A meeting should be held to review the progress and the relation between these tasks especially if there were any finish to finish relation or start to start, where two tasks must finish in same time or start in the same time, which might cause problems in the flow of the project.

In my opinion both designing and executing a timeline can be difficult, and the difficulty of executing a timeline is dependent on its design. A well-designed timeline is the foundation of a project, and with clearly defined responsibilities and tasks with ample time to complete, the project can proceed smoothly. However, unexpected delays are often inevitable in a project. If this occurs, instead of extending due dates on the timeline, it may be a good idea for the project manager to look into allocating more team members to work on the tasks that are running late, if feasible. This of course would not be beneficial if the reason for the delay is out of the project team’s control, but if the delay is due to the task taking longer than expected to complete, then the personnel you have available to you could be reallocated if their own responsibilities are already being completed on time.

Assuming an initial timeline is already developed, I would suggest that the group tracks and analyzes their progress on a somewhat daily basis. Each task should be divided into subtasks if possible, in order to help track the task. As each subtask is accomplished, it can be checked off and give the user a visual of progress. If a task is completed too early, the team will have to update their timeline. In this case there is a lot of room to adjust the remaining tasks. This is a better circumstance than updating a timeline due to finishing a task too late.

There are a number of ways to tackle predicting duration times. Using historical data is the best way to predict accurate times because you can take an overall average or use special simulations to predict best and worst case scenarios. In the case where there is no historical data, it is not recommended to take the best case scenario duration because there is no buffer time built into that duration. The team should run iterations to identify the bottleneck in the timeline for the specified time duration. If you really isolate this incident and add up the remaining some-what predictable duration for all other activities, then the only varying duration will come from that unpredictable task. Milestones can be built into the schedule right before these unpredictable tasks so that they are isolated and easy to identify. This method will also make it easier to explain why there is a push in the schedule. So, the best way to remedy the situation of planning other steps and the overall finish product end time is to be up-front and forthcoming about the placement of these unrealistic/unpredictable duration, because pushes in schedules will come from this uncertainty. That way, there is no need to explain why a duration was expected to take longer or shorter than originally anticipated. 

There are certain reasons why the team might have to update the whole planned process due to finishing tasks too early. There may be instances when there is compensation to the team for finishing earlier than usual. Some companies actually give bonuses to their employees if certain milestones are completed earlier than usual because the company gets compensated from their customer. 

I agree that the entire team is needed to determine the duration of the project and each task because those who work on those tasks will know how long they will take and what will be involved in the task. They will also know whether they’re going on vacation that could also change how long the tasks will take which needs to be accounted for. I don’t think there would be a huge issue if certain tasks were completed early because than it would give more time for other tasks to be completed or if other tasks have delays, the timeline would still be on track. Other things that can be done to fix this situation would be to continuously reference the Gantt chart and make sure to adjust the timeline as necessarily. When there are adjustments to the timeline, everyone should be informed on why it’s being changed and how the process can be improved or how other people can help as well.