在曾经做过的和主持过的实际项目实践过程中，经常会发现项目组个别人乃至项目组整体士气低落的现象，导致项目组成员工作效能大幅度降低。这种情形大部分是在项目进行期间发生了一些比较严重的风险的时候发生，有些是个别现象，与个别人本身有关，但是如果是大部分人都如此的话，肯定是项目出问题了。

　　一、人员士气下降直至低落的原因

　　个别人员士气下降，一般不会对整个项目造成致命影响，原因是多方面的，通常和个人的家庭生活、工作大环境有比较大的关系，例如：感情出现危机、个人对自己的具体工作缺乏兴趣等;或者由于一些个人的其它突发事件造成。

　　如果人员士气普遍下降，究其根本应该是项目本身出现问题了。能够产生这种现象说明项目已经不能够满足满足大部分人员当初的对它的愿望了，也就是说不能够很好的满足大家的个人利益了。经过比较仔细的分析，发现主要有以下几个原因：

　　第一、项目发生了比较大的风险

　　这些比较大的风险包括后期需求的大量变更、突然的技术难题出现乃至整个系统架构可能发生改变、项目在公司中的地位发生比较大的变化等。这些因素都会导致项目组人员感觉项目遥遥无期，自己再做下去只能会白白浪费时间甚至陷入无法自拔的泥潭;或者即使项目能够按期完成，对自己的未来发展也没有什么好处，甚至可能产生副作用。

　　第二、项目组的人文环境不好

　　整个项目组的人文气氛越来越差。比如个别人依靠一些特殊关系，虽然工作成绩平平，却可以通过其它的比较卑劣的手段获得比其它真正工作有成效的人更多的好处;流言四起，很多踏实肯干的员工却很受压抑。

　　二、提高士气的办法

　　对于个别现象，只能具体问题具体分析了，作为一个项目管理者，要创造良好的沟通气氛，及时发现存在个别人中的个别问题，并且能够帮助他尽快排除后顾之忧，能够尽快以良好的积极的心态投入工作。当然，一般项目(尤其是IT项目)不可能完全在规定的时间内、按规定的预算由规定的人员完成。所以，也要做好过程控制，尤其是项目中的重要文档的管理，这样保证其它的项目组成员能够尽快接手工作，这在整个项目中非常重要!

　　为了保证整个项目组人员士气高昂，不至于出现低落的情况，项目的管理者从项目初期建设团队的时候，就应该把这个问题提升到非常重要的位置上，以保证项目组整体较高的效率，这在一般的比较紧迫的项目中尤其重要。我们大概可以通过下面两种手段来保持项目组人员的士气。

　　方法一、防患于未然，注意初期项目团队的建设

　　项目管理者往往忽略项目初期的团队规划和建设，但是实际上，一个计划得很好的项目，如果没有强大的队伍实施的话，实际上就等于一个好的想法加上一些不相干的五颜六色的图表。所以，选择正确的项目成员，然后建立共同的愿望，对于项目成功来讲十分常重要的。假如在一个关键的岗位安排了一个不合适的人选，这个项目很可能会出师不利。当然在现有的人力资源中，不一定能顺利选到优秀的人才并组建成一只能战斗的队伍。我就曾经碰到这种最恶劣的情况：项目组只有主管有经验，别的成员都是刚刚毕业的大学生和劳务人员，那么主管的任务就不仅仅是管理，而且需要花费大量时间精力来培养这些新手，让他们能尽快进入预定的角色。

　　在组建项目团队的时候，第一件事情就是确定完成这些工作所需要的技能，然后根据这些既能要求挑选合适的项目组成员，做到知人善任，并且在列出项目本身所需要的技能时，不要忘记强调团队技能，毕竟选出来的这些人员要能够在一起工作。

　　同样重要的是建立一个沟通计划，这个计划知道整个项目的沟通，它在充当项目干系人的参考文件的同时，也归档了所有的沟通决定、进度计划等，它让包括团队成员、客户在内的每一个人都知道在发生着什么，而且能够确定谁需要什么样的信息。并且对如何对团队进行动态管理、什么会导致团队分裂、如何确保团队凝聚力这些问题造作打算。

　　另外从项目开始就在团队内树立能力为本、诚实、协作分享、融洽相处、合理竞争、分享胜利的良好的价值观。

　　这些事情做好以后，就为以后更好的排除员工士气低落、提升士气建立了坚实的基础。

