信息系统项目管理师(论文)

信息系统项目管理师

[键入文档副标题]

Owner [选取日期]

[在此处键入文档的摘要。摘要通常是对文档内容的简短总结。在此处键入文档的摘要。摘要通常是对文档内容的简短总结。]

1、论项目的范围管理（3182）

一、范围计划编制

项目范围的管理也就是对项目进行相应的定义和控制。每个项目都必须慎重地权衡范围管理所使用的工具、方法、过程和程序以及一些其他因素，以确保在管理项目的范围时所做的努力与项目的规模、复杂性和重要性相符，制定范围管理计划显得由为重要。在计划中明确定义项目范围、制定详细范围说明书、定义和编制工作分解结构以及验证和控制范围的步骤和方法。本项目范围计划中规定定义和编制工作分解结构的步骤为：识别项目交付物和相关项目工作;对WBS的结构进行组织;对WBS进行分解;对WBS中各级工作单元分配标识符或编号;对当前的分解级别进行检验，以确保它们是必需的而且是足够详细的。 二、范围定义

范围定义过程是详细描述项目和产品的过程，并把结果写进详细的项目范围说明书中。详细范围说明书主要包括如下内容：

⑴项目的目标。包括成果性目标:对开阳县已发生山洪灾害区域建设起监测网络预警系统，并逐步完善重点区域的山洪灾害防御预案、强化群测群防体系、宣传防御知识、提高全民防灾减灾意识等非工程措施为主的建设，有效防御山洪灾害，改变开阳县山洪灾害对区域经济带来的不利影响，减少人员伤亡和财产损失，同时也为我省山洪灾害防御规划项目的全面实施积累经验。

⑵产品范围描述：根据开阳县的具体情况，拟定在开阳县境内布设51个简易雨量站、11个人工雨量站（自记录雨量站）、2个人工水位站、16个自动水雨情信息遥测站(其中7个遥测水位站，9个遥测雨量站)；同时根据防御山洪灾害的要求，确定防御预案编制的要求；并结合山洪灾害公众参与要求，监理群测群防的组织体系以及加强组织宣传、培训等方案。

⑶项目的可交付物.包括设计原则、总体设计机构、系统建设模式、水雨情监测子系统、信息汇集与预警平台软件、防御预案的编制等。

⑷项目边界：群测群防功能的实现、短信自动报警、无线广播系统的自动广播等； ⑸项目验收标准。提交可交付物后先根据国家政策文件和相关标准以及与客户一起进行评审，然后进行系统试运行，试运行正常且稳定后进行验收。

⑹项目的约束条件。人员紧缺，且项目相当负责，在国内能进行参考项目数量极少的;

- 2 -

且开发时间紧。

⑺项目的假定。 三、创建WBS

该系统因涉及的环节多而复杂，需要做的工作也很多，为了详细描述项目所要完成的工作，避免应该做的工作被遗漏掉，方便项目团队成员间沟通，我邀请了组长、系统分析师及其他项目经理参加以“项目工作分解”为主题的会议，会议上对项目可交付物和项目工作按照滚动波式计划逐步分层分解为更小的、更易于管理的项目单元。分解工作按照以下原则进行：

⑴在各层次上保持项目的完整性，避免遗漏必要的组成部分; ⑵相同层次的工作单元应有相同性 ⑶一个工作单元只能从属于某一个上层单元 ⑷工作单元应能分开不同的责任者和不同工作内容 ⑸便于项目管理进行计划和控制的管理需要

⑹最低层工作应该具有可比性，是可管理的，可定量检查的 ⑺最低层次的工作单元是工作包 ⑻应该包括项目管理工作 四、范围确认和范围控制

