信息系统项目管理论文六篇.docx
- 文档编号:29961672
- 上传时间:2023-08-03
- 格式:DOCX
- 页数:22
- 大小:35.73KB
信息系统项目管理论文六篇.docx
《信息系统项目管理论文六篇.docx》由会员分享,可在线阅读,更多相关《信息系统项目管理论文六篇.docx(22页珍藏版)》请在冰豆网上搜索。
信息系统项目管理论文六篇
论信息系统项目的收尾工作
摘要
我在一个软件公司工作,2004年3月,公司主持了某市政府公文流转系统项目的研发工作,我担任该项目的经理。
该项目主要完成某市政府(地级市)的市领导、政府办公厅、下属40多个部办委局的工作机构之间的电子公文流转和电子签名工作,项目从启动到成功收尾历时10个月,顺利地达成了项目的标。
本文以该项目为实例,探讨了信息系统项目收尾工作的主要内容,包括合同收尾和管理收尾,给出了该项目的实施收尾的工作流程,该项目在收尾过程中也出现了一些问题。
对于需求变更的问题,采取了版本控制、与用户沟通及争取用户方领导协商的办法;对于用户不愿意签字的问题,在了解真实原因的基础上,对症下药;项目资金不能到位的问题主要是争取了公司领导和市场营销部的支持,共同攻关;并在验收后在项目组内部进行了认真的总结。
正文
2004年3月,我作为公司方的项目经理主持了某市政府公文流转系统项目的研发工作,该项目主要完成某市政府(地级市)的市领导、政府办公厅、下属40多个部办委局的工作机构之间的电子公文流转和电子签名工作,项目从启动到成功收尾历时10个月,顺利地达成了项目的标。
这个项目由于是客户方是政府机关,涉及的方方面面较广,收尾比较困难,但我们采取了相应的措施,在项目组内部和外部收尾工作都进行得有条不紊。
信息系统项目的收尾是项目生命周期的最后阶段,是软件产品准备提交时,项目班子所做的收尾工作。
收尾工作常常是零碎、繁琐、费时、费力的。
收尾过程是项目干系人和客户对最终产品进行验收,使项目或项目阶段有序地结束的过程。
许多软件项目在尚未完成之前就被取消了,但项目收尾仍然是重要的,因为通过项目收尾可以总结出经验教训,能够改进未来的项目。
项目收尾包括合同收尾和管理收尾两部分。
管理收尾涉及为了使项目干系人对项目产品的验收正式化而进行的项目成果验证和归档,具体包括收集项目记录、确保产品满足商业需求、并将项目信息归档,还包括项目审计。
管理收尾对降低信息系统项目失败率有重大的意义。
为什么会失败?
有什么地方可以改进?
获得了什么经验?
对一系列的问题应进行分析,总结得越多,资源就越丰富,能形成适合企业自身的成熟的管理模式,以降低信息系统项目管理风险和管理成本。
合同收尾就是了结合同并结清帐目,包括解决所有尚未了结的事项。
合同收尾需要对整个采购过程进行系统地审查,找出进行本项目其它产品或本组织内其他项目采购时值得借鉴的成功和失败之处。
在某市政府公文流转系统当系统开发完成并经过一个月的上线测试后,系统已基本稳定地运行了,我觉得已经进入可以开始收尾的时机了。
于是我先是用《验收报告》(是我公司写文档模板)给客户观看,做到双方心中有数,然后开始细致地梳理相关的问题,准备移交的文档资料、软件程序清单等资料;在收尾过程中与客户方保持了持续的多次沟通;最后举行了一场正式的验收会议,邀请双方的领导及项目组成员、相关单位的领导参加,完成了验收工作;在项目组内部也组织了一些正式的会议和非正式的谈话,编写的项目总结报告。
当然,在项目验收的过程中也碰到了不少的问题。
“用户需求的变更是不会变的”,项目要收尾了,需求还在变。
主要是因为使用了开发的系统后,用户由于对公文流转系统认识有了提高又有了新的需求。
系统使用的单位本就比较多,每个单位提一点就相当多了,而且有的还提出了与公文流转无关的业务需求。
对于需求在收尾时还在变更的问题,并不能不允许变更,而应是把变更控制在可接受的范围内。
在本项目中,我从以也几个方面入手解决:
一是运用版本控制的方法,向用户声明,当前的软件是Version1.0的(或者是某一版本的),不可能包罗万象,哪些功能我们将放在下一个版本中去实现,作为开发方,不能一味的答应下来,否则很有可能会限入变更的的反复,被其束缚;二是取得用户的理解,对不甚合理的地方作出解释,让其知道我们做出了多大的牺牲去帮助他们实现愿望,争取谈判和开发上的主动性;三是和用户方的领导小组进行了协商,统一定了提出需求的最后期限,大大减少了变更的数量。
在项目进行验收的过程中,我发现用户并不喜欢在正式的文档上签字。
经过仔细的调查,找出了原因,原来用户希望能让开发方多呆些时日,以让公司方多做一些功能,自己多发现一些问题,用户方普遍不愿意承担正式签字后的后果。
对此,为了消除用户心中的顾虑,我让项目组花些时间细心地给用户准备了详细的维护方案和手册;特别留意在每个单位培养了至少一名用户方技术人员达到可维护系统的水平;为了保证签字的有效性,经与用户方领导小组协商确定了签字责任人,有的在领导小组就可以解决签字的问题;同时我也向公司的领导做了汇报,让公司领导与用户方领导小组有横向的接触;最后组织召开了一次成功的验收会议,双方的领导、项目组成员及用户单位的领导都参加了会议,最终获得了用户的一致肯定和高度评价。
项目在验收会议表示验收通过后,项目的资金却迟迟不能到位。
资金没有到位,说明收尾还没有完成。
我马上向公司领导进行请示,请求支持,并向公司市场营销部门要求协助,共同重点攻关。
本项目标的并不高,只有100万,但用户方财务手续审批繁琐,造成了时间上的延时,经用户方领导小组组长的拍板,最后在验收通过的第20拿到了合同规定的款项,并保持了和用户的良好合作关系。
项目只是更大范围的组织环境中的一部分,许多对项目的影响因素不是为项目经理所控制的。
项目经理对管理事务常不熟悉,因为在国内项目经理大都是由程序员成长进来的,需要公司领导的培养和指导。
在收尾工作,象客户款项的收缴、项目结束时的会谈、客户关系出现危机等许多场合下是需要公司领导的支持和参与的。
在一个公司领导很重视的环境下,收尾工作会是更为出色的。
通过验收了,拿到资金还不能说项目收尾成功了。
在项目组内部还要进行认真的总结。
文档整理和项目经验的总结都是十分细致的工作,需要项目经理组织人员细心耐致地去做。
可组织一次项目组的正式或非正式会议,畅谈项目研发过程中的经验,会中做记录,会后做整理;将所有项目的文档和源程序归档。
项目总结是项目可持续发展的必要,也是对项目和项目组成员的尊重。
当前项目的经验对其它项目是有很好的借鉴意义的,特别是对类似的软件项目,在管理上、技术上、开发过程上都是一笔财富。
不仅要对项目的程序代码存储,所有相关文档资料(包括合同、开发文档、总结文档等)也要归档。
我比较倾向于在饭桌上和同事们谈经验来总结,一是大家完成项目了,代表公司表示慰问,另一方面在这个时候谈感想谈经验是最好的时机,大家话也比较多;在谈话后我编写了项目总结报告,总结了同事们的各种观点,为今后其它项目的开展提供了知识积累。
“不断地学习改进”,我把它作为自项目团队的工作信条。
总之,信息系统项目的收尾是一项需要细致、耐心而微妙的工作。
项目的收尾包括合同收尾和管理收尾,在本项目中,出现了用户需求仍在变更、用户不愿意在正式的文档上签字、验收后资金不能及时到位、内部项目总结如何开展的问题,都较好地得到解决了解决,成功地收尾。
论信息系统项目的整体管理
摘要
2005年3月,某市为实施城镇职工基本医疗保险,开发了一套医保管理信息系统,我作为用户方项目负责人,参与了项目管理、系统分析和编程的部分工作。
医疗保险管理信息系统涉及到医保管理部门、各定点结算点(医院、药店)、开发商,加之政策多变、业务不成熟,需求变化频繁,开发的难度的风险较大。
在某市医保管理信息系统开发过程中,我作为用户方的项目负责人参与了项目的整体管理工作,我在项目整体管理中采取了针对性的措施,加强了参与各方的沟通,注重用户需求和需求的变化,合理配置项目组成员,对风险进行了及时的评估并顺利地控制了风险。
通过这些办法,平衡了各方的利益,控制了项目的范围和进度,保证了项目的质量,顺利完成了这个项目。
该系统在2006年6月一次上线运行成功,目前运行情况良好。
正文
2005年3月,某市为实施城镇职工基本医疗保险,开发了一套医保管理信息系统,我作为用户方项目负责人,参与了项目管理、系统分析和编程的部分工作。
该系统的功能包含了基金征集和支付管理、参保单位(职工)管理、定点结算点管理、参保职工就诊结算管理、IC卡管理等,目标管理人数为30万、定点结算点200个,计划投资400万元;采用C/S结构,数据集中保存在市医保中心,定点结算点与医保中心之间数据实时交换。
通过分开招标,明确了项目的范围、时间、成本和采购,因此,我把整体管理工作的重点放在了项目的质量、人力资源、沟通和风险管理,目的是保证实现计划的功能并按时投入运行。
在工作中,我根据实际情况,采用了灵活的工作方法,取得了较好的效果。
该系统在2006年6月一次上线运行成功,目前运行情况良好。
一、加强了沟通管理
该项目涉及到医保中心、参保单位、定点结算点、系统开发(集成)商等多个单位,从需求分析到系统设计、测试都要各方参与、协调配合。
由于各方的地理位置十分分散,难以经常或长期集中,因此,各方及时有效的沟通是项目成功的必要条件。
为解决好这个问题,我采取了三个办法:
1、提高大家对沟通作用的认识,特别是各方主要领导人对沟通的必要性和重要性的认识,从而对沟通工作给予必需的人员、经费和时间支持,保证了沟通工作得以按计划进行。
2、对项目组外部的沟通,坚持从实际出发,采用多种沟通的方式。
一方面,把必要的、重要的沟通需要以联席会议、工作计划、总结报告的形式制度化。
另一方面,在适用的前提下,采用灵活、经济的沟通方式,比如:
对一般的小问题或者是简单问题进行电话交流,复杂一点的问题开碰头会,需要后续解决的、比较重要的及涉及面较大的问题要形成书面的会议记要,有必要的情况下要由相关单位加盖公章确认。
3、对项目组内部沟通,进行适当的控制,避免形式主义,在保证效果的前提下节省时间,提高工作效率。
规定项目组成员在每天工作过程遇到问题,将其记录下来,然后在以邮件方式发送给需要沟通或者询问者。
大家每天下班之前收取邮件,对于可以直接回答的问题则直接以邮件方式回复,对于无法直接答复而只需与提出问题者讨论的问题,在第二天上班前进行商议确定。
而需要众人一起讨论的问题,则放到每周会议上讨论,较紧急的问题召开临时性会议。
通过以上方法,基本上实现了有关各方及项目组内部的有效沟通,及时发现问题、解决问题,避免了因各方立场不一致造成严重对立而影响项目进度,避免了因交流不畅形成重大质量问题。
二、进行风险评估,在进度和质量之间进行权衡,争取最佳平衡点
由于项目资金已经确定,我就在进度和质量之间找平衡点,力争把风险降到最低。
由于医疗保险业务本身比较复杂,加之当时国家政策不稳定,业务流程不是很规范,系统需求也在不断调整、完善,给项目的进度带来一定影响。
由于这个项目涉及到十余万参保职工的医疗待遇,影响很大,通过与用户方领导沟通,决定不搞“形象工程”,在质量和进度之间优先考虑质量。
同时,考虑到这个项目的采用了增量开发模型和模块化的设计方法,我把项目目标进行了分解,涉及到业务经办的部分优先完成,保证系统在规定的时间上线运行,其它不影响业务经办的、辅助性的功能适当延期,包括医疗监督、统计分析和部分报表。
这样虽然整体工期有所延长,但没有影响系统及时上线。
这种做法同时照顾到各方的利益,把整体风险降到了最低。
三、重视需求变化的客观性,强化测试,保证软件功能完整、正确、高效
我们采用了软件工程方法,使用渐增式的增量模型,注重满足用户需求和需求的变化。
由于国家没有统一的医疗保险业务经办规范流程,另外,为保证医保基金的收支平衡,各地都在根据医保基金的运行情况进行不断的政策调整,造成医保系统的需求变化频繁。
根据这个情况,为保证软件满足应用需要,我们规定:
在整个项目的开发过程中,凡是用户提出的、经调查情况属实、经技术可行性论证可行的,全部予以响应。
同时,采取措施避免需求的反复和无意义、不合理的变更。
对较大的变更和比较关键的变更,要经各方联席会议论证通过,参与人员签字负责,并由提出变更的单位加盖公章确认。
由于不合理或技术上不可行而没有通过的需求变更,要提出替代的解决办法,并与用户单位协商,达成一致意见后予以解决。
测试是保证软件质量的重要手段,也是让用户直观地了解软件质量和熟悉软件操作的有效途径。
我有计划地强化测试环节,让用户由始至终地参与测试工作。
我们主要采取黑盒法进行测试,把工作重点放在测试用例的准备上,严格定义测试索引、测试环境、测试输入、预期结果、评价标准,尽可能的把各种业务的不同情况都表现出来。
同时,我们准备了一家定点结算点进行实际运行测试,在该结算点手工记账和计算机联网记账同时进行,并有计划地穿插一些测试用例。
通过这些办法,及时发现了和解决了许多问题。
经过努力,该系统一次上线运行成功,并在6个月后通过了验收。
回顾项目的整体管理工作过程中,虽然没有大的事故发生,但仍然存在许多问题,主要有以下3点:
1、软件测试不系统,用例准备仍不够充分,忽视了压力测试。
系统实际运行后随着参保职工和定点结算的增加,运行速度下降很快,达不到设计要求。
虽然通过升级硬件缓解了这个问题,但造成了资金的额外投入。
2、在需求分析过程中对各方目标的权衡不够充分,导致定点结算点使用的结算子系统功能较弱,提供的系统接口又不够强大,给定点结算点内部管理带来不便,一些必要的统计和查询功能难以实现。
3、对开发人员与操作人员对系统的要求差异认识不足,两者的直接沟通不够,造成一些对操作员而言很重要的问题在开发人员那里得不到重视,产生了一些矛盾,给项目带来不利影响,特别是影响到用户方领导部门对项目的整体印象。
综是所述,良好的项目沟通管理;合理的人力资源配置;用风险评估在进度和质量之间进行权衡;重视需求变化的客观性,强化测试,保证软件功能完整、正确、高效是我在某市医疗保险管理信息系统项目中的整体管理中的四个主要实践,为项目的成功奠定了坚实的基础。
在以后的项目整体管理工作中,我要加强测试的系统性和科学性。
注重各方利益的权衡,继续深化各方的沟通,协调好开发工作各个部分及各个方面的关系,更好地完成项目。
论信息系统项目成本管理
摘要
成功的成本管理就意味着项目成功了一半。
本文先总结笔者参与主持过的许多失败案例的成本管理过程中存在的问题。
再以一个成功的成本管理案例《承压设备和特种设备案例管理系统》为例,首先概要介绍该项目的简介,接着介绍成本管理的主要内容,再结合本案例说明范围管理对成本估算的影响,详细介绍资源估算计划过程及本项目采取成本估算的方法以及以前失败案例的成本估算方法,然后介绍了项目预算的过程,最后介绍了有效的项目控制方法和如何利用挣值分析方法对项目进行绩评估。
笔者在该项目中担任了开发方的项目经理,参与了整个项目的设计开发管理过程,项目估算为320万元,为期半年,开发过程中运用了本文所介绍的成本管理过程,不仅按时完成项目,同时在成本管理方面取得可喜成绩,项目实际支出为270多万,为公司节约了近50万的预算成本。
正文
笔者参与管理过的众多项目中,在成本管理上曾经有许多失败的案例,这些项目完成后,实际使用成本都大大超出预算值,究其原因,大致有以下几种:
(1)对项目范围管理不够重视,忽略范围确认过程,导致项目后期变更频繁,直接影响项目成本上升。
(2)对项目风险估计不足,比如项目组成员流动太大的风险、项目组成员水平太低造成的风险等等。
由于这些问题导致的项目进度、项目质量等原因产生的成本超支。
(3)亏本估算不够精确。
比如采用经验估算和专家头脑风暴估算的成本估算结果准确程度较低。
或者成本估算时太乐观或忽略了一些细节问题,比如项目组成员培训费用等。
(4)在进度和质量控制上力度不够,导致项目延期、返工率增加。
(5)在成本控制的关键环节缺乏行之有效的管理方法和流程。
笔者于2005年10月开始主持《承压设备和特种设备案例管理系统》项目开发任务,该系统包括《压力管道安全管理及图文分析子系统》、《压力管道定期检验管理子系统》、《压力容器安全管理子系统》、《压力容器定期检验管理子系统》、《特种设备(起重机、电梯、厂内车辆)安全管理子系统》、《特种设备定期检验管理子系统》、《锅炉安全管理子系统》、《锅炉定期检验管理子系统》、《承压设备和特种设备使用注册登记管理子系统》等。
该系统在总结了过去众多项目的经验教训的基础上,经过周密的成本估算,合理的预算及严格的成本控制,配合专家化的范围管理和严格的进度和质量控制,在成本管理方面取得了可喜的成绩。
项目预算投入320万元,实际投入开以成本只有270多万,为公司节省了成本支出并按期完成了项目,获得客户的好评。
成功的成本管理对控制项目成本超支现象起决定性作用。
美国斯坦迪什咨询公司的研究结果说明信息系统项目完成时成本超出预算已经成为一种普遍现象,但是如果对项目成本进行详细的估算和切合实际的预算,并加以有效的成本控制手段,将项目成本控制在预算成本以内是完全的可能的。
《承压设备和特种设备安全管理系统》是根据《特种设备安全监察条例》、《压力管道安全管理与监察规定》、《在用工业管道定期检验规程》、《压力管道使用登记管理规则》、《压力容器安全监察规程》、《在用压力容器定期检验规程》、《锅炉使用注册登记规则》、《锅炉定期检验规程》等有关国家法规要求的基础上开发的。
系统内大部分管理内容都是国家强制性执行的,因此系统需求必须符合这些法规的规定。
在需求确认阶段,我公司特地聘请中国机械工程学会压力容器和压力管道分会的高级专家对项目需求分析结果WBS工作分解结构作了一个详细的会审,会审的结果使项目的范围变更大大减少,为进行准确的成本估算打好坚实的基础。
首先进行的是资源计划估计。
利用专家会审过的WBS工作分解结构,对每项完成该交付物所需的资源和数量做出估计。
这个过程中我们借鉴了以前公司开发过的一个类似项目《设备及计量器具管理系统》开发过程国的实际资源和数量的使用情况记录。
这一过程的结果应该产生一份详细的资源需求清单,其中包括人员、材料、设备等关键信息。
如果项目经理想在预算限制内完成项目,他们必须进行严格的成本估算。
以往几个成本管理失败的案例的成本估算大部分采用的是类比估算法,这是由有关专家根据以往类似项目召开头脑风暴会议确定项目总成本,再将总成本按照WBS结构依次下传到最底层的活动。
这种成本估算方法虽然简单易行,而且投入的成本费用也比较少,但是结果往往比较粗糙。
为后续成本管理工作带来困难。
考虑到本项目的需求范围法规约束性很强,经过专家会审的WBS工作分解结构在范围管理方面的误差已经很小,我们决定采取基于WBS工作分解结构的详细估算方法。
根据完成的WBS工作分解结构和进度计划表就可以进行成本估算了。
先对WBS最底层的要素进行详细的费用估算,再向上汇总至各项分工作、分任务的费用,最终得到项目和整个计划的累积统计。
这个过程我们必须交付下列报告:
(1)WBS结构各项要素的费用,各项分工作、分任务的费用;项目和整个计划的费用报表。
(2)每个部门的计划工时费用曲线。
如果部门工时曲线含有峰谷,应考虑对进度表作出改变,以得到工时的均衡。
(3)逐月的工时费用总结。
以便项目费用必须削减时项目负责人能够利用此表和工时曲线作出权衡性研究。
(4)季度和年度费用分配表,此表以WBS要素来划分,表明每季度的所需费用,此表实际上是每项活动的先进流量的总结。
(5)原料及支出预测表。
它表明供货商的供货时间、支付方式以及支付原料的先进流量等。
基于WBS工作分解结构的详细估算方法本身需要大量的计算工作,工作量较大,估算过程需要一定的时间和费用。
但是这种方法估算结果准确度较高,在估算的过程中可以采取一些现代计算机软件辅助计算。
比如MicrosoftProject2003、P3项目管理软件甚至是MicrosoftExcel2000等。
成本估算过程中还必须考虑一些容易忽略的费用。
比如需要考虑一部分风险应急金和质量预防成本;必须对意外事件(通货膨胀、意外事故、项目延期处罚等)进行估计成本,列入成本估算时的考虑支出;另外可以提前考虑项目管理上产生的费用,估算项目管理储备金。
最后,给项目估算总成本一个误差,例如本项目表示为320±30万(为什么是±30万,一般是20%偏差)。
成本预算是将项目的成本估算分配到项目的各项具体WBS要素,确定各项工作和活动的成本定额,制订项目成本控制的基准。
可见在基于WBS分解结构基础上的成本估算工作完成后,成本预算工作就很简单了。
根据系统成本估算结果很容易得出成本总计和制订成本基准计划。
用S曲线表示出各个时段(如各月、各季度、年度)的成本基准。
它表明了项目的预期资金,便于项目经理在开销之前能提供必要的信息去支持资金要求,所以意义非常重大。
另外,请注意项目预算的项目资金需求是成本基线与项目管理储备之和,项目管理储备不包括在项目成本基线之中。
成本预算时也可以使用成本估算所用的计算机辅助工具。
成本预算完毕后,在项目实施过程中,一定要对成本费用用实时记录,以便追踪实际花销是否按照项目预算进度来支出。
在《承压设备和特种设备安全管理系统》的成本控制过程中,我们根据员工周报对已完成的项目交付物进行严格的质量控制和验证,实时更新项目绩效报告。
根据阶段绩效报告利用挣值管理进行绩效测量。
根据阶段绩效报告计算实际成本(AC)支出,再根据成本估算结果获取在该阶段投入的计划成本支出(PV),利用绩效报告在成本基准计划中汇总已完成工作的总预算价值即该阶段的挣值(EV)。
在获得、PV、EV之后就可以利用偏差分析和挣值分析技术进行项目绩效评估了。
经过上述行之有效的项目成本管理流程,《承压设备和特种设备安全管理系统》项目传问完成后不仅为公司节省了近50万元的预算支出,而且在进度和项目质量控制上也取得了不错的结果,获得了用户的好评。
当然,这次成功的项目成本管理是一个难得的经验,是一项积极的组织过程资产。
综上所述,我们看到信息系统项目的成本管理绝对不仅仅是处理一堆数据,它贯串于项目的始终,目的在于帮助项目经理更好地发现项目存在的问题并且为之采取必要的措施提供了依据,经验告诉我们,成功的成本管理就意味着项目成功了一半。
信息系统项目管理的成本管理
摘要
我在一个软件公司工作,我所在的公司在2005年10月承接了铁路工程总公司的铁路工程概预算系统项目的开发,我有幸参加了该项目,并担任项目经理,自始至终参与了整个项目的建设。
本文以我主持的该项目为实例,探讨了在项目管理中始终作为薄弱环节的成本管理中遇到的问题和解决的办法,文章首先解释了成本管理的基本概念,基本原理及其重要性,总结当今项目管理中严重超支的原因,及造成的严重后果。
提出了应按照项目成本管理的流程资源计划,成本估算,成本预算,使用EVM进行成本控制。
并借助microsoftproject2000辅助项目成本管理很好的把握了项目的成本管理。
铁路工程概预算系统项目自2005年10月启动到2006年5月项目验收历时7个月系统至今运行稳定,取得用户好评,很大程度上得益于项目成功的成本管理。
正文
项目成本管理是项目管理的一个重要组成部分,它是指在项目的实施过程中保证完成项目所花费的实际成本不超过其预算成本估算、项目预算编制和项目成本控制等方面的管理活动。
当前软件生产仍然采用的是19世纪手工作坊的生产方式。
据美国国家标准和技术研究院的一份报告显示,占据世界软件销售额85%的大型的专用软件,其开发的失败率却高达70%。
根据《旧金山新闻》刊登在头版条题为“计算机失误花费政府10亿美元”的文章,在20世纪90年代后期,加利福尼亚州存在着一系列的成本高昂的失误IT项目,花费了纳税人将近十亿美金。
IT项目造价昂贵,并以项目全部完成时常超出预算著称。
项目的实际成本一般是原始估算成本的189%,因此许多项目因为超支太多而夭折!
鉴于这种情况,我在主持的铁路系统概预算软件系统中特别注重了项目成本管理。
项目经理作为项目的主要承担者,要组织项目干系人在规定时间内利用有限资源保质保量的完成项目,努力减少成本,控制成本,以满足利益相关者的期望。
然而成本管理却一直
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 信息系统 项目 管理 论文