工程项目管理经验总结.doc

工程项目管理经验总结.doc

ID:58294502

大小:42.50 KB

页数:19页

时间:2020-04-13

工程项目管理经验总结.doc_第1页
工程项目管理经验总结.doc_第2页
工程项目管理经验总结.doc_第3页
工程项目管理经验总结.doc_第4页
工程项目管理经验总结.doc_第5页
资源描述:

《工程项目管理经验总结.doc》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、.工程项目管理经验总结  篇一:  从去年以来,我完整地参与了XXX项目的建设与管理工作,到现在项目已经基本收尾,下一期的项目也启动在即,现在有必要总结下该项目的得与失,从而指导下一期项目的建设工作,犯过的错误不要再犯,好的做法需要继续保持和发扬。  一、项目成功之处  1、项目进度管理相对较好  本项目的进度管理相对比较好,没有出现严重的进度延误的情况,主要是由于了实施了周例会+月例会+项目考核等制度。项目团队在每月末召开月例会,主要是总结上个月的工作目标完成情况,并共同制定下个月的工作目标。为了确保月度工作目标的实现,同时将月度工作计划分解成周工作计划,并以周例

2、会的形成来跟踪和监控项目目标的完成情况。除了月例会和周例会之外,同时对项目团队进行考核,如果月度工作目标没有完成就实施考核扣分。精细化的进度管理加上监督和考核机制可以基本保证项目的进度。专业资料.  2、建立起了一些管理制度  在项目实施的过程中,针对日常工作中一些不规范、混乱的地方,制定了相应的管理机制,主要有以下几个方面:  (1)新业务需求响应机制  新业务需求指的是在项目建设过程中,不包含在项目需求范围内的,业务部门日常工作过程中提出的一些关于系统的优化需求。项目团队原来对新业务需求的处理流程混乱,新业务需求往往存在项目团队的头脑中,过一段时间之后根本不清楚

3、哪个业务部门提了哪个需求,就算需求实现之后也没有反馈机制,给业务部门的感知交叉。在本项目实施过程中,针对这个问题专门建立了一条新业务需求响应机制,当接收到新业务需求之后,需要专门记录下需求的相关信息,例如需求描述,需求提出人的;接收到需求之后需要立即与需求提出人确认需求,并反馈需求接收到,告知需求的计划完成时间;当新业务需求开发上线之后,需要向需求提出人发送上线反馈单,告知提出人他的需求已经实现了。  从需求的接收到最后上线后的反馈等环节  (2)上线机制专业资料.  由于历史原因,我们项目团队相关工作的规范性不如BOSS那边,系统上线这一块也没有规范起来,以前项目

4、团队想上线就上线,从而系统的稳定性和安全性存在很大的隐患。为了规范系统上线流程,并向BOSS侧接轨,制定了上线流程,每月允许上线两次,上线之前需要提供需求、设计、测试、上线风险评估报告等文档,并提交上线申请至领导处审批,审批通过之后才允许开放商进行上线,上线完之后需要提交上线跟踪分析报告。  (3)沟通机制  建立了月例会、周例会制度,每次例会后以会议纪要的形式发出会议上达成的共识,作为后续衡量和评估相关决定有没有去贯彻和落实的依据。之前项目团队也会开例会,但是会议达成的需要去解决的问题往往会上说说的好好的,但是会后没有真正去做,会议成了一种形式。  (4)系统运营

5、报告制度  项目团队之前非常不重视系统应用的推广,往往功能上线之后就算完成了,不会去关注这个功能到底有没有被用起来,也不清楚整个系统的应用情况。在项目期间,我们建立了系统运营情况每月报告制度,将系统重要应用的使用情况以月报的方式发送给领导及相关人员。  二、项目不足之处专业资料.  1、对项目合同的把控不足,给后续管理工作带来隐患  由于公司IT系统的合同由其它部门负责管理,我们部门主要负责具体系统的建设,因此在本项目中对项目的合同关注不够,对项目的合同内容把控不足。主要体现在以下几个方面:  (1)合同中的项目的建设内容与当初汇报的建设方案中的内容两者没有仔细地核

6、对,有一些我方希望纳入的建设内容结果在合同中没有体现,最终导致我方与软件开放商之间的扯皮,软件开放商会拿合同来说事,这是很致命的一个问题,说到底关于项目合同是两个部门之间的衔接出现了问题。  (2)项目团队成员没有仔细核实,虽然在看合同时也发现了这个问题,但是由于对方是我公司的长期合作伙伴,这些小问题没有太多的在意,现在看来这种原则性的问题还是不能忽视。  (3)在签订项目合同是,我们公司通常要求包含项目的考核规则文档,在做本期项目时没有仔细地考虑好如何进行考核,结果把非常通用的一个考核规则文档放入了合同中,但这个通用的考核规则很多地方并不适合本项目,导致在后续实际

7、考核工作中,有些问题由于没有在考核规则中详细的描述清楚,导致具体执行起来没有依据,容易出现扯皮。  2、新业务的开发模式专业资料.  由于本项目的需求相对比较分散,因此在实施项目时采用的是新业务的开发模式,即一个个功能模块依次开发,每个功能模块都要经历需求分析、设计、开发、上线等阶段,有点类似迭代的开发模式。但是这种模式存在一些问题:一是每次迭代划分的太细,导致几乎每个月都要经历需求、设计、上线这些工作;二是这种开发模式导致对系统的整体把控能力不足,可能由于原来相关的一些功能模块,本来应该统一考虑需求和设计的,但是由于人为地把他们分割成多个阶段来实现,导致出现顾

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。