To eliminate all schedule margin or Terminal Float is not a good idea.  It is basic Project Risk theory that the more margin the more you increase the probabilities of success.  Still some "old school" specifiers require all Baseline Float to be used.

Anyway, padding activity duration mask true intent, it lacks transparency.

Better European specifications such as NEC require you provide some margin and if not it might be a reason for rejection.  You shall include allowance for rain as well as some schedule margin.  How much schedule margin can be rationalized if using project risk methodologies.

http://www.stevencevans.com/float/

• That critical path can be anything is quite ambiguous. 
• It looks like Hammer's Rule at it best, "if it does not fit then hit it with a hammer until it does".
• No matter what ambiguous rule you want to follow the use of mandatory constraints will override any calculation.
• Please be reminded that P6 calculation of "Longest Path" breaks under resource leveling as well under any other type of constraints.
  • http://docs.oracle.com/cd/E17462_01/Web_Access/Help/en/Projects/Tasks/pm...
  • The longest path is broken when activities are no longer driven by relationships; that is, when activity dates are driven by constraints or resource leveling. Longest path calculation includes interproject relationships. Therefore, activities designated as on the longest path may change depending on whether you schedule a project alone or with its related projects. If a project has interproject relationships and you schedule it alone, the interproject relationships are treated as scheduling constraints.

In their desire to see a flag fixed in time for a contractual milestone some schedulers use the mandatory constraint, not a recommended practice. Make sure you are not using a mandatory constraint, instead use a FNL type constraint.

http://warnercon.com/wp-content/uploads/2012/07/Article-7-Use-of-Milestones-and-Constraints1.pdf

• Finish-No-Later-Than (FNL) This is more commonly used, especially for projects with multiple, phased occupancy dates. Activity strings are highlighted as critical if they are driving a constrained item past it’s assigned ‘no-later-than’ date.
• A mandatory constraint will override the logic of the schedule when performing a schedule update for the sake of holding the date in place. A normal constraint date can be overridden by a schedule update but a mandatory constraint date cannot. Mandatory constraint dates are not considered a best practices in schedule updating for this reason. Similarly, if used in schedule leveling, the sequences might become altered in order to hold the constraint dates firm. With mandatory constraints an activity would be frozen from moving beyond the date constrained, thus potentially not reflecting reality. The mandatory constraint date does not show the effect of late or early completing activities. A normal constraint date would show negative float (behind schedule) if it was late to complete when its predecessor and successor activities had completed, whereas, a mandatory constraint would instead freeze the associated activities from being completed. Effective use of mandatory constraints requires recognition of the implications of its use. Some schedulers try to show that the schedule can finish on time by constraining the end date and then leveling the schedule. This is not recommended unless trying to create a recovery schedule and the resulting activity durations and logic are carefully reviewed.

Same as client I am not an advocate of using activities to represent buffer, we compare current schedule start and finish dates to a target late-schedule and calculate start and finish buffer for every activity.
 

Hi Tom Tom,

In your case, you still have a critical/longest path, but it consists of the Project Finish Milestone alone.  "Finish on" (FO) essentially combines an early finish (FOA) with a late finish (FOB) constraint.  As long as an FOA is more stringent than the predecessor logic, it effectively breaks the driving path to/through the constrained milestone (i.e. the longest path).  This is always the case. 

Your client's requirements may be aimed at prohibiting an early-completion baseline schedule, and in my view such requiremements are only appropriate if you (i.e. your company) have explicitly agreed that early completion is not planned.  In that case you can meet the requirement by inserting a 30-day "Contractor's schedule buffer" activity between the project finish milestone and its predecessors.  The result is a critica/longest path extending from the data date to the completion milestone.  At each update period you would need to adjust the duration of this buffer activity to ensure that a) the milestone's early finish remains driven by the buffer rather than by the constraint (thereby preserving the longest path), and b) you do not waive any rights to EOT in case of excusable delay.  This is a cludgy and time consuming - maybe the client can limit the requirement to the baseline schedule only, allowing you to remove the buffer and convert to FOB constraint for the monthly updates.

Good luck, tom