CIO通常是OA项目的负责人，中国的OA应用发展史可谓成也CIO败也CIO，在组织赋予CIO肩负起OA项目建设的职责的同时，不少CIO却充满激情地冲向陷阱。

　　陷阱一：缺乏长期规划

　　有些CIO一般有当前的项目规划，而无长期战略规划，为项目的早夭埋下了伏笔。详情参见第7问：如何进行实施阶段规划。

　　陷阱二：需求贪大求全

　　如果你坚信自己采集的需求是一种客观的需求，是必须被100%满足的需求，那么你就离失败不远了。

　　如何认识自己的需求?

　　99.99%的OA需求都是发白纸给所有人采集汇总而得来的，以这样形式采集汇总的需求造就了中国过去近20年几乎所有的OA都走项目化或者看着别人的OA还凑合拿来就用。如果你也是这样整理需求的，那简直就是自杀，这种看上去合乎逻辑的需求成型方式里面却埋藏着失败的种子。

　　把一叠白纸发给单位内各个部门的10天后，或许你收到了他们的书面反馈，那么来让我们仔细看看这份需求吧。

　　也许每个部门都提出了自己的需求，详细无比，里面不仅是一个个以自我为中心的要求，而且充满着本来应该归纳到业务范畴的应用需求，甚至包涵着个别领导的软件嗜好。这些本位主义需求从来没有考虑别人的应用感受，只想着用起软件来自己更轻松，把任何没有用计算机处理的事情都推给OA。依照这种需求，世上没有一套现成的软件能够100%满足，甚至同行用的不错的软件也无法对你做到这一点。面对这些需求中复杂的术语和深奥晦涩的部门业务概念，作为项目负责人的你未必能够逐一甄别。你千万不可以简单地装订成册提交供应商，让他就这样去写应对方案。依据这样的需求开发出来的OA软件，可能功能看上去非常丰富，但实际上形成了一个个以部门为中心的应用孤岛。第一代的OA都是这么出生的，最后大家用起来一头雾水，这些看上去都是我们想要的功能为何总感觉那么别扭?问题到底出在哪?

　　我们研究发现这类OA普遍存在一个问题：如果我们要以整个组织高效协同为目标，那么那个把我们协同在一起的功能是哪个?

　　请不要轻率地回答这个问题。你说用公文?别逗了，公文只有组织中不到10%的人经常用;文档?文档可以分享，不过文档不能主动产生协同;IM?IM好像不能进行表单审批吧;邮件?邮件能作流程化审批吗?邮件能使得整个组织共享吗?邮件用于要事的授权你既不知道过程也不知道结果你能放心吗?要用邮件来完成组织的日常协同我们还作OA项目干什么?

　　所以你必须这么去整理需求，从繁杂浩瀚的细节中脱出身来，本位主义一概放到后面，先找到一个组织共性的需求，然后才是关键部门的需求，最后才是重要角色的需求。这么说是不是太抽象了?没关系，你只要认识这个逻辑就行了。因为我们大约研究了中国数十家OA厂商，走访了数十家OA成功或失败的客户，仔细评估了超过200种常见OA的功能菜单，最后找到了那个共性的需求!我们发现它可能有成千上万种表现形式，但把其本质提炼出来就只有一个词最贴切地表达这个需求，那个词叫“协同”。这类需求的共性只有几个要素，包涵协同角色、协同诉求、协同流程规则、协同过程状态、协同资源需求、协同结果。无论你是什么行业，在什么样规模的组织，处于什么样的岗位级别，你日常的行为几乎80%可以归结为这个需求。

　　所以你在选型的时候一定要看，这个OA是否有这样的一个功能能够满足这个共性需求!另外你可能有其他各种需求，有你敬畏的上级提出的，有强势部门提出的，有不起眼的人提出的，其技术难度和实施难度可能有天壤之别，你必须衡量轻重缓急以及其需求是否满足对全局的成败影响。否则这些汇总的需求将使得你毫无把握项目主干进度的节奏的能力，双方有限的资源被分解为千疮百孔补丁工程，重蹈前人久拖不上的覆辙。

　　“∑汇总式”需求对OA项目建设的副作用在于缺乏共性需求的抽象提炼，主次不分，轻重不分，缓急不分，这必将导致前期实施目标点过多，局部各自兴奋，全局一盘散沙的局面，事实上你将成为需求平均主义泛滥的牺牲品，丧失把控实施进度的节奏的能力。

　　陷阱三：实现急功近利

　　如果你认为软件只要会编程就能作，那你可就大错特错了!隔壁邻居家的高中男孩就能干的事情是写程序，属于个人娱乐，和摄影爱好差不多。而软件是包含责任关系的商品，需要复杂的支撑体系。软件业已经发展到工程学的水平，拥有严格的环节分工和检验标准。从需求开始，有专业的人员进行需求的采集、提炼、评估，形成应用的“概念设计”;经过评审后，技术高手会充分考虑诸多因素后提出“构架设计”，评审后才会到开发部形成 “应用设计”，评审后才会有“代码开发”，然后是“功能测试”(诸如白盒测试、黑盒测试、性能测试、压力测试、环境测试、安装测试等)，然后才能交给你。这期间，所有的环节都应该是最优质的人力资源在保障质量，所以你千万不要指望找到一个非常廉价还百依百顺的供应商，根据你的指令快速而完美地帮你达成目标。

　　陷阱四：选择片面求新

　　对新技术的片面性追求常常导致项目成为了项目负责人(特别是CIO)自娱自乐的畸形产物，即使探索的精神无可厚非，但是毕竟尝试性的技术探索对于组织应用所期望的稳定性、实用性无疑是高风险和高成本的。不少项目负责人会认为“最新的技术”=“非常先进的技术”。这种认知是非常片面的。

　　在我们看来，所谓技术先进性的价值不在于先进本身，(许多CIO会认为，使用新发明的技术就是先进的标志，这实在是本末倒置了，全球银行业和证券业用的技术至少都落后于新技术好几年)而在于先进对扩展性、性能、安全性、集成性、易用性(常被CIO所忽视其实对终端客户的影响排在第一位)等诸多应用的现实价值和升级成本的抑制。而且由于协同管理软件的价值并不仅仅依赖软件本身，其布署过程和应用推进能力也对其价值发挥起到至关重要的作用。我们绝不能忽视这样的现象――同样的软件在不同的单位对价值有截然不同的评估，所谓花巨资上马的大型软件成为摆设的情况比比皆是。我们相信CIO对于软件的评估侧重应用和技术是理性的，但我们也同时注意到，CIO对于推动组织建立新型工作行为模式的艰巨性和挑战性的重视程度不够，常在对未来技术应用发展趋势的无限可能性的苦思冥想中忽略了组织与协调成本，导致系统实施成为踏入泥潭的第一步。只有对诸如布署的阶段性、短期用户学习、中期应用感受、长期需求发展、总体拥有成本等诸多方面与软件本身的综合形成的价值观和方法论是否适合特点的客户才是评估所谓先进性的标准。

　　陷阱五：实施缺乏导向

　　实施被不少CIO理解为软件开放、安装调试、培训、测试、上线这一类的事务，但我们认为这不是实施，至少实施的目标错了。实施不是结束一个软件的部署过程，而是在这个过程中达成管理提升的目的。如果是前面所说的工作是必需的过程，那么达成管理目标才是实施的结果。遗憾的是，极少才有CIO在实施计划中明确地提出管理提升目标，最高的层次也就是具体枝节需求的满足。最理想的结果也就是安装了一套对大家没有价值感受的软件!