项目管理中遇到问题的一些思考-神州巨龙项目管理和我

项目管理中遇到问题的一些思考

---神州巨龙项目管理和我

1.前言

担任项目管理工作两年的时间，执行了大大小小的项目，经历了一次次挫折和打击，当然付出了就必然会有收获，利用公司提供这个机会，我也想对这段时间遇到的问题、获得的经验做一个全面的总结，针对公司的项目执行现状提出一些建议，希望能够为公司的发展做一份贡献。

本来是想以一个明确的命题为中心来进行论述的，但发现要总结的问题实在太多，涵盖在我所掌握的项目管理知识中不同概念和项目管理过程不同阶段中，为了使文章具备更好的系统性和可读性，我将按照项目管理过程组的五个不同阶段，先提出问题再给出建议。

2.项目管理过程组五个阶段的具体分析

2.1项目启动阶段

问题描述：

项目经理被仓促任命，没有正规项目启动程序。合同签署完成后，没有召开相关部门的项目内部启动会议，更没有对项目进行前期风险分析环节，项目经理在不清楚项目目标、项目的主要矛盾及风险的情况下被仓促任命，往往还是被不合理的合同要求强加上了项目进度和成本的限制，即以不合理的项目进度，利用不合理的项目成本，完成不可能的项目目标。项目经理对项目三要素（项目范围、项目进度、项目成本）没有控制的权力，却承担着项目失败的责任。

提出建议：

1.合同签署阶段任命项目经理。由项目经理组织召开公司内部项目启动会

议，达到以下成果：

A.通过与其他相关部门领导沟通，根据项目的情况初步确认项目组成员，

并提出初步项目进度计划，经公司内部确认后归纳到《项目章程》中，在其后与客户的正式项目启动会上提交给客户方，并由双方签字确认。

B.通过与售前工程师、产品经理、研发经理的详细沟通，了解客户预期

的项目目标，制定项目的范围，分析项目主要矛盾及可能的项目风险。

在合同审核的过程中，项目经理将自己对项目的风险分析合理的转化

为项目实施的前提和要求，体现在合同和《项目章程》中，在其后与

客户的正式项目启动会上提交给客户方，由双方签字确认，最大可能

的降低项目执行过程中的风险。

2.对于中大型项目，必须组织客户领导层召开项目启动会议，在会议上由

项目经理介绍项目章程主要内容，包括：

A.确认双方项目负责人及项目团队，明确双方项目负责人在项目过程中

的主要责任和相应权力。

B.向客户方提交项目初步进度计划。

C.向客户方提交项目风险预案，让客户清楚为避免风险发生而应该提供

的必要协助工作。

2.2项目计划阶段

问题描述：

项目计划制定仓促，内容粗略，迫于客户的压力等，项目计划经常脱离实际，造成后期项目执行过程中，计划一再变更。

提出建议：

1.项目经理组织产品经理、研发经理召开项目计划讨论会，根据讨论结果

项目经理制定计划。项目计划应尽量将各阶段工作内容分解到最小，明

确每一工作包负责人，及其权力和应承担的责任。最终的项目计划应经

过产品经理、研发经理共同确认。

2.项目计划制定过程中，项目经理应积极与客户沟通，使客户了解并认可

项目计划，如果出现不可调和的矛盾，项目经理应及时向公司上层汇报，

积极寻求解决办法，避免问题拖延，造成项目后期执行阶段的雪崩效应。

2.3项目执行阶段

2.3.1 需求调研

a）项目调研不充分

问题描述：

由于项目调研的时间不足，调研人员业务经验不足，造成《需求说明书》内容粗略，不能有效届定项目范围，为后期项目实施埋下很大隐患。

提出建议：

1.由项目经理和产品经理共同确认调研计划，形成文档备案。

产品经理对《需求说明书》质量负责，对由于《需求说明书》内容粗

略、模糊而造成的后期项目执行过程中范围失控承担责任。

