Home › Forums › Discussion › Using both Project 202013 sub-projects in a master shell › Reply To: Using both Project 202013 sub-projects in a master shell
Jigs’ comment, “2010 was not a good year,” made me laugh. From my perspective it was pretty solid, and in many respects 2013 and 2016 appeared to be a step down. I’ve only recently “upgraded” to 2016 (even 64-bit) on the newest machine. When moving files back and forth between versions, there are two main areas of concern:
1. Active/Inactive. As already mentioned, inactive tasks are handled differently in the different versions. (Also Standard releases don’t allow modifying or manipulating the active flag, but the calculations are the same as Pro.) In 2010, an inactivated task is effectively removed from the schedule calculations, with otherwise unrestrained predecessors and successors being scheduled as open ends. I prefer that behavior, but most users don’t. When first introduced, Project 2013 inserted hidden FS links between the predecessors and successors of inactivated tasks, leading to behavior that most users seemed to like. If the inactivated task had overlapping predecessors or successors, however (e.g. SS or FF with a lag), then the new FS link could actually introduce a project delay. This may or may not have been fixed with a later update. Project 2016 seems to effectively compute the logic flow through most overlapping (inactive) tasks, though there still seem to be issues with mixed calendars and lags. I’ve not seen the late finish being pulled to the beginning of the project (with the resulting BIG negative slack) as described by Oliver; maybe it happens with reverse scheduling (which I never use).
2. Resource Leveling. The default leveling rules seem to have been tweaked from 2010 to 2013 (and preserved from 2013 to 2016). In the absence of explicit priorities, the later versions seem to result in longer schedules.