在项目管理中一直存在着这两个矛盾，一个是管理的需要，一个是业务本身的需要。所谓管理的需要，就是作为项目的指挥者必须实时知道项目的状态来调整整体的进展情况。项目中的状态会议和团队建设活动等都属于管理行为范畴。而业务的需要，就是为了实现项目的目标对项目进行的开发活动。例如需求整理、方案设计和技术开发等活动，这些都是需要项目开发人员来完成。管理行为和业务行为相互促进，缺一不可，但是却不能相互替代。作为管理人员或者作为项目的实际开发人员最常见的问题就是夸大自己工作的重要性，而忽视另外一种行为。

项目的监控过程本质上是一种管理行为，但是项目中的成员大部分时间面临的是项目工作本身的压力，也就是如何完成自己的工作任务，解决项目的业务问题。所以项目中的成员就有反对过分监控的本能心理动机。路是要一点一点铺的，墙是需要一块砖一块砖砌的，代码是需要一行一行写的，这个怎么都回避不了，也是面临这些任务的人每天的“痛点”。而此时由于管理者需要监控项目的情况，便于进行调整，所以就要求他们配合一些管理的行为，例如写项目的状态报告、总结和对项目的工作成果进行必要说明以及按照配置管理的约定管理自己的过程文档、成果等。这个时候便会引起项目成员心里本能的抵触情绪。但是经过这么多年的实际工作和公司内部的培训，项目成员也往往知道这些行为的必要性，这就产生了一种矛盾，一种理智和本能的矛盾。项目经理只有深刻了解这一点，才能更好地理解和预测项目团队成员在这个阶段本能的行为。

在这种情况下，项目经理为了缓解项目成员对项目监控这种管理行为的抵触，避免项目成员对项目报告等管理行为的敷衍态度，就要尽可能多地识别那些不必要的管理行为，尽可能地把管理行为和业务行为融为一体。(www.daowen.com)

例如，微软公司在开发中有“日创建”和“冒烟测试”制度，这种做法不仅可以尽早地发现错误，还可以让整个团队成员一直把目光集中在产品整体的性能表现上，也知道自己的模块对整体的重要性。这完全符合工作特性理论的任务重要性和同一性法则，会增强员工工作的积极性和工作效率。但是，不可否认的是这两种行为本质上还是以管理行为为主，所以时间长了，也会招致员工的敷衍心理。所以，在某家研发型公司推广这个做法的时候，一开始通过公司的制度来强制执行，要求员工每天下班之前必须要提交一个编译通过的代码到版本库中，之后在下班的时候由程序自动编译并执行测试脚本。如果每天下班之前没有提交这样的代码会被公司认为没有达到当天的绩效，直接影响项目的奖金情况。这样每天管理人员都会得到项目的最新缺陷信息，所以听起来不错。这套体制的建立花费了公司大量的人力和物力。因为当时仅编写自动测试的脚本就需要一个有相当技能的人员，而且还需要买进相应的软件系统。但是实施一段时间后，这套系统就开始变得形同虚设。因为有的员工可能当天并没有什么重大进展，所以就提交了一个本质上没有什么变化的版本入库。还有就是软件公司加班是特别正常的事情，在加班的情况下，如何提交这个版本就成了一个很麻烦的事情。这种情况继续恶化，最后项目管理部的人就说服公司发布更严格的制度来保证实施。结果就造成了技术人员和项目管理人员的严重对抗状态。而项目管理中一旦人发生对抗了，几乎所有的项目管理手段都会失效，这个已经是业内的普遍共识。后来把这个制度调整了一下，那就是定期地向每个员工发出统计说明，把常见错误进行了分类，给出每个员工的错误统计，员工可以实时来查询自己的错误分布。这个调整效果很好，因为大部分员工可以利用它来改进自己的技能，知道自己的不足之处。在这种情况下，员工主动提交的积极性开始上升。

项目经理还可以借鉴分配任务的时候讲过的技巧，把项目中的问题提给大家，征求大家的解决方案。利用大家的方案来制定项目的监控手段，这样效果也很好。