《工程项目管理工作总结范文.docx》由会员分享，可在线阅读，更多相关《工程项目管理工作总结范文.docx（5页珍藏版）》请在课桌文档上搜索。
1、工程项目管理工作总结范文从去年以来，我完整地参与了X工程的建立与管理工作，到此时此刻工程已经根本收尾，下一期的工程也启动在即，此时此刻有必要总结下该工程的得与失,从而指导下一期工程的建立工作，犯过的错误不要再犯，好的做法须要接着保持和发扬。一、工程成功之处1、工程进度管理相对较好本工程的进度管理相比照较好，没有出现紧要的进度延误的状况，主要是由于了实施了周例会十月例会+工程考核等制度。工程团队在每月末召开月例会，主要是总结上个月的工作目标完成状况，并共同制定下个月的工作目标。为了确保月度工作目标的实现，同时将月度工作准备分解成周工作准备，并以周例会的形成来跟踪和监控工程目标的完成状况。除了月例
2、会和周例会之外，同时对工程团队进展考核，假如月度工作目标没有完成就实施考核扣分。精细化的进度管理加上监视和考核机制可以根本保证工程的进度。2、建立起了一些管理制度在工程实施的过程中，针对日常工作中一些不标准、混乱的地方，制定了相应的管理机制，主要有以下几个方面：新业务需求响应机制新业务需求指的是在工程建立过程中，不包含在工程需求范围内的，业务部门日常工作过程中提出的一些关于系统的优化需求。工程团队原来对新业务需求的处理流程混乱，新业务需求往往存在工程团队的头脑中，过一段时间之后根本不清晰哪个业务部门提了哪个需求，就算需求实现之后也没有反应机制，给业务部门的感知穿插。在本工程实施过程中，针对这个
3、问题特地建立了一条新业务需求响应机制，当接收到新业务需求之后，须要特地记录下需求的相关信息，例如需求描述，需求提出人的;接收到需求之后须要立刻与需求提出人确认需求，并反应需求接收到，告知需求的准备完成时间;当新业务需求开发上线之后，须要向需求提出人发送上线反应单，告知提出人他的需求已经实现了。从需求的接收到最终上线后的反应等环节上线机制由于历史缘由，我们工程团队相关工作的标准性不如boss那边，系统上线这一块也没有标准起来，以前工程团队想上线就上线，从而系统的稳定性和平安性存在很大的隐患。为了标准系统上线流程，并向boss侧接轨，制定了上线流程，每月允许上线两次，上线之前须要供应需求、设计、测
4、试、上线风险评估报告等文档，并提交上线申请至领导处审批，审批通过之后才允许开放商进展上线，上线完之后须要提交上线跟踪分析报告。沟通机制建立了月例会、周例会制度，每次例会后以会议纪要的形式发出会议上达成的共识，作为后续衡量和评估相关确定有没有去贯彻和落实的依据。之前工程团队也会开例会，但是会议达成的须要去解决的问题往往会上说说的好好的，但是会后没有真正去做，会议成了一种形式。（4）系统运营报告制度工程团队之前特殊不重视系统应用的推广，往往功能上线之后就算完成了，不会去关注这个功能原委有没有被用起来，也不清晰整个系统的应用状况。在工程期间，我们建立了系统运营状况每月报告制度,将系统重要应用的运用状
5、况以月报的方式发送给领导及相关人员。二、工程缺乏之处1、对工程合同的把控缺乏，给后续管理工作带来隐患由于公司it系统的合同由其它部门负责管理，我们部门主要负责具体系统的建立，因此在本工程中对工程的合同关注不够，对工程的合同内容把控缺乏。主要表达在以下几个方面：（1）合同中的工程的建立内容与当时汇报的建立方案中的内容两者没有细致地核对，有一些我方盼望纳入的建立内容结果在合同中没有表达，最终导致我方与软件开放商之间的扯皮，软件开放商会拿合同来说事，这是很致命的一个问题，说原委关于工程合同是两个部门之间的连接出现了问题。（2）工程团队成员没有细致核实，虽然在看合同时也发觉了这个问题，但是由于对方是我
6、公司的长期合作伙伴，这些小问题没有太多的在意，此时此刻看来这种原那么性的问题还是不能无视。在签订工程合同是，我们公司通常要求包含工程的考核规那么文档，在做本期工程时没有细致地考虑好如何进展考核，结果把特殊通用的一个考核规那么文档放入了合同中，但这个通用的考核规那么很多地方并不适合本工程，导致在后续实际考核工作中，有些问题由于没有在考核规那么中具体的描述清晰，导致具体执行起来没有依据，简洁出现扯皮。2、新业务的开发模式由于本工程的需求相比照较分散，因此在实施工程时接受的是新业务的开发模式，即一个个功能模块依次开发，每个功能模块都要阅历需求分析、设计、开发、上线等阶段，有点类似迭代的开发模式。但是
7、这种模式存在一些问题：一是每次迭代划分的太细，导致几乎每个月都要阅历需求、设计、上线这些工作;二是这种开发模式导致对系统的整体把控实力缺乏，可能由于原来相关的一些功能模块，原来应当统一考虑需求和设计的，但是由于人为地把他们分割成多个阶段来实现，导致出现顾了当前没有考虑到将来及对原有功能模块的影响;三是这种开发模式使得工程经理不清晰整个工程的工作重点应当放在哪里;这种开发模式在下一期的工程中须要改良，不能再接受这种方式了。3、建立方案设计及汇报实力缺乏本期工程的建立方案主要由主管来完成的，志向的状况是方案由我来写，主管供应一些指导和看法，这样我这个角色才算是称职的。方案完成之后，向领导的汇报工作
8、不是很成功，前后汇报的三次才算通过，这算是一次很深刻的教训，须要吸取。4、需求文档和设计文档的标准性需求文档和设计文档的标准性这个问题始终困扰着我，不仅仅是这个工程，其它工程也存在一样的问题，就当前我所参与过的工程来讲，需求和设计能够做的好的很少。需求文档和设计文档应当表达哪些内容，这些内容如何以比拟好的方式来表达，才能清晰地描述清晰需求和系统的设计？5、应用推广重视度不够建立一个系统的目的是什么？目的是盼望系统能够为公司带来价值。那么如何表达价值?系统通过为公司的业务开展供应支撑实力，从而实现公司收入的增长的方式来表达价值。那么系统只有真正被业务部门运用起来才能够发挥出价值。而在本工程的建立过程中，虽然意识到了应用推广的重要性，但是具体的应用推广工作还是做的特殊不够，感觉是在为建立系统而建系统,感觉最求的是完成建立任务，至于用不用就不关我事了。
