IPD团队的组织结构会因项目规模和技术细节而有很大差异。项目规模会影响团队数量、团队各自的工作范围以及如何指导和协调团队。项目的技术细节将决定如何组织团队，以及团队是否以及如何重叠。最基本的模式（适用于小型项目）是创建一个由关键参与者组成的跨学科团队。与其创建多个团队，不如创建一个稳定的核心团队，并在项目的适当时刻引入其他专业的人员。该核心团队至少应包括业主的项目经理、项目建筑师以及承包商的项目经理或主管。随着项目的进展，其他业主代表（例如运营和设施管理代表、结构工程师以及机械、电气、管道和框架专业的代表）将根据项目需要加入团队。这样既能保证连续性，又能将团队的活跃规模保持在可控的水平，同时又能代表关键参与者，而无需他们在完全投入之前就必须参与。
有两种互补的方法来决定哪些实体是关键参与者。第一种方法侧重于哪些群体需要共同努力才能取得成功。在其他项目中，信息技术或视听系统对项目成功至关重要，核心团队应该考虑在设计早期就将这些学科纳入其中，而不是在基本系统开发之后。
如果采用基本方法，则应该在设计前召开一个由所有最终参与的团队成员参与的设计研讨会。该研讨会应重点关注将要使用的基本系统、可能存在的改进设计和施工成果的机会，并在设计决策做出之前向设计师提供来自设计团队的信息和建议。研讨会还应设定预期，即施工层面的信息不会作为单独的信息流（施工图和提交文件）出现，而是会包含在设计文档中。缺乏IPD经验的分包商和顾问可能不愿在设计决策确定之前参与，因为他们觉得如果参与分析那些可能不会被采用的方法，就会徒劳无功。但这恰恰是他们可能对项目最有帮助的地方，因为核心团队应该挑战他们的犹豫，并仔细询问潜在的参与者，以确定何时应该让他们参与。随着项目规模的扩大，基本方法（尽管不是基本理论）必须改变。一个灵活的团队根本不足以完成这项工作。如前所述，工作结构应以适应团队为导向，而不是为了适应工作而扩充团队。这意味着核心管理团队必须创建一个结构，使工作团队保持合理紧凑，避免团队之间职责脱节，允许同步协调，并确保与总体目标保持一致。
通常使用几种结构来划分工作范围。如果项目容易受到地域划分的影响，则可以采用基本的团队方法，但每个团队负责项目的一部分。例如，可以按部门、楼层、阶段或结构划分工作。在其地域划分范围内，每个团队负责所有职能和学科。区域责任团队需要采用整体系统方法，并需要与其他区域团队进行协调。整体系统方法由一个单独的团队制定，该团队评估各种方案，并为区域团队提供图表指导。区域团队之间的协调可以通过三种方式进行。首先，整体系统团队可以承担协调责任。这并不是首选，因为它免除了区域团队的协调责任，并且违反了将协调设计到流程中而不是在工作完成后测试协调性的规则。
更好的方法是将协调责任赋予各个团队，并使用团队成员重叠或定期的“大房间”协调（或结合使用这些技巧）来确保正在开发的设计协调一致。“大房间”协调会议不仅应侧重于协调已完成的工作，还应讨论每个团队在下次开会之前的一段时间内将完成哪些设计工作。这些会议应足够详细，以便团队在进行详细设计之前发现并解决潜在的协调问题。对于较大规模项目，第二种方法是按系统划分工作，例如干式或湿式机械系统。这种方法的优势在于能够提供特定系统的整体视图，并使所有成员都具备高水平的专业知识。然而，这种方法会降低多样性，并在功能系统之间以及物理元素之间产生额外的协调问题。基于系统的团队可以通过“大房间”流程进行协调，由相关团队召开联合会议。在“大房间”会议中，团队分析问题，检测工作冲突，解释下次联席会议前计划完成的工作，并制定彼此要求的决策和可交付成果清单。定期在显眼位置（例如走廊和墙壁）发布设计信息可以增强团队协作。虽然这些信息可能以数字形式存储在服务器上，但将信息呈现在其他团队经常看到的地方是更有效的工具。创建一个醒目的区域，让团队发布当前工作，以便其他团队成员一目了然地了解每个团队的进展情况，或许是值得的。
定期的进度安排也是一种有效的协调方式，因为它专注于团队之间的决策交流。为了将进度安排拉到某个里程碑，团队必须相互请求并承诺提供信息和可交付成果，这会暴露协调问题。在大型项目中，信息管理可能成为一个重大障碍，尤其是在不同软件工具之间共享建筑信息模型数据时。此外，即使系统具有足够的互操作性，也需要对信息进行适当的分类、标记、跟踪和归档。这需要项目标准和程序。此外，如果信息将被重新利用，那么创建和使用这些信息必须就如何在建筑信息模型中呈现设计和施工元素达成一致。
在大型项目中，信息需求极具挑战性，需要专门组建一个团队来处理项目的信息需求。项目的技术性质会影响团队的组成。医院拥有复杂的机电系统，因此医院团队会强调这一要求。剧院和大学教室对声学、显示和信息技术的要求至关重要。对环境要求较高的项目可能需要具备特定的能源效率或可持续性专业知识。这些项目将围绕这些要素适当地组建团队。
团队规模应与目标相匹配。规模较大的团队（12人或以上）更擅长开发替代项目解决方案，但完成任务的效率较低。规模较小的团队技能有限，缺乏多样性，限制了知识和创造力。最高效的团队既不会非常小（少于4人或5人），也不会非常大（超过12人）。规模极小的团队往往缺乏多元化的观点，而超过12人的团队则难以完成更多工作。一个好的经验法则是将团队规模保持在5到9人之间。一些专家还建议，团队规模不应超过完成任务所需的规模。如果任务对于一个高效的团队来说过于庞大，则应将其分解为子任务。保持团队规模较小可以减少成员之间的信息流失，并增强个人责任感。由于小团队的成员彼此了解，因此任何成员都很难在不被其他团队成员察觉的情况下放松自己的努力。当团队成员过多时，凝聚力和相互责任感会下降，社会惰化现象会加剧，更多的人会减少沟通。大型团队成员彼此之间难以协调，尤其是在时间压力下。除非项目规模非常小，否则没有哪个团队能够包揽所有事情。因此，团队组织的一个关键要素是团队内部的团队结构。
大多数项目都会成立专门的团队来负责项目特定元素、系统或物理区域的设计以及最终的构建。例如，负责大型医院某一楼层机械系统的团队通常会向负责MEP系统的团队汇报。确定团队边界的一种策略是评估历史故障区域，并确保团队中包含负责问题边界的人员。
跨职能团队IPD团队应始终保持跨学科性，并且通常应具有跨职能性。跨学科团队由具有不同培训和经验的成员组成。跨职能团队由具有不同职责的成员组成。例如，一个由建筑师、机械工程、机械承包专家组成的设计阶段团队是多学科的，但他们在该阶段可能都专注于设计。跨职能团队将包括采购、成本管理/估算和运营部门的代表，以及负责设计和施工的人员。他们的职能和背景各不相同。例如，跨职能IPD团队应该共同设计项目的一部分，但也应负责管理成本、确保进度、建造和调试该部分工程。范围、进度和预算应在团队内部紧密结合，而不应委托给不同的部门。跨职能团队在制造和软件设计领域取得了巨大成功。波音、丰田、IBM等公司都曾使用由来自不同内部团队的成员组成的团队，对一个产品或产品的一部分进行全面负责，从概念到创造，包括销售和市场营销。由来自设计、工程、生产和销售领域的人员组成的跨职能团队是爱德华·戴明（W.EdwardDeming）提出的“西方管理转型原则”（Deming，1998）之一。正如斯蒂芬·罗宾斯（StephenRobbins）所指出的：“跨职能团队是一种有效的手段，可以让来自组织内部甚至组织之间不同领域的人员交换信息、开发新想法、解决问题并协调复杂项目。”克雷格·拉曼（CraigLarman）警告说，仅仅进行跨职能的管理整合是不够的。在大型产品开发中，真正的跨职能整合非常罕见。相反，我们经常遇到由不同职能领域的管理代表组成的跨职能项目管理小组。这样的团队行不通。真正的跨职能整合发生在工作层面。只要有可能，团队就应该负责实现项目目标所需的所有组成部分，并负责与其他团队的协调。对项目独立完整的部分负责可以减少跨学科接口处的错误，并提升团队的主人翁意识和对整体的自豪感。目前的IPD团队通常围绕相关系统组建。这些团队随后将他们的建议或工作提交给职责更广泛的更高级别的团队。更高级别的团队充当信息收集者、协调团队以及将工作下放给职能团队的团队。软件开发的证据表明，团队应该直接负责协调，而不是依赖协调层，尽管在较大的项目中自我协调可能很困难。
人员流动会增加浪费，并限制团队效率。例如，建筑团队通常寿命较短，成员会随着工作量的增加或减少而频繁调动。这种做法与项目团队的研究结果相悖。成员稳定的团队比那些不断面临新成员加入和老成员离职的团队拥有更健康的活力，绩效也更佳。首先，项目提案团队应该作为执行团队，核心人员的变动不大。稳定的团队不仅在过渡期间信息丢失更少，也无需重建关系和信任。其次，如果项目负责人拥有多个项目，则应考虑聘请专门的团队负责后续项目，前提是该团队能够持续改进，并且人员配置基本相同。第三，公司应确定负责每个IPD项目的IPD专家，以便在不同项目中分享经验教训，并指导经验不足的团队。如果公司尚未拥有经验丰富的“专家”，则应考虑聘请拥有相关经验的顾问来扩充团队。最后，公司应积极将从正在进行的项目中学习到的知识融入到培训计划中，IPD实践知识应该制度化。如果您的团队足够幸运，能够长期保持稳定，那么引入新成员或让团队参与“创造性颠覆”或许是明智之举，以抵消长期项目带来的绩效下滑。
相关新闻推荐
