OA需求现状
目前，大多数企业采用收集归纳法进行需求定义：把空的需求表单发给各部门，一段时间后收集上来，对各部门的问题进行汇总归纳，形成总体的需求概况；继而参考从各个OA厂商产品宣传中收集到的信息，整理出一个大而全、缺乏整体性考虑的需求作为招标文件，让各个OA厂家去做方案。
这样的做法貌似解决了所有部门的问题，应该大家可以协同办公、非常融洽了吧？非也！实践证明，如此进行需求定义的OA系统，最终实施时都面临众多的、这样那样的问题。
作为项目负责人，您不禁要问：如此周全而面面俱到的需求定义究竟有何问题？
问题关键在于：所谓面面俱到实际上是面面都不到，这种眉毛胡子一把抓的方式必然导致失败！需求定义要从最迫切需要解决的问题入手，倘若覆盖面广泛但每个问题都点到即止又怎么能够深入的解决问题？
首先，您搜集上来的各部门需求，大多是站在自己部门的立场上考虑，常常带有很深的专业色彩，将业务应用需求与协同办公需求混为一谈，总希望一个软件能帮助完成所有的工作事项。依照这种需求，世上没有一套现成的软件能够100%满足。面对这些需求中复杂的术语和深奥晦涩的部门业务概念，作为项目负责人的你未必能够逐一甄别。
其次，您所参考的OA厂商宣传，或鱼龙混杂、或互相抄袭、或无中生有。有的还将其它多个专业方向（如专业的客户关系管理、专业的视频播放交流等）的软件概念直接挂在自己的头上炒作，真正有价值的协同办公模块却被淹没在无声的角落，无法尽善尽美地实现。
再次，每一款OA软件各有所长，如果不分轻重缓急的想要集所有闪光点于一身几乎没有可能。如果一定非要如此，为了完成合同内容，软件工程师必定需要进行各种方向的开发，如此一来先不说软件个部分的融合度如何，单是项目的完成周期就会无限期延长，资金投入也会成倍加大，可以说代价是非常巨大的。再加上或许随着项目开展您或您的同事将提出更多的需求将原有需求更加完善，如此不断变化，永远没有止境，最后项目只有不了了之，以失败告终，这样的前车之鉴还少吗？
笔者建议
建议您从繁杂浩瀚的细节中脱出身来，先找到一个组织共性的需求——协同，然后才是关键部门的需求，最后才是重要角色的需求。 另外可能有其他各种需求，有你敬畏的上级提出的，有强势部门提出的，有不起眼的人提出的，其技术难度和实施难度可能有天壤之别，你必须衡量轻重缓急以及其需求是否满足对全局的成败影响。否则这些汇总的需求将使得你无法把握项目主干进度的节奏，双方有限的资源被分解为千疮百孔补丁工程，重蹈前人久拖不上的覆辙。