在项目实施过程中，根据WBS上的可交付物进行监控，对已经完成或即将完成的可交付物及时进行会议评审，涉及核心业务的，提供相关文档由客户一起进行确认。比如，在山洪灾害短信自动报警功能开发完成后，我组织组长、系统分析师依据政策文件逐一进行会议评审，评审后要求测试人员写测试文件，并将系统计算出的结果截图附在测试文件中，发送给客户相关人员进行确认。

项目开发过程中，项目范围往往发生会不断变化，为了防止“范围蔓延”，我和项目的相关成员及负责人共同制定了变更控制流程；并对开发过程进行密切跟踪，最终常规功能模

- 3 -

块在试运行规定时间前完工，对于未开发完的非常规功能我们采取客户现场开发的措施。 五、资源冲突的解决

该系统因功能面广而复杂，考虑到部门实际情况，我将系统分解成3个相关联的子系统(遥测站系统、数据接收与数据核实系统、预警发布系统)，并同时进行开发和遥测站的安装及调试，并将项目组分成3个小组，每小组配备6至7人进行开发和实施。涉及的开发人员多，需要从其他项目组抽调开发人员过来；因负责中心业务系统开发的４个人时时不能从遥测站设备安装的人员中抽调过来，如果不能及时解决此问题将严重影响项目的进度。在与其他项目经理协商无果后，我及时与公司领导沟通协商，阐述此项目的重要性，并与公司相关领导沟通后，最终决定先招聘４个外包人员进驻我公司，顶替不能从其他项目组抽调过来的人员进行开发。随着外包人员的进入，有力地保证了所需的开发人员数量，项目进度得到了有力保障。

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

1、在需要客户确认时，与客户的沟通方式太单一，只是一味等待，导致某些工作落后于进度计划，并影响到项目整体进度。

2、客户提出新需求后没有跟客户进行很好的协商，试运行成功后直接进行了新需求的调整，导致验收时间推迟了１个多星期。

2、论项目的进度管理（3184）

一、在计划阶段做好工作量预算

- 4 -

我们使用经典瀑布模型与原型法相结合的开发方法，把开发过程划分为需求分析、原型开发、设计、编码、测试、部署等步骤，并在此基础上创建了工作分解结构WBS和制定详细的进度表，我们认为工作量的估算是制定进度表的基础，对于项目的进度管理十分关键，由于我们对代码行估算和功能点估算等估算方法研究不是很深入，工作量的估算还是主要采用基于公司项目历史绩效数据库和个人经验的估算方法，对WBS每项活动我都先确定具体的人员，然后需要对活动本身进行详细的分析，最后需要为各项活动建立依赖关系，明确各项活动的前置任务，活动的开始时间，结束时间。

同时我们开发的这个系统是基本C/S结构的，由于C/S结构的系统我们公司有不少的成功案例，因此有不少的案例供我们参考。对于本系统的部分功能我们就是借鉴以前我们做过的基本C/S结构的系统，基本C/S结构的系统的框架基本上是一致的，数据库设计、前台操作，如对数据库进行添加、删除、修改、查询、打印等一系列活动大体相同。正是如此，有大量的东西可供我们复用，如权限控制模块我们就是复用以前的案例，仅作少量修改。在工作量的估算上也有很好的借鉴作用。这对工作量的估算也是一个重要的参考，为工作进度安排提供了依据。

根据上述分析我们制定了一个详细的进度表并定义相应的里程碑。 二、识别关键任务

项目管理是该系统的核心部分，客户关系管理，库房管理，财务管理基本上都是建立在

项目管理基础之上，项目管理部分直接影响到整个项目。因此该部分是整个系统的关键部分，在系统设计和设计实现时，应该是重点考虑。

工作流管理部分，是用户着重提出的要求实现的功能，直接面对用户，这部分的成功与

否直接影响到该系统的质量，因此也是不容忽视的。

如果上述两部分任务的进度受到影响，则整个项目的完成将受到威胁，因此是本项目的

- 5 -

关键任务。在进度控制时我们将其作为重点对像进行控制。

三、在项目的全过程中有效管理和控制风险因素

