当前位置：首页 > 实用文档 > 其他范文> 项目管理流程五步骤

项目管理流程五步骤

时间：2022-05-06 11:33:18 其他范文收藏本文下载本文

项目管理流程五步骤(（精选8篇））由网友“鹅瘪”投稿提供，以下是小编精心整理的项目管理流程五步骤，供大家参考借鉴，希望可以帮助到有需要的朋友。

项目管理流程五步骤

篇1：如何策划项目流程和步骤

一、概述

项目策划的目的建立并维护用以定义项目活动的计划。

项目策划阶段的主要活动包括：确定项目目标和范围；定义项目阶段、里程碑；估算项目规模、成本、时间、资源；建立项目组织结构；项目工作结构分解；识别项目风险；制定项目综合计划。项目计划是提供执行及控制项目活动的基础，以完成对项目客户的承诺。

项目策划一般是在需求明确后制定的，项目策划是对项目进行全面的策划它的输出就是“项目综合计划”。

在笔者经历或者监管的很多项目中，发现一个规律掌握项目计划的项目经理在项目过程中管理会比较到位，而不掌握项目计划或者项目计划不到位的项目中我们的项目往往出现很多故事，项目管理往往是越管越乱。项目计划是帮组我们项目经理去理清项目的过程和各组织活动之间的关系，只有搞清楚这些，我们的项目才能被管理起来，否则我们不能谈项目管理，只能说我们在管着项目，但是还没有理清楚，结果则是什么也没有管到位。

二、确定项目范围

项目范围包括项目需求范围和项目工作范围，项目工作范围是为实现项目目标并使客户满意（有效地完成项目目标）而必须做的所有工作，它包括项目的最终产品或服务以及实现该产品或服务所需要做的各项具体工作；在《软件需求开发》中我已经说过了项目目标和需求范围的确认，本节内容是确认项目的工作范围。

项目工作范围的确定是为了有效地完成项目目标而界定的主要工作内容的活动，会将项目的可交付成果划分为可控的、易于管理的单元模块。

1、确定客户提供的工作产品

在确定项目范围的前，我们要与客户确认由客户提供的工作产品或资源，以及这些工作产品或资源的标准、提供时间、方式等信息。通过确认客户提供的工作产品我们可以界定项目中的哪部分工作是由客户完成，哪部分工作将要由项目组去实现。

2、确定交付给客户的工作产品

在确定项目范围的同时我们也要确认交付给客户的工作产品及资源，以及这些工作产品或资源的标准、交付时间、方式等信息。以确定该项目是否有额外的工作任务。

3、确定项目的工作范围

在项目中工作范围与软件生存阶段是基本对应的，项目工作范围可以理解为我们承担的主要开发阶段，一般的开发阶段有：概要设计、详细设计、编码、单元测试、产品集成、系统测试、验收交付、维护。

4、确定项目的质量目标

与客户确定我们软件需要达到的质量目标，在客户提出的质量目标中往往只有一些非功能需求的目标，大多与技术相关，而在项目开发过程中的质量目标可能客户不是很关心，涉及过程的质量目标大多也只有交付后的缺陷率。这个时候我们要结合公司的过程能力以及客户可能提出的质量目标进行能力匹配，并制定出项目的质量目标。过程能力匹配与分析以后单独进行说明。过程能力即项目组执行项目活动的子过程能力。如，代码生产率（单位：KSL/人月），单元测试bug检出（个/KSL）等，这些过程能力都有一个中线，3σ上线以及3σ下线，过程能力是根据公司历史项目的数据依据“过程标准差”的方法统计分析得出。

5、建立WBS工作包

依据项目需求范围和项目工作范围，把需求作为横坐标工作阶段作为纵坐标，我们可以得到一个项目的基本任务的工作包，我们一般把这类工作包作为WBS工作包。在WBS中我们也要包含任务返工、项目管理类和项目支持类的工作包。

三、定义项目阶段、里程碑

我们定义了项目的目标和范围，并建立了WBS的工作包。那么我们如何实现项目的目标，首先我们应该是分解项目目标，一般我们把它分解为里程碑目标或阶段目标。

1、确定项目的生命周期模型

项目生命周期各阶段的定义，依赖于需求的范围，项目资源的估计，以及项目的本质。项目一般都包含多个阶段。软件项目阶段的决定，通常包含软体开发模式的选择与改进，以说明项目活动间的相互关系与适当次序。生命周期模型的一般有瀑布、原型＋瀑布、迭代、增量模型。

2、选择生命周期模型的准则

A)瀑布模型

适用于新的有较多用户的产品、平台/中间件开发项目，或者是用户对开发过程有严格要求的工程定制项目。充分理解用户需求,且需求是确定不变的。用户有一定的能力，对需求的表述是确切的。所有过程工作产品的控制基线，需要有可见度和可靠性。

B)原型＋瀑布模型

新领域的应用项目的开发：如企业应用系统开发项目等。项目包含一种新技术，例：新硬件、新的系统架构等。需求不很清楚。存在关于性能、可靠性和可行性的主要的、未解决的问题。用户界面对系统成功是很关键的，但不很清楚。

C)迭代模型

新领域、新技术的研发项目。规模较大的项目或产品。需求的清晰度低，且需要进一步的调查。技术或体系结构方面的知识匮乏。

3、定义项目的阶段

我们依据以确定的生命周期模型定义项目阶段，在定义阶段的时候需要明确每个阶段的输入、输入、目标及主要工作。

定义项目阶段主要是对输入、输出以及工作量、规模、质量目标偏差控制范围的定义，我们一般定义输入工作产品的标准、要达到的质量目标，输出工作产品的标准，要达到的质量目标。阶段工作产品的工作量、规模以及质量目标的偏差控制范围，每个步骤的细节执行方式及这些细节活动的检查方法。如果阶段和里程碑时间点一致，可以与里程碑一起判断阶段目标的达成。

4、定义项目的里程碑

在瀑布模型和增量模型的阶段就是我们说的需求开发、概要设计、详细设计、编码、单元测试、产品集成、系统测试、验收交付、维护这些阶段。一般瀑布模型的里程碑设立根据项目规模和特点为需求、设计、编码＋单元测试、产品集成＋系统测试、交付；增量模型一般里程碑是每次可交付产品为一个里程碑，如果规模很大可以按照瀑布模型设立子里程碑。

迭代模型的里程碑一般是每次迭代就是一个里程碑。

我们上面说了里程碑定义的准则，简单理解里程碑可以作为是项目的一个可交付并能给项目工作承上启下的点，所以里程的目标、准入和准出的定义，是在项目实施中对项目能否达成项目目标的检查依据。

里程碑的准入准则，就是输入里程碑的工作产品、资源是否满足该里程碑的要求。我们就要定义输入工作产品标准、要达到的质量目标。而里程碑的准出不仅仅是工作产品的标准和达到的质量目标。还要判断这个里程的进度、成本、工作量、规模的偏差以及项目的变更是否在控制范围内。

5、定义项目的过程

确定项目执行过程中的子活动级活动的顺序，并给出这些活动的输出。在大部分公司都有一个项目执行过程的全集，项目在开始的时候依据项目的工作范围缺确定项目要执行的子过程以及输出的工作产品，在CMMI中把这个活动叫做裁剪项目过程定义，在这里我们要说明的是“裁剪”不是“裁减”，在对项目过程裁剪的'时候我们不是简单地考虑做或者不做，应该在不做的时候考虑是合并还是用其他的替代方法来执行。

四、估算项目规模、成本、时间、资源

对于已确定的项目范围，定义了阶段和里程碑，那么我们每个阶段的输出的工作产品的工作量、成本、质量如何估算就十分重要，这些也是判断阶段目标和里程碑是否达成的重要判断依据，而要估算工作量、成本等工作产品属，我们就必须先估算出工程阶段每个工作包的工作产品规模。

1、估算的顺序

