[摘要]
医疗保险管理信息系统涉及到医保管理部门、各定点结算点（医院、药店）、开发商，加之政策多变、业务不成熟，需求变化频繁，开发的难度和风险较大。在某市医保管理信息系统开发过程中，我作为用户方的项目负责人参与了项目的整体管理工作，我在项目整体管理中采取了针对性的措施，加强了参与各方的沟通，注重用户需求和需求的变化，合理配置项目组成员，对风险进行了及时的评估并顺利地控制了风险。通过这些办法，平衡了各方的利益，控制了项目的范围和进度，保证了项目的质量，顺利完成了这个项目。
[正文]
几年前，某市为实施城镇职工基本医疗保险，开发了一套医保管理信息系统，我作为用户方项目负责人，参与了项目管理、系统分析和编程的部分工作。
这个系统的功能包含了基金征集和支付管理、参保单位（职工）管理、定点结算点管理、参保职工就诊结算管理、IC卡管理等，目标管理人数为30万、定点结算点200个，计划投资400万元；采用C/S结构，数据集中保存在市医保中心，定点结算点与医保中心之间数据实时交换。
通过公开招标，明确了项目的范围、时间、成本和采购，因此，我把整体管理工作的重点放在了项目的质量、人力资源、沟通和风险管理管理，目的是保证实现计划的功能并按时投入运行。在工作中，我根据实际情况，采用了灵活的工作方法，取得了较好的效果。
该系统在04年一次上线运行成功，目前运行情况良好。
一、加强了沟通管理。
该项目涉及到医保中心、参保单位、定点结算点、系统开发（集成）商等多个单位，从需求分析到系统设计、测试都要各方参与、协调配合，由于各方的地理位置十分分散，难以经常或长期集中，因此，各方及时有效的沟通是项目成功的必要条件。为解决好这个问题，我采取了三个办法：
1、提高大家对沟通作用的认识，特别是各方主要领导人对沟通的必要性和重要性的认识，从而对沟通工作给予必需的人员、经费和时间支持，保证了沟通工作得以按计划进行。
2、对项目组外部的沟通，坚持从实际出发，采用多种沟通的方式。一方面，把必要的、重要的沟通需要以联席会议、工作计划、总 工作得以按计划进行。
2、对项目组外部的沟通，坚持从实际出发，采用多种沟通的方式。一方面，把必要的、重要的沟通需要以联席会议、工作计划、总结报告的形式制度化。另一方面，在适用的前提下，采用灵活、经济的沟通方式，比如：对一般的小问题或者是简单问题进行电话交流，复杂一点的问题开碰头会，需要后续解决的、比较重要的及涉及面较大的问题要形成书面的会议记要，有必要的情况下要由相关单位加盖公章确认。
3、对项目组内部沟通，进行适当的控制，避免形式主义，在保证效果的前提下节省时间，提高工作效率。规定项目组成员在每天工作过程遇到问题，将其记录下来，然后在以邮件方式发送给需要沟通或者询问者。大家每天下班之前收取邮件，对于可以直接回答的问题则直接以邮件方式回复，对于无法直接答复而只需与提出问题者讨论的问题，在第二天上班前进行商议确定。而需要众人一起讨论的问题，则放到每周会议上讨论，较紧急的问题召开临时性会议。通过以上方法，基本上实现了有关各方及项目组内部的有效沟通，及时发现问题、解决问题，避免了因各方立场不一致造成严重对立而影响项目进度，避免了因交流不畅形成重大质量问题。
二、合理配置人员。
对项目组人员进行规划配置，合理分工，明确责任，保证项目各阶段、各方面的工作能够按计划完成。我们在项目组长配置了以下人员：技术组长一名，负责技术难题攻关，组间沟通协调；需求人员5名，负责将用户需求转换成项目内的功能需求和非功能需求，编制项目需求规格说明书，针对每个迭代集成版本与用户交流获取需求的细化；设计人员5名，负责对需求规格说明书，进行系统设计；开发人员8名，实现设计，完成用户功能；集成人员1名，负责整套系统的编译集成，督促小组系统功能提交，及时发现各模块集成问题，起到各小组之间的沟通的纽带；测试人员2名，对于集成人员集成的版本进行测试，尽可能的发现程序缺陷，以及未满足需求的设计；文档整理人员1名，负责对小组内产生文档的整合，统一；维护人员1名，系统验收后，维护人员，建议维护人员早期进入项目参与项目测试以便顺利承担起项目维护职责。
在人员的管理方面，一方面要求项目组成员相对稳定，以保证开发工作的连续性，另一方面，不搞终身制，不能够胜任职工作的坚决调换，保证项目整体工作不受影响。通过平常和阶段性的工作考核、评审，对不合格人员进行调换。有一名需求分析人员因为工作态度不好，与客户单位业务人员关系恶化，调查落实后，我们立即把他调出项目组。
三、进行风险评估，在进度和质量之间进行权衡，争取最佳平衡点。
由于项目资金已经确定，我就在进度和质量之间找平衡点，力争把风险降到最低。由于医疗保险业务本身比较复杂，加之当时国家政策不稳定，业务流程不是很规范，系统需求也在不断调整、完善，给项目的进度带来一定影响。由于这个项目涉及到十余万参保职工的医疗待遇，影响很大，通过与用户方领导沟通，决定不搞“形象工程”，在质量和进度之间优先考虑质量。同时，考虑到这个项目的采用了增量开发模型和模块化的设计方法，我把项目目标进行了分解，涉及到业务经办的部分优先完成，保证系统在规定的时间上线运行，其它不影响业务经办的、辅助性的功能适当延期，包括医疗监督、统计分析和部分报表。这样虽然整体工期有所延长，但没有影响系统及时上线。这种做法同时照顾到各方的利益，把整体风险降到了最低。
摘要
风险就是会给项目带来威胁或机会的一些不确定性事件．2003年5月，我参与了某机场信息系统集成项目的建设，并担任项目经理工作。整个项目总投资近亿元，建设工期为3年．因为信息系统集成在当时的国内民航系统来说，还是新兴技术，熟悉民航业务和信息集成技术的专家和技术人员很少，加上项目投资规模大、建设周期长，因此，该项目的风险很大。
为了按照既定的进度、成本和质量完成项目的目标，在该项目中，我充分重视了风险管理，根据风险管理理论，结合自己的项目实践，按照风险管理计划编制、风险识别、风险分析、风险应对计划编制、风险监控等过程，有条不紊地进行风险管理．加之进行了良好的配置管理，整个项目建设过程中，始终遵循了变更控制程序，使该项目顺利完成了其目标．2006年3月，该项目建设完成，并在机场开通时投入生产运行，目前运行稳定．
正文
项目是在复杂的自然和社会环境中进行的，受众多因素的影响．对于这些内外因素，项目管理人员往往认识不足或者没有足够的力量加以控制．项目的过程和结果常常出乎人们的意料，有时不但未达到项目主体预期的目的，反而使其蒙受各种各样的损失，而有时又会给他们带来很好的机会。项目同其他经济活动一样带有风险．要避免和减少损失，将威胁化为机会，我们就必须了解和掌握项目风险的来源、性质和发生规律，进而实行有效的管理．
项目风险是一种不确定的事件或条件，一旦发生，会对项目目标产生某种正面或负面的影响．风险有其成因，同时，如果风险发生，也导致某种后果．当事件、活动或项目有损失或收益与之相联系，涉及到某种或然性或不确定性和涉及到某种选择时，才称为有风险．以上三条，每一个都是风险定义的必要条件，不是充分条件．具有不确定性的事件不一定是风险．
2003年5月，我所在的单位承接了双机场的机场信息系统集成项目的建设工作．该项目是国家重点建设工程项目的一个子项目，其主要工作是应用EAI框架，集成机场内其它各个重要信息系统，实现数据共享，整个项目总投资近亿元，建设工期3年．2006年3月，该项目建设完成，并在机场开通时投入生产运行，该信息系统集成项目以ORACLE 9i为平台，建立了一个可存储机场航班信息、管理信息和运营信息的综合中心数据库，开发了航班信息管理系统、机位自动分配系统、外场管理系统、机场资源管理综合系统等，构造了千兆以太网统一的网络平台，采用了EAI框架集成了这些新开发的系统外，还集成了机场内其它各个重要信息系统如航班信息显示系统、离港系统、广播系统等，连接机场外的许多相关系统如空管飞行信息系统、财务系统、航空运营系统等，实现不同应用操作平台的集成、异构数据库的集成，达到数据共享，应用集成。在该项目中，我担任项目管理工作．
到2003年为止，我虽然已经负责了近10个项目的开发和管理工作，但当时被安排担任该项目的项目经理时，感觉确实是一大挑战．因为信息系统集成在当时（2003年）的国内民航系统来说，还是新兴技术，熟悉民航业务和信息集成技术的专家和技术人员毕竟很少，因此，这种项目的风险很大。为了按照既定的进度、成本和质量，完成项目的目标，在该项目中，我充分重视了风险管理，按照项目风险管理理论，结合自己的项目实践，有条不紊地完成了该项目．具体来说，我是按照以下基本的管理过程来进行风险管理的。
1.风险管理计划编制
在项目初期，我组织有关人员编制了风险管理计划，具体描述如何为该项目处理和执行风险管理活动．我们采用会议的方法来制定风险计划的，因为该项目投资规模比较大，所有的项目干系人代表都被邀请参加了风险管理计划会议，全面地考虑了风险对项目的影响，制订充分的风险管理计划。
在计划中，我们确定了基本的风险管理活动（如每15天召开一次风险评估会议），根据项目管理理论和我公司的项目实践，定义了项目中的风险管理过程，估计了风险管理的时间表和费用，并把风险管理活动纳入了项目计划，把风险管理费用纳入了成本费用计划。
2.风险识别
根据项目的实际情况，我们把项目中的风险划分为技术风险、团队风险、外部风险三大类，采用风险分解结构（RBS）形式列举了已知的风险，如图1 所示。
在识别了上述风险后，我们还确定了这些风险的基本特性，引起这些风险的主要因素，以及可能会影响项目的方面，形成了详细的风险列表记录．根据试题的需要，在这里我只列出引起风险的主要因素，其他的方面限于时间和篇幅，不再介绍．
风险名称
引起风险的主要因素
对工作的分析和评估不足
缺乏类似的项目管理管理经验，对项目工作不熟悉
对EAI 架构不熟
行业内没有使用先例
关键人员流动
项目周期长，需要长期出差
缺乏合适的技术人员
项目周期长，异地开发
没有正确理解业务问题
项目干系人对业务的认识不足、信息化水平低
预算不能按时到位
甲方资金受限
3．风险定性分析
我们根据风险管理计划中的定义，确定每一个风险的发生可能性，并记录下来．除了风险发生的可能性，还分析了风险对项目的影响，包括对时间、成本、范围等各方面的影响．其中不仅仅包括对项目的负面影响，还分析了风险带来的机会。
在这个过程中，我们还是采用会议的方式来进行的．不过，在风险分析的会议中，除了有关项目干系人外，我们还邀请了相关领域的专家参加，以提高分析结果的准确性。例如，对于技术类风险的分析，我们就邀请了业内著名的架构专家参与评估。在确定了风险的可能性和影响后，接下来需要进一步确定风险的优先级。风险优先级是一个综合的指标，其高低反映了风险对项目的综合影响．我们采用了风险优先级矩阵来评定风险优先级的．最后得出的结果是架构风险排在第一位，该风险的可能性很高，影响也很大。
4．定量风险分析
对已知风险进行定性分析后，我们还进行了定量分析，定量地分析了各风险对项目目标的影响．在这个过程中，我们采用了专家评估的方法，组织相关成员对项目进行乐观、中性和悲观估计，同时，也利用了我公司历史项目的数据，用来辅助评估．进行定量分析之后，更新了风险记录列表．
5．风险应对计划编制
根据定性和定量分析的结果，我们对已识别的风险，制订了应对计划。对不同的风险，采取了不同的措施．风险名称
应对措施
对工作的分析和评估不足
利用已有经验，加强学习，利用标准的技术和理论
对EAI 架构不熟
聘请EAI专家做技术顾问，加强对有关人员进行架构培训
关键人员流动
紧密团结“少数人”，提高顶目完成奖金，实行人才备份制
缺乏合适的技术人员
在当地招聘部分技术人员，加强制度建设，加强培训
没有正确理解业务问题
加强对机场人员的培训，提高其信息化水平
预算不能按时到位
在合同中明确规定，由此引起的后果由甲方负责
6．风险监控
经过上述5个过程后，该项目中的风险已经比较清晰，这时就要进入风险跟踪与监控过程．在这个过程中，我们对已经识别出的风险的状态进行跟踪，监控风险发生标志，更深入地分析已经识别出的风险，继续识别项目中新出现的风险，复审风险应对策略的执行情况和效果。根据目前风险监控的结果修改风险应对策略，根据新识别出的风险进行分析并制定新的风险应对措施．
在这个过程中，我们主要采用了偏差分析、项目绩效分析和监控会议的方式来进行的。
总之，该机场项目由于技术领先、投资规模大、建设周期长、异地开发等原因，充满着风险，但由于我们＋分重视项目的风险管理，加之进行了良好的配置管理，整个项目建设过程中，始终遵循了变更控制程序，使该项目顺利完成了其目标．2006年3月，该项目建设完成，并在机场开通时投入生产运行，目前运行稳定，得到了机场方的肯定，由此，我得到了公司董事会的嘉奖．
目前，电子政务、企业管理信息化等已成为信息化建设的热点。这些以业务、数据流程信息化为主的建设项目相当复杂。有数据表明，这类信息化建设项目在国内外成功的比例都不是很高。正因如此，项目管理引起这个行业人士的普遍关注。同样，也有数据表明，西方国家的一些企业采用项目管理后，项目成功的比例有显著提高。
作者根据十多年项目管理实践经验，以及研究、培训和咨询的知识积累写就这篇文章，相信对信息化工程项目的建设者会有帮助。
本文涉及信息化建设项目管理的内容包括：项目经过的阶段；项目的计划、实施和控制；开发商对项目的管理；用户对项目的管理；项目的组织问题等。
信息化建设项目按时序划分，一般经过可行性研究、系统分析、系统设计、开发和测试、安装调试、运行维护6个阶段。
1、可行性研究阶段
可行性研究阶段段的主要任务是：识别需求，对项目产品进行描述，确定分阶段实施的进度，从业务、技术、经济效益等方面进行可行性研究，形成可行性报告。
2、系统分析阶段
系统分析阶段的任务是：对现行系统进行详细调查，分析业务流程，分析数据与数据流程，分析功能与数据之间的关系。指出现行系统存在的问题和不足之处，确立新系统的基本目标和逻辑功能要求，最后提出分析处理方式和新系统的逻辑模型。这个阶段也称为逻辑设计阶段。逻辑设计解决系统“做什么”的问题。因此，这个阶段是整个系统建设的关键阶段。
系统分析阶段的工作成果为“系统说明书”，这是系统建设的必备文件。系统说明书既要准确又要通俗易懂，用户根据系统说明书可以了解未来系统的功能，判断是不是他们所要求的系统。
“系统说明书”一经通过，就是系统设计的依据，也是将来评价和验收系统的依据。
3、系统设计阶段
系统分析阶段的任务概括地讲，已解决了系统“做什么”的问题，系统设计阶段要回答的问题则是系统“怎么做”。也就是说，根据系统说明书所规定的功能要求，考虑实际情况，具体设计实现逻辑模型的技术方案，即新系统的物理模型。这个阶段也称为物理设计阶段。这个阶段又可分成总体设计和详细设计两个阶段。
这个阶段的技术文档为“系统设计说明书”
4、开发和测试阶段
开发和测试阶段是按物理设计方案付诸系统实现的具体工作，包括开发与调试程序，采购硬件。
这个阶段的工作量很大。在这个阶段，开发工作要重视文档的建设，测试工作需要写出测试分析报告，包括功能“测试分析报告”和“系统测试分析报告”。
5、安装调试阶段
本阶段的工作包括：硬件设备与软件平台的安装调试，用户培训，数据文件转换，系统调试与转换等。
安装调试阶段实现现有系统被新系统所替换，需要用户许多部门的参与或配合。为了使系统顺利转换，必须精心安排，合理组织，统筹调度和协调。
6、运行维护阶段
系统投入运行后，需要进行经常性维护和评价，记录系统运行的情况，根据一定的程序对系统进行必要的修改，评价系统的工作质量和经济效益。
上述6个阶段，构成信息化建设项目的全（整个）生命周期。
根据美国项目管理知识体系指南（PMBOK）的定义：项目生命周期开始于项目启动（例如签订承包合同），结束于项目收尾（例如按合同验收）。因此，信息化建设项目生命周期包括系统分析、系统设计、开发和测试、安装调试这4个阶段。参见下图。
本文第二部分内容——项目计划、实施和控制，是基于项目生命周期来考虑的。由于项目管理其实是一种方法论，因此可行性研究阶段的工作也可以按本文第二部分介绍的方法来处理。
1、整体计划
整体计划的核心内容包括：范围计划、时间计划、成本计划和组织计划。
1）范围计划
项目范围由工作分解结构（WBS）界定。工作分解是一种以结果为导向的分析方法，用于分析项目所涉及的工作。工作分解结构中所包含的全部工作构成了项目的整个范围。工作分解结构是项目管理的一个非常基础性文件，因为它是计划和管理项目进度、成本和变更的基础。项目管理专家认为，没有包含在WBS中的工作是不应该做的。
信息系统建设项目的工作分解结构，第一层通常是由前面所述的项目生命周期的4个阶段组成，第二层则包括每个阶段需要完成的可交付成果，第三层包括第二层可交付成果进一步分解的结果——所有细化的可交付成果，…。
工作分解结构层次的多少，以便于管理为划分标准。相同的项目，不同的人会做出不同的工作分解结构来。工作分解结构最底层的可交付成果叫做工作包。
2）时间计划
时间计划是确定工作分解结构中每个可交付成果的开始和结束时间。时间计划通常用表格或甘特图、里程碑图来表示。网络计划技术中的关键路径分析、并行工程等技术方法，可用来优化时间计划安排。由于有项目管理软件的支持，生成时间计划图表，以及用网络计划技术优化时间安排都变得十分地容易。
3）成本计划
① 制订资源计划资源计划确定了为完成项目中各活动所需要的资源（人、设备、材料）。WBS是项目资源计划最基本的输入。
② 成本估算成本估算是利用WBS、资源需求、资源单价、活动历时估计等成本要素，通过有关算法与工具（项目管理软件或电子表格）算出完成项目所需各种资源的成本估计值。
③ 成本预算成本预算是为了确定测量项目实际绩效的基准计划，而把整个成本估算分配到由WBS确定的各工作包上去。成本预算和成本估算通常是同步进行的。
④ 成本基准计划成本基准计划是一种按时间分段的预算，可以用来测量和监控项目成本的绩效。按时段把估算的成本叠加起来即可求得成本基准计划。
4）组织计划组织计划是，利用责任矩阵确定WBS中各工作项的责任单位；利用组织图确定报告关系。但是，组织计划结果的具体形式受企事业单位的组织结构制约。（关于项目的组织问题，在本文第五部分解析）。
2、项目实施
项目实施总是一个阶段接一个阶段地进行的，前一个阶段的结果为下一阶段提供输入。信息化建设项目中，第一阶段的结果“系统说明书”，为第二阶段系统设计提供输入；第二阶段的结果“系统设计说明书”，为第三阶段的开发工作提供输入…。
每个阶段实施工作也都要首先做个计划，这个计划是为完成WBS工作包而采取的行动计划，包括：基于各项活动的基准进度计划，角色、职责分配计划。类似于前面讲到的组织计划，角色、职责分配也利用了责任矩阵这种方法，只不过在这里是把职责分配到个人。
项目子产品、产品实际上产生于项目实施过程中。
3、项目控制
项目控制包括绩效控制和变更控制
1）绩效控制
绩效控制目的是使工作结果与计划保持一致。
上面讲到，项目子产品、产品产生于项目实施过程，因此在这个过程中必须持续测量相对于项目基准计划的绩效，以便将实际绩效和基准计划进行比较，并以此为基础采取相应的纠正措施。
测量绩效的方法主要有两种，一是挣值测量，一是进度跟踪。而且，这两种方法通常是结合起来使用。
① 挣值测量
挣值测量在西方国家是测量绩效最常用的方法。它综合了范围、成本和进度测量，帮助项目管理队伍评价项目绩效。挣值测量涉及三个关键值：l 计划值（PV）：在规定时间内花费的获得批准的成本预算部分l 实际成本（AC）：在规定时间内完成工作发生的实际成本l 挣值（EV）：在规定时间内实际完成工作的价值不难看出上述三个关键值是三个关于时间的函数。由于函数曲线呈S形状，所以通常称之为S曲线图。
这三个值提供了评价工作绩效的测量尺度。包括l 进度偏差（SV）：SV=EV-PV l 成本偏差（CV）：CV=EV-AC l 进度绩效指数（SPI）：SPI=EV/PV l 成本绩效指数（CPI）：CPI=EV/AC
② 进度跟踪
进度跟踪是输入实际工作进度，然后与基准进度计划比较，找出各项活动进度上存在的偏差。利用项目管理软件进行进度跟踪极为方便、有效。
有了绩效测量结果，接着便是对偏差原因进行分析，进而根据分析结果决定纠正措施。纠正措施没有什么新东西，都是平时习以为常的一些方法，比如对进度偏差有赶工、快速跟进（有些书上叫做并行工程）等措施。理论著作上对这些方法的外延问题讲得很多，原因是在采取这些措施时，要考虑可能带来的许多问题，但这些都不是本文所要描述的内容了。
2）变更控制
变更控制的目的是维护绩效测量基准的完整性。也就是说对基准计划的变更予以控制。
基准计划变更包括：范围基准计划变更，时间基准计划变更和成本基准计划变更。一般说来，只有项目范围变更才会影响测量基准。但是，在某些情况下，进度延误或成本偏差非常严重，需要“重新确定基准计划”才能提供测量进度或成本执行情况的切合实际的数据。
基准计划变更是很慎重的事，应该：l 建立正式的变更程序l 由变更控制领导小组负责批准或否决变更申请l 定义正式文档变更的步骤
前面已经讲了，一般情况下只有范围变更才会影响测量基准。而在信息化建设这样的高科技项目中，范围变更往往是因技术（功能、性能）要求的变化而起。项目管理中讲到的配置管理，讲的是项目过程中的技术管理问题。
配置管理内容包括：l 识别工作项或系统的物理特征和功能特征l 控制这些特征的任何变更l 记录和报告这些变更l 审计这些工作项和系统以证实其与需求相一致。
进行配置管理的目的是，项目过程中任何技术上的变更都要在范围变更中反映出来，并要得到有关各方的一致认可。
无疑，开发商是信息化建设项目中的主角。对项目计划、实施和控制方面的工作，开发商都需要重视。
计划方面信息化建设项目往往带有较多的创新成份和不确定性，项目成果在出来之前，并不确切知道它会是什么样子。因此，用户的需求和任务目标在整体计划中都不容易表述得十分具体，特别是对要实现的功能的规定往往有相当程度的灵活余地。
由于这些原因，整体计划中的工作范围、完成各项工作（由WBS定义）所需的时间和费用都较难以准确估计，所以整体计划工作必定是一个反复修改的过程。实际工作中，人们往往因为“计划赶不上变化”而不愿做计划或只做一个大致的计划。专家认为，项目管理的首要任务是计划！计划！还是计划！先哲说：“凡事预则立，不预则废”。因此，尽管信息化建设项目中存在诸多变数，但细致的整体计划工作是必须要做的。
实施方面项目实施过程中，项目管理队伍必须协调、管理存在于项目中的各种技术和组织接口（界面）。对于信息化建设项目，在系统设计与开发、测试阶段，对各种技术接口的管理极为重要。而在系统分析与安装调试阶段，协调组织界面是项目管理队伍的重点工作。
实施过程中，项目队伍成员必须按计划做事！
比较我们与西方人做事的习惯不难发现，西方人总是按文档（当然首推计划）规定去做事，而我们做事主观随意性较大。应该学习和接受西方人的做事习惯！
控制方面挣值测量作为一种项目监控工具在我国使用得不多。主要原因是我们的项目管理者粗放式管理惯了，不习惯于做较精细的管理工作。当然，在信息化建设这类高科技项目的管理工作中，对工作量完成百分比做比较准确的估计（这是使用挣值测量法的前提）有些困难，也是人们不愿使用这种工具的一个原因。但笔者的体会是：对工作量完成情况做个百分比估计，比不做要好；对于类似项目第二次做时，对许多工作完成情况的估计还是有较好的置信度的。
变更控制可能是信息化建设项目中最需要但又是最困难的事。范围无止境的蔓延常常是让开发商苦不堪言。控制范围蔓延涉及到许多方面的因素，这里不一一讨论了。
在项目生命周期内，用户对项目的管理主要在进度控制、范围核实、质量把关等方面。由于通常是采用固定总价合同把项目承包给开发商，因此对成本的控制不是用户主要考虑的问题（当然，非固定总价合同情况除外）。而对范围、进度、质量等方面的管理是基于同样的标准的，即是说项目所有的技术和管理文档以及任何变更后的版本，都是开发商和用户达成一致意见后形成的。
在项目生命周期内，用户项目队伍重在参与。在系统分析阶段，没有用户项目队伍的重要参与就不可能产生好的“系统说明书”，也就不可能有好的项目成果。在安装调试阶段，没有用户项目管理队伍的协调、调度，转换工作就可能陷于混乱状态。在系统设计与开发、测试阶段，用户应着眼于未来的运行维护，派技术人员全程参与工作，其必要性有二：一是未来系统运行维护的重要责任，要求技术人员必须深度了解系统的技术情况；一是系统将来必然会不断升级，要求技术人员能够为升级方案做重要贡献。系统维护人员是了解公司业务的技术专家，不可等同于一般维护人员，也不同于一般网管人员，这点应引起用户的重视。
有些情况下，用户可以雇佣项目监理来协助自己完成项目工作。特别是项目启动前的可行性论证阶段，用户对怎样实现信息化或什么样的信息化解决方案对自己是实用的，可能并不很清楚，这时购买项目监理或咨询公司的服务是很有效的。在项目生命周期内的各阶段，从职能上说，项目监理与项目管理是差不多的。
对于信息化建设项目，多数开发商、用户单位的内部组织都是传统型（职能型）的，即组织的结构是按职能划分的。在这种结构体系里，对项目的组织往往是非正式的（用户方面更是如此）。所谓的项目经理一般也就是部门内部一个领头干活的人。而另一个极端的现象是，当认为某个项目很重要时，就可能由高层人物来负责这个项目。在一些媒体甚至某些高等教育教材中，我们都能看到有这样的说法：信息化很重要，信息化建设工作应该由一把手亲自抓。
对信息化建设的项目管理工作，由一个领头干活的人负责显然不行，但由一把手亲自抓的观点，也非常值得商榷。
本文开头提过，信息建设工作是很复杂的事情。“复杂”体现在两个方面：一是把业务流程、规范、标准等搞清楚，并据此确定要建一个什么样的系统很复杂；一是技术实现上复杂。负责信息化建设的项目经理，应有这两方面的知识与经验。从开发商方面看，该项目经理应有很好的技术背景，同时要熟悉所服务行业的业务情况；从用户方面看，这个项目经理应非常清楚本单位的业务流程，同时对技术有一定的掌握。
一把手是企业战略层面上的管理者，很难要求他管好信息化建设这样具体而复杂的项目。
保证信息化建设项目的顺利进行，应从组织结构上着手。
矩阵型组织（参见下图）是西方国家许多企业采用的一种项目组织类型。
在这种组织结构里，职能部门经理承担职能性职责，项目经理承担项目职责。所谓扁平化管理指的也是这个意思。
从图中不难看出，项目经理需要在全公司内整合资源来完成项目工作。要做到这点，首先应赋予项目经理必要的权力。高层经理应充分认识到，负责=职责+职权。上图显示出，项目经理和职能经理的权力是平行的。要重视信息化项目建设工作，高层管理者在职能经理与项目经理的权力平衡中就应更倾向于项目经理一边。
这里应该强调的是，矩阵型组织是一种现代型组织结构，重视这种组织结构应用，其意义不仅仅局限在信息化建设过程中，对处在产品或服务转型期的各行业来说，都有重要的现实意义。
结束语
本文阐述了信息化建设中的项目管理。然而，在当今信息化社会里各行业都应重视项目管理。
时代的变化已越来越快。产品生命周期短了，一种型号的产品推出后，很快就被功能更强、性能更好的产品所取代；对服务的要求更高了，与时俱进的人性化、个性化服务是不断摆在人们面前的课题。创新已是这个时代出现频度很高的一个关键词。产品创新需要立项，服务创新也是项目。项目的概念已超越了我们对它的传统认识。因此，我们不仅要在信息化建设中重视项目管理工作，还需要在广泛的社会领域中重视项目管理。
[摘要]
2004年6月，我作为项目经理开始参与某航空公司航空票务系统项目的开发，主要负责系统的组织规划实施开发与项目管理，该系统具有严格的安全，稳定，时实高效和可靠性能要求，该系统由票务管理系统和呼叫中心系统两部分组成，呼叫中心系统主要实现电话，传真和短信业务，票务管理系统是整个系统的核心，采用了struts+hibernate+spring主流WEB应用框架，实现了WEB应用服务器websphere与协作应用服务器lotus domino 的高度集成.
项目的成功很大程度上归功于我在项目过程中各阶段对进度的有效管理和控制，本文以该项目为例，结合作者实践，讨论信息系统项目中的进度管理问题 ，主要通过在计划阶段做好工作量估算，在项目的全过程中有效管理和控制风险因素，在实施阶段进行进度跟踪和控制，必要是调整进度表等方法和策略来有效管理和控制项目的进度，目前该系统已正式投入运行，状况良好受到客户一致好评.
[正文]
2004年6月，2004年6月，我作为项目经理开始参与某航空公司航空票务系统项目的开发，主要负责系统的组织规划实施开发与项目管理，当然还做一些编码工作，主要是公用基础代码和核心代码的编写与维护。航空票务系统是将呼叫中心系统和票务管理系统有效的结合起来，采用先进的ＣＴＩ技术和语音板卡技术，充分利用电话，短信，传真，因特网等信息化手段，解决航空公司的机票销售问题，规范了业务流程，强化了内部管理，与电子商务的完美结合，使应用系统功能更加完善，提高了整个航空业务的工作效率。 其中，票务管理系统包括：客户管理，机票管理，票证管理，销售管理，财务结算，调度管理，远程营业部（代理商／分销商）管理 ，系统管理八大功能模块，并统一于服务器端软件模块。呼叫中心系统由电话呼叫系统，短信分发系统，传真呼叫系统三部分组成。票务管理系统是整个系统的核心，在本次开发中，我把它视为整个项目的重点。
票务管理系统采用struts＋hibernate＋spring主流ＷＥＢ应用框架，使用ＲＵＰ软件工程方法，开发工具采用了ＷＳＡＤ５.０，ＷＳＡＤ５.０集成并扩展了Ｅclipse２.０的功能。硬件配置方面，ＩＢＭＲＳ／６０００用于安装websphere５.０，DELL服务器用于安装DOMINO R6和ORACLE 10g数据库，系统平台采用WINDOWS NT 实现了WEB应用服务器与协作应用程序服务器LOTUS DOMINO 的高度集成，并使用SINGLE SIGN ON （SSO）实现单点登陆。总体架构思想：用spring搭建整个框架，用hibernate取代原始的JDBC操作，并进行持久化管理，在spring 中采用Bean来管理整个持久化层和访问层，与hibernate 相连接进行数据库操作，视图层和控制器层通过STRUTS筐架实现，模型层是数据访问层DAO 和 hibernate的结合，数据库层功能使用ORACLE 数据库实现。在本系统中将订单数据的生成分析采用关系数据库实现，通过webspher架构实现业务逻辑处理，机票订单的生成和审核流程则由DOMINO 进行驱动，将基于业务为主的J2EE服务系统和基于协作为主的DOMINO 流程处理系统有效的结合起来，确保整个业务流程的有效运行和各种数据查询分析统计的有机结合。
由于考虑到寒假和春运期间将会是旅客的高峰期，客户要求系统必须在12月底前交付，项目开发周期为6个月，为此我做了如下安排：前4个月主要集中精力用于开发票务管理系统，后两个月主要完成票务管理系统和呼叫中心系统的集成以及项目收尾工作。
软件的进度管理是软件项目管理中一个非常重要的组成部分，进度管理的目的是通过执行项目进度管理过程和使用一些基本的项目管理工具和技术来控制项目的进度，保证项目如期完成。项目组整体上把按进度和预算交付项目作为我们最大的挑战，因此我十分重视项目进度的管理和控制，在本项目中我们借助项目管理软件Microsoft Project 2003来辅助进度和成本的计划与管理，我们主要通过在计划阶段做好工作量估算，在项目的全过程中有效管理和控制风险因素，在实施阶段进行进度跟踪和控制，必要是调整进度表等方法和策略来有效管理和控制项目的进度。
1. 计划阶段做好活动历时（工作量）估算.
项目需求分析阶段结束，《软件需求说明书》得到客户的正式签字确认后， 我们开始创建工作分解结构WBS和制定详细的进度表，我们认为工作量的估算是制定进度表的基础，对于项目的进度管理十分关键，由于我们对代码行（LOC）估算和功能点（FP）估算等估算方法研究不是很深入，工作量的估算还是主要采用基于公司项目历史绩效数据库和个人经验的估算方法，对于部分涉及流程的活动单位一般很难一次性把握其活动历时，事实上流程调试的工作量一般在页面基本功能（增加/删除/修改）的3倍工作量以上，例如销售模块—机票预定—顶单生成流程页面提交工作量为2日/人，而流程调试要涉及20多个角色和8条路径，对于把握不是很好的估算，我们一般通过一个乐观估算A，一个悲观估算B，一个正常估算M三次估算后利用PERT公式[1（4*M+A+B）/6]计算后取整，每项活动我都先确定具体的人员，然后需要对活动本身进行详细的分析，必要时查看公司项目历史绩效数据库，最后需要为各项活动建立依赖关系，明确各项活动的前置任务，活动的开始时间，结束时间。总体上讲活动历时的估算工作量较大，我花了数个工作日.
项目组流动率较底，在J2EE和STRUTS架构下的WEB应用开发已有一定的项目积累和团队合作基础，如项目组自行开发了功能完善的STRUTS-CONFIG..XML统一维护工具，实现了FormBean和AcationBean的方便管理，有大量可供复用的东西，如公用基础代码，权限管理模块等，这些也是我们在工作量估算中应该考虑的因素.
2. 项目全过程有效管理和控制风险因素.
项目中我们对项目进行了必要的风险管理，以避免风险时间的发生导致进度的失控，公司项目管理部门提供了完整的项目风险管理计划模板和风险时间列表模板，为了让项目组在项目各个阶段保持良好的风险意识，我尝试采用了“十大风险事项跟踪”，把项目中各主要的风险时间按照排名张贴在公告栏上，由于当时有部分未明晰的需求包括：客户订票流程，调度管理部分需求，客户方面可能提出新的需求…需求范围界定不清，计划不充分，用户参与不足，缺乏领导支持，技术问题等成为我们项目的主要风险事件，事实表明，这种做法非常有效。特别是客户方面，我定期把风险事件列表EMAIL给客户方负责人李某，为了能尽快落实未明晰的客户需求，我与客户方负责人李某进行了面对面的沟通，通过一番利弊关系的陈述，达成了尽快明晰悬留部分需求的共识，需求问题很快得到解决，项目组整体信心十足，积极性和责任感增强，公司领导方面对项目组也表现出特别的关心，特别是公司胡总开始频繁的出现在项目组每周的进度评审会议上，他们也开始担心因对项目支持不够而导致项目失败。
3. 实施阶段进行进度的跟踪和控制，必要时调整进度表。
实施阶段要进行进度的跟踪和控制，在确定项目开发计划时，我们制定了详细的工作进度表，在确定每项任务时都确定了该任务的工作量，开始时间，结束时间，持续时间，同时要让每个小组成员都知道自己承担的任务时间表，根据自己的任务制定详细的工作计划.
工作日志是了解每个小组成员工作情况的最好方式，我要求每个小组成员都要对自己的工作情况做日志，详细记录自己每天的工作。在每周5下班前通过内网B/S项目管理信息系统PMIS 提交《项目周报》，把各自本周内完成的任务进度情况和下周任务计划做出汇报，报告要严格按照百分比量化任务完成的情况，因为PMIS只提供具体的百分比选择，每个小组成员都要对自己的总结报告做出负责，我把各项任务实际完成数据输入到项目进度计划中，Project自动完成甘特图的绘制，通过查看甘特图就可以交好的把握项目的总体进度绩效，随时了解项目进度,并确定是否调整下一阶段的进度计划,
在本项目中，为保证项目快速完成，在定义甘特图任务的依赖关系时，我在没个任务的任务信息对话框中“前置任务”一栏中的“延阁时间”我填入10%，也就是说当任务完成90%的时候就可以结束转入执行下一任务，因为本项目的所有人员几乎是全程参与，我所以不是很担心，每个任务遗留的少量问题，在下一阶段每人去负责解决。
航空票务系统在2004年12月下旬正式上线，提前完成了项目，目前系统运行正常，受到客户和有关部门的一致好评，对项目的满意度较高。项目成功很大程度归功与在项目各阶段的对进度和成本的有效管理和控制，没有进度管理，项目很难如期交付，对项目质量，进度，成本三大目标的实现有巨大的风险。
摘要
本文讨论了某公司实施SAP系统的风险管理．该公司原先运行着一套ERP系统，现在要转到SAP上，需要完成新系统的流程的重新定义，数据的切换，用户的培训等工作．项目要求在11个月的时间内完成．实施一个大型的ERP系统有着各种的风险，这些风险如果不加分析和控制，将会给整个项目造成致命的影响．我作为项目经理，主要从控制进度风险，人员流动风险和系统功能风险三个方面去进行风险的管理．最后这三方面的风险都得到了有效的控制，从而使项目顺利完成．
正文
2003年1月，我参与了西门子集团下某公司的SAP留系统的实施，提任项目经理．该公司之前运行着另一套ERP软件：QAD的MFG/PRO系统．由于集团总部的要求，要用SAP 系统替换原先的MFG/PRO系统，并且要在2003年11月前完成．整个项目完成以下阶段，首先是项目的引进，包括成立项目小组，由顾问对项目小组成员进行初步的培训，让小组成员对SAP的标准流程有个大概的认识．接下来是要分模块进行讨论，制定出各模块的实施蓝图(blueprint)．该公司实施了以下的模块：SD（销售与分销），MM（物料管理），CO（成本控制），QM（质量管理），PP（生产控制），FI（财务核算），CO（成本控制）等．在Blueprint 完成后，由顾问根据定下的流程配置一个测试的系统，用户在该测试环境下进行练习和测试．测试完成后就是数据的准备和切换了，要从MFG/PRO系统把需要的数据下载下来然后你上传到SAP系统。完成数据的切换，SAP系统正式上线，同时不再使用原先的系统。
因为整个项目要在11个月的时间内完成，时间是非常紧迫的．如何在如此短的时间内使项目能顺利进行，控制各种可能出现的风险是必要的．为此，在项目的初始阶段，我召开了小组成员开会，专门针对项目的风险进行了讨论．会上，大家把想得到的风险都提了出来．经过分析筛选，我最后确定了三个重点进行控制的风险，并采取了相应的措施进行控制．
1、控制进度风险
ERP的实施是一个大型的项目，涉及到企业的流程改造和其它方方面面的东西．而该项目的上线时间不能改变，所以，项目进度在这里是个潜在的风险，如果不能如期上线，则公司的运作将会受到重大的影响．为此，我在项目启动后，召集了项目小组成员开会制定项目计划．我首先用Microsoft Project制定了项目的总体计划，在这个总体计划中，明确了各个阶段的任务和完成时间．如什么时候完成设计蓝图（Blueprint)，什么时候进行关键用户的培训，什么时候进行测试和练习，什么时候进行数据的切换等．总体计划制定出来后，各顾问在总体计划下制定各模块的实施计划，把每个模块在每一阶段的问题细化．各模块的实施计划要在总体计划的基础上进行，在任务和时间上不能滞后于总体计划．无论是总体计划和实施计划，都要求明确各步完成的时间，要精确到哪一天，而不能用模糊的描述，比如“3 月初完成Blueprint”这样的低描述是不充许的．为保证项日照进度进行，每周五都要召开项目会议，检讨项目的进展情况，发现有超期的任务，分析原因，及时解决．在进度的控制方面，还要应付突发的事件造成的影响，及时地调整计划以适应新的情况．2003年4月一5月，由于受到“非典”的影响，外部顾问不能出差来我公司，这使项目的进度受到了很大的影响．为了把这种影响降到最低，我即时调整了项目计划，把这段时间安排为关键用户的培训和对系统的熟悉。因为之前顾问已对关键用户进行了一些培训，所以用户对SAP 系统有了一定的认识．通过上机的操作，更进一步了解系统．有问题我们通过E-Mail与顾问联系。通过这种方法，把原本以后进行的用户练习提到了前面．虽然没有顾问的现场指导，但通过自己的摸索对系统的印象更加深刻，为之后的工作打好的基础．
2、控制人员流失的风险
在实施SAP过程中，有两种可能会导致人员的离职，一是工作繁重乏昧，压力大；二是积累了一定的SAP经验后找工作相对比较容易，这时如果有其它更好的机会，员工会考虑跳槽．而项目小组人员流动将会对项目造成很大的影响，甚至导致项目的失败．所以如何控制这些风险，是作为项目经理要考虑的问题．为此，我首先与人力资源部一起，制定了一套有效的激励机制．包括，把参加SAP项目作为年终的一个绩效考核内容，因为项目需要加班加点的，公司免费提供晚餐；设立项目基金，对表现突出的小组成员进行物质上的奖励；在整个公司的范围内大力宣传SAP，让项目小组成员感觉到SAP 的重要性和实施项目的价值等．其次，为了避免出现某个项目小组成员离职导致项目不能进展的情况出现，我在每个模块都安排了两个人员负责，一个是主负责，一个是次要负责．这样，可以减少人员流失造成的损失。在这里，我没有采用让项目小组成员签合同的方法，即实施项目后要在公司工作多少年。我觉得这种方法会给小组一种压抑的感觉，而公司主要靠企业文化来吸引员工．事实证明，我所采用的措施是有效的：在整个项目的实施过程中，没有一个小组成员退出或是离职．在项目运行一年多来，只有两个当时的关键用户离职，而他们离职后后备人员可以马上顶上来，对系统没有造成什么影响．
3、控制系统的功能
有人戏称SAP是“Stop All Production”，这也从一个方面反映了实施SAP的风险所在．而造成上了系统后停产的一个原因就是系统功能不能满足物流和生产的需要，这也是我担心的一个问题．因为切换后系统不能再使用，如果这时候新系统满足不了需要，就真的会造成停产．为此，我在项目中采用了演化型的原型开发方法，用演化型的开发方法，可以让用户针对已配置好的原型进行测试，发现不能实现的功能及时提出来，改进后再测试，再改进．在这里，测试工作显得很重要．为此，我强调一定要做好测试工作．在系统测试阶段，我把所有的项目成员集中在会议室中进行系统测试．在测试中，我要求用真实的数据，模拟真实的环境进行．系统测试通过后，我还特别做了一次上线前的演习，即把所有相关的数据都导致SAP，配置一个上线后要用的系统，在此系统上进行操作．这次演习成功后，坚定了大家使用系统的信心．系统上线后也没有出现什么大的问题．
通过以上措施，使把SAP的主要风险基本上都控制在萌芽状态，项目没有因为这些风险受到影响，最后项目如期上线，受到了管理层和用户的肯定．
在项目进行过程中，有些风险并没有事先预计出来．比如说顾问的问题．有的顾问水平高，但项目也多．用在我们这个项目上的时间就比较少，这给项目带来了不利影响．为此，我通过和该项顾问所在的公司签定合同，注明顾问在我们公司的工作时间，否则属违约，通过这一方式使顾问的管理得到改善．
项目管理是以可能的最高效率执行项目，做到按工期、按预算、按要求完成任务。今天，项目管理学科已经渗透到it行业的信息系统工程建设中，在同一个项目团队里，业主、承包商、监理三方如何相互协调配合，各司其职地做好工作？现代项目管理学为项目团队各方实现项目目标提供了有效的项目管理途径。我国加入wto后，工程管理应与国际接轨，当然，这必须以符合我国的国情为基础，与项目的实际情况相结合。
目前，我国的大型信息系统建设工程正在逐步实行监理制。通过将美国项目管理学会（pmi）的项目管理知识体系（project management body of knowledge, pmbok）的基本内容与工程监理的主要职责相比较，我们认为，工程监理是现代项目管理的一种重要的表现形式，工程监理的工作职责中包含着现代项目管理学的基本内涵，我们要用现代项目管理知识体系来增强信息系统建设工程管理体系。
我国的监理工程师是独立的第三方，业主、承包商、监理这个三角形不是等边的，监理向业主倾斜，接受业主的委托进行工作。it行业工程监理的主要工作内容是“三控制二管理”，即对工程项目的质量、进度、费用等过程实施控制，同时对项目合同、信息等进行管理。我国实施工程建设项目业主负责制、工程建设招投标制以及工程监理制，这是我们在项目管理方面的基本国情，现代项目管理必须关注这一现实，it行业也不能例外。从本文的分析中可以看出，pmbok的基本内容与工程监理的工作内容有着十分自然的关联。
美国项目管理学会（pmi）项目管理知识体系（pmbok）是对项目管理专业知识的一个总结。诞生于20世纪80年代的pmbok第一版由多名项目管理专家历经4年而成，之后分别在1991年、1996年和2000年对其进行了增订、完善和发展。
pmbok把项目管理划分为9个知识领域，即范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和综合管理。国际标准化组织（iso）1997年以pmbok为框架提出了“项目管理质量指南”（iso 10006），成为iso 9000族中重要的支持性技术指南。
近十多年来，由于pmbok的基本内容跨越行业界限而得到“普遍认可”，因而受到国内外专业学术领域的广泛重视。对信息系统的建设来讲，它同样具有指导价值，it建设工程项目团队，包括业主、承包商、工程监理，也将从中受益。
项目管理与其他管理学科有着密切的关系，一般性管理方法为项目管理奠定了基础。pmbok是我国入世后十分走俏的洋证书pmp（项目管理专业人员）资格认证所需的专业基础知识。据报道，我国的项目管理知识体系目前也正在制订之中。
比较之一:范围管理
信息系统建设中的工程监理十分注意抓好系统需求分析，弄清系统该做什么，不做什么；严格为业主把好系统功能模型、信息模型关，为系统的进一步实施打好基础。
项目范围管理的首要任务是确定并控制哪些工作内容应该包含在项目范畴内，并对其他项目管理过程起指导作用。从项目管理科学来看，项目生命周期的第一阶段始于识别需求、问题或机会，终于需求建议书（rfp）的发布。准备rfp的目的就是从业主的角度，全面、详细地论述为了满足需求需要做什么准备，要清晰地定义出项目目标，项目目标必须明确、可行、具体及可以度量，并与有关方面一致。it工程中有人爱炒概念、来虚的，这有悖于现代项目管理学的要求。
pmbok将项目范围管理分成启动、范围计划、范围界定、范围核实、范围变化控制五个阶段。在范围界定过程中，通过将项目目标和工作内容分解为易于管理的几部分或几个细目，以助于确保找出完成项目工作范围所需的所有工作要素。工作细分结构（work breakdown structure，wbs）可以帮助我们更加明确项目的工作内容，它不仅定义了工作内容，同时也定义了工作任务之间的关系，明确了工作界面。项目的wbs是我们对工作计划、进度、费用、技术状态进行部署和跟踪控制等管理活动的基础。
在信息系统建设过程中，人们常用数据流图、功能层次图、业务流程图等表示系统的功能模型，它们是从不同角度对系统功能模型的表达。而wbs则可以理解为是一种以管理为导向的系统功能模型，它有更丰富的内涵和外延。wbs是项目管理的核心工具，项目的计划、进度、成本、技术状态、资源配置、合同等方面的管理都离不开项目的wbs，它的建立必须注意体现项目本身的特点和项目组织管理方式的特色，并注意其整体性、系统性、层次性和可追溯性原则。wbs技术有力地支持了信息系统建设中的项目管理，是项目团队中管理人员必须具备的基本知识。
比较之二：时间管理
时间管理是项目管理中的一个关键职能，也被称为进度管理，它对于项目进展的控制至关重要。在范围管理的基础上，通过确定、调整合理的工作排序和工作周期，时间管理可以在满足项目时间要求的情况下，使资源配置和成本达到最佳状态。值得注意的是，进度是计划的时间表，应该按计划安排进度。计划决定需要做什么、谁去做、花多长时间、成本是多少等问题。
pmbok提出，项目时间管理由下述5项任务组成：活动（activity）定义、活动顺序、活动时间的估计、项目进度编制、项目的进度控制。
pmbok的进度管理与工程监理学在项目进度控制方面所提供的方法是基本一致的。我国三峡工程实施了项目管理，其中进度管理很有特点，使人很受启发。据报道，针对三峡工程的特点、进度计划编制主体及进度计划涉及内容的范围和时段等具体情况，确定三峡工程进度计划分为三个大层次进行管理，即业主层、监理层和施工承包商层。通常业主在工程进度控制上要比监理更宏观一些，但鉴于三峡工程的特性，三峡工程业主对进度的控制要相对深入和细致。这是因为三峡工程规模大、工期长、参与工程建设的监理和施工承包商多，任何一家监理和施工承包商所监理的工程项目及施工内容都仅仅是三峡工程一个阶段中的一方面或一部分，而且业主在设备、物资供应、标段交接和协调上的介入，形成了进度计划管理的复杂关系。为满足三峡工程总体进度计划的要求，各监理单位控制的工程进度计划还需要协调一致，这个工作自然要由业主来完成，这也就是三峡工程进度计划为什么要分三大层次进行管理的客观原因和进度计划管理的特点。
项目具有惟一性，根据不同的项目组织结构，由业主负责，根据自己在项目团队中不同的角色，相互协调、共同搞好工程项目的进度管理，这在信息系统建设中也不例外。
比较之三：成本管理
pmbok对项目成本管理的思路非常清晰，分以下四步进行：
(1) 制订资源计划 资源计划确定了为完成项目中各活动所需要的资源（人、设备、材料）。wbs是项目资源计划最基本的输入，需结合各种资源的使用要求，制订出项目的资源需求。
(2) 成本估计 利用wbs、资源需求、资源单价、活动时间估计等成本要素，通过有关算法或项目管理软件得到项目的成本估计，即可算出完成项目所需各资源成本的近似值。
(3) 成本预算 利用成本估计及wbs确认的项目的细目，考虑到项目的进度，将成本分配到项目的细目上，为每个工作包建立总预算成本（tbc）。一般当实际成本超过累计预算成本（cbc）时，就要注意调控了。
(4) 成本控制
工程监理对投资控制的主要思路也是将实际支出与计划投资相比较，结合项目进展进行调控。这一基本思路与pmbok十分类似，但是，由于管理体制不同，特别是项目财会管理水平的差异，与其接轨尚需时间。
比较之四：质量管理
在信息系统建设中，监理工程师把系统质量控制当做头等大事来抓，从iso 9000质量保证体系的高度来控制和规范项目团队中的各方行为。pmbok在介绍项目质量管理中指出，这一部分论述的质量管理的基本方案旨在与国际标准化组织在iso 9000和iso 10006质量体系标准与指南中提出的方案中相一致。因此，项目管理与工程监理在质量管理方面的指导思想是完全一致的，iso 9000与iso 10006相互支持，相得益彰。
比较结果：基本一致
在项目管理过程中，项目的范围、时间、成本和质量相互间是有冲突的，项目人员对项目的不同需求和期望也同样有冲突，我们需在它们之间寻求一种平衡，这就是项目管理的基本内涵。我们对pmbok中范围、时间、成本和质量与工程监理的主要职责做了对比分析，其结论十分明显：项目管理的基本内涵与工程监理的工作职责是基本一致的。pmbok提出可以用许多方式把关于项目管理的理论知识组织起来，而工程监理制则是一种符合我们国情的项目管理方式。项目管理还有着更丰富的内容，如风险管理、沟通管理、人力资源管理、采购管理、综合管理等方面，这些常常体现了项目的外部环境，它们与监理工作的合同管理、信息管理、协调项目团队等职责有一定的交叉，项目管理有着更全面、丰富的知识体系，而实际上，这也是在接受业主委托的条件下，为工程监理工作提供更丰富的工作内容。
国际咨询工程师联合会（fidic）编制了用于工程项目管理的有关标准文件，其中，《业主/咨询工程师标准服务协议书》、《电气与机械工程合同条件》是国际公认和通用的权威文件，非常详细、具体规定了项目管理中的各方面，充分体现了pmbok对项目管理的要求。现代项目管理理论进一步推动了我国工程监理制实施的健康发展。按照国家技术监督局对监理工作的要求，北京德瑞塔公司一直将这些标准文件作为信息系统建设中工程监理的指导性文件，承接了一批大型信息系统建设的监理和项目管理工程，取得了较好的效果。
摘要
本文讨论了一个作者参与的软件项目的项目计划制订的若干问题．项目所开发的产品是一种智能电子教学设备，该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上，并可以保存、编辑、打印用户输入的数据，联网的计算机也可以实时观看用户的书写过程，并且用户还可以通过投影在硬件端的PC机画面交互操作PC机．
作者是该项目的软件开发组负责人兼软件架构师．作者针对项目计划的制定采取了：分而治之，逐步求精，经验数据三个主要策略，从而得到较好的效果．
正文
2002年6月，作者所在公司启动了一个项目，该项目开发出来的产品是一种智能教学设备，该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上，用户可以保存、编辑、打印通过硬件端输入到计算机的书写内容，联网的计算机也可以实时观看用户的书写过程．另外，用户还可以通过投影在硬件端的PC机显示画面交互地操作PC机．作者有幸全程参与该项目的开发，并且担任了项目PC机软件开发组的负责人兼软件构架师的角色．对于这种实时通信且具有联网功能的软件项目，我认为首先需要制定一个良好的项目计划，才可以保证项目开发的成功．
总结这次项目的经验，我认为行之有效的策略有三个，分别是分而治之、逐步求精、经验数据。下面就结合这三个策略详细讨论本次项目计划的制订。
一、分而治之
将一个过于复杂的问题分解成若干复杂度不那么高的小间题来依次解诀，这种方法人类已经采用了几千年．这里我们也可以用于项目计划的制定．因为整个考虑项目的方方面面来制定计划其复杂度已经超过了人类处理问题的能力．为了解决这个问题，可以将整个项目分解为一些更小的组织体，逐一进行处理，这项工作也就是项目管理中的WBS（工作分解结构）。
比如针对这次项目中采取的RUP开发过程模型，我在完成需求管理计划时我就将计划内容分解成初始、细化、构建、移交四个阶段来分别制定，最后合到一块儿就是完整的需求管理计划．
除了按时间段分解的角度来制定项目计划，我制订软件开发计划时同时按照了RUP过程方法的工作流的概念来分解项目计划的制定工作，根据每个工作流在四个阶段业界通用的工作量估计来制定计划，安排工作人员以及相应的软件资源。因为软件开发计划涉及到多个工作流，我认为以这种方式分解是合理的．同时因为本项目的特点，我省略了业务建模工作流，这是因为这次的产品是以硬件为主，软件为辅的消费类产品，所以业务建模不是那么必要了．以不同的方式分解项目，可以从多个不同的角度来制定整个项目计划，有利于全面、深入地了解项目，避免“瞎子摸象”的情况发生．
二、逐步求精
计划工作其实是一种管理未来、管理未知的工作，而未来是变化莫测的，还存在许多自身无法掌握的因素，因此存在很大的难度．而解决这一困难的法宝就是逐步求精．按照先框架后细节，先粗后细地进行项目的计划．
比如在这个项目中，在接受这个项目后就开始了做了一个初步计划，这个计划的内容主要是做出时间上的安排．因为打算在2003年的月需要用这个项目的产品申请国家中小企业创新基金的支持，所以完成时间就定在了2003年4月，预留一个月用于写申请报告．总的时间进度确定后，大概分配了三个时间段：系统工程分析、软件开发模型确定、软件产品制造时间段、项目总结．
等到确定这改项目后的RUP 开发模型后，就可以继续对项目计划进行第二改求精了。其实RUP 过程中出体现了逐步求精的理念，比如在初始与细化两个阶段都要产生出项目计划的制品．这样我就可以在这个两个阶段对项目计划逐步求精，比如在初始阶段只是将我需要完成的项目计划分为了需求管理计划、软件开发计划、实施计划，然后在细化阶段我再具体地制定每类计划的详细内容．
比如在初始阶段时架构设计考虑以MFC为平台，根据这个决定软件开发计划的制定是比较粗略的，在细化阶段架构设计进一步详细，这时已经清楚各个模块和MFC的Doc/View主结构的接口定义，以及各模块之间的接口定义，这时我就可以根据所需开发的模块制定计划。比如这时我就计划了特效界面模块开发分两次迭代，第一次迭代计划一个月时间，第二次迭代两周时间，第一次迭代需要完成放大和缩小、树形选择、缩略显示等主要的界面效果，第二次迭代的主要任务是根据用户反馈进行修改调整．
三、经验数据
要制定一个良好的计划离不开精确的估算．不过项目计划是在项目开发的早期制定的，而在早期要完成精确的估算是非常困难的．要解决这个问题的关键就在于“经验数据”．由于整个软件产业都还十分年轻，经验数据的积累都普遍不足，才导致这一现象的出现．
但是因为这次项目开发的产品在国内还没有开发过，再加上公司没有积累深厚系统的项目历史数据．针对面临的困难，我选用了FP功能点分析作为项目主要的估算方法．因为FP方法中有大量项目经验数据可以从网络上获得，同时其数据功能TLF、EIF，以及事务功能EI、EO、EQ的计算对经验数据依赖不强，只需对概念理解正确一般就可以正确估算了．在估算成本的时候，因为公司以前的生产率数据是以LOC为单位的，我利用软件工程书籍中的“逆火”经验数据，将LOC转换为功能点单位，当然，这里必然导致一些误差。为了降低估算误差，最后使用Delphi专家分析法对估算结果进行了调整．
Delphi方法是一种集策法，也就是通过多名专家对估计值的不断校正的方法．当然，请专家增加了项目成本，不过最后得到高质量的项目计划还是值得的．比如，在某专家的建议下我们改变了自行开发网络层组件的计划，而是采购现有的完全可以解决项目需求的成熟的中间件产品，这个策略的调整在后来证明是正确的．一开始犯错误的原因是由于我们网络开发经验不足把用户需求想复杂了．
最后谈一下使用的工具软件．在制定项目计划过程中我采用了Microsoft的Project 2003绘制甘特图．因为项目的进度安排是和项目中每个人都是息息相关的，所以在做甘特图前我首先征集了大家对文字和条形图效果的意见，然后按大家的意见进行了美化，比如用鲜艳的颜色标识关键任务，放大任务摘要信息，突出里程碑信息等．这在有些项目管理者看来似乎是小事，不过我认为一个赏心悦目的甘特图可以带给观看者好的心情，而好的心情可以大大提高工作效率。
同时，考虑创新基金支持的项目在交互期限上有很大压力，所以在定义甘特图任务的依赖关系时我采取了业界惯用的“时间盒”的技术，也就是在每个任务的任务信息对话框中“前置任务”一栏中的“延隔时间”我填入5%-15%，也就是说当任务完成90%左右时就可以结束转而执行下一个任务．因为本项目中的所有人员几乎是全程参与，所以我不是很担心每个任务遗留的少量问题在下一阶段没有负责人去解诀。
配合Project 2003使用的估算软件是Software Productivity Research的KnowledgePlan.这款工具软件的最新版加强了对Microsoft Project 2003以及RUP开发模型的支持，而且其中的Project Template功能允许用户采用自己定制的WBS来进行估算，这些因素使得KnowledgePlan对本项目的项目计划成功制定带来很大的帮助．
在上述三个策略的指导下，以及合适工具的辅助下，使最后形成的计划有效地指导了后期的开发活动。项目开发出来的产品通过了专家的鉴定，获得了国家中小企业创新基金的支持．项目完成后发现的问题是早期计划的估算结论偏差还是较大，看来还是受到缺乏经验数据或者经验数据不够精确的影响，所以在以后的工作中需要开展有效的度量的工作，为公司积累覆盖面广且尽量精确的经验数据．
发布：华夏学习网 www.edu114.cn 时间：2006-11-04
回想一下你所经历的项目，有没有出现过以下这样的情况：客户在检查项目阶段成果时，指出曾经要求的某个产品特性没有包含在其中，并且抱怨说早就以口头的方式反映给了项目组的成员，糟糕的是作为项目经理的你却一无所知，而那位成员解释说把这点忘记了；或者，你手下的程序员在设计评审时描述了他所负责的模块架构，然而软件开发出来后，你发现这和你所理解的结构大相径庭……
可能你遇到的情况比上面谈到的还要复杂。问题到底出在哪儿呢？其实很简单，就两个字??沟通。以上这些问题都是由于沟通引起的，沟通途径不对导致信息没有到达目的地。“心有灵犀一点通”可能只是一种文学描绘出的美妙境界。在实际生活中，文化背景、工作背景、技术背景可以造成人们对同一事件理解方式偏差很大。
在项目中，沟通更是不可忽视。项目经理最重要的工作之一就是沟通，通常花在这方面的时间应该占到全部工作的75%～90%。良好的交流才能获取足够的信息、发现潜在的问题、控制好项目的各个方面。
沟通管理的体系
一般而言，在一个比较完整的沟通管理体系中，应该包含以下几方面的内容：沟通计划编制、信息分发、绩效报告和管理收尾。沟通计划决定项目干系人的信息沟通需求：谁需要什么信息，什么时候需要，怎样获得。信息发布使需要的信息及时发送给项目干系人。绩效报告收集和传播执行信息，包括状况报告、进度报告和预测。项目或项目阶段在达到目标或因故终止后，需要进行收尾，管理收尾包含项目结果文档的形成，包括项目记录收集、对符合最终规范的保证、对项目的效果（成功或教训）进行的分析以及这些信息的存档（以备将来利用）。
项目沟通计划是项目整体计划中的一部分，它的作用非常重要，也常常容易被忽视。很多项目中没有完整的沟通计划，导致沟通非常混乱。有的项目沟通也还有效，但完全依靠客户关系或以前的项目经验，或者说完全靠项目经理个人能力的高低。然而，严格说来，一种高效的体系不应该只在大脑中存在，也不应该仅仅依靠口头传授，落实到规范的计划编制中很有必要。因而，在项目初始阶段也应该包含沟通计划。
设想一下，当你被任命接替一个项目经理的职位时，最先做的应该是什么呢？召开项目组会议、约见客户、检查项目进度……都不是，你要做的第一件事就是检查整个项目的沟通计划，因为在沟通计划中描述了项目信息的收集和归档结构、信息的发布方式、信息的内容、每类沟通产生的进度计划、约定的沟通方式等等。只有把这些理解透彻，才能把握好沟通，在此基础之上熟悉项目的其它情况。
在编制项目沟通计划时，最重要的是理解组织结构和做好项目干系人分析。项目经理所在的组织结构通常对沟通需求有较大影响，比如组织要求项目经理定期向项目管理部门做进展分析报告，那么沟通计划中就必须包含这条。项目干系人的利益要受到项目成败的影响，因此他们的需求必须予以考虑。最典型也最重要的项目干系人是客户，而项目组成员、项目经理以及他的上司也是较重要的项目干系人。所有这些人员各自需要什么信息、在每个阶段要求的信息是否不同、信息传递的方式上有什么偏好，都是需要细致分析的。比如有的客户希望每周提交进度报告，有的客户除周报外还希望有电话交流，也有的客户希望定期检查项目成果，种种情形都要考虑到，分析后的结果要在沟通计划中体现并能满足不同人员的信息需求，这样建立起来的沟通体系才会全面、有效。
语言、文字还是“形象”
项目中的沟通形式是多种多样的，通常分为书面和口头两种形式。书面沟通一般在以下情况使用：项目团队中使用的内部备忘录，或者对客户和非公司成员使用报告的方式，如正式的项目报告、年报、非正式的个人记录、报事帖。书面沟通大多用来进行通知、确认和要求等活动，一般在描述清楚事情的前提下尽可能简洁，以免增加负担而流于形式。口头沟通包括会议、评审、私人接触、自由讨论等。这一方式简单有效，更容易被大多数人接受，但是不象书面形式那样“白纸黑字”留下记录，因此不适用于类似确认这样的沟通。口头沟通过程中应该坦白、明确，避免由于文化背景、民族差异、用词表达等因素造成理解上的差异，这是特别需要注意的。沟通的双方一定不能带有想当然或含糊的心态，不理解的内容一定要表示出来，以求对方的进一步解释，直到达成共识。除了这两种方式，还有一种作为补充的方式。回忆一下体育老师授课，除了语言描述某个动作外，他还会用标准的姿势来教你怎么做练习，这是典型的形体语言表达。像手势、图形演示、视频会议都可以用来作为补充方式。它的优点是摆脱了口头表达的枯燥，在视觉上把信息传递给接受者，更容易理解。
两条关键原则
在项目中，很多人也知道去沟通，可效果却不明显，似乎总是不到位，由此引起的问题也层出不穷。其实要达到有效的沟通有很多要点和原则需要掌握，尽早沟通、主动沟通就是其中的两个原则，实践证明它们非常关键。
曾经碰到一个项目经理，检查团队成员的工作时松时紧，工期快到了和大家一沟通才发现进度比想象慢得多，以后的工作自然很被动。尽早沟通要求项目经理要有前瞻性，定期和项目成员建立沟通，不仅容易发现当前存在的问题，很多潜在问题也能暴露出来。在项目中出现问题并不可怕，可怕的是问题没被发现。沟通得越晚，暴露得越迟，带来的损失越大。
沟通是人与人之间交流的方式。主动沟通说到底是对沟通的一种态度。在项目中，我们极力提倡主动沟通，尤其是当已经明确了必须要去沟通的时候。当沟通是项目经理面对用户或上级、团队成员面对项目经理时，主动沟通不仅能建立紧密的联系，更能表明你对项目的重视和参与，会使沟通的另一方满意度大大提高，对整个项目非常有利。
保持畅通的沟通渠道
沟通看似简单，实际很复杂。这种复杂性表现在很多方面，比如说，当沟通的人数增加时，沟通渠道急剧增加，给相互沟通带来困难。典型的问题是“过滤”，也就是信息丢失。产生过滤的原因很多，比如语言、文化、语义、知识、信息内容、道德规范、名誉、权利、组织状态等等，经常碰到由于工作背景不同而在沟通过程中对某一问题的理解产生差异。
如果深层次剖析沟通，其实可以用一个模型来表示：
从沟通模型中可以看出，如果要想最大程度保障沟通顺畅，当信息在媒介中传播时要尽力避免各种各样的干扰，使得信息在传递中保持原始状态。信息发送出去并接收到之后，双方必须对理解情况做检查和反馈，确保沟通的正确性。
如果结合项目，那么项目经理在沟通管理计划中应该根据项目的实际明确双方认可的沟通渠道，比如与用户之间通过正式的报告沟通，与项目成员之间通过电子邮件沟通；建立沟通反馈机制，任何沟通都要保证到位，没有偏差，并且定期检查项目沟通情况，不断加以调整。这样顺畅、有效的沟通就不再是一个难题。
在很多年以前，一位好的项目经理并不一定要是一位交流高手。客户们通常并不喜欢这种情况，但是由于项目经理能够向他们提供产品，他们也就接受了。然而，在今天这个崭新的IT世界里，所有的项目都要在客户的合作下才能够完成，而这种合作绝对离不开良好的交流。事实上，项目中出现的很多问题都是交流不善所产生的结果。但是，聪明的项目经理是懂得如何来解决交流中出现的问题的。
问题所在
一旦交流出现了问题，项目的成功就会遇到阻碍。那么问题通常出现在那些方面呢？
期望值不同
项目经理要努力让与项目有关的每一个人建立起同样的期望值，包括项目应该何时完成、带来什么样的结果，成本如何。这些期望值最初在对项目进行计划时就应该在计划书中明确下来。但是，很多项目经理没有能够让关键股东及时了解期望值的变化。人们在做出决策时通常要依据当时所掌握的最佳信息，如果项目经理不能让所有人都对项目的期望值有同样的了解，就会在同步性上出现问题。
意外
如果不能及时了解项目进展，人们就会对项目进行过程中出现的变化感到意外。例如，如果你无法按照预计工期完成项目，而又不想让股东在项目进展报告中了解到这一点，那么该如何去做呢？
前摄性的交流意味着及时意识到无法按照预计工期完成项目的风险。然后继续按照预计工期的要求进行项目。如果你不得不宣布无法按照预计工期完成项目，其他人能够有所准备，不会因此而感到过于不安。人们通常会由于在最后时刻才得知坏消息而感到愤怒和沮丧，因为他们已经来不及适应变化了的情况了。
没有人知道项目的进展情况
在一些情况下，股东们并不真正了解项目的进展情况。如果没有正确的信息，人们是无法做出最佳的决策的。如果他们不了解项目的进展情况，就要花费额外的时间去搜集更进一步的信息。事实上，如果你及时向股东提供项目进展信息，而他们却不停的向你追问更新的信息，这可能表明你们之间的交流还是存在着问题。
人们在最后时刻受到项目的影响
在这种情况下，项目经理没有提前让其他人了解项目会对他们产生的影响。交流通常总在最后一刻，但往往是为时已晚。
这样的例子有很多。例如，项目经理在三个月之前就已经知道自己需要一位专家，但是却在立即需要专家帮助之前一周才开始寻找。这样，其他人就无法做好充分的准备。
发布：华夏学习网 www.edu114.cn 时间：2006-11-04
项目启动是一个十分重要的阶段，它关系到一个项目能否成功的实施，能否达到项目干系人的期望，并能有效的获得项目关系人的支持。
在项目启动过程中，这个阶段的工作占项目经理整个项目工作量的50％以上，一个项目的成功与否都在于计划做的是否完善、预见到的问题是否全面。
由于在整个项目实施过程中，有许多限制项目的条件因素，例如：资金、时间、人员、合同范围等等，如何能在规定的时间内，合理的资金使用范围内，合理的人力使用范围内，成功的完成项目，对每个项目经理来说都是一种挑战。
根据个人多年的项目管理经验，成功的实施一个项目，关键一点就是能有效的在项目启动的时候完善的进行项目的计划工作，把项目实施过程中分解成为各个小的单元，也就是我们在项目管理过程中制订的WBS，这部分工作中，将用到头脑风暴法，鱼骨图法等多种方法，目的在于有效的制订出WBS，在对每个单元分配资源，包括人力资源、资金资源，不能忽视的一点是要在整个分配资源的过程中考虑各种资源所存在的分析，对风险进行分类，以次为各个风险定义风险级别，对高危害且高爆发的风险为其制订风险应对计划，为计划分配资源，通过对WBS的分解可以得到整个项目的工作范围，这也就是对项目的实施范围进行了界定，风险事件的考虑会避免突发事件的发生导致整个项目实施工作延时或出现资源不足的情况导致项目失败。
在整个项目的启动阶段项目经理的工作就是导引整个项目团队有目的性的制订项目计划，综合各个方面的实际情况，完善项目计划；在本阶段项目经理大部分的精力用于沟通，通过不断的沟通了解该项目干系人的期望，并根据不断的沟通使项目干系人了解整个项目的情况，使其产生一个合理的项目结果预期，这样对项目在实施过程中会有一个正面的推动，项目干系人不单指用户，还有内部与项目相关的人员，包括项目的销售，项目团队的领导等；只有这样在计划工作过程中才能更好的得到项目干系人的支持，如果期望定义太高，会导致项目干系人对整个项目情况失望，导致资源得不到保障；如果定义太低，会有损整个项目的价值，也可能会导致项目干系人失望；其实具体来说就是对项目价值度的衡量，实事求是的衡量项目价值，这个工作也是项目经理在项目启动阶段需要完成的工作之一。
在项目启动阶段对整个项目团队的要求就需要明确，项目经理要对整个项目负责，同时也要对项目团队的每个人负责，应该明确的告知项目团队在整个项目实施过程中他的权责在哪里，定义好工作的汇报机制，完成好人员的培训工作，这些工作也是需要在项目启动阶段完成的每个项目经理完成项目的看法都不尽相同，实施项目工作本身就是一个见仁见智的工作，多听听身边人的意见，对完成好项目管理工作是十分有益的；我通过几年的项目管理工作，有失败有成功，对项目管理工作的一些感悟，拿出来同大家分享。
[2007-7-20]
人常说："一个中国人是龙，一群中国人是虫。"由于中西方文化的差异，似乎中国人更擅长单兵作战。所以，项目团队的管理在我国显得特别需要。
笔者总结了数年来在IT行业项目管理的经验和教训，认为成功的项目团队应普遍树立起五种思想意识--目标意识、团队意识、服务意识、竞争意识和危机意识。下面一一诠释一下 。
一、目标意识
1、 目标到人
项目管理是目标管理，项目有明确的目标，所以团队中每个人必需有明确的目标。考核时，项目经理只关注各人目标完成的结果，当结果不理想时，再返回去逆向考核过程。
2、 个人目标与组织目标相结合
除完成项目任务外，每个人必需有明确的自身发展目标，并将自己的发展目标和项目大目标有效结合起来。
3、 责任心
按要求完成目标需要每个团队成员的高度责任心作保障。要求每个成员按时兑现自己所作的承诺，每个人要认清自己工作的重要性和工作失误会带来的严重后果。
4、 自信心
团队中每个人应该有足够的自信完成自己的任务，而且不受外界的因素影响。尤其是在项目出现危机的时候，越需要项目组成员坚定信心，各人完成自己的既定目标，以摆脱团队的危机。
二、团队意识
1、 集体成功观
团队中所有成员必需意识到，个人的成功融入集体的成功之中，只有项目成功、团队成功，才谈得上个人的成功，相反，项目的失败会使所有人所付出的努力付诸东流，表现再出众的成员也不会有成就感，因此，只有团队协作是项目成功的必要条件。
2、 树正气，刹歪风
水桶原理更适合于衡量团队战斗力。团队中全体成员要认清极少数人的工作进度拖延会造成这个项目的不可控、个别模块的不稳定会造成整个系统瘫痪这一严峻现实。不是所有人都在团队中都举足轻重，但任一人出一个微不足道的差错，就会使整个团队的工作功亏一篑。因此，团队中每一个成员要勇于和影响团队士气、干扰集体工作正常进行的作法作斗争。
3、 个人利益和团队利益相结合
团队中应达到共识--团队利益大于个人利益，如果团队成功需要，不惜暂时牺牲个人利益。团队中人人都能为团队着想，自觉维护团队形象，自愿以团队纪律约束个人行为。摒弃个别人自以为是、艺高脾气大、居功自傲的作风。
4、 沟通无限，理解万岁
项目团队中所有成员应该及时有效沟通，相互理解。团队中出现意见分歧时，分歧双方的基本态度应该是说服对方而非强制对方，裁决两种不同意见的唯一标准是看哪一种意见更有利于推动项目的正常进行。
三、服务意识
1、 面向客户的服务
客户是上帝，项目所做的所有工作就是为了客户满意，项目团队成员都要追求客户满意，而并非追求技术高难、业界一流等虚的指标，所以，项目团队成员面向客户的态度某种程度上可以决定项目的成败。技术人员以指点江山的专家姿态面对用户还是以帮助客户解决问题的技术服务姿态去面对客户，是决定项目成败的一个关键因素。
2、 面向团队内部的服务
下一道工序是上一道工序的客户。有一家著名的公司提出：公司中每一个人都要寻找你的服务对象并真诚为其服务，如果你找不到你的服务对象，那就意味着你改离开公司。软件开发中，编码人员是设计人员的客户，测试人员是设计、编码人员的客户。上一道工序的输出是否能满足下一道工序的输入是决定项目成败又一个关键点。比如，设计人员的设计应该是服务于编码人员，设计文档是否否易于被编码所理解，是否有二义性，是否能指导编程等等，任一环节出偏差都会导致项目偏离目标方向。同修一条路的两个施工队，如果每个工队都多做点工作，向对方辖区延伸一点，路就通了；如果每个工队都只管自己的辖区内的部分，那么交界处就成了双方扯皮的焦点。因此，项目团队要提高效率，减少摩擦必需要在团队内树立替下一道工序着想，为下一道工序服务的意识。
3、 面向维护人员的服务
同样的道理，项目团队在项目结束后，给项目使用人员、项目后期维护人员提供的培训与维护也很重要。有很多软件项目刚投入使用还比较成功，时间长了就会搁浅，多半原因就是后期服务或用户使用培训跟不上，所以，后期维护人员也是项目组的客户。
四、竞争意识
1、 责权利均衡，论功行赏
项目团队中要引入竞争机制，坚决按责权利均衡的原则，使在项目中贡献大、责任大的成员得到丰厚的报酬，形成良好的导向，以牵引多数人向同一方向努力，为项目做更大贡献。同时，要毫不客气地将影响团队工作进度或士气的后进分子赶出项目团队。
2、 处理好主角与配角的关系
项目经理要处理好主角与配角的关系，要让团队中的主角认识到他在主角的位置一旦出了差错，将可能被配角所代替，要让团队中的配角认识到如果他能够出色的完成他的工作，下个项目或过一段时间就会荣升为主角。配角的存在对主角形成压力，主角的存在对配角形成动力，是团队内部最好的竞争机制。
五、危机意识
1、 使命感
尤其是搞软件开发的项目团队，每一位同仁应当看到民族软件产业和世界先进水平的明显差距，意识到中国IT业腾飞的使命客观地落在我们这一代普通的程序员身上。产业报国不是一句空话，是要落实到每一个人的实际行动中去的。如果我们再不付出双倍的努力，那么，中国的软件业将距离国际水平越来越远。
2、 行业、市场的危机
软件行业的高速发展，本身就是一个很大的危机，稍不努力就可能被淘汰；随着中国加入世贸组织，国外的列强又都来抢占中国的市场，中国的软件企业要生存必需时时提高警惕，居安思危，这种危机感要传遍企业的每一个神经末梢--项目团队和个人。华为老总任正非有句名言："十年来我天天思考的都是失败，对成功视而不见，也没有什么荣誉感、自豪感，只有危机感。也许是这样才存活了十年。"
3、 团队的危机
还有，不能不让团队成员清醒的认识到：竞争对手正在虎视眈眈地盯着我们，等着我们犯错误。 物业安保培训方案
为规范保安工作，使保安工作系统化/规范化,最终使保安具备满足工作需要的知识和技能，特制定本教学教材大纲。
一、课程设置及内容全部课程分为专业理论知识和技能训练两大科目。
其中专业理论知识内容包括：保安理论知识、消防业务知识![](https://wkrtcs.bdimg.com/rtcs/image?w=12&md5sum=0df7eda37b1a005ad0cf6d723004bc23&sign=0beffc1359&rtcs_flag=1&rtcs_ver=3.1&l=webapp&bucketNum=116&ipr={"t":"img","w":"12","h":"9","dataType":"jpeg","c":"word/media/image1.png","imgOriW":361,"imgOriH":240})
、职业道德、法律常识、保安礼仪、救护知识。作技能训练内容包括：岗位操作指引、勤务技能、消防技能、军事技能。
二．培训的及要求培训目的
1）保安人员培训应以保安理论知识、消防知识、法律常识教学为主，在教学过程中，应要求学员全面熟知保安理论知识及消防专业知识，在工作中的操作与运用，并基本掌握现场保护及处理知识2）职业道德课程的教学应根据不同的岗位元而予以不同的内容，使保安在各自不同的工作岗位上都能养成具有本职业特点的良好职业道德和行为规范）法律常识教学是理论课的主要内容之一，要求所有保安都应熟知国家有关法律、法规，成为懂法、知法、守法的公民，运用法律这一有力武器与违法犯罪分子作斗争。工作入口门卫守护，定点守卫及区域巡逻为主要内容，在日常管理和发生突发事件时能够运用所学的技能保护公司财产以及自身安全。
2、培训要求
1）保安理论培训
通过培训使保安熟知保安工作性质、地位、任务、及工作职责权限，同时全面掌握保安专业知识以及在具体工作中应注意的事项及一般情况处置的原则和方法。
2）消防知识及消防器材的使用
通过培训使保安熟知掌握消防工作的方针任务和意义，熟知各种防火的措施和消防器材设施的操作及使用方法，做到防患于未燃，保护公司财产和员工生命财产的安全。
3) 法律常识及职业道德教育
通过法律常识及职业道德教育，使保安树立法律意识和良好的职业道德观念，能够运用法律知识正确处理工作中发生的各种问题；增强保安人员爱岗敬业、无私奉献更好的为公司服务的精神。
4) 工作技能培训
其中专业理论知识内容包括：保安理论知识、消防业务知识、职业道德、法律常识、保安礼仪、救护知识。作技能训练内容包括：岗位操作指引、勤务技能、消防技能、军事技能。
二．培训的及要求培训目的
安全生产目标责任书
为了进一步落实安全生产责任制，做到“责、权、利”相结合，根据我公司2015年度安全生产目标的内容，现与财务部签订如下安全生产目标：
一、目标值：
1、全年人身死亡事故为零，重伤事故为零，轻伤人数为零。
2、现金安全保管，不发生盗窃事故。
3、每月足额提取安全生产费用，保障安全生产投入资金的到位。
4、安全培训合格率为100%。
二、本单位安全工作上必须做到以下内容：
1、对本单位的安全生产负直接领导责任，必须模范遵守公司的各项安全管理制度，不发布与公司安全管理制度相抵触的指令，严格履行本人的安全职责，确保安全责任制在本单位全面落实，并全力支持安全工作。
2、保证公司各项安全管理制度和管理办法在本单位内全面实施，并自觉接受公司安全部门的监督和管理。
3、在确保安全的前提下组织生产，始终把安全工作放在首位，当“安全与交货期、质量”发生矛盾时，坚持安全第一的原则。
4、参加生产碰头会时，首先汇报本单位的安全生产情况和安全问题落实情况；在安排本单位生产任务时，必须安排安全工作内容，并写入记录。
5、在公司及政府的安全检查中杜绝各类违章现象。
6、组织本部门积极参加安全检查，做到有检查、有整改，记录全。
7、以身作则，不违章指挥、不违章操作。对发现的各类违章现象负有查禁的责任，同时要予以查处。
8、虚心接受员工提出的问题，杜绝不接受或盲目指挥；
9、发生事故，应立即报告主管领导，按照“四不放过”的原则召开事故分析会，提出整改措施和对责任者的处理意见，并填写事故登记表，严禁隐瞒不报或降低对责任者的处罚标准。
10、必须按规定对单位员工进行培训和新员工上岗教育；
11、严格执行公司安全生产十六项禁令，保证本单位所有人员不违章作业。
三、 安全奖惩：
1、对于全年实现安全目标的按照公司生产现场管理规定和工作说明书进行考核奖励；对于未实现安全目标的按照公司规定进行处罚。
2、每月接受主管领导指派人员对安全生产责任状的落
本文来源：https://www.2haoxitong.net/k/doc/ee975f796ad97f192279168884868762cbaebb51.html
文档为doc格式