项目中我们对项目进行了必要的风险管理，以避免风险时间的发生导致进度的失控，公司项目管理部提供了完整的项目风险管理计划模板和风险时间列表模板，为了让项目组在项目各个阶段保持良好的风险意识，我采用了“风险事项跟踪”，把项目中各主要的风险时间按照排名张贴在公告栏上，由于当时有部分未明晰的需求包括：项目管理变更和项目中止执行流程需求不明确，客户方面可能提出新的需求…需求范围界定不清，计划不充分，用户参与不足，缺乏领导支持，技术问题等成为我们项目的主要风险事件，事实表明，这种做法非常有效。特别是客户方面，我定期把风险事件列表交给给客户方负责人，为了能尽快落实未明晰的客户需求，我与客户方负责人进行了面对面的沟通，通过一番利弊关系的陈述，达成了尽快明晰悬留部分需求的共识，需求问题很快得到解决，项目组整体信心十足，积极性和责任感增强。

四、在实施阶段进行进度跟踪和控制，必要时调整进度表

项目的进度管理并不是一个静态的过程，在项目进度的管理过程中，需要不断调度、协调，保证项目的均衡发展，实现项目整体的动态平衡。实施阶段要进行进度的跟踪和控制，在确定项目开发计划时，我们制定了详细的工作进度表，在确定每项任务时都确定了该任务的工作量、开始时间、结束时间、持续时间；同时要让每个小组成员都知道自己承担的任务时间表，根据自己的任务制定详细的工作计划.

工作日志是了解每个小组成员工作情况的最好方式，我要求每个小组成员都要对自己的工作情况做日志，详细记录自己每天的工作，每周对自己的工作做总结。小组成员把各自本周内完成的任务进度情况和下周任务计划做出汇报，报告要严格按照百分比量化任务完成的情况，每个小组成员都要对自己的总结报告做出负责，我把各项任务实际完成数据输入到

- 6 -

项目进度计划中，Project自动完成甘特图的绘制，通过查看甘特图就可以较好的把握项目的总体进度绩效，随时了解项目进度,为调整项目计划提供客观基础。

同时我们在项目进度计划中根据项目计划定义了相关的里程碑，在每个里程碑我们都采取小组会议形式对本阶段的工作进行确认、总结；对本阶段的进展情况做出结论，并决定是否调整一下阶段的进度计划。

经过努力，该系统一次上线运行成功，并在当月通过了验收。回顾项目的进度管理工作过程中，虽然没有严重的项目进度延迟问题，但仍然存在许多问题，主要有以下3点：

1、估算不够精确，实际工作量与估算工作量偏差比较大，主要还是缺乏经验数据或者经验数据不够精确的影响。

2、团队成员协作程度不高，未能充分调动团队成员的积极性，最大程度的发挥团队合作精神。

3、沟通不够通畅，预先建立的沟通机制未能充分的发挥作用，未能将实际情况及时的调整，从而导致有一段时间项目组沟通效率较低。

3、论项目的需求管理（3108）

一、制定需求管理计划

在本项目启动时，在制定项目计划时，我负责该项目的需求管理管理工作。需求管理计划对于需求管理工作的成功实施，起来重要作用。因此在项目启动后，我通过如下步骤，完成制定需求管理计划工作。

1.与相关人沟通，梳理并明确需求管理工作内容。包括需求的沟通并达成一致、需求变更控制方法、需求跟踪频度及触发时机等

2.明确需求管理涉及的干系人、角色及职责。因需求管理涉及到干系人较多，为避免需求缺乏一个统一的入口及出口。在本项目中，我们要求客户方安排一名的需求接口人，我方

- 7 -

也安排一名需求接口人。所有的客户需求均由客户接口人收集并整理后发给我方需求接口人。对于需求的反馈意见，也由该接口人统一对外传递。通过该约定，避免了因客户直接面对开发人员，导致需求零散且随意变化的情况发生。