2.在《需求说明书》制定过程中应积极与客户负责人沟通，对于客户业

务中复杂流程部分，应尽量在《需求说明书》中设计、绘制出功能图

形界面，以便于客户直观的了解未来的产品模型，让客户在调研阶段

尽可能的提出自己的想法和意见，使我们的产品在设计阶段就得到了

完善。

b）制定的《需求说明书》不被客户重视。

问题描述：

在后期项目实施阶段，《需求说明书》不被客户承认，不能起到界定项目范围的目的。抛开前面提到的《需求说明书》内容粗略这一问题，另一方面主要原因是，在项目启动阶段没有让客户充分了解《需求说明书》的重要意义和作用，在项目计划中没有明确客户方负责人在需求调研阶段应承担的责任。

提出建议：

1.在项目启动阶段制定的《项目章程》内容中，明确描述《需求说明书》

的意义和项目执行阶段所起的作用，通过项目启动会上对《项目章程》

的签署，让客户方负责人充分了解并承认这一点。

2.在《项目计划》内容中，确定项目调研阶段客户方负责人，并明确要

求其在最终制定的《需求说明书》上签字确认。

2.3.2 产品设计、研发、内部测试阶段

没有明确的产品质量控制责任人，更没有明确的产品质量合格标准，

问题描述：

产品完成后，在上线投产之前，没有明确的标准去衡量产品的质量。

抛开上面提到的《需求说明书》范围模糊的问题，对于系统的运算性能和运行稳定性也没用明确的合格标准。没有明确的责任人对产品质量负责。

提出建议：

1.设立产品质量控制岗位，确定其权力和责任。

2.针对产品的运算性能和运行稳定性建立产品质量检测合格标准。

2.3.3 项目实施阶段

a）现场实施阶段，客户对产品不认可，拒绝上线，造成项目进度拖延，项目成本增加。

问题描述：

进入项目实施阶段，客户才第一次接触到完整的产品，经常发生客户对新系统不认可，不愿上线使用，造成项目进度拖延，项目成本增加。

提出建议：

由于项目存在渐进明细的特点，我们确实很难做到一次性达到客户要求。所以我建议在现场实施阶段前，增加产品客户端测试阶段。要求客户利用这一阶段，在项目范围内提出对系统的整改意见，经双方沟通后形成标准文档并签字确认，文档中应说明，系统在完成文档内容要求后则达到上线标准。

这样既给了客户一个提出意见、接受产品的时间，又能利用这段时间对系统做客户化修改，使其更加贴近用户，有利于推动后期的项目实施。

b）项目实施过程中，客户提出大量的需求修改意见，既降低了系统的稳定性，又影响了项目的进度，。

问题描述：

这里所说的大量需求修改意见，主要是指系统上线后，客户在使用阶段提出的意见。这也是我们以往项目中反复遇到的问题，对公司造成的影响也是最大的。我将在下面的建议中具体分析。

提出建议：

1.客户方没有明确对各部门提出的需求修改意见负责的相关责任人，该

责任人应该承担搜集、整理、评审、过滤、总结各部门提出的需求修改意见的责任，更重要的是统一上层领导与基层业务人员对项目目标的认识，协调各部门间由于业务流程引起的系统需求矛盾。建议在项目启动阶段的《项目章程》和《项目初步计划》中，明确描述该阶段客户方项目责任人以及他的权力和责任。在项目实施阶段，根据该文档要求，我方项目经理有权要求该阶段责任人对需求进行把控，避免需求泛滥。

2.在项目实施过程中，由于客户方组织结构发生变化或相关负责领导变

化，对系统的业务流程要求也发生了很大的变化，产生大量的修改需求。这应该属于可预测风险范畴，完全可以在《项目章程》中提出前提和假设，规避该风险。

3.系统数据的整合，业务流程的规范化对客户方基层业务人员的利益造

成了损害，他们通过不断提出修改意见和对新系统的消极态度来抵

制。针对这一情况，项目经理必须积极与客户领导层沟通，暴露出矛

