项目问题总结
1.项目总结怎么写啊
XX项目总结报告
XX单位管理委员会(你要汇报的机构,不能针对个人):
受领导指派,我于XX年XX月XXX日负责XX项目。X个月来,在领导的大力支持及同志们的密切配合下,项目进展顺利。于XX年XX月XX日圆满地完成了该项工作。现将项目建设情况汇报如下:
一、项目基本情况:
这一段回顾一下项目立项的依据及意义。
二、建设中的工作情况(最好给每一个小标题都起一个煽情的名字)
你是如何干的。包括你的指导思想、工作方针、工作措施、工作实际。可以加入一两个工作片断,以显得更加真实、感人。其实主要目的应该是向领导邀功。
三、
建成后的各项指标,要有具体数据,并以简要的分析做结语(这一段和二、建设中的工作情况调换也可以。灵活掌握吧)。
四、存在的不足:
(在这里矫情一下,比如发现了自身知识积累不足等)
五、几点体会:
(在这里你向领导表忠心。以“总之,在领导的大力支持下,该项目取得了成功,你个人的业务素质也在工作中也得到了提高”结束本段)。
以上是XX项目工作情况。请审阅。
XXX(这里是姓名,前面也可加公司名称和职务)
年月日
2.项目总结报告怎么写
XX项目总结报告
XX单位管理委员会(你要汇报的机构,不能针对个人):
受领导指派,我于XX年XX月XXX日负责XX项目。X个月来,在领导的大力支持及同志们的密切配合下,项目进展顺利。于XX年XX月XX日圆满地完成了该项工作。现将项目建设情况汇报如下:
一、项目基本情况:
这一段回顾一下项目立项的依据及意义。
二、建设中的工作情况(最好给每一个小标题都起一个煽情的名字)
你是如何干的。包括你的指导思想、工作方针、工作措施、工作实际。可以加入一两个工作片断,以显得更加真实、感人。其实主要目的应该是向领导邀功。
三、
建成后的各项指标,要有具体数据,并以简要的分析做结语(这一段和二、建设中的工作情况调换也可以。灵活掌握吧)。
四、存在的不足:
(在这里矫情一下,比如发现了自身知识积累不足等)
五、几点体会:
(在这里你向领导表忠心。以“总之,在领导的大力支持下,该项目取得了成功,你个人的业务素质也在工作中也得到了提高”结束本段)。
以上是XX项目工作情况。请审阅。
XXX(这里是姓名,前面也可加公司名称和职务)
年月日
3.项目管理心得体会
项目管理心得体会 经过二郎山项目、鹧鸪山项目和水界等项目的项目管理工作实践,对项目管理的各方面事务感触颇深。
在此,我将这多年的心得体会梳理,抛砖引玉,希望各位同行及领导多多斧正。 一. 管理时间就是管理自己,高效利用时间 每个人的工作课题存在差异,每个人的思想境界各有不同。
但是上帝却很公平的给了每个人一天24小时的时间,因此我们提出管理时间,是每个人都可以做到的事情。每天把24小时规划好,也就管理好了自己。
平时大家会说时间不够,事情做不过来,我建议大家把时间拿出来分析一下,根据工作性质合理安排时间。对于项目管理,事情多,工作琐碎.,这样我就养成了每天入睡前回顾一天工作的习惯,并对第二天的工作进行安排。
在安排工作上要求本部门各级员工把握一个主次分明,轻重缓急合理的原则。这样每天当一到工作岗位上就能很快的进入工作状态,而员工的工作也各级抓好,紧张工作。
这样就很好的把握和做到--"工作时效"。 二. 分清各项工作的轻重缓急 "轻重缓急"对于每个人来说都很重要,这就要求思路活跃,把火烧眉头的事情先处理掉,然后再去做日常工作。
就好比用户要一个深层次的技术交流,要求特别着急,这时你就需要安排资深的人员进行相关的支持,电话中能够完整的提供就现场进行,若是需面对面的进行,那好,用户的需要就是一切.总之轻重缓急具有非常的灵活性、时间性、场合性要视具体情况而当机立断。做好了也是减少客户抱怨的有效方法。
三. 不断规范和调整制度,没有规矩不成方圆 谈到管理,就一定要从规范入手。规范是我们日常工作的行为准则,是企业生存、运作、发展、壮大的标尺和纲要。
它的实施者既是所有领导,又是全体员工。只是各个岗位所规范的内容不同罢了。
万事开头难,难就难在你走出的第一步,第一步迈出去了,第二、三步就没有问题了。正如我们日常工作,你没有第一稿资料,就没有后续的所有工作内容。
你最近没有向职能部门提交**问题,就没有人来问你这个或哪个问题是如何如何的,等大家都有反映了这件事情,就有人开始琢磨怎么样来规范这项工作,让大家都按这个规定来做。以后大家就在这个基础上第二步、第三步的完善工作,把工作做得更好!任何事情都是一样的道理,只要你想做,你就会去规范这件事情,规范也就使每个人有了行为的准则。
四. 提高会议效率,事前告诉大家会议的内容 工作中的很多问题都是在会议中解决的。会议使我们对问题有了更多、更好的解决方案。
我们平常碰到的会议也比较多,大大小小、各式各样的都有,那么如何提高会议的效率就成为大家关注的事情。如果我们在会议之前把要开会的事项告诉所有人,让大家都有准备,开会的时候就可以切入主题,谈每个人的思路,这样可以缩短一些时间。
往往在会议上大家谈着谈着就会跑题,这时候就需要会议的主持人能够引导大家的思路往一个方向;再有就是会议结束前主持人或主管人员一定要重述这次会议的几项内容和解决措施,这样大家才会感觉到会议的重要性。 五. 统计数据,针对数据进行分析,分析结果加以应用,最后不忘评估、验证成果。
统计数据简单的说就是一个工作量化。是总结工作最直接、最明了的方法之一。
统计对于各块的工作都很重要,没有数据的分析,我们不知道努力的方向,至少说轻重缓急把握不好,有了数据就可以比较,知道目前面临最大的缺陷在哪里,针对弱点加以改进。对于基层的管理人员来说数据的统计可以通过公司相关部门获得,得到的数据分析后一定要应用,只作分析不加以应用等于白搭,反而增加了工作量。
有的会说,我应用了但效果不大,问题就是应用后,有没有跟踪验证,我们对分析出来的数据没有应用,没有验证,怎么会知道我们的分析是对的呢!因此分析-应用-验证,三者一个都不能少。 六. 愿景引来注意、尊重加深信心、沟通加强意义、立场导致信任 1)愿景--每次开会公司都会给我们描绘一下愿景,公司现在…… 即将……将来是…… 对于这些传到耳朵里的信息,员工们总是格外的在意,有的甚至在聆听笔记,这是不知不觉的愿景激励。
因为这些都与公司的每一分子的切身利益直接相关,不管愿景好与坏大家都会关注,我们跟同事开会的时候也不要忘记强调三年规划。 2)尊重--同事之间相互尊重,可以加深合作,同时也会得到其他人的尊重,做起事情也会格外的舒坦。
工作之余都谈到沟通很关键,企业领导鼓励下属发言,但自己却不太发言也不太敢发言,所以最后的结果常常就是大家都不发言,最后就变成你看着我、我看着你,然后领导看着现场所有人,脸上一副「说话呀!」的样子。这种状况就似乎是如果有一个人把话说出来之后他马上就会被企业宣判死刑一样,然后紧接着就被淘汰出局似的,所以大家对于自己想说的话都往肚子里吞,戒慎恐惧,一副「不要问我,我什么都不知道!」、「请你不要找我麻烦!」、「该死!怎么这么准,刚好问到我了!」的样子,所以只要你一鼓励他们把话说出来,大多数的时候,你很难获得到他们的回应,如果现场里有一、两个人敢勇于表达自己的意见,就已经算是不错。
4.项目总结都要写哪些内容
1 项目概述
1.1 产品
简要说明项目所完成的产品的功能、特点
1.2 项目组成员
描述项目所涉及的角色和人员
2 项目状态总结
2.1 进度
项目实际进度与计划 的对比
2.2 工作量
项目实际工作量与计划工作量的对比
2.3 成本
实际成本与计划成本的对比
2.4 规模
代码、文档实际规模与计划规模的对比
2.5 关键计算机资源
各资源实际占用率与计划占用率比较
2.6 风险
实际发生的风险、所造成的影响和采取的行动与计划的比较
非预计风险的数量
2.7 技术方案评价
项目采用的技术的利弊
2.8 KPA状态
2.8.1 需求管理
用户需求更改的次数
更改需求造成的影响
2.8.2 组间协调
组间曾出现的问题和解决措施
2.8.3 里程碑评审
实际完成的里程碑评审
2.8.4 培训
实际完成的项目培训与计划的比较
2.9 其他
项目经理希望说明的项目的其他方面的状态
3 经验及教训
根据第2节中项目状态总结,项目经理分析项目所获得的经验以及今后应该注意问题
4 建议
针对项目中的实践,项目经理提出一些改进建议,例如对规范。
5 结论
说明项目是否成功,以完全满足验收标准为成功。
5.项目工程总结怎么写
你好,我也是搞工程施工的,以下仅为交流:
1、是上级那个单位要的,这个写总结时,必须得有数。
2、写的内容涉及哪几个部门,需要各部门配合,各自写管辖范围内的工程总结,集整个项目部之力,方可写出高水平的项目工程总结。
3、统稿人必须对项目有比较清楚的认识,对项目所发生的大事比较清楚,一般情况由工程技术部或综合管理部来统稿。
4、初稿之后和主管领导沟通,把整个总结在从头分析一下,再行修改。
总之,项目工程总结是一个综合性、有针对性的文件。
6.如何改进项目的经验教训总结会
虽然项目本身没有实行敏捷管理方法,但是任何团队也可以通过采用精益和敏捷管理方法总结经验教训,进而提升项目的交付能力。
针对特定团队、项目和技术方面找问题
经验和教训的总结通常放在项目的最后
如果问题不针对特定的团队、项目或技术,也会因为太过模糊而失败
让我们逐个分析上述三个方面为何失败。
针对特定团队、项目和技术方面找问题
大多数在经验教训总结会上被提出的问题只集中在那些已经完成的项目。但即使同一个团队,也不会可能会再做一个项目,一些与具体项目相关的问题也可能也不会出现在下一个项目里。另外,不同项目中采用的技术手段也会出现差异。结果就造成,针对特定团队、项目或者技术的经验教训总结会变得一无用处。
经验教训总结会通常放在项目的最后
传统的经验教训总结通常会在项目结束之后进行,大概是为了提醒团队在下一个项目不犯类似的错误。但这种的方式的问题在于,很多人甚至不记得两周之前发生过什么,更别说有的长达半年后两年的项目了。试图回忆一年前项目中经验教训几乎是不可能的。此外,前文已经说过,如果是对已经完工项目的经验总结会,那么几乎是没有任何意义的:没有人能从中学到什么,也不会产生任何对未来项目有用的知识。这两方面决定这项措施必然会失败。
如果问题不针对特定的团队、项目或技术,也会因为太过模糊而失败
为了解决上述两个问题的困境,人们会将某些概念或问题一般化,希望能形成指导任何项目实行的一般性建议。如果我们试图这么做,那么这些所谓的普世经验或教训显得荒谬和可笑。我听过像“沟通是很重要的”、“股东们应该更关注公司发展”、“预算一定是可控的”之类的“普世经验”。这些表述是确实非常正确,但也是没有意义的,因为他们没有从根源探寻问题本质,也没有给出创造性的解决方法。那该怎么办?几乎每一个可提供真正生产效率的问题都是由特定的团队、项目或技术相互作用的复杂产物。任何一个项目都有其特定的问题,很有能有放之四海而皆准的解决方案。
传统的经验教训总结会与精益或敏感管理方法里的经验教训总结有着本质上的不同,具体来说,表现在方法、时间以及为什么要进行经验教训总结等方面。传统的经验教训总结为了不再重犯之前的错误,而精益或敏捷的经验教训总结(通常称作回顾或改进会)则是为了立刻纠正现有项目中的错误。他们会非常频繁的开会,花时间去解决现有项目中的一些问题。
针对特定团队、项目和技术方面找问题。
依然是针对特定的团队、项目或技术寻找问题,但因为队员们正在使用技术执行项目,所以这时的总结很有效。团队成员在总结会上对一些问题解决起来得心应手。
经验教训总结会通常放在项目的最后
精益或敏捷的总结会不会放在项目收尾阶段。他们会两到四周举行一次会议。这会产生以下三个方面的成效:
总结会放在项目中间阶段,会使得团队根据项目进展情况迅速解决。
如果问题不针对特定的团队、项目或技术,也会因为太过模糊而失败
在回顾或改善总结会,问题是不会一般化处理的。如果会议能对问题进行根本分析,并提出非常明确地解决方案,那么这个会议是不会结束的。这些解决方案会在下一次总结会上就实施情况再做总结。
即使某个项目是由传统方法驱动的,任何人也可以将精益或敏捷方法实施在项目的经验教训总结上。