3.明确需求管理采用的平台，如需求管理工具等。在本项目中，我们采用IBM Rational RequisitePro(以下简称RP)作为该项目的需求管理工具，主要实现需求双向跟踪管理等。采用IBM Rational ClearQuest(以下简称CQ)作为需求变更管理工具。这两个工具的组合，很好的帮我们团队实现了需求跟踪管理及变更管理。所有达成一致的需求我均会将其导入RP中进行管理。

4.编写需求管理计划。在本项目里，采用公司CMMI体系的需求管理计划模板，进行计划的编写。重点描述了上述内容。完成了需求管理计划编写后，由项目经理、各小组组长、QA、客户共同对该需求管理计划进行评审，并得到客户的认可。 二、需求变更管理

随着软件技术的复杂化，架构的多样化，业务的灵活化，以及随着客户对所需系统目标及需求的清晰化，变更时不可避免的。管理变更是目前项目成功的关键因素。因此，需求变更管理在整个项目的需求管理工作中显得尤其重要。 在本项目中我们采用如下需求变更管理流程。

1.首先是客户需求接口人提出需求变更清单(记录需求变更项)，我方需求接口人接收到该需求变更，并在CQ上发起需求变更流程，并分配给技术负责人。

2.项目技术负责人接收到需求变更，对该变更进行技术评估，如果技术上可行，进入下一节点;否则给出相关的技术解答，也同样进入下一节点。

3.项目经理接收到技术分析通过的需求变更，进行资源分析、进度分析等，分析通过的需求变更项，进入CCB审核环节。对于技术负责人分析不通过的需求变更，项目经理经过

- 8 -

确认后，结束来流程，处于驳回关闭状态。针对这部分需求变更，需求接口人将给客户予以答复。

4.对于项目经理审核通过的需求变更，CCB安排人员进行复核，复核通过后，该需求变更将由后续的实施人员(如开发修改代码、需求人员修改需求文档等)进行实施，并安排相关人进行验证。因实施及验证不属于需求变更管理流程，故这里不赘述。

通过上述手段，本项目保证了所有的需求变更都有据可依，同时，也通过该完整的需求管理过程，为后续的需求跟踪及相关的测试提供了信息保障。 三、需求跟踪

在实际项目开展中，经常会发生这样的情况。测试人员在进行测试时，发现某些需求未实现，或者客户UAT(用户接收测试)时，发现某些功能点未测试全。诸如此类的问题，很大一部分原因是由于需求双向跟踪未做好。

在本项目里，我们采用RP实现了上述双向跟踪。通过该工具，大大减少我们人为进行需求双向跟踪所需的工作量。而且通过RP和CQ集成，在进行需求变更时，我们可快速找到需求关联项。

在我参与的这个项目里，作为项目经理，我的工作主要目的是确保项目所有干系人对需求的一致理解，通过CQ管理和控制需求的变更，采用RP实现从需求到最终产品的双向跟踪。主要的工作流程包括制定需求管理计划，并通过评审得到客户的认可，求得项目所有干系人对需求的理解，求得对需求的确认、通过CQ管理需求变更，维护对需求的双向跟踪，并且通过RP的双向跟踪功能，协助我们识别项目工作与需求之间的不一致等。虽说该项目严格按照CMMI的需求管理过程要求实施，但是在实施过程中，也有我们自己的心得体会及教训，下面各列举一两点：

- 9 -

1.一定在项目启动时，就要和客户就需求接口人予以明确。经过该项目的实践，发现，这个角色的设置，是相当正确的，避免了客户所有业务人员直接面对开发人员的情况，保证了开发所使用的需求都是有依据和证据的。

2.有效的需求跟踪是避免需求遗漏的有效办法之一。可以避免在类似UAT时才发现需求未实现或者实现不全，减少项目上线压力，同时也减少了客户对公司项目团队的不满。正因为如此，通过该项目的实施经历，客户与我们又签订了后续的合同。通过该项目的成功实施，为我司与该客户后续的长期合作奠定了良好基础。

