I think it is important to have some buffers in the schedule to account for any unexpected delays for any reason. The time frame and budget is set when a project is approved. It is better to overestimate the time and money needed for the project when getting approved. If the time and money is underestimated, the company may not have the resources or want to use the resources to continue the project when it needs more time or money, poorly reflecting on the project manager. On the other hand. if a project uses less time or money from when it was originally approved, it reflects good on the team and project manager for saving the company resources.

In response to whether the project should downplay progress or not, I think the project manager should answer questions about progress in relation to the buffered budget and schedule as explained above. In my opinion, it is not the project manager's job to prevent other departments such as marketing from "jumping the gun". This seems like a bigger problem within the company.

Yes, I agree with Ashley that its good to set buffers in your schedule to account for the unexpected. At Sloan, if I'm working on a project-especially the development of a medical device- I always include buffers to my timeline. I know the principal investigator/ inventor will sometimes be behind on providing deliverables and will sometimes be out of the country on conferences, in clinic, etc so I always include buffers in the timeline to set the expectations of management. If you think the development and commercialization will go accordingly to your original gnatt chart or whatever you determined to be the optimum timeline, I personally think that is naive because that will never happen. You will always end up making changes to the gnatt chart and deliverables along the way. It is always good to plan though. As we learned in lecture, if you fail to plan, you plan to fail. So I think you should do your best as PM to set realistic timelines and expectations for management but don't be surprised if the timelines and deliverables change along the way.

I think that the best way to prevent employees from going off on their own and making decisions that will effect the whole project, is to have a clear scope baseline. As a project manager you should have your scope statement, a clear work breakdown structure, and a work breakdown structure dictionary. Having a clear scope statement will outline what will be focused on and what is to be excluded. With a work breakdown structure and work breakdown structure dictionary you will have a clear definition of the job each member is supposed to perform and what their boundaries will be. In the case you describe it seems that there were no boundaries set in a WBS dictionary by the project manager.

Building in delays is a good idea, but one thing no one has talked about is how long that buffer should be. You can't make it too long or else you may give the impression that the project shouldn't be done by an earlier date of nothing goes wrong. That extra time may make people complacent, which is the wrong result of what this is intended for. With this in mind, I agree with what Anthony and Ashley said.

jr377 taking into account how long the built in buffer should be is an important point to bring up. As with all parts of the project this too will be a factor that impacts the budget. The extra time allotted for a buffer window must be factored into the overall project budget because that is more time the company needs to pay employees or contractees for a project that could have been finished sooner and a new project could have been started. This goes back to being aware of the company strategy and taking this into account while project planning. On the other hand, if the buffer window is planned properly there will be no delays and the project may even be finished ahead of schedule which always looks nice to your superiors.

In the field of project management, things do go wrong and unexpected changes are always there. So, including a time buffer as a line item in the schedule is a way to account for unknown changes in the schedule. Also, I think this is a better way to avoid an extension of the project in order to protect the critical path from further delay instead of extending the project time in the schedule. Time restrictions help to use work time more efficiently. If the project proceeds faster than buffer times are consumed, everything is in the green, which is good for the team and the project. If buffer time is consumed more without real project progress, the project is critical, which is marked red.

Anthony, I'm not sure that employee and contract payments are the issue in that. Full time employees get salary, so they usually would be working on another project/aspect if they finish early. Contractors get paid hourly (for the most part) and if they finish they either stop getting paid, or they get moved to another aspect/project. I don't know of any that get paid for a specific time period, whether or not they finish late or early. The rest I agree with. As I said in another thread, finishing early is never a problem.

I have not worked in industry but I am currently working on my senior capstone project where we are developing a device and mimicking how the process would occur in industry (having status meetings, design reviews, etc.) My group and I have done a really good job at being realistic with our customer and our advisor about the design expectations, so we know we will be able to deliver exactly what they ask for. Additionally, we have placed buffers in our schedule for situations where we might encounter issues, which has happened. Our main strategy for when we are at a standstill in one area of the project is to try and progress in another. Therefore, in our status meetings we say something along the lines of "we had some delays in this area, but took the opportunity to get ahead on this in order to be able to dedicate more time to the other area next week." For the most part this strategy has worked and we have been able to stay on time keeping both our customer and advisor content.

It will be prudent to include buffers in the project plan to account to the unexpected. This is a practice in two companies I have worked for developing medical devices and combination products. I always include buffers in my timeline and DDP. Your example of marketing department going off and doing their own thing and impacting the project team can happen in dysfunctional organizations. However there are many other aspects during development of a product that can bring change to the project plan such as change to the actual product (e.g. design changes to improve performance). The important point is to understand that your gantt is a living document just as other documents (e.g. DID) that will change at least once to several times during the project development.

I agree with ec52. Buffers are set in place to account for unexpected events. As well as with the point that the gantt chart is a living document. I would like to add that communication helps eliminate human error. The marketing department "going off and doing their own thing" could have stemmed from misinterpretation of communication to them. Clear and concise communication can help eliminate that.

When determining a schedule human factors should already be taken into account. I believe that a good project manager should already have sick days, and vacations accounted for. The most dangerous waste of resources would obviously be what cannot be accounted for, and was just previously mentioned, sick days. Vacations can be planned, and should be communicated to the PM in order to allow for proper accountability/planning. Sick days are the one variable that are never planned by the person taking them. I would count this as the largest and most detrimental human factor. Therefore, a good PM would go into the project plan fully knowing that a person, or persons, may fall ill which would push back the final delivery date of the project. To combat this the PM should be aware of the amount of possible sick days the company provides, and factor in how much a sick person would delay this project. Many project members have different talents and contribute at different rates. I would say one way to determine how much the project will be affected by this human error is to account for the best team member taking a work week off. Of course this factor will depend on team size, but in this example let's just say a team of 5. With this sick time allocated, the project will be given a reasonable scope to be completed, and no one falls ill it should be completed before the expected time!

Unfortunately with project management, things tend to go wrong at the most inconvenient time unexpected changes are unavoidable. However, I do think that when briefing the management personnels about the progress of the project, PMs should try to be as factual as impossible, avoid vague promises and provide reports reflective of the actual progress, and not reflective of the report that the higher up will most likely like to hear. If the project proceeds faster than buffer times are consumed, everything is in the green, which is good for the team and the project. If buffer time is consumed more without real project progress, the project is critical, which is marked red. Whatever the status ( green or red), it will provide an honest presentation of the progress and a better brainstorming of ideas to turn the red status into the green status.

The time factor in project management is one of the things that must be considered when planning the project, so that the delay in implementation is not one of the sudden matters for the project manager.

There should be a clear and specific time margin for each stage of the project, and this margin must consider, If the delay in implementation exceeds the specified timeframe, including the expected timeframe for the delay, then priority activities must be identified and implemented first, and the full project timetable should be reviewed and reasons for failure to anticipate such a delay should be considered.

One thing that I have not seen discussed as much is everyone on the team having a complete understanding of who controls the project flow, timeline or schedule. It is usually the project manager, but sometimes - depending on if sequential tasks get completed - individual team members can update the timeline according to things they experience. Regardless, as mentioned earlier, communication within the team is vital so people like the marketing team "go off and change the deadline on their own".

One time, I experienced a moment where a member of our team went above our manager's head to report something and while it did not affect the schedule of the project, that team member had to be reminded of the work hierarchy once more.