在整个估算中，规模的估算是基础，大部分的估算都是基于项目规模的估算而来的。在规模时，对于采用的类是技术、开发语言、架构的项目，他们的工作产品规模与需求规模的比例是基本稳定的。如：1个简单的数据库录入功能，用Java编写的代码一般是20行，概要设计是1页，详细设计是1.5页，需要20个单元测试用例等??。这个比例关系的变化是很少的，但是工作量和公司的生产率人员水平等都有关系，估算工作量我们要考虑的人为因素要更多。所以我们对最稳定的那部分优先估算。

2、确定估算的方法

目前典型的估算方法有：经验值估算、功能点估算。

但是我们发现选择了估算方法，在项目执行中我们会发现这些估算很不准确。建立公司的估算能力是解决估算准确性的唯一途径，估算能力一般是根据公司历史项目的数据来建立估算的模型。当然我们为了获取更准确的估算值，也会采用多种估算方法，通过多种估算结果去验证估算的准确性。

3、确定估算因素

在确定估算方法后我们依据估算方法的特点要去了解项目具体功能的特点，一般设计及实现的复杂度、技术要求、可维护要求、可配置要求、可靠性要求等一些非功能需求都与项目的复杂度相关，还有一些特殊的业务功能也会给项目的复杂度相关，这些要素就是能否准确估算项目前提。

4、估算工作量和成本

一般工作量和成本的估算是依据项目的估算模型，依据工作产品的规模去估算工作产品的工作量。

成本的估算我们要考虑项目管理类、支持类及返工的工作量。在建立项目度量能力和模型的时候我们可以从历史项目中推出这些工作量的估算模型。一般每个开发阶段都要预留15～20％的工作量用于返工。管理类的工作量一般是项目总开发工作量的10％，质量保证、MA及其他支持类的工作量一半是项目总工作量的2～5%。

5、估算项目的时间

依据已经估算出的项目规模，每个阶段的工作量，结合现有资源估算项目的概要时间，时间估算的结果是阶段、里程碑、项目的起至时间。

6、估算项目的风险

依据历史项目积累的风险，在项目开始阶段对项目的技术、管理、质量、资源、需求等方面可能出现的风险进行全面评估。并评估出来的风险制定规避和管理措施。

7、估算的评审

项目的估算结果一般就是项目预算，我们一般先要对这些预算进行技术评审，以确定预算的合理性。然后还应通过到由公司高层的管理评审。

五、建立项目组织

我们已经有了估算结果和各个阶段的时间，这个时候是我们考虑项目的组织建立，一般有：PM－项目成员，PM－Leader－项目组成员、PM-SubPM－Leader－项目组成员等模式。

在PM-项目成员这个管理模式是很好管理，这个模式下一般项目组人员规模不超过10个人，项目在对问题进行沟通的时候一般靠喊一喊就能全部传达。

在后面2个模式中，项目组成员规模一般都在10个以上有的大型项目甚至能到几百人。为了将这些团队管理好，我们要建立使项目组能高效的管理和沟通的方法及原则。这些方法及原则主要有：明确组织的管理和监控的方法及流程，要明确各个岗位的职责和权利，要明确各个层级沟通及汇报的方式，明确各个组间的沟通及汇报的方式。只有明确了这些才能保证项目组的各个团队都能高效运作，这个也是企业管理文化在项目中的体现。

六、建立项目综合管理计划

为了能使项目能正常开展并且有依据，我们需要建立一个综合的项目管理计划。这些计划的主要内容有:

1) 项目的质量目标

定义项目各个子过程及工作产品的质量目标。

2) 项目的生命周期模型

定义项目的生命周期模型。

3) 项目的阶段和里程碑计划

定义项目的阶段、里程碑的输入、输出准则，以及阶段、里程的主要活动及时间计划。

4) 项目的监控计划

定义项目的监控对象、监控频率、监控原则、监控依据，定义项目的会议制度、沟通方式、以及项目中出现问题的沟通及汇报原则。

5) 项目的度量计划

依据监控要求和公司要求，定义项目要进行度量的度量元、度量频率、度量方法、度量结果保存方法。

篇2：项目管理流程

一、立项审批

项目单位委托有相关资质的单位编制《项目可行性研究报告》、《项目建议书》，报经济发展局审批。

二、规划选址

项目单位报选址，经开区审批后出具选址意见。项目单位报市住建局，取得《选址意见书》。

三、用地预审

项目公司提出项目用地报告，报国土分局审批，下发征地组织函。

四、环评、安评、风险评估

项目单位委托相关资质单位编制《项目环评报告》、《项目安评报告》、《项目风险评估报告》分别报送市级主管部分审批。

五、土地征迁

国土局进行勘测定界，签订征地合同，进行土地出让。（正常应按土地招、拍、挂程序进行），取得土地使用证。

六、用地规划许可办理

项目单位到住建局办理《建设用地规划许可证》。

七、工程规划许可办理

项目单位到市住建局办理《建设工程规划许可证》。

八、招标代理

项目单位确定招标代理机构

九、勘察、设计招投标

要求：单项合同估算价在三十万以上的，或低于三十万元，但项目总投资在五佰万元以上的。

9.1发布招标公告；

9.2接受报名；

9.3资格预审，发放资格预审合格通知书；

9.4招开答疑会，勘察现场；

9.5发放招标文件及答疑纪要；

9.6递交投标文件、开标、评标、确定中标人；

9.7中标公示，发放中标通知书，并在招投标管理办公室备案。

十、工程规划方案

项目单位委托设计单位进行项目规划，规划方案报经开区管委会及市住建局，重点项目召开方案评审会议。

十一地质勘察

设计单位出具地勘任务书，项目单位委托相关资质单位进行用地范围内地质勘察，并出具《工程地质勘察报告》。勘察报告需经相关资质单位审查。

十二、初步设计及施工图设计

12.1设计单位根据规划、可研、地勘等进行项目初步设计。

12.2市发改委组织召开初步设计评审会。

12.3根据初步设计进行施工图设计。

十三、施工图审查

项目单位委托相关资质单位进行施工图审查。审查完成后，设计单位交付施工图。

十四、工程报建

项目单位到市住建局办理工程项目报建，填写报建表备案。

十五、工程量清单、限价编制

项目单位委托造价咨询机构，根据施工图编制工程量清单及限价。

十六、施工、监理招投标

要求：施工单项合同估算价在一百万以上的，或低于一百万元，但项目总投资额在五百万元以上的。（监理招标要求同设计）

16.1招标公告

招标代理机构发布招标公告。

16.2按受报名

发放资格预审文件。

16.3资格预审

发放招标文件。

16.4招开答疑会议，勘察现场

项目单位、设计单位参加，会议结束向投标人发答疑纪要。

16.5工程量清单核对

16.6招标招投标会议

递交投标文件、开标、评标，确定中标人。

16.7中标通知

中标公示，发放中标通知书，并在招投标管理办公室备案。

十七、履约保证缴纳

中标单位收到中标通知书后，到市财政局办理履约保证证金缴纳。

十八、施工合同、监理合同签订

根据招标文件内容，项目单位与中标单位签订施工合同、监理合同。

十九、施工许可

项目单位到市住建局办理《建设工程施工许可证》，所项提供资料：

19.1规划许可证

19.2勘察、设计、监理合同、及备案

19.3施工图审查批准书

19.4环保部门出具的认可文件或准许使用文件

19.5劳保统筹已交证明

19.6安全文明施工措施费拨付证明

19.7施工单位资质证书、营业执照、法人证明或委托书、安全生产许可证、“三类人员”安全考核合格证书

19.8处地施工企业在韩人业的注册备案证书

19.9工程施工承包合同

19.10建设单位和施工单位办理工程保险的保险单

19.11建设单位和施工单位共同签订的创建文明工地承诺书

19.12分包企业相关证明文件

19.13工程质量保证及安全措施相关资料

19.14建设单位和施工企业无拖欠工程款和民工工资的证明

19.15质量安全监督委托书

19.16中标通知书

19.17税务登记证/报验登记

19.18其他相关文件

二十、开工

项目用地实现“三通一平”；主要材料、施工机械、人员到位；完成施工图交底工作；施工单位现场建点、放线完成，监理单位校核无误；施工组织设计已审批。

总监工程师下发“开工令”

