2022年工程项目管理工作总结

上传人:壹****1 文档编号:477788511 上传时间:2023-11-28 格式:DOC 页数:6 大小:18.50KB
返回 下载 相关 举报
2022年工程项目管理工作总结_第1页
第1页 / 共6页
2022年工程项目管理工作总结_第2页
第2页 / 共6页
2022年工程项目管理工作总结_第3页
第3页 / 共6页
2022年工程项目管理工作总结_第4页
第4页 / 共6页
2022年工程项目管理工作总结_第5页
第5页 / 共6页
点击查看更多>>
资源描述

《2022年工程项目管理工作总结》由会员分享,可在线阅读,更多相关《2022年工程项目管理工作总结(6页珍藏版)》请在金锄头文库上搜索。

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

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

3、个问题专门建立了一条新业务需求响应机制,当接收到新业务需求之后,需要专门记录下需求的相关信息,例如需求描述,需求提出人的;接收到需求之后需要立即与需求提出人确认需求,并反馈需求接收到,告知需求的计划完成时间;当新业务需求开发上线之后,需要向需求提出人发送上线反馈单,告知提出人他的需求已经实现了。从需求的接收到最后上线后的反馈等环节(2上线机制由于历史原因,我们项目团队相关工作的规范性不如boss那边,系统上线这一块也没有规范起来,以前项目团队想上线就上线,从而系统的稳定性和安全性存在很大的隐患。为了规范系统上线流程,并向boss侧接轨,制定了上线流程,每月允许上线两次,上线之前需要提供需求、设

4、计、测试、上线风险评估报告等文档,并提交上线申请至领导处审批,审批通过之后才允许开放商进行上线,上线完之后需要提交上线跟踪分析报告。(3沟通机制建立了月例会、周例会制度,每次例会后以_的形式发出会议上达成的共识,作为后续衡量和评估相关决定有没有去贯彻和落实的依据。之前项目团队也会开例会,但是会议达成的需要去解决的问题往往会上说说的好好的,但是会后没有真正去做,会议成了一种形式。(_系统运营报告制度项目团队之前非常不重视系统应用的推广,往往功能上线之后就算完成了,不会去_这个功能到底有没有被用起来,也不清楚整个系统的应用情况。在项目期间,我们建立了系统运营情况每月报告制度,将系统重要应用的使用情

5、况以月报的方式发送给领导及相关人员。二、项目不足之处1、对项目合同的把控不足,给后续管理工作带来隐患由于公司it系统的合同由其它部门负责管理,我们部门主要负责具体系统的建设,因此在本项目中对项目的合同_不够,对项目的合同内容把控不足。主要体现在以下几个方面:(1合同中的项目的建设内容与当初汇报的建设方案中的内容两者没有仔细地核对,有一些我方希望纳入的建设内容结果在合同中没有体现,最终导致我方与软件开放商之间的扯皮,软件开放商会拿合同来说事,这是很致命的一个问题,说到底关于项目合同是两个部门之间的衔接出现了问题。(_项目团队成员没有仔细核实,虽然在看合同时也发现了这个问题,但是由于对方是我公司的

6、长期合作伙伴,这些小问题没有太多的在意,现在看来这种原则性的问题还是不能忽视。(3在签订项目合同是,我们公司通常要求包含项目的考核规则文档,在做本期项目时没有仔细地考虑好如何进行考核,结果把非常通用的一个考核规则文档放入了合同中,但这个通用的考核规则很多地方并不适合本项目,导致在后续实际考核工作中,有些问题由于没有在考核规则中详细的描述清楚,导致具体执行起来没有依据,容易出现扯皮。2、新业务的开发模式由于本项目的需求相对比较分散,因此在实施项目时采用的是新业务的开发模式,即一个个功能模块依次开发,每个功能模块都要经历需求分析、设计、开发、上线等阶段,有点类似迭代的开发模式。但是这种模式存在一些

7、问题:一是每次迭代划分的太细,导致几乎每个月都要经历需求、设计、上线这些工作;二是这种开发模式导致对系统的整体把控能力不足,可能由于原来相关的一些功能模块,本来应该统一考虑需求和设计的,但是由于人为地把他们分割成多个阶段来实现,导致出现顾了当前没有考虑到将来及对原有功能模块的影响;三是这种开发模式使得项目经理不清楚整个项目的工作重点应该放在哪里;这种开发模式在下一期的项目中需要改进,不能再采用这种方式了。3、建设方案设计及汇报能力不足本期项目的建设方案主要由主管来完成的,理想的情况是方案由我来写,主管提供一些指导和意见,这样我这个角色才算是称职的。方案完成之后,向领导的汇报工作不是很成功,前后

8、汇报的三次才算通过,这算是一次很深刻的教训,需要吸取。4、需求文档和设计文档的规范性需求文档和设计文档的规范性这个问题一直困扰着我,不仅仅是这个项目,其它项目也存在相同的问题,就当前我所参与过的项目来讲,需求和设计能够做的好的很少。需求文档和设计文档应该体现哪些内容,这些内容如何以比较好的方式来表达,才能清晰地描述清楚需求和系统的设计?5、应用推广重视度不够建设一个系统的目的是什么?目的是希望系统能够为公司带来价值。那么如何体现价值?系统通过为公司的业务发展提供支撑能力,从而实现公司收入的增长的方式来体现价值。那么系统只有真正被业务部门使用起来才能够发挥出价值。而在本项目的建设过程中,虽然意识

9、到了应用推广的重要性,但是具体的应用推广工作还是做的非常不够,感觉是在为建设系统而建系统,感觉最求的是完成建设任务,至于用不用就不关我事了。第页共页工程项目管理工作总结(二)耐心细心完成冬季施工尾声工作,加强现场安全管理,在完成施工进度的同时,对工程整体的安全、质量认真执行,对工人分阶段进行安全施工培训及专业技能培训及按时按需发放工人劳保用品。针对现场未能及时清理的施工垃圾要及时清理掉,做到工完场清。对于现场工人取暖问题,要加强现场的安全防护措施。对于年前年后的工作安排到位。_年即将过去,新的一年也即将开始,在这辞旧迎新之际,回顾一年来的工作历程,总结这一年来工作中的经验、教训,有利于在以后的

10、工作中扬长避短更好的做好技术管理工作,下面分几方面对一年来的工作进行一下总结。一、今年的主要工作在过去一年做为施工现场施工管理人员,按照公司和领导的要求按时按质的完成了各项施工管理工作。1、施工管理过去一年时间里与一公司_工程相邻施工,不论是施工质量、施工进度、施工现场的管理都给我很大的压力,我工作的好坏已不是个人问题,直接影响到我们项目部声誉和今后发展。所以在今年的施工中必须认真学习施工图纸和施工规范以确保施工质量,在学习同时把施工重点、施工方法和处罚条例都记录下来,以便技术交底中不遗漏,尽量做到事先预料,事前解决,针对有些重点问题在每个阶段施工初期都要向施工队长提出具体要求,特别强调问题的

11、严重性并耐心向他们讲清规范中的要求。在施工前我会详细了解材料的储备情况和人员的准备情况为下一道施工程序做好充分准备。在施工中我严格按照方案实施,施工期间我不间断的在施工现场巡视,对施工重点情况落实检查、对施工质量的控制、化解各施工班组之间的矛盾、解决现场施工过程中出现的问题从而管理上保证了施工进度。2、资料管理在资料方面:按照工程的形象进度及时完成施工记录、放线记录、过磅记录、见证记录的编制,配合资料员完成检验批验收记录,并及时找驻地工程师签盖章,做到了施工资料与实际施工日期相吻合,满足了资料的编制要求。二、工作中存在的问题自身方面因为经验不足在说话、做事方面优柔寡断,对问题考虑不够全面,盲目的听从施工班组的意见没有更清楚、没有详细对事件进行分析就下结论,从而造成了不必要的损失。在管理上:对不听指挥、不按要求施工的班组没有进行严厉的惩罚,久而久之个别施工班组就有了侥幸的心态,至使在后期管理工作中出现了出现管理失控,也就形成安排工作难,现场管理难的情况。在以后的管理工作中首先要明确自己的立场,发挥项目管理人员在施工现场起的主导作用,对施工班组做到奖罚分明,形成绝对以项目部为中心领导方法,对那些不听指挥的施工班组决不心慈手软,施行严打、严抓以此来树立施工威信。第页共页

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 办公文档 > PPT模板库 > 总结/计划/报告

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号