什么是项目的成功?

　　参加工作的时间不同，给出的答案也不同。工作一年左右的时候，答案可能会是“按用户的要求，按时交付使用。”工作三年左右时，答案会变成“基于给定的成本预算，按照需求规格，按时交付产品。”工作五年左右时，我们不禁深思到底什么算真正的成功呢?

　　Standish group(美国专门从事跟踪IT项目成功或失败的权威机构)给出了成功的、不太成功的、失败的经典定义：

　　>> 成功的(Successful)：“按时完成，费用不超出预算，而且所有特性和功能都符合原先的设计规格。”

　　>> 不太成功的(Challenged)：“已完成而且可以运行，但费用超出了预算，没有如期完成，拥有的特性和功能少于原先的设计规格。”

　　>> 失败的(Impaired)：“在开发周期的某个时刻项目被取消了。”

　　其实这个问题本没有标准答案，我认为成功应该是：找到客户和软件公司两者愿景的平衡点。即，通过变更管理客户需求的变化，达到分阶段交付用户使用，提高客户满意度的同时使软件公司能够得到相应的回报。

　　那么客户和软件公司的愿景都是什么?

　　>> 客户愿景：能够满足业务的不断变化，保质保量地按时交付使用。

　　>> 公司愿景：费用不超支，时间不延长，符合评审通过的设计要求，交付用户使用。

　　那么项目成功的平衡点又是什么?

　　通过下面的例子来分析用户业务变化对项目产生的影响。

　　结合这些年的项目经历，抽象出两个典型的项目类型，以下称“项目A”和“项目B”。它们在开始时的计划都是交付200项功能。

　　项目A按预先计划，在项目结束时一次性交付了最初计划的200项功能，但客户发现其中大约30项功能没有太大用处，而另外30项有用的功能要等到下一个项目才能实现。

　　项目B在进行过程中，客户进行了一次业务调整，软件公司通过变更管理纳入了90项新的功能，并搁置了50项用处不大的功能。按预定工期交付了第一个可用版本，此后每隔一段时间交付一个更新版本，最终交付了240项功能。

　　项目A，站在软件公司的立场上是成功的，按时间、按成本完成预先约定的任务;站在客户的立场上却有30项有用的功能要等到下一个项目才能实现，没能满足业务的变化需求。

　　项目B，站在软件公司的立场上虽然没能按预先计划完成200项功能，但却满足了用户第一阶段的使用，且通过变更管理满足用户的需求变化;站在客户的立场上满足了自己业务的变化，获得了自己需要的可用的软件产品。显然项目B找到了成功的平衡点，即：满足了客户的要求，软件公司也能接受。

　　我们经历的项目大多数像项目B，经历着业务变化。基于找到的项目成功的平衡点，软件公司可以通过变更管理流程实现项目的变更，不产生项目蔓延，使变更在受控状态下进行，即：1)用户通常向项目经理提出变更要求;2)项目经理分析变更对项目产生的影响，包括实现需求的技术手段和时间，对项目工期的影响;3)影响较大的，须报上级领导，并组织招开会议，集体讨论，得出理想的解决方案;4)编写需求方案;5)通过评审;6)组织人员进行研发;7)变更后的测试及发布;8)变更后的监控。变更目的是否达到，判断发生变更后的项目是否已纳入正常轨道。

　　基于找到的项目成功的平衡点，用户能够给出合理的分阶段的交付时间。这样，虽然延长了项目整体的交付时间，却保证了项目整体的稳定性，提高了项目质量，减小了项目风险。项目的成功就是找到“平衡点”，既是客户的成功，也是软件公司的成功。