作为一名IT经理，我曾经经历过一段现在想来确实是十分难得的舒服日子。那个时候，需要管理的差不多只是一种类型的员工，因此只要在工作中有足够的投入，几乎所有的问题都可以得到解决。但是，当我手下的项目小组的数量不断扩大，员工类型不断增加——既包括程序设计人员、又包括质量保证专家、安全小组、基础设施工程师、人力资源专家和临时的看门人的时候，我开始逐渐的意识到：要完成工作任务，仅仅靠努力工作——哪怕是革新性的工作——已经远远不够了。实际上，现在对员工进行管理的方式同以往相比已经是截然不同了，需要管理者应用全新的组织和管理方法。
项目彻底失败
我意识到这一点是在一个失败的项目的进行过程当中，后来这个项目被我形容成了彻底失败的项目。我的项目小组又包含了五个分组，每个分组都有自己不同的职能和职责。其中有三个分组（开发、配置和业务/支持小组）“工作”非常勤奋，以创建客户环境。另外两个分组（资源和质量保证小组）负责向这三个小组提供管理和质量支持。我同项目小组的其他负责人一起努力工作，并且同其他的小组成员保持着联系和沟通。
在一个规模比较大的系统升级进行了六个月之后，整个项目小组的工作都停了下来。我们没能按时完成一个新的ERM软件的配置。当我问及能够完成任务的时间时，开发主管告诉我说：“永远也完成不了。负责质量保证工作的那些该死的白痴永远也完不成他们的工作”。
听他这么一说，我立即就给质量保证小组的负责人打了电话。他给我的回答竟然与开发主管的回答基本相同：“只有在有了成品之后我们才能够进行质量验证，可是开发小组根本拿不出任何可以让我们验证的东西来”。在他看来，更为糟糕的是，在配置小组和业务小组的帮助下，开发小组总是把在客户环境中配置新软件的责任推到质量保证小组的头上。
在同这些负责人的交谈中，我受到了某种触动。这些工作小组在谈论的似乎是完全不同的工作。根据我当时的理解和判断，一定有什么地方出了问题，我在自己的头脑中敲响了警钟。
在经过了反复的考虑之后，我召集了一个小组负责人会议。在会议召开之前的一个星期，我单独把每个小组的负责人都叫到了会议室面谈。在交谈的过程当中，我们一起分析各个小组的工作情况，明确各个小组的职能和职责。当一个小组的工作同其他的小组密切相关时，我们也会从领导者的角度对相应小组的角色进行分析。
事实突现
在会议召开的前一天，我把自己手头的工作交给了自己在公司里的朋友，让他们在未来几天的时间里代我履行基本的工作职责。然后，我就静下心来，把会议室的门一关，同各个小组的负责人一起分析整个项目小组的工作情况。
从某种角度来说，我还是感到非常高兴的。因为大家至少都在表面上在项目涉及的一些基础问题上达成了共识。在其他小组的职责问题上，各个小组的负责人之间存在很多重大的分歧，但是在任何项目的进行当中，出现这些分歧都是正常的，所以我们都不会感到奇怪。
但是，从另外一种角度来说，我的心又不禁感到一沉。造成冲突的原因，同时也是造成工作无法按期完成的不可避免的原因，是那么清楚的展现在我们的面前。
生产小组（开发和配置小组）对其他小组的外部依赖程度要相对小一些。它们的职责和职能决定了他们的工作表现直接取决于工作投入。如果这两个分组的某个成员在某项任务上投入了九个小时的时间，那么他能够得到的回报就是这九个小时的工作产出。
资源小组（质量保证小组和资源小组）如果没有其他小组的帮助，可谓是寸步难行。这两个分组的工作同其他小组的工作之间存在着错综复杂的相互依赖关系。如果没有配置小组的帮助，质量保证小组就不能更改测试数据库中的数据。如果没有其他小组的授权，资源小组也无法召集会议。换句话来说，这两个小组的工作极大的取决于其他小组的工作。真正起作用的并不是他们在工作当中的投入有多少，因为他们对其他小组的依赖性实在是太强了。
