项目管理知识实践应用浅谈
摘要：
随着信息技术的飞速发展，IT系统集成项目越来越复杂，规模也越来越庞大。由于系统集成项目的创造性及多学科参与的特点，引入项目管理，加强各学科协调配合成为IT企业当务之急。项目管理是为了使项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。项目管理者应该从有限的范围、时间、成本要求中寻求平衡，对整个项目实行计划、执行与控制，以便于最大限度的减少项目实施的风险。因此，如何管理好系统集成项目，在系统集成项目的整个实施过程中把握进度、控制成本、保证质量，就显得非常重要。
项目管理理论在建总行对公信贷综合管理系统（CLPM）的建设过程中得到了充分、灵活的运用。项目过程使用范围管理、进度管理、人力资源管理、沟通管理、质量管理等专业管理知识保证项目顺利进行。目前，项目已进入了结项收尾阶段。项目成果已经得到了客户满意的答复。
关键词：
信贷管理系统、项目管理、范围、进度、人力资源、沟通、质量
目 录
项目背景：本项目实施之前，建行各一级分行的信贷系统各自为政，信息缺
乏共享，信息孤岛现象严重，信贷管理带有明显的地域局限性，跨区域信贷管理风险巨大。而部分地区分行的信贷管理还处于手工操作的原始阶段。一把手一人决定，没有信用评定，不走审批流程。信贷风险较大，管理也相当混乱。这些都给其自身带来了巨大的管理风险，也严重束缚了中国建设银行信贷业务的发展。
项目目标：对全行的信贷管理进行标准化，进一步规范信贷业务操作流程，实现信贷业务流程标准化、自动化，加强对信用风险、操作风险的预警和控制。通过设计和实施符合新巴塞尔协议要求的信贷业务流程管理系统，提升信贷风险管理水平与盈利能力。项目总体目标是提升信贷风险和全面风险管理水平，增强核心竞争力和盈利能力，重组上市后，实现股东价值最大化。
2. 项目范围管理
2.1 分阶段实施的方案
建总行CLPM对公信贷系统是一个覆盖全国各级分行的信贷综合管理系统。实施需覆盖的地域范围、实施内容的复杂程度决定了开发完成、全面推广必然需要投入巨大的人力、物力，将历经很长的周期。
针对此情况我们采用 “整体规划、分阶段实施、重点突破，逐步完善”的原则，将整个项目划分为两个阶段。第一阶段着力实现系统信息管理功能、各授信产品审批流程、风险管理流程，保证信贷流程能顺利进行。此阶段完成后将全力推动项目的上线、推广，使之尽快产生相应的经济效益。在第二阶段，项目工作主要划分为两部分。第一部分是积极做好系统的线上运维工作。保证生产系统正常、稳定运行。第二部分是将第一阶段未实现的需要具体划分为不同的层次。根据需求的层次指导相应的版本切换计划，每个层次需求的实现作为一个里程碑，实现需求的逐步完善。两部分工作并行，从而推动项目稳定、有序的进行。
以下附图对第一、第二阶段项目进度、范围规划做了一个说明。
图1. 第一阶段里程碑说明
图2. 第二阶段版本切换计划图例说明
2.2 需求分析的方法论
业务需求分析是明确项目范围的基础。在向用户进行需求调研时，我们将首先根据制定好的需要分析计划、版本切换计划明确需求调用的进度安排。并要求参与调用的开发人员事先了解相关需求的背景、影响。向业务人员提出需求解惑单（见表1），进行需求调用时间安排。调研结果必须形成明确的会议纪要。同时业务人员必须向开发人员提供相关需求的需求说明文档。通过甲方项目负责人确认后最终汇总形成需求说明书。
CLPM项目组业务解惑单
编号：
| 功能名称 |
|
| 提问日期 |
|
| 疑问要点 |
提问人： |
| 解释要点 |
解释人： 审查人： 回复日期： |
| 解释根据 |
|
表1：业务需求解惑单
3. 进度计划与进度控制
进度计划方面，项目组采用project管理工具结合甘特图的方式，在WBS工作包分解的基础上对项目组任务进行统计、划分。当项目进入第二阶段后，又制定了详细的版本切换计划，并严格按照版本切换计划任务执行。项目计划详细而周密。
在进度控制方面，项目组根据Project统计的进度计划，每周定时检查计划完成情况。项目组内以小组为单位，小组负责人负责本组进度的安排、跟踪。组员必须对所安排的任务进行风险评估和任务完成情况反馈。组长将实时根据实际情况反馈完成情况或提出变更请求。每周的项目周例会，项目组也将就本周的任务完成情况做出评估，以决定版本切换计划的执行及变更情况。
4. 人力资源管理
整个项目组由项目管理办公室对项目进行管理。主要包括项目经理组成员以及甲方项目管理人员。
下设上线组、技术组、业务组。
上线组主要负责对生产环境问题的协调、反馈，保证生产环境稳定运行。
技术组划分为：系统设计组、系统运维组、应用支持组、应用优化组。
系统设计组主要负责系统分析、概要设计、详细设计工作。
系统运维组主要负责生产环境问题的分析、处理。
系统优化组主要负责对用户提高的优化建议进行分析、统计并安排修改计划。
开发组又划分为开发一组、开发二组。根据功能模块划分开发内容。两组并行协调展开工作。
业务组人员主要由甲方人员组成。下分为：测试组、业务支持组。
业务支持组人员均由甲方的一线资深业务人员组成。负责完成日常的需求调研，协助需求分析工作。是日常工作的需求确认环节。
测试组划分为：业务测试组、性能测试组。
业务测试组也是由甲方的一线业务人员组成。负责完成日常的业务验证测试，以确认系统功能满足实际业务需要。
性能测试组则由乙方的技术测试人员组成。主要把系统在压力环境下的工作情况作为工作重点。
由于项目进展采用的是循序渐进的工作模式。因此，项目组织结构虽然可能随着项目组的实际需要进行人员调整，但总体结构将在项目生命期中持续存在，以推动项目进展。
图3. 项目组织结构图
5. 沟通管理
一般而言，在一个比较完整的沟通管理体系中，应该包含以下几方面的内容：沟通计划编制、信息分发、绩效报告和管理收尾。沟通计划决定项目干系人的信息沟通需求：谁需要什么信息，什么时候需要，怎样获得。信息发布使需要的信息及时发送给项目干系人。绩效报告收集和传播执行信息，包括状况报告、进度报告和预测。项目或项目阶段在达到目标或因故终止后，需要进行收尾，管理收尾包含项目结果文档的形成，包括项目记录收集、对符合最终规范的保证、对项目的效果（成功或教训）进行的分析以及这些信息的存档（以备将来利用）。
在编制项目沟通计划时，最重要的是理解组织结构和做好项目干系人分析。项目经理所在的组织结构通常对沟通需求有较大影响，比如组织要求项目经理定期向项目管理部门做进展分析报告，那么沟通计划中就必须包含这条。项目干系人的利益要受到项目成败的影响，因此他们的需求必须予以考虑。最典型也最重要的项目干系人是客户，而项目组成员、项目经理以及他的上司也是较重要的项目干系人。所有这些人员各自需要什么信息、在每个阶段要求的信息是否不同、信息传递的方式上有什么偏好，都是需要细致分析的。比如有的客户希望每周提交进度报告，有的客户除周报外还希望有电话交流，也有的客户希望定期检查项目成果，种种情形都要考虑到，分析后的结果要在沟通计划中体现并能满足不同人员的信息需求，这样建立起来的沟通体系才会全面、有效。
本项目由于涉及的是一个用户覆盖面广，业务逻辑负责的系统，而且项目组中甲方成员所占比例较高（近40％主要是测试人员），沟通的管理显得尤为重要。最初采用书面沟通方式，如各项目小组中使用的内部备忘录，以及对客户和非公司成员使用项目报告、日报、周报、报事帖、更改通知单、会议纪要等。随着项目的进展，口头沟通包括会议、评审、私人接触、自由讨论也增加进来。进一步提高了沟通的效率。成功的沟通管理使客户很乐意与我们进行正式的和非正式的沟通，直接影响了项目质量的提高，对项目后期的实施和验收非常有利。同时，使项目各方实现利益最大化创造了良好的基础。
6. 质量管理
项目过程中会出现并可能导致项目差错的情况，主要是工作上的问题。问题管理是项目小组的重要责任，同时也是保证项目实施成功的基础。问题管理的重点在于解决问题或防止问题的恶化、统计问题防止同类问题的发生。在项目管理的过程中，必须保证出现在各个阶段的问题被及时发现和解决。问题应该在下一个项目阶段开始之前得到妥善解决。
这里主要谈一下项目组质量控制的方式、手段。由于项目存在两个阶段，当项目进展到第二阶段时，问题就可具体划分为：生产环境产生的问题、新需求开发产生的问题两类。对此，项目组有一整套问题处理的流程，并将Mercury Quality Center工具（下称：MQC 见图4）用于质量管理过程中，实现对问题处理情况的实时监控。
图4. Mercuty Quality Center工具
当生产环境出现问题时，首先会以《生产环境问题单》（见表2）的形式出现，并在MQC中。系统运维组对问题进行分析、统计，并安排相应的开发组人员处理问题。测试人员将对处理完成的问题进行业务验证测试。最终由系统运维组向用户反馈问题的处理情况。
CLPM系统问题记录跟踪表
编号：
| 项目阶段 | 正式运行 | |||||||
| 子系统名称 | □业务系统 | |||||||
| 功能名称或编号 | □界面 □录入域 □BUG □功能 □边界值 □其它 | |||||||
| 用户编号
| 经办机构名称 | 象山支行 |
|
| ||||
| 客户名称 |
| CLPM客户编号 |
| DCC客户编号 |
| |||
| 额度编号 |
| 业务编号 |
| 信贷品种 |
| |||
| 合同编号 |
| 债项编号 |
|
|
| |||
| 问题描述:
业务支持人员签字： 日期： 年 月 日 联系电话 上线组负责人签字： 日期： 年 月 日 | ||||||||
| 问题 分析 处理 结果 | 是否修改软件：□是 □否 是否提请项目负责人审批：□是 □否 指定修改责任人： 完成期限： 年 月 日 问题类型：□致命错误 □重大错误 □一般错误 □需求变更 □放弃 □需讨论 影响范围（涉及的子系统、数据库表和配置文件等）：
修改原则或修改方法：
分析人签字： 日期： 年 月 日 技术网站回复： □问题已解决 □问题已查明，预计 月 日解决 □该问题延期处理 | |||||||
| 项目 负责人 签字 |
| |||||||
| 分行 机构 确认 意见 | 是否通过：□是 □否 确认意见：
问题提出人： 日期： 年 月 日 业务支持人： 日期： 年 月 日 | |||||||
表2 CLPM系统问题记录跟踪表
当新需求开发出现问题时，首先会记录在MQC中，并分配给相应的开发人员处理。问题处理完成后，有测试人员进行业务测试。最终将由设计组确认该问题的版本切换计划，决定最后的上线计划。
总结问题跟踪按照下列方式执行：发现问题及时反映－>跟踪问题－>解决问题－>问题解决验证－>问题解决后体现在生产环境上。
问题发现人反映：项目组人员验证问题、确认问题类型、分析呈交的问题并决定是否在项目实施范围之内，分别采取如下措施：
1、问题拒绝：包括生产问题、新需求开发问题，因其与项目无关或超出项目范围；
2、问题推迟：推迟呈交的问题，因其附属于其它问题或暂无法解决；
3、问题转交：问题涉及设计、需求方面的变更，需要转交设计组、业务支持组进行分析、确认并制定问题处理方案。
4、问题接收：接受与项目相关的问题，进行问题处理；
问题解决的跟进：各组负责人将每日对本组问题的状态、进展情况进行统计，督促所有未解决的问题的解决。问题描述应尽量详细，并需要记录。项目组人员发现问题，先进行分析原因，能自己解决的自己解决，并作记录。如果不能解决，就将解决的方式和步骤记录下来，一起提交小组责任人。
问题引起的变更：部分问题经分析需要进行设计变更的，开发人员需首先将问题对应MQC告知相关设计人员，由设计人员确认变更的必要性。当设计人员确认需要进行变更时，设计人员将发起关于该问题需要讨论的会议。会议讨论的结果将做问题需求变更的重要依据。据此将应发相应的范围变更、计划变更等。
问题的统计： 针对生产环境问题，项目组采取了问题统计的机制。通过对同类问题的统计、整理，汇总出了一整套问题处理的方法论。使生产线上一部分非技术类问题由系统运维组通过问题处理方法论解决。从而提高了问题反馈的效率。
特殊问题特殊处理：如果问题在预计的时间无法解决，并会影响项目的进展，则问题必须按非常规的程序得到处理。首先对未完成的原因分析，制定后续行动，明确人员和时间；若需要，调整项目计划保证问题得到解决。
问题跟踪过程的记录：项目实施过程中出现的问题，从提出到最后解决，都应用在MQC中详细记录下来。从而形成记录的形式，以便日后查询统计。
7. 项目管理总结
由于文章篇幅的关系，这里只对以上几点进行了一个简要论述。但总体而言，项目管理理论在系统集成项目中发挥了重要的作用，使工作进展有序进行，既完成了工作又保证了项目的质量，达到了满意的效果，实现了我方与客户的利益最大化。
参 考 文 献
1．（美）凯西.施瓦尔贝著：《IT项目管理》，机械工业出版社，2004年
2．对公信贷管理系统（CLPM）项目管理规范手册
2563
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
