信息系统项目管理师英文词汇

第一篇：信息系统项目管理师英文词汇

项目管理英文词汇

ABC Activity Based Costing 基于活动的成本核算 ABM Activity Based Management 基于活动的管理 ACWP Actual Cost of Work Performed 已完成工作实际成本

ADM Arrow Diagram Method 箭线图方法

ADP Automated Data Processing 自动化数据处理 ADR Alternative Dispute Resolution 替代争议解决方案

AF Actual Finish Date 实际完成日期

AFE Application for Expenditure 支出申请 AFE Authority for Expenditure 开支权 ALAP As-Late-As-Possible 尽可能晚

AMR Advanced Material Release 材料提前发布 AOA Activity on Arc 弧线表示活动双代号网络 AOA Activity on Arrow 箭线表示活动双代号网络 AON Activity on Node 节点表示活动单代号网络 AOQ Average Outgoing Quality平均出厂质量

AOQL Average Outgoing Quality Limit平均出厂质量限度

APMA Area of Project Management Application 项目管理的应用领域

APR Acquisition Plan Review 采购计划评审 AQL Acceptable Quality Level 可接受质量水平AS Actual Start Date 实际开始日期 ASAP As-Soon-As-Possible 尽快

ATP Acceptance Test Procedure 验收测试过程 AUW Authorized Unpriced Work 批准的未定价工作 BAC Budget at Completion 完工预算

BAC Baseline at Completion 完成/完工基线

BATNA Best Alternative to Negotiated Agreement 协议外最佳方案

BCM Business Change Manager 商业变更经理

BCWP Budgeted Cost of Work Performed 已完工作预算成本

BCWS Budgeted Cost of Work Scheduled 计划工作的预算成本

BEC Elapsed Cost 计划工作的预算成本

BOOT Build, Own, Operate, Transfer 建造拥有经营转让

BPA Blanket Purchase Agreement 一揽子采购协议 BSA Balanced Scorecard Approach平衡记分卡方法 C/SCSC Cost/Schedule Control System Criteria 成本控制系统标准?

C/SSR Cost/Schedule Status Report 成本/进度状态报告

CA Control Account 控制帐目

CAD Computer Aided Drafting/Design 计算机辅助制图/设计

CAM Cost Account Manager 成本帐目经理

CAM Computer Aided Manufacturing 计算机辅助制造 CAM Control Account Manager 控制帐目经理 CAP Cost Account Plan 成本帐目计划 CAP Control Account Plan 控制帐目计划

CAR Capital Appropriation Request 资本划拨请求 CBD Component-Based Development 基于构件的开发 CBS Cost Breakdown Structure 成本分解结构 CCB Change Control Board 变更管理委员会

CCDR Contractor Cost Data Report 承包商成本数据报告

CDR Critical Design Review 关键设计评审 CI Configuration Item 配置项 CM Configuration Management/Construction Management 配置管理/施工管理

CPFFC Cost Plus Fixed Fee Contract 成本加固定费用合同

CPI Cost Performance Index 成本绩效指数 CPI Cost Performance Indicator 成本绩效指数

CPIFC Cost Plus Incentive Fee Contract 成本加奖励费用合同

CPM Critical Path Method 关键路径法

CPN Critical Path Network 关键路径网络图

CPPC Cost Plus Percentage of Cost Contract 成本加成本百分比合同

CPR Cost Performance Ratio 成本绩效比率 CPR Cost Performance Report 成本绩效报告 CPU Central Processing Unit 中央处理单元 CR Change Request 变更请求

CSCI Computer Software Configuration Item 计算机软件配置

CSF Critical Success Factors 关键的成功因素 CTC Contract Target Cost 合同目标成本 CTP Contract Target Price 合同目标价格

CTR Cost-Time Resource Sheet 成本时间资源表 CV Cost Variance 成本偏差

CWBS Contract Work Breakdown Structure 合同工作分解结构

DBA Database Administrator 数据库管理员 DBM Dynamic Baseline Model 动态基线模型

DBMS Database Management System 数据库管理系统 DCE Distributed Computing Environment 分布式计算环境

DCF Discounted Cash Flow 折现现金流 DD Data Date 数据日期

DID Data Item Description 工作项描述

DRD documentation Requirements Description 文档要求说明

DU Duration 工期持续时间

EAC Estimated Actual at Completion 实际完工估算 ECC Estimated Cost to Complete 尚未完成的成本估算 ECP Engineering Change Proposal 工程变更建议书 EF Early Finish Date 最早完成日期

EFC Estimated Final Cost 估算的最终成本

EMR Expenditure Management Report 支出管理报告 EPS Enterprise Project Structure 企业项目结构 ERP Enterprise Resource Planning 企业资源规划 ERPS Enterprise Resource Planning Systems 企业资源规划系统

ES Early Start Date 最早开始日期

ESAR Extended Subsequent Applications Review 扩展后续应用评审

ETC Estimate To Complete 尚未完成/完工的估算 EV Expected value 期望值

EVMS Earned value Management System 挣值管理系统 FAC Forecast At Completion 完工预测 FF Free Float 自由浮动时间

FFP Firm Fixed Price Contract 严格固定价格合同 FIFO First In, First Out 先进先出 FM Functional Manager 职能经理

FP Fixed Price Contract 固定价格合同

FPPIF Fixed Price Plus Incentive Fee Contract 固定价格加激励酬

FTC Forecast to Completion 完工尚需预测 FTP File Transfer Protocol 文件传输协议

G&A General and Administrative Costs 综合行政管理成本

G&A General and Administrative 综合行政管理费 GAAP Generally Accepted Accounting Principles 公认会计原则

GERT Graphical Evaluation and Review Technique 图形评审技术

GUI Graphical User Interface 图形用户界面 项目管理专用中英文术语词汇

1、活动，Activity

2、活动定义，Activity Definition3、活动描述/说明，AD=Activity Description

4、活动历时估算，Activity Duration Estimating

5、箭线网络图（双代号网络图），AOA=Activity-On-Arrow

6、节点式网络图（单代号网络图），AON=Activity-on-Node7、已执行工作实际成本，ACWP=Actual Cost of Work Performe*

8、实际完成日期，**=*ctual Finish Date

9、实际开始日期，AS=Actual Start Date

10、行政收尾，Administrative Closure

11、箭线，Arrow12、箭线图示法，ADM=Arrow Diagramming Method

13、逆推计算法，Backward Pass

14、横道图，Bar Chart

15、基准计划，Baseline16、完工预算，BAC=Budget At Completion

17、概算，Budget Estimate18、已执行预算成本，BCWP=Budgeted Cost of Work Performed19、计划执行预算成本，BCWS= Budgeted Cost of Scheduled20、日历单位，Calendar Unit21、变更控制委员会，CCB=Chang Control Board

22、沟通规划，Communications Planning

23、并行工程，Concurrent Engineering

24、意外费用，Contingencies25、意外准备金，contingency Allowance

26、意外规划，Contingency Planning

27、意外储备，Contingency Reserve

28、合同，Contract29、合同管理，Contract Administration 30、合同收尾，Contract Close-out

31、控制，Control32、控制图，Control Chart33、纠正措施，Corrective Action

34、费用预算，Cost Budgeting

35、费用控制，Cost Control

36、费用做算，Cost Estimating

37、质量成本，Cost of Quality38、费用绩效指数，CPI=Cost Performance Index

39、费用偏差，CV=Cost Variance 40、赶工，Crashing41、关键工序，Critical Activity

42、关键路线，Critical Path43、关键路线法，CPM=Critical Path Method

44、当前完成日期，Current Finish Date

45、当前开始日期，Current Start Date

46、数据日期，DD=Data Date

47、交付物，Deliverable

48、依赖关系，Dependency

49、虚活动，Dummy Activity 50、延续时间，DU=Duration51、延续时间压缩，Duration Compression

52、最早完工日期，EF=Early Finish Date

53、最早开始日期，ES=Early Start Date

54、挣值法，EV=Earned value55、挣值分析，Earned value Analysis

56、人工量，Effort57、估算，概算，Estimate58、在完成时的费用估算，EAC=Estimate At Completion

59、到完成时的估算，ETC=Estimate To Complete 60、单节点事件图，Event-on-Node 61、例外报告，Exception Report 62、完成日期，Finish Date63、完成到完成关系，FF=Finish-to-Finish 64、完成到开始关系，FS=Finish-to-Start 65、时差，机动时间，浮动时间，Float 66、顺推计算法，Forward Pass 67、自由时差，FF=Free Float68、职能经理，Functional Manager 69、职能组织，Functional Organization 70、甘特图，Gantt Chart71、图解评审技术，GERT=Graphical Evaluation and Review Technique72、集合工作，Hammock 73、悬摆，Hanger74、信息分发，Information Distribution 75、立项，Initiation76、成本/进度综合报告，Integrated Cost/Schedule Reporting77、邀标，IFB= Invitation for Bid78、关键事件进度计划，Key Event Schedule 79、滞后量，Lag80、最晚完成日期，LF=Late Finish Date 81、最晚开始日期，LS=Late Start Date 82、提前量，Lead83、全生命期成本估算，Life-cycle Costing 84、产品经理，Line Manager 85、逻辑图，Logic Diagram86、逻辑关系，Logical Relationship 87、回路，Loop88、管理储备量，Management Reserve 89、主进度计划，Master Schedule 90、矩阵型组织，Matrix Organization 91、里程碑，Milestone92、里程碑进度计划，Milestone Schedule93、现代项目管理，MPM=Modern Project Management 94、监控，Monitoring95、蒙托卡罗分析，Monte Carlo Analysis 96、次关键工作，Near-Critical Activity 97、网络，Network98、网络分析，Network Analysis 99、网络逻辑，Network Logic 100、网络路线，Network Path 101、节点，Node102、组织分解结构，OBS=Organizational Breakdown Structure103、组织规划，Organizational Planning 104、整体变更控制，Overall Change Control 105、重叠，Overlap106、参数估算法，Parametric Estimating 107、线路，Path108、线路时差，Path Float109、完成百分比，PC=Percent Complete

110、执行报告，Performance Reporting 111、执行机构，Performing organization 112、计划评审技术图，PERT Chart113、计划的完成日期，PF=Planned Finish Date 114、计划的开始日期，PS=Planned Start Date 115、优先图示法，PDM=Precedence Diagramming Method 116、优先关系，Precedence Relationship 117、紧前工作，Predecessor Activity 118、采购规划，Procurement Planning 119、工程，Program120、计划评审技术，PERT=Program Evaluation and Review Technique 121、项目，Project122、项目许可证，Project Charter123、项目沟通管理，Project Communication Management 124、项目费用管理，Project Cost Management125、项目人力资源管理，Project Human Resource Management126、项目综合管理，Project Integration Management 127、项目生命周期，Project Life Cycle128、项目管理，PM=Project Management129、项目管理知识体系，PMBOK=Project Management Body of Knowledge130、项目管理软件，Project Management Software 131、项目管理团队，Project Management Team 132、项目经理，PM=Project Manager133、项目网络图，Project Network Diagram 134、项目阶段，Project Phase 135、项目计划，Project Plan136、项目计划开发，Project Plan Development 137、项目计划实施，Project Plan Execution 138、项目规划，Project Planning139、项目采购管理，Project Procurement Management 140、项目质量管理，Project Quality Management 141、项目风险管理，Project Risk Management 142、项目进度计划，Project Schedule143、项目范围管理，Project Scope Management 144、项目团队成员，Project Team Member 145、项目时间管理，Project Time Management 146、项目型组织，Project Organization 147、质量保证，QA=Quality Assurance 148、质量控制，QC=Quality Control 149、质量规划，Quality Planning150、剩余持续时间，RDU=Remaining Duration 151、请求建议书，RFP=Request for Proposal 152、请求报价单，RFQ=Request for Quotation 153、储备量，Reserve154、资源平衡，Resource Leveling155、资源约束进度计划，Resource-Limited Schedule 156、资源规划，Resource Planning157、责任分配矩阵，RAM=Responsibility Assignment Matrix158、责任图，Responsibility Chart 159、责任矩阵，Responsibility Matrix 160、保留金，Retain age 161、突发事件，Risk Event162、风险识别，Risk Identification163、风险应对控制，Risk Response Control164、风险应对开发，Risk Response Development 165、S曲线，S-Curve 166、进度计划，Schedule167、进度计划分析，Schedule Analysis 168、进度计划压缩，Schedule Compression 169、进度计划控制，Schedule Control170、进度执行指数，SPI=Schedule Performance Index 171、进度偏差，SV=Schedule Variance172、计划完成日期，SF=Scheduled Finish Date 173、计划开始日期，SS=Scheduled Start Date 174、范围，Scope175、范围基准计划，Scope Baseline 176、范围变更，Scope Change177、范围变更控制，Scope Change Control 178、范围定义，Scope Definition 179、范围规划，Scope Planning 180、范围验证，Scope Verification 181、时差，Slack182、询价，Solicitation183、询价规划，Solicitation184、工作人员招募，Staff Acquisition 185、项目相关者，Stakeholder 186、开始日期，Start Date187、开始到完成关系，Start-to-Finish 188、开始到开始关系，Start-to-Start189、工作说明，SOW=Statement of Work 190、子网，Subnet191、子网络，Subnet Work192、后续工作，Successor Activity193、目标完成日期，TC=Target Completion Date 194、目标时度计划，Target Schedule 195、任务，Task196、团队建设，Team Development 197、团队成员，Team members198、时标网络图，Time-Scaled Network Diagram 199、目标完成日期，TF=Target Finish Date 200、目标开始日期，Ts=Target Start Date 201、总时差，TF=Total Float202、全面质量管理，TQM=Total Quality Management 203、权变措施，Workaround204、工作分解结构，WBS=Work Breakdown Structure 205、工作包，Work Package

第二篇：2015下半年信息系统项目管理师考试英文词汇汇总

2015下半年信息系统项目管理师考试英文词汇汇总

1、ABCActivityBasedCosting基于活动的成本核算

2、ABMActivityBasedManagement基于活动的管理

3、ACWPActualCostofWorkPerformed已完成工作实际成本

4、ADMArrowDiagramMethod箭线图方法

5、ADPAutomatedDataProcessing自动化数据处理

6、ADRAlternativeDisputeResolution替代争议解决方案

7、AFActualFinishDate实际完成日期

8、AFEApplicationforExpenditure支出申请

9、AFEAuthorityforExpenditure开支权

10、ALAPAs-Late-As-Possible尽可能晚

11、AMRAdvancedMaterialRelease材料提前发布

12、AOAActivityonArc弧线表示活动双代号网络

13、AOAActivityonArrow箭线表示活动双代号网络

14、AONActivityonNode节点表示活动单代号网络

15、AOQAverageOutgoingQuality平均出厂质量

16、AOQLAverageOutgoingQualityLimit平均出厂质量限度

17、APMAAreaofProjectManagementApplication项目管理的应用领域

18、APRAcquisitionPlanReview采购计划评审

19、AQLAcceptableQualityLevel可接受质量水平

20、ASActualStartDate实际开始日期

21、ASAPAs-Soon-As-Possible尽快

22、ATPAcceptanceTestProcedure验收测试过程

23、AUWAuthorizedUnpricedWork批准的未定价工作

24、BACBudgetatCompletion完工预算

25、BACBaselineatCompletion完成/完工基线

26、BATNABestAlternativetoNegotiatedAgreement协议外最佳方案

27、BCMBusinessChangeManager商业变更经理

28、BCWPBudgetedCostofWorkPerformed已完工作预算成本

29、BCWSBudgetedCostofWorkScheduled计划工作的预算成本

30、BECElapsedCost计划工作的预算成本

31、BOOTBuild,Own,Operate,Transfer建造拥有经营转让

32、BPABlanketPurchaseAgreement一揽子采购协议

33、BSABalancedScorecardApproach平衡记分卡方法

34、C/SCSCCost/ScheduleControlSystemCriteria成本控制系统标准

35、C/SSRCost/ScheduleStatusReport成本/进度状态报告

36、CAControlAccount控制帐目

37、CADComputerAidedDrafting/Design计算机辅助制图/设计

38、CAMCostAccountManager成本帐目经理

39、CAMComputerAidedManufacturing计算机辅助制造

40、CAMControlAccountManager控制帐目经理

41、CAPCostAccountPlan成本帐目计划

42、CAPControlAccountPlan控制帐目计划

43、CARCapitalAppropriationRequest资本划拨请求

44、CBDComponent-BasedDevelopment基于构件的开发

45、CBSCostBreakdownStructure成本分解结构

46、CCBChangeControlBoard变更管理委员会

47、CCDRContractorCostDataReport承包商成本数据报告

48、CDRCriticalDesignReview关键设计评审

49、CIConfigurationItem配置项

50、CMConfigurationManagement/ConstructionManagement配置管理/施工管理

51、CPFFCCostPlusFixedFeeContract成本加固定费用合同

52、CPICostPerformanceIndex成本绩效指数

53、CPICostPerformanceIndicator成本绩效指数

54、CPIFCCostPlusIncentiveFeeContract成本加奖励费用合同

55、CPMCriticalPathMethod关键路径法

56、CPNCriticalPathNetwork关键路径网络图

57、CPPCCostPlusPercentageofCostContract成本加成本百分比合同

58、CPRCostPerformanceRatio成本绩效比率

59、CPRCostPerformanceReport成本绩效报告

60、CPUCentralProcessingUnit中央处理单元

61、CRChangeRequest变更请求

62、CSCIComputerSoftwareConfigurationItem计算机软件配置

63、CSFCriticalSuccessFactors关键的成功因素

64、CTCContractTargetCost合同目标成本

65、CTPContractTargetPrice合同目标价格

66、CTRCost-TimeResourceSheet成本时间资源表

67、CVCostVariance成本偏差

68、CWBSContractWorkBreakdownStructure合同工作分解结构

69、DBADatabaseAdministrator数据库管理员

70、DBMDynamicBaselineModel动态基线模型

71、DBMSDatabaseManagementSystem数据库管理系统

72、DCEDistributedComputingEnvironment分布式计算环境

73、DCFDiscountedCashFlow折现现金流

74、DDDataDate数据日期

75、DIDDataItemDescription工作项描述

76、DRDdocumentationRequirementsDescription文档要求说明

77、DUDuration工期持续时间

78、EACEstimatedActualatCompletion实际完工估算

79、ECCEstimatedCosttoComplete尚未完成的成本估算

80、ECPEngineeringChangeProposal工程变更建议书

81、EFEarlyFinishDate最早完成日期

82、EFCEstimatedFinalCost估算的最终成本

83、EMRExpenditureManagementReport支出管理报告

84、EPSEnterpriseProjectStructure企业项目结构

85、ERPEnterpriseResourcePlanning企业资源规划

86、ERPSEnterpriseResourcePlanningSystems企业资源规划系统

87、ESEarlyStartDate最早开始日期

88、ESARExtendedSubsequentApplicationsReview扩展后续应用评审

89、ETCEstimateToComplete尚未完成/完工的估算

90、EVExpectedvalue期望值

91、EVMSEarnedvalueManagementSystem挣值管理系统

92、FACForecastAtCompletion完工预测

93、FFFreeFloat自由浮动时间

94、FFPFirmFixedPriceContract严格固定价格合同

95、FIFOFirstIn,FirstOut先进先出

96、FMFunctionalManager职能经理

97、FPFixedPriceContract固定价格合同

98、FPPIFFixedPricePlusIncentiveFeeContract固定价格加激励酬

99、FTCForecasttoCompletion完工尚需预测

100、FTPFileTransferProtocol文件传输协议

101、G&AGeneralandAdministrativeCosts综合行政管理成本

102、G&AGeneralandAdministrative综合行政管理费

103、GAAPGenerallyAcceptedAccountingPrinciples公认会计原则

104、GERTGraphicalEvaluationandReviewTechnique图形评审技术

105、GUIGraphicalUserInterface图形用户界面

第三篇：信息系统项目管理师

信息系统项目管理师

http://

论项目的综合管理

【摘要】

2006年4月，我有幸参与了国家发改委投资建设的“XXX部委办公业务资源信息系统”项目的工程建设，并担任应用系统建设方的项目经理，负责项目的整体规划、组织实施和管理控制。由于该项目规模大、涉及范围广，参与人员和公司众多，具有大型复杂项目特点，首先建立适合该项目的过程管理体系，以指导、管理和约束各方以一致的方式来实施项目。通过制定“三审”制管理和控制项目实施，制定变更管理制度有效管控项目变更，通过项目分项验收、初步验收和竣工验收的三阶段验收过程来保证项目的成功收尾。在项目的实施过程中，我以积极的态度推动项目进展，加强各方沟通，平衡相关干系人的利益，有效地控制了项目的范围和进度，确保了项目的质量，最终顺利完成了该项目，取得了用户高度的认可。【正文】

为进一步增强XXX部委工作的科学性和民主性，提高XXX部委的工作效率和质量，在XXX领导、原信息产业部部长吴基传同志的领导和指导下，由XXX部委常委会办公厅向国家发改委申请建设“XXX部委办公业务资源信息系统”。经国家发改委批复，总投资金额为XXXX万元，其中应用系统包为3056万，由我公司承建。该项目于2006年X月正式启动，我有幸被公司任命为现场项目经理，全面主持该项目的管理工作。该项目的应用系统建设内容包括XXX部委...六大业务应用系统，合计37个子系统。经过两年多的系统建设和试运行，在支撑XXX代表大会和常委会的代表、会议管理方面发挥了重要作用，初步实现了XXX部委立法、监督工作的全业务流程管理，进一步增强机关整体信息化水平

信息系统项目管理师

http:// 和办公工作效率，得到了业主和最终用户的高度认可。

在该项目领导小组的亲切关怀和具体指导下，业主的全力配合与支持下，我与项目组全体同仁一起并肩作战，克服种种困难，历经两年多的系统建设和试运行，于2009年10月全面通过了验收委员会的竣工验收。

该项目的成功实施，我们认为得益于有效的项目整体管理机制，下面结合笔者实际经验，简要介绍该项目的整体管理过程和方法。

一、制定项目管理规划

XXX部委项目具有项目规模大、建设周期长、政治及社会意义重大、涉及领域广且复杂等特点，需要按照大型项目建设特点并参照国家电子政务工程建设标准规范对项目进行整体规划。具体规划工作如下：

1、大型及复杂项目在制定项目计划前，需要建立一套适合本项目的项目管理过程体系，XXX部委项目的业主方、监理方和各承建方对此有足够的认识，委托我们牵头起草制定《XXX部委项目工程建设管理办法》，经过多次讨论、审议并通过了该管理办法。该项目管理办法要求打破各承建公司界限，成立工程总体组，统一管理项目的实施工作。提出以应用为龙头，指导网络、安全系统的建设；建立项目管理和控制流程，建立项目沟通机制和采购管理制度等；为后续制定详细项目管理计划和项目实施提供了依据。

2、在制定项目管理计划过程中，根据该项目自身特点，我们划分了项目阶段、制定了范围管理计划、质量管理计划、配置管理计划、沟通管理计划、采购管理计划及工程档案管理计划等内容。对于项目阶段的划分，考虑到该项目业务需求的不确定性以及应用支持平台选型的关键问题，我们提出将项目划分为两个大的阶段，第一阶段为业务需求的原型法求证和应用支持平台的选型技术论证，信息系统项目管理师

http:// 并通过试点应用以进一步确认。第二阶段是在第一阶段成果基础上基于成熟的应用支持平台产品全面开展系统开发、测试、上线及试运行工作。对于范围管理计划，我们严格按照发改委批复的初步设计开展项目范围管理工作，如项目范围发生变更，根据《国家发改委的电子政务工程管理办法》，向发改委进行报备。为满足国家档案局对该项目的项目档案验收的要求，我们配合业主和监理制定了项目档案管理办法，对项目从招投标开始到项目竣工验收全过程的过程文件进行管理和归档。

3、项目管理计划经过了多次评审，并确立了里程碑基线。在工程建设及试运行期间，我们不断对项目管理计划进行调整和更新，以适应新形势的变化。

二、项目执行及管控

项目执行及管控是对实现项目管理计划所规定的工作进行实施、管理和监控的过程。根据项目管理计划，为便于分工和管理，我将项目团队分为总体组、六个业务应用开发组、平台技术组、数据库组、系统测试组、配置管理组和标准规范组。其中总体组由项目经理和技术总监组成，负责项目的管控和技术总把关，并向业主和监理汇报。其他各组均设立组长，明确分工和职责。六个业务组对应六大业务应用系统的具体开发工作，其他职能组协助系统的开发和管理工作。合理建立项目组织机构为项目实施开展提供了有力组织保障。

在项目整体管控方面，建立了“三审”制度。每一项建设任务均按开工审查、上线部署审查、分项验收审查三个阶段实施审查；每一项采购（硬件设备及系统软件）均按采购申请审批、询价申报审批、到货验收三个流程实施审查。我们作为承建方，在每一个系统上线或采购前均严格执行三审制度，进行汇报、接收审查及获得验收确认。

信息系统项目管理师

http://

根据工程建设具体情况，需要阶段性接收业主方工作审查。我带领项目组开展项目绩效的收集，讨论并形成阶段性工作汇报PPT，通过会议形式向业主汇报接收审查，业主根据我们的绩效情况提出具体的整改要求，并在监理监督下,会后开展具体的整改工作。

三、整体变更控制

整体变更控制过程用来审查所有变更请求，批准变更，并维护项目管理计划、项目范围说明书和其他可交付成果。由于该项目时间跨度大、涉及内容广，在项目的实施过程中，因换届、机构调整、部门领导变动等因素导致需求发生了较大的变化，为规范项目变更管理，由监理牵头，各方参与制定了《项目变更管理办法》。该办法明确了变更控制流程和变更文档模板，并成立变更控制委员会，主要由信息中心领导、业务处处长及科员组成，必要时邀请专家顾问参与。项目组依据该办法先进行需求调研及分析，确认与用户理解一致后，提出变更后的实施方案，随变更请求，提交变更控制委员会进行批准。批准通过后，需更新项目管理计划等文档作为项目控制基线。变更请求文档，更新的项目文档作为过程文档进行管理。对于建设需求变化较大的，比如子系统级的变更、第三方采购软件选型变更等，需根据发改委《关于进一步加强国家电子政务工程建设项目管理工作的通知》中的相关规定，在规定的调整范围内进行变更得，需对变更原因、变更内容、涉及费用等情况说明并向发改委进行报备。

四、项目收尾

项目收尾指完结项目管理计划中规定的所有活动以正式结束项目的过程。该项目的收尾或验收需依据《国家电子政务验收大纲》的要求，分为分项验收、工程初步验收和竣工验收三个阶段。由于项目规模大，分系统众多，又涉及第三方

信息系统项目管理师

http:// 转包和采购，使得项目验收的工作量很大。在项目建设后期，几乎耗费了我全部的时间用于项目验收工作。为顺利完成项目验收，我采取了在项目组内部成立验收文档组，调动其它分组组长参与具体的验收相关工作的措施。下面简要介绍三个阶段的验收过程：

分项验收是项目整体验收的基础和关键，分项验收需要最终用户出具用户使用报告，作为分项验收不可缺少的依据。出具用户使用报告需要最终用户单位报各级领导层层审批，加上领导通常很忙，效率很低。有时赶上某位领导出差，要等上一周的时间；有时用户单位的领导怕担责任，相互推诿，能拖则拖。针对这些情况，我通常先走正常的审批流程，不断监控审批情况，一旦发现有拖延，就加强督促力度；遇到用户领导推诿或是不想签的情况，我会同信息中心局领导沟通，请他们出面协调最终用户主管局领导协商解决。随着各分系统的上线和试运行，我们采取了“成熟一个，验收一个”的策略，经过9个月的努力，完成了共xx项的全部分项验收工作，为工程初步验收打下了坚实基础。

为顺利通过专家组的初步验收审查，项目组采取了按终验标准准备的策略，一是聘请第三方测评机构进行系统验收测试、风险评估和等级化保护测评两项测评工作；二是准备初步验收总报告、工程、技术、财务和档案分项报告；三是邀请工程、技术、财务和档案专家组提前入场指导验收工作。在监理的统一协调管理下，各承建单位打破公司界限，成立验收工作准备小组，开展验收准备工作。期间，我组织应用系统项目团队召开了验收动员大会，要求团队各成员以配合验收工作为首要任务，积极推进验收工作的开展。经过一个多月紧张的准备工作，项目组于2008年XX月XX日在XXX召开了工程初步验收会议。会议期间，我们负责专家提问的关于应用系统建设部分的应答、配合分项专家组出具分项验收

信息系统项目管理师

http:// 报告，配合专家总体组出具初步验收报告。最终顺利通过了初步验收。

完成了初步验收工作，工程整体进入了试运行阶段，为完成竣工验收工作，我们主要完成了三方面的工作：一是大力推进办公平台在全机关各单位的全面应用；二是根据初步验收专家组和第三方测评机构提出的整改意见组织力量开展各项整改工作；三是编制工程试运行报告、工程整改报告和典型应用案例，配合业主形成竣工验收申请材料，向国家发改委提出竣工验收申请。因准备工作充分，本次竣工验收获得了专家的高度认可，并顺利通过。

从该项目启动到竣工验收，经历了三年多的时间，总结整个项目的实施，我们认为得益于在项目初期阶段就建立了符合大型复杂项目特点的项目管理过程体系，引入了项目整体管理理念和方法，对项目进行了科学、规范的整体管理。通过项目整体管理，使项目所有的组成要素在适当的时间充分地、有机地结合在一起，极大地提高了项目的实施效率。

如需了解更多信息系统项目管理师资讯请到希赛网进行查看！

第四篇：信息系统项目管理师要点

项目建议书： 1.项目必要性 2.项目的市场预测

3.产品方案或服务的市场预测 4.项目建设的必需条件

技术类的立项申请书： 1.项目名称

2.项目建设的必要性和依据 3.项目目的、作用及意义

4.国内外技术发展概况、水平、趋势 5.研究领域，关键技术，研究内容，技术方案、规模、进度安排 6.开发情况、工作基础和设备条件 7.项目负责人，主要的技术人员 8.项目起止时间，最终目标，前景及预期的考核的技术经济指标 9.项目经费预算、用途和用款计划 项目评估报告的内容： 1.项目概况 2.评估目标 3.评估依据 4.评估内容

5.评估机构和评估专家 6.评估过程 7.详细评估意见

8.存在或遗漏的重大问题 9.潜在风险 10.评估结论11.进一步建议

计划的编制原则：全局、全过程 1.目标的统一管理 2.方案的统一管理 3.过程的统一管理 7.应该包括项目管理工作，包括分包出去工作 8.遵循8/80原则

WBS的用途： 1.是展现全貌，详细说明完成项目必须完成各项工作的计划工具 2.是清晰地表示各项目工作之间的项目联系的结构设计工具 3.是帮助项目经理和团队确定和管理项目所涉及的工作的依据 4.定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具 详细的项目范围说明书的内容1.项目和范围目标

2.产品或服务的需求和特性 质量保证活动： 1.制定质量标准 2.制定治疗控制流程

3.制定质量保证采用方法和技术 4.建立质量保证体系及评估 质量保证作用：

1.是保证质量的一个重要环节 2.为持续质量改进供基础和方法3.为项干人提供对于质量的信任 4.是质量管理的一个重要内容 5.与质量控制共同构成对质量的跟踪和保证 质量管理保证内容 1.制定质量标准 2.制定质量控制流程

3.提出质量保证采用方法和技术 5.组织纪律性强

6.互相信任，善于总结和学习有效管理原则：

1.对团队有耐心，态度良好 2.解决问题而非抱怨成员3.定期召开有效会议 4.将团队控制在3-7人

5.规划社会活动，熟悉彼此 6.给予成员同等压力

7.培养鼓励成员帮助其他成员 8.认可个人和团队成绩

绩效考核可能带来问题： 1.赶工或偷工减料降低质量 2.员工超负荷劳动，影响质量士气 3.只追求目前的项目按时交付 4.只追求本项目成功，无能力积累 4.计时法 5.风险分类

6.风险概率和影响的定义 7.概率和影响矩阵

8.修改的利害关系者承受度 9.汇报格式 10.跟踪

风险特征：

1.是损失或损害 2.是一种不确定性 3.是针对未来的 4.是客观存在的 5.是相对的6.是预期和后果之间的差异 风险识别内容：

1.识别并确定项目哪些潜在风险3.4.5.6.7.建立配置管理系统 变更管理 版本管理 配置状态报告 配置审计

配置识别内容：

1.识别需要受控的软件配置项 2.给每个产品和其组件及文档分配唯一标识

3.定义每个配置项重要特征以及识别其所有者 4.识别组件、数据及产品获取点和准则

5.建立和控制基线

6.维护文档和组件的修订与产品版本之间关系 建立配置管理方案步骤：

绩效报告内容：

1.项目进展和投资情况 2.项目的完成情况

3.项目总投入、资金到位情况 4.项目资金实际支出情况 5.主要需要情况 6.财务制度执行情况

