Microsoft Project does not allow users to create multiple logical relationships between the same two tasks. Project DOES ALLOW importing of such multiple relationships in XML files, however. If desired, users can directly edit XML versions of project schedules to introduce multiple logical relationships, and these relationships appear to be persistent and active in all subsequent schedule calculations.
Microsoft Project and Oracle’s Primavera P6 are the two dominant tools for complex project scheduling in North America, and I’ve been a regular user of both tools and their predecessors since the early 1990s. Aside from major issues related to data architecture, one of the key remaining differentiators from a user’s point of view is Project’s limit of one logical relationship between any two pairs of activities.
This limit can be a deal-breaker for longtime users of other tools who are dependent on scheduling workflows using “ladder logic”, or concurrent SS/FF relationships with lag. This kind of logic is used to represent sequentially-related activities whose overall characteristics allow them to proceed mostly in parallel. In construction, a simple example might include digging 1,000 meters of trench, laying 1,000 meters of pipe in the trench, and covering the trench. The most timely and profitable approach to the work is to execute the three tasks in parallel while providing adequate work space between the three crews whose production rates are well matched. Using ladder logic, it is possible to model the work using three relatively long duration activities with concurrent SS and FF relationships. Appropriate time lags are assigned to the relationships to represent the necessary space (or work volume) offsets between the activities. A similar approach can be used to schedule shorter-duration activities performed by successive crews at the same location, where availability of ready work front for the follow-on crew is the the primary constraint. [See also: Overlapping Tasks in Project Schedules.]
In my own experience, I’ve found ladder logic useful for effectively modeling the field approach while avoiding unnecessary detail in the schedule. Implementing ladder logic in Microsoft Project (MSP) requires the use of dummy milestones, complicating the logic and adding needless detail. I would prefer to avoid this workaround. Recently I learned that the one-relationship limit may not be irrevocable, and combined SS/FF links may be used to implement pure ladder logic in MSP (with some outside help.)
Figure 1 illustrates a simple fragnet (in P6) comprising three activities that are linked together with ladder logic. (This is just a test schedule; the implied work relationships are meaningless.)
Figure 2 illustrates the same fragnet (this time in MSP Pro 2010). Dummy milestones have been added to carry the logic through the Start-to-Start side of the ladder, so five activities are needed to schedule the same work that requires only three in P6.
Figure 3 demonstrates a fully-functioning MSP fragnet that incorporates dual SS/FF relationships without the aid of dummy milestones. The relationships appear to be fully functioning in the forward-pass and backward-pass calculations, and they are fully editable.* (Like all relationships in MSP, changing the predecessor or successor task requires deletion and re-initiation of the relationship, i.e. not an edit.) It appears, therefore, that multiple relationships between a single pair of tasks does not automatically break the schedule calculations in MSP Pro 2010. Unfortunately, the only way I’ve found to add these relationships is by directly inserting them into an xml version of the schedule file, then opening the file with MSP. (Similarly, P6 schedules that are transferred to MSP through the xml interface can manage to keep their redundant links.) Once opened, MSP appears indifferent to the presence of these externally-inserted dual relationships, but it continues to prohibit introduction of new ones, whether through the standard user interface or through direct manipulation of the underlying data in the open project.
*Interestingly, the only way to successfully edit the dual relationships is using the predecessors or successors list in one of the “task form” lower-pane views as shown here. Attempting to edit using the Predecessors tab of the Task Information dialog window or using the predecessors or successors column in a task table fails — with MSP deleting rather than editing the relationship.
Overall, I’m encouraged that Project’s longstanding limitation of one relationship per pair of tasks is not – apparently – an inevitable and unavoidable consequence of the program design. Nevertheless, inserting redundant relationships through xml editing hardly seems workable in general, and I doubt that I’ll be using this technique much going forward.