4、论项目的风险管理（2998）

1、风险管理计划编制

在项目初期，我组织有关人员编制了风险管理计划，确定如何为本项目处理和执行风险管理活动。我们采用会议的方法来制定风险计划的，因为该项目投资规模比较大，所有的项目干系人代表都被邀请参加了风险管理计划会议，全面地考虑了风险对项目的影响，制订充分的风险管理计划。

在计划中，我们确定了基本的风险管理活动（如每15天召开一次风险评估会议），根据项目管理理论和我公司的项目实践，定义了项目中的风险管理过程，估计了风险管理的时间表和费用，并把风险管理活动纳入了项目计划，把风险管理费用纳入了成本费用计划。 2、风险识别

根据项目的实际情况，我们把项目中的风险划分为技术风险、团队风险、外部风险三大类。在识别了上述风险后，我们还确定了这些风险的基本特性，引起这些风险的主要因素，以及可能会影响项目的方面，形成了详细的风险列表记录。

在技术风险方面有二个方面，一是对三层架构的B/S结构运用不熟，在这样大型的项

- 10 -

目中我们公司还是第一次运用；二是oracle公司数据库公司海量数据的处理能力，我公司还没有成熟的经验，需要oracle公司的技术支持与服务，虽然这方面主要是由其他公司联系处理，但oracle公司对数据库性能的优化与否将严重影响项目的进度和质量。

在团队风险方也有两方面，一是编程人员中新手较多，对软件质量及工期进度有影响，主要是因项目周期长，工作量大，需要大量的编程人员；二是核心技术人员不能长期在现场监督指导，主要是因为项目异地开发。

外部风险主要有没有正确理解业务问题，项目干系人对业务的认识不足、信息化水平低，同时我们公司缺项目的行业专家，行业专家有甲方提供，而甲方行业专业不能专注于该项目。 3。风险定性分析

我们根据风险管理计划中的定义，确定每一个风险的发生可能性，并记录下来。除了风险发生的可能性，还分析了风险对项目的影响，包括对时间、成本、质量等各方面的影响。其中不仅仅包括对项目的负面影响，还分析了风险带来的机会。

在这个过程中，我们还是采用会议的方式来进行的。不过，在风险分析的会议中，除了有关项目干系人外，我们还邀请了相关领域的专家参加，以提高分析结果的准确性。例如，对于技术类风险的分析，我们就邀请了业内著名的架构专家以及资深的Oracle数据库管理专家参与评估。在确定了风险的可能性和影响后，接下来需要进一步确定风险的优先级。 风险优先级是一个综合的指标，其高低反映了风险对项目的综合影响。我们采用了风险优先级矩阵来评定风险优先级的。最后得出的结果是架构风险排在第一位，该风险的可能性很高，影响也很大。 4。定量风险分析

对已知风险进行定性分析后，我们还进行了定量分析，定量地分析了各种风险对项目目标的影响。在这个过程中，我们采用了专家评估的方法，组织相关成员对项目进行乐观、中

- 11 -

性和悲观估计，同时，也利用了我公司历史项目的数据，用来辅助评估。进行定量分析之后，更新了风险记录列表。 5。风险应对计划编制

根据定性和定量分析的结果，我们对已识别的风险，制订了应对计划。对不同的风险，采取了不同的措施。

对B/S架构不熟悉，外聘架构专家及本公司专家一起分析，并利用已有经验加强学习。对Oracle数据库管理，由甲方数据库管理人员提前介入，不便解决开发过程中的问题，而且对后项目移交后的平稳过渡打下基础。对于核心技术人员现场指导时间少，拟组建核心团队，技术支持小组，关键人员轮岗制度。对新手要加强培训，加强制度建设，同时提高招聘门槛保证优质员工进入公司。对没有正确理解业务问题，加强对税务人员的培训，提高其信息化水平。同时，尽量培养我们自己公司的业务专家，以解决业务专家的紧缺问题。 6。风险监控