7.项目团队个职能团队绩效 8.项目执行过程中存在的问题 9.预测 10.变更请求

11.其他需要说明的问题

项目变更主要原因：

1.项目外部环境发生变化

2.项目范围的计划编制不周密详细，有遗漏 3.市场上新技术、新手段、新方案 10.其他

详细可研的内容： 1.概述 2.需求确定

3.现有资源、设施情况分析 4.设计（初步）技术方法 5.项目实施进度计划

6.投资估算和资金筹措计划 7.项目组织、人力、技术培训计划 8.经济和社会效益分析 9.合作协作方式

项目论证作用

1.确定项目是否实施的依据 2.资金筹措、向银行贷款的依据 3.编辑计划、设计、采购、实施以及机构设置、资源配置的依据 4.防范风险、提高效率的重要保证 可行性研究步骤：

1.明确项目的目标和规模 2.研究正在运行的系统 3.建立新系统的逻辑模型 4.导出和评价各种方案 5.推荐可行性方案 6.编写可行性研究报告 7.递交可行性研究报告

需求开发：

1.获取2.分析 3.定义4.验证 需求管理流程：

1.制定需求管理计划 2.求得对需求理解 3.求得对需求承诺 4.管理需求变更

5.维护对需求双向跟踪

6.识别识别工作与需求不一致性 需求管理变更原则

1.谨慎对待，尽量控制变更 2.高度重视需求变更 3.签署变更控制协议

4.在基线基础上做好变更

5.需有好的变更控制工具的支持 6.吧项目变化融入项目计划 7.及时发布变更信息 需求说明书：

1.完整性2.一致性 3.可修改4.可跟踪

项目章程的内容： 1.项目需求，反应干系人要求期望 2.项目须实现商业需求、项目概述或产品需求

3.项目的目的或立项理由 4.委派的项目经理并授权 5.概要的里程碑进度计划 6.项目干系人的影响 7.职能组织及其参与

8.组织的、环境的和外部的假设 9.组织的、环境的和外部的约束 10.论证业务方案，包括投资回报率 11.概要预算

项目启动的主要活动： 1.识别项目需求 2.解决方案的确定

3.对项目进行可行性分析 4.项目立项

5.项目章程的确定

4.计划的统一管理 5.人力资源的统一管理

6.技术工作与管理工作协调统一 7.各干系人参与 8.逐步求精

项目整体管理计划内容： 1.项目背景 2.项目干系人

3.项目总体技术解决方案 4.所使用的项目管理过程

5.每个特定管理过程的实施程度 6.完成这些项目的工具技术描述 7.选择项目周期和相关项目阶段 8.如何用选定过程管理具体项目 9.如何执行工作完成项目目标 10.如何监督和控制变更 11.如何实施配置管理

12.如何维护项目绩效基线完整性 13.项目干系人沟通的要求和技术 14.为项目选择的生命周期模型 15.为解决遗问和未定决策，对内容、严重和紧迫程关键管理评审 项目管理计划编制流程

1.明确项目目标和阶段目标 2.成立初步的项目团队 3.工作准备和信息收集 4.依据标准、模板编初步概要项划 5.编写范围、质量、进度等分计划 6.将分计划纳入，进行平衡优化 7.项目经理负责组织编项目计划 8.评审与批准项目计划

9.项目获批，形成项目基准计划 范围管理内容 1.确定项目需求

2.定义规划项目的范围 3.范围管理的实施 4.范围变更控制管理 5.范围核实

项目范围管理计划的内容：

1.根据初步的项目范围说明书编制详细项目范围说明书的方法 2.从详细的项目范围说明书创建WBS的方法

3.关于正式确认和认可已完成交付物方法的详细说明

4.有关控制需求变更如何落实到详细的项目范围说明书的方法 WBS制定过程

1.识别和分析项目可交付物和与其相关的工作 2.构造和组织WBS

3.把高层的WBS分解为低层次、详细工作单元

4.为WBS工作单元分配代码 5.确认分解程度是必要的充分的 WBS分解原则

1.各层次上保持完整性，避免遗漏 2.一个工作单元只属于某上层，避免交叉从属

3.系统层次工作单元性质相同 4.工作单元应能分开不同责任者和工作内容

5.便于满足项目管理计划，控制的管理需要

6.最底层工作具有可比性，可管理，定量检查

3.项目需求和可交付物 4.项目的验收标准 5.项目边界

6.项目的约束条件 7.项目的假设条件 8.初始的项目组织 9.初始风险 10.进度里程碑 11.初步分解结构 12.资金限制 13.14.项目配置管理需求 15.项目规范 16.范围变更控制关注内容：

1.对造成范围变更因素施加影响，以确保该变更得到一致的认可 2.确定范围变更是否已经发生 3.当变更发生时，管理实际的变更 进度变更控制关注内容： 1.确定项目进度当前状态

2.对引起进度变更因素加以影响，以保证该变化朝有利方向发展 3.确定项目进度是否已经变更 4.当变更发生时，管理实际变更 成本变更控制关注的内容：

1.对造成成本基准变更的因素施加影响

2.确保成本基准变更获得同意 3.当变更产生时，管理实际的变更 4.确保潜在的成本超支不超过授权项目阶段资金和总体资金 5.监督成本执行绩效，找出与成本基准的偏差

6.准确记录所有与成本基准偏差 7.防止错误、不恰当、未批准的变更被纳入成本或资源使用报告 8.就审定的变更通知项目干系人 9.采取措施，将预期的成本超支控制在可接受的范围内 编制成本预算的原则： 1.要以项目需求为基础 2.要与项目目标相联系，同时考虑质量和进度目标 3.要切实可行 4.应当留有弹性

成本估算的主要步骤：

1.识别并分析项目成本构成科目 2.根据识别的项目成本构成科目，估算每一科目的成本大小 3.分析估算的成本结果，找出各种可以相互替代的成本，协调各成本之间的比例关系 成本预算步骤：

1.将项目总成本分摊到WBS的各个工作包

2.将各个工作包成本分摊到所包含的活动上

3.确定各项成本预算支出的时间计划及项目成本预算计划 质量管理流程：PDCA 1.确立质量标准体系

2.对项目时候死进行质量监控3.将实际与便准对照 4.纠偏纠错

4.建立质量保障体系

质量管理保证方法

1.首先执行项目的质量管理计划 2.采用质量保证的工具和技术 3.提出相应的质量整改措施，如建议的纠正措施，对项目计划更新 质量保证人员工作

1.制定计划和质量标准 2.实施质量检查 3.分析、解决问题，验证解决问题 4.给干系人质量报告 5.培训和指导

质量控制的步骤： 1.选择控制对象

2.确定控制对象的标准和目标 3.制定实施计划，确定保证措施 4.执行计划

5.对实施情况跟踪监测、检查，将监测结果与标准和计划比较 6.发现并分析偏差

7.根据偏差情况采取措施 提升项目质量 1.强有力的领导

2.建立组织级的项目管理体系 3.建立组织级的质量管理体系 4.建立组织级的激励制度 5.理解质量成本 6.提高文档质量

7.发展和遵从成熟度模型 提升质量步骤

1.建立项目质量目标

2.建立质量保证和控制流程 3.建立质量参数度量体系 4.对过程和产品检查，比对发现质量问题，监督控制问题的处理 5.对质量问题分析，找出改进措施 6.不断循环 人员配备管理计划： 1.组建项目团队 2.时间表

3.人力资源释放安排 4.培训需求 5.表彰和奖励 6.遵守的规定 7.安全性

团队建设的目标：

1.提高成员个人技能，以提高完成项目活动能力，同时降低成本、缩短工期、改进质量并提高绩效 2.提高团队成员间的信任感和凝聚力，已提高士气，降低冲突，促进团队合作

3.创建动态团结合作的团队文化，以促进个人与团队的生产率、团队精神和团队协作，鼓励成员间交叉培训以共享经验和知识。成功项目团队的特点 1.团队的目标明确，成员清楚自己的工作对目标的贡献 2.团队的组织结构清晰，岗位明确 3.有成文的或习惯的工作流程和方法，而且流程简明有效

4.项目经理对团队成员有明确考核和评价标准

高效会议：

1.实现制定一个例会制度 2.放弃可开卡不开的会议 3.明确会议的目的和期望结果 4.发布会议通知

5.会议前将材料分发给参会人员 6.借助视频设备 7.明确会议规则

8.会议后要总结，提炼结论 9.会有要有纪要 10.做好后勤保障

人员转移流程

1.项目团队成员的管理计划即人力资源管理计划所描述的人员转移条件已触发

2.项目团队成员所承担任务已完成，提交了警确认的可交付物并完成工作交接

3.项目经理与项目团队成员确认该成员的工作衔接已完成4.项目经理签发项目对成员转移确认文件

5.项目经理签发团队成员绩效考核文件

6.项目经理通知所有相关干系人 7.若项目收尾其他项目成员结束项目工作，应召开表彰大会，肯定项目的成绩，团队成员的业绩，同时总结项目的经验教训。沟通管理计划内容：

1.项目干系人的沟通要求 2.对要发布信息的描述 3.信息接收的个人或组织 4.传达信息所需的技术或方法 5.沟通频率

6.上报过程,确定上报时间,管理链 7.随项目的进展对沟通计划进行更新和细化 8.通用词语表

沟通管理计划编制步骤

1.确定干系人沟通信息需求 2.描述信息收集和文件归档结构 3.信息交流的形式和方式 沟通原则： 1.内外有别

2.非正式沟通有助于关系的融洽 3.采用对方能接受的沟通风格 4.沟通升级原则 5.扫除沟通的障碍 沟通阻碍因素：

1.沟通双方物理距离 2.沟通环境因素 3.缺乏清晰沟通渠道 4.复杂的组织结构 5.复杂的技术术语 6.有害的态度

项目干系人管理：

1.对需求期望识别了解沟通层次 2.理解干系人需求达成项目目标 3.使用计划中的确定的沟通方法 4.目标是促进干系人理解和支持 风险管理计划内容： 1.方法论 2.角色与职责 3.预算

2.识别引起这些风险的主要因素 3.识别项目风险可能引起的后果 风险识别特点 1.全员性 2.系统性 3.动态性 4.信息依赖性 5.综合性

采购管理计划内容： 1.采用的合同类型

2.是否采用独立估算为评估体系 3.有采购部门时团队采取啥行动 4.标准的采购文件 5.管理多个供应商

6.协调采购与项目的其他方面 7.对计划的采购造成影响的任何约束和假定

8.处理从卖方购买产品所需的提前订货期

9.进行自制外购决策

10.确定每个可交付成果日期安排 11.确定履约保证金或保险合同，减轻风险

12.为卖方指导，助其制定维护WBS 13.确定用于采购或合同工作说明书的形式格式

14.确定通过资格预审的卖方 15.管理合同和评估卖方衡量指标 工作说明书格式： 1.前言

2.项目工作范围 3.项目工作方法 4.假定

5.工作期限和工作量估计 6.双方角色和责任 7.交付件

8.完成以及验收标准 9.服务人员 10.聘用条件

11.收费和付款方式 12.变更管理 13.承诺 14.保密

管理收尾

1.确认项目或者阶段已满足所有赞助者、客户及其他干系人心情的行动和活动

2.确认已满足阶段或者项目完成标准，或者确认项目阶段或者项目的退出标准的行动和活动 3.需要时把项目产品或服务转移到下一个阶段，或者移交到生产或运作的行动和活动

4.活动需要收集项目或阶段记录、检查项目成功或失败、收集教训、归档项目信息，以便组织未来的项目管理。合同收尾办法：

涉及结算和关闭项目所建立的任何合同、采购或买进协议，也定义为支持项目的正式管理收尾所需的与合同相关的活动。该办法包括产品验证和合同管理收尾。配置管理的主要工作 1.制定配置管理计划 2.配置识别和建立基线

1.组建配置管理方案构造小组 2.对目标机构进行了解和评估 3.配置管理工具及其提供商评估 4.制定实施计划

5.定义配置管理流程 6.试验项目的实施 7.全面实施

CCB对变更申请确定内容： 1.变更的内容是否合理 2.变更的范围是否正确、考虑周全 3.受影响的配置项是否被充分考虑，是否需要同时进行变更 4.工作量估计是否合理 5.如有变更实施方案，评估基线变更的实施方案是否合理 功能配置审计验证内容： 1.配置项的开发已圆满完成2.配置项已达到规定的性能和功能特性

3.配置项的运行和支持文档已完成并符合要求 物理配置审计验证内容：

1.每个构建的配置项符合相应的技术文档

2.配置项与配置状态报告中的信息相对应 变更程序：

1.提出和接受变更申请 2.对变更的初审 3.变更方案论证

4.项目变更控制委员会审查 5.发出变更通知并开始实施 6.监控实施的变更7.变更效果的评估

8.判断发生变更后项目是否已经纳入正常轨道 PMO关键特征：

1.在所有PMO管理的项目间共享和协调资源

2.明确和制定项目管理方法、最佳实践和标准

3.负责制定项目方针、流程、模板和其他共享资料

4.为所有项目进行集中配置管理 5.对所有项目的集中的共同风险和独特风险存储库加以管理 6.项目工具的实施和管理中心 7.项目间的沟通管理协调中心 8.对项目经理进行指导的平台 9.在企业级对所有PMO管理项目的时间基线和预算集中监控 10.在项目经理和任何内部或外部的质量人员或便准话组织之间协调整体项目的质量标准 工作绩效内容：

1.计划进度与实际进度 2.哪些可交付物已经完成，未完成 3.进度表中那些活动已开始，结束 4.对质量标准符合到何种程度 5.预算执行情况 6.活动完工估计

7.活动的实际完成百分比

8.已被记录并送人经验知识库的经验教训

4.项目实施组织本身发生变化 5.客户对项目、产品或服务的要求发生变化

6.产品范围定义的过失或者疏忽 7.项目范围定义的过失或者疏忽 8.增值变更

9.应对风险的紧急或回避计划 10.项目执行过程与基准不一带来被动的调整变更控制流程作用

1.指出怎样提交变更手续 2.记录变更情况

3.列出管理层对变更影响 4.记录变更批准情况

5.说明能批准变更的权限级别 变更注意：

1.对变更因素施加影响。2.对变更确认正式化。

3.对变更操作过程规范化。变更管理主要任务

1.分析必要性和合理性，是否实施 2.记录变更信息，填写变更控制单 3.作出更改，并报上级审批 4.修改配置项，确立新版本 5.评审后发表新基线

变更初审的目的：

1.对变更提出方施加影响，确认变更必要性，确保变更是有价值的 2.格式、完整性校验，确保评估所需信息充分

3.在干系人间就提出供评估变更信息达成共识

4.变更初审常见方式为变更申请文档的审核流转 变更评估涉及方面：

1.首要的评估依据是项目基准 2.结合变更的初衷看变更的目的是否已达到

3.评估变更方案中的技术论证、经济论证内容与实施过程的差距并推进解决。系统集成项目文档： 1.系统集成项目介绍 2.系统集成项目最终报告 3.信息系统说明手册 4.信息系统维护手册 5.软硬件产品说明书、质量保证书 项目总结意义

1.了解项目全过程的工作情况及相关团队或成员绩效情况 2.解出现的问题并改进措施总结 3.了解项目全过程出现的值得吸取的经验并进行总结

4.对总结后的文档进行讨论，通过后存入公司知识库，纳入企业过程资产 项目总结会内容 1.项目绩效 2.技术绩效 3.成本绩效 4.进度计划绩效 5.项目沟通

6.识别问题解决问题 7.意见和建议

第五篇：信息系统项目管理师论文

项目管理师论文写作指南

1.大纲中的要求

《信息系统项目管理师考试大纲》中，要求考生根据试卷上给出的四个有关项目管理的论文题目，选择其中的一个，按规定的要求写论文和摘要。论文可能涉及的内容极其广泛，主要有信息系统项目管理，信息安全，信息系统项目监理，信息化战略与实施，大型、复杂和多项目的管理，项目绩效考核和绩效管理6个主要模块的论题方向，这6个方向又分为若干个子内容。

历届高级资格考试论文写作一般会有如下的要求：

简述你所从事的项目及你在项目中担任的角色；

在项目中关于论题方向碰到的问题和解决对策；

对项目实话的总结和展望。

2.为什么会觉得论文考试难

对于在职人员来说，可能存在以下困难：

有项目经验但要写成论文觉得写作水平有限；

长期从事某一个方面的工作，很少从事项目管理这种综合性的工作；

从事技术性工作或研究工作，热衷于技术实现，管理工作做得较少；

工作任务过重，无暇复习及攥写论文。

要想考试过关，一是要尽量从繁忙的学习和工作中抽出时间来应考；二是要熟悉考试论文的写作格式及注意事项；三是掌握一定的论文写作技巧；四是需要阅读大量的资料来充电，五是在考试之前作适当的练习。当然如果您项目经验十分丰富，可以把重点放在锻炼写作技巧上来。

3.论文的格式与写作技巧

3.1 格式要求

项目管理师考试的论文不同于要放在学术杂志上发表的学术论文，也不同于学生的毕业论文，她主要是对自己工作经验的总结，更象一份述职报告，因此在格式上的要求也比较简单。

论文的内容分为两部分：摘要和正文。这两部分的书写要注意以下的格式：

达到字数要求。摘要一般要求200字以上，500字以下，正文要求2500字以上。在论文写作的方格纸上会有字数提醒。

不要在论文中书画图形，尽量用文字表述。

尽量保持卷面清洁，如果实现需要划掉文字，在字上划一横线即可。

不必写关键词。

3.2 写作进度把握

论文的写作时间只有两个小时，要在短短的两个小时里写出一篇高质量的论文确属不易，需要考生有较为丰富的理论和实践知识的积累，当然也不必害怕，因为这还是有章可循的。这里建议的时间分配如下：

通读论题，选定论题（5分钟）；

构思论文，写论文提纲（10分钟）；

摘要写作（15分钟）；

正文写作（80分钟）

复查论文（10分钟）。

论文的摘要由于在论文的写作过程中论文的论点及内容可能会有所变化，建议在写作完正文后再写摘要。下面按写作步骤详细解说。

3.3 论文选题

拿到试卷后，先把试题快速通览，找到自己最容易发挥，最擅长的方向的论题。为了照顾大多数考生的情况，论文题目会比较宽泛。

需要注意的一点是，既然是考项目管理师，论文内容当然不会关心过多的技术细节问题，重在项目管理。

选题时要考虑应和什么项目相关联。文章至少要与一个项目关联起来。那么如何选定项目呢？

在校的学生由于没有项目经验，往往不知论文应与什么项目关联为好。一是要看题目要求，如今年5月考试的论文题目中就明确指出要是参与管理过的大型信息系统项目，因此一般不要以如“学生成绩管理信息系统”这种课程设计性质的项目来写；二是尽量写自己熟悉的，如一般的可写高校人事MIS，高校教务MIS等，在职人员也可如此考虑。项目可以是虚构的，不需要指明开发单位，委托单位；三是如果有大型项目或可以构思出大型项目则更佳。

3.4 论文提纲

选定论题后不要急于动笔直接在答题纸（论文的答题纸为方格作文纸）上写作。因为直接写作很难有一个整体的思路，而且在写作的过程中可能会涂改而使得卷面不整洁，影响评卷人的心理。不提倡在草稿纸上书写论文再抄至论文答题纸上，因为考试的时间本就十分有限，抄写论文的时间也需不少。不妨先花点时间理理写作的思路，在草稿纸上写作论文的提纲，所谓“磨刀不误砍柴工”。

提纲中写些什么内容呢？可有如下的内容；

拟联系写作的项目，思考如何联系此项目来写作；

拟写论文的主要论点。

各段落的主要内容，如果直接以论点来分段就不必再写此项了。

论文的阅卷者一般会把论文看两遍，第一遍快速浏览全文的论点，以找出文章的“文眼”，第二遍再仔细阅读。如果论点清晰，会给阅卷者以清晰明朗的感觉。

3.5 正文写作

有了提纲了，写正文就轻松多了。正文可采用“总——分——总”式，即文章开头提出中心思想，再分述论点，最后在结尾处作出总结；也可用“提出问题——分析问题——解决问题”的逐步深入的方法。写作时注意以下几个方面：

理论联系实际，一定要与项目关联起来讨论，切忌空谈理论；

论点要正确，合乎工程实践的实际情况；

可以分条叙述的方式，但不要全文用此方式；

论点清晰，最好每段在开头处或结尾处点明论点；

结尾处要对项目的实施情况，以及应用论点论据应用情况作出总结。

不必列举过多的计算公式。

文章要带有一定的学术性，更多的应是谈项目经验。

不要关注于技术，多就论题写管理方面的问题及采取的措施。

3.6 摘要写作

摘要可按如下几个方面来写：

项目概述，包括自己主持或参与的项目及自己担任的角色。

论文的主要论点。

为方便大家书写摘要，这里给出两个摘要的书写模板。

模板一：（论点——项目概述）

本文以我主持（或参与）的××××××（项目名称）为实例，探讨了××××××（论文论题），认为××××××（论点）。在此项目中，我担任了××××××（角色），参与了××××××（任务），实施后×××××（用论文中的方法实施后的效果）。

模板二：（项目概述——论点）

×××××（项目名称）是×××××（项目说明），在此项目中，我担任了×××××（角色），参与了×××××（任务）。对于项目的×××××（论题），本文认为×××××（论点）。该项目实施后×××××（用论文中的方法实施后的效果）。

下面给出模板一的一个实例，以供参考：（论信息系统项目的需求管理和范围管理）

本文以我主持的某商业银行网上银行系统项目为实例，探讨了作为开发方公司在信息系统项目的需求管理和范围管理方面碰到的问题及解决的办法，文章首先解释了需求管理和范围管理的基本概念，认为需求工作做得不扎实，项目范围把控不好是导致项目难以成功的主要原因，提出应以CMM过程改进的思想指导项目的需求管理和范围管理，项目在需求分析阶 段应确定需求可以决策的人，充分和客户沟通以正确把握需求，对于需求和开发范围的变更管理提出了解决的办法。我在该项目中担任了开发方的项目经理，自始至终参与了整个项目的建设，自2004年4月项目启动至2004年12验收历时8个月，系统至今运行稳定，取得客户的好评，很大程度上得益于项目成功的需求管理和范围管理。

4.论文考题分析

我们来把考试大纲的内容与历年的软件资格与水平考试高级（包括系统分析师和项目管理师）相关的考试论文题目列举出如下表所示，也许您会有所启迪。

表1

历年软件资格和水平考试高级考试与考试大纲相关的论文题

模块方向子内容历年考题考试年份

信息系统项目管理项目选择

可行性分析论信息管理系统的可行性研究1997年

项目生命周期流程管理

项目的整体、范围、进度、成本、质量、人力资源、沟通、风险和采购管理论软件开发的质量管理1989年

成本/效益分析1990年

论软件项目的质量保证1993年 论项目管理工具的选用1998年 论软件质量保证2002年

论软件开发的风险控制2003年 论软件开发成本管理2004年上半年

论应用软件开发范围和功能的确定2004年下半年 论项目管理中的进度控制2005年上半年

论信息系统项目的需求管理和范围管理2005年上半年项目管理师 项目评估

企业级信息系统项目管理体系的建立

项目中的质量管理与企业质量管理异同分析论软件开发的质量管理1989年 论软件项目的质量保证1993年 论软件质量保证2002年

信息安全信息安全体系系统的安全与保密控制1992年 信息安全体系的安全风险评估

企业信息安全策略论企业信息系统的安全2005年上半年 论企业内部网的安全策略2004年下半年 信息系统工程监理监理的方法与工作流程

监理的机构及监理工程师

监理中的质量、投资、进度和变更控制

监理中的合同管理、信息管理和安全管理

监理中的组织协调

信息化战略与实施企业建设信息化系统的过程

信息化系统建设过程中常见问题

新技术对信息化建设的影响

CIO在信息化建设过程中的作用

信息化规划

不同类型信息化建设过程中的差异

电子政务建设论电子政务信息共享整合2005年上半年 企业自身管理成熟度对企业信息化建设的影响

大型、复杂信息系统项目和多项目的管理计划过程

跟踪和控制过程

范围管理论应用软件开发范围和功能的确定2004年下半年

论信息系统项目的需求管理和范围管理2005年上半年项目管理师 资源管理

协作管理

项目绩效考核与绩效管理团队绩效与项目绩效的关系

绩效评估的方法

项目绩效指标设计

绩效改进

从上面的表格中可以看出，还没有出过题目的内容极可能会成为下次考试出题的对象，“信息系统项目管理”模块中的“项目的整体、范围、进度、成本、质量、人力资源、沟通、风险和采购管理”是近四年的高级考试中必出论文考题的内容。据此，作者列出19个考题供大家参考和练习（每个模块3~4个）：

l 信息系统项目管理

论项目团队建设

论项目沟通管理

论企业信息系统项目管理体系的建立

论项目采购管理与合同管理信息安全

论企业的信息系统安全体系

论企业信息系统的安全控制策略

论企业信息系统安全风险的评估【此三项要工作联系实际】信息系统工程监理

论信息系统项目的工程监理

论信息系统工程监理中的质量控制

论信息系统工程监理中的进度控制信息化战略与实施

论企业信息化的规划

论电子政务项目管理

论企业信息化的建设

大型、复杂信息系统项目和多项目的管理

论信息系统项目计划的制订

论信息系统项目资源管理

论信息系统的跟踪与控制【此三项是指导工作实际】项目绩效考核与绩效管理

论项目绩效评估的方法与策略

论企业信息化中的绩效评价机制

论信息系统项目绩效指标的设

5.如何准备论文

可以从以下几个方面着手准备论文：

l.看别人写的项目经验文章，这是快速弥补经验不足的办法。以下的网站可以找到不少的资料：http://www.xiexiebang.com（中国项目管理信息网）等。如果可以看到一些项目的实施方案书则提高实践经验更快。一定要在考试前动手写几篇论文。可就前面提供的6个方面的论文题目去找几个自己感兴趣的，多准备几篇，最好能有6篇，不必每个方向都写，6个方向选其中的2——3个即可。写完以后，最好能在身边找一位专家帮你批改论文，写作水平会迅速提高。多与项目管理经验丰富的人员聊天谈项目实施的感受，谈项目管理的点点滴滴，得到一些书本上不能得到的知识。

要想通过项目管理师考试，绝非一躇而就，论文写作较为真实地集中体现了考生的水平和能力。但论文的写作也是有章可循的，不仅要挤出时间来准备，还要注意论文的写作格式与写作技巧，勤于练习，虚心向经验丰富的同仁请教。

论文实例

1.论文论题

这次一起分析和讨论的论题是：“论信息系统项目的整体管理”。题目如下：

项目管理的9大知识领域包括项目的整体、范围、时间、成本、质量、人力资源、沟通、风险和采购管理，其中项目整体管理包括在项目生命周期中协凋所有其他项目管理知识领域所涉及的过程，它确保项目所有的组成要素在正确的时间结合在一起，以成功地完成项目。

信息系统项目往往比较复杂，经常出现各项目目标之间或参与项目的人员之间的冲突，项目管理人员常常要处理各种冲突，协调为完成一个项目所需的人员、计划以及工作。

请围绕“论信息系统项目的整体管理”论题，分别从以下三个方面进行论述：

1、概要叙述你参与管理过的信息系统项目，以及该项目在项目整体管理方面的情况；

2、论述项目整体管理的主要内容及其重要性；

3、详细论述你参与的信息系统项目整体管理的过程，方法及实际效果，讨论在项目实施过程中出现的冲突情况及解决办法。

2.范文一：论信息系统项目的整体管理

[摘要] 医疗保险管理信息系统涉及到医保管理部门、各定点结算点（医院、药店）、开发商，加之政策多变、业务不成熟，需求变化频繁，开发的难度和风险较大。在某市医保管理信息系统开发过程中，我作为用户方的项目负责人参与了项目的整体管理工作，我在项目整体管理中采取了针对性的措施，加强了参与各方的沟通，注重用户需求和需求的变化，合理配置项目组成员，对风险进行了及时的评估并顺利地控制了风险。通过这些办法，平衡了各方的利益，控制了项目的范围和进度，保证了项目的质量，顺利完成了这个项目。

[正文] 几年前，某市为实施城镇职工基本医疗保险，开发了一套医保管理信息系统，我作为用户方项目负责人，参与了项目管理、系统分析和编程的部分工作。

这个系统的功能包含了基金征集和支付管理、参保单位（职工）管理、定点结算点管理、参保职工就诊结算管理、IC卡管理等，目标管理人数为30万、定点结算点200个，计划投资400万元；采用C/S结构，数据集中保存在市医保中心，定点结算点与医保中心之间数据实时交换。

通过公开招标，明确了项目的范围、时间、成本和采购，因此，我把整体管理工作的重点放在了项目的质量、人力资源、沟通和风险管理方面，目的是保证实现计划的功能并按时投入运行。在工作中，我根据实际情况，采用了灵活的工作方法，取得了较好的效果。

该系统在04年一次上线运行成功，目前运行情况良好。

一、加强了沟通管理。

该项目涉及到医保中心、参保单位、定点结算点、系统开发（集成）商等多个单位，从需求分析到系统设计、测试都要各方参与、协调配合，由于各方的地理位置十分分散，难以经常或长期集中，因此，各方及时有效的沟通是项目成功的必要条件。为解决好这个问题，我采取了三个办法：

1、提高大家对沟通作用的认识，特别是各方主要领导人对沟通的必要性和重要性的认识，从而对沟通工作给予必需的人员、经费和时间支持，保证了沟通工作得以按计划进行。

2、对项目组外部的沟通，坚持从实际出发，采用多种沟通的方式。一方面，把必要的、重要的沟通需要以联席会议、工作计划、总结报告的形式制度化。另一方面，在适用的前提下，采用灵活、经济的沟通方式，比如：对一般的小问题或者是简单问题进行电话交流，复杂一点的问题开碰头会，需要后续解决的、比较重要的及涉及面较大的问题要形成书面的会议记要，有必要的情况下要由相关单位加盖公章确认。

3、对项目组内部沟通，进行适当的控制，避免形式主义，在保证效果的前提下节省时间，提高工作效率。规定项目组成员在每天工作过程遇到问题，将其记录下来，然后在以邮件方式发送给需要沟通或者询问者。大家每天下 班之前收取邮件，对于可以直接回答的问题则直接以邮件方式回复，对于无法直接答复而只需与提出问题者讨论的问题，在第二天上班前进行商议确定。而需要众人一起讨论的问题，则放到每周会议上讨论，较紧急的问题召开临时性会议。通过以上方法，基本上实现了有关各方及项目组内部的有效沟通，及时发现问题、解决问题，避免了因各方立场不一致造成严重对立而影响项目进度，避免了因交流不畅形成重大质量问题。

二、合理配置人员。

对项目组人员进行规划配置，合理分工，明确责任，保证项目各阶段、各方面的工作能够按计划完成。我们在项目组长配置了以下人员：技术组长一名，负责技术难题攻关，组间沟通协调；需求人员5名，负责将用户需求转换成项目内的功能需求和非功能需求，编制项目需求规格说明书，针对每个迭代集成版本与用户交流获取需求的细化；设计人员5名，负责对需求规格说明书，进行系统设计；开发人员8名，实现设计，完成用户功能；集成人员1名，负责整套系统的编译集成，督促小组系统功能提交，及时发现各模块集成问题，起到各小组之间的沟通的纽带；测试人员2名，对于集成人员集成的版本进行测试，尽可能的发现程序缺陷，以及未满足需求的设计；文档整理人员1名，负责对小组内产生文档的整合，统一；维护人员1名，系统验收后，维护人员，建议维护人员早期进入项目参与项目测试以便顺利承担起项目维护职责。

在人员的管理方面，一方面要求项目组成员相对稳定，以保证开发工作的连续性，另一方面，不搞终身制，不能够胜任职工作的坚决调换，保证项目整体工作不受影响。通过平常和阶段性的工作考核、评审，对不合格人员进行调换。有一名需求分析人员因为工作态度不好，与客户单位业务人员关系恶化，调查落实后，我们立即把他调出项目组。

三、进行风险评估，在进度和质量之间进行权衡，争取最佳平衡点。

由于项目资金已经确定，我就在进度和质量之间找平衡点，力争把风险降到最低。由于医疗保险业务本身比较复杂，加之当时国家政策不稳定，业务流程不是很规范，系统需求也在不断调整、完善，给项目的进度带来一定影响。由于这个项目涉及到十余万参保职工的医疗待遇，影响很大，通过与用户方领导沟通，决定不搞“形象工程”，在质量和进度之间优先考虑质量。同时，考虑到这个项目的采用了增量开发模型和模块化的设计方法，我把项目目标进行了分解，涉及到业务经办的部分优先完成，保证系统在规定的时间上线运行，其它不影响业务经办的、辅助性的功能适当延期，包括医疗监督、统计分析和部分报表。这样虽然整体工期有所延长，但没有影响系统及时上线。这种做法同时照顾到各方的利益，把整体风险降到了最低。

