项目支持团队和项目团队之间的协调

newmaker

欢迎访问e展厅 展厅 3 管理咨询与服务展厅 企业文化, 战略管理, 生产管理/工业工程, 营销管理, 知识管理, ... 支持团队有时也叫扩展团队，它由全职或兼职工作在部分或整个项目的人组成。本章将讨论如何获得他们的参与和承诺，以及如何协调他们与项目团队之间的关系。我们也考虑到项目团队、支持团队以及分包商之间的互动。 参与和承诺 要使支持团队建立一种参与的感觉并获得他们的承诺，那就要像项目团队那样，使支持团队的成员参与建议书的准备过程。员工的参与也构造了团队精神，这种精神 能够超出项目之外而存在。如果没有建立起团 队精神，那么就要让他们自己来计划自己的工作并将其落实到书面上，这样也可以激发他们的参与和承诺，记住第5章中所介绍的黄金规则：让真正将要工作的员工做出工作计划。 项目经理，不论他们的公司是怎样的具体的组织形式，他们都经常感觉到缺少职权。在一个B2B项目型的组织中，项目经理确实拥有对下属员工的职权。尽管这样，在所有的状况下，您将会在第15章了解到，职权实质上并不是很有用，影响力才是一种重要的组织力量。 使支持小组尽早参与 项目经理和项目团队经常忽略对必须由其他团队提供的支持的需求，直到为时已晚。这就是通常叫他们扩展团队的原因之一。每个人通常认识到他们在项目中有成员，并且在项目成功中起到作用。在更大的公司中，支持团队包括诸如采购、仓储、接发货物、合同管理、模型车间，以及其他专业服务等职能部门。除非这些支持团队的个人认识到他们的服务可能被需要，否则他们无法预测他们被需要的程度。当支持需求提出得太晚时，支持团队将会有一种被遗弃的感觉，取得他们的承诺也就会很难了。 由于项目团队有某种程度上的狭隘观念，或不知道什么支持会容易得到，都会导致这种情形的出现。项目团队可能不理解其他人员能够扮演哪些潜在角色，或以为自己的团队比支持团队更知道最需要哪种类型的支持性工作，后者的情形更经常出现，因为项目团队认为支持团队将会为他们该做的工作“镀金”，从而超出项目预算。 就如前面提到的那样，解决这些问题的最好的办法是，在建议书阶段就让支持团队参与。如果不能这样做的话，在项目工作的尽可能早的时候使他们参与其中。给他们参与为他们工作做计划的机会，发挥他们最好的思考和专长技能。 这个同样可以运用到时间和费用的估计上。支持团队应该为他们的工作估算时间和费用，然后经项目小组核准通过。如果他们与支持团队的第一次估计不同的话，这些估算可能需要讨论修改，从而调整其他的项目任务来适应支持小组的计划。这种情况很常见。支持小组有时必须按照由其他更高优先权的任务要求来执行他们的角色，这样会造成对您的项目的支持与您所计划的有所不同。 支持小组发现，以一种完全不同的方式去执行自己的角色对项目来说通常是非常有利的方式。或者，支持小组的专家会使项目团队相信他们的角色必须比原来认为的要更宽广。因为这些原因，所以说要使支持小组尽可能早地参与项目。 书面承诺 在组织内从支持团队得到的有意义的承诺，就像您从外面的分包商那里得到的一样，应当都是书面协议(对于项目团队的承诺您也应该这么做。唯一的不同就 是，在解决可能出现的争议时所采取的行动)。 如果支持团队管理者签署了书面合同，他就会 激励他的小组努力实现这个承诺事项。就像我们在第2章讲得那样，书面的合同是合法的和可实施的，但是去聆听关于经验和文件重要性的理解的声音更重要。这个结论和萨缪尔高德温的一句话很相似：“一个书面的合同都比不上它所在的那张纸。” 支持团队的优势 就像我们在前面章节描述的那样，多数项目经理看上去更喜欢将项目完全或大部分)配备给项目团队的成员。但是少数项目经理(特别是矩阵式组织中)更喜欢有一个大的支持小组，而不是一个大的项目团队，其原因如下： (1)在项目结束后，项目经理没必要担心支持小组的安置问题。 (2)对于分包商的情形，支持协议包括在一个有法律效力的手段中，也就是分包合同或采购协议中。 (3)项目经理搜索具备所需技能的专业人员或专家的范围十分广泛。 协调 在确定了支持小组、他们的工作也得到了正确的计划、与项目团队的阶段工作很好地衔接之后，还需要继续协调项目团队的工作。这时用网络图最合适(见图14-1和图14-2)。在这两个图中，支持团队的工作和网络工作的主要部分已分开。有很多种方法，比如为每个支持类别制定不同的线条样式。在有彩色复印机或 打印机的地方，可以使用彩色的代码。一些基于计算机的项目管理软件，使得您能为具体的小组和个人制定进度表。其他PDM软件可以使您将日程图的部分(如后期两英尺，中间三英尺，或较低的两英尺)指定给一个小组或个人(图13-2显示了一个备用的方法来帮助协调)。 变更 仔细考虑图14—1的网络图。假设您发现您将在任务D处拖延，您是否应该将此消息通知您的分包商(负责任务B)?一般来说，最好通知您的分包商您真正需要的日期。这样做的话，您会让他们后面比较轻松，而且他们的费用会会较低(至少长期来说)。但是如果分包商一向都是延迟，最好对于他们的工作加入时间上的应急储备，不要让他们知道您所经历过的任何延迟。 应该主要以书面的形式进行沟通和协调。对于变更，如果需要的话，应该通过快速的口头交流——用电话和／或尽可能有很多人参加的会议。那么您应该确信您在项目计划的修订版本里记录了变更。 修订 计划一旦落实到纸面上，就应该公布出去，并且让所有涉及的人都理解它。还需要始终保持计划是最新版的。如果任何过时的项目计划还在项目中流通的话，那么所有项目计划的可信度将会受到怀疑。因此，每个有最初计划的人必须收到修订版。这可以通过保持准确的分发名单来完成。如果您的公司拥有局域网，每个人(至少每位关键人员)应该在自己的桌面上有一台终端，并带有最新的时间表。显然，他们必须既商议又要理解时间表和任何变更。 与支持小组的交互作用 项目团队和支持团体的交互作用可能显得非常困难。非常普遍的原因是支持小组很晚才涉人项目中来。这引出一个故事：在早班火车刚刚开始启动时，一位乘客劲头十足地冲向火车的站台。一个旁观者看到这个人错过了火车，说：“太糟糕了，如果您跑得再快一点，或许您会赶上火车。”当然，这个经常往返的乘客知道这不是仅仅跑得再快些的问题，而是应该早一点出发的问题。 项目行动 前面提到的那位迟到的乘客的情形对于项目中涉及采购的部门最为合适，采购的材料如果比要求的日期到达的晚，项目就会延迟，项目的采购人员就会责备分包商运出的太晚，或者责备采购部门没有尽早下达命令。事实上，责备的对象应该是那些没有按要求采购的人，否则货物就可以按时交付了。他们不需要跑得更快，而是应该早出发。 有经验的项目经理处理这样的问题有两种方式：一是他确信网络图时间表留出了足够的时间，以便支持团队能够有好的表现；二是项目经理确信所有的人都知道任务活动什么时候必须完成，并使任务经理负责满足时间表的要求。 支持小组的观点 这些事情可以从不同的角度看待，也就是说从支持团队的角度去看。他们由专业人员组成，在前述的例子中，也就是指采购方的专业人员，他们希望得到最好质量的货物，但要在项目人员强加的其他限制内以最可能低的价格购买。他们需要时间按照专业的竞争的方式去执行他们的职能。比如对于政府合同的情形，通常按照法律法规，甚至规定要有三个竞争性的投标。 和我们一起工作地项目支持小组的经历，发现有些项目团队不能充分利用支持小组的在现存工作委托中的专长和知识。第5章中曾提到的支持小组经理举例说明了一个普遍的争论，也就是他们的专长和知识不能被足够早地认为是有帮助的。例如，当项目需要他们的参与时，就可以把工作量强加于 当然，对于任何支持小组来说都是这样，比如技术工作者、计算机程序员、设计师、绘图员或模型车间人员。每个人都想把工作做好，并且希望有足够的时间来完成工作。但是不满却在他们身上强加来自其他部门的一些工作量。他们努力应付那些不定时的带来不定量的工作。因此，支持小组在能够接受新的请求之前，通常都积压着一些必须完成的工作。如果他们没有这些积压的工作，即如果他们空闲地等着任务的到来，那么他们就没有最有效地利用自己的时间，而这正是组织至关重要的资源。 分包商 分包商，基本上和您自己没什么不同。他们和自己的顾客签订合同，这个客户就是您或者您的B2B项目。他们想要对您负责，但是他们也有和您相似的难题：人员和资源经常不能立即可用，或者是不完全合适；他们也需要时间去为他们的工作做计划；他们也需要正确地理解三个约束条件等。 一个合同控制着您和您的顾客的关系，同样的道理，分包商通过您公司的采购部门与他们签订的合同来确定他们和您的项目的关系。如果需要发生变更时，当然应该告诉他们。但是只有在成为合同变更时，这种变更才真正有效、有意义。 与分包商合作时需要考虑的另一点是，您的建议书邀请函(REP)可以要求在合同中加入定期的评审。这是非常必要的，就像您的客户很可能要求对您的工作进行评审一样。通过总结，您可以看到他们的工作进展得如何，了解是否需要做出任何变更，他们遇到了什么难题。简而言之，您需要了解他们工作的最新进展。 在很多情形下，您可以做其他事情来帮助您的分包商更有效地工作。LL如，您可以和他们的项目经理开几个长点的会议，让他知道对于您们来说什么是重要的。您也可以对非关键性的事项(如果合适的话，适当地修改合同，做出让步。您可以了解并审查他们的进度表，并提出建设性的建议。假设您已经做出了合适的安排，您还可以检查他们的分析并亲自参加工程测试。 但对于提出新的要求和仅仅了解他们在做什么之间，您必须很好地划清界线。记住，合同指导着工作流。进度审查和 对活动的监控都不能替代他们对工作的管理， 相反，这些工作仅仅是为了检查工作。您不能每天、每周或每月向他们提出变更要求，并且还期望他们能够成功地执行您的变更要求。 典型问题 与支持小组一同工作是难度最大的，特别是对于那些新上任的、没有经验的项目经理。这个问题的根源取决于要依赖不是上下级关系的人员工作。另外两个难题也紧密相关。第一，谈判支持协议需要很多时间，而这通常发生在项目很忙的开始的阶段。因此，这就会导致合作协议经常是很不情愿地去做的，而且做得很差，甚至会被省略掉。在后一种情况下，项目经理要自己来判断支持小组将要做什么。第二，即使当支持协议被很好地指定下来了， 以后的事件也会频繁地需要协议发生一些变更。同样，这是件耗费时间的事情， 因此必须预料到这一点。下面是我们遇到的一个项目经理的评论： 我工作在一个40%~50%的技术工作都是由另一个团队来做的项目。有意想买的目的是把这两个技术组合起来，因此这两部分的工作都对项目成功具有很重要的作用。其中一个团队因为有很严重的技术困难，所以不能指定一个工作策略。尽管我们有相同的项目基线，他的团队还是拒绝我们的建议。我们相信我们团队可以解决我们交给他们的那部分并且可以把工作做的更好。 这个评论说明了依赖内部支持小组工作的难题。公正而论，这个评论也由于这个团体本身比较傲慢，而且另一个团体可能也存在不想创新的惰性。 当支持团队非常忙，而且他们已经有着一个繁重的工作进度表时，另一个问题浮现了。这个情形下，很难为项目获得支持，而且项目经理缺少直接的职权。项目经理的评论显示了这个问题的另一个方面。 一个项目可能需要很多的部门来完成。您在建议书阶段，您会要求每个人提交项目建议书。在您为项目前述协议后，其他部门优先执行他们的项目而不是为你执行项目的工作，这是司空见惯的事情。 显然，您应该试图在制定初始计划时，预料到这些潜在的问题。您还应该清楚，对于被指派同时工作在多于两个或三个项目以上的人员，不能指望从他那里得到有效的帮助。效率的急剧下降很可能就是因为这样的人。最后，谨防招募一个大型团队的想法。团队越大，就需要越多的时间去交流，这样就会更无效。当两个公司都开发比较大型机处理器时，较小的团队会进展得更快。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (6/17/2009)