公司自从成立以来，取得了很大的成绩。然后也存在很多的问题，特别是在项目管理方面，项目延期不能及时验收，尾款回收不来。直接影响公司的经济效益。公司应该高度重视项目管理的作用和地位，为此，我们为公司项目做整体规划与建议:

　　任何一个项目，从启动到收尾，从项目管理角度出发，可分为以下五个环节的关键步骤，并且中间环节应环环相扣：

　　以下是关于项目整个周期各阶段规范化的想法与建议。

　　项目阶段一：项目的立项和启动

　　项目的启动过程可以是项目的核准和确定，项目新阶段的范围，或者使暂停的项目工作继续进行。在这个过程中，我们应该明确项目授权人员，项目实施人员，项目目标和边界，总体概算和里程碑。

　　项目目标的制定可遵循SMART原则（此原则为2009年《项目管理》时的学习内容）：

        S（Simple）：简明的项目目标，具体的阶段结果和里程碑
        M（Merit）：项目进度的可考核性
        A（Authority）：责权到位的，包括客户方与我方的接口对应，实施方与开发方的责任对应
        R（Reasonable）：项目整体，乃至具体到各阶段，都是有理由且可实现的
        T（Time-defined）：（整体和阶段）有时限的

　　该阶段主要强调的是一个项目的整体原则，作为一个启动节点，只需要在资源调配上占用时间即可。

　　项目阶段二：项目计划阶段

　　项目的规划过程应定义项目的范围并使之完善成熟，识别发生于项目中的各项活动并为之安排进度，进而制定项目所涉及的各方面的管理计划。

　　在这个过程中，我们应该制定完整的项目计划书，为整个项目周期的进展做好先决条件以及规范约束。项目计划书应包含以下部分（可进过公司讨论确定最终的计划书模板）：

1。        项目背景，周期和项目目标；
2。        约束和假定；
3。        项目实施范围和实施方式；
4。        需求分析说明；
5。        工作分解结构，项目成果和交付物；
6。        任务角色配置，人员职责和项目组织结构；
7。        项目里程碑及明细工作结构；
8。        项目信息沟通和汇报关系；
9。        依赖关系，问题解决流程（包括部门内部和跨部门间的协调和冲突解决）;
10。        变更处理，变更范围和变更限制；
11。        风险分析和对策；
12。        质量要求和验收标准；
13。        培训，支持性工作；
14。        其它必要内容；

　　项目的计划阶段会对整个项目的进展，阶段性成果，客户满意度以及最终的验收产生直接的影响，是一个重要的阶段。可通过内部会议沟通讨论，确定符合我们的一个标准化的项目计划书模板，为整个项目以及项目参与方提供依据。

　　对于其中的工作分解和里程碑，我觉得这里已经涉及到了项目节点控制。可使用Office Project工具（附件为IBM对美邦的HER实施的Project范例，以作参考）对其进行规划，制订明确的项目计划。并在一定的周期阶段，进行实施人员，开发人员和部门负责人之间的meeting，以Project中的节点为依据，进行阶段性的评估。各阶段工期的制订，首先要确立工作内容是否存在依赖关系，若存在，则应有前导图与之对应。活动历时的制定，要衡量悲观时间，乐观时间和最可能的时间，以根据内容不同，制订出更合理的任务工期。

　　项目阶段三：项目实施与执行技巧

　　项目的执行过程为执行项目管理计划中确定的工作，交付项目阶段性成果给客户，管理项目的实施，实现项目需求和目标的过程。

　　在这部分工作中，承担着主要角色的是公司的实施人员。在实施过程中，最常用的是项目执行的“硬”技能（项目实施方法和标准化的流程；产品，专业和技术知识与技能等）和“软”技能（沟通协调和人际技巧；项目过程管理技巧；谈判技巧等）。在实施的过程中，会不可避免的出现很多违规范，个体化的需求，应从规范化的角度着手，告知流程改变所需的代价，甚至适当进行拖延，当然这里要有充分的识别。因为任何一个系统都应有其规范化的操作，不能因个体习惯而变，对于系统规范化在个体上的执行，应先僵化，再优化，再固化，使其改变操作习惯。

　　另外，实施过程中应该注意到以下几个关键点：