四、重视需求变化的客观性，强化测试，保证软件功能完整、正确、高效。

质量是软件的生命，软件功能完整、正确、高效是软件质量的重要组成部分，也是用户最关心的内容。

我们采用了软件工程方法，使用渐增式的增量模型，注重满足用户需求和需求的变化。由于国家没有统一的医疗保险业务经办规范流程，另外，为保证医保基金的收支平衡，各地都在根据医保基金的运行情况进行不断的政策调整，造成医保系统的需求变化频繁。根据这个情况，为保证软件满足应用需要，我们规定：在整个项目的开发过程中，凡是用户提出的、经调查情况属实、经技术可行性论证可行的，全部予以响应。同时，采取措施避免需求的反复和无意义、不合理的变更。对较大的变更和比较关键的变更，要经各方联席会议论证通过，参与人员签字负责，并由提出变更的单位加盖公章确认。由于不合理或技术上不可行而没有通过的需求变更，要提出替代的解决办法，并与用户单位协商，达成一致意见后予以解决。

测试是保证软件质量的重要手段，也是让用户直观地了解软件质量和熟悉软件操作的有效途径。我有计划地强化测试环节，让用户由始至终地参与测试工作。我们主要采取黑盒法进行测试，把工作重点放在测试用例的准备上，严格定义测试索引、测试环境、测试输入、预期结果、评价标准，尽可能的把各种业务的不同情况都表现出来。同时，我们准备了一家定点结算点进行实际运行测试，在该结算点手工记帐和计算机联网记帐同时进行，并有计划地穿插一些测试用例。通过这些办法，及时发现了和解决了许多问题。

经过努力，该系统一次上线运行成功，并在6个月后通过了验收。回顾项目的整体管理工作过程中，虽然没有大的事故发生，但仍然存在许多问题，主要有以下3点：

1、软件测试不系统，用例准备仍不够充分，忽视了压力测试。系统实际运行后随着参保职工和定点结算的增加，运行速度下降很快，达不到设计要求。虽然通过升级硬件缓解了这个问题，但造成了资金的额外投入。

2、在需求分析过程中对各方目标的权衡不够充分，导致定点结算点使用的结算子系统功能较弱，提供的系统接囗又不够强大，给定点结算点内部管理带来不便，一些必要的统计和查询功能难以实现。

3、对开发人员与操作人员对系统的要求差异认识不足，两者的直接沟通不够，造成一些对操作员而言很重要的问题在开发人员那里得不到重视，产生了一些矛盾，给项目带来不利影响，特别是影响到用户方及领导部门对项目的整体印象。

综上所述，良好的项目沟通管理；合理的人力资源配置；用风险评估在进度和质量之间进行权衡；重视需求变化的客观性，强化测试，保证软件功能完整、正确、高效是我在某市医疗保险管理信息系统项目中的整体管理中的 四个主要实践，为项目的成功奠定了坚实的基础。在以后的项目整体管理工作中，我要加强测试的系统性和科学性，注重各方利益的权衡，继续深化各方的沟通，协调好开发工作各个部分及各个方面的关系，更好地完成项目。

[老师评语] 此文基本达到了考试要求。写作比较规范，行文流畅。文章结构清晰，所述的一些情况确实是在项目开发过程中所经常碰到的而又需要解决的问题,给人的感觉问题真实,针对问题采用的措施亦较为有效。

3.范文二：论信息系统项目的整体管理

[摘要] 本文以笔者所主持的某卷烟厂物流控制及管理信息系统项目为实例，探讨了信息系统项目整体管理在项目实施过程中的重要性，并分别论述了项目计划编制、项目计划实施，以及项目综合变更控制等项目整体管理过程，在整个项目生命周期内所起的积极作用及其实施经验。在该项目中，本人以开发方公司副总工程师身份担任项目经理，负责了项目的整体规划、组织实施和管理控制。我们科学地运用了信息系统项目整体管理的一般理论知识及其指导方法，有效地保障了项目的顺利实施，很好地满足了各利益相关者的需求和预期期望。

[正文] 信息系统项目的整体管理是项目取得全面成功的一个至关重要的前提和基础。通过项目整体管理，可以确保项目所有的组成要素在适当的时间有机地结合在一起，以顺利、成功地完成项目。这在本人所主持的某卷烟厂物流控制及管理信息系统项目实施过程中得到了充分验证。

该项目是一个综合性的系统工程项目。从技术实现角度讲，它所涉及到的主要技术领域包括卷烟生产工艺、制造业物流技术、工业自控技术和计算机管理信息技术等等。从利益相关者角度讲，它又涉及到作为需方的烟厂、物流设备供应商、工业自控设备供应商，以及作为信息系统集成商的我公司。因此，这是一个复杂程度高、涉及面较广、实施周期长的综合项目。

面对这样一个项目，作为开发方公司的副总工程师，我受公司委托担任该项目经理，我首先想到的是应该将主要精力放在项目的整体管理上，科学地运用相关理论知识及其指导方法，做好项目的全局性统领工作，协调完成项目所需的所有人员、计划和工作，带领整个项目团队实现项目的顺利成功。另外，我也考虑到，除了项目本身内部的各组成要素之外，项目的相关利益者也不容忽视。一方面是作为公司承担的一个对外项目，我们实行项目经理负责制，具有一定意义上的独立性，但同时也是公司整个组织日常持续运作中的一部分，离不开公司的整个组织环境，而且公司也已决定将该项目作为业务延伸拓展的一个新的窗口，将其提升到了一个相当重要的位置。另一方面，该项目是需方烟厂整体搬迁重大技改项目的一个部分，其实施的进度、质量和成本等，受到来自其主管上级部门和烟厂新经营目标的严格要求和控制。此外，还会涉及到物流设备供应商、工业自控设备供应商等中标单位。所以，项目的整体管理显得是那么的重要、不可或缺。否则，稍有顾及步骤之处，都将会给项目的实施带来很大的麻烦和影响。

下面分别从项目计划编制、项目计划实施，以及项目综合变更控制等方面对项目的整体管理过程加以简要论述。

1、关于项目计划编制：

凡事预则立、不预则废。信息系统项目尤其如此。只有站在统领全局、整体规划的高度，对项目进行科学、合理、全面、周详的计划，预先制定一个用来协调所有其他计划、以指导项目实施和控制的文件，才能使项目得以顺利实施并最终取得成功。项目计划记录了计划的假设条件和方案选择，可以为各利益相关者之间的沟通提供了一个参照，并确定了关键管理审查的内容、范围和时间，同时还为进度评测和项目控制提供了一个基线。

在该项目中，我们对项目计划具体内容的确定，结合项目的各方面实际情况，主要参照IEEE1058.1中“软件项目管理计划”的基本内容，其中包括项目介绍、项目组织、管理过程、技术过程和进度预算等五个部分。在坚持科学、合理、全面、周详的原则基础上，还视部分具体的计划条款，详略得当。但所有的计划内容都必须是正确的、明确的、易理解的和可执行的，切忌未经确认、含糊不清、容易误解、难以执行的项目计划描述。这就要求我们必须在制定计划之前或在制定过程中，与需方烟厂、公司上层、其他设备供应商、项目团队各技术和管理小组进行充分的沟通与协商，明确确定项目有关内容，如项目可交付成果、技术方法工具、组织结构、各工作包、资源要求、预算分配、进度计划等。

另外，因为项目管理的最终目标是满足或超越各利益相关者的需求和期望，在项目计划过程中考虑利益相关者分析也是非常重要的，但不宜将其作为项目整体计划的一个部分，最好把它作为公司内部使用的一个项目计划附件。该项分析的内容可以包含各利益相关者的所属组织、所处角色、项目利益、影响程度及管理这些利益相关者的合适建议等。对于项目经理来说，花点时间来关注和利用这些信息也是非常重要的。我在该项目管理过程中的感觉是，在项目的日常实施过程中，尤其是在项目陷入某些困难的时候，这些分析结果常常会帮助我起到对症下药、药到病除的作用。

当然，项目计划的制定和执行，也必须考虑和注意它的动态性和灵活性。尤其是对于综合性的项目而言更加重要。由于项目复杂程度高、涉及面较广、实施周期长，所以其中的变更是在所难免的。在该项目实施过程中，由于烟厂项目局部需求的修改，或由于各方交流的失误等，曾经导致了部分项目内容的变更从而致使了项目计划人员和进度的变化和调整等。而且这种计划动态修订的次数还不止一次。所以项目计划制定以后并非一劳永逸，它与项目实施过程相互渗透，有一个动态的、灵活的修订过程。

2、关于项目计划实施：

项目计划实施是指对项目计划中所规定的工作进行管理和实施的过程。项目产品主要都在项目实施阶段生产出来，所以项目的大部分时间和预算都花在这一阶段。在该项目中，我们的软件编程、与需方烟厂有关技术人员的具体沟通、与有关设备供应商的具体交流、阶段性调试，直至全套系统软件和技术文件的完成等，都发生在这一阶段。为了能够成功地完成项目产品，项目团队进行了大量反复的具体编程、学习、沟通、修改、软硬件安装和调试工作。

如前所述，该项目涉及到的主要技术领域包括卷烟生产工艺、制造业物流技术、工业自控技术和计算机管理信息技术等，我们项目团队不仅要从事熟知的信息技术工作，还要花大量时间和精力了解烟厂具体的细节性的需求，学习卷烟生产工艺、制造业物流理念和常识、物流设备的基本工作原理和管理知识、自控设备的基本工作原理和管理知识等等，以及反复地和烟厂、相关设备供应商、公司上层等进行必要的交流沟通。作为项目经理，在此阶段主要的工作是要按照预先制定的项目计划，利用项目团队组织机构和工作程序，领导项目团队开展各项工作，管理和协调各利益相关者的关系，成功地将项目计划投入实施。

项目计划和项目实施是相互渗透、不可分割的活动。在该项目的实施中，我们对于项目计划编制和实施之间的协调改进工作主要采取谁实施谁计划的原则。虽然项目经理负责整体项目计划，但编制该计划的大量基础信息均来源与各技术组和技术人员。事实证明，按照这一原则，项目计划的编制更加合理、可行，实施起来更加顺利。

3、关于综合变更控制

综合变更控制是指在项目生命周期内对项目变更进行识别、评价和管理的工作，这也是项目经理及其项目团队的一项重要工作。如前所述，该项目的复杂程度高、涉及面较广、实施周期长，所以其中的变更是在所难免的。当有变更要求提出的时候，作为项目经理，我都会召集项目团队相关人员，进行协商讨论和工作安排。主要内容有：

A、对变更因素加以影响：通过在范围、时间、成本和质量等关键项目尺度的权衡，对促使变更形成的因素进行分析和采取对策，确保变更对项目有利；

B、确定变更是否发生：在最终确定变更发生前，项目经理必须了解项目几个关键方面的状态。尤其是一些重大变更，项目经理必须与公司高管层，以及其他利益相关者进行必要的交流与沟通。

C、对变更加以管理：项目经理在项目管理过程中必须严格行事，尽量避免或减少变更的发生。但变更不可避免发生时，更重要的是对变更进行管理。

按照项目整体管理的指导方法，我们在变更发生时，要求必须输入项目计划、变更申请和绩效报告等重要内容，输出更新后的项目计划、纠正行措施和经验性教训记录等。通过这些做法，使我们的项目变更控制与管理工作规范有序。

该项目顺利成功地实施完毕已经有一年多了。回顾起来而言，应该得益于我们在项目进行的最初期阶段就引入了项目整体管理理念和方法，对项目进行了科学、规范的整体管理。通过项目整体管理，使项目所有的组成要素在适当的时间充分地、有机地结合在一起，极大地提高了项目的实施效率。

[老师评语] 本文基本达到了考试的要求。摘要和正文都写得比较流畅，给人的感觉思路清晰，层次感强。项目所述情况基本与项目研发过程中的情况相同，给人以真实感和作者有丰富的项目实施经验的感觉。

文中如果能把一些具体的问题和解决办法展开一下则更佳。如：在变更控制上为了尽量减少变更的数量，采用的需求变更申请表的形式，让烟厂方需求人员埴写需求变更申请表，并签名。一方面控制了需求变更的随意性；另一方面对明确了各方的责任，也为开发人员提供了方便。

4.范文三：论信息系统项目的整体管理

[摘要] 本文以我主持某市地税银行代理缴税系统项目为实例，探讨了信息系统项目的整体管理，及个人的一些经验教训。在该项目中我受领导委派，担任银行方项目组长。通过实践，对项目整体管理有了更深刻的认识：（1）前期工 作很重要，需要与各方进行充分沟通，明确接口，需要制定切实可行的计划；（2）项目管理是一项系统的、动态的工作，不要僵硬化，应保障信息共享，及时根据情况变化进行计划调整；（3）在项目管理中，特别是牵涉部门比较多时，应采用各种方式保证良好的沟通、协调，保证进度。

通过本人及项目组的努力，该项目按计划完成，达到目标要求。[正文] 项目整体管理是项目管理中一项综合性、全局性的管理工作。它决定在什么时间，在哪些预期的潜在问题上集中资源和基础和工作，在问题变得严重前进行处理，协调项目干系人及各项工作使项目走向成功。整体管理的工作流程主要有制定项目章程、指定项目初步范围说明、制定项目管理计划、指导和管理项目执行、监督和控制项目工作、综合变更控制、项目收尾。项目整体管理是一个项目能否高效、顺利的进行的一项基础性的工作。

2003年，根据某市地税部门和我行的代理协议和该市我行的零售业务部门提出的需求，我受省行科技部门指派，担任银行方的项目经理，组织开发了某市地税银行代收项目，该项目2003年5月中旬启动，2003年10月1日正式投产。项目涉及我行省行、市行，市地税、市地税方的信息系统外包开发公司四家单位。

在该项目的整体管理中，我在项目管理的五大过程中分别做了以下工作：

（1）在项目启动过程中，我根据业务需求，提出项目开发立项报告，完成项目的启动工作；进行项目的初步范围制定，对项目的目标、范围，项目组织、进度里程、项目费用估算进行分析；

（2）在项目的计划过程中，用project制定项目初步管理计划；

（3）在项目的执行过程中，配置人力资源，调配系统资源，执行项目计划，协调、沟通项目组、市地税方、市中行，确保项目正常、顺利完成；

（4）在项目的监督、控制过程中，收集分析项目周报，举行项目例会，将项目进度与项目计划进行比较；对变更情况进行分析、流程改变、记录分析，跟踪项目风险点，并制定风险应对方案；

（5）在项目收尾过程中，要求业务部门提供项目验收测试报告、项目投产申请；完成运行部门的项目投产单。该项目业务跨越银行及税务两大行业，并各有自己的信息系统，如何实施双方系统的互联，进行需求的确定是一个比较困难的工作，需要解决税务局和银行，银行业务部门与技术部门的各种冲突，即要满足对方的需求，也要考虑本行的利益。

可以通过从对方角度考虑问题，进行良好的沟通，最后圆满解决不合理的需求问题。如税务局开始时提出，纳税人在银行交费后，税票信息需要在银行保留。而银行系统一般只保留交易的账务信息，对保存税票信息需要比较大的代价来实现，为解决该问题，我从税务局的角度进行分析：首先会有其他银行也加入地税代收的工作，其次纳税人可能在就近的银行或税务局打印发票，所以，税票信息需要集中保存，集中保存的最合适地方是税务局。

在开发工作中，可以把行内业务需求人员加入到项目组中，或者建立紧密的沟通机制，调动业务人员积极性，让其在项目开发的需求确定，业务测试中发挥积极作用，减少需求的反复，开发的重复劳动，减少投入，确保工程进度。

对避免不了的需求变更。需要需求方以文字的形式对该变动进行规范、明确的阐释：如要求地税局或业务部门要提供需求变更说明，填写需求变更申请表等，减少需求提交的随意性，大大减少需求变更的数量。

该项目还有一个特点，涉及的单位和人员比较多，协调工作比较复杂，对此我的解决办法是：

（1）与地税局及业务部门，要充分进行业务流程、交易接口、通讯接口的讨论，确定双方的交易功能，技术接口定义，明确各方的工作职责；

（2）在项目组中，根据明确的需求，及时进行工作分解，根据项目组成员的特点、专长分配各项子任务，做到职责明确，分工合理；

（3）在项目开发过程中，要及时进行信息交流，及时向各方发布项目进度情况，我通过建立文件共享服务器，发布技术协议，需求分析，概要设计，项目计划，项目周报等文件，让项目组成员及配合的业务人员对工作有全面了解，对工作重心及时掌握，尽量减少内部冲突；

（4）在功能开发基本完成后，及时组织双方的系统联合测试，在准生产环境中运行，及时发现问题，解决问题。（5）建立良好的进度管理机制：在项目启动时就用Project制作计划，统一分发，与其它单位协商计划文档；在项目进行中，及时完善、更新进度；计划前提有变动时要及时调整；建立跨单位的周例会制度，项目周报填报制度等。

该项目历时一个月，顺利完成投产工作，并在生产中，达到要求，为银行创造了效益，为地税部门减轻了负担，为纳税人提供了方便，实现了多赢的结果。同时也锻炼了我的项目管理能力，对项目整体管理有了更深刻的认识：项目管理前期工作很重要，需要制定切实可行的计划，需要充分沟通，明确接口；应对项目管理有是一项系统的、动态的工作的认识，不要僵硬化，应保障信息共享，及时根据情况变化进行调整；在项目管理中，特别是牵涉部门比较多时，应采用各种方式保证良好的沟通、协调。[老师评语] 论文基本上达到了考试论文的写作要求，均是作者实践经验的总结，侃侃道来。美中不足的是：论文正文的字数稍少了点。在正文中的有些论点可适当再展开一下。如进度管理中是填制项目周报发现其它单位并不愿意填制周报，解决办法：主动将自己项目组的周报发给其它单位并作沟通，在此基础之上再表明希望这个单位也能回一个进度周报，即主动沟通。

5、范文四

信息系统项目的整体管理

[摘要]

本文以我参与的某大型结构分析软件系统的消化、移植、开发项目为实例，探讨了信息系统项目的整体管理，指出项目整体管理在信息系统项目实施中具有重要地位和关键作用，应根据项目的实际情况和特点，在做好项目整体管理各项工作内容的前提下，有针对性地强化某一方面整体管理的工作。具体论述了在本信息系统项目的实施中，系统动态地处理问题、明确接口定义并严格实施、换位思考以化解冲突三种方法对整体管理工作的积极意义。

[正文] 项目整体管理在项目实施中具有重要地位和作用，在本人参与的一项工程分析软件系统的开发项目，充分体现了这一点。该项目开发的主要内容是：将引进某外国的运行于大、中型计算机（如，IMB4381、WAX3300等）的结构有限元分析系统进行消化、移植，形成有自主版权的可运行于工作站（如，HP715）和微机的结构分析系统，并在此基础上开发出当时国内急需的结构优化功能、图形化前后置显示功能和复合材料结构单元等新功能。该项目工作量大，仅需消化、移植的某源程序就有四十多万条；技术复杂，涉及有限元理论、离散数学、计算机技术、各型计算机体系结构和操作系统的兼容性、结构力学、材料力学等多学科；多单位协作，有多达四个单位参加；参加人员众多且跨不同专业，有数学人员、力学人员和计算机开发应用人员。如此大型复杂的信息系统项目开发，综合的整体管理至关重要，决定着项目的成败。

为了保障项目的成功实施，在前期由我单位领导挂帅成立了项目领导小组，统一管理、协调根据项目的学科方向组建了相应项目研发小组，成立了项目管理组负责组间协调和项目的整体管理工作，我担 任了项目管理组的组长，自始至终参与了项目的整体管理工作，切身地感到了研发活动的整体管理所起到的重要作用，并认识到了一些整体管理的具体理念和方法。

项目整体管理是贯穿项目生命期全过程的一项综合性和全局性的管理工作，它以项目成功为目标，采取统一、协调、集约、澄清等措施，使项目实施全过程沿正确的轨道运行。通常项目整体管理工作包括：

（1）制定项目章程，确立项目的组织机构和运行机制，约定行动规则、制定实施标准等；（2）初步确定项目的工作内容和工作范围，明确完成项目都要做哪些工作；

（3）在项目实施各分计划的基础上，制定、协调、集成项目管理计划，并作为项目实施的准绳；（4）依据管理计划，指导和管理项目实施过程中各项活动的执行；（5）监督、控制、协调项目的各项工作；

（6）进行变更控制管理，保持项目的完整性和一致性；（7）对项目进行收尾总结，工作有始有终，积累经验。

信息系统项目往往比较复杂。如本人参与的这个项目，既有涉及不同技术和专业的，如建立力学模型，设计各种算法，使用高级语言和汇编语言等，也存在有不同组织和个人的不同期望，如有计算力学所，计算机所，对模块性能有不同观点期望。协调进度、成本、质量，进行有效沟通和资源配置，树立全局观念等，都是项目所必须的，但又往往存在大量主观和客观的问题，对以上的管理构成障碍和挑战。在各项目目标之间和参与项目的单位和人员之间经常出现不协调或冲突，项目管理人员必须在这些不协调或冲突酿成危机前处理好各种矛盾和冲突，协调为完成项目所需的资源、计划以及工作。可见没有有效的整体管理工作，项目是难以成功的。

信息系统项目整体管理工作的内容繁多、涉及方方面面，存在着需要特别关注和做好的重要方面，换句话说，就是要特别关注在正确的时间、正确的场合，使用正确的方法，投放资源和实施工作。以我参与的这项工程分析软件开发项目来说，项目最终按期完成，基本实现预期目标，与项目整体管理工作中着重做好了系统、动态地处理问题；明确接口并严格实施；换位思考以化解冲突、矛盾这三方面的工作密切相关。

系统、动态的处理问题，就是对项目实施中出现问题的处理应放到项目全局中进行考虑，全面地、联系地进行分析，动态的而不是静止的加以解决。在本项目开发实施中，由于系统的需求是来自工程领域利用计算机进行结构分析与优化，并实现大型分析系统的微机化，项目成功的技术重点和难点在于不同计算机系统的差异和兼容性，而项目负责技术总体设计的总工程师是工程力学方面的专家，对其它领域专业知识（特别是计算机专业）的局限，使动态内存管理模块的设计方案几易其稿，难以满足系统总体要求，造成项目开发进度在系统移植阶段停滞不前。为了解决这个问题，我向项目领导小组及时请示，取得了单位领导的支持，召集相关的主要负责人，通过认真分析，采取了数学组专家提出的方案，并由数学组的组来负责移植阶段的总体技术工作，系统移植的技术难题才得以正确解决。由此可以看出，在项目实施的全过程中，系统地看待和处理问题，动态地、恰如其分地调配资源，有益于项目整体管理工作目标的达成。

明确接口并严格加以实施，是促使项目成功采取的一个重要措施。本结构分析系统是在已有原型基础上的移植、开发，在模块之间的接口调用上，存在不同的解决方案，具有不同的性能指标，如何整合集成，仅仅给出笼统的标准还不够，在项目进行到一定的阶段，必须由模块开发的各方，在项目有关的负责人协调下，确立明确、具体的接口定义，并严格按照定义的接口检测验收，以保证软件系统的完整性和一致性，形成阶段可交付的子系统，推进项目的进度。在如此庞大的信息系统项目开发过程中，没有明确的接口定义，项目在模块联调阶段，将面临大量协调、沟通、扯皮、更改工作，为项目推进带来许多不必要的返工和重复，使本来不存在技术问题的项目实施举步维艰。我们项目管理组根据以往的经验，从项目一开始，就特别注重模块接口定义的整体、全局管理工作，协调各研发小组共同讨论接口的设计问题，使各研制组的工作在衔接处平稳对接，没有因为接口定义的不到位而对项目造成拖延和资源上的浪费，取得了明显的成效。

项目在开发过程中实施的各项活动交互重叠，不可避免地会发生冲突和矛盾，矛盾和冲突发生时，在双方方案均具有合理性，又各持己见、相持不下时，换位思考以求折中、平衡，从而化解冲突和矛盾，不失为整体管理工作中的一项行之有效的方法。在本项目中，研发人员主要是两类专业技术人员组成，工程结构方面的和数学、计算机方面的，两类人员由于专业背景的关系和出发点的差异，在对问题的解决上，常常各持己见，互不相让，而有时冲突的原因是对对方专业知识的缺乏。为了很好的解决这一问题，我们项目管理组经过计划和组织，约定在每周五举办学术交流活动，请两方面的专家讲解、介绍各自专业领域的基本知识，使双方都能对对方的技术观点有了较客观的理解，从而有利于在工作配合、协调时，能够站在对的角度，寻求到双方均满意的平衡点。由于课题组积极的措施和倡导，换位思考成为项目参加人员的共同理念，为项目的成功实施创造了良好的文化氛围。

该项目在历时两年后，较为成功的实现了当初制定的目标，并被评为当年部科技进步二等奖，能取得这样的成绩，很大程度上得益于良好的项目整体管理工作，特别是系统动态地处理问题、明确接口定义并严格实施、换位思考以化解冲突这三种解决项目冲突的方法。

[老师评语] 本文整体感觉比较流畅，观点鲜明，论文中讲述的情况，特别是对于多学科交叉的大型信息系统项目来说，作者的三点主要论点的体会，给人的感觉比较实在。

第一篇 项目管理（进度、风险）

IT项目管理

1）IT项目同传统项目的区别

传统的项目需要经历的时间长，使用的是有形资源，项目成果是通过对资源的消耗与形态的转化来逐步实现的。

IT项目的实质是“知识转移”，项目是以无形的智力产品为项目目标。典型的IT项目是IT系统的建造(如系统集成)和软件开发项目。

因此说，IT项目的实质是“知识转移”，而建造项目的实质是“资源消耗”。当然，并非说IT项目中不存在“资源消耗”，也不是说传统项目中没有“知识转移”。这一点应该得到辨证的理解。

2）项目管理的五个过程与IT项目生命周期

项目的管理过程分为五个过程组，每个过程组由多个过程组成。分为：

启动过程组

计划编制过程组

执行过程组

控制过程组

收尾过程组

过程组之间相互关联，每个过程组的输出是另外过程组的输入。同时，各过程组之间不是独立的事件，在同一阶段会有多个过程组同时进行。

典型的IT项目的生命周期分为：

概念阶段

需求分析阶段

计划阶段

设计阶段

执行阶段 交付阶段

结束阶段

项目所处的阶段越早，项目不确定性就越大，项目调整或变更的代价比较低。但随着项目的进行，不确定性逐渐减小，而变更的代价、付出的人力、资源逐渐增加，就会增加决策的困难度。

在项目生命周期的每一个阶段都要重复项目管理过程的五个过程组。

3）概念阶段

概念阶段的主要工作是：

评估商业需求和机会

开发项目以满足商业需求和机会

财务收益分析

确认相关项目干系人

建立概念方案

启动项目

启动项目中最重要的是要建立项目章程，授权相应的项目经理开展项目。

4）需求分析阶段

需求分析阶段的主要工作是：

收集需求

分析需求并对需求排列优先级

记录定义下来的需求

确认需要做的需求并细化需求

IT项目管理的三个条件、五个步骤

【本文精彩，可熟背】

项目是为完成某一独特的产品或服务所做的一次性努力。根据这个定义，项目就具有了目标明确性、活动一次性及资源消耗性等特性。换句话说，具备前面三个主要特性的活动，都可以看作是项目。现实中的项目随处可见，如设备消缺、会议组织、技术竞 赛、结婚典礼以及家居装修等等，都可以看作是项目。在这些项目的实施过程中，都存在项目管理问题，不过，实际生活与工作中，可能更多关注的事情本身，而对做好事情相关的组织、计划、控制等过程相对缺少关注，或者没有经验与能力加以关注。

项目管理是在项目活动中运用知识、技能、工具和技术来实现项目要求。项目管理总体有五个过程：启动过程、计划过程、实施过程、执行过程、收尾过程等，包含了九大领域的知识：范围管理、时间管理、成本管理、质量管理、风险管理、人力资源管理、沟通管理、采购管理及系统管理的方法与工具。作为项目经理要全面掌握这些九个核心领域的知识，并重点把握系统管理的观念，避免进入某个细节，注意在五个不同阶段的重点。

一、项目管理的三个约束条件

任何项目都会在范围、时间及成本三个方面受到约束，这就是项目管理的三约束。项目管理，就是以科学的方法和工具，在范围、时间、成本三者之间寻找到一个合适的平衡点，以便项目所有干系人都尽可能的满意。项目是一次性的，旨在产生独特的产品或服务，但不能孤立地看待和运行项目。这要求项目经理要用系统的观念来对待项目，认清项目在更大的环境中所处的位置，这样在考虑项目范围、时间及成本时，就会有更为适当的协调原则。1.项目的范围约束

项目的范围就是规定项目的任务是什么？作为项目经理，首先必须搞清楚项目的商业利润核心，明确把握项目发起人期望通过项目获得什么样的产品或服务。对于项目的范围约束，容易忽视项目的商业目标，而偏向技术目标，导致项目最终结果与项目干系人期望值之间的差异。

因为项目的范围可能会随着项目的进展而发生变化，从而与时间和成本等约束条件之间产生冲突，因此面对项目的范围约束，主要是根据项目的商业利润核心做好项目范围的变更管理。既要避免无原则的变更项目的范围，也要根据时间与成本的约束，在取得项目干系人的一致意见的情况下，合理的按程序变更项目的范围。2.项目的时间约束

项目的时间约束就是规定项目需要多长时间完成，项目的进度应该怎样安排，项目的活动在时间上的要求，各活动在时间安排上的先后顺序。当进度与计划之间发生差异时，如何重新调整项目的活动历时，以保证项目按期完成，或者通过调整项目的总体完成工期，以保证活动的时间与质量。

在考虑时间约束时，一方面要研究因为项目范围的变化对项目时间的影响，另一方面要研究，因为项目历时的变化，对项目成本产生的影响。并及时跟踪项目的进展情况，通过对实际项目进展情况的分析，提供给项目干系人一个准确的报告。3.项目的成本约束

项目的成本约束就是规定完成项目需要花多少钱。对项目成本的计量，一般用花费多少资金来衡量，但也可以根据项目的特点，采用特定的计量单位来表示。关键是通过成本核算，能让项目干系人，了解在当前成本约束之下，所能完成的项目范围及时间要求。当项目的范围与时间发生变化时，会产生多大的成本变化，以决定是否变更项目的范围，改变项目的进度，或者扩大项目的投资。

在我们实际完成的许多项目中，多数只重视项目的进度，而不重视项目的成本管理。一般只是在项目结束时，才交给财务或计划管理部门的预算人员进行项目结算。对内部消耗资源性的项目，往往不做项目的成本估算与分析，使得项目干系人根本认识不到项目所造成的资源浪费。因此，对内部开展的一些项目，也要进行成本管理。由于项目是独特的，每个项目都具有很多不确定性的因素，项目资源使用之间存在竞争性，除了极小的项目，项目很难最终完全按照预期的范围、时间和成本三大约束条件完成。因为项目干系人总是期望用最低的成本、最短的时间，来完成最大的项目范围。这三个期望之间是互相矛盾、互相制约的。项目范围的扩大，会导致项目工期的延长或需要增加加班资源，会进一步导致项目成本的增加；同样，项目成本的减少，也会导致项目范围的限制。作为项目经理，就是要运用项目管理的九大领域知识，在项目的五个过程组中，科学合理的分配各种资源，来尽可能的实现项目干系人的期望，使他们获得最大的满意度。

二、项目管理的五个主要过程组

一个项目的生命周期大概分成概念、开发、实施与收尾过程。在概念阶段主要是对成本进行分析，对项目的可行性进行研究，其结果是要拿出一份报告，并获得批准与支持。实际工作中，我们只是有了一个新的想法与概念，就立即转入开发过程。在开发阶段，要有项目计划书、预算的成本以及工作分解计划。

我们做事时，可能只是拿出一个简单的工作分解与大致的项目计划时间表，就结束了。在实施阶段，要有底层的工作包与确定的成本估计，但我们没有，到了这一步，我们基本上就开始失去了控制，没有明确的里程碑，我们只是把一个阶段当成了一个项目。在收尾阶段，我们是经常讨论每个项目的教训，但对完成的工作的文档工作基本上没能及时跟上，同样与用户之间的交接也未能做好。

项目管理的五个过程组：启动、计划、执行、控制与收尾，贯穿于项目的整个生命周期，对于项目的启动过程，特别要注意组织环境及项目干系人的分析；而在后面的过程中，项目经理要抓好项目的控制，控制的理想结果就是在要求的时间、成本及质量限度内完成双方都满意的项目范围。1.项目的启动过程