　　方法二、及时发现解决，做好项目过程中人力资源管理，创造良好的沟通氛围

　　每个团队都会经历四个阶段：形成、混乱、规范、执行。在项目启动的准备活动完毕以后，如何在项目进程中做好人力资源管理，创造良好的沟通气氛，就成为能否让整个项目组保持士气的关键。要做好这件事情，应该注意做好以下几件事情：

　　·树立和维系合理的价值观

　　一个项目，尤其是比较复杂的IT项目，很少有单***匹马就能把项目全部搞定，往往需要团队来完成，那么团队的合作精神就显得尤为重要。为了使大家的思路统一，形成一个强有力的战斗团体，需要给大家树立共同的价值观，并且要时时注意很好的执行贯彻，通常应该给项目组成员树立能力为本、诚实、协作分享、融洽相处、合理竞争、分享胜利的良好的价值观。但是有一点要注意，这些价值观一般要符合整个企业的文化才能发挥更加显著的作用。

　　·与人力资源部门协作，做好人力资源管理

　　不可能要求项目经理都是全才，样样都行，但是在实际项目进程中，项目经理不但要“做事”还要学会“为人”。项目中最主要的问题就是团队活力和人际冲突。作为团队的关键人物，你同样需要知道怎样使团队成员的优势最大化、弱点最小化。很多项目发生比较大的风险通常与人为因素有关，尤其是有些比较核心的技术人员发生变动的时候，很可能会给项目组带来非常坏的影响，最严重的就是可能产生“雪崩”效应，一个倍受大家尊重的项目组核心人员的离去，很大程度上会涣散军心。为了能够使你的团队更加稳定有朝气，肯定要研究每个项目组成员，了解他们每个人企业利益和个人利益，让每个人都能有明确的目标，有的放矢，长期受益。这个管理人力资源的问题非常灵活复杂，最有效的办法就是经常与人力资源部门沟通，借助他们的经验会让你在处理人际问题的时候更加游刃有余。

　　·借助各种手段，创造良好的沟通环境

　　在一般人的眼里，技术人员都普遍比较孤傲，不好管理。主管不仅仅要掌握良好的沟通技巧，还要擅于感情交流，帮助解决项目组成员工作上和生活上的实际困难，使他们集中精力干好本职工作。良好的上下级和同级关系创造了融洽的工作气氛，尤其是有了这个良好的气氛以后，每个人不但清楚的知道自己工作的进展，还能够了解其他人和整个项目的进展，没有人甘心落后，项目成功的可能性大大增加。

　　创造这种沟通环境有很多办法。首先在技术层面上可以建立一个项目组内部的信息收集发布平台，使得项目干系人都能随时掌握自己关注的项目情况，这个平台利用好以后，还能够使大家共享很多技术信息，大大降低重复劳动造成的浪费。简单的沟通环境可以采用E_Mail系统，复杂一点的可以采用比较专业的工具，例如PVCS、微软PROJECT2000、IBM/Lotus QuickPlace等，这些优秀的工具结合起来，不但提供简单的信息收集发布功能，还能帮助项目组成员更好的协作。

　　其它的交流方式可以采用会议、头脑风暴等手段。这些会议可以是不定期的，也可以是定期的项目例会，通常项目例会是非常必要的，频率根据项目的不同而不同，一般一个星期左右为宜，这些沟通活动气氛要相对轻松，但是效率非常重要。

　　总而言之，建设好项目团队，保证项目成员的活力和士气而能够充分发挥每一个人的主管能动性是贯穿整个项目的复杂的管理活动，尤其是比较大一点的项目涉及人员比较多，人员之间的关系通常也比较复杂，这项工作就更显得重要了。

　　三、案例分析

　　问题

　　在以前的项目中，笔者曾经遇到过这样的事情：项目已经完成过半，项目的期限马上就要到了，但是我在日常绩效审核(绩效审核是反应项目组效率的非常客观直接的一种方式)中发现整个项目组制订的计划的执行越来越拖拉，原来一个星期内做好的事情，现在两个星期了还没有完成，这样下去，随时有项目失败的危险。

　　原因

　　发现这件事情的时候，我感觉到这是一件非常严重的事情必须很快处理，否则后果不堪设想，在请教了一些有经验的项目主管甚至人力资源主管以后，发现这种情况表面上是由以下两个原因造成的。

