绝大多数的OA需求都是发问卷给相关人采集汇总而得来的，以这样的形式采集汇总的需求造就了中国过去近20年几乎所有的OA都走项目化，或者看着别人的OA还凑合拿来就用。如果你也是这样整理需求的，那简直就是自杀，这种看上去合乎逻辑的需求成型方式里面却埋藏着失败的种子。
CIO通常是OA项目的负责人，中国的OA应用发展史可谓“成也CIO败也CIO”，在组织赋予CIO肩负起OA项目建设职责的同时，不少CIO却也还满怀激情地冲向陷阱。
陷阱一：缺乏长期规划
CIO一般有当前的项目规划，而无长期战略规划，为项目的早夭埋下了伏笔。
陷阱二：需求贪大求全
如果你坚信自己采集的需求是一种客观的需求，是必须被100%满足的需求，你就离失败不远了。那么，如何认识自己的需求?
让我们仔细看看这份需求吧!也许每个部门都提出了自己的需求，里面不仅是一个个以自我为中心的要求，而且充满着本来应该归纳到业务范畴的应用需求，甚至包含着个别领导的软件嗜好。依照这种需求，世上没有一套现成的软件能够100%地满足。依据这样的需求开发出来的OA软件，可能功能看上去非常丰富，但实际上却形成了一个个以部门为中心的应用孤岛。第一代的OA都是这么出生的，最后大家用起来一头雾水，这些看上去都是我们想要的功能为何总感觉那么别扭?问题到底出在哪?
我们研究发现，这类OA普遍存在一个问题：如果我们要以整个组织高效协同为目标，那么，那个把我们协同在一起的功能是哪个?
请不要轻率地回答这个问题，有人说用公文?公文只有组织中不到10%经常用;文档?文档可以分享，但文档不能主动产生协同;IM(即时通信)?IM并不能进行表单审批;邮件?邮件能完成流程化审批吗?能用邮件来完成组织的日常协同，我们还实施OA项目干什么?
所以你必须从繁杂浩瀚的细节中脱出身来，放下本位主义，先找到一个组织共性的需求，然后才是关键部门的需求，最后才是重要角色的需求。你在选型的时候一定要看，这个OA是否有这样的一个功能能够满足这个共性需求!
陷阱三：实施急功近利
如果你认为软件只要会编程就能做，那你可就大错特错了!写程序是邻居家的高中男孩就能干的事情。
软件是包含责任关系的商品，需要复杂的支撑体系。软件业已经发展到工程学的水平，拥有严格的环节分工和检验标准。从需求开始，有专业的人员进行需求的采集、提炼、评估，形成应用的“概念设计”;经过评审后，技术高手会充分考虑诸多因素后提出“构架设计”，评审后才会到开发部形成“应用设计”，评审后才会有“代码开发”，然后是“功能测试”，最后才能交给你。这期间，所有的环节都应该是最优秀的人力资源在保障质量，所以你千万不要指望找到一个非常廉价还百依百顺的供应商，根据你的指令快速而完美地帮你达成目标。
陷阱四：片面追求新技术
对新技术的片面性追求常常导致项目成为了项目负责人(特别是CIO)自娱自乐的畸形产物。探索的精神无可厚非，但是毕竟尝试性的技术探索对于组织应用所期望的稳定性、实用性而言是高风险和高成本的。
技术先进性的价值不在于先进本身，而在于先进对扩展性、性能、安全性、集成性、易用性(常被CIO所忽视，其实对终端客户的影响排在第一位)等诸多应用的现实价值和升级成本的抑制。而且由于协同管理软件的价值并不仅仅依赖软件本身，其部署过程和应用推进能力也对其价值发挥起到至关重要的作用。我们绝不能忽视这样的现象：同样的软件在不同的单位对价值有截然不同的评估，所谓花巨资上马的大型软件成为摆设的情况比比皆是。
我们相信CIO对于软件的评估侧重应用和技术是理性的，但我们也同时注意到，CIO对于推动组织建立新型工作行为模式的艰巨性和挑战性的重视程度不够，常在对未来技术应用发展趋势的无限可能性的冥思苦想中忽略了组织与协调成本，导致系统实施成为踏入泥潭的第一步。
陷阱五：实施缺乏导向
实施被不少CIO理解为软件开放、安装调试、培训、测试、上线这一类的事务，但我们认为这不是实施，至少实施的目标错了，不是结束一个软件的部署过程，而是在这个过程中达成管理提升的目的。如果前面所说的工作是必需的过程，那么达成管理目标才是实施的结果。遗憾的是，极少有CIO在实施计划中明确地提出管理提升目标，最高的层次也就是具体枝节需求的满足。最理想的结果也就是安装了一套对大家没有价值感受的软件!
大部分客户把OA当成了一个阶段性项目，而没有意识到，如果能充分重视OA，它将成为一个强大的战略实施的支撑平台。
