案例
　　SNET是一家提供软交换设备的供应商。他与国内一家运营商ACA达成协议，准备在浙江某地试验应用新型的软交换设备。ACA是国内第一家准备采用软交换设备的运营商，因此在与SNET的协议中，ACA提出，设备的不少功能处于开发之中，他们的需求还没有完全明确，并且将随着应用的增加才能不断提出。SNET答应了运营商的条件，因为他们认为只有通过这种方式，才能最终赢得后续的合同。

　　从2001年3月开始，各方人马陆续进驻，项目开始进行。ACA在浙江不直接运作项目，而是通过当地的一家运营商，它是广电的下属企业，他们之间是合作的关系，共同提供网络资源。根据协议规定，由SNET提供设备，验收合格后，ACA再付款给SNET。

　　4月底，设备安装完毕，可以开始试运行，效果还不错。运营商马上提出，要增加若干项功能。SNET答应了，继续做这个项目。

　　5月底，新试验完成后准备测试。这时，运营商又提出了一些新要求。SNET自然是继续配合。到6月底，试验终于完成，开始进行测试。很快，测试系统通过验收。运营商暂时没有更多新的要求提出。SNET与ACA就付款和系统的交接进行具体协商。

　　然而，此时SNET的最新版本设备完成了系统测试，并可以提供更多的增值功能。SNET向ACA提出建议，希望其采购最新版本的设备。运营商也倾向于采用最新的设备，但同时要求进行全面的测试。因此，付款的事情暂时搁置。 　　SNET对这个项目很有信心，相信一定能够赢得更多的订单（因为新的设备容量大，价格高，利润更大）。正当系统进行测试时，几家竞争对手也向ACA提出了新设备的测试建议，ACA有了更大的选择余地。最后，ACA决定再增加另外两家新的供应商进行测试。随着测试的进行，ACA发现几种设备各有特色，功能不尽相同，而且无法兼容在一起。经过电信专家组的论证，认为采用现有技术还不成熟，会增加系统的风险，建议ACA暂缓采用这种新的技术。

　　9月底，就在SNET和新加入的竞争伙伴正在做测试的时候，ACA总部发了一个文件，要求暂停试验，项目中止。SNET没有拿到任何付款。

　　在这个项目中，SNET损失惨重，白白投入了大量资金和时间却没拿到任何付款。造成这一结果的最直接、主要的原因是他与运营商之间没有任何强制性的合同约束；其次是需求不明确，运营商的需求是逐步提出的。

　　在这里，运营商的需求不明确是一个先天的不足。但SNET出于竞争的需要，答应了运营商的这些不确定要求，甚至是过分的要求。并且，它不断被卷入了测试的漩涡之中，甚至自己提出做新的测试。这就是人们常说的“镀金计划”的陷阱。

　　“镀金计划”是指为了满足客户的额外需求，超出了原先预想的合同的范围，或者出于某种目的（通常是为了竞争的需要，有时是为了取悦某些客户）添加一些额外的功能。

　　通常，在此类合同中会有一个标准的RFP应答和建议书。在本案例中没有，但初次测试验收可以看作是类似的文档。但是在项目进行过程中，运营商不断地提出新要求，这样就造成需求超出了RFP的范围，使得原有计划变成了不断变化的东西。此类要求对于设备商是不合理的条约。但由于竞争的缘故，客户的很多过分的要求没有被拒绝，甚至有可能被放大。从成本核算和项目管理的角度来说，这种项目的风险很大，通常会形成管理风险---即项目经理无法承担的风险。

　　对于设备商来说，“镀金计划” 通常是一个不被重视的问题。在与客户的谈判中，设备商有时候难免会送上一些“金点子”，但要是真打算落实到纸面上，最好要三思而后行，以免出现更大的风险。

