大型复杂IT项目管理实践第一篇大型复杂IT项目的特点和管理难点文档格式.docx
《大型复杂IT项目管理实践第一篇大型复杂IT项目的特点和管理难点文档格式.docx》由会员分享，可在线阅读，更多相关《大型复杂IT项目管理实践第一篇大型复杂IT项目的特点和管理难点文档格式.docx（25页珍藏版）》请在冰豆网上搜索。
以“市民卡项目”为例，市民卡是政府为市民提供服务的一种新的载体，反映了政府工作理念由管理型向服务型的转变，这就需要各个政府部门打破在管理上条块分割的局面，因此“市民卡项目”会涉及到多个政府部门的业务。
这些业务如何开展、跨部门业务流程如何协同仍处于探索阶段，该项目关系到国计民生，与普通市民的日常生活、切身利益密切相关，需求变化较频繁，不易掌控。
需求随着项目的进展逐渐明确，但是还可能不断演化、扩展甚至推翻，很多失败的软件项目往往因为需求变化的不可控而导致项目进度延期和成本投入加大。
需求分析的关键是：
不但要满足用户提出的“明确”要求，还要满足用户未提出的“潜在的期望”，软件项目的需求开发和管理是重点和难点。
2）
人力资源管理难度大
大型复杂IT系统建设的主要工作是技术密集型的工作，项目的工作成果主要依赖项目团队成员的脑力劳动结果，项目团队成员的知识经验、精神状态等对工作成果的质量和工作效率有根本的影响，人的能力和所发挥的作用是决定系统成败的关键因素，因此团队的建设、人力资源管理有很重要的地位，也有较高的难度。
2.
系统建设技术难度大，涉及面复杂
大型复杂IT系统的技术难度大，涉及多种学科技术，需要组织协调骨干力量进行技术攻关。
例如在“市民卡项目”中，需要解决海量数据存储、大数据量业务处理的问题；
需要完成加密算法的大规模应用以实现个人身份信息、业务应用信息的安全管理；
需要实现各种“异构系统”之间的多种业务数据的共享交换；
需要完成卡片的技术选型和芯片研制等工作。
3.
多部门多单位参与，项目组织协调难度大
对于大型复杂IT项目，总集成商经常需要调集公司内部多个部门的兵力协同作战，并领导多个分承建单位共同参与建设，组织和协调难度很大，表现在以下几个方面：
不同部门、不同单位的人员的能力、素质和行为对项目会产生重要影响，而这些不确定因素很难预测；
不同单位的项目团队需要建立互相信任和合作的关系，然而由于彼此分散在不同的地点办公，这对于需要密切配合的工作是一个挑战，沟通量和沟通难度很大；
负责大型复杂IT项目的项目经理要能够管理多个部门、多个外部单位的项目团队以及众多的个人。
除了项目经理所在部门的团队成员以外，还有很多人员与项目经理并没有行政隶属关系，因此造成项目经理的控制能力和约束能力相对较弱；
4.
不同单位在项目中都要追求自身利益最大化，容易出现推卸责任、为了局部利益而损害项目全局利益的情况，并导致进度延期和成本超支等问题。
例如在“市民卡项目”中，公司内部的四个部门、十几个分承建单位和软硬件供应商参与了系统建设，一百多家医院系统开发商参与了系统对接工作。
该项目牵涉到多个政府部门、开发商的利益和权益，要真正实施起来，可以说是困难重重。
多卡割据的局面也使得市民卡在应用领域推广时会处于一个非常复杂的应用环境中，与相关部门和合作伙伴的关系比较复杂，而系统能够满足各方的需求和权益是系统得以推进的基础，这就需要在多方复杂的矛盾之中善于平衡、协调。
统筹管理大量紧密关联的子项目
大型复杂IT项目一般会被分解成多个子项目实施，子项目彼此之间在技术、业务和管理方面有紧密的内在联系，例如在“市民卡项目”中，数据共享交换平台需要为其他子系统服务，稳定传输业务信息；
数据采集子系统要给制卡生产管理子系统提供市民基础信息，进行卡片的生产和制作；
卡服务网站、呼叫中心与卡服务管理子系统之间有多个数据查询接口等等。
以上特点体现在项目管理上，表现为多个子项目之间的工作任务存在着紧前紧后关系，多个子项目的进度、人力资源的调配存在着互相制约的关系，需要很好地解决多项目管理中合理分配共享人力资源、协同安排项目进度的问题。
5.
项目规模大、建设周期长、社会影响大
电子政务领域的大型复杂IT项目一般涉及到政府为民服务领域，关系到国计民生，涉及到的用户群庞大、覆盖范围广，社会影响大，建设周期长，充满了复杂的未知、不确定因素，在技术、需求、工程组织管理方面有很多风险，需要有很强的风险意识和风险控制能力。
例如“市民卡项目”在大型城市实施，一般会涉及千万人口，覆盖一两千家医疗机构，建设周期以年单位，项目规模会达到几千万甚至几亿。
在理解什么是大型复杂IT项目时，还需要注意区别以下概念：
“大型”和“复杂”是两个关联而有区别的概念，有时大型项目不一定是复杂项目，复杂项目也不一定就是大型项目。
复杂项目的一个典型特征就是对于大量界面的管理，以及由子项目经理而不是项目经理来管理的大量子项目。
在复杂程度较低的项目中，项目经理直接对项目团队进行管理。
在复杂项目中，项目经理负责管理子项目经理、众多的个人、公司中不同的部门和多个外部的单位。
“管理的复杂程度”与“技术的复杂程度”是有联系但又截然不同的两个概念。
技术的复杂会一定程度上带来管理的复杂，但并不是决定因素，例如一个技术难度很大的项目，也许比较容易管理，而一个管理难度很大的项目，其技术难度可能很一般。
决定“管理的复杂程度”的主要因素在于被管理对象（包括外部单位、不同部门和个人等）众多以及彼此之间具有错综复杂的矛盾和利益关系。
大型复杂IT项目管理实践第二篇成功经验---1.建立新型的项目组织结构
下面将从项目整体管理的角度，结合项目管理实践谈谈如何管理大型复杂IT项目。
建立新型的项目组织结构
合理的组织结构有利于项目获得所需的资源，有利于降低对众多项目相关方协调的难度，有利于增强对项目的控制能力，对于大型复杂IT项目是至关重要的。
下面是传统的项目组织结构图：
图1-传统的项目组织结构图
在图1中，业主单位负责人直接对多个承建单位进行管理，协调多个承建单位之间出现的问题。
当系统建设周期很长、承建单位很多时，甲方为了解决具体问题，要花费大量时间和精力了解技术和实施细节，这不利于甲方集中精力对项目进行总体规划和宏观管理。
为了避免这种情况，在“市民卡项目”中，采用“总体统筹负责制”的方式建立了新型的项目组织结构，如图2所示：
甲方授权一位高层负责人作为甲方项目经理进行项目管理，总集成商（乙方）选派一名经验丰富的项目经理（下文中简称高级项目经理），协助甲方对众多承建单位进行管理，统筹负责系统的建设、运行和维护，并向甲方项目经理汇报；
子项目分别由总集成商及分承建单位的项目团队实施，分承建单位的子项目经理代表本单位对子项目负责，并向乙方项目经理汇报，项目管理办公室（PMO）帮助乙方项目经理对各个子项目进行更好地组织、协调，对同时开展的各子项目进行多项目综合管理；
在承建单位发生问题时，由于乙方对其没有直接的行政管理权利而在一定程度上处于弱势地位，此时由甲方出面协调，发挥甲方的权威约束作用，增强乙方对项目的控制能力，这是利用了管理的借力原则。
图2-新型的项目组织结构图
大型复杂IT项目由于涉及到多个学科复杂的专业技术，一般需要聘请相关专家进行深入研究和论证，为此“市民卡项目”建立了专家组，成员来自于科研院所以及相关技术管理机构，对系统的方案进行把关和评审。
大型复杂IT项目管理实践第三篇成功经验---2.关注高层次管理，关联性管理
关注高层次管理，关联性管理
1）
高级项目经理的关注点
大型复杂IT项目一般会被分解成多个子项目进行实施，由高级项目经理负责与各方用户及项目相关方沟通协调、确定项目范围，制定项目总体计划，审批各子项目计划并审核各子项目的里程碑，负责各子项目之间的资源、进度的统筹协调和调配。
各子项目的日常管理工作应由子项目经理完成。
高级项目经理的关注点在于：
高层次的项目管理以及各子项目之间关联关系的管理，这个原则会体现在各个方面，如下表所示：
高级项目经理
的主要工作
子项目经理
需求
分析
审批子项目需求分析报告，形成子项目需求基线
管理子项目需求之间的关联关系，关注某个子项目的需求变化可能对其他子项目产生的影响
负责子项目的需求分析工作，完成子项目需求分析报告
系统
设计
负责系统总体技术方案
组织、协调子项目团队进行子系统间的接口设计
负责子项目的系统设计工作，完成系统设计报告
参与不同子系统之间的接口设计工作
测试
对子系统进行验收测试作为子项目验收的依据
负责子项目的内部测试工作
制定
项目
计划
负责制定项目总体计划，明确各子项目在人力资源、进度方面的关联、制约关系
负责审批子项目计划
负责制定子项目计划
监控
执行
审核各子项目的里程碑
监控项目总体计划中关键路径上关键任务的完成情况
解决各子项目实施过程中在人力资源、进度协调方面的冲突和问题
监控子项目的日常工作，及时发现子项目的问题并解决
沟通
协调
在客户、监理、各分承建单位之间沟通、协调
组织、促进各子项目在需求、设计和项目管理等方面的沟通
负责子项目内部的沟通协调，并与其他子项目团队沟通
人力
资源
管理
统一调配公司内的多个子项目团队成员，提高人力资源的共享程度和利用率
管理子项目经理和子项目团队
直接管理子项目团队成员
配置
负责对项目总体计划、子项目计划、子项目需求基线、设计基线以及重要会议纪要等进行配置管理
对项目例会、重要会议的纪要等负责配置管理
负责子项目的所有相关文档和代码等的配置管理
根据上表，高级项目经理的管理思路和重点总结如下：
对项目进行高层次管理：
关注项目总体计划中关键路径的关键任务，关注关键人力资源的调配，关注各子项目的基线和里程碑，关注总体技术方案，关注子系统交付质量；
对子项目间的关联关系进行管理，涉及各子项目的需求、技术、进度、资源和沟通等各个方面。
高级项目经理每周通过“系统建设核心组”召集各子项目经理，召开项目每周工作例会，了解一周以来各子项目在技术、进度、人力资源、质量以及成本等方面的状况和存在的问题，针对问题研究解决方案，落实责任人。
项目周例会是一个“检查点”，在管理各子项目间的关联任务方面具有重要作用，可以及时发现某些任务的拖延。
对于进度落后的单位，要严格要求其调整，不能耽误其他单位后续任务的完成。
对于会对多个单位的后续任务造成影响的任务，高级项目经理应尤其重视。
例如在“市民卡项目”中，卡驱动应用接口完成开发后，要分发给一百多家医院应用系统开发商进行系统对接，开发卡驱动应用接口的工作如果拖延或者质量发生问题，则需要对后续的对接工作进行重新安排和部署，影响面很大。
因此要严密监控这个任务的进度和质量，防止对后续工作带来重大的不良影响。
2）
高级项目经理容易犯的错误
高级项目经理要对自己有准确的定位，坚持把时间和精力花在高层次的、子项目关联关系的管理工作上，一定要避免陷入子项目的具体管理工作。
当子项目经理来自分承建单位时，高级项目经理不容易犯这个错误，但是当子项目经理是自己的下属，而又没有起到应有的作用时，高级项目经理为了工作不受影响，容易越俎代庖，跨过子项目经理直接去过问子项目的进度、质量，发现日常工作的一系列问题，并亲自出面解决。
这种情况会成为项目的一个风险，高级项目经理会因此而忽略了项目的整体管理，而且导致项目团队中责任、权力和汇报关系的混乱，不利于扭转被动的局面。
如果子项目经理能力弱、不称职甚至因有对立情绪而故意设置障碍，高级项目经理应通过强有力的领导使子项目经理担负起自己的职责，而不能代替子项目经理工作，这对高级项目经理的个人影响力、领导能力提出了更高的要求。
大型复杂IT项目管理实践第四篇成功经验---3.多组织分工协作、利益平衡
多组织分工协作、利益平衡
采用集中作战室，加强跨组织沟通协作
大型复杂IT项目的团队成员通常来自不同的单位和部门，由于办公地点分散而容易导致沟通不畅，“集中作战室”（WarRoom）是解决这个问题的好方法。
在“市民卡项目”的关键时期，曾多次采用了“集中作战室”的工作方式，不仅加强了项目团队成员之间的沟通，显著提高了工作效率，还有效地增强了团队的凝聚力。
在确定总体技术方案的过程中，需要多个项目团队紧密沟通、协同作战。
各分承建单位的技术骨干全部集中到同一地点办公，在办公空间的墙上挂满了项目整体计划、设计方案架构图等，办公室就像是作战的指挥中心。
这种环境营造了一种紧迫的工作气氛，各子项目的技术骨干充分、频繁地就总体技术方案进行沟通，一起围绕在墙上挂的架构图、设计方案讨论，确定系统总体架构以及子系统之间的接口方式，非常有效地加快了设计总体技术方案的速度。
在上线前的系统测试阶段，采用“集中作战室”方式，由各家单位选派骨干测试人员建立一个统一的系统测试组，对即将上线的系统进行全面的测试。
需要测试的业务流程包括采集市民基础信息、产生实名信息、印刷卡片、制作和发放卡片、卡片挂失退换服务以及在医院持卡就医结算等流程，整个业务流程会贯穿多家单位的多个子系统。
测试工作打破了所属单位的界限，完全按照实际业务流程划分测试任务，模拟真实的系统运行环境，对系统进行全面测试。
每天的测试结果按照不同的严重等级进行BUG数量的统计，并制作成报表挂在墙上，营造了一种紧迫感和互相监督的氛围，有效督促了各个单位在系统上线前全力以赴，为系统顺利上线做好准备工作。
平衡多组织局部利益，保证项目全局利益
在大型复杂IT项目中，各分承建单位之间的利益、分承建单位的局部利益与项目全局利益经常是矛盾、冲突的，这种矛盾和冲突有多种表现形式，以“市民卡项目”为例，列举两个例子：
某分承建单位不能按照计划按时提交工作成果，已提交的部分质量也很差。
在要求限期改正后，分承建单位又提出种种理由尽量拖延，观察到他们的开发人员非常疲惫，这是为什么？
后来了解到：
这些开发人员经常加班赶其他项目的进度，挤占了本项目的工作时间。
目前很多单位为了控制成本在多个项目之间共享开发人员，这在一定程度上会造成某些项目不能得到足够的人力资源而拖延进度、质量受损。
分承建单位的利益冲突还会表现为需求冲突。
市民卡在医院的应用需要确定机构的唯一标识，这是一个关键的数据项，在多个分承建单位的子系统里都要使用。
项目初期规定采用地方标准，但某分承建单位提出质疑，要求采用行业标准（这是出于产品修改成本、在商务方面占据有利地位等多种因素的考虑），并因此发生比较激烈的争议。
各分承建单位作为理性的市场参与者，在项目中都有自身利益和权益的诉求，都要追求自身利益的最大化。
为了扩大自身利益、降低自身风险，分承建单位有可能做出有损于项目全局利益的事，甚至有些单位为了满足局部利益而牺牲项目整体利益，遇到问题推卸责任、拖延进度、降低质量。
针对这种情况，高级项目经理要保证项目的全局利益，通过与分承建单位的“高层领导”沟通解决问题，即所谓擒贼先擒王，通过强有力的管理进行严格控制，绝不能因为分承建单位的局部利益影响到项目整体的进度和质量。
高级项目经理要主动分析，随着项目的进展，会对分承建单位带来哪些利益和风险，进而考虑如何平衡各分承建单位的利益和目标的冲突，从而减少项目的阻力，使来自不同单位的参与人员形成一个团结合作的项目团队，为项目工作的顺利开展铺平道路。
高级项目经理要与甲方保持密切的沟通，使甲方了解、掌握项目进展的动态，以便使甲方更充分地参与到项目管理工作中。
这样，当项目执行过程中出现难以解决的问题时，高级项目经理就可以借助甲方的力量，增强自己对项目的组织、协调和控制力度。
大型复杂IT项目管理实践第五篇成功经验---4.关注沟通管理
关注沟通管理
大型复杂IT项目涉及很多机构和单位，参与人员众多，各家单位的系统有大量复杂的接口，彼此之间的工作互相制约、依赖，有效地进行工程的组织协调是一项具有挑战性的工作。
大型复杂IT项目包括的任务数量非常大，而且都是智力密集型的劳动，需要挖掘人的潜能、主观能动性和创造力，因此沟通的效果对于项目是否能获得成功是非常重要的。
只有注重沟通，才能科学地组织、指挥、协调和控制项目的实施，才能够建立和改善人际关系，营造一个良好的内部和外部环境，才能使项目整体团队有凝聚力、向心力。
采用正式沟通渠道，控制项目进展
根据项目进展情况，高级项目经理可以定时（如每周或者每月）通过系统建设核心组（参见“新型的项目组织结构图”）召集各相关方召开项目工作例会，甲方项目经理、各子项目经理、监理方是必须参会的成员。
高级项目经理通过会议了解各子项目在技术、进度、人力资源、质量以及成本等方面的状况和存在的问题，针对问题研究解决方案，落实责任人，并识别、分析和记录可能存在的风险，落实后续的主要工作任务，如果有任何影响工作完成的问题则提出，在会议上进行讨论，如不能当时解决则记录下来在会后协调解决。
项目工作例会应形成会议纪要，在会后对照会议纪要，分别检查各子项目围绕会议决定的工作执行情况，并形成会议纪要检查表，下发至各子项目组成员。
高级项目经理会后综合各个子项目的进展情况，形成项目总体进展报告定期向客户方项目领导小组汇报。
建立项目特殊情况报告制度，当遇到重大问题，如技术难题、人力资源冲突、重大质量问题和进度问题时，各子项目经理可以书面形式或口头形式与高级项目经理进行沟通，高级项目经理组织相关人员讨论解决方案并落实相关工作的责任人。
采用非正式沟通，营造和谐的团队文化
在大型复杂IT项目中，经常需要各分承建单位的项目团队紧密配合共同完成工作。
来自不同单位的项目团队成员开始时彼此陌生，容易发生一些摩擦，会有一个互相磨合、适应的过程。
例如在“市民卡项目”中，卡管理系统与医疗信息系统分别由A、B两个单位负责开发，在联调接口的阶段，两个子项目经理协商好，A单位的技术人员去B单位的办公地点共同联调。
但是当A单位人员按时到达后，B单位并没有做好准备，使A单位的人员等待了较长时间。
在联调过程中A单位又发现B单位的程序有较多错误，更加不满，埋怨、责备了对方，还有个别人员之间发生了正面冲突，气氛很紧张。
最后，A单位向高级项目经理投诉了B单位，联调工作受到一定程度的影响。
解决这个问题，可以采用公事公办的方式，分清各方责任，这是必要的，但是容易造成双方的对立情绪。
如果在正式沟通的基础上，能适当地采用非正式沟通方式，则能够在不同项目团队之间营造和谐的气氛，建立良好的关系。
高级项目经理可以适当组织一些体育活动、聚餐活动，为不同项目团队的核心人员（包括子项目经理及技术骨干）建立非正式的沟通渠道。
在轻松的活动中，大家会很快地熟悉并成为朋友，彼此关系融洽了，在处理很多事情时就不会站在互相对立甚至拆台的立场上，强调责任的界限和范围，而是能够互相包容，共同面对问题，积极解决问题。
3）
通过横向、纵向沟通实现跨单位、跨部门协调
大型复杂IT项目通常需要跨部门协作，有多个子项目的骨干人员是来自于公司其他职能部门，这些人员与本部门任命的子项目经理之间没有明确的上下级关系，而且这些人员并不是全职服务于本项目，同时还承担着其所在部门的一些工作，因此给本项目的管理带来较大的难度。
例如在“市民卡项目”中，抽调了其他部门的系统设计员、测试人员、系统工程师和实施人员，这些人员被分配给“市民卡项目”的多个子项目，子项目经理由本部门骨干人员担任，负责实施子项目的设计、开发和运行维护任务，按照矩阵式的管理模式进行项目管理，如下图所示：
图3-矩阵式组织结构中的跨部门管理
上图是一个简化的组织结构，为了突出一个特点，即项目团队成员来自于其他部门，子项目经理需要对这些“没有管辖权力”的人员进行管理。
在大型复杂IT项目中，经常会遇到这种跨部门协调的问题：
如何协调长期性组织（即职能部门）与项目组织之间的关系，子项目经理在遇到这类问题时普遍感到比较困惑。
例如，子项目经理X所管理的开发人员A总是不能按要求完成任务，平时也很少向X报告工作，而且A经常不在岗，自称是部门2有事，也从来不提前告诉X。
X感到很难与A沟通，无法管理，希望项目经理帮助解决。
开发人员A虽然被抽调到项目组，但是对其有“权威管理权力”的却是他所在部门的领导，当项目工作与部门工作发生冲突时，A肯定要优先完成部门工作。
在最初面临这个问题时，项目经理直接去找A的部门经理反映，转达了X的意见，部门经理答应与A沟通一下，但是沟通的结果完全出乎意料，A认为事情不是X说的那样，而且认为X的工作安排有问题。
部门经理向项目经理反馈A的意见，并说A的一贯表现还是不错的。
项目经理发现问题并不简单，如果再去找X核实情况，X又认为A说的不对，就需要反复验证，这个过程采用了纵向沟通方式，沟通环节太多，沟通效率低，效果也差。
项目经理意识到在这种需要多方参与，反复交换意见、提供反馈的情况下，应采取横向沟通方式，把需要沟通的多方聚到一起，当面讨论解决问题。
于是项目经理带X去找部门经理，首先表明项目进展很紧迫，有些问题必须要解决，请A与X就工
升级会员 