盾的本质，争取领导层的支持。

c）由于客户的要求，项目实施人员现场时间被拖延，不能按计划返回，或临时因为会议等要求，需要相关人员到达现场，大大增加人工成本。

问题描述：

为了把问题分析清楚，我们把复杂的情况简单化，排除上面提到的需求泛滥，上线失败等引起的实施人员现场时间拖延的情况，这里我们

要说的仅仅是由于客户方的强烈意愿，我们为了保持良好的客户关系而

做出的牺牲行为。

提出建议：

在合同中明确描述现场实施的人天数（这一数字可以在合同签署过程中，项目经理通过相关部门内部沟通及以往的项目经验初步估算的时

间，并通过公司内部确认）及费用标准，并说明由于甲方原因造成超出

合同规定现场人天，我们将另外计费。在具体项目实施中出现以上情况，项目经理利用有效的文档依据向客户提出追加项目费用，并由客户签字。

2.4项目质量监控

问题描述：

项目的质量控制有别于产品的质量控制，它是对项目各阶段的进度、范围、成本的监控。而暴露在项目现状的主要问题是，没有一套完

整的，应对于项目各阶段的质量监控文档模板。使项目经理在与客户的

沟通过程中由于提不出有力的执行标准，而往往处于下风。例如各阶段

的交付物成果，里程碑报告等等必须的文档记录，客户都拒绝签字确认，

造成项目后期客户拖延或拒绝验收，或借此机会提出各种不合理要求。

提出建议：

项目管理部门形成一套完整的质量管理流程和文档标准，建立专职项目质量控制岗位，项目经理在项目实施过程中要求客户配合完成应有

的项目质量控制流程，签署相关文档。

2.5项目收尾

问题描述：

没有建立项目档案资料库，项目验收后，项目经理没有将这个项目过程中出现的新业务、遇到的风险、存在的最主要矛盾等等有价值的信

息总结成文档，存放于项目部门的《项目档案资料库》。使我们很多类

似的项目在执行过程中没能避开以往的弯路，规避以往的风险，做出合

理的预估，节约项目成本。

提出建议：

建立项目档案资料库，制定文档规格，要求项目经理在项目验收后，收集整理本次项目中有价值的经验总结到该文档中，在文档标签中标明

该项目的类型属性，便于以后项目执行者选择类似项目文档做为参考依

据，降低项目风险，减少项目成本。

3.总结

1.我们不能要求通过建立完整的项目管理体系标准，就能达到立竿见影的效

果，一定会有人对我以上提出建议的可操作性表示质疑，因为很难相信客户方会很快接受我们的这些流程上的正规化转变。我的观点是：不奢求一次项目就达到完全的规范化，但是要从这一刻开始，首先从公司内部做起，通过我们不断的努力和积极的客户沟通，来逐步引导客户配合我们走入正轨。

2.在我前面的建议中，很多内容都是在合同签署阶段和项目启动阶段来执行

的，这也符合项目管理的特性，我们在项目前期做的越多，那么项目后期就越顺利，风险就越少。

3.以上的总结仅仅出于项目管理过程这一层面，很多问题暴露在项目管理过

程中，但其根本原因却来自更深层的问题，也不可能通过项目管理的办法去解决，例如：项目准备时间仓促（前面提到很多建议都要建立在充足的时间基础上），项目成员经常变更（临阵换将是兵家大忌），项目人力资源匮乏。我的想法是，任何公司都会出现一些因特殊战略意义而产生的项目，这样的项目会出现时间紧迫，资源匮乏的情况，这也正是考验项目经理沟通、协调、管理能力的关键时刻。但如果这个公司每次的项目启动都缺少必要的环节，造成项目准备不足，为后期埋下隐患；更甚者，公司的市场

战略与资源实力出现极大矛盾，那么这考验的就不是项目管理人员的能

力，而是考验广大客户的容忍度，和公司苟延残喘的能力了。