二十一、工程分步分项验收

根据施工组织设计，所有分步分项验收需由建设单位、施工单位、监理单位、设计单位、勘察单位五方共同进行预验收，预验收合格后，报建筑工程管理处（质监站）进行正式验收。

二十二、竣工验收

施工单位完成图纸全部内容后，递交竣工验收报告，经监理单位签审后，组织五方责任主体进行竣工验收。

二十三、施工资料整理

整个施工过程中，施工单位、监理单位应与工程同步编制施工资料（变更、签证、实验、自检、分步分项验收等），绘制竣工图。

二十四、资料备案

项目单位、施工单位将施工资料移交至市城建挡案馆。

二十五、竣工决算

施工单位根据招标文件、中标文件、施工合同、设计变更、施工签证、竣工图等编制竣工决算书。

二十六、工程决算审计

项目单位将项目批文、招标文件、中标文件、施工合同、设计变更、施工签证、竣工图、施工资料、监理报告、施工影像资料（纸质、电子版）交市审计局进行工程决算审计。

篇3：任务项目管理流程

一、风险评估

软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等各方面的问题，以及由这些问题而对项目所产生的影响。项目的风险与其可行性成反比，其可行性越高，风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、需求风险、相关性风险、管理风险、安全风险等六个方面：

1. 产品规模风险

项目的风险是与产品的规模成正比的，一般产品规模越大，问题就越突出。尤其是估算产品规模的方法，复用软件的多少，需求变更的多少等因素与产品风险息息相关：

(1) 估算产品规模的方法

(2) 产品规模估算的信任度

(3) 产品规模与以前产品规模平均值的偏差

(4) 产品的用户数

(5) 复用软件的多少

(6) 产品需求变更的多少

2. 需求风险

很多项目在确定需求时都面临着一些不确定性。当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造预期的产品。每一种情况对产品来讲都可能致命的，这些的风险因素有:

(1) 对产品缺少清晰的认识

(2) 对产品需求缺少认同

(3) 在做需求分析过程中客户参与不够

(4) 没有优先需求

(5) 由于不确定的需求导致新的市场

(6) 不断变化需求

(7) 缺少有效的需求变化管理过程

(8) 对需求的变化缺少相关分析等

3. 相关性风险

许多风险都是因为项目的外部环境或因素的相关性产生的。控制外部的相关性风险，能缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并觉察潜在的问题,与外部环境相关的因素有：

(1) 客户供应条目或信息

(2) 交互成员或交互团体依赖性

(3) 内部或外部转包商的关系

(4) 经验丰富人员的可得性

(5) 项目的复用性

4. 技术风险

软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：培训、聘请顾问以及为项目团队招聘合适的人才等。关于技术主要有下面这些风险因素：

(1) 缺乏培训

(2) 对方法、工具和技术理解的不够

(3) 应用领域的经验不足

(4) 对新的技术和开发方法应用不熟悉

5. 管理风险

尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风险管理计划的人，他们有先天性的不足――不能检查到自己的错误。因而，使项目的成功变得更加困难。如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目本身。当我们定义了项目追踪过程并且明晰项目角色和责任，就能处理这些风险因素：

(1) 计划和任务定义不够充分

(2) 对实际项目状态不了解

(3) 项目所有者和决策者分不清

(4) 不切实际的承诺

(5) 不能与员工之间的进行充分地沟通

6. 安全风险

软件产品本身是属于创造性的产品，产品本身的核心技术保密非常重要。但一直以来，我们在软件这方面的安全意识比较淡薄，对软件产品的开发主要注重技术本身，而忽略了专利的保护。软件行业的技术人员流动是很普遍的现象，随着技术人员的流失、变更，很能会导致产品和新技术的泄密，致使我们的软件产品被它公司窃取，导致项目失败。而且在软件方面关于知识产权的认定目前还没有明确的一个行业规范，这也是我们软件项目潜在的风险。

7. 回避风险的方式

(1) 以开发方诱导能保证需求的完整，使需求与客户的真实期望高度一致。再以书面方便形成《用户需求》这一重要的文档，避免疏漏造成的损失在软件系统的后续阶段被逐步地放大。

(2) 设立监督制度，项目开发中任何较大的决定都必须有客户参与进行的，在该项目中项目监督由项目开发中的质量监督组来实施。

(3) 需求变更需要经过统一的负责人提出,并且要用户需求的审核领导认可,需求变更应该是定期而不是随时的提出,而且开发方应该做好详细的记录,让客户了解需求变更的实际情况。

(4) 控制系统的复杂程度，过于简单的系统结构，对用户来使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险。适当控制系统的复杂程度有利于降低开发的风险。

(5) 从软件工程的角度看，软件维护费用约占总费用的55%~70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。

(6) 设定应急计划，每个开发计划都至少应该设定一个应急预案去应对出现突发情况和不可遇知的风险。

二、成本预算

1. 成本预算方式

(1) 自上而下的预算方法

自上而下的预方法主要是依据上层、中层项目管理人员的管理经验进行判断，对构成项目整体成本的子项目成本进行估计，并把这些判断估计的结果传递给低一层的管理人员，在此基础上由这一层的管理人员对组成项目的子任务和子项目的成本进行估计，然后继续向下一层传递他们的成本估计，直到传递到最低一层。

使用此预算方式，在上层的管理人员根据他们的经验进行的费用估计分解到下层时，可能会出现下层人员认为上层的估计不足以完成相应任务的情况。这时，下层人员不一定会表达出自己的真实观点，不一定会和上层管理人员进行理智地讨论，从而得出更为合理的预算分配方案。在实际中，他们往往只能沉默地等待上层管理者自行发

现问题并予以纠正，这样往往会给项目带来诸多问题。

自上而下更适用于项目启动的前期，与真实费用相差在30% ~ 70%之间。

Scrum使用自上而下的成本预算方式，它不会立即精确地确定成本，而是以最大限度容纳客户对未来产品要求所

产生的变更。

(2) 自下而上的预算方法

自下而上方法要求运用WBS（Work Breakdown Structure，工作分解结构）对项目的所有工作任务的时间和预算进行仔细考察。最初，预算是针对资源（团队成员的工作时间、硬件的配置）进行的，项目经理在此之上再加上适当的间接费用（如培训费用、管理费用、不可预见费等）以及项目要达到的利润目标就形成了项目的总预算。自下而上的预算方法要求全面考虑所有涉及到的工作任务，更适用于项目的初期与中期，它能准备地评估项目的成本，与真实费用相差在5% ~ 10%之间。

注解：WBS

WBS是面向提交成果对项目的分解，从提交成果的列表可以确定每个提交成果需要执行的活动。Scrum会对WBS进一步细化，把每个迭代分解为更细小的工作包。

2. 确定项目支出

总体成本预算就是结合下列多个成本预算方式，组成开发的总体成本：

(1) 零基数预算

在成本预算的初期应该使用零基数的计算原则，而不可以使用类似于：以上一年总体费用加上20% 这样粗略的方式计算项目成本。

(2) 软硬件成本、物品成本

物品成本是指类似于：服务器（RAM 硬盘 CPU NIC卡 RAID簇）成本、维护成本、机房租金、光纤通讯成本、软件成本等的成本。

计算成本时需要考虑组装硬盘需时的长短，技术人员需要具备的质素，产品供应商能否提供保证质量，管理时是否需要额外的管理人员这些多方因素。

(3) 软件许可证成本

(4) 外包成本

当使用类似：视频、短信、移动电信类服务、门户网站等子项目时可以考虑以外包形式完成，以降低开发成本。

(5) 人力资源成本

计算人力资源成本时应该使用以最高和最低的工作效率估算平均效率的方式，计算出人力资源的平均成本。

(6) 维修保养成本

三、客户沟通的过程

从客户沟通的方向出发来看，软件项目可分为：需求识别、方案定制、项目实施、项目结束等4个不同的阶段，各个阶段都具有不同的沟通重点。

1. 需求识别阶段

(1) 文本沟通

