8.2 建立项目决策体系
8.2.1 项目团队决策的基本步骤
项目团队的决策是在分析、评价、比较的基础上对项目活动方案进行选择。其具体过程如下。
（1）研究现状，决定改变的必要性。决策是为了解决一定问题而制定的，决策的目的是为了实现项目组织内部活动及外部环境的动态平衡。因此，制定项目决策，首先要分析不平衡是否存在，是何种性质的不平衡，它对项目组织的不利影响是否已到了需要改变的程度。
（2）确定项目团队决策的目标。在分析了改变项目团队活动的必要性以后，还要研究针对不平衡将要采取的措施应符合哪些要求，必须达到哪些效果。也就是说，要明确项目团队决策的目标，因此必须完成以下几项工作：
1）提出目标。
2）明确多元目标之间的相互关系。
3）限定目标。
（3）拟定项目团队的决策方案。决策的本质是选择。要进行正确的方案选择，就必须提供多种备选方案。应当注意，在项目决策过程中，拟定可替代的方案要比从既定方案中选择重要得多。项目团队在拟定这些不同的备选方案时，为了使方案选择有意义，这些方案必须相互替代，互相排斥，而不能相互包容。如果某个方案的活动包容在另一个方案中，那么就失去了可以参加比较和选择的资格。
（4）决策方案的选择与比较。在实际进行项目团队有关方案的决策时，方案的拟定、比较和选择往往是交织在一起的。因为方案的拟定不是一次完成的，需要不断完善。要进行选择，首先要了解各种方案的优劣评价和比较。评价和比较应注意以下几个问题：
1）方案实施所需的条件是否具备。
2）方案实施能够给组织带来何种长期和短期利益。
3）方案实施中可能遇到的风险和失败的可能性。
根据以上比较，就能找出方案的差异和优劣，在此基础上即可进行方案选择。决策者在方案选择中，应处理好以下几方面的问题：
●要统筹兼顾；
●要注意反对意见；
●要有决断的魄力。
8.2.2 项目决策中的关键要素
决策的基本要素有决策者、决策对象、决策信息、决策的理论和方法以及决策结果。项目决策中的关键是项目经理（决策者）、项目信息系统（决策信息）和项目团队决策方法（决策的理论和方法）。
1.项目经理
决策者是决策系统主观能力的体现者，它可以是个人，也可以是集团决策机构。“决策都要与决策者自身发生必然的联系”，这是决策活动中一个最基本的事实。项目经理在项目决策体系中占有重要地位。因此要重视项目经理的选择，严格按照前文有关要求和方法选择项目经理。
2.项目信息系统
信息是反映客观事物规律的一些数据，项目信息是进行项目管理决策的依据，也是影响项目管理决策正确与否的主要因素之一。如果没有可靠的、充分的信息为依据，不可能做出正确的决策。例如，在工程项目管理中，在施工招投标中，发包方要对投标单位进行资质预审，以确定哪些单位适应招标工程的要求。为此，发包方必须了解各个承包单位的技术水平、财务实力和施工管理经验。
项目信息管理主要包括四项内容，即明确项目信息流程，建立项目信息编码系统，建立健全项目信息采集制度，利用高效的信息处理手段处理项目信息。项目信息有很多种，如进度控制信息、质量控制信息、成本控制信息、合同管理信息、项目外部信息等。在项目信息系统中要做好信息的收集、编码、整理、检索工作，为决策打下基础。在信息收集时要收集与项目有关各方面的信息，如项目计划信息、项目控制信息、项目利益相关者信息等。还要做好信息的沟通传递工作，保证项目信息系统的畅通。
3.项目团队决策方法
团队运作是否出色，取决于其集思广益的程度。团队的决策优劣，反映了决策过程的质量高低。团队领导者应当努力营造一个积极的氛围，将刻板和嫉妒排除在外，从而使人们在这一氛围中以智力相互竞争。领导者不应一开始就不停地阐述自己的观点，而必须给其他成员发表见解的机会，否则团队合作将无法实现。虽然在项目团队中达成共识需要时间，但可以大大提高后期的执行效率。经典的决策方法是，领导者耐心听取团队中每个成员的见解，然后再为整个团队做出决策。在决策过程中，一个真正的领导者应当起促进、激励和监督实施的作用，而不是进行控制。
几种常用的团队决策方法为：标准日程法、点式计划法、名义群体法、头脑风暴法、德尔菲法等。头脑风暴法详见第10章项目工具箱，这里介绍标准日程法、点式计划法和名义群体法。
（1）标准日程法。标准日程法分以下几步：
1）了解团队面临的问题，以何种方式解决为宜，何时是截止日期，确认现有资源。
2）分析问题的实质。问题在何处，团队要回答的问题到底是什么。
3）收集信息。在所有成员之间充分沟通，认真审视每条信息。
4）树立标准。理想的解决办法应包括哪些方面，解决办法中的哪些要点可被应用到次于最佳方案的可接受方案中，可能阻碍解决方案实施的法律、金融以及其他方面的限制有哪些。
5）产生备用方案。集思广益，为下一步做好准备。
6）将各个方案同标准相比较。
（2）点式计划法。点式计划法可以帮助大型团队尽快确定工作重点。首先，团队成员集思广益，并将各自的观点记录在纸上，公开张贴。然后，每位成员分别得到两条上面贴有2～3个即时贴的纸带。这两条纸带分别为两种颜色：一种代表最重要；另一种代表次要。成员走向贴出来的写有个人意见的纸张，按照自己的判断为那些观点加注重要记号。有的团队要求每位成员只能在一个观点前加贴一个记号，但有的则允许那些对某个观点十分重视的成员将自己所有的即时贴全贴上去。这些即时贴使团队能很容易地找出大家共同认可的工作重点是什么。
（3）名义群体法。该方法在决策制定过程中限制讨论，故称为名义群体法。与参加传统会议一样，团队成员必须出席，但他们是独立思考的。具体来说，它遵循以下步骤：
1）成员集合成一个团队，但在进行任何讨论之前，每个成员独立地写下他对问题的看法。
2）经过一段时间沉默后，每个成员将自己的想法提交给团队。然后一个接一个地向大家说明自己的想法，直到每个人的想法都表述完并记录下来为止（通常记在一张活动挂图或黑板上）。在所有的想法都记录下来之前不进行讨论。
3）成员们开始讨论，以便把每个想法搞清楚，并做出评价。
4）每个队员独立地把各种想法排出次序，最后的决策是综合排序最高的想法。
这种方法的主要优点在于，团队成员参加会议，但不限制每个人的独立思考，而传统的会议方式往往做不到这一点。
案例
案例一
项目经理张松最近因为项目工作，需要与相关的9个部门沟通，得到了几个部门的大力配合，但也体会到“部门墙”的根深蒂固。
他这次感受到的主要有三种形式：
（1）表面上积极，实际上得过且过。在预约中，A部门积极响应，在沟通时，他们也承诺积极配合，但是谈到具体实质工作时，特别是需要其部门做出些改变或工作时，他们就会找到各种听起来合理的理由。这类部门是在不影响自己利益的前提下还算配合，但是要想让他为了公司利益而多承担一点工作是很难办到的。在沟通中，项目组与A部门接洽感觉是满意的，A部门表现和承诺的都比较积极，但是后来项目组提出了改善方案，对公司整体明显有利，会大幅降低公司工作量，但会少许增加A部门工作量，A部门对此也是非常清楚的，但A部门轮番找各种理由排斥。这种情况的主要原因是完全从部门利益出发的。
（2）能推就推，能拖就拖。很多部门会以各种理由推托沟通，从内心就不愿了解更不愿配合部门外的非常规工作。项目组一周时间邀请B部门经理9次，但均遭到各种理由的婉言谢绝，结果一周后，他又出差了。项目组没办法，就要求与其召开电话会议，其没有办法，最终接受。但是效果难以达到预期目的。
（3）在沟通前就已经有了自己的立场，不予配合。很多部门在你还没开口前就把你定位为给其布置任务、寻找其工作漏洞的角色，所以一开始就抱着如何逃脱责任的心态。在再三邀请下，终于约定了C部门。在开始沟通时，虽然项目组首先明确了沟通目的和前提，但是C部门似乎一点没有理解，完全是从自己逃脱责任的角度出发。例如，项目组问其能否从财务的角度考虑分公司总经理应该关注哪些工作，“我们只管提供数据，分公司总经理应该做什么，那是你们的事情”。表面上大家似乎都没有什么错误，但是这种软性的不配合总让张松感觉劲用在了棉花上，影响项目的进度。
项目组只是一个松散的临时机构，作为项目经理张松并没有太多的权力去制约他们。请问，面对这些部门的不配合，张松该如何去做？
案例分析
在本案例中，作为项目经理张松应该考虑利益相关者的分析。就像本书提到的，可以将项目利益相关者进行分类，列出支持者和反对者。并可以进一步分析其立场和利益关系：
项目利益相关者对项目的预期是什么？
项目利益相关者有可能从项目中获得哪些收益？
项目利益相关者有哪些利益可能会与项目产生冲突？
项目利益相关者如何看待利益相关者名单中的其他人或组织？
可以看出A、B、C部门各有各的利益诉求，需要分别对待。比如，A部门从立场上是配合的，但不愿意承担更多对自己不利的工作量；B部门的立场是“从内心就不愿了解更不愿配合部门外的非常规工作”；C部门的立场是“抱着如何逃脱责任的心态”。因此从立场角度来分析，可以先以A部门作为突破口，并寻找公司利益和部门利益的共同点，以小步快跑的形式实现快速的项目起步，并及时向公司高层、部门领导、员工等层面采取对应的方式展示项目的成果，以获取他们的理解、认可和支持。
这样，一旦局面被打开，就可以趁势纵深发展，要求公司高层给予更多支持、部门领导给予更多配合。随着成果的展开，员工间也可以有更好的口碑。A部门局面打开后，就可以进一步考虑B部门和C部门，并且拿A部门的案例来说事，从而树立标杆效应，引发B部门和C部门的竞争意识，使项目的推进事半功倍。
案例二
李先生最近刚刚荣升为项目团队的项目经理，他信心百倍，带着分配给自己的十几个人一头扎进了项目的研发中。刚开始，整个团队踌躇满志，大家都把精力投入到研发工作中，可随着研发难度的增加和时间的推移，团队里出现了一些不和谐的情况。
每当李先生分配好工作，他就钻进自己的实验室进行工作。当他发现有的团队成员并未完全理解他的意图、未能及时跟上整个研发进程时，索性将下属的工作拿过来自己做。特别是最近，他开始发现大家好像不愿意和他一起探讨问题。有时探讨工作要么是应付，要么就是等自己拿主意，眼看团队组建有一段时间了，而研发工作进展却非常缓慢。
李先生在项目团队管理上到底走进了哪些误区呢？
案例分析
本案例中，李先生没有很好地摆正自己作为项目经理的角色。就像本书中提到，项目经理应该是一个“协调者”、“沟通者”、“会议召集人和主席”。
作为“协调者”，项目经理必须监督许多领域的工作，而每个领域都有自己的专家，这样项目经理必须具备把一项工作的许多组成部分整合为一个整体的能力。从这个意义上说，项目经理必须更擅长整合工作，而不是像案例中的李先生那样自己充当专家来分析工作。
作为“沟通者”，当项目团队的信息传播可能会误导其他方的信息，或信息传播与系统中的其他信息直接冲突的信息时，问题就产生了。项目经理有责任在这种沟通混乱中引入一些秩序。就像在本案例中所说，项目团队出现有的团队成员并未完全理解项目经理的意图、未能及时跟上整个研发进程。这时，作为项目经理不应该将下属的工作拿过来自己做，而是应该积极、真诚地与团队成员沟通，一起分析沟通中出现的问题，并想办法与团队成员一起解决这些问题。
作为“会议召集人和主席”，项目经理沟通最频繁的两个方面是向高级管理层汇报工作情况和向项目团队下指令。项目经理与项目团队的沟通常以项目团队会议的形式开展。因此，在本案例中，李先生想要有效解决沟通问题，需要高效地组织一些项目会议，并在会议上达成团队共识，并监督跟进团队成员的项目行动，而不是什么事情等李先生自己拿主意。
案例三
某房地产项目实施过程中，在项目沟通环节存在很多接口，建设单位的相关部门与个人都可以直接就项目事宜联系施工单位项目负责人，而项目负责人基于市场以及维护与建设单位关系的立场，在没有了解现场情况以及专业技术条件的情况下，便答应建设单位的要求，但实际上却完成不了，久而久之导致了项目经理的权威性丧失。而项目的技术负责人在不了解前后背景的情况下步步妥协，最终造成项目交付上的被动和业主对项目经理的不满。在这种情况下项目经理该怎样去理顺项目负责人在项目上与建设单位的接口关系？
案例分析
在本案例中，项目经理应该确定各团队成员的职责，即可以参照本书的方法，制定项目的工作职责矩阵，规定每个成员的职责和职权范围。就像本案例中所说的，必须规定项目负责人和技术负责人具备怎样的职权，并明确越过职权范围所带来的后果：项目负责人在对外答应建设单位的要求前必须先汇报给项目经理，只有项目经理才有最终的项目决策权，并可以将此体制告知建设单位。
在实际项目过程中，如果发现职权范围被打破，应立即采取惩罚措施以起到警戒作用，这样可以有效规避重复的错误发生，保护项目经理的权威性。
