信息系统项目管理师论文Word格式文档下载.docx
《信息系统项目管理师论文Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《信息系统项目管理师论文Word格式文档下载.docx（19页珍藏版）》请在冰豆网上搜索。
此外，本文也讨论了该项目中进度管理存在的缺陷及其造成的后果，期望能给广大项目管理同行有所借鉴。
成本管理
本文结合我的实践，以综合安防管理平台项目为例，讨论了成本管理过程。
对于平台开发，我们采用类比法进行成本估算；
对于系统部署，我们采用参数法进行成本估算。
然后我们使用编制成本预算，并对成本风险进行了分析。
在项目执行中，通过工作日志系统进行成本统计与跟踪，发现偏差，及时采取纠正措施。
此外，本文也讨论了该项目中成本管理存在的缺陷及其造成的后果，期望能给广大项目管理同行有所借鉴。
沟通管理
本文结合我的实践，以综合安防管理平台项目为例，讨论了沟通管理过程。
我们首先对项目干系人进行分析，重点是将客户细分为六类，确定了关键客户。
在项目实施中，我们针对沟通对象的特点采用有针对性的沟通方式，取得了良好的效果。
此外，本文也讨论了该项目中沟通管理存在的缺陷及其造成的后果，期望能给广大项目管理同行有所借鉴。
人力资源管理
本文结合我的实践，以综合安防管理平台项目为例，讨论了人力资源管理过程。
我们首先编制了人力资源计划，确定先组成软件开发团队，在软件平台进入系统测试时，工程实施人员再进入。
在项目实施过程中，我们采用工作报告、QQ群等方式进行团队沟通，利用工作日志系统进行绩效管理，发现缺陷，及时纠正。
此外，本文也讨论了该项目中人力资源管理存在的缺陷及其造成的后果，期望能给广大项目管理同行有所借鉴。
整体管理
本文结合我的实践，以综合安防管理平台项目为例，讨论了整体管理过程。
我们首先通过公司项目管理系统的审批，正式启动项目；
然后进行项目范围说明书和项目总体计划的编制。
变更控制委员会负责对项目变更进行审批。
项目强调绩效评估的量化，取得了良好的效果。
本文也讨论了该项目中整体管理存在的缺陷及其造成的后果，期望能给广大项目管理同行有所借鉴。
项目组合、组织级项目管理、大型负责项目管理
本文结合我的实践，以综合安防管理平台项目为例，讨论了组织级项目管理和大型项目管理过程。
本文首先对公司的组织结构、公司级项目管理流程及研发中心项目管理流程进行了介绍。
然后对该项目的分解与过程剪裁进行了描述，最后重点对项目绩效管理进行了阐述。
本文也讨论了该项目中项目管理存在的缺陷及其造成的后果，期望能给广大项目管理同行有所借鉴。
一、项目概况
随着城乡社会经济的飞速发展，随着物联网与云计算的推进，电信用户对电信服务的可靠性要求越来越高，高可靠性电信设备不断推陈出新、电信自动化程度日益提高、无人值守通信机房越来越广泛，这些都对通信机房以及数据中心的安全保卫工作提出了更高的要求。
Z省通信运营商原有通信与数据机房的安防信息分散在多个系统中，如通信枢纽楼的建筑消防系统，数据中心的智能门禁系统，机要场所的视频监控系统，移动基站的动力环境集中监控系统等等。
多系统多信息来源造成了安防工作中重要安防信息响应速率低、网管、监控与安防人员之间分工不明确、安防人员工作效率低等致命的缺陷。
综合安防管理平台以“防火、防盗”为核心功能，以广泛部署的动力环境集中监控系统为基础，整合其他独立安防系统，实现通信机房安防信息的集中处理、实时报警、数据存储与统计分析，并向相关现场安防责任人派发电子工单功能，实现安防报警的闭环管理。
综合安防平台可划分为两个相对独立的层次：
A：
现场数据采集层：
负责原始报警的采集，所处理的报警类型包括消防报警、防盗报警、配线架强电入侵报警、智能门禁报警、通信电缆被盗报警、充气机报警、可燃气体报警、视频监控。
B：
中心应用层：
负责报警的发布、存储、统计、分析，并实现报警的闭环处理流程。
综合安防平台以本地网为基础，即在每个本地网设立一个安防监控中心，以管理本地网内的所有安防报警。
根据合同约定，在2009年12月底，我公司应当完成11个本地网综合安防平台的建设，并实现对全省271个通信枢纽楼与数据中心的监控。
我担任该项目的项目经理，主要负责项目管理，此外，还承担了部分需求开发与系统设计工作。
二、需求开发与范围管理
二、二需求开发与项目管理
该项目是一个信息系统集成项目，特点是涉及范围广，项目干系人众多。
项目的范围管理影响到项目的成功。
该项目存在两个互相关联的范围：
产品范围和项目范围。
产品范围定义信息系统的要求，项目范围定义项目要完成的工作。
产品范围是项目范围的基础。
因此首先必须明确定义产品范围，即进行需求开发。
针对项目的特点，我们首先对项目干系人进行了分析，将平台用户分为四类：
省公司安防管理员：
主要关心本地网安防管理的绩效。
本地网安防管理员：
主要负责本地网安防管理
C：
本地网安防中心值班人员：
实行24小时值班制，负责所有安防报警的接警与处理。
D：
现场安防责任人：
负责所辖通信机房安防报警的处理。
E：
本地网网管中心值班人员：
负责动力监控系统的管理。
平台的最终用户超过400人，对所有用户进行全面的需求调查显然不现实。
这里，我们采用的分类抽样的方法。
首先我们与客户协商，由省公司安防管理员担任甲方项目经理，负责项目的接口。
然后，我们按照项目干系人的分类，与甲方项目经理协商，确定了12名用户代表为需求调查对象。
随后，于2008年4月在省公司召开了需求调查会议。
在会议之前，我们进行了精心的准备，使用图形工具制作了一个原型演示系统，目的是为用户提供直观的感受，启发用户，以便于需求的获取。
另外，我们还使用公司提供模板编制了需求调查表，在会议之前发送给与会人员，让用户事先做好准备。
需求调查会议由甲方项目经理组织，由于事先准备充分，通过一天的会议，获取了大量的第一手的用户需求。
会后，我们和甲方项目经理一起对用户的需求进行整理与分析，编制了《用户需求说明书（征求意见稿）》，对于被拒绝的需求，也进行了记录并说明拒绝需求的原因。
然后，将会议纪要和需求说明书下发进一步征求反馈意见。
最后，在2008年5月，甲方项目经理确认了《用户需求说明书》。
根据《用户需求说明书》，我们又编制了《软件需求说明书》和《项目范围说明书》，至此需求开发完成，产品范围确定，项目范围也得到了明确。
我们使用MicrosoftProject2003，按照系统对项目范围进行进一步分解，编制了WBS和WBS字典。
《项目范围说明书》和WBS一起构成了项目的范围基线。
虽然我们定义了项目的范围，但是范围变更是不可避免的。
为了管理范围的变更，我们建立了变更控制委员会，成员包括甲方项目经理、我方项目经理（本人）、技术经理和工程经理。
所有的范围变更请求（包括用户提出的变更和我公司在项目实施过程中提出的变更）都要由变更控制委员会进行审批。
在项目进行过程中，各地方的用户又陆续提出很多变更。
现场项目人员按照管理规程对变更请求进行了记录，由设计人员对变更的影响进行评估，最后由变更控制委员会进行审批。
在进行审核时，我们主要从变更的必要性和对项目的质量与进度的影响等方面进行讨论，在与甲方项目经理达成一致后，做出批准或者拒绝的决定。
其中，某用户提出在报警电子处理流程中使用ECP网络电话代替电话语音卡，通过评估，我们发现，使用ECP网络电话可以有效降低业务台的硬件配置要求，节省投资，但是使用ECP涉及内外网的互联，并且需要使用ECPSDK进行开发，会对项目进度造成较大影响，因此建议在下期工程中实现该功能。
二、三总结
通过范围管理，我们有效的避免了范围的蔓延，使项目可以按期、高质量的交付，同时也提高了用户满意度。
当然，我们的范围管理工作也有不足之处。
例如，项目范围中包括数字化消防图纸录入，但是在系统部署时才发现，大量的建筑消防设备只能提供纸质消防图纸，对于纸质消防图纸的数字化是否包括在项目范围之中我们和甲方有不同的理解。
最后，为了不影响进度，我们将纸质消防图纸的电子化工作进行了外包。
究其原因，是由于我们在开始时对项目范围定义不严格。
在进行项目总结时，这些问题都作为经验教训写入项目总结报告，纳入公司的项目管理知识库。
我们真诚希望，在公司未来的项目实施中，不会出现类似的失误，从而实现项目管理过程的持续改进。
三、风险管理
三、一风险策划与识别
风险是一种不确定的事件或条件，一旦发生，会对项目目标产生某种正面或负面的影响。
风险是客观存在，是不可避免的。
风险管理就是要对项目风险进行认真的分析和科学的管理，避开不利条件，少受损失，取得预期的结果并实现项目的目标。
我们首先成立了风险管理小组，由我任组长，成员包括技术经理和质量保证人员。
然后，对项目的风险进行了识别。
通过对项目的分析，采用头脑风暴法和公司提供的风险清单，我们识别出了十一个风险。
随后，通过的风险可能性和影响的分析，利用风险优先矩阵，我们识别出了四个高优先级的风险：
需求不明确的风险：
由于项目干系人众多，如果需求开发不全面，很有可能遗漏重要需求。
客户不配合的风险：
由于项目要在11个本地网部署平台，并且需要接入271个通信枢纽楼的安防系统，因此当地客户的配合至关重要，否则极有可能无法按期交付。
用户可能不恰当使用系统的风险：
系统的最终用户很多，知识水平参差不齐，部分用户可能不会正确的使用系统，从而导致系统不能发挥应有的作用。
报警漏报的风险：
由于是安防系统，要求报警准确率是100%，如果漏报，后果非常严重。
针对这些风险，我们制定了相应的应对措施。
例如，对于需求不明确的风险，我们执行了严格的需求开发过程。
然后，我们按照项目干系人的分类，与甲方项目经理协商，确定了12名代表为需求调查对象。
需求调查会议由甲方项目经理组织，由于事先准备充分，通过一天的会议，获取了大量的第一手的用户需求。
会后，我们和甲方项目经理一起对用户的需求进行整理与分析，编制了《用户需求说明书（征求意见稿））》，对于被拒绝的需求，也进行了记录并说明拒绝需求的原因。
根据《用户需求说明书》，我们又编制了《软件需求说明书》和《项目范围说明书》，至此需求开发完成，产品范围确定，项目范围也得到了明确。
三、二风险跟踪与监控
风险分析与应对计划完成后，在项目的进行过程中，我们还持续的对风险进行跟踪与监控。
根据项目管理计划，我们在每周一的项目例会中，都要对风险进行评估，确认已识别风险的状态，并检查是否有新出现的风险。
在每个阶段的管理评审中，还要对本阶段的风险管理作出评价。
例如，在平台试运行的过程中，某本地网的安防中心值班人员没有严格按照规程操作，在对建筑消防设施进行例行测试时。
没有按照规程在系统中将设备设置为“测试状态”，测试过程中系统里产生了大量火警（按照设计这些测试状态的火警应当被屏蔽），错误的火灾报警被发送到现场责任人处，引起了不必要的恐慌。
通过对这一事件的分析，我们认为“用户可能不恰当使用系统的风险”已经发生，原因是用户不理解“测试状态”的意义。
这次是误报，如果用户在正常状态下将设备设置为“测试状态”，下次就可能是漏报，后果更为严重。
对此风险，我们最初制定的应对措施是编制完善的用户手册和对用户进行培训。
用户培训已经完成，但是由于用户较多，接受集中培训的只是部分用户代表，理想的情况是经过培训的用户对其他的用户进行二次培训，但是显然大多数用户并没有得到系统的培训。
针对这种情况，我们修改了培训方式，首先对我公司的项目实施人员进行培训，使他们具备相应的培训技能。
然后，他们在本地网实施项目的过程中，按照培训规程对当地的用户进行现场培训；
此外，每个本地网的实施人员和当地的安防人员组成虚拟团队。
共同推进系统的应用。
通过以上措施，用户的误操作率大为减少，项目的推进速度得到了保证。
三、三风险管理
通过风险管理，我们有效地减少的风险的影响，使项目可以按期、高质量的交付，同时也提高了用户满意度。
当然，我们的风险管理工作也有不足之处。
例如，在现场建筑消防设备的接入过程中，我们才发现部分建筑消防设备不具备智能接口，或者智能接口已经损坏，无法接入。
这些消防设备都是列入合同范围，必须要完成智能接入的。
由于已经是项目后期，设计已经无法更改了。
最后，为了不影响进度，我们将消防设备智能接口开发的工作进行了外包，由于时间要求较紧，因此开发费用相对较高，增加了项目成本。
究其原因，是由于我们在开始时对风险识别不全面，没有及早识别出该风险。
四、质量管理
四、二质量策划
质量是过程、产品或服务满足明确或隐含需求的能力。
项目质量包括产品质量与过程质量。
项目的实施过程，也是质量的形成过程。
质量管理是项目管理的重要方面之一，包括质量管理职能的所有活动。
我公司的质量方针：
“强化管理、优质服务、科技创新、质量第一、满足顾客的要求和期望是我们永恒的主题”。
按照这个方针，我们对项目的质量管理进行了策划。
通过对公司的质量管理过程进行剪裁，我们编制了项目的质量管理计划。
质量管理计划首先对质量管理的组织和职责进行了明确。
项目配置了一名兼职QA，负责项目的质量保证工作。
另外，在配置了两名专职的QC，负责平台的测试工作。
项目分为平台开发与系统部署两个阶段，两个阶段质量要求有较大的区别。
在质量管理计划中，针对各个阶段制定了有针对性的质量标准与测试方法。
例如，在系统部署阶段，一个重要的质量标准就是安防报警的准确性、实时性，针对报警的测试，我们规定各种类型报警的抽样率，要求准确率为100%。
四、三实施过程中的质量管理
项目组共有成员二十多人，其中，软件开发人员已经基本具备质量意识与质量控制技能。
而部分实施人员则有所欠缺。
QA根据质量管理计划对项目组成员进行了质量管理培训，帮助项目组成员理解项目的质量目标与质量要求。
在该项目实施之前，我们已经和用户一起在某个本地网部署了实验系统，对项目的可行性进行了验证。
需求开发比较成分。
因此，我们决定采用V型模型进行系统的开发V型模型强调阶段评审与测试，有助于软件质量控制。
QA则负责检查工作是否符合已定义的过程。
我项目组的QA参加过多个项目，经验非常丰富。
例如：
在对代码的走查中，QA发现一名开发人员没有编码规范进行编写，在对数组访问时没有检查数组上下限，QA在记录不合格项的同时，还对该名开发人员进行了编码规范培训。
在随后的测试中，内存地址冲突错误只出现过一次，这和QA的认真审查是分不开的。
在现场部署阶段，由于接入的安防报警很多（例如，一个建筑消防设备就有上百个报警点），全面测试显然成本过高。
我们采用统计抽样的方法，规定建筑消防设备抽样率为10%。
我们还对接入设备未通过测试的原因进行了分析，主要有两个原因：
一：
设备本身故障
二：
设备的配置发生了变更与设计图纸不一致
针对这两个原因，我们都制订了相应的措施。
对于设备本身故障要求维保单位进行维护；
对于设备配置的变更，我们则要求维保单位首先对设计图纸进行更新；
然后再进行测试。
由于我们对质量进行了严格的管理，在甲方进行系统验收时一次性通过。
此外，由于还协助甲方消除了不少安全隐患，甲方向我公司表示了感谢。
四、三总结
通过质量管理，我们有效地减少项目的风险，使项目可以按期、高质量的交付，同时也提高了用户满意度。
当然，我们的质量管理工作也有不足之处。
例如，我们对质量的管理不够全面，只注意了正确性、健壮性和可靠性，对性能和安全性则很少重视。
由于缺少压力试验，在系统试运行后，出现并发用户多时系统性能下降，反应变慢的情况，后来通过优化数据库解决了问题。
另外，对于系统的安全性也缺乏重视，部分用户采用弱密码很容易被攻破，该问题在验收会议上提出并作为遗留问题写入验收纪要在进行项目总结时，这些问题都作为经验教训写入项目总结报告，纳入公司的项目管理知识库。
五、进度管理
五、一项目进度策划
在合同中已经约定项目要在2009年10月底之前完成。
并且用户也将年底前完成全省安防平台的建设列入2009年的工作计划，因此按时交付是本项目是否成功的重要标志。
项目分为平台开发与系统部署两个阶段，两个阶段进度管理有较大的区别。
我们首先对项目的进度进行了策划。
我们使用MicrosoftProject2003作为工具编制了项 WBS，确定“提交通过评审《用户需求说明书》”、“提交通过评审的《系统设计方案》”、“提交通过系统测试的平台软件”以及“提交通过评审的本地网安防平台现场测试报告”等重要的里程碑。
在编制进度计划时，我们采用了滚动式规范的方法。
滚动式规划是一种渐进明细的规划方式，即对近期要完成的工作进行详细规划，而对远期工作则暂时只在WBS的较高层次上进行粗略规划。
在最初的项目进度计划中，需求开发阶段进行了详细计划，其他阶段只对里程碑进行了计划。
随着对项目认识的逐级深化，项目进度计划也逐渐细致。
为了加快开发，保证项目的进度，我们决定综合安防平台的数据采集层直接使用我公司现有动力环境集中监控系统的数据采集层。
动力环境集中监控系统已经应用超过十年，期间经过多次升级，软件稳定可靠。
特别是数据采集层，采用软总线结构，通过挂接不同的设备驱动就可以实现各种设备的采集。
目前动力环境集中监控系统数据采集层的设备驱动主要是UPS、开关电源、智能空调等。
如果将安防设备（建筑消防设备、防盗主机等）视为通用智能设备，开发专用驱动，则可直接接入数据采集层的软总线。
这样新平台的软件开发量就减少将近一半。
综合安防平台的中心应用层则以现有动力环境集中监控系统的中心应用层为基础，按照安防平台的特殊需求，进行二次开发而成。
在对WBS中的软件开发活动进行细致分解后，我们对每个活动所需的时间进行了估算。
估算的主要方法是类比估算法。
我们首先列出每个活动需要实现功能点，然后将功能点与已有系统中类似功能点模块进行比较，估算出代码行。
然后通过计划评审技术估算出该活动的历时，计划评审技术的基本公式是t=（a+4m+b）/6，其中，a代表乐观时间，b代表悲观时间，m代表最可能时间。
通过估算，我们发现，平台开发阶段的历时比最初的计划可以提前一个月，项目按期完成的概率很大。
据此，我们对项目进度计划进行了调整，计划提前一个月完成项目。
五、二项目进度管理
虽然项目计划提前一个月完成，但是在项目的实施过程中，由于主客观条件不断变化，凭借一个最优计划而一劳永逸显然是不可能的。
如果不对项目进度进行控制，不仅无法提前，项目还有可能延期。
进行项目管理，我们首先强调人的作用。
在WBS中，我们为每个活动指定了责任人，确保每个责任人明确他的职责和时间期限。
同时，我们还利用工作日志系统，实时收集项目的进度。
对于软件开发人员，我们要求他每天在工作日志中报告执行任务的进度，并且进度要量化，要以完成百分比表达。
对于现场部署人员，则要求每周在工作日志中报告任务进度，量化的指标是接入安防设备的数量。
根据甲方的要求，我们每月要向甲方项目经理提交一份项目进展报告，报告项目的进度，对发展趋势进行预测。
在软件开发阶段，项目基本上按照进度执行。
但是到了系统部署阶段，项目的进度开始出现偏差。
按照合同约定，我们要在每个本地网都部署一个中心平台，处于节省资源的考虑，我们设立了三个部署小组，分区域进行部署。
在进入系统部署的第二周，我们进行进度检查时，发现部署进度出现了偏差。
按照计划，每个部署小组每天应完成三台安防设备的接入，但是实际上平均每天只完成了一台安防设备的接入。
我们迅速对偏差进行了分析，发现主要有两个原因：
安防设备本身故障，无法接入
安防设备的配置发生了变更，与设计图纸不一致，导致测试时达不到合格标准。
对于设备本身故障，我们通知甲方，要求维保单位进行维护，然后再进行测试；
对于设备配置的变更，我们则要求维保单位首先对设计图纸进行更新，然后再进行测试。
但是，我们也意识到，系统部署已经无法按照原进度计划执行。
根据估算，如果仍然是三组并行工作，不仅无法提前完成，还有可能延期。
因此，我们重新对进度计划进行了修订，向公司申请资
升级会员 