项目的启动过程就是一个新的项目识别与开始的过程。一定要认识这样一个概念，即在重要项目上的微小成功，比在不重要的项目上获得巨大成功更具意义与价值。从这种意义上讲，项目的启动阶段显得尤其重要，这是决定是否投资，以及投资什么项目的关键阶段，此时的决策失误可能造成巨大的损失。重视项目启动过程，是保证项目成功的首要步骤。

启动涉及项目范围的知识领域，其输出结果有项目章程、任命项目经理、确定约束条件与假设条件等。启动过程的最主要内容是进行项目的可行性研究与分析，这项活动要以商业目标为核心，而不是以技术为核心。无论是领导关注，还是项目宗旨，都应围绕明确的商业目标，以实现商业预期利润分析为重点，并要提供科学合理的评价方法，以便未来能对其进行评估。2.项目的计划过程

项目的计划过程是项目实施过程中非常重要的一个过程。通过对项目的范围、任务分解、资源分析等制定一个科学的计划，能使项目团队的工作有序的开展。也因为有了计划，我们在实施过程中，才能有一个参照，并通过对计划的不断修订与完善，使后面的计划更符合实际，更能准确的指导项目工作。

以前有一个错误的概念，认为计划应该准确，所谓准确，就是实际进展必须按计划来进行。实际并不是如此，计划是管理的一种手段，仅是通过这种方式，使项目的资源配置、时间分配更为科学合理而已，而计划在实际执行中是可以不断修改的。

在项目的不同知识领域有不同的计划，应根据实际项目情况，编制不同的计划，其中项目计划、范围说明书、工作分解结构、活动清单、网络图、进度计划、资源计划、成本估计、质量计划、风险计划、沟通计划、采购计划等等，是项目计划过程常见的输出，应重点把握与运用。3.项目的实施过程

项目的实施，一般指项目的主体内容执行过程，但实施包括项目的前期工作，因此不光要在具体实施过程中注意范围变更、记录项目信息，鼓励项目组成员努力完成项目，还要在开头与收尾过程中，强调实施的重点内容，如正式验收项目范围等。

在项目实施中，重要的内容就是项目信息的沟通，即及时提交项目进展信息，以项目报告的方式定期通过项目进度，有利开展项目控制，对质量保证提供了手段。4.项目的控制过程

项目管理的过程控制，是保证项目朝目标方向前进的重要过程，就是要及时发现偏差并采取纠正措施，使项目进展朝向目标方向。

控制可以使实际进展符合计划，也可以修改计划使之更切合目前的现状。修改计划的前提是项目符合期望的目标。控制的重点有这么几个方面：范围变更、质量标准、状态报告及风险应对。基本上处理好以上四个方面的控制，项目的控制任务大体上就能完成了。5.项目的收尾过程

一个项目通过一个正式而有效的收尾过程，不仅是对当前项目产生完整文档，对项目干系人的交待，更是以后项目工作的重要财富。在经历的很多项目中，更多重视项目的开始与过程，忽视了项目收尾工作，所以项目管理水平一直未能得到提高。另外要重视那一类未能实施成功的项目收尾工作，不成功项目的收尾工作比成功项目的收尾更难，也来得更重要，因为这样的项目的主要价值就是项目失败的教训，因此要通过收尾将这些教训提炼出来。

项目收尾包括对最终产品进行验收，形成项目档案，吸取的教训等。另外，对项目干系人要做一个合理的安排，这也是容易忽视的地方，简单的打发回去不是最好的处理办法，更是对项目组成员的不负责任。

项目收尾的形式，可以根据项目的大小自由决定，可以通过召开发布会、表彰会、公布绩效评估等手段来进行，形式是根据情况采用，但一定要明确，并能达到效果。如果能对项目进行收尾审计，则是再好不过的了，当然也有很多项目是无需审计的。

三、项目管理的九大知识领域

项目管理的九大知识领域是指作为项目经理必须具备与掌握的九大块重要知识与能力。其中核心的四大知识领域是范围、时间、成本与质量管理。在这些知识领域中还涉及很多的管理工具和技术，以用来帮助项目经理与项目组成员完成项目的管理。如：网络图示法、关键路径法、头脑风暴法、挣值法等，不同的工具能帮助我们完成不同的管理工作。另外，还有很多项目管理软件，如：Microsoft Project、P3等，作为项目管理的工具，也可以很好的帮助我们解决在项目的各个过程中完成计划、跟踪、控制等管理过程。1.项目整体管理知识

项目的整体管理，或者说是综合管理也不为错，它是综合运用其他八个领域的知识，合理集成与平衡各要素之间的关系，确保项目成功完成的关键。项目的整体管理包括三个主要过程：

项目计划制定：即收集各种计划编制的结果，并形成统一协调项目计划文档。项目计划执行：通过执行项目计划的活动，来实施计划。整体变更控制：控制项目的变更。

项目经理负责协调完成一个项目所需的人员、计划以及工作，统领全局，带领团队实现项目的目标；当项目目标之间或参与项目的人员之间出现冲突时，负责拍板定夺；并负责及时向高层管理人员汇报项目进展信息。总而言之，项目经理主要负责项目的整体管理，这也是项目成功的关键。回顾以前负责的项目，觉得主要存在以下问题：

未找到项目发起人，或者项目发起人不明确，常把自己当成项目发起人； 项目交付成果定义不清，以致最后收尾时无法对照计划进行验收； 缺少组织结构描述；

对项目的控制未能规范化，尤其是项目范围的变更控制；

风险管理未得到重视，只是在项目组内讨论，并停留在项目负责人的头脑中； 缺乏项目干系人分析；

没有规范的进度报告，项目进展报告随意性较大。

要有效的开展项目管理，引用项目管理的知识体系与方法工具，先依样画葫芦，通过实践，进一步领会这些内容是必须的。

2.项目范围管理知识

项目范围的不确定，会导致项目范围的不断扩大，作为项目经理，在项目开始时，就要对项目范围拿出项目干系人都认可的、理解无歧意的范围说明文档——项目章程。然后为了保证项目的实施，明确项目组成员的工作责任，还必须分解项目范围，使之成为更小的项目任务包——工作分解结构（WBS）。

最后还有就是要认识到项目本身不是孤立的，因此有时范围的变更也是必须的，关键是当变更发生时，如何加以控制。

在以上讨论之前，最重要的是当面临项目时，或不知道具体做什么时，如何进行范围管理。对潜在项目的识别，有四个步骤：

确定做一个什么样的项目；

业务分析，找出重要的业务过程，分析其中最能从项目中得到好处的过程； 形成项目可能的优势，确定范围、好处及约束； 选择方案，分配资源。

对于从多个项目中选择项目，或从多个方案中选择方案的情况，常见的四种方法：整体需要、分类、NPV及加权评分模型。

3.项目的时间管理知识

项目的时间管理，就是确保项目按期完成的过程。首先要制定项目的进度计划，然后是跟踪检查进度计划与实际完成情况之间的差异，及时调整资源、工作任务等，以保证项目的进度实现。在跟踪过程中，要及时与项目干系人进行交流，以及时发现范围的偏差，而产生时间与进度上的差异，或项目组成员有意或无意识的虚报了项目完成情况，导致进度的失控。具体包括以下内容：

活动定义：从WBS分解而来；

活动排序：明确活动之间的依赖关系；

活动历时估算：估算每项活动的时间，可以PERT方法进行； 利用PROJECT 2002等工具软件，协助项目的时间管理； 利用甘特图帮助跟踪项目进度；

利用网络图及关键路径分析，协助确定完成日期上的重要性或调整工期对项目工期的影响，以及处理关注的焦点活动。

需要注意一点，以前学习项目的时间管理工具及方法以后，就以为可以实现对项目的跟踪控制了，其实不然，这些工具都是通过人来发生作用，活动也是由人来完成的，因此项目经理不能把太多心思花在工具上，而是学会利用工具来协调人与资源的矛盾冲突。4.项目的成本管理知识

对于项目经理在成本管理方面，就是要努力减少和控制成本，满足项目干系人的期望。其过程包括： 资源计划：即制定资源需求清单； 成本估算：对所需资源进行成本估算；

成本预算：将整体成本估算配置到各个单项工作，建立成本基准计划；

成本控制：控制项目预算的变化，修正成本的估算，更新预算，纠正项目组成员的行动，进行完工估算与成本控制的分析。

在成本管理中涉及很多财务管理的概念、术语、基础理论及方法与工具的使用，作为项目经理，对这些内容要熟悉，特别是挣值分析的相关术语及简称，如：BCWS、BCWP、ACWP、CV、SV、CPI、SPI等等，不光要了解这些术语的涵意，还要掌握他们的计算公式。5.项目人力资源管理知识

项目的人力资源管理就是有效发挥每个参与项目的人员的作用的过程。项目的人力资源管理过程包括： 组织计划编制：形成项目的组织结构图； 获取相关人员：其中重点是业务相关人员；

团队建设：明确每个项目干系人的责任，训练与提高其技能，实现团队的合作与沟通。

因为与人发生关系，其中首先是要明确各自的责任，这一点计划编制时就要明确，可以通过项目管理软件帮助项目经理提高效率，并能及时发现任务分解的合理性，最后形成合理的任务分解表。

同时，要通过有效的激励方法来帮助项目成员实施项目计划，提高效率。项目是通过团队共同努力实现的，注意充分发挥团队的作用，使团队成员各尽所能是项目经理的挑战。在处理过程中，争取做到对事不对人，通过有效的会议来帮助项目实现沟通、检查以及目标实现。6.项目的质量管理知识

项目的质量，理解为项目满足客户明确或隐含的要求的一致性程度。注意这里包括明确的要求，也包括隐含的要求。这对IT项目来说，如何满足用户隐含的质量要求，可能是IT项目质量失败的重要原因。可能所开发的系统符合需求说明中的要求，却与用户实际的要求（包含隐含的需求中），相差很大，导致不一致，结果导致IT项目的失败。

现代质量管理经过了一个发展过程，目前已建立起相对完善的质量体系，国际组织也有相关的质量文件，以评审普通的生产质量，如ISO2000系列质量标准；对软件的生产质量，也有一些评价模型，如SQFD模型、CMM软件成熟度模型等等。其中CMM成熟度模型分成五个层次：自发的、简单的、有组织的、被管理的及适应的，分别标识为不同的级别。

对于项目管理需要制订质量计划，并应用质量保证的工具确保质量计划的实施。在质量控制的过程中，有许多现成的工具与方法，如帕累托分析、统计抽样和标准差等。要提高项目的质量，必须在领导中形成质量意识，通过建立一个好的工作环境来提高质量，通过形成质量文化来改进质量，是全面提升项目质量管理的关键因素之一。在以往所经历的项目中，项目的质量管理基本上没有得到重视，公司每年都在开展QC活动，该活动的目的就是改进质量，但活动成了科技创新活动，而更多的项目实施过程中，如何开展质量管理，却未能有所体现，这也是值得探讨的问题。

7.项目的沟通管理知识

项目的沟通管理非常重要，对项目经理而言，就如同前线指挥需要情报管理一样，这是使整个项目组掌握项目信息，实施其他管理手段的基础，所有的控制都有基于沟通基础之上的。

在项目的开始，需要编制沟通计划，包括什么时间、将什么内容、以什么样的格式、通过什么样的方式、向谁传递。在项目的沟通中，可以采用书面报告、口头报告或非正式的交流，各种方式有利也有弊，关键看是否有利于沟通的效果。

沟通的复杂程度随着对象的增加而快速增加，因此要通过适当的工具和手段，使面对面的沟通控制在一定范围之内，尽量减少因无效沟通而给项目管理带来的负责影响。

在沟通中，会议是有效形式之一。很多业务员人员喜欢通过会议，以简单的形式化的语言描述项目的进展与项目中碰到的问题，而不喜欢技术化的图表与文档。8.项目的风险管理知识

当因为未能做好风险管理，导致项目的风险发生时，项目干系人将难以一下子接受风险发生的事实以及风险所带来的损失，需要用更多的时间来调整心理状态，才能恢复对项目的实施。

项目的风险管理不仅是在项目进行过程中，有效避免风险的发生；而且能在风险发生时，帮助我们用正确的心态去面对，而不会手足无措。很多项目的失败，是因为风险发生时，对项目干系心理上造成的伤害，导致失去主观 15 判断能力，而作出错误的决策。从这种意义上讲，项目的风险计划的制定主要是为提高项目干系人的风险意识，只要有了足够的风险意识，风险识别全面与否，在有些项目中可能重要性反而不是太明显。

风险识别可以采用头脑风暴法、经验法则等方法，在识别这些风险因子之后，可以对这些因子加上权重，最后可以计算出项目成功的概率，并能据此决策项目是否应该开展、继续或停止。识别风险因子之后，紧接着就是制定风险应对措施。根据风险发生的概率，产生的风险成本与收益，决定相应的应对策略，如风险处理、风险接受、风险改善等等。

实际工作中，可能识别到存在的风险，但却不能加以正确处理。风险就这样被层层传递。如因用户参与不够，导致需求不正确，进一步产生工期估计的失误，结果是计划的偏差，最后整个项目的结果产生偏差。因此，要注意从风险的源头抓起，防止风险的层层放大。9.项目的采购管理知识

采购就是从外界获得产品或服务。对于IT项目而言，采购变得越来越重要。目前绝大多数的IT项目都离不开采购管理，而且很多项目的主要内容就是设备采购或咨询采购，对于企业而言，能否做好采购管理是保证项目成功的重点内容。

有效采购管理包括以下过程：

编制合理有效的采购计划：这是项目管理的一个重要过程，即确定项目的哪些需求可以通过采购得到更好的满足。在采购计划中，首先是决定是否需要采购、如何采购、采购什么、采购多少、何时采购等内容； 编制询价计划：即编制报价邀请书RFQ或招标书； 询价：进行实际询价；

开标：评估并选择供应商； 管理：对采购合同进行管理； 收尾：对采购合同进行收尾。

在整个过程中，容易忽视的两个过程，一是采购计划，二是合同收尾。采购计划的编制，是采购管理整体按需求进行的前提，如果这一步做不好，其他都是白费劲；而在采购的合同收尾过程中，最容易忘记或做不到的就是采购审计。至于供应商的选择等过程，在IT项目中，往往会过分重视技术，而忽略管理与成本。其实，管理与成本决定合同能否按期保持履行的前提。在我公司的实际情况中，一般项目以设备为主要成本时，往往就不再考虑其他内容，而仅是作为一般的设备采购，交会器材部门实施。因为不光没能做到项目管理，亦未做到采购管理，所以这类项目虽然也实施完成了，但项目的实施质量总令人不太满意。[结束语]

PMP认证要求申请者必须具备的专业经历至少具有3年以上4500小时的项目管理经历。之所以有这样的要求，是因为项目管理不只是光靠读两本书，掌握几个工具的使用就能胜任的，很多知识与经验，需要在实际的项目管理实践中体会与积累。

IT项目管理的五大错误

范围管理：项目成功一环

定义并计划一个项目只是成功管理一个项目的第一步。在你制订工作计划后，你就要按照这个计划工作。你必须保证工作要在规定的时间和预算范围内完成。一旦项目开始进行，客户就会不断要求你完成超出原来范围的工作，或者和原来范围不同的工作。这就是你必须要使用范围变化管理的时候。如果你不善用此一技巧，你就会因为要完成比原先同意的工作，还要多上好几倍预算和工作量因而疲于奔命。换句话说，你将会遭到很大的麻烦。

导致项目失败的主要原因

一般IT经理都经历过不太成功的项目。以下将讨论五个最为常见的项目管理错误。切记：“糟糕的计划是项目管理第一大失误”。

范围管理从范围定义开始

定义项目范围是定义一个项目过程中最重要的部分。如果你不确定你在进行的是什么，以及你所进行的项目底线，你就根本不可能成功。管理项目范围是项目管理里最重要的一部分。但是，如果你没有好好定义项目范围，管理项目范围几乎就是不可能的任务。

定义项目范围的目的，是把项目的逻辑范围清楚地描述出来并获得认可。范围陈述被用来定义哪些工作是包括在该项目内，而哪些工作又是在该项目范围之外。你能够把项目范围定义得越清楚，你的项目目标就会越明确。下面的信息整理会有所帮助。

 • 范围内和范围外的交付使用类型（商业需求、目前状况评估）

 • 范围内和范围外的生命周期流程（分析、设计、测试） • 范围内和范围外的数据类型（财务、销售、雇员情况等） • 范围内和范围外的数据来源或数据库（账单、总帐、薪水明细等。） • 范围内和范围外的组织（人力资源、制造商、供货商等）

 • 范围内和范围外的主要功能（决策支持、数据输入、管理报告）

可行的范围变化流程

项目经理和项目小组必须意识到范围变化本身并没有什么不对，也就是说在项目进行过程中修改范围并不是个坏主意。事实上，在很多时候里，这也是一件好事。首先，客户通常都不能确定其所希望的解决方案具有何种需求和功能。其次，就算客户十分清楚终极目标，商业动态亦随着时间不断变化，因此项目的需求也会发生变化。

如果你不能够容纳变化，最终的解决方案就达不到预定的成效，甚至有可能完全无用。因此，你必须在需要时拥有改变项目流程的能力。如果项目经理对于项目变化没有准备，问题将陆续发生。每一个项目都应该有一个流程以进行有效管理变化。这个流程应该包括确定变化、评估变化的商业价值、评估对于项目的影响，然后把这些信息提报给项目发起人进行评估。

发起人可以决定是否同意该变化。如果同意，发起人还应该考虑变化对项目的影响程度，然后追加预算或延长项目时间。

IT项目管理：问题、体系、方法

摘要：无论是在国内还是国外，项目管理的学科、技术和应用的普及与发展已经进入了一个飞速发展的时代，信息技术（Information Technology，简称IT）的发展又将IT项目管理推向了全新的应用高度。本文分析了IT项目管理技术及其应用与发展的关键问题，提出了基于系统集成理念构建的IT项目管理的体系结构和技术框架，肯定了IT项目管理的总体指导思想和实施策略是“需求牵引、效益驱动、总体规划、分步实施”。

关键词：信息技术

项目管理

体系结构 引言

人类进入21世纪，信息化成为我国全面构建和谐社会、快速发展国民经济的着眼点。党的十五届五中全会就明确指出：“大力推进国民经济和社会信息化，是覆盖现代化建设全局的战略举措。以信息化带动工业化，发挥后发优势，实现社会生产力的跨越式发展。”党的十六大再次明确：“信息化是我国加快实现工业化和现代化的必然选择。坚持以信息化带动工业化，以工业化促进信息化，走出一条科技含量高、经济效益好、资源消耗低、环境污染少、人力资源优势得到充分发挥的新型工业化路子。”目前全国上下各行各业、各个领域、各个层面的信息化建设正在如火如荼地进行着。

信息化项目的开展是以信息技术为支撑，以业务活动为主体，以现代化管理为指导思想的一项全新的、复杂的系统化工程。全新在于信息技术这一新生事物的飞速变化与发展，复杂在于信息技术、业务工作、项目管理思想的一体化融合与集成化应用，这正是IT项目管理问世的缘由。信息化建设的成功经验告诉我们，结合信息化应用特点，采用项目管理技术而开发的专用方法对IT项目在计划落实、质量跟踪、成本管理和风险控制等方面进行管理，是保证IT项目达到预期目标的有效手段。

本文在项目管理知识体系的基础上，介绍了IT项目管理的特殊性，回顾了学术界和工业界在不同方向上为解决这些问题所做的努力、获得的成果。在系统集成理念的指导下，探讨IT项目管理的体系结构和模型驱动的集成技术与方法。IT项目管理的特殊性

信息技术发展快、渗透广等特点，使得IT项目与一般工程项目存在着明显的差别，这种差异性造成了基于工程项目管理理论与经验基础上发展起来的项目管理知识体系在处理IT项目时面临诸多的难题。

第一，IT项目的需求来源广泛，涉及国民经济的各个领域，几乎所有领域都能够和信息技术相结合而构成信息化项目。信息技术可以支持多种业务需求的发展：

（1）市场要求，如商业银行提供网上支付业务，以支持越来越频繁的电子商务活动。

（2）环境需求，如企业为了应对各国越来越严格的环境标准中对产品回收再利用的要求，启动一个构建产品全生命周期管理系统的项目。

（3）经营需要，如一个传统的大型商业企业开展网上销售业务，以扩大其销售收入。（4）技术发展，如飞机制造企业为了提高设计水平而开展虚拟制造系统的项目。

（5）用户要求，如快递公司要构建一个物流管理系统，以满足顾客对跟踪其委托的快递物件过程状态的查询需求。

（6）法律需求，如一个城市为了减少合同犯罪的数量，而启动企业印鉴信息系统；为了杜绝假文凭的泛滥而建 立文凭查询信息系统。

正是由于信息化项目涉及到了几乎所有的经济领域，因此很难形成有针对性的规范和标准，这无疑增加了项目管理的难度。

第二，与一般工程项目所涉及的领域经过了长时期的发展、技术相对成熟不同，IT领域是目前发展最快、最活跃的领域，新的技术层出不穷，技术更新也非常迅速，因此IT项目开展过程中会具有更多的风险因素。有统计表明，每18个月，CPU的速度就会翻一番，与之关联的计算机体系结构、软件架构等也发展非常迅速。例如早期的集成信息系统采用大型主机带终端的结构，随着网络技术和分布式计算技术的发展，出现了Client/Server结构的信息系统，而目前流行的架构则是在互联网上基于Browser/Server结构的信息系统，C、C++、Java等各种开发工具更是一代代迅速更迭，各类操作系统、协议、标准等都是IT项目必须面对的，这些都会增加项目过程中的风险。

为了处理好技术发展迅速所带来的问题，IT项目团队必须在先进性、实用性、经济性、成熟性等诸多方面进行权衡，片面追求技术的先进性往往会事与愿违。在保证项目所采取的技术具有相当的前瞻性、先进性和可扩展性、可集成性的同时，从需求出发，注意技术的可靠性、成熟性和经济性。

第三，信息技术的应用主体在管理领域，管理信息系统包含了特定的管理理念，将这些管理理念同企业的发展战略与业务逻辑进行整合是信息系统实施的关键任务。IT项目的阻力75%以上是来自人和管理的因素，因此，IT项目特别强调技术、管理与人的集成。如何处理好信息系统所涉及的人的问题是成功管理IT项目的关键。

从更深层的角度而言，经典项目管理理论是构建在土建工程项目的研究和实践基础上的，基本的项目管理方法并不能解决IT项目的特殊问题，例如：

（1）如何衡量项目进度的问题，土建工程使用完成土石方的量来标识工程进度，但是完成软件90%的代码编写工作并不意味着还有10%的时间就可以完成软件开发项目了。业界普遍认为在工程项目中广泛使用的挣值法在IT项目中缺乏适应性。

（2）在计划的调整方法上，土建工程在计划拖期时，可以通过增加资源的方式来加快进度，但是对于一个软件开发项目，如果出现同样的问题，寄希望于增加编程人员的数量来追赶工期，只能造成更大的麻烦。

另外，除了信息技术之外，IT项目还涉及信息系统应用单位的组织、管理的调整与经营过程/业务流程的重构，单靠信息技术是无能为力的。因此，要成功管理IT项目，要成为IT项目的合格从业人员，需要一套全面的IT项目的知识体系与方法的支撑，它的内容将覆盖项目管理、信息技术、现代管理技术、系统集成技术、软件工程技术等多学科领域，这正是IT项目管理技术研究和实践的目标与方向。IT项目管理技术的发展脉络

目前在信息化领域的不同方向，许多学者开发了针对不同方面的项目管理方法，其中比较有代表性的是软件项目管理和广义的IT项目管理。

软件项目管理是软件工程和项目管理的有效结合，将项目管理中重视过程、重视计划控制的观点引入软件工程领域，目的是控制软件开发项目的成本、进度、质量、风险等问题。近几年IT领域进一步引进全面质量管理理念，认为软件开发企业自身质量控制体系和控制能力的优劣，将会极大地影响软件产品的质量，这就要求软件企业从修炼内功入手，也就是确认质量是控制出来的而不是检测出来的，从根本上保证软件产品的质量，由此提出了软件过程改进和软件能力成熟度模型(CMM)的概念。CMM基于经典的产品质量原理，建立了定量控制软件过程的项目管理和项目工程的基本原则，与此同时，CMM有关能力成熟度的操作方法也被引入经典项目管理领域，用以测评承担项目的组织的项目管理能力。

广义IT项目管理是目前业界讨论比较多的，也出了不少这方面的专著，其基本思路是将IT项目当做一般工程项目，使用PMBOK的方法体系，结合一些信息技术项目的案例，研究如何在信息技术项目中应用项目管理方法。

广义IT项目管理是将所有与IT有关的项目不加区分地通盘考虑，包括IT产品开发项目的管理和IT应用项目的管理。实际上广义IT项目可以细分出多个类别，各个类别之间的差距是非常巨大的。计算机硬件开发项目与一般家用电器产品的开发设计具有非常高的相似度，而软件设计开发则完全不同，信息技术应用项目与上述两个分支领域更是存在巨大的差异，因此广义的IT项目管理实际上是在经典项目管理知识体系的基础上，尝试解决IT项目的具体问题。目前来看这种处理方式比软件项目管理体系的针对性差很多，对其进行细分研究具有非常重要的意义。为了提高IT项目管理的针对性，提高解决方案的系统性，学术界和企业界在企业信息化、数字化城市与电子政务、数字化军工、供应链与物流、电子商务等不同领域分别开展了体系结构、实施指南、参考模型等的研究和实践，取得了一定的成果。IT项目管理的体系结构与方法论

系统参考体系结构是“一组用以描述所研究系统的不同方面和不同开发阶段的、结构化的、多层次多视图的模型和方法的集合，体现了对系统的整体描述和认识，为对系统的理解、设计、开发和构建提供工具和方法论的指导”。

系统参考体系结构为IT项目的管理提供了体系参考和方法论，经过各国专家的努力，已经形成了一批相当有代 表性和广泛影响力的体系结构及其建模方法，并进行了大量的工业实践，如CIM开放系统体系结构(CIM-OSA)、GRAI集成方法论(GIM)、IMPACS、普度参考体系结构(PERA)、集成的信息系统体系结构(ARIS)、通用企业参考体系结构与方法论(GERAM)，以及在我国提出的阶梯形CIM系统参考体系结构(SLA)等。

在信息化项目管理过程中，系统的认识和构建是阶梯上升的，在概念定义阶段需要明确企业的战略目标，并据此形成集成系统的目标，然后围绕系统目标，从组织、资源、信息、产品、功能和经营过程等角度描述企业的现状，形成对企业基本框架和运行机制的完整描述。在这些描述的约束下，采用合适的模型分析手段进行分析，找出现有系统中的问题进行改进，然后构建目标系统，形成多视图的目标系统的描述。在形成目标系统描述时，除了使用各个视图的描述方法外，还可以应用其他建模方法，以便提供对系统更为完整的描述。完成基于模型的设计后，就是在构建工具集的帮助下，将设计转化为实际系统构建的技术说明，并构建实际系统。系统描述对于系统的运行仍然能够发挥作用，可以作为实际系统运行的参考，并据此进行系统的优化与调整。

一方面由于信息化项目的多专业性，为了解决沟通和分析设计的问题，需要借助建模的手段实现对被处理对象系统的描述；另一方面由于信息化处理对象的复杂性，依据“化繁为简、分而治之”的原则，使用多层次多视图的模型来描述目标系统。视图的划分包括反映结构信息的信息视图、资源视图、组织视图、产品视图，反映系统时间和逻辑特征的过程视图，结合反映系统功能结构和功能关系的功能视图，以及反映企业经济性和目的性的经济视图。静态结构反映了系统的存在，行为结构给出了系统的属性和运行方式，而评价结构则将系统和它的目的性关联在一起。透过多视图，为IDEF、ARIS等其他建模方法和工具的集成，对于制造企业原模型和企业本体的开发提供了技术框架。利用模型技术解决IT项目的交流、设计、技术转移、系统构建乃至运行维护的问题是目前学术界和业界的普遍看法，模型驱动的体系结构是目前的一个研究和实践的热点。结论

随着信息技术的发展和应用范围的不断扩大，IT项目管理越来越具有普遍性。分析IT项目的内在特征和特有问题，在项目管理知识体系的架构下，有针对性地开发适应性的理念和方法，将是IT项目管理领域的发展方向。

需要强调的是，信息技术本身的发展并不是IT项目的目的，满足应用对象的需求和战略目标才是其出发点，因此需要切实做好项目的需求分析，一切从业务工作的实际需求出发，在集成理念的指导下，充分考虑整个系统的集成要求，并在此基础上选择相关的成熟技术、应用系统和产品，同时做好项目的技术经济分析，才能保证信息化项目发挥实效。国家863计划CIMS主题专家组在大量信息化工程实践的基础上提出的“需求牵引、效益驱动、总体规划、分步实施”的策略是IT信息化项目管理的总体指导思想。

成功的软件项目需要几点要求

现在,随着国内的软件企业的逐渐的增多,而且,外资企业也不断的深入到我国的软件领域,来分享我们的一些或大或小的软件项目.我们始终有一中压力的感觉.说句不好听的话,我们现在的软件整体水平和欧美的差距越来越大,和日本的差距也很大,为什么这么大,难道我们真的没有能力把项目做好.或者我们根本做不好这个领域的项目.不是,我们做不好,而是,我们缺少的东西太多了.我就根据自己在日企做过的一些项目,来谈谈自己的一些个人所得吧.第一:自责

在项目无论是开始还是进行中,还是即将结束的时候,对项目出现的问题,大家一定不要互相推托责任,而是明确项目不是一个人的项目,是大家共同的项目.是一个集体性的活动.无论项目是成功还是失败,大家都有不可推卸的责任.同时也希望项目负责人或者公司的领导多说几句这样的话,让大家都有压力的存在.不要把所有的责任都推托到项目负责人身上,难道你身上没有责任吗?都有责任的.多一些自责,建立自己的威信.有利于以后的项目的开展.有利于大家的合作.第二:责任

责任,是一个比较复杂的东西.成功了,大家都希望,有自己的功劳.而失败了,大家都想把责任推托到别人的身上,和自己没有任何关系.其实事实也并不是这样.我想这个问题大家都比较明白.咱们举一个比较简单的例子:小偷偷东西.如果大家看到有人在背后偷别人的东西,都去制止一下,小偷不会这么猖狂.如果大家都把自己的东西放在比较隐蔽的地方,小偷也不会偷东西.如果国家对小偷的打击力度在大一点.小偷也不会那么大胆了.好多如果,好多假设.但是,大家都有责任.小偷不偷你的东西,而你开心.小偷偷了你的东西.你伤心.如果，在如果.小偷也不会偷你的东西了.对不对.和我们的项目一样,如果大家都有责任心,都想如何把项目做好.遇到一些同事的不积极,而去主动沟通和交流.遇到同事的问题,一起解决.那么,项目还会失败吗? 第三:任务

现在,大家把任务,都作为自己的任务.而别人的任务,和自己没有任何关系.是不是真的没有关系呢?咱们在举一个 例子:在软件开发的过程中,一个程序员没有按照需求去写,而你发现,而没有制止.那么在写完后.你的程序和他的程序进行,调试.你如何都不能调试过去,这个时候,你会不会想到是它的原因,而不是自己的原因,是不是为这个原因而花费掉好多金钱和时间呢?如果你在做好自己的同时,也会去帮助一些他,那么整体的效率是不是就提高了.希望大家在以后的项目开发过程中,不要把自己的任务,作为任务,实际上其他人的任务,并不是项目负责人一个人的任务,而是大家的共同的任务.第四:务实

如果把这两各自分开来理解:任务和实际.意思就是说我们不仅要做好自己的任务,而且要切合实际.保证质量.保证进度.这可能需要大家的一个共同的心态吧.如果大家都把自己的工作保持完美,那么整体的工作一定会很完美的.什么都不能和务实相比较.在项目启动的时候,大家要多进行交流和沟通,因为我们的目的只有一个.把项目做好.只有项目做好了.我们才可以做大项目.只有做大项目了,我们自己的能力才可以得到发挥.那么属于我们的东西就自然而然多了.真诚希望大家能在一起互相讨论一下,如何把项目做得更好,更美.其实,我们个人和日本以及欧美是没有差距的.而是我们对问题的看法不一致.相信,我们整理的力量也会比他们厉害的.加油吧.让我们一起努力吧.对软件项目管理的探讨

一、引言

随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。各软件企业都在积极将软件项目管理引入开发活动中，对开发实行有效的管理。我公司是西安一家中型软件企业，在公司中已经实行了项目管理制度，软件项目管理是整个项目管理中的一个重要组成部分。

从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展（即减小开发风险）。

软件开发不同于其他产品的制造，软件的整个过程都是设计过程（没有制造过程）；另外，软件开发不需要使用大量的物质资源，而主要是人力资源；并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。基于上述特点，软件项目管理与其他项目管理相比，有很大的独特性。

二、软件项目管理的组织模式

