Redmine

I support this submission.

As mentioned in the Reference, the PMBOK (Project Management Body of Knowledge) introduces the following four dependencies that exist between the two activities

1. SS (Start to Start)
2. SF (Start to Finish)
3. FS (Finish to Start)
4. FF (Finish to Finish)

In this post, as in the previous one, we propose to support two new dependencies, SS and SF, in addition to the FS and FF that Redmine already supports.

In addition, we propose to define separate specifications for FS and FF, which are currently supported, from the current Follows/Precedes and Blocks/Blocked specifications, to unify the level of support among the above four, and to ensure that these four dependency specifications will be managed in a unified manner as a group.

These four dependencies and their current support status in Redmine are listed in the table below

(*1) "Start and end dates are constrained" means that the start and end dates of their respective dependencies. (Example) In the FS dependency, the start date of the subsequent activity is the day after the end date of the preceding activity.

(*2) "Status constrained" means that the statuses of the preceding and following activities are constrained to be consistent with their dependencies. (Example) In FF dependency, the status of a subsequent activity cannot become terminated unless the status of the preceding activity becomes terminated.

As you can see from the table, the current Redmine only partially supports constraints related to start and end dates and status in both FS (Follows/ Precedes) and FF (Blocks/Blocked). Here, we propose that the newly implemented FS and FF support the above two constraints simultaneously.

The four dependencies proposed here are supported by Oracle Primavera P6 and Microsoft Project, the de facto standard for project management systems in the construction and engineering industries. By supporting these functionalities in Redmine as well, it will be able to gain traction as an open-source product in a broader industry segment.

The following is an explanation of why it is desirable for the plant engineering industry to support a broader range of dependency concepts than is currently available. This is not a specific request from a particular organization, but describes a need in the same industry, and in similar industries.

In plant engineering operations, design, procurement, construction, and commissioning operations often proceed in parallel, and in such cases, SS and FF dependencies are required because FS alone cannot express the dependencies between each activity.

Specifically, the creation of the overall plant plan and 3D model requires design information on individual equipment and units from the manufacturer, but waiting for the "Design by Manufacturer" activity to be completed before creating the plan and 3D model does not mean waiting for the "Design by Manufacturer" activity to be completed before creating the plan and 3D model. However, it is not necessary to wait until the "Design by Manufacturer" activity is completed before starting to create the floor plans and 3D Models. Some activities that do not require design information from the manufacturer in order to create a complete plant plan or 3D model can be started immediately after the "Design by Manufacturer" activity is initiated. In such cases, expressing the relationship between these activities in terms of FS dependencies would extend the overall project schedule beyond what is necessary. This is why SS and FF dependencies are necessary.

The project schedule resulting from expressing the dependencies of the activities described above using only FS would be unrealistic and would make it difficult for the client to accept the project. Even if work has actually started, if FS dependencies are used as a substitute for SS dependencies, the status of subsequent activities cannot be set to "started" due to this limitation, and correct progress cannot be captured, resulting in problems with progress management and volume control. The above situation is illustrated in the figure below.