工程项目管理总结2篇
总结是对某一阶段的工作、学习或思想中的经验或情况进行分析研究的书面材料，它有助于我们寻找工作和事物发展的规律，从而掌握并运用这些规律，因此我们需要回头归纳，写一份总结了。你想知道总结怎么写吗？下面是小编帮大家整理的工程项目管理总结，供大家参考借鉴，希望可以帮助到有需要的朋友。
工程项目管理总结1
一年一度的社团招新工作终于圆满结束了，为了能够更好的进行以后的工作，现将本次招新工作总结如下：
一、前期准备。
组织本次招新工作，本协会从招新前两周便开始筹备。刚开学便着手本协会宣传页的设计和制作工作，短时间内便已完成，并组织本协会干事到新生自习室演讲宣传协会并发放适当宣传单和报名表。这极大的促进了新同学对工程项目管理沙盘协会认识和了解。
10月14号本协会内部召开会议，对招新的各项工作进行了安排布置，同时对招新时段的人员进行分配，做到了招新工作的计划性。
二、招新过程。
虽然做好了充分的准备进行招新工作，但是仍然在前段时间发生的短时间的人员混乱以及责任不明确的现象，以及学校临时增加的'招新要求也是我们没有想到的。但是经过大家的努力，一切困难都被我们克服了。
10月18号晚，协会在实验室举行沙盘观摩面试会，本次参加协会的人数大大增加，这是这些天同学们在招新工作期间努力工作的结果。同时我们也初步筛选出了留在协会继续学习的同学。
三、后期工作。
招新工作结束后，我们立刻组织人手将招新所借物品归还原主。
四、招新心得
我们今年的的招新情况总体来说好于往年，在招新过程中，同学们有的放弃了吃饭，有的放弃了休息，有的放弃了学习时间，只是为了能使我们的协会能够发展的更好。在这里，我要郑重地对你们说一声，谢谢。
在这次招新活动中，给了我最大帮助的，还是大二依然坚持留在协会帮助我的同学。进入大二，很多同学都因为这样或那样的问题，渐渐离开了社团，或者不再负责协会的日常事务，我们协会也不例外。但是在这新老交替的风雨飘摇之际，协会仍有一些同学留下来帮我一起做，他们的帮助使我感觉到自己不是一个人在战斗，至少还有这样一群朋友在默默的无私的帮助和鼓励我。当然说了这么多，这次招新工作我认为还是存在一定问题的。至少是在协调管理方面做得不到位，并且宣传方面虽然已经很不错，但我认为还不够。另外就是没有联合商家一块进行，不能达到招新费用的自给化。这些问题在以后的工作中会尽量改正。
工程项目管理总结2
一、项目成功之处
1、项目进度管理相对较好
本项目的进度管理相对比较好，没有出现严重的进度延误的情况，主要是由于了实施了周例会+月例会+项目考核等制度。项目团队在每月末召开月例会，主要是总结上个月的工作目标完成情况，并共同制定下个月的工作目标。为了确保月度工作目标的实现，同时将月度工作总结计划分解成周工作总结计划，并以周例会的形成来跟踪和监控项目目标的完成情况。除了月例会和周例会之外，同时对项目团队进行考核，如果月度工作目标没有完成就实施考核扣分。精细化的进度管理加上监督和考核机制可以基本保证项目的进度。
2、建立起了一些管理制度
在项目实施的过程中，针对日常工作中一些不规范、混乱的地方，制定了相应的管理机制，主要有以下几个方面：
(1)新业务需求响应机制
新业务需求指的是在项目建设过程中，不包含在项目需求范围内的，业务部门日常工作过程中提出的一些关于系统的优化需求。项目团队原来对新业务需求的处理流程混乱，新业务需求往往存在项目团队的头脑中，过一段时间之后根本不清楚哪个业务部门提了哪个需求，就算需求实现之后也没有反馈机制，给业务部门的感知交叉。
在本项目实施过程中，针对这个问题专门建立了一条新业务需求响应机制，当接收到新业务需求之后，需要专门记录下需求的相关信息，例如需求描述，需求提出人的;接收到需求之后需要立即与需求提出人确认需求，并反馈需求接收到，告知需求的计划完成时间;当新业务需求开发上线之后，需要向需求提出人发送上线反馈单，告知提出人他的需求已经实现了。从需求的接收到最后上线后的反馈等环节。
(2)上线机制
由于历史原因，我们项目团队相关工作的规范性不如BOSS那边，系统上线这一块也没有规范起来，以前项目团队想上线就上线，从而系统的稳定性和安全性存在很大的隐患。
为了规范系统上线流程，并向BOSS侧接轨，制定了上线流程，每月允许上线两次，上线之前需要提供需求、设计、测试、上线风险评估报告等文档，并提交上线申请至领导处审批，审批通过之后才允许开放商进行上线，上线完之后需要提交上线跟踪分析报告。
(3)沟通机制
建立了月例会、周例会制度，每次例会后以会议纪要的形式发出会议上达成的共识，作为后续衡量和评估相关决定有没有去贯彻和落实的依据。之前项目团队也会开例会，但是会议达成的需要去解决的问题往往会上说说的好好的，但是会后没有真正去做，会议成了一种形式。
(4)系统运营报告制度
项目团队之前非常不重视系统应用的推广，往往功能上线之后就算完成了，不会去关注这个功能到底有没有被用起来，也不清楚整个系统的应用情况。在项目期间，我们建立了系统运营情况每月报告制度，将系统重要应用的使用情况以月报的方式发送给领导及相关人员。
二、项目不足之处
1、对项目合同的把控不足，给后续管理工作带来隐患
由于公司IT系统的合同由其它部门负责管理，我们部门主要负责具体系统的建设，因此在本项目中对项目的合同关注不够，对项目的合同内容把控不足。
主要体现在以下几个方面：
合同中的项目的建设内容与当初汇报的建设方案中的内容两者没有仔细地核对，有一些我方希望纳入的建设内容结果在合同中没有体现，最终导致我方与软件开放商之间的扯皮，软件开放商会拿合同来说事，这是很致命的一个问题，说到底关于项目合同是两个部门之间的衔接出现了问题。
项目团队成员没有仔细核实，虽然在看合同时也发现了这个问题，但是由于对方是我公司的长期合作伙伴，这些小问题没有太多的在意，现在看来这种原则性的问题还是不能忽视。
在签订项目合同是，我们公司通常要求包含项目的考核规则文档，在做本期项目时没有仔细地考虑好如何进行考核，结果把非常通用的一个考核规则文档放入了合同中，但这个通用的考核规则很多地方并不适合本项目，导致在后续实际考核工作中，有些问题由于没有在考核规则中详细的描述清楚，导致具体执行起来没有依据，容易出现扯皮。
2、新业务的开发模式
由于本项目的需求相对比较分散，因此在实施项目时采用的是新业务的'开发模式，即一个个功能模块依次开发，每个功能模块都要经历需求分析、设计、开发、上线等阶段，有点类似迭代的开发模式。
但是这种模式存在一些问题：
一是每次迭代划分的太细，导致几乎每个月都要经历需求、设计、上线这些工作;
二是这种开发模式导致对系统的整体把控能力不足，可能由于原来相关的一些功能模块，本来应该统一考虑需求和设计的，但是由于人为地把他们分割成多个阶段来实现，导致出现顾了当前没有考虑到将来及对原有功能模块的影响;
三是这种开发模式使得项目经理不清楚整个项目的工作重点应该放在哪里;
这种开发模式在下一期的项目中需要改进，不能再采用这种方式了。
3、建设方案设计及汇报能力不足
本期项目的建设方案主要由主管来完成的，理想的情况是方案由我来写，主管提供一些指导和意见，这样我这个角色才算是称职的。方案完成之后，向领导的汇报工作不是很成功，前后汇报的三次才算通过，这算是一次很深刻的教训，需要吸取。
4、需求文档和设计文档的规范性
需求文档和设计文档的规范性这个问题一直困扰着我，不仅仅是这个项目，其它项目也存在相同的问题，就当前我所参与过的项目来讲，需求和设计能够做的好的很少。
需求文档和设计文档应该体现哪些内容，这些内容如何以比较好的方式来表达，才能清晰地描述清楚需求和系统的设计?
5、应用推广重视度不够
建设一个系统的目的是什么?目的是希望系统能够为公司带来价值。
那么如何体现价值?系统通过为公司的业务发展提供支撑能力，从而实现公司收入的增长的方式来体现价值。
那么系统只有真正被业务部门使用起来才能够发挥出价值。
而在本项目的建设过程中，虽然意识到了应用推广的重要性，但是具体的应用推广工作还是做的非常不够，感觉是在为建设系统而建系统，感觉最求的是完成建设任务，至于用不用就不关我事了。
【工程项目管理总结】相关文章：
工程项目管理总结12-19
工程项目管理总结[实用]07-18
工程项目管理总结15篇02-13
工程项目管理工作总结10-24
工程项目管理总结1000字（精选9篇）10-15
建筑工程项目管理总结（精选14篇）10-15
工程项目管理口号汇总07-06
工程项目管理培训心得03-31
【优选】工程项目管理工作总结09-16