“选对了行业，在技术发展方向上是走对了”， 不仅通过这个项目有了“灯塔客户”，并很快带来了新的订单。
2) 利用项目本身，完成一个“产品”(我认为更贴切的说法可能是基础版、或者是基础平台)。如果没有这个项目，就需要额外的开发投入，以及去找第一个客户的市场销售费用，因此，这个项目本身已经节省了大量的投资。
3) 积累了宝贵的经验，特别是业务经验。如果将实施的过程进行整理，形成一套可以重复的过程——“实施方法论”，文中的天华合信就可以成为这个细分领域的专家了!
因此，项目的成败，往往要看你从哪个角度去评价，这样通过一个项目就同时获得“灯塔”、“产品”、“实施方法论”，能说是不成功的吗?如果说到项目本身可能的改善之处，有几点建议仅供朋友们参考：
一、项目管理中，应该注意多方协调。从文中推测，项目中还有其他的协作方(无线网络实施)，并且由于这部分的滞后造成了项目延期。复杂项目的特征之一，就是至少有两个以上的参与方，在这种情况下，一般都需要有多方参加的PMO协同指挥，否则就容易造成相互制约和效率低下等问题。案例中，如果时间协调得好，可以在资源调配上节约很多成本。另外，如果是外地实施，也可以考虑采用适当比例的人员外包，以降低实施成本。
二、作为一个建议，应该将实施过程进行梳理，形成方法论，固化实施过程。这样，不仅对新客户的主导性会大大增强，而且今后还可以不断优化。对项目中的风险和问题也可以总结成“最佳实践”，因为，这个项目中所有遇到的困难，将来都可能遇到，如果“你”能自信地说出可能遇到什么困难、应该怎么解决，也会大大增加新客户的信心。
三、在项目之初，企业如果有个明确的业务模式定位，也许可以减少变更引起的工作量。一般来说，按实现客户需求方式划分，应用软件大体分成三类：“产品”，“产品+服务”，“定制”。纯“产品”要求装上就能用(或者只需要比较简单的配置)，不需要大规模实施。但是，因为客户的业务规则往往差异很大，甚至本身都不明确(如文中所述);因此，应用软件如能做到这个层面，那的确是非常出色了。“产品+服务”模式，一般是已经有一个基础版本(或基础平台)，并且有一套实施方法论，能按一定的步骤完成客户化，有效控制成本。“定制”方式完全按照客户的要求设计开发，对复用考虑的比较少(一般复用的机会不大);为了控制风险，往往采用“T&M”方式计价。
由于“产品+服务”方式可以大量的复用构件，降低交付风险，应用软件多用这样的方式。这种模式在“产品”的设计过程中就需要进行分层和抽取，例如，哪些是核心模块(“Core”，基本不用改动)?哪些是通用模块(Common Function)，可以组合调用完成业务功能? 哪些做成快速开发工具，灵活满足客户个性化需求。
在这个案例中，3个月已经形成了基础版本，如果在后续一年的等待中完成了这样的产品化过程，可能为以后的实施带来更大的价值。
总而言之，如果后续能够很好地完成“产品化”、“交付方法论”的整理，并注意实施中的多方协调，换个角度看项目之后应该是苦尽甘来了，相信后续项目一定会非常成功!