　　1.项目很可能要延期。当时项目组为了避免移交的时候产生太多风险，在项目正式移交前一个月给用户提交了一个beta版本，结果出乎意料：用户觉得我们其中两个比较大的模块与用户想象的大相径庭，不满意。这就意味着项目组要多花至少半个月时间来重新做，项目延期几乎是必然的。

　　2.个别人怠工。因为项目要延期，个别人在项目组里面担心自己的利益受损，在项目的比较关键的时刻怠工，以此作为筹码想让项目组满足他自己的一些私人利益，为了达到目的，曾经还与其它的相关成员进行了协商，这样很多项目组的成员也与他一道来对抗。

　　现在想起来，当时亏得对项目的进展每两天就检查一次，发现问题比较早，否则要是这个问题再晚发现一个星期，恐怕好多项目组成员已经离开了，项目肯定会失败。其实这个问题的本质原因有两个：第一，项目组的每一个人都担心项目失败，这样肯定会很大程度上影响个人利益，而并不是对项目组的其他人有看法。项目发生变动以后，项目主管并没有及时的把承包商和用户的真实用意与所有项目组成员及时沟通，导致大家纷纷猜测，并且很可能被一些别有用心的人利用了这种情绪。第二：这里面也的确有个别别有用心的人为因素，这个问题一定的及早处理，否则它会搅得整个项目组不得安宁。

　　解决方案

　　问题根源找到以后，首先得解决沟通的问题。这包括用户、承包商总体负责人、项目组成员之间的沟通，项目主管尽快找到最终用户，把用户的更改要求和我们的理解与用户进行了更加细致的沟通确认，让用户认识到我们非常在意他们的意愿，但是按照原来的方案更改的话，项目至少要延期半个月，其实这个风险对用户方的影响也很大，最终项目组与用户达成了折中的方案：项目组在第一次移交的时候，只是更改那些工作量不是非常大的但是不解决无法让用户方领到满意的问题，而对于其它的问题，都放在第一次移交一直到维护期结束这段时间来完成。其实，当时用户并没有想得非常多，只是想尽量尽早的把所有的工作提前做完，也并没有认真考虑到很多工作需要耗费大量的时间和精力而导致整个项目拖延而影响到他们自己，而这些工作大部分并不是那么要紧。经过第一次沟通以后，项目组成员对于项目的问题和期限有了更加清晰的认识，已经能够感觉到其实用户并非是故意难为项目组，项目即使延期，对项目整体的影响并不大。紧接着，项目主管找到了承包商的直接负责人，把项目需求变更可能导致延期的问题和原因进行了汇报，随即在项目例会中，承包商的直接负责人对项目组的整体成绩给予了肯定，对项目组的优秀人员给予了口头表彰，对个别的非常懈怠的员工也提出了一定的批评。终于，项目组内部的种种猜疑都基本上结束了，用户方和承包方对于项目的问题都有了比较清楚的认识，项目组的成员也都明白：项目虽然有困难，但是还是会成功结束的，每一个人的利益其实并不受什么影响。

　　沟通的问题解决以后，还是有个别涣散军心的人继续做一些对项目不利的事情。但是这个人在项目组中又比较重要，如果轻易的在项目组中去除，很多比较关键的工作就没有人负责了。为了避免这个人笼络更多的人，最后掌握更多的要害来要挟项目组而造成更坏的结果，当时在项目组中专门制定了“代码同行评审”的制度，每天抽出一点时间对于项目中比较共性的设计、代码进行相互评审，这也是一个相互学习的过程，对于表现比较好的个人记入绩效，予以表彰。这不但让每个人都有更多机会了解学习他人，也给每个人提供了更加好的展示自己的舞台，大大激发了大家学习进取的积极性。这样不但更好的保证设计与编码的一致性以及好的设计、代码的复用性，而且大大降低了个别人的变动对整个项目组的影响。然后项目组决定把涣散军心的人的地位抬高到系统设计师的地位，而把具体的工作不断的拆分给那些比较好学的其它人员手中。果然，当项目后期这个人离开的时候，项目组中的其它两个人已经可以接手他的工作了。

　　看来在项目管理中重视文档以及公共知识的管理，并且能有很好的沟通环境，可以大大降低项目进程中的人为风险，并且，有了更加客观的绩效标准以后，能够塑造出更合理的环境，更好的保证成员的积极性。