老邱解答
对于这样子的项目，我觉得我们可以前期花一部分的精力在项目规划上面，而对于需求的反复确认是非常重要的。因为涉及到的部门和相关方过多，你往往会发现在咨询大家这些需求都要不要做的时候，大家并不会提出反对意见，因为他们也害怕动了其他人或者部门的利益。所以很容易出现一个当时只是想做一个初步功能的小项目，而需求被各个相关方们无限扩大，他们并不会考虑项目的难度和周期，他们反正希望想到的功能点越多越好。
这时候我们发现PMBOK上提到的需求跟踪矩阵的的意义就发挥了出来，作为项目团队的我们会把大家提到的这些需求都分门别类的整理出来，现在需要各个部门之间的取舍，因为我们知道按照我们现在的团队力量在短期内是做不完这么多的需求点的。为了满足每个部门的面子，我们可以采取投票的技术来确定哪些需求是需要交付的，哪些需求是可以暂缓的，而不是盲目的把所有需求都做完整。当然啦，我们知道项目的工期是有限的，又或者说项目的交付时间是确定的，我们也可以运用项目的总交付时间来倒过来推算。比方我们项目是100天后交付，我们可以在需求跟踪矩阵上把每个需求的完成时间做一个初步估算，比如这些需求全部做完可能要200天，那么我们告知这些部门不得不舍弃一些需求。有时候呢，给项目减负和做减法是一个很好的方法，而不是用项目团队的判断确定哪些要做，哪些不要做，这样你们一定会得到各个部门的投诉。切记，需求是业务方的，删减的权限也应该给到业务方。
再来分析这个企业的另外一个现象，就是很多项目都不一样，项目管理讲究创新和弹性，真的很难把所有项目的文档、表单都统一化。现状确实如此，我觉得不用把所有文档都统一，但是项目管理的主干文档是可以统一归类的。大家可以想想PMBOK可以运用在各行各业，航空、汽车、医疗、建筑、软件开发等等行业都能很好运用，其实我们已经剥离的各行各业的技术方法，保留了项目管理的方法论。也就是说大部分企业的项目管理方式是差不多的，放到部门也是如此，我们可以推荐PMO为大部分IT项目设计一些主干的项目管理文档。
比如说，我们立项都是需要项目章程的，项目都需要需求跟踪矩阵、范围说明书和WBS，又比方说项目都需要甘特图和成本预算，还比方每个项目都需要问题日志和变更管理流程等等。而这些文档将来都是需要存档为企业的组织过程资产，供未来项目使用和作为估算的参照。对于瀑布式项目管理来说，文档、流程可能高于一切，所以这些都是需要记录的。
另外我说说每个企业比较特殊的IT部门，这个部门的人非常强大，他们是最知道整个企业中各个业务部门的流程和管理方式的。因为要上线IT系统，首先就要懂得这些业务部门完整的工作流程是怎么样的，这样才能为他们设计符合他们业务流的IT系统。不像很多企业，质量部只负责质量、研发部只负责研发、采购部只负责采购，而这些IT人需要懂得整个企业的业务框架和流程。
现代的企业是离不开信息系统的了，无论任何行业都需要，IT已经不再是以前我们说的企业信息化那么简单了，要做到信息化我们只要有基础架构和软件，通过运维保证系统可用性、可持续性和稳定性即可。现在越来越多的企业在推行IT数字化，甚至我们还通过各种大数据做到了IT智能化。一个企业IT建设的优劣也确定了这个企业在行业中的江湖地位，因为我们知道IT不单单跟工作流挂钩了，他们还跟业务流挂钩，还跟大数据人工智能挂钩了。
IT人的学习是永无止境的，IT的工具和方法每年都会出来很多很多的新方法和新工具，所以IT人对于学习也是永无止境的。这时候就要考虑自己的职业规划和定位了，因为你不可能一辈子只做技术，所以这些年IT的项目经理和产品经理也越来越多。我们往往会发现一个完全不懂IT技术的项目经理很难融入IT团队，也很难推进IT项目。这些项目经理不用自己IT技术能力很强，但是你应该对各个技术都有略懂，你需要有很强的团队管理力和领导力！
所以呢，真的要破解企业IT部门各个条线的项目经理标准也不尽相同，PMO是支持型的架构并没有错。管理这个东西呢，抓的太细也不好，太宽松也不好，就好比水至清则无鱼的道理。给IT部门设计一些大家都能适用的基本流程和文档，设置一些项目成功的标准，抓大放小即可。
加油打工人，加油IT人！