制定计划谨防错误
每个项目经理都知道，项目计划是项目得以顺利实施的根本依据，它的主要目标是要设定项目目标和方向，分配资源、预见问题以及确定一些激励措施。因此制定项目计划就成为所有项目经理必须监督完成甚至亲自完成的工作。然而正是这项工作给许多项目经理带来了灾难。他们在制定项目计划时，经常会出现各式各样的错误，有些错误对于项目来说常常是致命的。
其归纳起来引起错误的因素无外乎以下几点。
1、计划水平不统一
项目经理在制定计划时最常见的严重错误是选择了不一致的计划水平，结果计划脱离实际。按一个水平制定计划，我们或是选择范围很宽，但又不很详细的计划，或是选择非常详细的计划。这样就不用制定出通过整个项目达到目标的计划。项目经理们经常陷入后面的圈套里，按每项活动安排计划项目，他们发现一旦开始去做这个项目就会自动得到很多信息，这样有些活动不需要，但又需要另一些新的活动。项目经理陷入计划和再计划的旋涡里，没有时间从事项目管理，使计划失去了可靠性。
将很具体的计划向上层管理人员或用户汇报，是不实际的作法。上层管理人员和用户只是对如何达到项目目标感兴趣，他们从非常详细的项目活动中看不到项目目标。他们需要看到的是整个项目的概述，即里程碑计划，这个计划能够向他们表明项目进行的是否与目标一致。如果没有这个里程碑计划，他们就要求提供其他信息，以表明其采取的措施是否正确，项目的进行是否对准了目标。
另一方面，范围过宽，过于笼统的计划不能用于与项目团队成员的沟通。如果任务量过大，就难以此测定工程的进度。这样参加项目的人员难免会产生误解，而在工作中出错。所以项目经理至少需要制定两种计划，一个是里程碑计划，一个是项目活动计划。前一个计划是管理级的，后面的计划是任务级的。
2、不易使用的计划工具
第二个常见的错误与第一个有关。详细的计划与不易使用的计划工具相关。我们当中的很多人见过成千上万项活动的网络，这些工具妨碍了交流，而不是加强交流。
每一级用于说明计划和报告项目进度的，应是一页或不超过两页纸的报告。里程碑计划和有关的责任制定义应是两页纸。不能期望主管们将更多的内容包括进去，因为他们的时间有限。每个里程碑计划中相关的内容各项活动都写在一张纸上，使得项目人员很容易地看到他们应做的工作，而不需要去看冗长的与他无关的总体计划。
3、计划范围在心理上不健全
有这样一种趋势，很多项目经理都注重项目最后期限，即非常重视完工的这一日期。如果只关心将来某一点的时间，参加项目的成员们可能会感觉到，有大量的时间做这项工作，结果对项目优先考虑的程度过低。换句话说，人对时间产生了麻痹感，项目团队成员就会以低效的工作打发时间。项目经理应为完成工作制定明确的目标，确立短时间的水平计划，计划中确立的目标和活动应是在短时间内容易控制的，项目团队成员一旦努力就能做得到。
4、计划方式抑制创造力
第四个常见的错误与前三个有关系。如果计划水平、手段和范围很烦琐，项目团队成员在进行计划的讨论中就不会发挥其创造性。在计划中使用的语言应让所有的团队成员都能看明白，而不只是项目经理才能看得懂，应使用简练的语言，这点也是很重要的。
计划的制定都是以小组活动的形式，相关的人员一起工作，完成手中的任务。在执行任务当中，每个人都承担其工作职责。制定计划时应采用民主程序，而实施项目时应采用专制方式。但在实际中，情况恰恰相反：项目经理，甚至高层管理独自制定计划，然后传达给下面各组去执行。
5、对时间和造价的计划过于乐观
原因1：任意缩减计划
根据自己的主观意愿任意缩减计划，这是过于乐观，或缺乏现实所为。我们在制定一项新的项目计划时，通常是采用详细估计工作内容和项目造价的方式，并将曾有过的经验为依据用于进行项目规划，接着就是过于乐观地执行。可是主管们看着这些估算，认为太高，于是开始假设有可能使工作做得更快、更便宜。但是，如果采用估价的方式，你就应该相信他们，接受取得的结果，否则你所做的努力就要白费。另一种可以导致自我欺骗的情况是当项目必须“出售”给基层组织机构或外面的客户，为了使项目有吸引力，降低对工作内容和造价的估算，并说服自己，新的估算也能取得结果。但不幸的是，经常是达不到所要求的结果。
原因2：缺乏工作经验
第二个过于乐观的是低估达到程序变化所需要的时间。以经验为根据的数据可以用来估算各种技术活动所需要的时间。比如说我们知道浇灌1000m3混凝土的厂房基础需要多长时间，使其凝结需要多长时间，我们也可以知道写1000行COBOL节目平均要花一个程序编制人员多少时间。相反，我们不会知道变化一个程序需要多少时间，我们也不会知道发生变化将受到多少阻力，能采用什么样的变化模式，是否不需要很长时间？是否变化明显？是否需要好几个月才能完成变化？
再说，有些进度是根据公司里做出的某种决定而改变的，大部分情况下公司做决定时，往往忽略政治因素，因而少估了所需要的时间。其结果是提供给程序任务的时间和资源不够。时间过短使人们没有时间获取新的知识和转变态度。艰巨的任务没完成好，需要重做，实际上是浪费了资源。
对项目过于乐观是危险的。为了避免出现这种错误，那些要承担项目工作的人必须参加制定计划，负责执行这些计划的人必须抱有现实的态度。最重要的是要考虑过程变化，所需要的时间和资源，解冻、履行变化，然后再结冻组织机构，这些资源也必须包括在计划中。在资源的计划安排中高估了其能力和能量
这里常见的错误与上一个问题有关联，它起了一定的作用。对时间和造价的估算往往以理想的资源和理想的环境为依据。虽然这些工作人员有知识和经验，但他们能投入到项目中的时间并不是那么理想。重要的一点是制定计划时一定要考虑其限定因素。
6、项目日期安排忽略了浪费的时间
项目经理们在计划制定上都会不自觉地有这样一个趋势，即好像外面的世界不存在。但现实生活中人会生病，会去度假，会去参加课程学习和各种研讨会，而这些因素会影响他们对的工作量的完成。根据我们的经验，由于上述原因会使项目团队成员的工作效率降低20%—30%。
7、计划中忽略了各种活动
由于每个项目都是独一无二的，项目经理们过去的经验不能事先告诉他们都有哪些活动。如果他们将所有的活动都列入清单之内，许多人就试图在制定计划时就搞得过于详细，而有些事情还是会被忘记。以前有过类似项目活动的清单也可借鉴，但要注意的是，由于没有两个完全一样的项目，在使用这些清单时就一定要慎重。
制定项目计划是出现错误往往是致命的，它会在项目开始实施后给项目经理带来极大的困扰，似乎一切都不能按照计划进行似的。于是才总是出现这样的一幕：项目经理们每天忙于不停的修改计划，修改项目的实施方法，最终所有人全都无所适从。由此可见，项目经理们与其在项目实施开始后抓瞎，倒不如在制定项目计划时多下功夫，把一切可能出现的情况与意外都尽量考虑在内，最大限度地避免上述的这些错误的发生。
实施控制并非轻而易举
制定出一个好的计划是项目经理的第一步，组织项目成员的活动是第二步。而项目管理就是用预先制定好的计划来指导项目成员，在小组中提供合作性的领导，这就是我们所说的项目控制。
项目控制就是跟踪实际工作进程并将其与计划安排进程进行比较，发现问题，及时纠正，以保证项目计划的有效实施。项目不可能一帆风顺，避免导致失败的问题才是唯一的出路。项目控制是一项重要的技能，它同时也是一项问题解决的技能。项目经理的控制职责主要是全面对项目进行监控，了解项目实际进展状况，及时发现偏差，并采取措施加以纠正，使项目工作处于受控状态。项目控制是一个项目经理的重要部分，控制内容包括：就与计划有关的项目进度做出报告；分析项目进展和计划之间的差异；采取措施限制住计划和进展之间的差异。
对于项目经理来说，正确的项目控制方法包括四个基本的步骤。它们分别是掌握最新情况；分析冲击；处理偏差和公布修改方案。
1、掌握最新情况
控制离不开信息，掌握最新情况的重点是，收集评价项目运作状况所必须的信息，然后将这些信息进行必要的公布和共享。
2、分析冲击
当收集到足够的信息时，接着需要项目经理应该进行以下三步工作：首先是比较，将计划结果与实际结果相比较，以便暴露偏差；其次确定原因，当发现问题的确存在时，要仔细找出其原因；最后是制作分析报告，结合上述情况，要准备分析和预测报告，推断未来一段时间内的发展趋势，其中要特别强调完成日期、完成效果和成本。
3、处理偏差
如果通过上述步骤，项目经理如果发现情况良好或者一切正常，就不需要采取进一步行动；如果比较下来情况不佳，就需要采取整改或预防性措施了。
总体来说，有三种常用的方法：
第一，不采取行动。这是因为问题不大，对项目的冲击很小，没有必要采取措施；或者是因为问题尚未明朗，还无法采取可行的措施。
第二，修改计划。查验各项计划，在预定进度、人员、成本等内容上适当修改，以容纳问题。
第三，调整计划。开始探讨变动的可能性，或许是增加进度表的时间，或者增加人员、增加经费等等。
同时，有几个重要的原则项目经理要时刻记在心中：
首先，不要反应过度。这也就是说，不要化小为大，过分张扬。出现问题很正常，不用大惊小怪，满城风雨。但同时记得，不要忽视问题，问题一般也不会自行消失，最后总是要解决它，但有时可以适当等待，等问题有明显倾向后再采取断然措施。
其次，“检查后再修改”。这是基本的程序，也是为了确保有效性的重要环节。对问题的确认是否正确无误？所采取的措施是否合适？会不会因设计不当而导致新问题的产生？有关各方是否已达成共识？这些问题要心中有数，才不会“一波未平，一波又起”。
4、公布修改方案
公布修改后的计划与当初开始实施时公布原始计划的意义是一样的，并应发给同样的一些人。否则万一在哪一环节出现“我不知道！”之类的摩擦，肯定会让项目经理痛苦不堪。
让我们来看看下面的这个案例，从中你也许会体会到些什么。
一天，WAQ公司的总经理把托马斯叫进办公室，告诉他与他手下的小组要马上接手一个新的项目，这个项目已经经过客户和公司两方高层的确认了，最后要求完成的时间是2个月，也就是在12月29日之前必须完成，合同已经签署了。然后，总经理把客户传真过来的需求交给了托马斯。
托马斯仔细地浏览了客户的需求，发现其中的很大一部分公司都已经有现成的程序可以满足。而只有构建一个更好的桌面系统，把应用集成到一个框架中是他们急需要做的。于是托马斯首先询问了客户对界面的需求，他们的回答是：需要简洁明快的桌面风格，并且Email给托马斯一张图片。值得庆幸的是，公司原有的界面就是这种风格，并不需要太大的修改。托马斯觉得这个项目问题不大，有望在2个月内完成。
在项目开始前，托马斯大概做了一下近期的计划，首先它的项目小组要对桌面系统和用户交互方面进行一次深入的讨论，拿出一个让客户满意的方案；然后考虑采用哪些技术，并进行软件设计；最终进行编码实现。
尽管时间紧迫，托马斯还是准备在3~4周之内，拿出用户交互设计的方案。这段时间中，他的小组不停地在开讨论会，大家提出了很多好的见解和近乎疯狂的想法，期间托马斯还参考了一些资料，讨论了要进行集成的应用程序，以及构建界面系统的方案。最终，托马斯制定了项目的计划和时间的安排。
但是托马斯马上就发现，他的计划与现实有一些差距，首先他需要5个人，然而他的项目小组算上他仅仅只有4个，另外他还需要6周时间，可现在离客户最后的时间底线只有5周了。更糟糕的是，托马斯现在的人手已经分配到各个项目中去了。托马斯在项目讨论会上，向事业部经理提出了他的资源和时间问题。托马斯得到的回复是，时间不能改变了，感恩节加班，这样就有6周时间了；然后，公司同意把托马斯的一个小组成员史蒂夫从另外一个周期较长的项目调到托马斯的这个项目中来。
最终，托马斯的项目小组由5人组成，包括一个兼职的学生John，史蒂夫、达考特、劳拉和托马斯自己。确定了人员后，托马斯的项目小组开始工作了。
首先他们考查了这些功能的实现技术，大体做了设计的工作，用了整整1周的时间。紧接着，感恩节到了，John、史蒂夫和托马斯在这期间加班了一周，期间他们在公司吃住，每天都是通宵工作，然后白天睡觉，下午还一起去打一小时台球。很快的，假期结束后，他们各自的工作已经基本完成了。
这时突然，用户由于参加了一次展会，对他们原先提出的界面设计有了新的想法，并发回给托马斯的小组展会上的一些图片。更糟糕的是，公司负责这个项目的销售人员在没有和托马斯协商的情况下便对客户做出了承诺。这个看上去十分简单的改动，实际上并不只是换换图片而已，它需要在桌面配置管理部分进行不小的代码改动。托马斯想提出异议，但是已经为时已晚了。好吧，重新进行设计和编码，好在由于原来的设计灵活度比较大，没有伤筋动骨。但是，返工还是花了几天时间。
这时，意料之外的情况再次发生了，John由于导师布置的课题进行了调整，现在必须要花加倍的时间在他的毕业设计上了，只有晚上有几个小时可以过来、周六日可以工作。
同时，项目进入整合阶段了。首先，托马斯在整合中发现史蒂夫和John没有充分考虑到他们两个人的工作是将会整合到同一个进程中的，他们原本设计的基础是两段程序并行的，于是，托马斯不得不花了3天的时间，把两个人的工作成果重新进行了组织，终于把它们整合到了一起。但是，这次整合让整个系统变得非常不稳定，经常发生运行错误，Bug是随机出现的而且还无法确定其发生的地点。这个Bug极大的困扰了托马斯的小组，他们整整花了一天一夜24小时连续调试和检查代码终于发现了错误。不幸的是，在John准备备份的时候，由于连续工作精神恍惚，错误的删除了新修改的代码，这不得不又花费了项目小组3个小时以上的时间，在最近一次备份的基础上重新修改并验证。
在这个Bug解决之后，托马斯希望把整个系统提交系统测试部门进行测试。但是，测试部门拒绝了他们单一应用测试的请求，理由是他们只接受产品的测试，这个单一应用无法进行系统测试，而且这个测试应该由我们自己完成。这使托马斯火冒三丈，坚持认为系统测试部门应该进行单一程序的测试，这样及时发现Bug有助于他的小组节省开发的时间。最终，大家不欢而散。
这期间，公司合作伙伴与之相配合的相关程序也早就应该就位了。但是，不幸的是由于合作伙伴所在的公司发生了并购，交付的时间大大的被推迟了。并且在拿到程序后，托马斯发现这些程序在测试板上经常死机，他不得不每天保持和合作公司的联络来解决这一问题。
当完成了这一切以后，托马斯发现时间已经是12月29日了，他不得不告诉事业部经理，工作已经完成了99%，只差整合了。整合的时候，也发生了一些意外情况：由于系统不同，有的脚本需要调整；程序运行过慢，这跟系统资源紧张有很大的关系，最后不得不取消了这段程序……
转眼1月4日了，整合工作仍然没有最终完成，托马斯与他的小组大量地设想权益之计设法让系统基本运行正常。最终，在1月12日，他们把一个伤痕累累的系统提交给了系统测试部门。
系统测试部门进行了为期4天的测试，然后托马斯的小组又用了两天时间对所发现的Bug做了必要的修正，在1月21日把产品提交给用户了。而托马斯惊奇的发现，原来客户对于不能在12月29日交付的反应并不强烈，这让他们开始怀疑6月5日的DeadLine是如何得来的？
最后的结果是，客户在收到产品之后不久，就放弃了这个产品……
从上面的案例中，我们可以看到一个项目经理在项目实施过程中对突发事件糟糕的控制，他几乎完全没有预料到所发生的每一件事，在问题出现后早已经把项目计划抛在了脑后，对于托马斯来说，这真是犹如恶梦的一段经历啊。
由此我们也能够了解到，项目控制对于整个项目的顺利进行来说是多么的重要，项目经理在这一过程中是不允许犯任何错误的。然而在现实中，许多项目经理都会像托马斯那样感到无所适从，在项目控制方面他们经常会犯的错误有：
＊项目经理和他的小组不了解控制的目的，他们不了解监督和控制之间的差异。
＊计划和项目进度报告不一致。
＊项目经理和项目成员之间的交流，没有合适的定义。
＊项目经理只有职责，而没有正式的权力。
1、项目控制目的
许多项目经理不了解项目控制的目的，其实项目控制目的并不是挥舞棍棒来处分或惩罚有过失者。而是监督工作进度，及时采取正确的措施。我们必须强调的一点是控制不仅仅是监督和报告工作进度。许多项目中的控制仅意为给项目经理就当前状况写出几篇类似的文章，或用图表画线表示出项目进展了多少。很可能项目经理只是看看这些报告，然后将这些报告存档，这就是报告的最后归宿。因为有人让你写这些报告，报告就成了你的日常工作，而不是一项你很认真对待的活动。控制的严肃性在于对计划和计划实施的偏离后果进行评估。
2、一致的计划和进度报告
为了实施项目控制，你所制定的计划应支持项目控制。我们建议报告应该写在计划里，这样写出报告，也同时就是对计划进行了修改。但一般都不会是这样的，因为在制定计划的结构中，项目控制总是以巨大的行政负担的方式出现。这些计划总是长篇大论，但根本不包括可以有效地分析偏差的资料。传统的例子有大量的、五彩缤纷的带有成千上万项活动的网络工作，有时会出现在主管的办公室里。项目控制得不到支持，其原因如下：
＊难以判断在项目进行过程中一项活动延期完成的影响。
＊不可能测定出每个项目的生产率。
＊质量评定只能在最后一项活动完成之后才能进行，而这时又太迟了。
理想的计划项目包括项目控制，向项目经理提供信息，使他们能够行使控制权。
3、正规的交流
很多项目经理容易犯的错误是否去认真地观查其工作人员的工作进展情况，他们了解工作人员的工作进展只是在咖啡机周围与他们交谈，但这种非系统的、非正式的监督是不够的，而且也得不到重视。
在一个项目中，采用非正式对话有益无害，这种讨论方式有助于创造式的交流。但如果是进行项目控制，最有效的方法还是每隔一段时间里采用正式交换意见的形式。应该固定联系时间采用预先确定的形式。如果不这样的话，工作人员就会不遵重工作进展的检查，这样项目控制就失去了作用。
4、具有权力的责任制
尽管项目经理上述几个方面都做得不错，但如果项目经理没有与向他提供资源的基层组织同等的权力，他就不能控制这个项目。如果一个项目成员在项目经理和他的部门主管同时都、需要他时，这就发生了冲突，他应优先考虑谁？他肯定会选择他的部门主管，因为他的部门主管支付他工资，项目完成之后他还是得为他的部门主管工作。
项目经理最终要为取得项目目标而负责，因此，必须赋予其相当的权力。具有领导魅力的项目经理将能从他的个性中获取一些权力，我们称之为个人才能。但是大部分的项目都是一般人来管理的，他们缺乏自然权力，所以必须赋予项目经理地位上的权力，这样控制项目的权力影响必定会反映在项目的组织机构中。
谨防在项目执行中摔跟头
我们已经说明了在确定一个项目时，项目经理有可能犯的错误，接着是在项目计划、项目组织和项目控制方面常见的错误。如果项目经理在具体的管理工作上失败了，就是专业能力再好也不足以保证项目能够成功。同样，如果没有专业能力，不管提供多少行政管理上的支持，也无济于事。要想项目成功，二者缺一不可。
为结束这场关于项目中常见错误的讨论，我们还是一起考虑在下列项目工作中出现的问题。这些问题对特殊的专业原则来说，有其独特之处。这些问题是：
＊低估各种资源协调工作的复杂性。
＊改变计划和计划书，使项目失去控制。
＊项目活动还没有完成，还没有发给证书，就开始了其他的活动。
＊时间、造价和质量上的目标不平衡。
1、各种资源的配合
一个项目的特性就是它需要各种各样的资源，这就会导致在项目的执行过程中，各个资源相互配合上出现一系列的问题。
（1）不相识人之间的合作
许多人低估了将各种人放在一起工作的难度，如果他们以前没有一起工作过，情况会更复杂。由于主管认为这并不重要，因此不去投入时间和精力去创造这种合作。这也许是由于项目经理缺乏这方面的经验，他有可能不知道如何加强这种合作，也有可能错误地相信项目成员们习惯于一起工作。
（2）不同的工作习惯和程序
项目成员不可能都有同样的工作习惯和程序，工作文件的风格也不同，这会削弱他们之间的合作力，减少项目成员利用过去各自潜在的工作经验互补性的优势。这也会降低项目经理的灵活性，这是因为难以将从事这项工作的人转向另一项工作。再说介绍新的工作人员不容易，因为他们被培训成会各项工作程序的人。明确合作的原则，建立共同规定和工作程序使工作在这个项目上的人们一同遵守。
（3）技术问题的复杂性
项目小组实际上是代表将来用户的。用户和项目经理的不同经验会使合作变得更难。项目经理们采用的特有手段完成这种协作，采用未来用户对其陌生的项目目标表达方式，或用户们不懂的专门术语，会影响彼此沟通和交流。项目经理们应该用用户能听懂的语言去表示项目，但又要准确简明地保留住项目的真正意义。
2、项目目的发生了不可控制的变化
在项目进行的过程中，不可避免地会发生一些变化，但是失去了控制的变化能够将一个项目扼杀，因为项目成员们卷入了无休止的计划和再计划的旋涡之中。必须控制项目上的变化，对于计划中需要变化的内容，只有作出特别说明才能写入计划里。
3、项目中的各项活动没有按顺序开始
如果一个项目小组的人数被固定住，有时有些成员就会被闲置。为了防止因为闲置，上司会对他们不满意，项目经理发现他们为了使自己手中有事干，而不置于再闲置，他们开始不按顺序要求在前一项工作还未完成时，就开始提前操作后面的工作。
如果后做的工作不符合要求，前面做的工作又需要重做，项目的实施过程就会失去控制。所以，项目中的所有工作应该按顺序去完成。
4、时间造价和质量与目标要求不符
这是由以下两个原因造成的。
原因1：追求完美
技术工作就其本身，不应只有一个目标，工作应以达到包括时间和造价的项目目标为准。项目经理们往往抱怨，他们没有充足的时间去寻求最佳方案。要寻求最佳方案，必须有一定的专业威望，在这种情况下，时间和造价的目标就处于第二位了。有时，我们应该接受并不十全十美，但考虑较全面的方案，它也兼顾了时间和造价。项目经理应该有权在最佳方案、时间和造价这几个因素中找出平衡点。而且最终用户应该做出是接受低价低质还是高价高质的选择。
原因2：不合格的质量控制
上面谈了关于非完美但较完善的方案，时间和造价之间的选择，为了判断这些非完美的方案是否完善合格，项目经理应该计划和控制质量，这样就应该为控制整个项目而制定一个里程碑计划。
这样只要项目最终没出现什么问题，我们就不会没有必要总去进行质量分析，但是一旦出现问题，付出的代价将会很大。
把错误扼杀在摇篮中
从过去的经验中，我们会思考并找到导致一个项目失败的一些原因。但是如果认为一定有保证项目成功的神秘偏方，这是危险的。有些项目失败，并不是主要原因造成的，有可能在计划清单里，没有详细注明，但是如果想要项目成功的把握性大一些，避免出现上述问题还是可以找到解决的办法的。
在这里我们引入GDMP（直接目标项目管理）的概念，它是一种技术。这种技术提供了避免出现这些问题的方法和手段。我们也曾建议过如何去做，才能避免出现错误，总结了这些建议，这可以作为好的项目管理和手段的要求计划书。
下面表明了应该怎样进行项目管理，如何根据要求做计划书，衡量直接目标项目管理的效果。
项目工作中能避免出现问题的主要因素
＊项目工作应该是一项对基层组织机构也很重要的任务，整个经营计划和项目目标紧密相关。
＊基层组织机构应有项目工作的原则和政策。
＊项目方式和手段必须能够促使这些参加项目的人们为指定的项目目标奉献时间，取得项目应有的结果。
＊项目方式和手段必须能够促使这些参加项目的人们集中精力投入到项目的混合目标之中，这个混合目标包括与项目有关的人、系统(技术方面)和组织机构。
＊项目计划的制订至少要考虑两级以上。
＊必须制定短期和可控制的中间目标。
＊项计划应清楚地写在一张标准页的纸上。
＊这些制定计划的人必须清楚地认识到，项目结果的好坏直接影响到他们自己的切身利益。
＊必须清楚这样一个事实，即改变中间程序需要时间。
＊必须清楚什么是控制，控制在项目工作中是多么重要。
＊计划的制定必须注意它即能促进实施又能方便控制。
＊给予项目团对成员与他的项目有关的基层组织的权力。
＊建立一套报告程序
＊必须清楚，一个项目可以有若干种不同的组织方式。
＊个项目中各部门的责任范围必须表明清楚。
＊项目中所需的各种资源必须在相关的协议中写清。
＊高度激发项目成员的积极性。
＊选择合适的人才专攻某一项目。
＊从事具体工作为项目的合作创造良好的条件。
—项目工作中选用统一的方式，这样便于专家和用户之间的沟通。
—对项目的目的和目标在经过谨慎考虑之后，再做改变。
—整个项目中必须有质量控制。
聚合中文网 阅读好时光 www.juhezwn.com
小提示:漏章、缺章、错字过多试试导航栏右上角的源