　　在本案例中，SNET却逆常理而行，最后还自己提出新的测试。类似这样的事情，前些年并不少见。那时，有些公司并不靠经营收入，而是靠所谓的无形资产来吸引投资。但是，对于成熟企业来说，必须要对“镀金计划”这种行为加以限制。
　　“镀金计划”的风险
　　通常，在项目实施过程中，人们会经常会听到像这样的对话，“前天我做了一个项目，我觉得可以用很少的额外时间做一个很好的小功能送给他，这样会吸引客户不断采购我们的东西。”

　　实际上，在一般情况下，建议在项目中最好不要这样做。事实上，在工程项目管理中，对限制“镀金”有很强的理论论述。而在软件项目管理和IT行业，这种观念还没有明确。

　　为什么尽量避免这种做法？暂且不说实现一项功能具体到商业环境中就是需要资金的，也就是额外的成本开销。即便是假设把成本忽略不计，那种做法同样是没有可取之处的。

　　可以用一个简单的图表来说明这个问题：

　　可以看到，“镀金”基本上没有带来什么好处，项目经理对此应有明确的理解。

　　在工程项目中，如果打算临时增加一个新的功能，那么价格可能是事先计划的几倍。并且，增加一个新功能，就可能会增加相关的工作量。或许增加一个小功能对项目实施人员来说很容易。但即便如此，大多数工程项目经理也会对此非常谨慎。如果一定要做，通常会采用补充合同来规范。这是因为功能的增加通常会改变项目的范围。熟悉项目管理知识体系的人都知道，范围变化的影响是非常大的。

　　在IT项目中，每增加一个计划外的新功能，测试人员可能要花很长的时间去测试整个系统的可用性。同时，每个模块的开发人员可能要花很长的时间去理解新的功能对原有功能带来的影响。这些影响都是未知的，也就是项目管理所说的一个“未知的未知（Unknown unknown）”风险。这和“已知的未知(known unknown)”风险是有区别的。“已知的未知(known unknown)”是指当已经知道在什么地方可能会出现风险后，就可以制定计划来避免。但“镀金计划”产生的就是“未知的未知”风险。而且这种不可预知的风险使得项目人员根本没有做任何准备，因而可能会导致非常严重的问题，要尽量避免。
　　如何避免出现“镀金”
　　对于项目实施人员来说，如何避免项目发生“镀金”情况，最好应从以下几方面进行约束：

　　1.明确的目标，明确的设计，明确的需求。项目的目标是什么，这是项目经理和项目管理者要时刻牢记的。本案例的情况相对复杂。项目开始时确实没有明确的设计和需求，但对SNET来说，占领ACA的部分市场是项目的首要目标。但在案例中，可以看到，项目的结果是没有达到预期的目标。

　　2.处理好来自外部的“镀金”倾向。通常情况下，来自外部的，也就是来自客户的需求，可以看作是一种技术进步的原始动力，满足这种需求是竞争的需要。但项目经理和管理者应当理性地处理项目本身和新需求的辩证关系，增加版本管理是处理外部需求的首选方式。例如，当客户提出一些新要求后，项目经理可以向他表达感谢。经过认真研究后，合理的部分可以放到下一个版本的系统中。项目经理可以通知客户，他的新需求将被下一个版本的系统支持，这一需求可能会被要求支付费用（即使是免费提供，也会减少项目的风险，至少不会影响当前正在进行的项目）。

　　3.处理好来自内部的“镀金”倾向。其实，理论上说的“镀金”基本上是指来自内部项目成员的额外工作。建议最好采用强制的办法约束项目组成员的这种倾向。第一，让每个项目成员明白这样做的风险。第二，新的需求和设计可以在项目会议上提出，并用会议记录的方式肯定项目成员的积极性，作为收尾文档的一部分。第三，完善配置管理，每个阶段测试后，严格管理任何功能上的修改和变化。

　　4.及时向上级管理团队报告。如果来自外部、内部的需求造成项目运作的困难，项目经理应及时向上级管理团队报告，由上级管理团队决定是否增加和修改系统功能。