软件项目可以是一个单独的开发项目，也可以与产品项目组成一个完整的软件产品项目。如果是订单开发，则成立软件项目组即可；如果是产品开发，需成立软件项目组和产品项目（负责市场调研和销售），组成软件产品项目组。

公司实行项目管理时，首先要成立项目管理委员会，项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。

1、项目管理委员会

项目管理委员会是公司项目管理的最高决策机构，一般由公司总经理、副总经理组成。主要职责如下：

（1）依照项目管理相关制度，管理项目；

（2）监督项目管理相关制度的执行；

（3）对项目立项、项目撤消进行决策；

（4）任命项目管理小组组长、项目评审委员会主任、项目组组长.2、项目管理小组

项目管理小组对项目管理委员会负责，一般由公司管理人员组成。主要职责如下：

（1）草拟项目管理的各项制度；

（2）组织项目阶段评审；

（3）保存项目过程中的相关文件和数据；

（4）为优化项目管理提出建议。

3、项目评审小组

项目评审小组对项目管理委员会负责，可下设开发评审小组和产品评审小组，一般由公司技术专家和市场专家组成。主要职责如下：（1）对项目可行性报告进行评审；

（2）对市场计划和阶段报告进行评审；

（3）对开发计划和阶段报告进行评审；

（4）项目结束时，对项目总结报告进行评审。

4、软件产品项目组

软件产品项目组对项目管理委员会负责，可下设软件项目组和产品项目组。软件项目组和产品项目组分别设开发经理和产品经理。成员一般由公司技术人员和市场人员构成。主要职责是：根据项目管理委员会的安排具体负责项目的软件开发和市场调研及销售工作。

三、软件项目管理的内容

从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发，还是团队协作开发，这六个阶段都是不可缺少的。

根据公司实际情况，公司在进行软件项目管理时，重点将软件配置管理、软件质量管理、软件风险管理及开发人员管理四方面内容导入软件开发的整个阶段。

在八十年代初，著名软件工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则，同样，我们在进行软件项目管理时，也应该遵循这七条原则。它们是：

（1）用分阶段的生命周期计划严格管理；

（2）坚持进行阶段评审；

（3）实行严格的产品控制；

（4）采用现代程序设计技术；

（5）结果应能够清楚地审查；

（6）开发小组地人员应该少而精；

（7）承认不断改进软件工程实践地必要性。

四、编写《软件项目计划书》

项目组成立的第一件事是编写《软件项目计划书》，在计划书中描述开发日程安排、资源需求、项目管理等各项情况的大体内容。计划书主要向公司各相关人员发放，使他们大体了解该软件项目的情况。对于计划书的每个内容，都应有相应具体实施手册，这些手册是供项目组相关成员使用的。

《软件项目计划书》一般应该包括下述内容：

1.引言

1.1计划的目的

1.2项目的范围和目标

1.2.1范围描述

1.2.2主要功能

1.2.3性能

1.2.4管理和技术约束

2.项目估算

2.1使用的历史数据

2.2使用的评估技术

2.3工作量、成本、时间估算

3.风险管理战略

3.1风险识别

3.2有关风险的讨论

3.3风险管理计划

3.3.1风险计划

3.3.2风险监视

3.3.3风险管理

4.日程

4.1项目工作分解结构

4.2时限图(甘特图)

4.3资源表

5.项目资源

5.1人员

5.2硬件和软件

5.3特别资源

6.人员组织

6.1组织结构

6.2管理报告

7.跟踪和控制机制

7.1质量保证和控制

7.2变化管理和控制

8.附录

五、软件配置管理

是否进行配置管理与软件的规模有关，软件的规模越大，配置管理就显得越重要。软件配置管理简称SCM（Software Configuration Management的缩写），是在团队开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。

1、目前软件开发中面临的问题

。在有限的时间、资金内，要满足不断增长的软件产品质量要求；

。开发的环境日益复杂，代码共享日益困难，需跨越的平台增多；

。程序的规模越来越大；

。软件的重用性需要提高；

。软件的维护越来越困难。

2、软件配置管理应提供的功能

在ISO9000.3中，对配置管理系统的功能作了如下描述：

。唯一地标识每个软件项的版本；

。标识共同构成一完整产品的特定版本的每一软件项的版本；

。控制由两个或多个独立工作的人员同时对一给定软件项的更新；

。控制由两个或多个独立工作的人员同时对一给定软件项的更新；

。按要求在一个或多个位置对复杂产品的更新进行协调；

。标识并跟踪所有的措施和更改；这些措施和更改是在从开始直到放行期间，由于更改请求或问题引起的。

3、版本管理

软件配置管理分为版本管理、问题跟踪和建立管理三个部分，其中版本管理是基础。版本管理应完成以下主要任务：

。建立项目；

。重构任何修订版的某一项或某一文件；

。利用加锁技术防止覆盖；

。当增加一个修订版时要求输入变更描述；

。提供比较任意两个修订版的使用工具；

。采用增量存储方式；

。提供对修订版历史和锁定状态的报告功能；

。提供归并功能；

。允许在任何时候重构任何版本；

。权限的设置；

。晋升模型的建立；

。提供各种报告。

4、配置管理软件PVCS 6.0

PVCS6.0是一套非常优秀的配置管理软件，它能够实现配置管理中的各项要求，并且能和多种流行开发平台集成，为配置管理提供了很大的方便。

六、软件质量管理

随着软件开发的规模越来越大，软件的质量问题显得越来越突出。软件质量的控制不单单是一个软件测试问题，在软件开发的所有阶段都应该引入质量管理。我公司除加强了国家标准“信息技术软件生存期过程”（GB/T8566--1995）的规范管理外，还积极为通过ISO 9000.3做准备。

1、软件质量保证计划

在进行软件开发前，需要有一个《软件质量保证计划》。目前较常用的是ANSI/IEEE STOL 730--1984，983--1986标准，包括以下内容：

1.计划目的2.参考文献

3.管理

3.1.组织

3.2.任务

3.3.责任

4.文档

4.1.目的

4.2.要求的软件工程文档

4.3.其他文档

5.标准和约定

5.1.目的5.2.约定

6.评审和审计

6.1.目的6.2.评审要求

6.2.1.软件需求的评审

6.2.2.设计评审

6.2.3.软件验证和确认评审

6.2.4.功能评审

6.2.5.物理评审

6.2.6.内部过程评审

6.2.7.管理评审

7.测试

8.问题报告和改正活动

9.工具、技术和方法

10.媒体控制

11.供应者控制

12.记录、收集、维护和保密

13.培训

14.风险管理

2、质量管理的基本原则

。控制所有过程的质量；

。过程控制的出发点是预防不合格；

。质量管理的中心任务是建立并实施文件化的质量体系；

。持续的质量改进；

。有效的质量体系应满足顾客和组织内部双方的需要和利益；

。定期评价质量体系；

。搞好质量管理关键在于领导。

3、软件质量因素

正确性：系统满足规格说明和用户目标的程度，即，在预定环境下能正确地完成预期功能的程度。

健壮性：在硬件发生故障、输入的数据无效或操作错误等意外环

境下，系统能做出适当响应的程度。

效率：为了完成预定的功能，系统需要的计算资源的多少。

完整性（安全性）：对未经授权的人使用软件或数据的企图，系统能过控制（禁止）的程度。

可用性：系统在完成预定应该完成的功能时另人满意的程度。

风险：按预定的成本和进度把系统开发出来，并且为用户所满意的概率。

可理解性：理解和使用该系统的容易程度。

可维修性：诊断和改正在运行现场发现的错误所需要的工作量的大小。

灵活性（适应性）：修改或改进正在运行的系统需要的工作量的多少。

可测试性：软件容易测试的程度。

可移植性：把程序从一种硬件配置和（或）软件系统环境转移到另一种配置和环境时，需要的工作量多少。有一种定量度量的方法是：用原来程序设计和调试的成本除移植时需用的费用。

可再用性：再其他应用中该程序可以被再次使用的程度（或范围）。

互运行性：把该系统和另一个系统结合起来需要的工作量的多少。

4、软件评审

软件评审并不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误，如果这些错误不及时发现并纠正，会不断地扩大，最后可能导致开发的失败。下面这组数据可以清楚的看出前期的错误对后期的影响。

软件评审是相当重要的工作，也是目前国内开发最不重视的工作。

（1）评审目标

。发现任何形式表现的软件功能、逻辑或实现方面的错误；

。通过评审验证软件的需求；

。保证软件按预先定义的标准表示；

。已获得的软件是以统一的方式开发的；

。使项目更容易管理。

（2）评审过程

A、召开评审会议：一般应有3至5人参加，会前每个参加者做好准备，评审会每次一般不超过2小时。

B、会议结束使必须做出以下决策之一：接受该产品，不需做修改；由于错误严重，拒绝接受；暂时接受该产品。

C、评审报告与记录；所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审简要报告。

（3）评审准则

。评审产品，而不是评审设计者（不能使设计者有任何压力）；

。会场要有良好的气氛；

。建立议事日程并维持它（会议不能脱离主题）；

。限制争论与反驳（评审会不是为了解决问题，而是为了发现问题；

。指明问题范围，而不是解决提到的问题；

。展示记录（最好有黑板，将问题随时写在黑板上）；

。限制会议人数和坚持会前准备工作；

。对每个被评审的产品要尽力评审清单（帮助评审人员思考）；

。对每个正式技术评审分配资源和时间进度表；

。对全部评审人员进行必要的培训；

。及早地对自己地评审做评审（对评审准则的评审）。

5、ISO9000.3软件质量认证体系

ISO9000.3是ISO9000质量体系认证中关于计算机软件质量管理和质量保证标准部分。它从管理职责、质量体系、合同评审、设计控制、文件和资料控制、采购、顾客提供产品的控制、产品标识和可追溯性、过程控制、检验和试验、检验/测量和试验设备的控制、检验和试验状态、不合格品的控制、纠正和预防措施、搬运/贮存/包装/防护和交付、质量记录的控制、内部质量审核、培训、服务、统计系统等二个方面对软件质量进行了要求。

6、测试

软件测试是软件开发的一个重要环节，同时也是软件质量保证的一个重要环节。所谓测试就是用已知的输入在已知环境中动态地执行系统（或系统的部件）。测试一般包括单元测试、模块测试、集成测试和系统测试。如果测试结果与预期结果不一致，则很可能是发现了系统中的错误，测试过程中将产生下述基本文档：

（1）测试计划：确定测试范围、方法、和需要的资源等。

（2）测试过程：详细描述和每个测试方案有关的测试步骤和数据（包括测试数据及预期的结果）。

（3）测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，并且必须经过调试解决所发现的问题。测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，并且必须经过调 试解决所发现的问题。

七、软件风险管理

软件项目管理存在着风险，如果我们提前重视风险，并且有所防范，就可以最大限度减少风险的发生。进行风险管理是有效的手段。

1、风险的分类

根据风险内容，我们可以将风险分为项目风险（成本提高，时间延长等）、技术风险（技术不成熟等）、商业风险（销售问题等）、战略风险（公司的经营战略发生了变化）、管理风险（公司管理人员是否成熟等）、预算风险（预算是否准确等）等。

另外，我们还可以将风险分为已知风险（如员工离职等）、可预报风险（从以往经验得出可能有风险的）和不可预知风险。

2、风险的识别

风险识别的有效方法是建立风险项目检查表。主要涉及以下几方面检查：

。产品规模风险检查

。业务影响风险检查

。与客户相关的风险检查

。过程风险检查

。技术风险检查

。开发环境风险检查

。与人员的模式和经验有关的风险检查

3、风险评估

风险评估主要从下面七个方面进行：

。发生的可能性

。发生的结果（影响）

。建立一个尺度表示风险可能性（如，极罕见、罕见、普通、可能、极可能）

。描述风险带来的后果

。估计对产品和项目的影响

。确定风险评估的正确性

。根据影响排定有限队列

另外，要对每个风险的表现、范围、时间做出尽量准确的判断。

4、风险的评价

对风险的评价主要依据三个因素：风险描述、风险概率和风险影响。从成本、进度及性能三个方面对风险进行评价。确定项目的中止点，在中止点出再一次进行风险评价。

5、风险的驾驭和监控

风险的驾驭与监控主要要靠管理者的经验来实施。如，某开发人员的离职概率是0.7，离职后会对项目造成一定的影响，则该风险驾驭和监控的策略如下：

。与在职人员协商，确定流动原因。

。在项目开始前，把环节这些流动原因的工作列入风险驾驭计划。

。项目开始时，作好人是会流动的准备，采取一些措施确保人员一旦离开时，项目仍能继续。

。制定文档标准，并建立一种机制，保证文档及时产生。

。对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作。

。对每个关键性技术人员培养后备人员。

在考虑风险成本之后，决定是否采用上述策略。

八、人员管理

1、对项目经理的要求

。能够使小组每个成员都能发挥能力

。有一定的组织能力

。能够使小组美味成员有成就感

。有提出解决问题方案的能力

。对问题的理解有一定的深度

。要能让成员知道软件质量的重要性

2、人员的通讯方式

（1）正式非个人方式，如正式会议等；

（2）正式个人之间交流，如成员之间的正式讨论等（一般不形成决议）；

（3）非正式个人之间交流，如个人之间的自由交流等；

（4）电子通讯，如E-MAIL（电子邮件）、BBS（电子公告板系统）等；

（5）成员网络，如成员与小组之外或公司之外有经验的相关人员进行交流；

在实践中发现，（5）的通讯效率最高，其次是（1）。

人力资源管理中的风险管理

在进行人力资源管理时，我们往往重视招聘、培训、考评、薪资等各个具体内容的操作，而忽视了其中的风险管理问题。其实，每个企业在人事管理中都可能遇到风险，如招聘失败、新政策引起员工不满、技术骨干突然离职等等，这些事件会影响公司的正常运转，甚至会对公司造成致命的打击。如何防范这些风险的发生，是我们应该研究的问题。特别是高新技术企业，由于对人的依赖更大，所以更需要重视人力资源管理中的风险管理

给项目管理一双慧眼

在诸多招聘广告中，经常可以看见一些IT软件企业或集成商对他们的技术部门经理或者项目经理是这样要求的：

有XX行业X年软件开发经验

精通XXX编程

语言掌握XXX数据库„„

这里面隐含着什么意义？那就是对于大多数IT企业，他们眼中的技术部门经理或项目经理都是技术高手，部门员工碰到什么搞不定的技术难题，这些经理一出手，一切搞定，赢来阵阵喝彩。这应该是这些经理们的第一职责吗？显然，有不少人都会说“No”。他们明白，对于这些经理们来说，管理好项目是更重要的职责。

正因为这样，项目管理资质认证成为继MBA之后的一大热点，许多媒体纷纷刊登有关项目管理资质认证的各种利好信息，大有项目管理资质认证是解决一切项目问题之灵丹妙药。其实，专业的项目管理是保障项目成功实施的关键因素之一，但并不是唯一因素，就象股份制只是使企业的所有制趋于合理化，但股份制并不能保证企业的经营一定能获得良好的经济效益。

虽然国内众多IT企业都开始重视项目管理，也积极的让员工们参加各种项目管理的培训，但是在实际的项目执行中，往往还是会出现许多不尽如人意的情况，或者可以说，在注意项目管理后，许多项目的执行效率并没有得到实质性的提高。或许，我们需要一双慧眼来仔细看看项目管理领域里存在的诸多关键点。

一、项目管理的理论、方法和工具

首先需要认清的是项目管理的理论、方法和工具的区别以及相互关系。

有不少人接受了一些关于项目管理培训，或者阅读了一些关于项目管理的书籍，他们基本上就知道项目管理需要制定计划，需要进行跟踪和监控，也了解项目管理包含哪些内容，比如说质量管理、变化管理、风险管理、合同管理等等。但是，当他们真正在一个项目中去进行项目管理，却仍然会感到无从下手，无法通过执行项目管理的活动让项目沿着正确的方向前进。

之所以出现这样的情况，是因为他们所掌握的往往还只是项目管理的理论，但却还没有掌握项目管理的方法。而理论的可操作性往往很弱，因此出现这样的情况也是非常正常的。用一句话说，掌握理论只是知道了“What”，但还不知道“How”。

而方法会告诉你应该如何去做，它解决了“How”的问题，比如说，项目管理分成几个阶段？每个阶段又包含哪些活动？这些活动的执行顺序是什么？这些活动之间的关系是什么？这些活动产生哪些计划？诸如此类等等。这样就具有很强的可操作性。但遗憾的是许多培训或者书本，都还是保持在理论的层次。

在日常工作中，经常会听到这样一句话“计划不如变化快”。甚至有人会拿这句话做为挡箭牌，拒绝进行积极的项目管理。实际上，没有一个项目可以在执行中完全遵守一开始制定的计划，尤其是在计划制定得非常详细的情况下。项目的执行过程中肯定会随时发生各种变化的，因此在进行项目管理时，是一定要对项目进行监督和控制的，并设定一些节点根据项目的进展对项目计划进行必要的调整；另外，在制定项目计划时，还应该注意根据项目的规模和时间，从粗到细制定详细程度不同的计划，以保证计划的指导作用和有效性。象这样的情况，都是要有方法才可以解决的。出现问题，并不是“进行项目管理”的理念不对，而是没有找到合适的方法。

在日常工作中，还常听到有人说：“以后我们要加强项目管理，使用××软件进行项目管理。”他们不但用软件做出了计划，也产生了甘特图和关键路径图等等，但是实际的工作往往和他们所做出的计划有很大差异，项目管理成效依然甚微。在这种情况下，他们所犯的错误通常是以为有了工具，就可以解决一切问题，而其实他们并没有项目管理方法。实际上，工具是基于方法的，需要和方法相结合。使用工具是为了更好的贯彻方法，如果没有相适应的方法，使用工具甚至会产生负面的效果。

因此，在具体项目实施中，一定要有清楚的项目管理方法，才可能用好工具；同时也必须注意到所选择的工具和采用的项目管理方法是相匹配的，因为并不是所有的项目管理软件都会适用于所有的项目，应该基于项目管理的特定需要选择某个项目管理软件，就象ERP系统实际上体现着某种企业管理的理念，每个企业在选择ERP时都需要密切关注隐藏在它背后的企业管理方法，而不只是它需要的技术支撑平台是什么？它的实施需要几个人月？

二、项目管理方法和项目实施方法

其次，也必须看到，在一个项目的执行过程中还同时需要两种方法：项目管理方法和项目实施方法。

项目管理方法是关于如何进行项目管理的方法，是可在大部分项目中应用的方法。而项目实施方法指的是在项目实施中为完成确定的目标如某个应用软件的开发而采用的技术方法。项目实施方法所能适用的项目范围会更窄些，通常只能适用于某一类具有共同属性的项目。而在有的企业里，常常把项目管理方法和项目实施方法结合在一起，因为他们做的项目基本是属于同一种类型的。

实际上，只要愿意，做任何一件事情，我们都可以找到相应的方法，项目实施也是一样。以IT行业的各种项目为例，常见的IT项目按照其属性可以分成系统集成、应用软件开发和应用软件客户化等，当然，也可以把系统集成和应用软件开发再分解成一些具备不同特性的项目。系统集成和应用软件开发的方法很显然是不一样的，比如说：系统集成的生命周期可能会分解为了解需求、确定系统组成、签订合同、购买设备、准备环境、安装设备、调试设备、验收等阶段；而应用软件的开发可能会因为采用的方法不同而分解成不同的阶段，比如说采用传统开发方法、原型法和增量法就有所区别，传统的应用软件开发的生命周期可能分解成：了解需求、分析需求、设计、编码、测试、发布等阶段。

至于项目管理，可以分成三个阶段：起始阶段，执行阶段和结束阶段。其中，起始阶段是为整个项目准备资源和制定各种计划，执行阶段是监督和指导项目的实施、完善各种计划并最终完成项目的目标，而结束阶段是对项目进行总结及各种善后工作。

那么，项目管理方法和项目实施方法的关系是什么呢？简单的说，项目管理方法是为项目实施方法得到有效执行提供保障的。如果站在生命周期的角度看，项目实施的生命周期则是在项目管理的起始阶段和执行阶段，至于项目实施生命周期中的阶段分布是如何对应项目管理的这两个阶段，则视不同项目实施方法而不同。下图是一个简单说明。

项目管理方法和项目实施方法对项目的成功都是有重要意义的，两者是相辅相成的，就如管理人员和业务技术人员对于企业经营的意义一样。

从IT企业的角度看，任何一个IT企业如果要生产高质量的软件产品或者提供高质量的服务，都应该对自身的项目业务流程进行必要的分析和总结，并逐步归纳出自己的项目管理方法及项目实施方法，其中项目实施方法尤其重要，因为大部分企业都有自己的核心业务范围，其项目实施方法会比较单一，在这种情况下，项目管理方法可能会弱化，而项目实施方法会得到强化，两者会较紧密的结合在一起。只有总结出并贯彻实施符合企业自身业务的方法，项目的成功才不会严重依赖于某个人。在某种程度上，项目管理方法和项目实施方法也是企业文化的一部分。

从客户的角度看，如果希望得到有保障的产品或服务，那就既需要关注提供产品或服务的企业是否有恰当的项目管理方法和项目实施方法，也必须尊重该企业的方法。

三、项目管理和项目的目标

有了合适的方法，还要清楚项目的目标，才能有针对性的进行项目管理。项目的目标是指项目做完后能够支持客户如何运作业务，或者客户可以获得具备哪些功能的产品等。

在项目的实际执行过程中，客户方和项目执行方往往很容易产生争执，出现“先君子，后小人”的情况：开始时大家都是一团和气，或项目执行方为了获得项目合同，先是猛拍胸脯保证没问题，只要是客户方的要求就承诺一定实现。但随着项目的进展，才发现双方的期望有着不小的难以弥补的差距。

这种现象的原因就是项目双方并没有定义清晰的、可实现的项目目标，换句话说，双方并没有真正在项目目标上达成彼此认可的一致。这样就很可能出现不了双赢的局面，要么是最后产生的结果不是客户需要的，要么是客户不断的修改需求，导致项目的进度和质量受影响。项目目标既是客户期望的体现，也是项目执行方期望的体现，因此它们应该是清晰的和可实现的。

从另一方面讲，项目目标的实现是要受到一定制约的，那就是它应该在确定时间和财务预算内实现。有一些目标并不是不能实现，而是实现的代价太高，或者不能满足进度的要求。这也是在项目实施中需要注意的。

同时，清楚的目标也是界定项目是否成功的客观标准，是对项目进行验收和质量管理的重要依据。设定清楚的项目目标，在某种程度上也会让执行项目的IT人员更清楚要做什么，因为在一些项目中，往往会出现片面追求技术的先进和完美，而忽视项目的结果是为谁服务的。因此，为了保证项目双方能够在项目执行过程中愉快有效合作，保证项目的成功执行，双方都应该注意尽快在项目实施初期定义清楚的目标。

四、项目管理与体系结构

“体系结构”这个词语来自英文单词“Architecture”，在计算机行业中也有译为“系统结构”，许多行业都用到这个单词。对于一台计算机而言，它所关注的是如何合理的利用合适的软件、硬件和固件来构造计算机，使之能够以最好的性能价格比完成用户所需要的任务。之所以特别提出“体系结构”，主要有三方面的原因：一个是IT应用范围的扩大；一个是IT系统的复杂性和产品多样性；一个是软件技术的发展。

随着IT技术的发展，以及人们对IT技术的理解和掌握，IT在各行业的应用都日渐的发展和成熟，越来越多的行业和人员都在利用IT技术提高他们的业务运作效率，也就产生越来越多的应用型项目。尤其是IT 应用发展到现在，一个IT系统所覆盖的范围日益扩大（范围包括最终用户数量、部门数量、地理分布等），比较常见的大型IT项目是一些新用户希望在一个高起点上构建一个覆盖多个业务部门的完整的新IT系统，或者一些用户希望在原有分散的IT系统基础上进行整合，从而构建成一个完整的IT系统。

对于这样的大型项目，它们所覆盖的业务部门很多，彼此的业务功能差异比较大但又存在相当的联系，也就是说应用软件的功能会比较多，且相互之间存在着一定关联；而与之相适应的是应用软件技术也发生了变化，多层结构、对象技术和组件技术等得到日益广泛的应用，这就意味着必须对应用软件的体系结构进行全面的分析设计如层次如何划分、组件如何划分等，才有可能产生一个较完善的应用软件系统以满足最终用户的复杂需求。

同时从IT系统的基础设施来看，其使用的产品也是多种多样的，从服务器级的系统平台、网络平台到客户端等，有功能的差异，也有性能的差异，甚至还有采用异构技术实现的。如何让这些产品构成一个和谐完整的系统为客户提供方便、快捷的服务，就需要站在整个IT系统的高度上进行完整的分析设计，定义整个IT系统的组成内容，每个组成部分的功能和性能，相互之间如何进行数据交换。

如果没有清楚的体系结构观念，在项目实施中往往会出现这样的情况：客户今天说需要这样的功能，项目人员就按照客户的要求实现了；客户明天再提出新的功能，项目人员也实现了。这看起来很简单，“简单就是美”——客户也会感到很满意，可是随着项目的进展，情况就不那么美了，客户开始发现“这两个部分怎么不能连接”，进而提出要修改想法，甚至要求重新来过。整个项目实施就可能会出现“边施工，边设计”的情况，在这种情况下，项目的进度和开销就很难有效控制，项目的资源可能被极大的浪费，而质量能否得到保证则存在很大的风险。

在体系结构清楚的基础上，项目管理人员就可以根据一定的优先次序关系组织资源去建设IT系统的各个组成部分，从而保证项目的顺利实施，而不致于出现“停工待料”甚至是“推倒重来”的局面。因此，在一个合理的项目组织机构中，必须保证项目经理和体系结构设计师的有效配合。

五、ISO9000、CMM与项目管理

从90年代中后期开始，众多的IT企业象其它传统企业一样，开始关注国际标准组织颁布的ISO9000标准系列，并有不少企业通过了ISO9000认证。2000年后，国内大部分从事软件开发的IT企业开始和国际接轨，重视CMM认证，并有许多企业走上CMM认证之路。这是非常好的一个现象，说明我们的观念和意识在提高，在一定程度上意味着未来更加光明。但是也出现有的企业为认证而认证，而对于它们的客户来讲，所得到的产品或者服务并没有因为这些企业通过某项认证而得到更好的质量保证。

为什么会这样呢？其中很重要的一点是大家并没有完全认识清楚ISO9000、CMM和项目管理、项目实施的相互关系，或者是不愿意承认这种关系。ISO9000针对质量保证和管理，而项目管理要考核的指标包括了时间（或进度）、成本、资源和质量，它不仅有质量管理，还包含了变化管理、风险管理、合同管理等，当然这些专项管理内容和质量管理是相辅相成的，或者说这些专项管理都是在为质量服务的（有时质量的范畴会被尽可能的扩大）。项目管理必然包含质量管理，而ISO9000标准并无法完全代替项目管理。

ISO9000是面向绝大多数企业的质量标准体系，是具有通用性的质量保证和管理标准，也因此它对某些行业可能缺乏针对性。虽然它也提出和软件开发有关的指南，但从总的来看制造业最容易按照ISO9000标准实施。对于制造业和IT企业（软件、集成），它们都需要质量体系，但是它们的质量指标并不完全相同，甚至可以说绝大部分是不同的。当然，如果在未来的某一天软件和系统集成的技术方法真的发展到很完善就象工厂中的流水线一样，那么ISO9000类似的质量标准对软件和系统集成的衡量就很有意义了。

IT企业通过ISO9000认证，这个体系一定要和项目实施方法密切结合。从ISO9000的发展历程我们或许可以看出，质量管理方法的完善在时间上是落后于项目实施方法（对于制造业，应该是产品的研发和生产方法）的完善的，因为要进行质量管理，必须清楚要管理的质量指标项和相应的衡量标准，而这些都必须在积累一定的开发生产经验后才能提出和完善。因此对于IT企业来讲，要有很好的质量保证，必须有相对清楚合理的项目实施方法，才有可 能把ISO9000标准真正贯彻到项目中，没有项目实施方法，全面贯彻ISO9000标准是不切实际的。当然，这并不是说在没有清楚合理的项目实施方法之前不能接触ISO9000标准，不能应用ISO9000标准。如果在起步阶段就开始接触ISO9000标准，应该说会更有可能以全面的眼光去看待项目的实施以及项目管理和落实项目质量保证，也更有可能逐步去完善项目管理方法和贯彻ISO9000标准。

至于CMM，则是侧重于对企业的软件过程和软件能力的评估评价，它提供的是一个软件过程改进的框架，这个框架与软件开发的生命周期无关，更与项目管理的生命周期无关，因此它并不是企业可以直接采纳的软件开发方法和项目管理方法。CMM做为一个指南能够帮助软件企业选择、采纳和合理使用一些先进的软件项目管理方法和软件开发方法，并在实践活动中不断提高和完善，从而极大程度地提高企业按计划的时间和成本提交有质量保证的软件产品的能力。如果一个企业真正达到CMM第四级，那么它的软件开发方法和软件项目管理方法应该是相当成熟的。

因此，CMM只是为客户选择软件开发商提供一个参考标准，它并不等同于软件产品的质量，也不能代表企业对所有项目的管理能力。或许有一天，会推出项目的能力成熟度模型来评估评价企业的项目管理过程和项目能力，那样提高项目管理能力可能就更容易了。

六、结合实情逐步落实

完整的项目管理还包括一系列专题管理，如：质量管理、变化管理、风险管理、财务（或成本）管理等。这些专题管理并不完全停留在项目范畴内，它们的实施要依赖企业内部诸多相关部门的配合，如果一开始就准备在项目实施中进行全面的项目管理（包括诸多专题管理），会存在相当大的难度，因为很多企业的内部运作还不足以支撑这样的全面项目管理，而且大部分人员也不可能在一开始就能全部领会这么多的内容。“罗马，不是一天建成的。”

在推广项目管理的过程中，经常会出现这样的情况，有的人会委婉的提出意见：“你提出的这种项目管理观念非常好，我也觉得应该这样去做，可是我又感觉好像太理想化了”，或者“太理论化了”等等。也就是说，对于他们，思想上接受了，但行动上却很难真正执行，思想和行动总是存在一定的距离。

项目管理对于很多人来说是一个新事物，观念上接受它就需要时间，更何况是在行动上完全采纳。应该承认的是，引进项目管理，无论是对于企业，还是员工，都是一种变化。但是，这种变化对个体来说是必须的，而对整个行业来说则是必然的。

要让项目管理真正进入实际业务运作中，应该结合实情逐步落实项目管理理论中的各项内容。比较合适的步骤是：第一阶段，先进行一般意义上的项目管理，做到可以清楚的定义项目的目标、范围及工作成果等，在这个阶段应该确保对项目管理方法和项目实施方法及体系结构有清楚的认识和理解，并掌握适当的项目管理工具；第二阶段，全面实施质量管理；第三阶段，全面实施变化管理、风险管理以及财务管理。

接下来，制定一个计划，把“实施和推广项目管理方法”做为一个项目去执行和管理，一步一步去做，就会获得成功的。开始吧！

工程项目管理的新挑战—可持续发展

摘 要:工程建设会引起一系列的环境问题,本文从可持续发展的角度,详细分析了可持续发展项目管理的必要性,同时对项目中的各个参与方在项目中所负的责任加以阐述,并且对可持续发展的项目管理从资源管理、环境管理、技术管理和项目参与人员的管理等方面提出了相应的措施。

关键词:可持续发展;工程项目管理

引言

从20世纪80年代的“鲁布格经验”到今天,项目管理对建筑业的发展起到了无法替代的作用。但是由于建筑业一方面为人类建筑美好的居住空间,同时又对环境产生一定的破坏。例如:由于建筑工业大量使用合成的化工材料,使得一些含有二氧化硫、二氧化氮、卤化物的材料暴露在大气中或与在自然的氧化作用下,释放出相应的气态化合物;在施工过程中产生的噪音污染;由于机械化施工而产生的机械废气;施工过程中产生的大量的固态建筑垃圾等。

因此,在人们日益重视环境问题的今天,可持续发展越来越成为人们关注的热点,然而可持续发展关注的热点主要集中于土地、自然资源等不可再生资源的可持续利用上,集中于经济发展的可持续研究上,忽视了对人们行为的主要对象—项目进行可持续性研究,造成了许多项目仅仅是某些领导政绩的标志,由此造成了资源的巨大浪费和环境的严重破坏。如何从可持续发展的角度来推广和发展项目管理的组织方法和实施方法,是当今项目管理领域的一个很有意义的话题。1 可持续发展的工程项目管理的特点及含义

1.1 管理对象的泛化传统意义中的工程项目管理的管理对象是工程项目本身,是通过可行性研究报告、项目计划书、设计图纸、设计规范、实物模型等定义和说明的。而可持续发展的项目管理的对象不但包括项目本身,还包括项目所处的微观环境和中观环境,就是说作为可持续发展的管理者在进行管理的时候,要将与工程项目所有的外部关联元素全部纳入考虑和管理范围。

