Fixed Dates - Best Practice RRS feed

  • Question

  • Hi,

    I am currently trying to schedule a project which has fixed meeting dates which are controlled by the client i.e. a committee which sits only every 7th of each month. I'm trying to figure out the best way to enter these fixed dates, but a google search has just told me to avoid them all together, which I cannot.

    Please could you guys let me know how you would deal with this? Or if there is a best practice method?

    All help greatly appreciated.



    Thursday, May 11, 2017 3:25 AM

All replies

  • Andy,

    if you type in a start date for a task you will create a "start no earlier than" (SNET) date constraint.

    If you type in a finish date for a task you will create a "finish no earlier than" (FNET) date constraint.

    Generally, you should avoid imposing date constraints on tasks, because you are going to be wanting to use the built in critical path method which calculates the dates based on the duration estimates and the predecessors/successors.

    Once you start typing in dates you may as well not be using the software. Also, once you type in dates you have to maintain those dates as the project proceeds. If you do not type in dates then when you update progress tasks will be automatically re-scheduled accordingly. This is much easier and more reliable than manually maintaining dates.

    However, there are some kinds of tasks, such as your meetings, which will not form part of your critical path network. In the particular case you describe, it is appropriate to use recurring tasks which will all get SNET constraints, as shown in the indicators column, when you create them. Recurring tasks are in the task button on the task ribbon. Note that the task are all auto scheduled.

    Give it a shot. Let us know how you get on.

    Thursday, May 11, 2017 4:45 AM
  • Hi Andy,

    just in addition to Trevor's reply (using constraints for meetings is completely valid as he wrote):

    You could also use Manually Sceduled tasks for your meeting. See sample below: Meeting task is manually scheduled, included in dependency chain. If it should now be re-scheduled because of increased duration of T2, this meeting will not be moved. But the red line is indication, that there is a potential scheduling problem.

    You as a project manager has to decide, if you want to ignore or how to solve.

    Perhaps also an solution?

    Thursday, May 11, 2017 5:23 AM
  • Hi Andy,

    Using constrained or manually-scheduled tasks as suggested by Trevor and Barbara seem appropriate on a case-by-case basis as long as decisions or approvals taking place at these meetings are not logically connected to any other tasks.  Whether they are "best practice" in general might be subject to debate....

    There are real-life cases where key project decisions may only be confirmed/approved at scheduled gatherings (e.g. Monthly Steering Committee or Board-of-Directors meetings).  Failure to get a key action (like a major subcontract award) on the docket for such a meeting can turn a 1-day paperwork slippage into a 1-month project delay.  I've had success modeling such decision/approval activities using task calendars with very restricted work days (for the meetings) in a 100% logic-driven schedule.  The resulting dates are robust and reliable.

    As always, introducing task calendars may invalidate Total Slack as an indicator of the critical path.  (E.g. Task 28 on the chart is on the driving path to project completion and has delayed the project by 1 month, but Project still computes 20 days of Total Slack.)  Then alternate methods for critical path analysis are needed. 

    Thursday, May 11, 2017 3:46 PM
  • There are many valid comments already presented, but ultimately these are meetings that don't have any dependencies, and don't move once scheduled;  it seems like a perfect opportunity to use manually scheduled tasks with no dependencies.

    Ben Howard [MVP] | web | blog | book

    Thursday, May 11, 2017 6:10 PM