经过上述5个过程后，该项目中的风险已经比较清晰，这时就要进入风险跟踪与监控过程。在这个过程中，我们对已经识别出的风险的状态进行跟踪，监控风险发生标志，更深入地分析已经识别出的风险，继续识别项目中新出现的风险，复审风险应对策略的执行情况和效果。根据目前风险监控的结果修改风险应对策略，根据新识别出的风险进行分析并制定新的风险应对措施。在这个过程中，我们主要采用了偏差分析、项目绩效分析和监控会议的方式来进行的。

经过努力，该系统一次上线运气成功，并在当月通过了验收；回顾项目的风险管理工作过程中，虽然没有大的事故发生，但仍然存在许多问题，主要有以下2点：

1、风险识别与估计不足。实际风险与估算风险偏差比较大，主要还是缺乏经验数据或者经验数据不够精确的影响。

- 12 -

2、风险应对措施控制不够成功,且团队成员协作程度不高，未能充分调动团队成员的积极性，最大程度的发挥团队合作精神。

5、论信息系统项目的整体管理（3312）

1、关于项目计划编制：

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

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

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

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

项目计划实施是指对项目计划中所规定的工作进行管理和实施的过程。项目产品主要都在项目实施阶段生产出来，所以项目的大部分时间和预算都花在这一阶段。在该项目中，我们的软件编程、与业主方有关技术人员的具体沟通、与有关设备供应商的具体交流、阶段性

- 13 -

调试，直至全套系统软件和技术文件的完成等，都发生在这一阶段。为了能够成功地完成项目产品，项目团队进行了大量反复的具体编程、学习、沟通、修改、软硬件安装和调试工作。 如前所述，该项目涉及到的主要技术领域包括雨水情数据采集、数据分析与处理、监测预警等，我们项目团队不仅要从事熟知的信息技术工作，还要花大量时间和精力了解业主方具体的细节性需求，学习雨水情数据采集程序、数据分析与处理办法、监测预警方式等，以及反复地和业主、相关硬件设备供应商、公司上层等进行必要的交流沟通。作为项目经理，在此阶段主要的工作是要按照预先制定的项目计划，利用项目团队组织机构和工作程序，领导项目团队开展各项工作，管理和协调各利益相关者的关系，成功地将项目计划投入实施。 项目计划和项目实施是相互渗透、不可分割的活动。在该项目的实施中，我们对于项目计划编制和实施之间的协调改进工作主要采取谁实施谁计划的原则。虽然项目经理负责整体项目计划，但编制该计划的大量基础信息均来源于各技术组和技术人员。事实证明，按照这一原则，项目计划的编制更加合理、可行，实施起来更加顺利。 3、关于综合变更控制

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

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

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

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

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

6、论信息系统项目的采购管理（3082）

(一)、制定采购计划

项目采购是一项复杂的工作，在实施具体的采购行为前首先要考虑项目的采购需求。这就需要结合项目的管理计划、项目范围说明书、工作分解结构表等等，决定项目必需采购的产品或服务、采购的数量、采购设备的规格及质量要求、采购验收标准等；在采购中应及时

- 14 -

了解当前产品或服务的市场价位、市场供求情况，以便对采购成本作出一个比较准确的估算和预测，以使项目的资金使用率得到提高。在制订采购计划中还要充分考虑采购的风险，根据风险管理计划，对已识别的风险应采取有效的措施进行预防。比如供应商选择的风险、设备不能及时到货的风险、售后维修风险等。通过对以上各种因素的分析，并参照了公司采购管理制度及操作流程的规定，我编制出详细可行的项目采购计划。