1。        与客户的对应一定要保持一对一的关系，不能打破这种单一对应，不能未经接口人认可执行任何变动；
2。        项目进展中，以计划阶段的Project管理文件为基准，工作内容中的待确认部分应提前于开发进度；
3。        阶段性结果或总结，要有邮件告知客户接口人确认，抄送项目相关人员及负责人；
4。        明确质量要求和验收标准，分辨客户的硬性需求和软性需求，并以此为原则指导日常工作；

　　另外，以展濠项目为例，展濠清单中分为三部分：合同，BUG，OTHER。随着合同内容的进展，客户开始更多的提出OTHER部分的内容，而将合同剩余内容优先级降低，这种情况会影响到项目的规划进度。个人有个建议：在制订合同时，我们可加入适当的条例。比如针对项目过程中提出的OTHER内容，若需要项目周期内完成的提供100H的支持，项目收尾后提供支持并解决的内容为160H。超出部分需另支付成本费用。任务所需时间由乙方制订并交由甲方确认（基本确认内容为任务需时是否认可；周期内完成还是作为验收后的后续支持处理）。

　　这样可以减少项目周期不断拖延的风险，具有一定的约束力。也可以避免当项目规划与客户要求发生冲突时，实施人员难以与其协调而产生磨擦。

　　项目阶段四：项目控制

　　项目控制的主要作用是监视和控制项目的启动，规划，执行和收发，评估实施结果，采取必要的纠正措施解决项目进程中出现的各种问题，以满足项目管理计划说明书所确定的绩效目标。

　　在这个过程中，要着重处理好项目变更和新需求这两种情况。若为需求变更，则应先确立该变改是因需求分析不明确造成的，还是由于客户原因变更。这种情况的解决方式我觉得应按以下步骤进行处理（以序号顺序优选）：

1。        站在客户角度分析：对客户谈影响，让客户了解风险；
2。        若有其它方式可解决该变更，以一些技巧说服客户使用；
3。        说服客户在保证项目进度的情况下，待项目完成后另立项目解决；
4。        变更项目计划，实施变更；

　　需求变更和新需求申请，应遵循以下流程：

　　项目阶段五：项目收结与验收

　　项目收尾与验收，是正式结束一个项目或阶段的所有活动，将完成的产品移交给客户。
在这个阶段开始之前，要为收尾工作做好计划和预算。实施人员应整理每个里程或阶段交于客户的书面文件（在实施阶段中对客户的各阶段的邮件，内容应有附件说明，以作验收时的书面文件），客户应对合同各细节进行确认，以立项细则为准进行全盘收尾，并最终签字完成验收。
公司内部应有完整的项目纪录和会议纪要，以此总结经验教训。

　　管理控制建议

　　我认为我们的管理控制可以逐步要求符合CMMI标准，并在一定的时间以后，产品申请通过CMMI标准，我想这也可以成为我们产品销售时的一个卖点。
对于我们的VSS管理，在原有的基础上，可扩充为以下List:

　　Remark:

Doc: 包括开发规范等一系列规范化说明，以及一些实用的资料等内容；
Pro。 Name: 各项目名称，各项目父目录结点；
Summary: 项目概述，包括项目计划书，Office Project等一系列项目相关文档；
Dev Code: 开发项目代码；
Design Documents : 项目设计文档。现在我们这部分是相对不够完善的，希望可以逐步完善补充各模块业务设计文档，并在其基础上，对每次更改进行纪录和修改。这样既规范了文档化管理，另外对人员流动，工作交接都会有好处；
Update History: 更新文件历史。存放命名格式为Update20100416的压缩文件，此文件为更新文件，文件，文件应包括update， bin， DB三个文件夹，并包括更新清单文档；该文件夹可开发实施人员权限，在更新结点日，项目负责人将文件放入该文件夹，供实施人员获取，确认更新清单内容并对客户进行更新。实施人员应定阶段向客户提供标准化的阶段性成果汇总文档，以邮件形式告知；
现阶段VSS上的DB文件夹，提供更新时需运行的SQL文；
Test & FAQ: 测试文档和FAQ文件，此权限可开放。供日常发现问题纪录。部门管理者应阶段性审核该目录下文件，并评估紧急程度，分配资源解决