在需求识别的前期，应该通过问卷、原型展示、界面展示、逻辑处理展示、准化文档模板等方式进行全方位多角度的分析，随时将不明确之处反馈给客户,以期待客户解答。并以文本记录的方式建立需要分析书，并要求客户审核需求分析书，以达到需要分析与客户的真实期望高度一致的结果。

(2) 业务逻辑沟通

在进行业务沟通时，应该了解客户的行业语言，以促进业务分析的过程，越过应用需求和开发之间的鸿沟。沟通过程提倡以草图或者可视信息化的方式进行,针对不同层面的企业用户提供最适合的操作界面。以多角度的方式思考问题，要抓住需求重点,尤其是客户方领导所关注的创新类和实用类需求。

(3) 需求变更的规范化管理

需求变更在软件开发类项目中是可以理解的,但必须对需求变更做好规范化的管理，以避免出现需求无止境变更的风险。需求变更必须由统一的负责人提出,并且由用户需求的审核领导者认可。需求变更的提出应该是定期而不是随时的，开发方应该做好详细的文本记录,让客户了解需求变更的实际情况和开发方为之所付出的成本代价。

2. 方案定制阶段

该阶段项目的主要任务是与客户共同制定一个以前期明确的需求、双方的资源、项目开始的阶段、实施的时间约定、项目费用限制等为基础的具有可操作性的项目计划,从本阶段开始争取客户全面参与项目的管理，并以双方的共同利益考虑项目实施的具体计划与风险规避。

3. 项目实施阶段

在该阶段,软件项目团队应该与客户共同领导项目的实施。同时,项目团队应实时评估客户满意度,并通过持续改进的方式提高客户满意度,还应要求客户参加必要的培训,以及在必要时检查项目产品。在出现客户的需求变更前,应主动与客户沟通交流,使客户充分了解项目的每个环节,以及变更带来的影响,减少需求变更。如果出现客户需求变更,应与客户一起共同解决由变更引起的成本、进度、质量变化。

4. 结束阶段

该阶段主要进行项目成果的移交，并把系统交付给维护人员，帮助客户实现商务目标，结清各种款项。完成这些工作后应该进行项目评估，审核此项目的成果并总结项目经验。

5. 售前人员注意事项

在产品型项目作为开发成果时，相关销售人员应该注意：对产品的推销不应该过分承诺。如果过分承诺,会给后续的项目实施带来困难;一旦承诺没有兑现,也会降低客户满意度,影响今后合作。如果有附加承诺,一定要以文本形式记录，让实施项目经理知晓并传达给项目组成员。

注解：在软件项目中,需要明确以下四种客户角色

A. 要明确最终使用部门和用户,要去了解他们现有的工作方式,要让他们知道项目的目标框架,知道项目要解决他们的哪些困难,但绝对不是全部困难,这样可以较好的控制项目范围。

B. 要明确需求的提出者,他或者他们要能够代表最终客户群体。提出产品需求的这类客户要具有一定的技术、业务能力和权威,能够真正代表最终客户团队的意愿和想法,最好有IT基础,能够用IT语言描述问题和需求,以利于双方的沟通、协作,避免产生歧义。

C. 要明确做需求确认的中层领导,他要把握方向。软件开发项目是解决实际生产或者管理问题,同时也是领导系统建设的具体实现,做需求确认的客户领导,既要了解高层领导的系统建设要点和方向,又要谙熟具体业务和生产管理实际。如果是这样的客户领导来把握和决策,对企业软件开发项目的顺利进展作用非凡。

D. 要明确谁来对成品提意见,谁来验收。项目验收环节,是项目的收尾环节,如果验收的人对项目初期的需求目标不了解,会从态度和产品实际使用效果上对验收产生负面的影响,对提供产品的企业关闭项目非常不利。根据实践总结,由需求提出人和确认人来做项目的验收工作,能够促进项目的顺利完成,避免延期。

四、需求分析

1.需求分析的过程

需求过程包括需求开发和需求管理2个部分：

(1) 需求开发就是对开发前期的管理，与客房的沟通过程，可以分为4个阶段：需求获取、需求分析、编写需求

和需求验证。

(2) 需求管理：就是软件项目开发过程中控制和维持需求约定的活动。包括：变更控制、版本控制、需求跟踪、需求状态跟踪。

2. 需求的层次

需求的层次包括：业务需求、用户需求、功能需求、非功能需求等4个方面。

3.需求开发阶段的重点

(1) 提取业务对象

业务对象是指系统使用的真实对象，例如一个供应链管理(Supply Chain Management ,简称SCM)业务对象主要包括：生产批发商、零售商、送货商、顾客多个层次。

(2) 提取业务流程

在了解业务逻辑的过程中，应该列举出所开发软件模块的各自职能，并细化每个工作流程，深入分析业务逻辑。

(3) 性能需求

在分析的前期应该注意客户对所开发软件的技术性能指标，如存储容量限制、运行时间限制、安全保密性等。

(4) 环境需求

环境需求是指软件平台运行时所处环境的要求，如硬件方面：机型、外部设备、数据通信接口;软件方面：系统软件，包括操作系统、网络软件、数据库管理系统方面;使用方面：使用部门在制度上，操作人员上的技术水平上应具备怎样的条件。

(5) 可靠性需求

对所开发软件在投入运行后发生故障的概率，应该按实际的运行环境提出要求。对于重要的软件，或是运行失效会造成严重后果的软件，应提出较高的可靠性要求。

(6) 安全保密要求

在需要分析时应当在这方面恰当地做出规定，对所开发的软件给予特殊的设计，使其在运行中，其安全保密方面的性能得到必要的保证。

(7) 用户界面需求

为用户界面细致地规定到达的要求。

(8) 资源使用需求

开发的软件在运行时和开发时所需要的各种资源。

(9) 软件成本消耗与开发进度需求

在软件项目立项后，根据合同规定，对软件开发的进度和各步骤的费用提出要求，作为开发管理的依据。

(10)开发目标需求

预先估计以后系统可能达到的目标，这样可以比较容易对系统进行必要的补充和修改。

面向对象分析的基本原则

面向对象分析是面向对象的软件开发过程中同问题域直接打交道的阶段，为了尽可能完成高质量、高效率的分析，分析过程中应该遵循如下原则。

1.抽象原则。面向对象分析方法中的类就是抽象得到的；系统中的对象是对现实世界中事物的抽象；类是对象的抽象；一般类是对特殊类的进一步抽象；属性是事物静态特征的抽象；服务是事物动态特征的抽象。

2.分类原则。分类就是把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。分类原则实际上是抽象原则运用于对象描述的一种表现形式，通过不同程度的抽象可以形成一般/特殊结构。在OOA中所有的对象都是通过类来描述的。

3.聚合原则。聚合是把一个复杂的事物堪称若干简单的事物的组合体，从而简化对复杂事物的描述。在面向对象分析中运用聚合原则将一个较复杂的事物划分为几个组成部分，分别用整体和部分进行描述，这样形成的整体/部分结构不仅能清晰地表达事物的组成关系，还可以简化分析过程。

4.关联原则。关联是人类思考问题时常用的方法，通过一个事物可以联想到另外的事物，产生联想的原因是事物之间存在着某些联系。在面向对象分析过程中运用关联原则可以在系统模型中明确地标识对象之间的静态联系。例如理发师和剃头刀之间存在着这样一种关联，理发师可以使用某把剃头刀。如果这种联系信息是系统责任所需要的，则要求在面向对象模型中通过实例连接明确地表示这种联系。

5.消息通信原则。这一原则要求对象之间只能通过消息进行通信，而不允许在对象之外直接地存取对象内部的属性。通过消息进行通信是由于封装原则而引起的。在面向对象模型中要求用消息连接表示出对象之间的动态联系。

4. 需求分析的任务

需求分析的主要任务是借助于当前系统的逻辑模型导出目标系统的逻辑模型，其流程如下：

(1) 确定对系统的综合需求（功能、性能、运行、扩充需求）

(2) 制作产品需求文档 (PRD)

(3) 分析系统的数据需求（概念模型、数据字典、规范化）

(4) 导出目标系统的详细的逻辑模型（数据流图、数据字典、主要功能描述）