1.2 管理目标的泛化作为一般意义上的项目管理目标,是要实现项目的质量目标、经济目标、进度目标。可持续发展的项目管理的目标则远远超出了这三个目标,它还要实现整个微观区域和中观区域的环境质量目标、经济效益的长期最大化,实现人与自然、人与社会的和谐统一。

1.3 管理组织的泛化可持续发展的项目管理需要参与方的全体紧密合作,任意一个环节的失误都会造成整个管理的失败。

1.4 管理方法的多样性随着电子技术的发展以及Ｉｎｔｅｒｎｅｔ的使用,现代的管理更加倾向于开放性、及时性、准确性,可持续发展的项目管理作为一种工程管理方式同样如此,尤其是ＥＲＰ、ＣＲＭ等系统的应用。因此,可持续发展的项目管理实际上是将工程项目放在一个微观或中观的区域内,应用现代的生产技术,实现项目的成本、质量、进度和社会、经济的系统目标,从而解决项目的环境与发展问题,实现项目和社会的可持续发展。影响可持续发展的项目管理的因素项目生命周期的各个阶段犹如串联起来的一组电路,任何一个环节出现问题就会破坏项目管理的可持续发展。

影响可持续发展项目管理的关键因素有许多,涉及项目的各个方面。对项目可持续性的影响因素包括:项目的经济效益、项目的资源利用情况、项目的可改造性、项目的环境状况、项目的科技进步情况、项目的可维护性等几方面。当然,项目的可持续性发展还要受到管理、组织的影响,另外项目所在国的政策、政治状况等都会对项目的可持续性产生影响,其影响不仅涉及项目的可持续性甚至关系到项目的生死存亡。可持续发展的工程项目管理中各方面的责任和义务

在任何一个项目中,项目的参加者包括:政府部门、业主、勘察与设计单位、监理单位、承包商、材料供应商、用户等。因此每一个参与者的行为都将对整个项目的可持续发展有着极大的影响。

3.1 政府部门作为项目的审批者和监督者,社会公共利益的代表者,如果政府部门在项目的立项审批、规划审批、设计审批等方面提高对项目的可持续发展的要求,同时积极开展“社会评价”,使得项目的发展有利于自然资源合理利用与生态环境保护,有利于我国的经济建设,合理利用有限的自然资源,节约有限资源,保护自然与生态环境,造福人类,实现以人为本的可持续发展。同时,政府可以对采用了可持续发展的项目管理的业主给予税收或融资方面的优惠措施,鼓励业主采用可持续发展的项目管理方式。2004年4月中央查处了“江苏铁本钢铁公司违规建设钢铁项目”事件。虽然有部分人认为“铁本项目”的下马给国家带来了很大的经济损失,但是如果把这个事件放在我们整个国家的大的经济环境下考虑,我们可以清楚的发现,“铁本项目”的死亡正是政府在考虑了整个社会成本的前提下采取的最优的管理方式,可以说更大程度上是为了保证可持续发展。同年4月29日江苏省委书记李源潮、省长梁保华在向全省领导干部通报查处铁本项目违规建设情况时指出,铁本集团违规建设一案性质严重,教训深刻。江苏省委、省政府从铁本事件中总结的三条经验教训的第一条就是坚持以人为本,全面、协调、可持续的发展观。

3.2 业主业主是项目的投资人,一般情况下在保证质量和功能的前提下,自然会考虑项目的经济可行性,但是如果采用可持续发展的项目管理方式,则意味着业主要将该项目放置在一个更高的层次,即社会和自然的角度来进行项目的可行性研究、项目的设计、筛选项目的承包商、采用新的环保材料、建造技术和环保技术,因此也需要业主预支费用,加大了成本,但是由于采用可持续发展的项目管理方式使得整个社会的收益提高,因此,业主完全有可能从政府获得相关的优惠政策,从而补偿自己的损失。在2008年的北京奥运会的场馆建设中,北京奥林匹克运动会组织委员会在项目的招标书中明确规定了投标者的环境保护责任。在项目的标书中,把执行环境影响评价制度、防治污染的工程设施与主体工程同时设计、同时施工、同时建成投入使用的制度,和投标者应承担的经济责任写入了标书,要求投标人认真贯彻执行。同时制定了《奥运工程绿色施工指南》,对工程施工提出了环境要求。要求在施工过程中,严格执行环境管理措施,防止扬尘、废水、施工垃圾、施工噪声对周围环境造成的污染。

3.3 勘察与设计单位勘察与设计单位虽然在作为业主的被委托方,必须考虑委托方的经济利益,但是在某种程度上勘察与设计单位可以利用自己的专业知识,向委托方提供有利于可持续发展的项目管理方式的设计方案、新的环保材料、建造技术和环保技术。

3.4 监理单位监理单位的主要作用在于协调业主和各个项目参与者的关系,保证项目的质量、进度等公共利益。监理的成功与否,对项目的成功与否有很大的影响。监理单位在保证业主利益的同时,如果站在可持续发展的高度开展工作,实际是在行使其社会职责,因此政府应该从开发企业上缴的税收中,拿出一部分用于对监理单位的报酬。

3.5 施工单位施工单位是完成项目的核心,项目在施工的过程中要使用的机械设备,会产生大量的废气、粉尘、振动、噪音,对环境产生极大的破坏,影响项目的可持续发展。如果项目中标的施工单位在业主、监理单位和政府法 规的约束下,采用可持续发展的项目管理方式,采用绿色环保施工建造技术,将进一步完善现有的施工方法,提高企业自身的核心竞争力。北京城建集团有限责任公司是一个以建筑为主、多元化经营的综合性上市公司,具有工程总承包的一级资质,是全球最大的国际承包商之一。该公司之所以能够在如林的强手中中得奥运会的主场馆项目,应该说同该公司在施工中坚持采用绿色环保施工建造技术有极大关系。

3.6 材料供应方工程项目的施工建造需要大量的材料,而这些材料的使用者由于缺乏相应的专业知识和不对称的信息,难以对材料做出非常准确的评价,而材料的供应方却相反,他们拥有专业的技术设备、强大的信息库,可以为业主、设计方、施工方提供绿色环保、符合可持续发展要求的新型材料。作为整个可持续发展项目管理链上的一个组成,材料供应方应该从法律上保证所提供材料符合可持续发展要求,政府需在税收上给予优惠。

3.7 项目的使用者工程项目建成以后,作为项目的使用者则更大程度体现了项目的可持续发展性。因为项目使用者在使用的过程中,要消耗大量的自然资源(水、光等),同时会产生一系列的废弃物。因此如何在使用的过程中,少消耗资源,少产生废弃物或废弃物再次利用程度,则是该项目可持续发展能力的一个很重要的指标。可持续发展的工程项目的实施管理

4.1 资源管理项目资源管理主要指项目运营所需原材料和项目废弃物的处理和再利用的管理,以及项目报废后资源的再利用情况。原材料的可再生性和对环境的影响直接关系到项目的可持续性。由于项目的废弃物处理和利用关系到项目对环境的影响,关系到项目的存在与可持续发展能力,所以项目的可持续必须考虑项目的废弃物利用和处理状况,并对其作出评价,通过它进一步评价项目是否具有持续发展能力。只有这样,才能全面保证项目的可持续发展。

4.2 环境管理对环境的管理包括自然环境、社会环境、生态环境等几方面管理。

4.2.1对自然环境的管理对自然环境管理是指可持续发展的项目管理要能够防止或减少项目造成的环境污染,如光污染、噪声污染、废气、污水污染等,达到项目与周围自然环境具有相容性、协调性。管理的措施包括:在项目的可行性研究阶段就要确定可持续发展的主题;在项目的设计、施工阶段,要采用绿色环保的施工技术和材料;在项目的使用阶段,要对产生的废弃物采用分类、无害处理。只有当项目达到污染治理的标准,并且与周围自然环境相协调,项目才具有持续发展的可能。

4.2.2对社会环境影响的管理对社会环境的影响管理包括对周围居民生活的影响管理、对社会文化的影响管理、对社会经济环境的影响管理等。管理的措施包括:保证项目与社会文化相容;与人们的生活习惯相协调;与经济发展相吻合,并具有一定的前瞻性。一个项目只有符合社会文化要求,不影响居民生活,与经济发展协调,才有存在的可能和继续发展的必要。以举世闻名的三峡工程为例。有材料表明,该工程建成后,将保护长江中下游广大平原湖区,使国土开发长治久安;能够充分利用原有农业基础设施,加强农田水利基本建设,大大提高长江流域粮棉生产水平,促进农业生产的发展;可利用水库1084ｋｍ2水域面积和上百条大小支流库汊,发展渔业、养殖业、林业及畜牧业等,为食品加工和轻工业提供原料基地;万吨级船队可大半年直通重庆,宜昌以上航道将大大改善,促进长江流域和西南地区的开发和对外交流,使长江成为名符其实的“黄金水道”。

4.2.3对生态环境影响的管理项目处在一定的环境中,都或多或少地对生态环境产生影响,对生态环境影响的管理需要各个参与方的共同努力,尤其是政府部门应该通过相应的法律、法规明确规定对生态环境的保护,同时对破坏者给予严厉的处罚,对于主动进行保护的给予奖励。同时要培养全社会的环保意识,使环保的观念深入人心,形成全社会爱护环境、保护环境的风气。

4.3 技术管理技术管理主要考虑两个方面:项目设计的先进性和技术本身的先进性。项目的设计要具有科学性、超前性,并有发展余地。设计时除了要考虑人们现在生活需要,还要考虑未来需要,使项目具有一定的前瞻性,能与以后的经济、技术、文化发展相衔接。设计的先进性还表现在尽可能利用已有的新技术、新材料、新工艺,并具有一定的超前性,为以后发展留出接口。技术本身的先进性主要指项目实施技术和运营技术的先进性。项目的技术先进性表现在已09资源环境与工程有先进技术成果的应用上,表现在为以后技术发展留出的接口上,项目的技术先进性使项目能经得起时间考验,同时具有可持续发展前景。

4.4 项目参与人员的管理作为整个项目建设的核心主体,项目参与人员在实施建设过程中的每一个动作都会对项目本身产生直接的作用,直接对项目的可持续发展产生影响。项目可持续发展的资源管理、环境管理和技术管理都直接依赖于项目参与人员的实施。因此,行业主管部门很有必要在项目参与人员上岗之前对其进行相关的政策法规培训,对其进行技术指导,提高素质,并在项目的实施过程中不定期的进行检查,使可持续发展观深深植根于项目参与人员的头脑中。结束语

可持续发展战略的核心是经济发展与保护资源、保护生态环境的协调一致,让人类子孙后代能够享有充分的资源和良好的自然环境。工程项目的可持续发展管理虽然只是可持续发展的一个非常细小的分支,但是如果我们能够“勿以善小而不为”的态度去认真的从事工程项目的管理工作,可持续发展在不远的将来一定会成功。

管理的三化与六法

企业管理的“三化”与“六法”，是现代企业管理理论与中国企业管理的实践相结合的经验总结，是现代管理理论的中国本土化。

“三化”

（一）决策层级民主化

决策层级民主化是指企业在进行各层级的决策时，要充分占有信息，要使用有效的手段科学地处理信息。广义的民主化还应包括利用外脑。具体地说董事会会议，对公司重大事务进行决策。在民营企业中，董事局主席一般是企业的主要业主，由民主决策进而正确决策，实际上是业主个人财务安全和增值以及企业发展的保障。所以，对重大事务的决策民主化表现为在董事局会议上按持有股份的多少行使投票表决权。重大的决策比如公司的兼并、合并、注销等必须有 2/3 以上（指持有股份的总额达到公司股份总额的 2/3，而不是投票人数的 2/3）的股东同意。其他的决策要由 1/2 以上的股东同意才可形成；子（分）公司层级的决策主要是经营决策，重大事务由子公司董事会决策，日常事务由子公司经理办公会决策；职能部门事务决策，由部门经理办公会进行。

（二）管理层级制度化

随着技术的进步、科学的发展，管理的方式、手段不断改进和提高。现代化的管理手段开始在企业使用，对员工提出了更高的要求，管理层级的制度化势在必行，即企业职工的行为的准则，它规定着人们在共同区作中应当执行的工作内容、工作程序和工作方法。也是企业生产经营活动和一切管理工作所应遵循的法规。现代企业的生产经营过程极其复杂，分工协作极为严密，没有严格的规章制度，企业的生存在就没有保障。所以管理层级必须按照规章制度办事，逐项落实。一视同仁地坚持有章可依，有章必依，执章必严，违章必究，即“依葫芦画瓢”。只有按章办事，才能保证政令畅通。

（三）操作层级选择化

操作层级选择化指把企业管理的每一项工作都细化和量化，每一个岗位都有明确的岗位职责和工作流程，形成企业的各项目作分工合理、科学、明确，从而达到企业管理科学化，人人有事干，事事有人管，没有重叠，没有空白。任何一个员工，即使没有某一岗位所需要的专业知识，只要他翻开职位说明书，就可以利用手机拨打电话一样。为此，员工要先逐字逐名学懂弄通公司的操作程序，再在工作实践中切实的执行。每一个具体的人在每一个具体的岗位上，按最有效的程序去完成相应的工作，成为一颗螺丝钉。反对和禁止形式主义、花架子，自以为是，另搞一套。

“六法”

（一）折箭法

“折箭”讲的是古代的一位老人教育他的儿子们团结起来力量大的故事。一个人折一捆箭是折不断的，可是把箭拆散，一根一根地折就很容易折断。在日常的企业管理中，事务性的工作很多，其中只有 20% 是重要的，而这 20% 的事务要花费 80% 的精力去处理，这也是所谓的犹太人“黄金法则”。对所有的问题，先解决普遍问题，再解决特殊问题；先解决今天存在的问题，再解决历史上遗留的问题，而且要一个一个地解决。每一个职能部门，每一个员工，每天解决一件，整个公司就解决了很多事情。解决问题最好的方法就是现场办公，现场办公是事事落实的最好形式。

（二）试点法

一项新的决策，为了降低风险应该在小范围内试点。先试点再总结，先创新再推广。

（三）源头法

凡事要抓住重点、抓住源头、提纲挈领。即做任何事情的方法是：要抓主要矛盾，把问题简明地提出来，不要胡子眉毛一把抓。面对纷繁复杂的工作，要理顺思路，突出重点，抓大放小，层层剥皮。大与小的关系是西瓜和芝麻的关系，抓大放小就是抓住西瓜。企业发展的源头是市场，基层是其效益的来源地，也是培养和锻炼管理干部的源头，一切工作重心应围绕基层市场，以有利于基层市场的深入发展和扩张。

（四）重心下移法

管理重心下移，实际上就是企业组织结构和管理体制的创新，形成管理层级少而精的扁平式组织结构和科研、市场营销两头大，中间管理层级小的哑铃式管理结构。公司的领导，特别是高级小的哑铃式管理结构。公司的领导，特别是高层的领导者应经常深入基层和市场一线，调节器查研究，解剖麻雀，现场发现问题，解决问题。管理重心下移还表现在公司的干部要直接参与管理部门或本公司的某一具体工作管理直通车，即最高决策层可以和最基层直接沟通。这是因为基层是和企业的上帝——消费者直接接角的地方；是员工成长的舞台，发展的条件，也是员工积累经验的源头，所以企业的领导者要重视基层，特别是深入基层，解决实际问题。要把深入基层当作一项经常性的

工作，同时也要根据不同的时间段落实下基层的高层领导人员。每一高层领导应具体负责某一领域的工作，既有利于管理，又有利于办事效率的提高。

（五）组织放大法

作为公司的领导，要抓住关键总是不要事必躬亲，所有的工作要通过组织来作。企业的组织是配置资源和发挥能力的结构形式，是企业整体能力的整合机制现代企业的整体能力依存于三种组织联系形式：正式组织主要是通过“职能角色”发挥资源的优势作用；非正式组织主要是通过“自然沟通”发掘深层的内在活力；外部协作组织主要是通过“利益共享”实现合作竞争力。涉及企业内部事务的，企业领导要善于利用正式组织途径解决问题；在适当垢机会和场合，通过恰当的方式，调动非正式组织成员的积极性和主动性；现代企业要生存，必然面临从多的竞争者；分工又使得企业不能离开其他的合作伙伴而存在，所以企业还必须会利用外部协作组织来发展自己。

（六）高位嫁接法

企业要根据其发展的阶段，实行“拿来主义”，站在巨人肩上，高位起步。技术要不断更新，管理要不断改进，营销手段落要随市场变化而变化。因为在信息时代，企业之间的分工将主要取决于企业之间的技术优势，而不是资源优势和资金优势。技术开发引导着市场需求，技术变迁决定着企业产供销流程体系和企业产业的发展方向，技术创新成为企业界赢得市场份额的根本途径。企业的发展离不开企业在技术上的优势，企业技术优势的发挥离不开企业在管理上的创新。管理创新是企业根据产供销技术的变迁和市场的变化，调整企业组织、企业经营管理观念和管理方的过程。管理创新能够打破陈规陋习，提高企业的运转效率，能够激发员工的技术创新意识并增强企业的活力

管理项目失败的教训

事后诸葛亮——管理项目失败的教训

能力的提高往往不是从成功的经验中来，而是从失败的教训中来。

在克莱斯勒汽车公司，一位项目经理把辞职信交给当时的CEO艾科卡·李，表示要对自己所领导项目的失败负责。艾科卡拒绝了，他知道这位项目经理还

会在汽车行业继续工作，于是说：“我不希望这100万美元的学费替别的汽车公司交，把教训记下来，这是我们的财富。”这只是艾科卡带领克莱斯勒走出困境的一个小插曲，却令人回味。

许多项目经理不注意经验教训积累，即使在项目运作中碰得头破血流，也只是抱怨运气、环境或者团队配合不好，很少系统地分析总结，或者不知道怎样总结，以至于同样的问题不断出现。

可有可无的项目终结

项目总监王深刚进公司不久就接到一项任务，要求他尽快把项目成本估算的准确度抓一下。由于市场竞争激烈，公司不得不在没有足够信息和数据的情况下，短时间内做出标书。这使过去几个项目的进度大大延误，成本失控，公司管理层对各项目经理的信任大打折扣。

王深查看了公司的项目文件档案，按ISO9000管理来看还是比较规范的。他找来正处于项目收尾阶段的项目经理李明，请他写一个项目总结。要求项目组所有成员都参与总结，一周之后拿出一份完整的总结文件。李明的项目比预定工期晚了1个月，成本比预算多出10万元，但与大部分项目相比，这算是做得不错的了。

颇使王深意外的是，两天后一份两页纸的项目总结摆在他的办公桌上，除了项目背景的介绍，就是一些原则性的套话，“加强合作、及时跟踪”等等，没有触及任何实质性问题。毫无疑问，公司的项目经理们觉得“总结”可有可无、无足轻重，但是许多宝贵的经验就是这样白白地丢掉了。也许，静下心来好好总结一下，我们可以学到很多东西。

会议主题：抱怨

不得已，王深亲自召集李明的项目组开总结会。赵雁发牢骚说：“总结会不是已经开过了吗？我手上又接了一个电厂项目，马上要做详细设计了，这会能不能不开？”王深没有回答，把李明写的报告递给赵雁，问道：“这些体会，你都清楚吗？”赵雁扫了一眼，虽然有些不太明白，但还是不以为然地说：“这是项目经理的事，我们组员无所谓。况且，大部分项目根本就不写总结报告。想写也没有时间！”

“这就是大家没长进的原因！” 王深不客气地说，“超支10万元是怎样造成的？是选择分包商安装监控设备但又无法控制领料造成的！本想赚取材料差价，却没考虑潜在的风险。”王深接着说：“我听说以前公司发生过类似的事情，不幸在我们的项目上又发生了。要是总结就这样草草了事，下次还会有！”

大家逐渐意识到总结的必要性，联想起以往工作，纷纷发表意见。话匣子一打开，总结会变成了一个控诉会。

在项目总结会上，这是常有的事。项目组把所受的委屈，尤其是来自客户方面的，统统发泄出来。但结论往往没有什么建设性，大都是“不要相信分包商的承诺、对客户的无礼要求应拒绝”等没有指导意义的结论。

王深鼓励大家畅所欲言，他说：“总结的意义在于判别结果和我们预想的是否一致，以便调整我们今后做计划的方法，为以后的项目工作打基础。大家最好比较一下项目计划和实际执行的差距。”

李明不好意思地说：“我们的计划只更新过一次，大家基本不太用。” 赵雁插话道：“这是因为计划与实际太离谱，连我们自己都不相信它。”

王深并没有责怪，他说：“对于新的项目，我们的报价、人员安排、进度控制大都基于假设，这很正常。现在我们可以回过头来，逐一检查当初的假设与现实情况的差距。下次同类项目，就可以大大提高计划的准确率，尤其是在成本估算和报价策略上，也就能提高中标率了。” 在王深的提醒下，大家的思路逐渐清晰，原来带有发泄意味的各种意见也变得有些系统化了。赵雁觉得大家的建议在新接的项目中就用得上。

王深特别强调了风险识别意识。他说：“这次在消防审批上的时间比预计的要长很多，影响了回款，这应该加在风险列表中。” 李明补充道：“应该尽早更换电缆供货商，我们一直希望他们能补上进度，所以迟迟没有启动备选供货商。虽然最后还是换了，但是耽误了两周的工期。”

一份非常不错的总结报告出来了，超过了10页，特别精彩的是对风险防范中启动应急计划的体会以及工程量的估算部分。

成长的烦恼

笔者曾在一家外企工作，看到其完备的计划书、风险分析、文档模板，由衷地感叹总结工作的艰辛。许多项目经理不是意识不到总结的重要性，而是疑虑所付出的劳动太多，是不是值得？

一位著名作家在参加亚洲作家笔会之后曾有这样的感想：我们代表团成员的论文动辄就是综述、概述和趋势分析，而少有像日本学者所做的编年史、作家生平考证之类的基础数据积累。这或许是在中国文化某些领域我们的研究水平反而比海外落后很多的原因吧。

项目管理水平的提高，离不开项目总结这项基础工作。这是任何教科书都无法替你做的。如果我们没有诸葛孔明的前瞻智慧，那么项目总结上的亡羊补牢或许也能起到勤以补拙的效果。

我们往往只有在自己碰得头破血流后才真切体会到别人的忠告是多么正确。在经历了无数的成长的烦恼之后，我们才能体会“不听老人言，吃亏在眼前”这句老话的味道。

对于管理项目，你还想重蹈覆辙吗？

论项目管理中的量化管理

项目管理理论是一门综合多门学科的新兴研究领域，包括项目综合管理、项目范围管理、项目时间管理、项目费用管理、项目质量管理、项目人力资源管理、项目沟通管理、项目风险管理和项目采购管理等九大知识领域。传统的项目管理论著都重点着眼于这九大知识领域来讲解项目管理，却忽视了一项基础性工作：量化管理。缺乏量化管理，项目管理只能处于一种“混沌”状态。以IT项目为例，据称只有26％的IT项目成功地实现了范围、时间和成本目标，剩余的74%都有不同程度的失败。而如果采用了量化管理，项目管理的全过程就会变得“可视化”，发现问题也可以“让数字说话”。

一．量化管理发展现状

当前，在项目管理过程中实行量化管理方兴未艾，较为典型的理论有六西格玛管理和CMM/CMMI 体系。

六西格玛是一项以数据为基础，追求几乎完美的质量管理方法。西格玛是一个希腊字母σ的中文译音，统计学用来表示标准偏差，即数据的分散程度。对连续可计量的质量特性：用“σ”度量质量特性总体上对目标值的偏离程度。几个西格玛是一种表示品质的统计尺度。它有别于其它的质量管理方法，是依据严格的数据采集和统计分析，找出误差的根源，并寻求消除这些误差的方法，根据顾客的要求来确定的管理活动。

实施六西格玛包括五个阶段：定义(D)，测量（M），分析（A），改进（I），控制（C），其数据流程如下图所示：

以上这些过程并不是单一的，独立的，而是相互关联的统一体（如图1）。由这些过程很容易看出，六西格玛是一种基于数据的决策方法，强调用数据说话，而不是凭直觉、经验办事。其基础是需求，作用及过程的量化，从

而可以客观地反映我们的现状，引起人们的关注。数据定义抽样数据收集统计分析试验设计控制数据定义测量分析改进控制。

CMM(Capability Maturity Model)是卡耐基梅隆大学软件工程研究院（SEI，Software Engineering Institute）受美国国防部委托制定的软件过程改良、评估模型，也称为SEI SW-CMM，（Software Engineering Institute SoftWare-Capability Maturity Model)。该模型于1991年发布，目前修改至1.1版，并发展成为系列标准模型。全世界已经有1万多家软件企业经过CMM评估。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化，标准化。使企业能够更好的实现商业目标。

CMMI(Capability Maturity Model integration)是为了解决现有不同CMM模型的重复性、复杂性，并减少由此引起的成本、改进过程，由美国国防部出资，委托美国卡耐基梅隆大学软件工程研究院（SEI）开发的能力成熟度模型集成，它将软件CMM2.0版草案C(SW-CMM)、EIA过渡标准731（系统工程CMM）及IPD-CMM集成为一体，同时，还与ISO15504相兼容。该模型广泛适用于政府机构、软件和硬件开发公司。

无论是CMM还是CMMI，都有个共同特点，就是关注量化管理，在CMM/CMMI模型中，企业过程能力等级越高，对量化管理的要求就逐步提高，当达到第4级“已管理级”（Managed级）时,要求针对组织过程的每一个阶段都进行了监控、取样和定量分析，形成了一个关于产品制作和维护流程的数据库并不断更新，以保证组织过程保持较高的质量。

他山之石，可以攻玉，可见，在项目管理中引入量化管理也是大势所趋。

二．项目管理中需要量化管理的领域

项目管理知识体系中，涉及到需要量化管理的领域非常多，从事前管理和事后管理的角度来分，可以分为估算和度量两大类。估算是以实际统计调查资料为基础，根据事物的联系及其发展规律，间接地估算和预计有关事物的数量关系和变化前景。而度量则是依据特定的标准，衡量当前的事物与标准之间的差异。项目管理范围中，有如下阶段需要应用估算技术：

1．项目范围估算

对项目预期的范围进行评估是项目的基础，范围估算失误将给项目带来不可挽回的损失。

2．项目成本估算

成本估算估计完成项目各活动所需每种资源成本的近似值，成本预算的过程是把估算的总成本分配到各个工作细目，建立基准成本以衡量项目执行情况。可见成本估算的准确性直接决定成本的预算情况。

3．项目进度估算

项目管理的关键要素之一就是时间管理，也即进度控制。准确地估算对制定项目计划、监督项目执行都有重要的意义。

4．项目风险估算

对风险识别不到，或对风险可能造成的影响估计不足都可能导致项目失败，因此对项目风险的量化估算更是至关重要。

定义项目、制定项目计划的时候需要进行项目估算，而项目执行过程中的跟踪监督过程则离不开度量。良好的项目管理主要针对项目要素进行跟踪度量，通过分析度量数字就可以及时发现项目进展中存在的问题，从而有针对性地制定解决方案。通常需要度量的项目要素包括

1．项目进度度量

对项目进度进行定期的跟踪度量，及时发现当前进度与计划的偏差，可以及时采取措施，及时赶工或调整进度计划。

2．缺陷度量

项目的成败直接取决于客户满意度，客户满意度是个难以量化的指标，而项目成果——产品的缺陷密度直接影响着客户的满意程度。度量产品的缺陷密度，可以有效地了解项目完成的质量。

3．项目工作量度量

工作量是衡量项目成本、人员工作情况的基础，准确地度量出项目真实的工作量，既可以掌握当前项目的情况，对于今后估算其它项目数据也有重要意义。

4．人员生产率度量

人力资源是项目中最为重要的资源，掌握人员的生产能力对于项目管理中人员管理、资源管理都有重要的参考价值。

三．量化管理的方法

量化管理涉及范围广、意义重大，应该如何进行量化管理呢？有很多科学的方法可以辅助项目管理人员进行估算和度量。

典型的估算方法有：

1.Delphi法

Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方。

Delphi法的步骤是：

1、协调人向各专家提供基本情况介绍和估计表格；

2、协调人召集小组会各专家讨论相关的因素；

3、各专家匿名填写迭代表格；

4、协调人整理出一个估计总结，以迭代表的形式返回专家；

5、协调人召集小组会，讨论较大的估计差异；

6、专家复查估计总结并在迭代表上提交另一个匿名估计；

7、重复4-6，直到达到一个最低和最高估计的一致。

2.类比法

类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到估计数据。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。

以某软件项目的规模估计为例，类比法的基本步骤是：

1、整理出项目功能列表和实现每个功能的代码行；

2、标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；

3、通过步骤1和2得出各个功能的估计值；

4、产生规模估计。

针对项目工期估计，常采用PERT(计划评审技术，Program Evaluation an Review Technique)技术进行估算。

针对项目成本估计，较好的方法有经验估算法、因素估算法和WBS基础上的全面详细估算法等多种方法。

度量不一定需要特定的方法，度量的关键在于数据采集与分析。度量的数据是根据管理的需要采集的，通过对采集到的数据统计分析，就可以掌握项目的情况。

四．量化管理实例

以某系统集成项目为例，可以看一下怎样在项目管理中应用量化管理。

项目名称：某大楼综合布线系统集成

项目启动，首先估算项目范围、进度、成本，以便制定项目计划。由于该项目属于典型的系统集成项目，采用“类比法”进行估算。估计该大楼项目范围约需为2000个点布线，时间约需1个月，成本约为300万。项目组根据估算结果编制项目计划。

项目实施过程中，针对缺陷数量采集数据进行度量，从而管理项目质量，获得采样数据如下图所示：

可见，缺陷数量始终控制在允许的上下限范围内，该项目质量获得了较好的控制。五．结束语

项目管理是个不断完善的知识领域，引入量化管理，强化量化管理，可以使项目管理知识体系发挥更大的作用。

浅谈如何实行有效的项目管理

目前随着公司的快速稳定发展和在系统工程业界的影响不断扩大，签定的项目呈现出以下特征：

1.系统规模大

2.工期紧张

3.需要各方面的配合多。这就对我们的项目经理提出了更高的要求。

如何实行有效的的项目管理，从我个人的理解，一个项目实施的过程中，最重要的是对目标的实现。对于项目目标的明确划分和界定就成为了如何能够达到项目目标的关键的第一部，同时对于项目实施的每一步都是围绕着项目目标进行的。其次是对进度的控制。对于实现项目目标的基础上，是否按时完成了项目的目标就成为了检验项目是否成功的标准，按时完成目标关键是对项目进度的合理控制和把握。再次是对成本的控制。成本的控制包括对资源的申请、合理调配和合理利用；对项目资源之外的各方面成本控制。

另外，在项目实施中最关键的一点保证就是客户，因此同客户保持良好的客户关系，时时体现为客户着想，让客户满意也是检验项目是否被客户认可的一个关键因素。下面就围绕着以上几方面进行简单的介绍。

1.目标管理。每一个项目的实施从与客户接触到合同谈判到具体实施都有一个明确的总的系统目标。而在项目实施中，将总的系统目标分解为几个阶段目标进行，每个阶段目标再分解为若干小的目标，最终分解为每个人在一定时间内能够看到并达到的目标而加以实现。同时每一步的目标分解和确定都经过和客户方的协调和确认，以保证总目标的实现得到客户的认可。对于每一步目标的变更以及同客户间任务的分配也经过同客户多次的会议讨论确

定。

2.时间控制。项目的时间控制是同目标管理密不可分的，每一步的进度控制都是基于一个特定的分解目标而确定的。目标的时间计划制定要求切合实际，并且在开始阶段要求严格实行按时完成，这样到后面可控化的程度就高多了。对于项目的时间计划也要求分解到每个人在一定时间内能够完成一定的目标。同时对于进度的控制要求随时检查时间计划是否按时完成以及同计划间的差异，随时采取措施调整相应计划以保证总体计划的可控性。

3.规范化的项目管理。项目按照规范化的项目管理方法进行管理能够很好的对项目进行控制。首先从项目的综合计划和质量计划，将项目的总体目标和分解目标以及时间计划都纪录下来，以保证项目的实施。其次对项目按周计划、周总结以及每个人按照周计划、周总结的管理方式进行管理控制，随时记录下文档，以保证项目进程的可控性。同时随时监控项目中可能出现的异常情况，比如硬件、软件问题；人员资源问题等等，出现问题及时予以解决并记录下来，及时予以调整项目控制保证项目进程的实施。

4.良好的客户关系。在一个项目中保持良好的客户关系可以说是本项目能否成败的基础，因为项目需要配合的方面很多，任何一方面的问题都可能导致项目的拖延。从项目一开始，根据我们的经验积极为客户着想，设计改进适合客户的系统，客户对我们的努力满意，也就为能同客户更好的合作奠定了基础。

