首先，我们要理解什么是“控制”。“控制”是一种提前预防的纠偏行为，比如汽车拉力赛的副驾驶就是一位控制者，他时刻拿着地图引导在远离岔路几公里时，提供道路决策。控制有一个关键特性：
a. 提前性，必须提前识别被控制事务可能发生的形态，并提前做出预判；
b. 基于a，意味着控制必须提前做出判断设置，比如对错或优劣；
c. 控制是对‘事’的控制，而不是对‘人’的控制，副驾驶不是试图去代替驾驶员，而是去帮助驾驶员理解前进方向；
这意味着要对“需求和计划的变更”进行控制，我们需要做到如下几点：
i. 提前识别需求和计划可能变更的原因；
ii. 提前识别需求和计划可能变更的发生时间；
iii. 与团队达成共识；
iv. 判断衡量依据；
v. 利用确定的衡量方法，时刻监控变更；
vi. 一旦监控出现异常信息，提前预报给重要的团队成员，采取措施。
说非常容易，做极其困难。
首 先，在6个步骤中，ⅰ、ⅱ两件事情是长期性的，超出了某个具体项目的生命周期范畴。就a来说，IT行业可能发生需求变更和计划变更的原因实在是过多了（这 也是为什么有限的篇幅无法说明白的主要原因），我们需要长期分析与跟踪这些因素，了解这些因素之间的互相关系，并且至少做到心里有数。通常我们会将最终的 因素分类成如下几种：
1. 必然发生，而且变化的内容对于客户（或任何甲方）来说是必须的和重要的；
2. 必然发生，但变化的内容是值得商榷的；
3. 可能会发生，取决于我们的引导和判断；
4. 可能会发生，但是我们控制不了。
对 于1类变更，我们的控制手段应该是留下容量（无论是时间还是人员），因为它是必然的；对于2，就算是在某个特定的项目中无法避免，我们会问自己有没有可能 在项目后有机会与所有利益相关人达成共识，下次避免；对于3，提升团队关键人物的能力，尤其是说服引导的能力很重要；对于4，我们要问，是不是冒点风险， 不去控制是值得的，因为第四类的控制成本可能高过了发生变更的应对成本。
同时，我们必须明白，变更与变更之间是有相互关系的，哪些变更是主要变更，其他只是由其引起的变更。管理者面对变更控制时，必须抓大放小，直击主题。
但是，我们也要意识到，许多的变更如果不事先进行预判，到了那个节骨眼上是没有任何办法的，这也就是为什么上述ⅰ和ⅱ的工作是长期性的工作，因为你必须在事后进行反思、总结和思考下一次的对策，并且要和整个团队分享。
短暂的篇幅内，也只能先说那么多了，希望对你有所帮助，但有一点是可以肯定的，如果确实希望解决某一类特定的变更，我们就必须要全面了解他的发生原因、背景、可能的影响，才能提供合理的建议和决策依据。