Can we agree it is not a good idea to have "meetings" in schedules, even pre-construction or prep meetings? - Why, because they depend on 10 people mutual calendars than logic, to even get close would require constraints which are generally not allowed, and for all work activities there are common sense orbital work items that should not be put in CPM schedules. I do not like it and wouldn't do it, but I am generally out-ranked and its not worth the arguement - so I at least try to limit it to the critical or near critical activity meetings only.
Can we agree it is not a good idea to have "meetings" in schedules, even pre-construction or prep meetings?
Forum Sponsor
Top Posters
Julian Pegg
1 posts
Peter Nagy
2 posts
Raymund de Laza
17 posts
Syed_Asad
0 posts
Tony Greyvenstein
0 posts
Ahmed Al-Jubouri
13 posts
Umar Alvi
3 posts
Sibusiso Mahlalela
0 posts
Michael Samanyayi
3 posts
Simon Gumede
0 posts
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.
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.
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
Ever seen schedules that include milestones for each monthly submission date, logically linked together using lags? Guess what they end up becoming..