(5) 开发原形系统

(6) 从PRD提取编制软件需求规格说明书（SRS）

备注：SRS格式

1.引言 2系统概述（项目背景、系统目标、核心业务流程） 3.术语说明 4.系统结构（架构图、功能图）

5.主体功能与业务逻辑（重点） 6.接口需求（内部、外部接口、） 7.网络总体设计（拓扑网络、主机、组网）

8.运行环境（Linux、Windows、IIS、 WebLogic、Tomcat、OLAP、OLTP、JDK 8.0 、.NET Framework 4.0等）

五、面向对象程序设计（略）

1. 设计原则

(1) SRP单一职责链

每个类都应该只负责做一件事。

(2) OCP开封闭合原则

软件的实体（类、模块、函数等）应该是可以扩展的，但是不可修改的。

(3) LSP替换原则

子类必须能替换他们的基类型。

(4) DIP依赖倒置原则

高层模块不应该依赖于低层模块，二者都应该依赖于接口与抽象类。抽象不应该依赖于细节，细节应依赖于对象。

(5) ISP接口隔离原则

不应该强迫客户依赖于并未使用的接口，而应该把胖接口分离。

2. 实现UML建模

(1) 业务对象的提取

(2) 根据SRS、CRC等实现用况建模

(3) 实现业务顺序图

(4) 建立类图，根据用况图建立对象之间的关联

(5) 绘制活动图、实现协作图、状态图

六、开发管理

1. 建立项目计划

(1) 设计总体架构

针对系统的实施需要，采取适当的且成熟的框架结构。

(2) 控制可扩展度

扩展度过大，将提高系统的复杂程度，延长开发时间；扩展度过低，会直接影响系统的二次开发与维护。控制系统的可扩展性，能提高开发效率，降低系统维护的难度。

(3) 建立基础设施

合理分配软、硬件等基础设施的部署所需要的时间与成本（例如：服务器的订购安装、光纤接入、软件平台订购）。

(4) 划分开发任务

利用WBS（Work Breakdown Structure，工作分解结构）对可交付结果进行分类与划分。每个项目都能划分为多个不同阶段，每个阶段又可以分为多个工作包（Work Package），工作包是WBS里最小的可交付结果，最后从工作包中分解出多个开发任务列表。

(5) 部署开发进度

一个项目应该按进度划分为多个开发阶段，每个阶段的开发周期一般在30~60个工作日以内。在此阶段内应该与客户举行协商会议，制定产品路线图，在开发过程中邀请客户积极参与并提出反馈意见。然后把该时段内的开发任务按照开发难度，依赖性，重要性等多方条件划分为多个迭代周期。

在Scrum 敏捷软件开发原则中，应该把每个迭代任务进一步细分为多个开发任务列表，开发任务的开发时间应该控制在15个工作小时以内，如果开发时间超出15个工作小时，应该考虑把开发任务再度细化。开发任务建议应该由组员自主选择，而不要使用强制分配的方式。

(5) 测试项目成果

每个工作包都应该同步部署测试工作，提高项目的质量。对出错BUG的工作包应该由测试人员以文本方式记录，向开发人员展示错误所在，让开发人员及时进行修改。

2. 管理开发团队

(1) 组建团队

按照工作任务与项目时间的前提条件建立团队，按团队职责分配人员，一般团队人数应该控制在8~12人之间。当团队人数超过15人时，应该考虑把团队分解成2个独立团队，负责不同的开发任务。

(2) 分配开发任务

在每个迭代周期内（一般是15~30个工作日），应该把每个工作包进一步细分为多个开发任务，开发任务的开发时间应该控制在15个工作小时以内，如果开发任务的开发时间超出15个工作小时，应该考虑把任务再度细化。而开发任务应该以自由选择的方式分配给每个组员。

(3) 监督开发进度

在迭代的前期举行一次会议，让组员了解开发的进展及流程，并以自主选择的方式分配开发任务。期间可使用Microsoft Project等工具记录开发流程的进展，在每个工作包完成开发后应该进行性功能的测试，并以文本方式记录测试结果。

每天举行一次15分钟的站立会议，让组员交待昨天已完成的开发任务，当天将要做的任务，与开发过程中所遇到的问题。并在每周末举行一次例行会议，交待总体进程。

在迭代末期举行一次冲刺会议，总结项目的进展，交行已完成的任务，回顾该迭代周期内所遇到的问题，为下一个迭代做好准备。

(4) 系统测试

对每个已完成的工作包进行适时的测试，保证系统质量与性能。对测试结果进行文本的记录，并把测试结果与绩效工资收入挂钩，并以真实数据计算组员的绩效收入。

(5) 解决开发中所遇到的问题

对开发人员进行前期培训，可适当按工作能力分配任务，指导组员的开发。当遇到问题时应该在当天的站立会议时即时提出，并在15个工作小时内解决所遇到的问题以防止问题进一步扩大。

3. 监管产品质量

(1) 质量需要的是计划、设计而并非审查的。在产品建立的初级，必须与“质量保证”（QA）的部门进行协商，以正式文档的方式，决定恰当的质量策略和标准。

(2) 在开发过程中使用TDD（测试驱动开发）的模式，提高开发质量。测试人员应该以文本方式记录bug，并与开发人员共同工作的，把突出的缺陷演示给开发人员，以提高修改的效率。

(3) 在每个迭代的结束时进行一次产品效果的演示，从客户、使用者、高层领导中收集反馈信息。在团队内部举行评审会议，分析测试结果，了解产品性能，为下次迭代所需要做的改进做好计划。

4. 修改项目计划

(1) 在产品需要识别阶段，应该以文档形式记录产品功能与开发流程，在开发计划需要修改时，应该与客户共同探讨，让客户了解计划修改对项目进度所造成的影响。

(2) 项目计划的修改应该由统一的负责人提出,并且由用户需求的审核领导者认可。需求变更的提出应该是定期而不是随时的。

(3) 计划的变更应该做好详细的文本记录，让客户了解需求变更的实际情况和开发方为之所付出的成本代价。

七、产品交付

1. 项目的后期审核

在项目开发最终完成后，对开发人员来说可算是放下工作的重担，但对项目经理来说这往往是项目的关键时刻。前期的风险评估、成本预算、需求分析、软件设计都是为了引导项目走向这一时刻，此时所有的目光都将投向项目管理人员。你可能发现大量而琐碎的工作将要在几个小时内完成，此刻项目经理更需要保持清醒与镇定，把最后的工作视为微型项目来对待。细致地对项目进行后期的审核，分析项目成果、项目团队的效率、可交付产品的价值，以此审核结果可作为项目管理经验总结的一部分。

2. 质量评审

在项目交付前，应该把项目交给相关的“质量保证”（QA）部门进行质量评审，并邀请典型用户感受产品的质量。

3. 项目的最终交付

正常情况下在项目的前期就会订立项目交付的协议，项目交付方式分为非正式验收与正式验收两种。一般在项目完成后都会先进行非正式验收，让客户体会项目的质量并提出反馈意见，最后在客户肯定产品质量后再以书面协议的形式进行正式的产品验收。

4. 项目的最终报告

在项目的最后，应该制定项目的最终报告，此报告可以视为是对该项目一个记录，但报告不必包含项目的所有方面。一般最终报告应该包含以下方面：

(1) 最初引进项目时的初期项目视图

(2) 对该项目的价值评估及支持性信息

(3) 项目的范围

(4) 项目的开发流程及WBS

(5) 项目的会议记录

(6) 项目变更的报告及变更的理由

(7) 与项目相关的沟通过程文件

(8) 项目的审核报告与客户验收报告

(9) 项目成员的表现报告

(10)项目的最终成果

[任务项目管理流程]

篇4：信息系统项目管理流程

项目管理流程是项目先后衔接的各个阶段的全体，以下是信息系统项目的管理流程，一起看看吧。

信息系统项目管理流程

项目启动

