Meetings are events that occur within the project. Regular meetings such as weekly progress meetings are part of the project scope. They should be included in a program. In MSP they can be included as recurring tasks. Other meetings may be significant and should be included in the program, if only to record their occurrence. They should be in the program but they are not linked into the network. Recurring tasks in MSP always get a SNET date constraint, that's how it works. This is one of the legitimate reasons for and use for constraints. Where you say constraints are not allowed, that is for tasks in the CPM network.
I believe all of these support my argument. The deliverables listed that should be in a schedule may or may not come out of a meeting - it is the deliverable that is important not the meeting. Such as "authorization" - that is a written deliverable. The others such as site start - those are physical actions. I am not looking for arguments with schedulers because we all have experienced different scenarios, - it was an issue on a project that I took over that already had meetings in it - it is hard to have them in without breaking the specs - no constraints but that is easiest way for meetings, no neg. lag but..., etc. Generalities are tough in such a diverse industry. I worked on DOE projects where half the work was meetings.
Member for
20 years 4 months
Member for20 years5 months
Submitted by Peter Holroyd on Sun, 2022-11-20 10:46
agree with Patrick. Some meetings types are essential to maintain a schedule - Design Safety authorisations, HAZOP, Constructability, Contract Kick Off, site start. JV decisions etc. Key project activities must be completed and submitted to the meeting before authorisation can be given to proceed.
Member for
24 years 9 months
Member for24 years9 months
Submitted by Patrick Weaver on Sat, 2022-11-19 01:10
There are two types of meeting. The routine administration meetings and meetings that provide decisions or other outputs essential for work to continue.
Routine admin functions including meetings are a resource and cost issue, not a schedule issue and generally should not be in the schedule (or included as a 'hammock' or non-critical LOE activity to hold the resources and costs).
Key decisions, authorizations, etc. should be in the schedule as they constrain future activities, these are usually best included as a milestone identifying the required decision/authorization.
Member for
19 years 11 monthsMeetings are events that
Meetings are events that occur within the project. Regular meetings such as weekly progress meetings are part of the project scope. They should be included in a program. In MSP they can be included as recurring tasks. Other meetings may be significant and should be included in the program, if only to record their occurrence. They should be in the program but they are not linked into the network. Recurring tasks in MSP always get a SNET date constraint, that's how it works. This is one of the legitimate reasons for and use for constraints. Where you say constraints are not allowed, that is for tasks in the CPM network.
Member for
12 years 5 monthsI believe all of these
I believe all of these support my argument. The deliverables listed that should be in a schedule may or may not come out of a meeting - it is the deliverable that is important not the meeting. Such as "authorization" - that is a written deliverable. The others such as site start - those are physical actions. I am not looking for arguments with schedulers because we all have experienced different scenarios, - it was an issue on a project that I took over that already had meetings in it - it is hard to have them in without breaking the specs - no constraints but that is easiest way for meetings, no neg. lag but..., etc. Generalities are tough in such a diverse industry. I worked on DOE projects where half the work was meetings.
Member for
20 years 4 monthsJohn,agree with Patrick. Some
John,
agree with Patrick. Some meetings types are essential to maintain a schedule - Design Safety authorisations, HAZOP, Constructability, Contract Kick Off, site start. JV decisions etc. Key project activities must be completed and submitted to the meeting before authorisation can be given to proceed.
Member for
24 years 9 monthsThere are two types of
There are two types of meeting. The routine administration meetings and meetings that provide decisions or other outputs essential for work to continue.
Routine admin functions including meetings are a resource and cost issue, not a schedule issue and generally should not be in the schedule (or included as a 'hammock' or non-critical LOE activity to hold the resources and costs).
Key decisions, authorizations, etc. should be in the schedule as they constrain future activities, these are usually best included as a milestone identifying the required decision/authorization.
The purpose of a schedule is to plan and manage the work of the project, not to be a cost system: https://mosaicprojects.com.au/PMKI-SCH-010.php#Overview
Member for
20 years 6 monthsEver seen schedules that
Ever seen schedules that include milestones for each monthly submission date, logically linked together using lags? Guess what they end up becoming..