5.人员协调。随着项目规模的扩大，项目组成员的数量也会越来越多，如何协调好每个人发挥每个人的充分作用就很大程度上决定了项目的成败。因此项目组从管理上严格每个人的任务职责分工。从生活上关心每一个员工，让每一个员工都成为朋友，帮助每一个员工前进，也使得项目组的情绪稳定，遇事不会影响到整个项目组，保证了项目组的活力。同时，要把项目组成员的定义范围广义化，即直接面对用户的项目组成员和间接面对用户的的项目组成员，如生产部门、采购部门、计划部门、财务部门、质量部门等等，充分发挥它们的协助、指导和监督作用，对高效率、高质量完成项目目标起到至关重要的作用。在这里，我也希望我们这些间接面对用户的部门能够从思想上认识到它们自身也是项目组的一分子，多从项目组的角度考虑问题，为用户提供出色的全面的服务。

从上面几个方面阐述了我对如何实行有效的项目管理的看法，其实方法还有许多，但我认为最最关键的是我们对待用户的看法和态度。应该这样理解我们的用户：他们不是我们工作的障碍，而是我们工作的目标；我们不是通过为他们服务而给他们恩惠，而是他们给我们为其服务的机会而给予我们恩惠。只有树立这样的观念，“真诚的为每一位用户设想”才不是一句空话，我们和利时公司才能在如此激烈的竞争市场找到长久的立足点。

浅谈项目管理

一.商务谈判

1.作人的姿态

作人似乎跟商务谈判不太有关系，很多技术人员相信PM需要的是本事，是如何做好一个项目，而不是会搞好关系弄的四平八稳的人。随着PM在中国的悄悄兴起，越来越多的PM开始在老总的授意下参与商务谈判，和销售们一起打单子，这就比较实在的需要PM们去揣摩客户的心理。揣摩客户心理需要有多方面的知识，需要深度和广度，然而，最重要的仍然是作人。如何放下架子，降低作人的姿态，对从技术人员转型的PM们来说，是至关重要的。

降低作人的姿态需要从多个方面去实施，最主要应该记住：人不可貌相，更不可以地位衡量。很多公司为了保持公司形象，会统一叫员工打扮的好看一点，看起来象个白领的样子。然而，老板多半是没有约束的。中国改革开放才二十年，很多有钱的老板实业家文化层次都不高，往往是当大学生们只会把屁股坐在板凳上肆意挥霍父母辛苦积攒的财富时，他们已经在各地奔波，积累丰富的商业经验并对金钱，人生和社会的本质有了充分的认识，形成了自己稳定的思维框架。这些人，很多都是穿着旧旧的衣服，戴着破破的手表，说话的时候经常会带上三字经，钻进上海的人堆里，搞不好你会把他当成民工。因为到他们所处的社会地位，已经不需要任何华丽的外表来衬托自己的身份，他们有的是底气。对PM来说，这是个非常危险的挑战。虽然说项目在初期有意向时会对对方的人事和关键人物有一定的了解，然而大项目里能说的上话的人太多了。上海人最瞧不起的就是土气，很多人谈项目的时候看到民工或很俗气的表现不免会皱皱眉头，往往在皱眉头的时候就失去了项目，也就是失去了市场和金钱。PM必须作到能与每一个层次的人交谈，尤其是看起来比自己层次要低的群体，哪怕是公司里扫地的阿姨。只有作到谦虚谨慎，不摆架子，尊重别人，才会得到别人的尊重，才有机会赢得项目。鼻子比眼睛高的人只会把自己的鼻子撞扁。

2.丰富的知识面

光尊重别人还不足以赢得项目，准确的说是赢得对方关键人物的信赖。PM一般用不着陪客户喝酒吃饭，那是销售们的事情，但是PM和客户讨论问题可能是最多的。讨论问题的时候就是机会，如何投其所好，是一大关键。金钱与美女依然是常规的敲门砖，然而这种傻瓜也知道的办法人人都会去做。老板的关系也只是一个方面，如今的大

老板，哪个没有关系？同等条件下PM凭什么去胜过别人一筹？

我一个朋友（PM）打一个单子时，发现对方对什么都不太感兴趣，费了很大力气也找不到突破口。对方这个人非常顺利，金钱地位美女样样不缺。他花了好多天和对方交谈，以自己的博学逐渐取得了对方的信任。后来他隐约发现对方对数学和天文学的发展史有所涉猎，如获至宝，回家花一个通宵的时间在网络上搜索相关资料。第二天他根本不谈项目的事情，只跟对方大谈特谈哥白尼，布鲁诺，伽利略这些人的生平，整整吹了一天。对方点头如捣蒜泥，态度和热情都来个一百八十度转弯，隔天他就拿到了单子。这是个经典的战例，谁能事先想到哥白尼会来帮助IT的人赚钱？这个PM靠的就是博学和由博学引申出的敏锐的感觉抓住了机会，让客户产生共鸣。客户感觉他层次也很高，而且和自己有共通之处，信任度大大增强，把项目交给他放心。如今这种例子在商务谈判中已经屡见不鲜了。对PM来说，并不要求在各个方面都很精通，那是不可能的事情，只要PM对一些流行的话题和天文地理历史各方面的知识有个大概的了解，在需要的时候能尽快的掌握，才有机会创造机遇和把握机遇。

3.强大的沟通能力

胸中有万千墨水却不知如何表达其实是比较少见的，但并非绝对没有。每个人的人生轨迹都有所不同，思维受环境的影响也各有差异。包括象我们目前这个班级里的一些未来的MSE们，一定有比较内向或者不太爱表达自己观点的人，这些人比较被动，往往很难承担起谈判的重任。从今天开始，这类人就必须重新学习如何说话，如何大声的争论。沟通，并不仅仅是大声说话，而是在表达自己观点的同时发现问题并综合整理加以解决。除此之外，沟通的能力与社会经验息息相关，与PM的见识联系紧密。在日常生活中，PM就要多留心，多思考，当别人想到某个层次的时候要争取比别人考虑的更深。当然，也有一些不够踏实的朋友把沟通和吹牛当成了完全的一回事情，在和客户交流的时候口若悬河的说一些不着边际的话。这种人，碰到不懂，不太认真或者好奇心强的客户是有一定市场的；而有水平，负责任的客户往往会觉得这种人不可靠，一般不会把单子交给他。PM需要把握好这个度，吹是肯定要吹的，只是吹牛的时候一定要有基础的去吹，对从来没涉及过的领域或者根本不懂的东西轻易不要发表意见，挑选自己熟悉的方向合理的进行发挥，适当的留上一两手，给对方高深莫测的感觉，效果最好。

4.优秀的售前团队

这个团队一般是由总经理发起并组建的，通常不指定PMP，对团队的成员如SALES，PM，SA，ENGINEER们的团队合作提出了比较高的要求。一般公司在接下一个单子进行到一定程度的时候，PM往往会尴尬的发现协议上销售代表们对客户的一些承诺是几乎做不到或者根本做不到的事情。这种情况非常多，销售的任务是拿下单子，我听到的销售们说的最多的就是“没问题”或者“NO PROBLEM”，但是当我听到客户的要求和销售的回答时我总是心惊肉跳，很不自然。销售是非常辛苦的，为了建立客户关系，尤其是空白的市场是很不容易的，往往为了一个单子会牺牲非常多。在这种情况下，和销售进行协调自然而然的又落到了PM的头上。在销售和客户做承诺之前，PM要主动的跟销售交流，提供粗略的总体设计框架和技术难关以及能考虑出的工作量，而不是等出了问题再被动和销售在老板面前互相推委责任。在组建团队的时候，PM要根据团队里每个人的素质和任务进行因人置宜的信息传递。优秀的售前团队合作是接单的重要保障。

在商务谈判的实际操作中，存在着各式各样的问题，PM的职责和要求绝非以上几点所能描述详尽。根据环境，政策，人文，关系等各方面的不同情况，PM的不同成长经历，每个PM最终都会建立自己对商务谈判的看法和经验。但是有一点可以肯定，这是PM成为PM的第一道关，也是最重要的一关。接不到单子，PM将失去存在的意义。与销售有所不同，PM在该阶段的任务除了接单，还要尽可能的搜集客户关键人物的资料并与对方各个阶层的负责人建立良好的客户关系，以便在项目实施时充分调动资源。

二.启动阶段

1.项目的一些基本概念

项目三要素有多种版本，各不相同。实际操作中多分为范围，成本与进度，其中最重要的莫过于范围。我们把项目最终生成并提交给用户的产品和文档统称为递交件。谈判的时候一定要确立递交件的标准和要求，也就是范围。尽管商战的时候不可避免的客户会不断提高标准和要求，而承诺的款项却不会有一分钱的增加。但是这个标准对每个公司来说都有一个底线，一旦超过了这个底线，那项目就肯定是亏的。除非是为了二期有利可图或者是为了搞好关系，否则范围超过底线的时候情愿不做，再厉害的PM在这种情况下也是无能为力。建立范围需要的就是PM的多年的实战经验，在大大小小的项目中用血泪换来的一些体会。在这个时候，很能体现PM与技术人员的区别。成本就是客户答应付的款项，与我们的投入成本并不是一回事情。进度就不用多描述了。

项目如何成功？也有一些关键的因素。个人的理解也不尽相同，通常包括以下几个方面：界定工作目标及工作任务；老板或高层的支持；优秀的PM和开发团队；充足的资源；良好的沟通；对客户的积极反应以及适当的监控和反馈。这里要注意的就是资源和高层的支持。一个上规模的公司总是同时会有很多项目，可是再大规模的公司资源也不足以保证每个项目都能组建最合适的开发队伍或拥有最好的环境。这时候各个团队或者部门之间不可避免的会发生资源争夺战，摩擦再所难免。这时候对PM的作人再次提出挑战。除了高层对PM项目的重视程度，如果PM

平时在公司与同事相处的好往往能使很多别人看起来很棘手的问题迎刃而解。相反，一个不会作人的PM由于人缘差，即使高层强压别的部门或团队配合，别人也会能拖就拖，延缓项目的进度和质量。有时候，这种内耗对项目和PM来说是毁灭性的。对客户的积极反应也比较关键。一般来说PM已经被项目里大大小小的事情搞的筋疲力尽，要PM去主动要求客户配合是很吃力的事情。然而，这个时候，越是困难，越是觉得累，越是要去主动。客户往往也不是特别的积极，主动与客户联系沟通和测试能及早发现问题。从风险控制的角度来说，问题发现的越早，风险越小，损失也就越小。积极的态度可以带动客户的积极性，在项目完工的时候，客户对你的感激往往是难以用语言描述的，这对以后接单或者做二期三期会打下良好的基础。因为在和别的新客户谈判的时候，新客户自然会找你的老客户了解情况，这时老客户随意的一句话顶的上你很费心的十句。

项目具有商业行为的几个重要特征，有消费源，有参与者，有成功关键因素，有财务目标，有风险。

2.启动阶段的主要任务

根据PMI的解释，接单之后项目自然转入启动阶段。启动阶段PM的主要任务是率领总体架构设计师和系统分析员收集尽可能详细的数据，确立尽可能详细的需求，进一步确立详细的项目范围，预估资源，确立其他方案并获得进入下一阶段的批准。在这个阶段，随着需求分析的深入，PM也开始在公司内部进行人员挑选和资源争夺，着手组建自己的项目团队。项目即将进入计划阶段。

在收集完数据之后，PM要和客户开始明确项目的大小，成本，规格，期限等重要特征并将其写入合同文本，同时准备内部的包括预算，衡量标准等文档，建立项目的评估标准。接下来就是需求分析。由于专业的原因，我们这里仅讨论软件工程项目的需求分析（以下简称需求分析）。

需求分析的主要参与人员有PM，总体架构设计师，系统分析员，熟悉业务流程的客户。PM统领的团队这时候还不是真正的开发团队，我们叫做前期团队。随着需求分析的逐步深入，新的团队成员不断加入，启动阶段结束的时候正式的团队将建立。对一个已经启动的项目来说，需求分析直接决定了项目的成功与失败。最初的需求体现在客户的工作说明书或招标文件及附件上。这种需求一般比较含糊，无法体现客户真正的需求。前期团队要根据自己的经验和客户沟通并引导客户进入正轨。有时候客户会很不讲道理或者思路僵化，就要求按照他的思维去定一些明显错误的需求。这个时候团队成员要耐心和客户举事实，谈经验，讲道理，用图形或模型等直观的方式将需求描述出来，比如常见的数据流图等。所以说，争论再所难免，客户有时候会吹胡子瞪眼睛拍桌子甚至会说“这个东西不要你们做了”之类的话。PM此时除了要亲身参与需求分析综合整理文档之外，还要处理好团队成员与客户的关系，确保关系不会恶化到无法收拾的地步。只要PM尽力约束团队中的成员，这个度还是很容易控制的。

对快速开发和叠代开发来说，需求和实现往往是同步进行，开发速度快是一大优势。对有相同或类似模式的小项目来说采用快速开发或叠代开发是很合算的做法，时下流行的极限编程就是针对这方面建立的思维模式。然而，大中型项目中有太多不一样的需求和模块。如果不是因为项目有差异，那么市场上就只有产品而没有项目了。所以，大中型项目的需求要认真仔细的去做。我们要讨论一个问题，究竟应该在需求分析和总体设计上花费多少时间？我们熟悉的瀑布开发模式基本上分需求分析，总体设计，软件开发，测试等几个阶段，然而究竟应该在前两个阶段上花多少时间却没有定论。实际项目操作的例子表明，分析设计的时间越长，需求设计做的越详细，测试的时间就越短，返工率越低，风险也越小，成本越容易得到控制。而需求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期进展顺利的时候问题不大，到了项目后期和测试阶段一些潜伏期比较长但是破坏作用比较大的问题就会凸显出来，造成返工，延长测试时间。所以与其把问题堆积到紧张的项目后期，不如把时间多花点到需求分析和总体设计上。基础夯实了，金字塔就容易造了。

在日本公司打工的程序员们可能都知道，小日本的软件规范非常厉害，他们花在需求分析和总体设计上的时间通常在40%到50%左右，远远超过国内软件项目的实施，效果也要强的多。他们总体设计的规范甚至详尽到某个过程该如何判断，确立什么样的条件，换言之就是把什么时候该如何写(if...else)语句都帮程序员定好了。在这样的软件规范下，程序员更象是装配流水线上的工人，对一个模块或技术熟悉到一定程序就变成了完全的重复性劳动。所以在日本和欧美经常会有程序员是低级工作一说，很多人不明就里，对国内程序员也照搬，对国内的程序员来说是很不公平的。在国内，只会照抄别人代码，一点都不懂创新，凡事依靠别人，快下班就盯着表看的程序员是不少，这种人一般很难有什么前途。但是，优秀的不断进取的程序员也很多。由于国内没有象CMM这样的软件规范或者很少，所以这类优秀的程序员不少都是干着系统分析员甚至PM的活，拿着程序员的工资。这类程序员虽然在起步时会吃很多亏，而且是主动找亏吃，然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为PM进行商务谈判的时候，前者还在各个公司里频繁跳槽，跳来跳去都不满意。有些扯开了，回到我们的话题。日本的软件规范与CMM有惊人的相似，其中至少有35%以上都是几乎一模一样的。最近经济不景气，东京倒闭了160家软件公司，这个数字是今年6月份的，还在不断增加。这些公司纷纷抢滩上海，招收技术人员。如果去这样的公司应聘就要考虑清楚了，进去可以学到他们的规范和质量控制，可是要想从程序员成为系统分析员或PM，比登天还难。往往一个程序员进去干了好几年，对自己的那一块熟的不得了，而对隔壁同事所做的东西一窍不通。

拒传华为正在尝试CMM4（华为印度研究所已经通过CMM4），对在华为工作的程序员们来说可谓福祸难料。当然，已经作到PM或QA或者热爱CODING的朋友例外。

需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最长，分析员们在客户的各个部门之间几乎把腿都跑断，把口水说干，就是为了确立一个初期的需求模型。所有的文档将会提交给PM进行复审并签字，不合格的打回重做。反馈表随之将提交给客户，第二遍第三遍等等等等接踵而来，与客户反复讨论和磋商，反复提交文档和表格，目的只有一个，明确需求。当PM最终合并了所有文档并确立需求之后，最终生成的需求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加，以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。需要说明的是，客户并非都是蛮不讲理，但是说实话，颇有无奈，国内目前的项目大多数客户为了不让自己的钱白花，经常变着法子提需求。在启动阶段明确需求并签字，无论最终情况如何，一份详尽的书面文档可以解决很多口头承诺或概念模糊的文档带来的许多问题。

详尽的需求分析有一个额外的好处就是对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进行项目的判断标准。有时候，这种大项目在签单时双方都没有绝对把握保证可以出成果，一旦在需求分析阶段发现难以逾越的技术难关，就会放弃项目。典型的例子就是NMD洲际导弹防御系统。上世纪八十年代初美国搞星球大战计划，拖跨了苏联。大家对那段历史有些含糊，很多人认为苏联人上了美国的当。其实并不完全如此，苏联人的情报机构无孔不入，并非那么容易上当受骗。实际上当时美国国防部已经开始着手NMD系统软件的需求分析，前后耗资数亿美圆，耗时两年，仅仅是做需求分析，终于发现存在着在当时技术上无法达到的高度，随后项目被放弃。

3.项目启动

项目启动要确定项目计划，与客户一起实施第一次项目审核，确认并对一些产品和服务向下包厂商下订单。这个时候的PM会忽然发现有开不完的会，一天开三到四个会议是很正常的事情。这些会议有与客户的会议，与下包厂商的，有团队的，有公司高层的。团队的会议主要是建立正式的团队，提供团队成员的角色和职责，提供绩效管理方法，向成员提供项目范围和目标。与客户的一个主要会议将是项目启动会议。在这个会议上PM会与客户确立正式的交流渠道，项目综合描述，让项目参与人员相互了解，建立以PM为核心的管理制度。还有一些零零碎碎的东西甚至包括办公场地的大小，电话多少部，所有人的联系方式等等都要在会议上确立，并做会议记录。这都是些非常琐碎的事情，听起来婆婆***，却是非常必要，缺一不可。大概就是所谓三军未动，粮草先行吧。

这时候，作为公司高层，应该向全公司发表申明，正式给PM发布项目经理任命书和项目授权书。这个动作虽然在别人看来有些形式主义，但是对提高PM本人的士气和责任感是有很大助力的。

三.计划阶段

1.定义结构分工结构图（WBS）

启动阶段结束后，项目进入计划阶段，也就正式进入实施。这里概念可能有些不太对头，其实是翻译的缘故，反正大家明白意思就行，不用拘泥于字面。WBS是一组要提交的项目元素，用来组织定义项目的总体范围，具体包括从工作内容，资源，成本角度考虑项目范围；建立一套系统所需要的分层工作结构；把项目分解成易于管理的几个细目，这概念有些模糊，其实跟资源管理器里分目录是一回事情。可以说，WBS是计划阶段的核心。WBS会详细的分到递交件，包括给自己人用的项目使用的过程文件，给客户用的模块和说明文档，完成每个细目的标准以及如何把这些细目的责任分配到具体的个人。WBS有缩进式和树状式，我这里也没办法画图，大家参考一些项目管理的书籍，里面有详细介绍。我整个文章只挑我觉得需要注意的地方，如非必要，对技术细节或者工具使用不做详细介绍。WBS的细目并不需要分解到同一水平，最下面的细目叫做工作包，分包的依据是个人的责任和可信度，也就是说到每个人头上的任务是否能落实，是否有把握完成；还有就是准备对项目进行控制的程度，程度越深，WBS树也就越深。由于WBS是实用性的东西，根据个人理解也不一样，所以一个项目可能会有几个正确的WBS，看PM的需要和最适合当前团队状态的进行选择。

WBS的定义还是很麻烦的。PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式（BRAINING STORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。在头脑风暴式思考时，会有很激烈的争论，PM要协调关系，调节气氛，从自己能考虑到的各个角度旁推侧敲，提示成员的思维角度和方向并加以总结。尽管很麻烦，制订WBS仍然是非常值得的。如同需求分析一样，WBS准备的越充分，编码的进度越快。

2.风险管理

既然是商业行为，那么项目的风险必然存在，相信阅读这个帖子的朋友不少人都经历过或大或小的风险。有些风险很容易解决，有些风险则大大损害利益。不论什么样的风险，能避免尽量避免，所以有必要对风险进行管理。由于风险的不可预知性，风险管理难度很大，概念也很难讲清楚，只能从一些可行的角度去分析，进行管理。

首先要识别风险。这是个难度很高的活。PM要先召开风险识别会议，这个会议面向公司，高层，跨部门的有经验的人都将参加。然后审核由项目小组生成的风险清单并与重要成员进行风险沟通，检查一些重要的风险源如WBS，40 成本（时间）预估，人员计划，采购管理等等。最后就要用到PM本身在以前类似项目中得到的经验教训。

识别之后要进行分析。我们可以进行粗略的量化分析（精确分析是不可能的事情）。有经验的人可以一起参加讨论，把提交出来的风险进行分类。首先按发生的可能性分，一般分成高，中，低三个级别，虽然很勉强，但是好歹也有个量化了；然后按耗去的成本分，也是高，中，低三级。我们可以把这两种类别的三个级别进行组合，碰到可能性也高，成本也高的风险就定位为不能接受。碰到这种风险只好让客户修改需求或者增加风险预留成本，否则一旦亏起来不是亏一点点，有可能赔的很厉害。高和中，中和中的搭配都是属于高风险，中和低，低和低搭配属于低，高和低搭配属于中。

针对出现的可能性，需要采取一些手段降低风险。到目前为止也没有一个定论说有绝对好的方式，只能尽其所能的避免。有几种方法可以考虑，第一种是将风险纳入项目管理计划并指定负责人，由外部人员定期检查项目风险，一旦风险发生，执行风险管理计划；第二种是保险，这种属于风险转嫁；第三种方式有点奸，不过最保险，就是把客户拖下水，让他们一起参与风险管理，呵呵，到时候就好说话了：）

风险管理作为项目计划之后，PM需要更新WBS，修改日程计划和更新风险管理计划。

风险预留通常是成本的8%。

3.预估

预估是从量化的角度对项目进行评估，主要包括工作量，任务期限，人力，设备，材料，成本等，要注意预估不是财务策略或报价。

预估其实并不是一次性工作，在整个项目过程中，预估始终需要。预估似乎没什么特别需要提的地方，每个PM接到项目的时候自然会有预估，在项目发生变更或进入下一阶段时也会预估。预估的作用主要还是让PM作到心中有个底，安排计划时不至于毫无头绪。

4.进度计划

进度计划就是一个模块或功能要写多长时间，PM安排个日期，设立里程碑，叫程序员们不能偷懒。进度计划是从WBS提取过来的。对PM来说，合理的安排进度计划对项目控制和激励团队士气有着很大的作用。对程序员来说，进度计划毫无疑问是噩梦。

显示进度计划一般有先后顺序图，甘特图和里程碑图表。上回邵卫老师讲课，推荐的工具是m$的PROJECT，这个工具我还不会用，因为没时间去摸索。我的头倒是用的很溜了，近一个月来他就用这个PROJECT画了一个又一个的里程碑图，不停的折磨我和同事的神经。我们一般都是一边开发一边做UNIT TEST，效果上来看，因为有强大的时间压力，效率上比之前确实要提高不少，可是我们也只能结结巴巴的赶完进度。由于TEAM里人少，我们都是一个人做几个人的活。我每天早晨六点多出门，经过将近两小时颠簸，八点多点已经坐在位子上，中午吃15分钟的饭，干到晚上八点下班，到家吃完饭往往已经11点了。一个多月我从来没吃过早饭，没有睡过六个小时以上的懒觉。虽然强大的压力使我们能在短时间内掌握尽可能多的技能，开发更多的模块，但是对我们的情绪也是有很大的影响。所以说，项目里程碑是一把双刃剑，合理安排才能既促进效率也不至于打击士气。团队成员士气的逐级衰落会给项目后期的开发带来难以估计的影响，进度将会大大延缓。关于PM和团队的问题我们后面会讲到，这里我先祥林嫂一把，然后跳过。

里程碑图表的特征是任务，成员和时间，任务和成员用文字标志，时间用数字描述并辅助以图线跨度，象阶梯一样非常形象，一目了然。管理起来非常方便，完了的打个钩就可以了。

网络逻辑图是表示任务和逻辑关系的示意图，可以用先后次序表示，也可以用关键路径表示。其实把各个活动划分为1，2，3，4等阶段，每个阶段包括小活动1.1，1.2，2.1，2.2，2.3，2.4，3.1，3.2，3.3，4.1，4.2等，日程计划也分四种，一般只提到从前向后和从后向前两种。从前向后的概念就是某项活动必须相同或晚于直接指向这项活动的的所有活动的最早结束时间的最晚时间。有些绕口，我们打个比方：2阶段指向3阶段，那么2阶段里的4个子阶段也都指向3。假设2.1结束时间为1月12日，2.2结束时间为1月22日，2.3结束时间为1月15日，2.4结束时间为1月20日，那么，2阶段中最晚的结束时间是2.2的1月22日，所以在3阶段中的3个子阶段3.1，3.2，3.3的最早开始时间都不能早于1月22日。至于从后向前的例子大家自己去推吧，我就不举了，刚才几个123打的我累死了：）

项目经常需要调整进度。在不改变项目范围的情况下，调整进度有几种方法：利用快速跟踪手段来改变任务间的关系；将串行的任务改成并行；改变工作方法（可能改变WBS）；改变日期限制，使关键路径上的任务开始或结束的更早。虽然方法多样化，在我看来只有一条，就是拼命的压榨程序员的劳动力。如何压榨，还是个技巧。如前面所分析的，需求分析恨不得多分点时间给它，压需求是不太可能；测试阶段后期接近完工，罗里巴唆的事情一大堆，忙都忙不完，那时候PM一门心思提前/按时完工，好收钱，压那段时间似乎也不太可能。说来残酷，最能压的还是CODING，编码阶段往往是压缩重点，总之大家埋头苦干就是了，大项目压缩的时候程序员吃喝拉撒都在公司是很正常的事情，相信不少人都有很深的体会，这里伤心事情也就不提了。只是我总结一下，让未来的PM们有压

榨后来人的依据，呵呵。测试前期也可以适当的压一压，那时候人刚完工，都比较懒散。国内一般企业规模都不大，没有专门的质量控制部门，所以质量保证和测试往往就是程序员或PM本身。其实质量保证和测试人员的人数和素质都应该要高于程序员。在日本和CMM实施的公司里，编码压缩是很容易实现的事情，因为那些程序员真的是技能熟练的装配工人，压起来方便的很。他们这样培养人的目的或许就是为了压缩吧？！

四.控制和执行阶段

1.软件开发

实在没什么好说的，也是大家最不愿意谈的，平时在公司里谈的已经够多的了，还要在这里受我唠叨。需要提醒的依然是团队合作精神和完善的文档管理制度。SOURCESAFE这些工具有时候还是有必要使用的。经常看到有人说天才程序员不写注释什么的。我相信有这种天才程序员，因为我碰到过几个。我爱人公司里也有一个，他们的一套产品核心代码就是这个人写的，4年过去了，周边代码换了好几茬，核心算法始终没换过，可惜这小子跟了李洪痔，如今已经不知所踪了。但是他的代码似乎也要有点注释的，没有注释过段时间再天才的程序员也不能保证他是最有记忆力的。而且，对一个项目的编码来说，靠一两个人打天下如今是不可能了。别人的公司都是团队，两人智慧胜一人，这头还在靠一个天才支撑门面，实际上市场可就别人抢了去，那时候再天才也没用了。编码的时候讲究技术公开，程序员不要藏着掖着，对大家没好处，PM要想办法调动大家创新思维的积极性，营造良好的技术讨论氛围，碰到技术难关的时候就容易攻破了。

有个问题需要单独对还没有PM觉悟的程序员说，其实是在调研的时候就定了的，就是使用什么样的开发工具。没有经验的程序员往往会拿着C++或者JAVA的资格证书或者拥有一两个开发工具的一些经验而得意洋洋。其实老板和PM根本不看重这个，他们关心的是使用什么样的工具能尽快的达到目的。管你什么C++，DELPHI，PB还是JAVA，只要能做的出来，VFP都可以用。我举这个例子并非说不看中工具，而是提醒想转型为PM的程序员，第一要把工具当作工具，而不要被工具套进去，钻研一些一辈子都用不上的技术；第二要掌握的并非是单独的一个工具，而是流行的程序设计的思想，以及在最短时间内掌握一门陌生工具的能力。只有建立了这样的思维，才有可能转为PM，否则一辈子都是技术工人，最多就是个技术总监。

2.变更

对任何项目，变更无可避免，无从逃避，只能去积极应对，这个应对应该是从需求分析就开始了。对一个需求分析做的很好的项目来说，基准文件定义的范围越详细清晰，用户跟PM扯皮的幌子就越少。而需求没做好，基准文件里的范围含糊不清，被客户抓住空子搞你一下是非常头疼的事情，往往要付出无谓的牺牲，有时候甚至非常火大。

需求做的好，文档清晰又有客户签字，那么后期客户提出的变更就超出了合同的范围，需要另外收费。这个时候千万不能手软，并非要刻意赚取客户的钱财，而是不能养成客户经常变更的习惯，否则后患无穷，维护的成本会让PM吃不消。在客户提出变更请求时，要建立变更申请登记表和变更申请表，并让客户签字。当然，有时候一些不是非常关键的模块PM也不至于一点不讲情面，该卖面子的时候还是要卖，尤其是当着对方领导的面，千万要卖面子，但是也别卖的太干脆，不要让他们得到的太容易。

需求做的不好，客户抓住漏洞或者非常不讲道理，麻烦就大了。有时候争论会很厉害，到非常白热化的地步，PM与客户代表几乎沟通不了。PM在客户关系和短期利益两方面难以取舍，一般都是向客户妥协，最终形成恶性循环。这种情况非常难办。一般这种情况都是到了项目后期，做重大的更改几乎是不可能的事情，如果白做就要亏钱。而这个时候如果PM跟对方高层的人关系搞的定，可以透过对方高层把事情压住。然而由于已经到后期，客户代表不会轻易更换，对方这次没有改成，必然心怀不满，下回在别的模块依然会找麻烦或者在谈二期的时候动动手脚，都是很让PM伤脑筋的事情，这方面目前还没有什么好的解决方法，所以尽可能的做好需求比什么都重要。相对需求来说，什么WBS，风险管理，计划进度都是扯淡，需求做好了，一帆风顺。还有一种办法就是装可怜，要装的非常的象，在对方的领导面前装，而且不能让人看出是装的样子，要让你自己都觉得你自己是真的可怜，那么就算这次客户硬是要求改了，下回他也必然不好意思再叫你改。其实人心都是肉长的，如果可能的话，我还是不赞同使用一些手段的，但是有时候客户非常难以在短时间打动而工期又将接近，这种情况下就要靠PM耍一些手段了。各人有各人的方式，八仙过海，各显神通吧。

PM在变更管理中需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。

3.质量控制

大公司有质量管理部门（QA），QA的成员基本上都是由非常有经验的PM转型过来的老狐狸，是老总接班人的有力争夺者。一个QA会管理多个项目，有时候甚至会亲身参与。PM和QA有些象猫和老鼠，不停的通过报表传递一些心照不宣的假数字。QA对PM的工作最终是有评定的：A级表示总体在控制下；B级表示当前在控制下；C级表示有显著问题；D级表示有重大问题。如果PM得了个D，那可不太妙，不但世界级的QA会每个月要收报告，地区QA会一个星期找来面谈一次，训一顿。得到A的PM是很逍遥的，基本上不会有人来过问。在没有QA的公

司，质量控制只能由经过授权的团队成员进行，效果就要差的多了。

质量管理贯穿整个项目周期，详细的可以参见CMM。

4.成本管理

PM经常通过控制进度和预估来控制成本。PM必须经常问自己，项目已经到了什么阶段？完成了多少？花费了多少？完成时成本是多少？挣值法的术语不少，象BCWS，BCWP，ACWP，但是关系比较简单，大家参阅一下相关资料，这里不再羸述。总之，PM要管理好成本，注意节约，但并非是拼命剥削程序员，该花的还是要花。

五.结束阶段

1.项目结束

项目结束时，PM要将最终系统方案提交给用户，完成项目所有的提交件，收集项目全部信息并结束项目，完成或终止合约，签署项目结束的相关文件。

项目结束意味着可以收钱了。PM辛苦了那么多，终于可以高兴一下了，收到最后一笔款项，意味着递交件的移交和团队的解散，项目也转入维护阶段。不过收钱未必代表着赚钱，要看项目是否按时完工。一般来说，提前完工的项目很少，但是能赚大钱；按时完工的赚小钱；延期的要赔钱。一个人首次承担PM，如果没有人带，多半会失败。失败没什么，所有的PM（注意是所有，不是几乎所有）都失败过，然而失败会成为教训和经验，推动你继续前行。在美国，每年至少有40%的项目无法实施被搁浅。只有在项目中和生活中不断磨练，培养自身素质和作人的基本准则，才能成为赚大钱的PM。