在项目管理过程中，启动阶段是开始一个新项目的过程。启动信息技术(IT)的项目，必须了解企业组织内部在目前和未来主要业务发展方向，这些主要业务将使用什么技术及相应的使用环境是什么。启动信息技术(IT)的项目的理由很多，但能够使项目成功的最合理的理由一定是为企业现有业务提供更好的运行平台，而不是展示先进的IT技术。

每个项目在一个阶段完成后，进入下一阶段之前必须要顺利的通过前面一个阶段的阶段关口控制。要将本阶段的关口控制文件或关口控制审批做好。随着项目不断地向前推进，项目的投入将越来越多。因此，每个阶段都要进行阶段性的审核或检查。上一阶段控制关口提供的文件将是下一阶段的启动文件。

一般意义上的项目启动是在招投标结束了，合同签订之后。

项目计划

在项目管理过程中，计划的编制是最复杂的阶段，项目计划工作涉及十个项目管理知识领域。在计划编制的过程中，可看到后面各阶段的输出文件。计划的编制人员要有一定的工程经验，在计划制定出来后，项目的实施阶段将严格按照计划进行控制。今后的所有变更都将是因与计划不同而产生的。也就是说项目的变更控制将是参考计划阶段的文件而产生的。

目前，一些企业为了追求所谓的低成本、高收益，压缩项目计划编制时间，导致后期实施过程的频繁变更。学习PMP的人都知道，质量是规划、设计出来的，不是靠检查来实现的。所以，这样做既没有降低成本，也没有提高效益，反而导致项目的失败。

项目实施

在项目实施阶段是占用大量资源的阶段，此阶段必须按照上一阶段定制的计划采取必要的活动，来完成计划阶段定制的任务。在实施阶段中，项目经理应将项目按技术类别或按各部分完成的功能分成不同的子项目，由项目团队中的不同的成员来完成各个子项目的工作。在项目开始之前，项目经理向参加项目的成员发送《任务书》。《任务书》中规定了要完成的工作内容、工程的进度、工程的质量标准、项目的范围等与项目有关的内容，《任务书》还含有项目使用方负责主要人的联系方式及地址等内容。

项目收尾

项目的收尾过程涉及到整个项目的阶段性结束，即项目的干系人对项目产品的正式接收。使项目井然有序地结束。这期间包含所有可交付成果的完成，如项目各阶段产生的文档、项目管理过程中的文档、与项目有关的各种记录等。同时通过项目审计。

在项目的收尾阶段中的主要活动是，整理所有产生出的文档提交给项目建设单位。收尾阶段的结束标志是《项目总结报告》，收尾阶段完成后项目将进入维护期。

项目的收尾阶段是一个项目很重要的阶段，如果一个项目前期及实施阶段都作的比较好，但是在项目的收尾阶段没有重视，那么这个项目给人的感觉就象虎头蛇尾的工程一样，即使项目的目标已达到，但项目好像总没有完结一样。所以一个项目的收尾是非常重要的，项目的收尾做的好，会给项目的所有干系人一个安全的感觉。项目的收尾还有一个重要的事情，就是要对本项目有一个全面的总结，这个总结不仅对本次项目是一个全面的总结。同时，也是为今后的项目提供一个可以参考的有经验的案例。

项目维护

在项目收尾阶段结束后，项目将进入到后续的维护期。项目的后续维护期的工作，将是保证信息技术能够为企业中的重要业务提供服务的基础，也是使项目产生效益的阶段。在项目的维护期内，整个项目的产品都在运转，特别是时间较长后，系统中的软件或硬件有可能出现损坏，这时需要维护期的工程师对系统进行正常的日常维护。维护期的工作是长久的，他将一直持续到整个这个信息技术(IT)项目的结束。也就是说，什么时候本IT项目的硬件及其上运行的系统退出，那时将是项目后续的维护期的结止日。

[信息系统项目管理流程]

篇5：装修项目管理流程

一、装修前需要准备的物品

装修前，必须准备好的几样东西放在你的包包里。有卷尺（买5m的，不要3m的）、计算器、大板夹（夹单子、收据用）；另外，最好提早在工地准备好旧毛巾（柔棉的那种，贴完砖擦砖用）、塑料袋（缠在管道接口上，可防脏物堵塞）

二、选择良辰吉日

放炮开工在工人进场之前，最好将家里的角角落落亲自测量一遍，拿笔尺记下来，标清楚，一定一定不要偷懒。测量的内容主要包括：

1.明确装修过程涉及的面积。特别是贴砖面积、墙面漆面积、壁纸面积、地板面积；

2.明确主要墙面尺寸。特别是以后需要设计摆放家具的墙面尺寸。

做完这些，此时，应该去购买散热器了。

三、主体拆改，让空间更实用

主体拆改是最先上的一个项目，主要包括拆墙、砌墙、铲墙皮、拆暖气、换塑钢窗等等。拆改完的垃圾，要及时清理出去，保证室内的清洁，也是为了方便施工。

此时，该把成品门定下来了，这时最好把橱柜、烟机、灶具、热水器逛透，并可以确定下来。

四、水电改造，安排好每个空间的用途

水电改造，没有后悔药吃。砖上了墙、吊顶一封上，再想加插座可就难咯。所以，一定要确定好开关、灯具、台盆、浴缸、洗衣机等等确切的位置。水电改造前，橱柜设计师应上门进行第一次测量，帮你确定好电源、水路的改造方案。

热水器，也最好派人来根据你所确定的型号，设计好电源、接口的位置。温馨提醒：水盆下面的墙上，最好留电源插座，方便装厨宝。

空调洞和电源尽量放在床头的这面墙上，避免以后空调直接对着人吹。强电和弱点要保持20公分的间距，例如，插座和网线间要留20公分距离。

五、包立管

把难看的管道包起来考虑到厨房卫生间的易潮易湿环境，包立管的材料一定不能用木龙骨！大家千万小心，即使木龙骨上刷防腐涂料也不行。

记住，包立管用轻钢龙骨，或者红砖。轻钢龙骨省地方，但最牢固好用的是红砖。

这时需要购好瓷砖、勾缝剂等，家具要提早定，留好工期，一般至少要15天左右。

六、贴砖，第一件有实体质感的东西

贴砖前，要买好地漏。要买专用的洗衣机或淋浴用地漏，而且要防臭功能。做完防水、拉毛后，就准备贴砖了。除了正常的贴砖注意，瓷砖泡水、阴干；破残的瓷砖留做切割外，我个人强调贴砖的整体美感。简单说，就是上墙的砖，宽不能小于10公分以下。贴砖时经常要遇到这种情况，比如说，1米的墙宽，砖为32*32cm，正常贴法，3整1小。但是，32×3＝96，还要预留1公分的勾缝空间，最后剩下那个小砖只能贴3cm宽。不是我挑剔，窄窄的一条砖贴在那里，要多难看有多难看。

这时候需要你提前跟瓦工师傅说清楚，上墙的砖，宽不能小于10公分以下。他就会两边裁砖。还是举刚才1米宽的墙的例子，就变成2整2小。32×2＝64，预留1公分的勾缝，两边的小砖各17.5cm就可以了。这样，看起来两边不但对称，而且整墙都不会有窄窄一条在那里碍眼。不过，此做法费砖，请大家买砖前就量青春。

这时应确定水盆、龙头，并约请橱柜设计师第二次上门，同时购买油漆（混或清）、墙漆、硝基漆、稀释水等，如贴壁纸，也要先定好。

七、油工上阵

洗刷刷洗刷刷如果不买成品门，那么就让工人师傅做吧。

小贴士：任何木工活，哪怕只是做垭口，一定要遵循这个步骤，大芯板沉底，饰面板贴面，然后才能上油漆。做混油时，有那种不负责任的工人，偷懒，直接在大芯板上刷油，这是绝对错误的。别信个别卖大芯板的胡说，直接在上面刷油都没问题。记住，直接刷油，过不了多久，就得全部开裂，切记切记。现在做混油，都不用刷，而用喷的。最好，让工人把门内侧、电表箱一并喷上白色，不浪费还漂亮。