在采购实施工作中，为规范项目采购管理工作，我们同客户方共同制定了“三审”制，即对采购申请、询价申报和到货验收三个关键点的审查。采购申请审批是在项目选型经过技术论证后开展；询价申报审批是在确认供应商，并通过谈判确认最终采购价格后开展，同时需提交供应商的相关证明文件、售后保证等承诺等文件；到货验收审批是依据采购合同，执行到货验收的审查工作。“三审”制对于保证采购工作合理、规范的开展，发挥了重要作用。

(二)、招标

为了保证采购计划的有效性，按时、按质的获得外部产品和服务资源，必须制订出项目的招标计划。合同编制过程包括准备招标所需要的文件和确定合同签订的评定标准的过程。招标文件编制的质量将直接关系到招标工作是否能正常进行、授标后是否能顺利履行合同。故我在编制过程中，力求做到内容完整、详尽，用词准确严谨，避免招标双方对文件的理解和解释产生歧义，增加评标工作量，影响招标工作的顺利进行。

招标文件一般包括技术文件（设备、耗材及附件的技术条件和要求）和商务文件（包括询价函、报价须知及供货一览表、合同基本条件及包装、运输等）两个方面。在拟订招标文件过程中，我组织了有关方面的专家及具备类似经验的人员，从项目的实际需求出发，经过反复讨论、审查、修改，最后形成定稿。对于关键件的选用，在广泛了解市场及使用情况的基础上，在招标文件上予以明确设备配套关键的规格型号及供货厂商。这样有利于提高各投票文件的响应性，防止投标文件内容及标价差异过大，从而减少评标的工作量。

- 15 -

(三)、供应商的选择

在收到众多供应商的报价之后，我组织相应人员对供方的供货能力、提供的价格、产品质量和服务质量等进行评估，以选择合格供方，确保采购的产品和服务符合规定要求。在开展此项工作中，我建立了一套供应商评价表， 设置了包括：需求分析、产品价格、技术实力、企业资质、经验质量、管理能力、售后服务等评价内容，并对每一评价内容按照重要程度设置了对应的权重标准。在设置权重时，我认为低价位是供应商选择的一个比较重要的指标，但不一定是主要考虑因素，交货周期及付款方式，甚至和供应商友好合作的关系等都是一些需要综合平衡考虑的因素。依据供应商评价表，我组织了包括公司产品部、营销管理部等干系人参与对供应商进行统一打分，并将分数的高低做为选择供应商的一个重要的指标。

在选定相应供应商之后，我安排公司合同管理员，参照公司的合同样本制订了采购合同。合同条款中重点明确设备规格、数据、价格、验收标准、付款方式及交货地点和交货方式等条款。为了确保合同无漏洞，又请了财务、营销管理部、公司法律顾问等相关人员共同审阅并会签。经过相关部门及供应商共同对合同条文的反复商讨及修订，最终形成合同定稿。为了控制相关变更带来的影响和风险，合同中特别明确当任一变更发生时，应及时书面通知对方，双方就变更协商一致，方能执行变更，必要时可就变更事项签订补充协议。

(四)、合同管理

合同管理过程是确保供应商执行符合合同的需求，我根据合同及采购规划设立了对供应商的检查点，要求供应商按时提交合同进展情况、工程安装调试进度等等，以便及时有效地监督合同执行情况。在执行本项目的采购合同中，我针对所采购的应用服务器到货及安装要求，设置了几个主要的检查节点，要求供应商报告设备的订货状况、货物的拟发运日期、到货日期、货物的验收报告、现场的安装调试报告等。

(五)、合同收尾

- 16 -

当全部采购的设备都按照合同条款进行验收核实后，就进入了合同收尾阶段，我同时也向财务部门提出了合同尾款的支付申请。同时对于一些过程文档（包括工作说明书合同、发货单、收货单、验收单等）进行了归档整理，对采购管理中获得的经验与教训也做了备案记录。

- 17 -