当一个组织是以项目的形式运作管理时，在管理上积淀是比较困难的，项目本身就是一独立的权力结构，但并不是公司法定的，公司的组织机构是按部门、科室式划分的，公司的管理体系也多以部门的职能划分的流程，这时权力的矛盾就一定会在业务运作时产生，发生资源的掠夺行为，要么部门难以管理，要么项目难以管理，而由于项目是一个临时的组织，这种人力的汇聚与释放都是比较麻烦的，人不是一个机器部件，放在哪儿都是一样，你起用一名人力需要相当长的磨合期，而且公司的任务往往是有周期性的（最小时间单位很大），这时人力释放时并不意味可以马上投入利用，这种痛苦没有经历过很难体会到，这比你在ERP中排生产计划还要难。
运维服务一般是项目的形式管理的，项目内的作业与要求与部门或公司的制度或管理往往是存在偏差的，这时如果部门或公司处于强势地位，项目内的作业往往会被冲击，或者被动的敷衍配合公司的制度或管理，就比如培训，站在部门或公司的角度希望搞员工能力提升的培训，这种计划安排与内容，往往与项目内希望做的培训是有非常大的出入的，很多时候项目的一线主管们，往往认为公司或部门并不是帮助他们，而是一个麻烦制造者。一旦项目数量大时，这种情况越普遍，因为项目越多，上层对规范、标准化的愿望就越发强烈，当一线的项目主管们花费越来越多的管理资源配合公司的规范与标准时，对项目的控制力就会开始下降，一旦发生问题，上层领导就会认为是因为缺乏规范与标准化，形成一个恶性循环。当某个项目发生个严重运维事件时，马上会短时间把管理资源进行堆积，对这个事件进行深入到可怕的分析，然后制订出一个非常完备的制度，要求每个项目进行落实，真的这种做法会起到良性的作用吗？反应过度了，也有些缺乏理性，资源永远是有限的，你把多数的资源花在防止概率很低的问题上，而让那些概率较高的问题没有相应的管理资源去控制。当你想达到一个目的时，你会采取一种措施，但事实上你采用的措施往往会让你妨碍你达到目的。
对于运维服务而言，你让客户用一个最重要的词来说出他的要求，他们往往是说“稳定”，同样的道理，运维服务管理也是最需要稳定的，那种救火堵漏的做法并不可取，你先要很稳定你的管理，再去谈改善，永远处于制度的发布与调整中，会让运维服务管理反而成为最大的运维风险，作为高层领导，由于缺乏细节信息，对自已的运维服务管理缺乏信心，总是觉得随时会发生火山爆发，一旦发生问题，就会过度的反应。
作为运维服务的管理部门，一定想清楚自已应该做些什么，你的管理边界在什么地方，你是一个政策制订者，不应该越过项目的边界去干涉项目的内部事务，这种做法最多只能取得短期成效，从长期而言，结果一定是负面的。管理部门负责服务体系的维护与执行监督，以及所有服务资源调配的控制者，这才是最重要的，在细节层面，管理部门应该只起到辅助的角色。