刷墙没什么好说的，找平、打磨、滚刷，效果好不好，绝对依靠你家油工的手艺。我家除了壁纸就是白漆，没刷颜色。需要提醒大家，如果墙壁要刷颜色，调色一定要注意，调出的颜色要比色卡浅，千万不能同于色卡或比它深，否则你会后悔不已。因为刷墙时至少两遍面漆，有些还要三遍，上墙的颜色会一层比一层深的。

关于刷漆方法是喷涂还是滚涂，仁者见仁，智者见智。我家用的是滚涂，没试过喷的。据说喷的效果好些，可一旦有了破坏要补漆，将变得困难万分。

八、壁纸

美轮美奂的墙壁贴壁纸比刷墙漆，效果要好很多很多。

墙漆刷好后，油工会在需要贴壁纸的地方刷硝基漆，漆隔天就可以干透，然后就可以约师傅贴壁纸了。我刚开始还担心贴壁纸会把刷好的白墙搞脏，后来贴时才知晓，贴壁纸真是个特干净的活儿！我的担心完全多余。

注意：壁纸贴完48小时内不要开窗通风，让它慢慢阴干。

跟师傅说好，个别地方起翘的话，要麻烦他帮忙来修补一下。

此时，该买面板、插座、灯具了。

九、安装插座面板插座面板大概半天可以安装完毕。

温馨提醒：

1、插座最好买带开关功能的，尤其是厨房，这样电饭锅、微波炉就可免于插拔电源，用开关即可控制。

2、有开关的插座虽好，但要注意实用性。据我观察，带开关的五孔电源，三项插座都是扁口的，一旦你的电器需要的是圆口三项时，就会出现空着插座用插板的郁闷局面。所以，多用插座也一定要，哪怕它没开关控制！

此时，应购买卫生间厨房所用吊顶，如需装浴霸，请在吊顶前购买并安装。

十、厨卫吊顶，封上最后一个难看的部分

先安装热水器和浴霸，安装好后，吊顶封边才能更好地半包热水器，也就是更美观地衔接啦。

小贴士：1、最好买铝扣吊顶，即使多年后拆掉不用，卖废铝都值不少钱。反观，pvc扣板好看，但质量、性能都一般般，而且塑料的东西即使卖废品都值不了几个钱。

2、买扣板，要问全包的价格，不要扣板、边角分着买。但安装费是另算的。

十一、安装橱柜

漂亮的整体厨房诞生橱柜是个配合工程，应提前约好烟机、灶具和水槽。最好同一天送来并跟橱柜一起同时安装。提前跟橱柜厂说，把裁下灶具和水槽位置的人造石台面一并带过来，N多银子的东西，不能白给了厂家。包个水表、管道什么的，很有用处。

十二、安装成品门应先于地板安装

主要因为装门步骤复杂，合页、门锁、门吸、门框等等，所用工具众多，如先装地板，磕磕碰碰很难避免。我家就是先装地板后装门，地板上磕出了很多小坑，很心疼的。

十三、安装晾衣架、窗帘杆、灯具、洁具、卫浴五金件。建议在装地板前，将这些灰渣散落多的项目一一搞定。

十四、安装地板前一定要做找平

我好多邻居家铺地板没用找平，所以我和老毛都大意了。没想到，地板铺上后，过道一走一瘪，非常郁闷。只好拆下来，拿快沾粉找平后重铺。事先备上一点胡椒粒，不要买地板工人带来的所谓的杀虫粉，让他们沿着踢角撒上就行。一定要求工人不要在屋内切割地板，走廊里去切，最后把走廊打扫一下就可以了。

十五、安装散热器

装修到了最后，最容易疏忽大意。必须事先跟js说明确，安装单上盖的如不是厂家的章，将不予签收。

注意看散热器的安装单，（不是购买单），盖章的部分是谁？很多js是这么操作的，购买单上盖的是厂家章；安装单盖的是安装队的章。这样，所谓的“保××年”只是保的散热器本身，可是材质上不是钢就是铜铝，只要能出厂几乎就没有什么质量问题。最容易出问题的地方是安装！如果认同了安装队的章，就基本表示你放弃了让厂家负责的权利。一旦出现泡了地板、淹了家的事故，厂家绝对推卸责任，安装队根本不可能找得到人。所谓的质保，只能由用户承担。

十六、开荒保洁

保洁的最大体现，我认为是擦玻璃。那么高的楼，自己爬到外面去擦，是个令人惊恐的事。其次是地板打蜡，蜡要自己买，便宜还好用，但一定要用保洁的打蜡机，效率比人工快几十、上百倍。其余的方面，我觉得不需要太依赖保洁，他们也就拿着小刀片这里刮刮、那里刮刮，没有那么灵的。所以，保洁走后，最好自己再进行一遍细致保洁。去超市买包“五洁粉”，弄几个旧毛巾。用旧毛巾，沾着干的五洁粉，从垭口到门、从瓷砖到踢角，一个屋一个屋的擦，不要偷懒，结果绝对让你骄傲。

十七、家具、家电进场，焕然一新的新家家具首当其冲。床、床垫、衣柜、鞋柜、沙发、餐桌等等。

小贴士：家具进场前，应备好如下物品：一次性鞋套（别买质量差的，踩踩就破）、几盒活性炭、梯子、地板保护膜（搬运衣柜、电视柜等最好对地板做个保护）。如果你买的是布艺床，提醒你看看布艺能否全部取下来。因为我实在无法忍受化纤的静电，隔天想自己把原布套取下来，去定做一套纯棉的时候，发现布套做的过长，被钉进床箱里去了。工人偷懒，以为我一年半载的不会拆套子。不知别人家是否有这种经验，反正工人师傅第二天又跑来一趟，死沉的床拆卸一番相当麻烦。家电赶紧送货，手头紧或不着急的等等再说也行。反正电器是越来越高级、越来越便宜。

十八、配饰装点，家才有了味道

有了装饰画的点缀，再配上漂亮的窗帘，家里的温柔味道就出来了。

小贴士：窗帘千万别在辅料上花太多钱，帘头、铅坠是必加的钱，但花边、布扣、穗子，这八元、那十元的，每米都要多花二三十元，没必要，而且也未见得好看。

篇6：项目管理9大流程

项目整体管理

项目整体管理贯穿项目启动到项目收尾，在于协调各个流程间的关系。

项目范围管理

项目范围的管理也就是对项目应该“包括什么”和“不包括什么”进行相应的定义和控制。

项目进度管理

项目进度管理是指在项目实施过程中，对各阶段的进展程度和项目最终完成的期限所进行的管理。

项目成本管理

项目成本管理为使项目成本控制在计划目标之内所作的预测、计划、控制、调整、核算、分析和考核等管理工作。

项目质量管理

项目质量管理是对产品质量与工作质量的管理过程，产品质量是指产品的使用价值及其属性；而工作质量则是产品质量的保证，它反映了与产品质量直接有关的工作对产品质量的保证程度。

项目人力资源管理

项目人力资源管理包括制订人力资源管理计划、项目团队组建、团队建设和管理的各个过程，不但要求充分发挥参与项目的个人的作用，还包括充分发挥所有与项目有关的人员――项目负责人、客户、为项目做出贡献的个人及其他人员的作用，也要求充分发挥项目团队的作用。

项目沟通管理

项目沟通管理是为了确保项目信息合理收集和传输，以及最终处理所需实施的一系列过程。

项目风险管理

项目风险管理是指对项目风险从识别到分析乃至采取应对措施等一系列过程。

项目合同管理

项目合同管理是对施工合同的订立、履行、变更、终止、违约、索赔、争议处理等进行的管理。

[项目管理9大流程]

篇7：项目管理关键流程

只要流程界定清晰，项目经理就能保证项目的发展方向与最终目标相契合。广义而言，要掌控各种类型项目的发展，首先要关注十个关键的流程。

一、生命周期与方法论

项目的生命周期与方法论，是项目的纪律，为项目开展划出了清晰的界限，以保证项目进程。生命周期主要是协调相关项目，而方法论为项目进程提供了持续稳定的方式方法。

