软件开发队伍改变他们的需求过程时，与其他项目风险承担者沟通的接口也会发生变化。外部组织功能，这些功能是通过一定的接口与软件开发队伍联系的，这些接口对项目需求活动起着重要作用。

为能顺利进行这些接口操作，要与其他领域的合作者多交流，让他们知道你的改进想法和调整计划。要向他们说明改进后的新过程会带来什么好处。如在改进过程中需要获得合作时，可以从这样的谈话开始：“这些是我们曾经经历过的问题，而我们认为进行这些变更将会有助于问题的解决。这就是为什么我们要这样做的原因，我们需要得到你们的帮助。而我们的这些工作也会给你们帮助的”。反对变更是由于害怕变更带来的影响，因此要指明你进行的过程变更所可能带来的影响，从而减少大家的恐惧感。

向各个功能领域的人说明你从他们那里所需要获取的信息和帮助，从而有助于成功开发整个产品。在开发过程中要遵从开发组与其他功能领域之间重要交流接口的规范和内容，如系统需求规格说明文档或市场需求文档。通常重要项目的文档从写作者角度是严格规范的，但往往不能给客户提供他们所真正需要的全部信息。

询问其他组织需要从开发队伍中获取什么以有助于他们的工作。技术可行性方面哪些能帮助市场部更好地完成产品计划？什么样的需求状态报告能使管理者更充分地看清楚项目的进展情况？与系统工程部之间怎样合作才能确保系统需求在软、硬件间的分配合理？努力在开发组和其他需求过程风险承担者之间建立合作关系以便所有人都能更有效地促进项目成功。

人们都不喜欢被迫离开他们已经习惯的环境，因此，你可能会在需求过程变更中面临抵制与反对。要做好思想准备尽量理解这些反对的缘由，以便你既能尊重他又能化解他。许多反对是由于不了解情况而引起的恐惧所造成的，因此一开始就要给他们说清楚为什么要作这些变更，变更后他们将受到怎样的影响，将会带来什么好处以及为什么你在过程改进一开始就需要他们的参与等等。下面是一些你可能遇到抵制的情况：

1)需求变更控制过程可能被看成变更是很难进行的一个障碍而被丢弃。而实际上，它提供了结构化和有条理的变更过程，并使得知道的人能作出更好的业务决定。你的任务是要确保变更过程真正能起作用。如果新的过程不能带来更好的结果，那大家将会“绕道而行”了。

2) 一些开发人员把编写和审查需求文档看作是浪费时间的官僚做法，妨碍他们的“真正工作”—编写代码。如果你能向他们讲清一旦发生重写代码所带来的惨重代价，开发人员和管理人员将更能明白为什么需要做好需求工作。

3) 如果客户支持的费用没有和开发过程联系起来，开发小组可能会缺少变更的动力，因为他们并不会因最终产品的低质量而带来损失。

4) 如果改进后的需求过程的目标是通过创建高质量产品以减少技术支持费用，那么提供技术支持的管理者可能会感到受到威胁。谁希望看到自己的帝国衰败呢？