2.项目完工会议

项目结束时，依然要开会，不过少多了。一般跟客户要开一个，主要是确定所有的提交件都已经被接收，对突出的个体进行表扬，对外宣传成功案例，标志并记录项目的正式结束。这时候开会很轻松，目的也很明确，做完了大家好聚好散，或者以后有机会再合作。

团队要解散，内部会议肯定是要开的。也没什么好废话的，该表扬就表扬，该发多少奖金就发多少奖金，毕竟大家都累死累活的干了那么长时间。项目结束请客户出去泡温泉时PM们千万别忘记了辛苦为你工作的

程序员和工程师们，当然，如果他们不愿意看到你的脸那么你就折现发到他们的存折上去，正好让他们回家好好休息休息。这样下一个项目需要他们的时候他们才会为你卖命。说出来奖金发出去似乎你损失了，其实你赚大了。

3.客户满意度

形势也好，历史记录也好，尽管项目结束的时候客户满意度PM心中已经有底了，但是还是有必要向客户各个层次的项目代表发一张信息反馈表，收回的信息将反应客户的满意度。其实真正体现客户满意度的地方有很多。第一就是付钱付的快，如果客户不满意，一分钱藏在他牙缝里你也很难抠出来；第二就是二期，二期非常非常重要，因为这里已经是属于一种无销售成本的项目，又有一期的经验，可以说二期的钱是最好赚的。这中间的感觉，只有经历过的人才明白。

六.团队管理

1.建立团队

挑选人材依然是PM头疼的一个大问题，有时候一个在别的项目里很优秀的人材，挖过来未必能适应。所以，PM还是要拓展知识面，培养自己的敏锐度，因人置宜，才能挑选对自己项目有帮助的人材，才能真正对项目起作用。

2.核心程序员

任何项目都有核心程序员。核心程序员背负着很重的责任，平时要和普通程序员一样没日没夜的加班，碰到重大的技术难关更是整个人扑在电脑上，熬上几个通宵是家常便饭。常有人抱怨程序员工资高，真想请这些人来尝试一下程序员的工作，看看他们付出的精力是否配那份工资。前面说过的，中国的程序员不同于日本和欧美，他们很多人参与了系统分析和建模，对脚踏实地工作的程序员来说，这份工资实在是委屈了。看看行业里努力工作的程序员们，有几个不是头发花白，高度近视，未老先衰的？上星期五晚上我加班到10点，隔壁公司的一个技术总监特意留下来跟我说：“我们这种人，前半生拿命去换钱，后半生拿钱来买命！所以，工作的时候一定要注意劳逸结合！”道理我并非不懂，我也不想透支自己的身体，但是我有选择么？

PM要特别注意爱护核心程序员，尤其是他们的生活困难和精神状况，有时候，他们耍性子或者不合作PM要妥协，要从自己身上找原因。其实在国内，我还没碰到过敢这么做的程序员。相对PM来说，程序员是绝对的弱势群体，没有任何发言权，几乎可以说PM想怎么做，想怎么改，程序员就要付出一切代价去达到目标。

3.奖励与惩罚

奖励是不用说的了，相信所有阅读我这篇文章的PM，未来的PM，程序员和未来的程序员们都知道如何去做，这里只说惩罚。惩罚似乎很不好办，其实对PM来说再简单不过。一个程序员把模块做砸了，骂，扣工资，开除都不顶用，在项目没完成之前不是追究责任的时候。一个优秀的PM应该给他一个机会，当作没事一样让他去做别的

事情，把他做砸的事情交给别人去做，就是对他最大的惩罚。这样既能激励他上进又不会让他尴尬，他会感激你一辈子，因为你给了他一次机会。而PM挑选这个人进团队并给予他责任，他没有完成，PM本身就有责任，应该自我检讨。

4.管理冲突

无论团队里的成员相互之间很熟悉还是不熟悉，冲突再所难免。在发生冲突的时候PM要牢记以公开，公正的方式处理冲突，不能因为其中之一是自己的小姨子就干掉另一方；处理事情的时候必须对事不对人。有时候，成员与PM之间也会有冲突，一般情况下都可以几乎肯定是PM的责任，因为很少有成员敢吃豹子胆来反抗自己的顶头上司。这时候PM除了要及时的做自我检讨之外，要有宽广的心胸。绝对不可以利用职权打击与自己有矛盾的成员，否则团队里所有成员都会心寒，项目的质量将会大打折扣。如果他确实不对，也要忍住，等项目完了慢慢收拾他不迟。PM的心胸还表现在不能嫉贤妒能上。当公司高层越级表扬团队某成员时，你应该高兴和光荣，而不是阴险的想着下次如何把这份光环戴到自己的头上。实际上在国内的很多PM都是这么做的，邀功的时候全是他的，有了责任都在下面。这种PM永远做不大，迟早会被淘汰。

5.承担责任

项目是有风险的，肯定会有失败的部分甚至整个项目失败。虽然说每个人都在WBS里定下了责任，在项目里程碑里都有任务。但是当整个项目危机来临的时候，PM要勇于站出来，承担起全部的责任。这是做人的方式，也能让你赢得团队所有成员的尊敬和爱戴。往往在这个时候我们才能体会到什么叫团队合作精神，就是大家齐心合力，共渡难关。

6.资源争夺

前面提到过，资源有限，如何争夺而不伤和气是对PM的另一个挑战。因为整个公司是一个大团队，内耗的厉害对PM没有好处。当然，摆平各路神仙是不可能的。但是一个健康的公司必然有健康的管理制度和优秀的成员。物以类聚，人以群分，PM应该在公司里主动结交志气相投的朋友，在拿到项目时这些朋友会给你很大的帮助，当然，在这些朋友需要你帮助的时候你也应该懂得怎么做。如果你性子很怪，很难找到脾气相近的朋友，没关系，交几个酒肉朋友也不错。我们公司数据统计，一个人在公司的人缘和他在公司请客吃饭的次数成正比。PM一定要尽心尽力的为公司打算，这样在需要高层支持的时候才会获得鼎立相助，而总是为自己打小算盘的PM是不长久的，总会被别人看穿的。

后记：写到这里实在写不动了，控制阶段的合约管理和项目跟踪没有写进去，一方面我不熟悉，另一方面让大家自己去做一些思索。其实前天我就在构思这篇文章了，本来还想把CMM也写一篇的，如今看来太高估自己的能力了，时间实在是不允许。抬头一看，东方已露鱼肚白，外面隐约传来麻雀的嬉叫声。今天我还要去跟人谈祖房子的事情，明天还要上课，星期一开始又要没日没夜的加班，多想睡个懒觉呀！

上回邓老师的课，我再次跟大家说声对不起，我的发言打扰了大家。作为非MSE成员，我的举动实在是有些过火。但是有一点我还是要申明，我不是为了我自己，我也想为大家好。

我看到了在课程讨论版面里关于我们课程太少，不如其他院校和课程安排不透明的讨论。因为上次的教训，我一直没有表态，担心会再惹麻烦。今天帖子写完，实在是忍不住想说几句了。我觉得课程安排不透明是复旦老师的责任。至于我们课程太少，不如其他院校的问题我觉得不是很有必要提。课程是死的，人是活的。再好的条件也有不成材的，再恶劣的条件也有脱颖而出的，更何况我们的条件并不比别人差很多。只要我们努力，我们不会输给清华的人。我一直不觉得在光坐在课堂里听课能学到什么真本事，MSE们如果不把学到的知识与自己的实际工作融合贯穿并领会其中的思想，那这个文凭拿到手也没用。看本科教育就知道了，大家都是过来人，如今也在工作，你们感觉当初在学校里学的知识在真正上了工作岗位之后有多少能派上用场？好象很多东西都要重新来过。这就是MSE相对普通研究生的优势所在，因为你们一边工作一边学习，理论与实践相结合，对知识的掌握会很快，而不是变成考试和拿文凭的工具。我今天看到亚联招聘的信息，上面根本不提高学历，而是换成了有本事。什么叫有本事我无法定义，但绝对不是一纸文凭能代替的了的。文凭只是个辅助和敲门砖，可以保证你进一个好公司三个月，三个月后你的命运如何还是取决于你能做多少事情。我就是高中毕业，大学退学了两次，无论计算机还是英语连个象样的证书都没有。但是无论你是清华，北大，复旦还是交大的MSE，两年后你毕业的时候你有把握在岗位竞争或商务谈判中击败我吗？

我们需要的是自觉，踏实，进取和拼搏。只有拥有不断努力的恒心，我们才能最终提高自己的社会地位和人生价值，说的难听点最起码不要让自己被淘汰。网络上所有的资料都公开，都有的当，我们的老师又很有能力。其实根本用不着攀比老师的能力，学历和目前的社会地位，只要他有可以传授给我让我学习的经验，我管他是博士还是文盲，管他是IT总裁还是扫大街的！呵呵，这话说出来又要得罪人了！唉，话多就话多吧，总要有人说的！

这篇文章有我一个晚上的心血，也让我复习了一下PM的知识。我把他献给复旦02年所有的MSE们，也献给我爱人。这些年风风雨雨，她跟着我，吃了很多苦，但是她从来不说什么。我要谢谢她！

希望能和大家共同度过愉快的两年！

浅谈项目管理机制

一.项目及项目管理 1.什么是项目

要讨论项目管理，就必须首先理解项目这个概念。项目是为完成某一独特的产品或服务所做的一次性努力。项目一般要涉及一些人员，由这些人员完成一些相互关联的活动，项目发起人通常希望能够在最有效地利用资源的基础上，及时、高效地完成项目任务。

2.什么是项目管理

项目管理是指“在项目活动中运用专门的知识、技能、工具和方法，使项目能够实现或超过项目干系人的需要和期望。”这一定义不仅仅是强调使用专门的知识和技能，还强调项目管理中各参与人的重要性。项目经理不仅仅要努力实现项目的范围、时间、成功和质量等目标，还必须协调整个项目过程，满足项目参与者及其他利益相关者的需要和期望。

二.项目管理的历史及发展 1.历史事件

现代项目管理通常被认为开始于20世纪40年代，比较典型的案例是美国军方研制原子弹的曼哈顿计划。但直到80年代，项目管理主要还限于建筑、国防、航天等少数行业。我国和世界其他各国历史上都有许多成功的项目管理范例。项目管理的实践可以追溯到古代的一些主要基础设施如埃及金字塔、运河、大桥、欧洲的古教堂、道路、城堡等的建设之中。对于项目管理的出现，有说服力的其他一些特别事件有：

■ 1917年，亨利甘特发明了著名的甘特图，使项目经理按日历制作任务图表，用于日常工作安排.■ 1957年，杜邦公司将关键路径法（CPM）应用与设备维修，使维修停工时间由125小时锐减为7小时。■ 1958年，在北极星导弹设计中，应用计划评审技术（PERT），将项目任务之间的关系模型化，将设计完成时间缩短了2年。

60年代著名的阿波罗登月计划，采用了网络计划技术使此耗资300亿美圆、2万家企业参加、40万人参与、700万个零部件的项目顺利完成。

2.职业发展

进入20世纪70年代，各类项目日益复杂、建设规模日趋庞大，项目外部环境变化频繁，项目管理的应用也从传统的军事、航天逐渐拓广到建筑、石化、电力、水利等各个行业，项目管理成为政府和大企业日常管理的重要工具。同时，随着信息技术的飞速发展，现代项目管理的知识体系和职业逐渐成型。

■ 项目管理是二次大战以后发展起来的综合性管理科学分支，■ 1965年第一个专业性国际项目管理组织IPMA（International Project Management Association）在瑞士洛桑成立。

■ 1969年，美国成立项目管理学会PMI（Project Management Institute）。

■ 1976年，PMI在蒙特利尔会议开始制定项目管理的标准，形成项目管理职业雏形。■ 1984年美国项目管理协会推出项目管理知识体系PMBOK（Project Management Body of Knowledge）和基于PMBOK的项目管理专业证书PMP（project management professional certification）两项创新。

项目管理因此作为一门学科和专业化管理职业在全球得到迅速的推广和普及。3.项目管理的应用

实际上任何创新和改革都是项目活动。由于这些任务具有一次性和独特性的共同特征，人们日益认识到采用常规的管理是难以应付的，必须组成专门的项目班子，采用项目管理方法。因此，在企事业单位和政府管理机构中也同样出现了对项目管理的强烈要求。

1）国外市场

世界银行把每一笔贷款作为一个项目来管理；在美国，DEO（能源部）、DOT（交通部）等政府部门，在项目建设时不但自己使用项目管理软件，并规定参与方也得用项目管理软件对项目进行管理；摩托罗拉是世界著名的通信设备和服务供应商，在20世纪90年代就启动了一个旨在改善其项目管理能力的计划；总部设在瑞士的国际ABB工程公司，在90多个国家运营，要求公司的大部分工作实行良好的项目管理；英国、德国、加拿大、法国等国家的政府机构，其投资的项目都要求使用项目管理软件进行管理。

■ 自1983年以来，美国政府投资的所有项目，不论军用还是民用，都要求用项目管理软件进行管理。其效果十分明显，为国家节省了大量的财富及资源。在国外，项目管理软件已拥有一个非常成熟的市场。

■ 业界排名第一的primavera公司业绩： ■ 所应用管理的项目总值超过4万亿美元

■ 第25位PC软件公司(2001软件排行榜前100位)■ 全球85个国家均有授权经销商 ■ 超过35万用户 ■ 典型用户：

Boeing，Chevron，Exxon Mobil, Federal Express，Ford-Jaguar，General Motors，Honeywell IAC，Intel，Lucent Technologies，Motorola，Ontario Hydro，Raytheon，Glaxo SmithKline，Westin Hotels & Resorts。

■ 大客户：香港机场，伦敦地铁，旧金山机场，国内三峡工程。2）国内市场

随着我国经济日益融入全球经济体系，国际竞争日趋激烈。我国涉外项目的比例也将越来越高，国内外形势的发展要求项目管理采用国际通用方式，这就使得我们对项目管理的需求更为迫切。

我国在第一个五年计划时期，就投资建设了156个重点建设项目，到2002年预计在各种项目上的投资将以万亿计，其中大型项目投资将达到2000个，几乎涵盖了经济、文化、科教、国防等所有重要领域，诸如银行贷款项目，能源、交通、水利等基础设施项目，房地产项目，农业发展项目、工业企业技改项目、环保项目、扶贫项目、科研、教育项目、体制改革项目，以及体育、文化活动项目等。

■ 2002年政府拨3000亿元专款用于各类政策性项目 ■ 省、市地方政府捐助至少1000亿元的专款 ■ 每年都有2000个新的1亿元以上的大项目 ■ 我国每年从世界银行获得约30亿美元的贷款

■ 亚洲银行贷款、国际经济援助、出口信贷等，利用外资数额每年都在几百亿美元 ■ 此外还有许多项目要通过国际招标、采购、咨询等方式来运作 伴随着改革开放、申请并最终加入WTO，中国经济在高速增长中日益深刻地融入全球市场，在国际化大背景下，国内大中型项目的数量、投资额度、资金来源和币种的多元化以及管理上的复杂性都大大超过以往。

现代化、国际化的项目建设必须用科学的方法进行管理，现在我国已经开始实行政府采购制度、招投标制度、项目监理制度、政府审批制度等等都是国家加大监管力度、杜绝暗箱操作、确保项目建设质量的具体措施。现在，传统大型企业（导入案例中的汽车制造企业）、高新技术企业（如IT企业）、政府机关、社会团体都开始把项目管理模式作为解决问题一个重要的工具和方法，项目管理的人才和应用热潮已经扑面而至。

三.项目管理的知识领域

在PMBOK中，将项目管理划分为9个知识领域，范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和整体管理。其中范围、时间、成本和质量是项目管理的四大核心领域。

四.项目管理的五大过程

1.启动：批准一个项目或阶段，并且有意向往下进行的过程。

2.计划：制定并改进项目目标，从各种预备方案中选择最好的方案，以实现所承担项目的目标。3.执行：协调人员和其他资源并实施项目计划。

4.控制：通过定期采集执行情况数据，确定实施情况与计划的差异，便于随时采取相应的纠正措施，保证项目目标的实现。

5.收尾：对项目的正式接收，达到项目有序的结束。五.项目管理的基本思想和技术 1.挣值法EVMS

挣值法实际上是一种分析目标实施与目标期望之间差异的方法，故又常被称为偏差分析法。挣值法通过测量和已完成的工作的预算费用与已完成工作的实际费用和计划工作的预算费用得到有关计划实施的进度和费用偏差，而达到判断项目预算和进度计划执行情况的目的。其独特之处在于以预算和费用来衡量工程的进度。

简而言之，EVMS的思想可以概括为以下几个方面：

■ 所有工作开始之前的预先计划 ■ 基于技术目标上的性能衡量 ■ 时间表状况分析

■ 按照完成的工作对资金支出的分析(非预定的工作)■ 隔离问题：

■在费用时间表参数内的技术质量问题 ■不打算替换或更换技术问题过程中的探测 ■ 预测完成日期和最终费用

■ 纠正行为

■ 维持性能测定基线的正常控制 2.蒙托卡罗模拟技术

蒙托卡罗模拟技术是项目风险管理——不确定性分析技术。由于项目中许多因素是变化的，不能用一个固定的值来描述，例如，在软件开发项目中，开发某个子程序到底需要多长时间，一般来说，不能用一个定值（例如20天）描述，但是根据经验，往往可以给出一个范围，例如18-23天。问题是，如果在一个项目中有多个因素都是具有不确定性，如何计算结果呢。这就是蒙托卡罗模拟技术所要做的。本技术中的主要内容包括：

■ 描述不确定性风险因素的方法

■ 如何建立项目模型

■ 抽样技术

■ 数据分析技术

■ 敏感性分析等

3.项目进展评价技术

由于项目中有许多任务组成，在项目进行到一定阶段后就会发现，有些任务工期缩短了，有些加长了；有些任务超出了预算，有些低于预算。如何从整体上评价进展呢？这就是本技术中要讨论的问题。本技术中的主要内容包括：

■ 流逝时间评价法

■ 工期评价法

■ 工时评价法

4.网络计划技术（PERT、CPM）

网络计划是以网络图为基础的计划模型，其最基本的优点就是能直观地反映工作项目之间的相互关系，使一项计划构成一个系统的整体，为实现计划的定量分析奠定了基础。同时，从数学的高度运用最优化原理，去揭示整个计划的关键工作以及巧妙地安排计划中的各项工作，从而可使计划管理人员依照执行的情况信息，有科学根据地对未来做出预测，使得计划自始自终在人们的监督和控制之中，达到以最短的工期、最少的资源、最好的流程、最低的成本来完成所控制的项目。

网络计划的基本形式是CPM（关键线路法）与PERT（概率网络评审技术）。前者是美国杜邦公司和兰德公司于1957年联合研究提出，后者则是在1958年由美国海军特种计划局和洛克希德航空公司在规划和研究在核潜艇上发射“北极星”导弹的计划中首先提出的。两者在初级发展阶段的主要区别是：

■ CPM假设每项活动的作业时间是确定值，而PERT中作业时间是不确定的，是用概率方法进行估计的估算值。

■ CPM不仅考虑时间，还考虑费用，重点在于费用和成本的控制，而PERT用于含有大量不确定因素的大规模开发研究项目，重点在于时间控制。

■ 到后来两者有发展一致的趋势，常常被结合使用，以求得时间和费用的最佳控制。

关键路径法是项目时间管理中的技术，简称CPM。它是把完成任务需要进行的工作进行分解，估计每个任务的工期，然后在任务间建立相关性，形成一个“网络”，通过网络计算，找到最长的路径（主要矛盾），再进行优化。本技术的主要内容有：

■ 项目目标确定与时间、成本、资源的综合权衡

■ 工作分解结构建立

■ 工期估算影响因素

■ 正向计算

■ 反向计算

■ 时差计算等

5.WBS，OBS，CBS，PBS分解技术

WBS是项目范围管理中的技术，它是确定项目范围的一种主要技术，也是进行成本、资源的估算的基础。本技术的主要内容包括：

■ 分解原则

■ 工作分解结构

■ 组织分解结构

■ 成本分解结构

■ 产品分解结构

6.项目管理可视化技术

项目管理的不可见属性，为项目团队的沟通、控制带来了很大的障碍。本技术将介绍，如何把项目的进度、成本、风险、质量可视化的方法。

浅析软件项目管理中的10个误区

随着计算机硬件水平的不断提高，计算机软件的规模和复杂度也随之增加。计算机软件开发从“个人英雄”时代向团队时代迈进，计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法，完成思想观念上的转变。笔者在此分析了10个在现代项目管理中思想观念上容易陷入的误区，希望能够抛砖引玉，引发大家更多的思索和讨论。

误区1：在项目的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一致即可，具体细节可以在以后填充。因为无论开始时有多么细致，以后对需求的修改几乎是必然的。分析：这是一种非常危险的思想。实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致，导致后来预算超出或者时间 进度达不到要求。正确的做法是：在项目需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面 要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。并且，在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽 早地对需求变动问题进行沟通。

误区2：软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现。分析：的确，在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进，往往会有一些需求的 改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过，这并不表明“软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现”。实践表明：随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶 段实现需求更改需要花费1倍的代价；那么，在系统设计和编码阶段，需要花费1.5-6倍的代价；在系统测试阶段需要花费10-20倍的代价；在软 件版本发布以后，甚至可能要花费60-100倍的代价。由此可见，在项目开展过程中，软件需求的改变应当尽量早地提出。这样才可能花费少，容易被实现。

误区3：软件程序主要由代码组成，因此编码阶段是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的资源。分析：与以前相比，由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，现代软件项目管理的中心发生了转移--不是 着重编码阶段，而是着重系统总体/详细设计阶段。一般说来，在现代软件项目管理中各种资源的合理分配比例是：项目论证、风险评估阶段3%，项目需求分析阶段8%，系统总体/详细设计阶段45%，编码阶段10%，系统测试阶段34%。

误区4：为了便于代码的维护修改，在系统的详细设计阶段文档工作应该做到写出所有程序的伪码。分析：通常伪码的最大作用是对程序的算法流程进行描述，便于人们深入了解程序的功能和实现过程。可见，在一定程度上伪码的确有利于对 程序代码的维护和修改。但是，我们知道为了保证项目文档和程序代码的一一对应关系，维护程序代码的时候同时需要对项目文档进行维护。伪码和程序代码是非常接近的，对伪码进行维护的话，相当于进行了2倍的程序代码维护。工作量是很大的。所以切合实际的方式应该是对一般 的程序文档做到程序流程图即可，对于涉及了较复杂算法的才需要伪码。

误区5：既然在项目人员配置中设置了专门的测试人员，那么软件所有的内部测试工作全部应该由测试人员完成。分析：软件程序测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时 测试人员总是最优先使用“黑盒法”。他们的工作方式往往是先对程序进行“黑盒法”测试；如果测试没有通过，不得已这才考虑对程序代码 进行“白盒法”测试。显然，这种对“白盒法”有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁。如何解决这个问题？一方面需要 提高对测试人员的要求，另一方面也需要程序员完成部分的“白盒法”测试（实际上，程序员往往也是进行“白盒法”测试的最佳人选）。

误区6：软件项目管理只是相关技术部门的事情，与公司其他部门无关。分析：在竞争日益激烈的今天，软件项目规模大、复杂度高而且时间要求紧迫。要想提高公司的软件项目管理水平，这就需要提高公司的整体 参与意

识，需要公司各个部门协同作战。例如需要会计部门协助进行项目预算，财务管理和费用控制；需要研究部门（技术委员会）指派专家 协助进行各种风险评估，提供技术指导；需要后勤部门提供各种保障。

误区7：在开发进度滞后的情况下，可以聘请更多的程序员加入到开发团队中，通过增加人力资源来赶上进度。分析：在注重团队开发的时代，开发方应该根据目前的软件项目管理水平慎重考虑这个做法。如果新加入的程序员对目前软件项目的应用行业 有一定了解，并且可以很快适应了开发方的项目管理方式、软件开发风格、团队协作氛围；那么“新人”的加入是有益的。否则，可能会“好 心好意做坏事”。因为尽管其个人能力很高，但是为了使其与大家一起协同工作，开发团队不得不分出人手对其进行与项目有关的技术/业务培 训，更重要的（也是难度最大的）是还要引导其融入团队。这可能需要花费开发团队许多时间和精力，很有可能使项目进度更慢。

误区8：技术骨干应该成为项目的项目经理，项目经理一定是所有项目成员中薪水最高的。分析：在“软件作坊”时代，这是一种普遍使用而且效果不错的方法；而在“软件工厂”时代，这种方法却带来各种问题，有时甚至直接导致 项目失败。究其原因这主要是因为随着现代软件开发分工的细化，对项目经理的要求也发生了根本的改变--最注重的不是其对某项专业技术 的掌握程度，而是其组织、领导、协调开发团队的能力（当然，可以两者均突出最好）。至于项目经理的薪水问题，这和定薪制度有很大关系。通常，项目经理执行的是管理人员的薪酬体系，而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较高的，但不 一定是最高的。有时候，为了激励技术人员，项目中的技术骨干得到的酬劳比项目经理要高。

误区9：只有项目经理以及部门主管才会关心项目整体进度，程序员只关心自己的开发进度。分析：这是一种“官僚”的想法。实际上程序员作为团队中的一员，他不仅仅是在打一份工，更重要的是在参与一件“作品”的创作。在体味 工作的辛苦的同时，程序员更重要的是要享受创作的快感。项目经理不应该漠视程序员对“成就感”的追求，应该向每一个人详细描述最终“ 作品”将会如何美妙和令人兴奋，并且在到达最终目标的路上设立一系列的里程碑。每当项目整体推进到一个里程碑的时候，项目经理应该把 这个消息告诉每一位项目成员。实际上，这不仅仅可以让所有的项目成员享受到阶段胜利的喜悦，还可以激发大家更大的工作热情，提高工作效率。

误区10：为了保证项目继续，为了留住核心程序员，加薪吧。分析：加薪可以说是很多企业在挽留程序员时所使用的常用方法。这一招可能暂时奏效，不过往往是人留下来了，但副作用也来了--加薪的 人未必见得多干活，没有加薪的人却开始消极怠工了。其实，项目的进行过多地依赖程序员的个人技术是“作坊”时代沿袭下来的“陋习”。既然IT行业人员的流动是无法控制的，现在项目的执行应该更加注重团体的力量，应该更多的考虑公司整体技术水平和核心技术能力。例如形 成公司自己的专家知识库，类/函数库，第三方控件库，拥有自主版权的开发平台等。另外，实际上程序员萌生去意的原因很大程度上不是薪水，而是缺少激励和尊重。这需要项目经理使用“老土”一点的办法，找适当的时机对程序员做一做思想工作，向其描述项目的美好未来，让其 感受关心和尊重。总之，要从多方面着手保证项目的顺利开展，而不是简单地加薪。

如何估算大型项目的工作量

我是一个九人开发团队的领头人。一般来说，我们所从事的是（项目）支持和强化的工作，但是有的时候，我们被要求完成一项大型工作，而这项工作大到肯定可以被作为一个项目来看待。我们所面临的问题是：我们很难估算需要在这些大型项目上所花费的工作量和时间。通常我们对工作量的估算不足，所以搞得在最后几个星期里才拼命加班完成所有的工作。我正在尝试先预估工作量，然后在未来将其翻倍。有没有什么简单的方法能够解决这个问题？——Kurt

回答：

Kurt：在先前的专栏里，我们看到了在估算大型工作的工作量问题上，很多支持人员都是出了名的估算不准者。我们知道，支持工作的很多特点会在支持人员试图估算大型工作的工作量时合起来阻挠他们。好消息是，如果你知道这些陷阱并试着避免它们，而且学会一些基本的估算技巧，那么在估算工作量上你就会做得更好。

估算的技巧

项目的特点之一是，工作和可交付的内容是唯一的。这就意味着对项目的估算也会是唯一的。但是，基本的估算技巧能够帮助你建立一个对项目需要多长时间的初步评估。有一些技巧要依赖于暴力（硬性估算），有一些会利用同其他项目之间的相似性，有一些要依赖数学计算，而有一些要靠其他人的意见。如果有可能的话，你应该使用两种方法，并对比它们（的结果），看它们是否合理和一致。如果这两种估算（的结果）很接近，那么你的估算就是相当准确的。如果它们相差较大，那么你就应该改进估算的方法，并找到不足之处了，或者使用第三种估算方法来尝试获得某种一致性。

对工作结构的分解

进行估算最精确的方法通常是建立一个将工作分解开的结构。这就需要在一个很高的层面描述工作，然后将该工作分解成更小的部分，直到每项活动都能够被估算在80小时以内完成。（或者如果项目比较小的话，就是40个小时。）这通常也需要花费很多时间和精力。但是，如果你非常好地了解了这项工作，而且如果你能够确定所需要的工作都已经包括进了你的工作分解结构里，那么你就常常取得获得一个精确的估算。

以前的经验

尽管所有的项目都是唯一的，但是有些项目同其他的项目非常相象。使用以前的经验这一技巧，你可以找一找以前完成的类似项目，然后根据那个项目实际所需要的工作量来估算你当前的工作。这是一个估算工作量的好方法，因为它允许你使用以前的经验。但是，它要求你以前有一个类似的项目，而且你必须具有对那个项目实际工作量的准确计算。例如，假设你正在将你的财务软件升级为一个新的版本。如果这是你第一次完成一个新的版本，你就没有以前的经验。但是，如果你以前进行过软件的升级工作，你就应该非常了解这次升级需要什么。即使这个项目是唯一的，它也和以前所做过的工作非常类似。

类比／比率

类比技巧和以前的经验非常类似。但是，你不需要具有先前的项目作为比较对象，而是寻找具有类似特点的项目。例如，让我们还是来看一下前面升级财务软件的例子吧。如果你以前从来没有对进行过升级，那么你就不知道这个项目会花多长时间。但是，你也许的确具有升级应收帐款（Accounts Receivable）软件包的经验。尽管这两项工作不相同，但是它们很类似。知道了升级应收帐款软件所花费的工作量和时间，会有助于你估算财务软件升级所需要的工作量和时间。

根据比率来估算是类似的，不同的是，你要考虑当前项目同以前的项目相比而言的大小。一个很简单的例子是，你以前可能在四个地区办事处里安装过一个新的财务软件。现在你被要求将同样的软件包安装到另外两个办事处里。如果所有的条件都相同的话，在新项目（两个办事处）上所花费的工作量将是前一个项目（四个办事处）所需工作量的一半，这样考虑是理所当然的。

专家的意见

即使你以前没有进行过这样的项目，其他人可能经历过。找一找内部或者外部的专家，看看他们是否能够用其以往的经验来指导你进行估算。例如，如果你必须部署一项新技术，你可以找一个研究分析师，请他来帮助你估算所需工作量的水平。

参数造型

要使用参数造型（parametric modeling）这一技巧，工作中就必须存在一个模式，这样的话对一个或者多个基本部分的估算就能够被用来推动整体的估算。例如，如果你必须在40个分支办事处里部署一个财务软件，那么你就可以（分别）估算大型、中型和小型办事处所需要的典型时间和工作量。然后，将你的40个办事处按照大型、中型和小型来分组。最后，通过计算来估算整个项目的时间和工作量。

事实上，你的提问就是这个技巧的另一个天然例子。你说你会将你团队成员所估算的工作量翻倍。由于这里使用了某种算法，所以也可以被当作参数造型技巧。

概要

Kurt，你的问题是一个我碰到过很多次的问题。支持人员在估算大型项目时所碰到问题一部分与文化相关，一部分与技术相关。首先，他们通常的工作文化是迅速地辨别和解决问题。这就使他们养成了一种短期的思想，当他们需要在一个更长的尺度内对工作进行筹划和估算的时候，这种思想并不总是能够很好地转变过来。

其次，这里可能有一个技术鸿沟。要跨越这一鸿沟，你需要将我在这里描述的估算技巧介绍给你的人员。这些技巧可能会促使你使用自己公司已有的技术和资源来估算大型工作的工作量，从而使估算工作更加容易一些。在得到你人员的估算并将其翻倍以前，看看这两个方面。如果你能够将他们培训成为更好的评估者，你在未来会获得更加准确的估算。

如何计算项目的投资收益率

jeanne说：

老师说：考试中经常会考计算项目的投资收益率，如何计算项目的投资收益率？

钟鼓楼回答：

我也是现学现卖，不对的地方，请大家指教。

项目投资的主要决策指标有三个：净现值（NPV）、内部收益率（IRR）和盈利指数（PI）。

▲ 净现值是将项目在计算期内各年的净现金流量（即现金流入减去现金流出），以行业投资的