生命周期通常由项目的阶段组成（包括：开始、规划、执行/控制、完成），或由工作的重复周期构成。项目生命周期的细节一般都会随具体业务、项目、客户要求而改变。因此即使在同一个项目中，周期也会有多种可能的变化。对工作细致度、文件管理、项目交付、项目沟通的要求体现在生命周期标准和考核的方方面面。大项目的阶段一般更多更长，而小项目的阶段少，考核点也少。

与生命周期类似，项目方法也因项目而易，细节关注程度高。产品开发项目的方法经常涉及使用何种工具或系统，以及如何使用。信息技术项目的方法包括版本控制标准、技术文档管理、系统开发的各个方面。

项目方法往往不是由项目团队自行确定，而由公司为所有项目设定。采用与否，其实项目团队没有太多选择。公司管理层设定的方法本身代表权威，也是你作为项目领导获得项目控制权的一个途径。考虑项目方法某方面的作用时，始终要把握其对项目人员管理的效率，即在可能出现问题的地方争取正面效应。

二、项目定义

清晰的项目描述决定了你的项目控制能力，因为接下来所有工作都在描述范畴之内。不管你如何并为何要进行描述，你要对你的项目进行书面定义，让项目各方和项目组随时参考。

项目定义的形式和名称各式各样，包括：项目章程、提案、项目数据表、工作报告书、项目细则。这些名称的共同点在于，项目主管方和其他相关各方面从上而下地传达了他们对项目的期待。清晰的项目定义还包括以下方面：

1、项目目标陈述（一小段文字，对项目交付成果、工期、预期成本或人力进行高层次的描述）

2、项目回报（包括商业案例或投资分析的回报）

3、使用中的信息或客户需求

4、对项目范围进行定义，列出所有预期的项目成果

5、成本和时间预算目标

6、重大困难和假设

7、描述该项目对其他项目的依赖

8、高风险、所需的新技术、项目中的重大问题

努力将尽可能多的具体信息，囊括在项目描述或章程中，并使其在项目主管方和相关方面获得认可，进而生效。

三、合同与采购管理

不管你在你的组织内有多大的影响力和权力，你对受雇于其他公司的项目成员的影响会比较小。虽然不一定普遍适用，但你可以尽量不将项目工作外包，这是提高项目控制力的一个技巧。

在考虑启用合同商或外部顾问之前，对整体采购流程进行重检。寻找有服务合同起草经验并可以帮助你的人。

建立成功的外包关系需要时间和精力，这些工作要及早着手。为了不误项目工期，你要及时做到所有细节到位，所有合同及时签订。你打算外包哪部分项目交付成果，对这部分工作的细化就是你实施项目控制的着手点。记录这些细化内容、评估和接收标准、所有相关要求、必要时间规划。项目定义信息一定要包括在合同之内，相关责任及早确定。和所有你考虑到的供应商讨论这些要求，这样你的项目期望才会在各方之间明晰。

四、项目规划、执行、跟踪

作为项目领导，通过制定有力的规划、跟踪、执行流程，你可以建立项目控制的基础。争取各方面的支持，进而在项目内全面推广。

让项目组成员参与规划和跟踪活动，这可以争取大家的支持并提高积极性。睿智的项目领导往往大范围地鼓励参与，并通过流程汇聚大家的力量。当大家看到自己的努力以及对项目的贡献被肯定的时候，项目很快就从“他们的项目”变成“我们的项目”。当项目成员视项目工作为己任的时候，项目控制就会简单得多。较之于漠不关心的团队，此时的项目管理成功几率更大。运用项目管理流程也会鼓励项目成员的合作，这也让你的项目控制工作更加轻松。

五、变化管理

技术性项目中问题最集中的方面就是缺少对具体变化的管理控制。要解决这个问题，需要在项目的各方面启用有效的变化管理流程。

解决方法可以很简单，例如被项目团队、项目主办方、相关方认可的流程图。这提醒了项目人员，变化在被接受之前会进行细致地考察，并且提高了变化提案的门槛。

审查变化提案的时候，要注意该提案是否对变化有清晰到位的描述。如果变化提案的动因描述得不清不楚，该提案就要打回去，并且要求对变化所带来的益处进行定量评估。对于那些仅局限于技术解决方案的变化提案，要多打几个问号，因为提案人也许不能全面地判断问题。如果变化提案过多地关注问题的解决，而不注重实际问题，打回去并要求关注具体的业务形势。

最后，如果不接受某变化提案，一定要做到有理有据。而且，对项目时间、成本、精力等其他相关因素所受的影响，进行合理的估计。

六、风险管理

风险管理的流程能让你制定出全面的规划，找出潜在的麻烦，就风险问题的解决方法达成一致，根除严重的问题。

风险管理要做到事半功倍，就要与项目规划同时进行。进行项目工作分解安排时，注意对项目活动的不恰当理解；分配项目任务和开展评估时，寻找风险；资源匮乏或项目资源不足，或项目工作依赖于某一个人时，要知道风险的存在。分析项目工作将遇到的困难，鼓励所有参与规划的人在规划过程中，设想最坏的情况和潜在困难。

七、质量管理

质量管理提供了另一套搭建项目结构的流程，保证项目领导提出的工作要求一个不落地执行到位。项目质量的标准分两类：行业内实行的全球质量标准，公司或项目独有的质量标准。

如果你的公司实行或接受了质量标准，要注意该标准对你和你的团队有何要求。具体而言，这些标准会包括ISO 9000标准或六西格玛。进而确定质检清单、质控流程及相关要求，并将其与你的项目规划进行整合。项目必须遵守的书面步骤、报告、评估，对团队成员是强有力的推动，让大家步调一致。标准比你的临时要求更有效。

质量管理流程还能将项目要求与客户心声联系起来。不管你说什么，只要是在传递客户或用户的要求，你都要加以强调。市场调查、标杆分析、客户访谈都是评估和记录用户需求并确定项目要求价值的好工具。

八、问题管理

项目开展过程中问题的出现不可避免。在项目初期，在资源、工期、优先事项等其他方面为项目的问题管理确定流程。争取让团队支持及时发现、跟踪、解决问题的流程规定。建立跟踪流程，记录当前问题。问题记录信息包括：问题描述、问题特征或表现（用于沟通）、开始时间、责任人、目前状态、预计结束时间。

处理待解决问题的流程很简单，包括列出新问题的流程、定期复查待解决的问题、处理老问题的方法。对于没有太多组织管理权的项目领导而言，问题跟踪流程的力量在于让其把握了问题状态和进度的实时信息。一旦问题责任人承诺了问题解决的时限，你可以任意公布问题解决过程中的变数。不管问题责任人是本项目成员，还是其他项目或部门的成员，谁都不乐意随时将自己的大名置于人们质疑的目光中。问题清单的公开使得掌握该清单的人获得一定的影响力和控制力。

九、决策

项目管理时时有决策，快速得当的决策对于项目控制至关重要。即使项目领导掌握了控制权，完善的集体决策流程仍然裨益颇多，因为共同决策能获得更多内部支持，效果自然会更好。

项目工作中的决策绝非易事，项目组内纷繁复杂的观点让决策更加困难。项目各方认同的问题解决流程可以简化决策的过程，照顾各方要求。

尽早和你的项目组一起设立决策流程，或采用现有流程，或对现有流程做适当的修改。好的决策流程能为你的项目控制提供强有力的支持。该流程应该包括以下步骤：

1、清楚地陈述必须解决的问题。

2、吸纳所有需要参与决策或将会受该决策影响的成员参与决策过程，这样可以争取团队支持。

3、与项目组一道重审项目陈述，必要时进行修正，让每位成员获得一致认识。

4、针对决策标准（如：成本、时间、有效性、完整性、可行性），开展头脑风暴或讨论。选择那些与计划目标关联的、可执行、可供项目各方参考供决策之用的标准。

5、与项目组一道确定各标准的权重（所有标准的权重总和为100个百分点）。

6、设定决策的时限，规定用于调查、分析、讨论、最终决策的时间。

7、开展头脑风暴，在规定时间内尽可能多地产生决策想法。多方发展整个项目组都能接受的想法。

9、理性对待讨论中出现的异议。有必要的话，可增加决策标准。