没有继承人的活动（除项目填写除外）被称为悬垂活动。这些开放的活动在项目中排放到困难的项目中，使其进展困难。然而，在时间表中捆绑悬垂活动的方式有止多种方式。
关系定义了活动之间的顺序和交互。最常见的是结束到开始(FS)关系，在这种关系中，后继程序在前一个程序完成之前不能开始。一个典型的FS应用是“浇筑基础”和“安装墙”之间的关系。FS关系连接了前辈的“浇筑基础”和后辈的“安装墙”。这种关系不仅告诉了我们活动的顺序，而且也规定了“浇筑基础”必须在后续的“安装墙”开始之前完成。
有时活动没有明显的逻辑继任者。你在这些情况下做什么？你留下了没有继承者的悬挂活动吗？答案是没有你的。考虑而不是替代方案。
本文解释了在附表中处理悬空活动的替代方法。本文呈现的计划是在Oracle的Primavera P6专业中生成的。
捆绑那些摇晃的活动
我们在图1中有我们的示范项目。
图1
注意，特别是“安装围栏”活动。此活动没有明确的继任者。它留下了自己的悬挂，没有什么可以在时间表中重新连接。还要注意其总浮动的31天;安装围栏有些可能考虑高浮动活动。因为“安装围栏”没有继承人，所以其总浮动从计划的完成日期到项目结束时衡量。
这意味着在我们的示例中，安装围栏可以延迟31天，而不会影响项目的结束日期。特别是在博客中讨论了高浮法活动必威体育网页全网独家DCMA 14点评估和高浮动任务。
虽然国防合同管理机构（DCMA）指引上述环节表示，高浮法活动总浮动股票大于44天，许多人将考虑31天的总浮法，以成为高浮法情况。好吧，不仅是'安装围栏'高浮子，还是再次，它也是一个松散的最终活动。
为什么这可能是一个问题？悬空的“安装围栏”活动不提供早期警告，即其缺乏进展成为一个问题。在花费总共31天的所有31天，您不会知道存在问题，并且它开始推动项目的结束日期。
当发生这种情况时，为时已晚。您将在手上有一个项目火灾，并且您必须争夺完成“安装围栏”以最大限度地减少它导致的任何进一步的项目延迟。但这个项目火灾和延迟完全是不必要的。你有三十一天，你放手才通过安装围栏进行任何进展。鉴于此，我们如何将围栏安装回到计划中以防止投影？
首先，调度指南，特别是DCMA将考虑安装围栏的缺乏继任者“缺失逻辑”。请参阅博客必威体育网页全网独家14点评估和日程安排缺失逻辑'检查讨论“缺少逻辑”。
因此，安装围栏需要一个继任者，以坚持接受的日程安排指导方针。为了达到指导方针的要求，调度人员的第一反应通常是将任何悬空的活动与“项目完成”里程碑(项目的结束)联系起来。这满足了“缺少逻辑”的指导方针，但仍然没有提供早期警告，您的安装围栏的延迟会威胁到项目的完成日期。
您真的希望分包商比项目的关闭更快地完成“安装围栏”任务。那么，那么为什么不在安装围栏上或之前的限制（FOOB）约束时饰面？约束是一种对任务日期额外限制的一种方式，以强调项目生命中该日期的重要性。在图2中，我们在“安装围栏”上放置FOOB约束。
图2.
请注意，当我们应用此约束安装围栏时，总浮动减少到2天，图3。
图3.
太棒了!因此，安装围栏计划完成比项目结束日期早得多。这就是我们想要的。但是使用约束也有缺点。
在时间表中应该有节制地使用约束。原因之一是它们不会自动更新正在进行的更改。所以一个有很多限制的时间表需要更多的繁琐的注意力。约束还应该附带说明其目的。
一个以前的学生想对他的转包商隐瞒总金额，因为他们往往把工作推迟到最后可能的时刻。约束可以隐藏总浮点数，但这不是一个诚实的调度实践。约束不应该被用来简单地隐藏总浮动对你的分包商。还有更好的解决方案吗?
最好仔细考虑一下你的日程安排情况，并试着找到一个合乎逻辑的常识来接替你的任务。在我们的时间表中，将“安装栅栏”与“实质性完成”任务绑定是有意义的。围栏的安装是项目接近完成的一个标志。在图4中，我们按照FS关系将“安装围栏”与“实质性完成”连接起来。
图4.
这适用于消除“缺少逻辑”并避免约束。但我们的总浮动（21天）仍然有许多人认为高浮动情况。此外，为了讨论讨论的目的，可以做些什么来减少我们的21天浮动活动？
让我们进一步检查一下情况。考虑安装栅栏的活动。围栏的用途是什么?栅栏为工地提供了安全保障。我们什么时候需要在工作现场提供保安?在任何高压危险设备到达之前。根据围栏的安全功能，安装围栏的逻辑后继程序将是“安装母线和跳线”，这是危险的电气元件。在图5中，我们将“安装总线和跳线”作为安装栅栏的后续步骤，总浮动压缩时间为13天，这更加合理。
图5.
总结
调度指南将标记任何悬空的活动，即任何任务（“项目关闭”），没有继承人，因为“缺少逻辑”。对此“缺少逻辑”指南的最小严格遵守通常导致将松散的最终活动连接到“项目关闭”里程碑。这符合“缺少逻辑”指南，但仍然失败了高浮法指南。
调度程序可以求助于外部约束来减少总浮点数。这可以很好地减少总浮点数，但可能不够诚实。全面披露是质量计划的一个特点。更好的解决方案是考虑可能的接班人。通过这种方式，您将减少总浮点数，提供逻辑后继程序，并维护动态和响应性调度。因此，考虑有问题的可交付产品的目的或功能可能有助于找到合乎逻辑的后续产品，并将总浮动保持在最低水平。