多项目管理心得7篇

时间:2022-09-30 作者:Brave 心得体会

所谓心得体会可以记录我们的感受,要注意着重表达自己的真实感受,心得体会可以遵循我们的内心,促进我们不断思考和进步,下面是范文社小编为您分享的多项目管理心得7篇,感谢您的参阅。

多项目管理心得7篇

多项目管理心得篇1

通过这段时间工程项目管理课程的学习,我对这一专业有了更深一步的认识。从原来的懵懂不知到现在的渐学渐深,可以说这段时间的学习对我以后进一步学习其他专业知识以及今后的实际工作都是有很大益处的,在这里我简要谈一下我对工程项目管理模式的一些心得体会。

传统的设计—招标—建造模式(ddb)由于长期广泛的在世界各地采用,因而管理方法较成熟,参与各方对有关程序都很熟悉。业主方可自由选择咨询设计人员来控制设计要求,并且可以自由选择监理人员来监理工程,采用各方均熟悉的标准合同文本,十分有利于合同管理和风险管理。但是这一模式也存在着或多或少的缺陷,诸如管理和协调工作较复杂、业主前期投入较高、总造价和工期不易控制、质量事故出现时设计和施工双方责任不明确等,容易导致业主对监理工程师控制工期和造价的能力信心不足,这也制约了这一模式在现在工程项目管理中的应用。

而在设计—建造总承包模式(db)中,业主在选定总承包商时能把设计方案的优劣作为主要的评定标准,这在很大程度上能使业主得到高质量的工程设计,并且总承包商能在设计阶段充分考虑施工因素,可以最大程度地减少由于设计错误引起的变更。而且在这一模式中,总承包商对整个工程实行总价包干,并承担全部责任和风险,能使业主对工程成本得到初期的保障。但是由于业主不能直接参与设计过程的监控,再加上实行了总价包干,导致业主对设计细节控制力降低,而且最终可能会影响到工程质量。

设计—采购—施工的模式(epc)与设计—建造总承包模式(db)较类似,能够较好的将工艺的设计与设备的采购及安装紧密结合起来,有利于项目综合效益的提升。但是由于现在国内能够承担大型epc项目的承包商数量不多,经验也不是很丰富,导致承包商在投标报价时可能报价过低,加上由于经验影响到管理能力,可能直接影响到项目的工程造价、效益及质量。

项目管理型承包模式(pmc)的发展得益于近年来国际上部分工程项目在建设管理上的实践,从原来的可研至竣工验收发展成为定义和执行两个阶段,业主在这两个阶段中委托一家工程公司对项目进行全面的管理。第一阶段中pmc在组织或完成基础设计、确定所有技术方案、确定设备材料的价格和数量、对工程造价作出准确估算后编制出设计、采购和建设的招标书,从而确定工程的总承包商。第二阶段中确定下来的总承包商负责执行详细设计、采购和建设工作,这一阶段中pmc负责替业主对全部项目进行管理协调和监理。采用这一模式能够充分发挥管理承包商在项目管理方面的专业水平,统一协调和管理项目的设计和施工,有利于缩短工期。但是业主在这一模式下与施工承包方没有合同关系,对工程的施工控制能力降低;并且与其他传统模式相比增大了管理层的费用。

在市场经济逐渐演变成市场和计划相结合的混合经济的境况下,bot(建设—经营—转让)模式比较符合这种市场机制和政府干预相结合的混合经济的特色。一方面,bot能够保持市场机制发挥作用。

政府以招标方式确定项目公司的做法本身也包含了竞争机制。作为可靠的市场主体的私人机构是bot模式的行为主体,在特许期内对所建工程项目具有完备的产权。这样,承担bot项目的私人机构在bot项目的实施过程中的行为完全符合经济人假设。另一方面,bot为政府干预提供了有效的途径,这就是和私人机构达成的有关bot的协议。尽管bot协议的执行全部由项目公司负责,但政府自始至终都拥有对该项目的控制权。在立项、招标、谈判三个阶段,政府的意愿起着决定性的作用。在履约阶段,政府又具有监督检查的权力,项目经营中价格的制订也受到政府的约束,政府还可以通过通用的bot法来约束bot项目公司的行为。在bot模式中,项目的参与各方均能获得较大利益优势。项目发起人能充分利用项目经济状况的弹性,减少资本金支出,拓宽项目资金的来源,并能将特定风险转移给放贷方,能极大地降低发起人的政治风险;而放贷方在承担风险的同时却大大提高了自身的收益率,并且在参与项目过程中会遇到的竞争较少;政府作为项目的参与方,在实施bot模式过程中能极大降低自身风险,充分发动外资和私营企业或机构的能动性和创造性,引进先进的管理模式和生产技术,并能充分合理地利用资源,有利于发展国民经济和金融资本市场。虽然bot模式也有诸多缺点,比如对于项目发起人而言,项目融投资额较大、融投资周期长、收益的不确定性较大,导致发起人承担着较大风险;对于政府而言,引进的外资和私营企业或机构可能会在当地出现掠夺性经营,并且使用的价格较高,容易导致国民对政府行为的不满。但是,采用bot模式对加快我国基础设施的建设和改革的有着积极的作用,而且在提高项目运作效率、拉动内需、增加就业以及国家一些战略性发展项目上有着充分的推动作用。

因此我认为,在我国大量兴建基础设施的高峰时期,由于急需资金,bot以及类似于bot的一些其它模式的确是一种融资的好方式,只要掌握得当,政府和企业可能双赢。但是,一个国家或一个地区不可能全部或主要靠借钱来兴建基础设施,只能主要依靠政府和民众的财力。在我国刚刚开始大规模兴建基础设施的时候,宣传和提倡bot有其积极和现实的意义,但基点必须放在实施市场化上。如果将bot与市场化划等号,不但不能建立市场化,而且基础设施的建设和运营也可能会出现畸形。

多项目管理心得篇2

时间好快,短短我来到_公司已经两个月拉。在这段时间里,每天都在感受_公司的激情和发展。和同事的相处中,我得到了很多帮助,这其中更多的是来自我的指导人吕某,每每我碰见一些生疏的办事环节或工作任务,总能得到他的精心指导。如今我对_公司有了一个全面的了解,感受到了很多同事间的和谐友好,项目组的团队意识。

在过去的两个月里,我负责x模块的需求讨论、数据库设计,代码编写进度管理的同时,还负责x项目_平台的开发进度管理,通过与大伙的通力合作,基本上在规定的时间内完成了大部分的业务需求。通过这个项目,也增强了自己在项目管理方面的经验,学习了很多x方面的业务知识,全面地了解了项目组内各成员的综合素质和工作能力。就个人业务方面,对x大部分业务做了深入的了解。_评估方面,我主要了解x,x,x,x等业务。当然这很多得益于小唐、小卫、小冯等人的精心指导,我很是感谢他们。

在已过去的x项目实施过程中,我也发现了项目组存在的一些优势和问题。对于优势我就不多说,主要还是大伙的实干精神较强吧。针对项目组存在的一些问题,这里我发表一些个人的观点,仅供参考。

1.项目组的控制力

由于我们当前的项目是一个全新的组合,各成员间存在太多的生疏和不确定性,这就造成了,我们在实施计划任务的过程中,对其风险的控制程度不为乐观。我们在制作相关计划任务的时候总是凭借自己的第一感去处理,所以在实施过程中也出现了很多计划滞后的事件,对待这些滞后我们唯有加班来弥补,过度的加班和返工必然损坏其组内成员对项目组控制力的满意度,当然也直接影响到对公司的认知和评价。

我感觉我们总是缺少一些可以控制和预见的能力,完成任何事情或目标总是存在不可预知的风险,但如何在风险爆发前限度的加以控制,降低其影响层面,那是我们应该去考虑和管控的。

2.项目组的协作力

说到项目组的协作力,我觉得当前我们做的很差,在任务实施的过程中,现在的项目组就好比中国古代的三国时期—群雄逐鹿,各忙各的。每天我们都很忙,但是忙的就是自己的那块空间,彼此的交流和协作时间太少。一个功能模块的实现不是限度去寻求业务的吻合度,而是自己凭借自己脑袋乱写,自创轮子,总是把自己的意识强加给客户。

在过去的代码编写时间里,我总是发现很多同事存在一个问题,自己做的模块与别人的存在关联,这时候彼此间需要进行简单的交流,配合完成。但是很多人没有交流,而是把别人的代码直接下载下来,然后加上自己的需要,提交完事,等其具体人员某天发现自己的代码被修改而不为所知,最终遇到问题,相互推诿,这就是缺乏交流的后果。

说到协作,顺便说下分工,在代码编写的过程中最为紧要的应该就是分工明确啦,我们需要严格规定那些人有相关文件的修改权限,那些文件删除前需要广播说明。而不是一味的看着不爽就改、删、加,试问操作前是否考虑过有对其项目或别人的影响?

3.项目组的执行力

执行力方面,我觉得主要是我们需要的规范太少,可依赖的标准几乎没有。试问下:我们的《开发规范》,《项目组日常行为准则》,《系统技术选型方案》,《技术定型评审标准》,《压力测试评估范围》,《代码检查计划》,《代码核查标准》,《业务流程处理说明》,《项目风险性预测报告》。诸如类似的标准在哪里,目前除了一个大概的开发规范,我没看到任何成型的文档存在。

我们选择了s2,spring,ibatis,dojo这样的技术框架,但是为什么我们要选择这些,而不是去选择s1,hibernate,ext等,我还清楚地记得我们是怎么选择的,很是草率很简单,一拍桌子,ok就选它们了,可是为什么呢?

每次我们讨论业务纷争,总是一味的你一句我一腔,张说张有理,李说李有道。漫天就是口水战,这样的讨论还不如不论,浪费时间,有那些时间不如回家睡觉去。

一个良好的开发框架,一定限制和影响其使用者的研究方向,因为我们日常的编码技术本就是寄托在框架下的ctrl+c、ctrl+v,所以对于开发选择和成熟完善需要一个慎重和持续的过程,我不知道我们现在使用的框架是否需要延续,如果是,我们应该给出健壮性、兼容性、可扩展性、可维护性等相关评审说明。

健壮性应该兼顾做好应对各种高并发、突风险处理;兼容性应该具备不断的技术版本升级、灵活运用于各类数据库;可扩展性保障系统的各类可用性功能扩展,实现方式升级、灵活多变;可维护性告诉我们需要在持续的使用中不断修正其bug和通用性,有专门的人员完成不同时期版本升级,专注于系统架构的相关人员应该对其使用的项目技术有专攻的过程,毕竟任何东西都是有利有弊,不透彻的了解,怎么知道其需要改进的地方呢?

4.项目组的统筹力

最后说说统筹力吧,这很多时候应该是针对实施计划安排,实施过程管理而说的。我希望每次我们制作计划时都做一个简要的评审过程,这样的过程可介乎于几个人内。很多时候做计划的人总是按照自己的思路和想法在行走,我们应该在完成计划之于,多和参与计划的执行人员进行交流,查看其是否可以在计划的时间内完成安排,并进行讨论修正。对一个任务你是否只有一个计划,你是否考虑过当前计划的风险,如果执行者某天生病不来上班或离职了怎么办?你的计划时间某段被公司的集体活动占用怎么办?公司某天停电怎么办?等等类似的问题太多啦,这些就是我们的计划风险,是不可预知的,你是否应该考虑一个b计划

做计划不是做完后盲目的下发开展,别老是告诉你的执行者,就这么干,做不完自己加班,很是暴力。

写了这么多都是自己的想法,很多可能都是片面的观点,对于当前项目组,我感觉很战斗力很强。当然任何东西不是生来就是完美的,就让我们慢慢地改进和磨合吧。忠心希望自己能陪同_公司这个大家庭共同发展、努力。

多项目管理心得篇3

一、项目概况

20xx年3月,我加入聚光科技sap项目组,从项目成立至项目顺利上线持续运营,和40多名项目组的领导同事、共同度过了9个月齐心协力、并肩作战的工作时光。我在这大半年作为项目助理参与支持项目组工作的过程中,获得了来自于项目经理、各模块关键用户、各业务支持部门领导同事、及九慧顾问团队等各方面大力支持,顺利完成项目组的各项工作。

sap系统是为公司的企业管理提供解决方案的高信息化集成系统。在这大半年的过程中,项目组经过业务调研、蓝图规划、系统实现最终准备及上线支持,通过对公司各模块业务流程深入的梳理和规划,完成了公司从前端销售到供应链、后端财务等各项业务的系统切换。这是我第一次参与如此技术密集型的项目,也是第一次和如此多技术及业务骨干们共事,可以说作为一个以市场、品牌宣传、活动策划等作为工作内容的我来说,是一个很好的学习过程,同时也是很大的挑战。

sap信息集成化系统从筹备到上线,及上线运维的约9个月的时间里,大约分为了以下几个阶段:项目准备阶段、需求调研及蓝图设计阶段、系统实现阶段、最终数据准备阶段及上线后的支持阶段。我从入职后即加入sap项目组,从3月8日召开系统上线启动会以来,经历并且参与了系统筹备到上线以及运维期的每一个阶段,深入学习sd/mm/pp/fico模块的各项业务内容和系统操作规范。我一直抱着从零开始的心态,重新学习公司的各项业务,从前端sd模块的项目创建、创建合同、销售订单下达;至系统设计人员进行配置清单下达、非标bom维护;供应链计划员进行mrp运行、计划订单转采购订单;至采购员的采购执行、付款、采购收货、发票及付款;再进入生产阶段,包括生产订单下达、发料、执行、报工入库、生产订单关闭;接着就是物流及仓库的工作了。仓库的成品库存调拨,交货单创建、拣配、发货过账、然后是发货。供应链流程结束后,数据通过sap系统归集到财务人员手中,由他们进行收入确认、收款指派、成本结算等相关业务。整个业务流线,起源于销售,归集到财务,包含生产、采购、发货等各项供应链业务,将各项信息和数据集成到系统,很好的用信息化系统连接起了全过程。

二、项目助理工作日常

我作为项目助理加入sap项目组以来,除了做好项目助理的日常工作,更多的时间花在了学习业务逻辑和系统操作两方面。这约9个月的项目组工作,让我对生产型企业各项业务逻辑有了很好的认识,而sap系统作为公司信息化迭代的载体,将各项流程及审批归集为流程图,将各项销售数据及各项成本,归集为表格,让人一目了然。可以说,加入sap项目组的这大半年,是我了解业务逻辑、提高系统操作、完善人际交往和问题处理能力的最好学习机会,对于公司给我提供一个加入sap项目,学习业务知识的机会,我深表感谢。

项目助理除了参与项目组的各项业务工作,主要的日常运营分为两块:一是项目组成员、会议、文件等行政类日常事物,并辅助项目组跟催未清事项及项目进度;二是团队建设、团队文化、团队活动、项目宣传等各项宣传类工作。在日常的工作交流中,我和团队成员培养了良好的关系,大家在统一了项目目标即系统顺利上线后,工作热情高涨,特别是在8月-9月的系统上线期间,在连续并且高强度的工作压力下,很多人甚至每天工作时间超过16个小时,有人甚至持续加班到凌晨睡在公司。在项目上线前夕,项目组所有成员团结一致,激情高涨。我在完成各项会议安排,人员通知等工作,更多的做好后勤服务,保证大家的夜宵水果和红牛、东鹏特饮等加班能量的供给。面对高强度的工作压力,项目组成员没人叫苦叫累,几乎每天工作时间超过12个小时,中秋节、国庆节也坚守岗位,奋战在系统上线第一线,保证业务流程和评审流程高效,保证数据收集的准确及时,保证各项业务操作顺利高效。

另外,除了项目组日常工作事项,团队建设和文化宣传也是非常重要的一项工作。项目说到底就是团结一群人以目标导向为基础,共同做一件事,所以事情能不能顺利高效的完成,很重要的一部分源于“人”的因素。包括项目组按阶段召开项目启动会、蓝图汇报会、上线动员大会和最后项目总结大会,所有的方式无一不是鼓励团队成员团结一致、凝心聚力。项目组在蓝图阶段结束后进行了一次团建活动,一起体验了富春江皮划艇、定向寻宝等一些考验团队能力的活动项目。轻松愉快的活动流程让大家放松身心、为后续实现阶段的工作状态养精蓄锐。因项目蓝图规划结束后,紧接着就进入系统开发和调试阶段的繁忙工作中。在项目上线前夕,我们安排了团队聚餐,为大家在接下来一个多月的上线冲刺阶段加油鼓劲。

团队建设各项工作,按照项目组计划,依照所有成员的工作状态和当下的阶段情况及时调整,对提高项目组40多位成员的工作积极性提供了很好的助力。

三、项目管理学习心得

我作为项目助理全程参与sap项目的这段时间以来,在不断学习业务知识和系统操作的同时,也时时总结和反思有关于项目管理方面的关键问题和注意点,尤其以团队为单位去推动一场“变革”的时候,产生的来自于内部以及外界的各项助力和阻力,同时对于如何面对机遇和挑战进行了自己的思考。以下,我通过一张思维导图,将我所理解的项目管理学习心得进行说明,希望能够抛砖引玉,为以后的新项目或是助理相关工作类型做一番启发。

我把项目管理的关键点分为以下四点,并就sap项目中实际出现的情况做出自己的思考:

a、]如何跟进未清事项/掌握关键阶段节点

sap项目本次上线的一共有四个模块,分别是sd&ps模块/mm&qm模块/pp模块/fico模块。因为项目涉及公司从前端到后端的全业务流程体系,因此势必面临多业务流线,不同岗位不同工种相互配合的情况。因为体量大,业务复杂,项目在上线前夕面临庞大的未清数据收集工作,虽然项目组已经预料到数据收集情况复杂,数据量大涉及人员多,提前两个月开始了收集计划,并且明确各项数据责任人和时间节点,下发了sap系统数据收集模版,但情况仍然不容乐观。

8月初,未清数据收集计划发布,开始收集;9月初,依据当前进度,发布详细版数据收集计划,明确每一版数据收集的业务范围、时间、各业务单元收集人、责任领导、数据复核完成时间、数据收集完成状态,并就数据收集实际情况和出现的问题,隔天召开数据收集例会,和项目组所有成员宣贯该项工作的重要性,及时跟进进度。因为sd模块需要提前上线,数据量大且配置清单等拆分到站点复杂且耗时,一度面临数据收集逾期,项目上线的风险性高问题。为解决此类问题,项目组自上而下达成了重要性共识,并积极寻求各相关业务部门负责人和各部门一级负责人的支持,项目执行小组组长虞总多次在未清数据收集逾期清单告知邮件中提及:基础数据的完备直接影响到sap-erp整个系统的上线是否顺利成功,所以请务必重视,及时按计划时间完成相关工作,对于工作中确实有难度和工作量的请项目组及信息技术部一起群策群力想办法帮助相关人员保质保量完成。请各业务单元的领导给予相关人员工作上的大力支持,需要资源的也请给予优先考虑支持。决战时刻需要大家每个岗位的成员同心协力,互相配合支持完成,相信在大家共同努力下能顺利成功上线。

visual project(高层计划和任务计划)里强调,高级管理者需要从宏观层次上掌控项目关键点的情况,更关注关键点的达成情况,以及对整个项目预期的影响。根据项目组在未清事项的跟进方式来看,在明确目的、事项明细、责任人和完成时间节点的情况下,另有四个举措,可以更好的掌握关键阶段节点和跟进进度:

一是需要树立项目计划的严肃性和目的的明确性;

二是需要设计项目进展的评审和审批关卡,设计关键点的控制,比如我们每个阶段结束后的相关模块责任人签字确认环节;

三是需要实时掌握项目执行的偏差和趋势;

四是需要寻求支撑,拉动外围环境建设,例如绩效、奖金以及项目组一直在实施的月度之星评选的工作,以促进未清事项的完成。

总之,在项目管理中跟进各项业务进展是非常重要的一项工作,虽然在面对不同的项目内容时会有所变化,但完成该事项的目的都是一致的,因此调动责任人的积极能动性和调动资源、积极寻求支持是比较重要的一个环节。

b、如何协调团队工作、处理团队内部矛盾

有独特想法的人未必有执行力,有执行力的人未必有独特想法,因此我们要组建团队。各项目的团队合作虽然目标是做事,但做事的主体都是人。因此项目的很大一部分工作是协调团队内部工作。

项目组内部交流有两种基本的方式:消息(邮件、备忘录、微信群)和会议。重要信息、通知等大多通过邮件来确认,紧急但不重要的信息通过微信发送。会议是把团队结合在一起的凝固剂,会议成功的关键是只开迫切需要开的会议。在sap项目组会议十分频繁。尤其在业务流程专项讨论阶段,专题会议非常多,再加上项目组例会、培训会等会议,有时一周的会议约有8-10个之多。而部分夯长的会议占用了大家太多的时间精力,导致晚上要加班工作,造成了一个不好的工作影响。后来项目组养成了一个习惯,保证会议议程和参会人员的精简,频繁开会没有错,但没必要的长会坚决不开。

sap项目组的同事都是资深业务骨干,大部分都有超过10年深耕本领域的工作经验,对业务流程和关键阶段非常清楚,在业务流程方面具有相对权威的发言权。因此项目组在进行内部沟通的另一个独一无二的方法是通过四处走动来了解情况。sap项目组除了在滨安路园区的项目指挥部(原党工会议室),另外安排了三个小会议室让各模块成员集中独立办公。只要四处走走,与各模块聊一聊,就可以获得更多信息,许多不太容易暴露出来的小问题和小情绪,就在这茶水间、走廊里、转角口的交流中被无形解决了,因此千万别低估这些随机事实的价值。

无论选择什么样的方式进行沟通,协调团队工作,一定要确保经常而且公开地进行沟通。团队的氛围和士气、良好心态、高效的工作氛围这些都很重要。

c、如何完成跨部门协作共同推进工作事项/ 如何使得上下游业务相关人员接受及传达的信息一致

sap项目组主要分为四个模块,sd/mm/pp/fico模块分别由业务关键用户、组长和顾问团队组成,各模块业务独立又有相关联。因此在蓝图规划阶段,各模块除了梳理例如财务、供应链、事业部等的业务流程外,更多的进行跨模块业务专题的流程串联;包括后期系统实现阶段进行的集成测试和系统联调,也是要进行跨模块的流程串联,对如何更好的沟通模块、衔接业务,都是考验团队协调重要的工作方式。

有效信息有三个关键点:简洁、完整、结构。只要把这三个方面都包含在传递的信息中,就可以做到信息被人理解。因此在进行跨模块沟通时,我们会把相关模块关键用户即业务责任人、模块顾问、模块组长,如有需要会邀请具有决策权的业务负责人共同参与。在会议有限的1-2小时内,就本问题在已有方案的基础上提出优化和修改方案,并就会议讨论点、会议决策点和会后跟进事项(包含责任人和完成时间节点)邮件进行会议纪要的整理和发送确认,如此没有异议则讨论点已确认。如此,在跨模块部门协作推进事项中,各方面均遵循简洁、完整、结构三个关键点,另因为公司流程复杂,业务相关负责人多,有一关键点是,要找对人。要找业务关键责任人及其业务直接领导进行确认。

沟通只是一个过程,而达成共识才是结果。

d、如何处理新系统/新项目在推进过程中来自于外界的不理解和不配合

sap项目按照项目管理流程(project management process )有五个阶段:项目启动、项目计划、项目实施及控制过程、项目收尾和项目后续维护。每个阶段节点的控制和进入下一阶段的方式,在项目组大概有以下几种方法:开蓝图汇报会、蓝图签字确认、项目上线动员大会,还有项目组内部的汇报会和培训会等等,目的都是自上而下进行信息及项目进程的共享,做到项目组所有成员接收到的信息都是同步且最新的。

项目在推进过程中,经常就业务专项问题或流程系统优化方案召开专题会议,首先要在心理方面理解业务部门的困难,让他们觉得项目组的确在为他们所想;在实操方面要让业务部门切切实实的看到优化过后的高效方案和最终效果,并报以期待共同完成该项优化任务。另外,除了主动站在业务部门实操的角度去思考优化方案外,更要用市场化的思维来思考,令对方觉得当下讨论的这个方案,对双方对公司都是一场公平的“买卖”,用双赢的思维推进新系统/新项目的变革过程。

尽管变革是一场阵痛,但晚面对不如早面对,在调动内外部成员工作积极性的同时,也要抱以更大的耐心去听取意见和建议,以达成双赢的结果。

四、项目管理个人收获

在参与sap项目这9个月以来,收获良多。除了用逻辑性和缜密的思维去思考问题以外,更多的是良好的工作和沟通习惯的养成。非常感谢项目经理陆总和九慧项目经理闫总,两位求真求实、事必躬亲的工作精神为项目组为我做了一个很好的工作表率作用,而项目组所有成员的实际工作方式教会我一件事,办法总比困难多。面对一个问题或者一个难题时,不产生知难畏难的情绪,更多的是思考如何解决、用什么样的方法解决和谁能解决。用以目标为导向的工作方式,而不是过程导向。

个人收获总结归纳为以下四点:

a、想清问题背后的逻辑,而不仅仅停留在表象;

在项目组工作的日子里,时常会听到开发组或者各模块顾问老师询问需求提出者这么一句话:这么做背后的逻辑是什么。说实话,这样的问法,对一直学商科,一直接触市场类媒体类相关工作的我来说,说一次很大的冲击。因为当面对一件事情,我很少会倒回去想事情的本质是什么。

大部分人思考、行动和交流都是从黄金圈法则中的最外层what层开始思考,即这是个什么样的问题。而黄金圈法则的思考方式是从内线到外线的,即用why-how-what的方式近似思考。

思考why,从为什么开始。当面对一个问题的时候,发掘解决这个问题做这件事的深层原因,比如为什么要开发批量导入bom的报表,达到的目的是什么。

思考how,问了为什么后,明白解决问题的本质原因,才思考中间的圈层who,也就是怎么做。这里主要是梳理如何实现why,用什么样的方法落实解决问题的理念以及需要通过这个问题传输怎么样的价值观,坚定了一件必须做的事情,接下来就是为了做好这件事而去思考解决方法。

思考what,如果前面的两个圈层思考的很清晰了,那么what圈层也是水到渠成。知道了怎么去做,那么就按照既定的计划去做。

想清问题背后的逻辑,而不仅仅停留在表象。人与人之间最大的区别是思维方式,竞争壁垒是认知。

b、千人千面的沟通能力;

拥有强沟通能力的人,就是拥有一个庞大的沟通行为资料库。面对一种情境,特别是在棘手的境况下,他们可以有多种回应方式,并会有意识地从中选择一个对自己最有利,对他人最有效的方式。当一种方式没有取得理想的结果时,他们会迅速做出调整。

拥有多样的行为反应只是基础,拥有强沟通能力关键的是拥有挑选恰当行为的能力,他们知道什么样的情况采取什么样的行为最合适最有效。有三个方面的判断方式:

一看沟通情境。时间和地点等外界的影响,常常会改变沟通的结果。

二看沟通目的。主题讨论、会议、日常交流等,不同目的的沟通存在着不同的方式。

三看沟通人双方的认知。每个人都有自己的背景,你面对的每个人,都带着他的过去来和你相遇,个人经验、原生家庭、教育程度、经济实力、身份地位等所有的因素都会影响沟通过程。

c、 目标导向,而不是过程导向;

在想清问题背后的逻辑,而不仅仅停留在表象中提到,人与人最大的差别是思维方式。具有批判性、独立思考的能力非常重要,这会让你在这个复杂的社会里保持坚定,有自己的判断,也有助于解决问题。

在sap系统上线运行阶段,时常能接受到来自各部门的sap系统最终用户的“投诉”,找项目组关键用户诉说自己在利用系统操作后,要完全改变原有的操作的逻辑和习惯,导致工作时间剧增,任务完成情况远不及以前。面对这样的问题,首先需要用同理心去理解对方内心的焦虑和烦躁,帮助他一起拆分流程进行分析,到底是在整个工作过程中,哪一方面导致了工作效率的下降,在统计各个流程阶段耗时和效率后,再进行整体评估,提出优化方案。

面对一个问题,我始终相信的是办法总比困难多。而大部分重复性、拥有可替换性的工作行为,都是可以寻找软件的简便操作方式或者利用计算机来代替解决的。

美团创始人王兴曾说,多数人为了逃避真正的思考愿意做任何事情。面对问题,最忌讳逃避,我们更应该以目标为导向,去寻找解决问题的更多更有效的办法。

d、养成良好的工作习惯,用双赢思维去完成跨模块跨部门的工作

在项目工作的过程中,共享和双赢的思维始终充斥在项目推进的过程中,其中良好的工作习惯让我受益良多。

一是所有重要的确认点及未确认点,都要落实到书面。在项目组,我们采用项目临时文件夹和正式文件夹的协作模式,临时文件夹以模块为单位,所有人都可以查看、上传和修改,用于在相互交流中、正在进行中及未确认事项/会议/问题的记录;正式文件夹只有项目顾问和项目组有上传和修改的权限,正式确认的问题清单、会议纪要、演示ppt等重要文件均在此处显示。在正式文件夹的文件呈现形式中,我们采用版本更替的做法,老版本不删除,更改后的新版本用v2.0/v3.0的方式标出,并明确修改时间,确认以最新版本为准。共享文件夹的协同模式,为整个项目中按项目进度的变化,在各阶段各模块中,出现过的各式纷繁复杂的问题和过程进行了归类和整理,所有重要事项均用电子文本的形式永久保留下来,为项目结束后的总结和工作移交,打下基础。另外,在进行专题会议的过程中,也是要进行会议纪要的总结,明确会议达成共识的事项,未清事项及未清事项负责人及完成时间节点。以便于进行会议信息的共享和确认。

二是在项目协作和执行的过程中,要建立双赢关系。双赢关系实际上就是双方在沟通中建立一个情感账户,双方的关系能否存续长久,取决于情感账户的资金是否充足,而坦诚相待、相互信任、勇于担责就是情感账户的资金。项目组成员来自于公司各个岗位和部门,按各自的岗位内容分成了mm/pp/sd/fico四个模块。在平日日常工作过程中相互间平等相处,相互合作,为项目顺利上线而共同努力。但从另一个方面来说,系统的优化升级涉及公司业务的方方面面,其中牵扯到的上线部门也有好几十个,因此项目组成员作为来自于各部门的业务骨干,同时也是项目关键用户需要将各自业务系统的优化结果传达到各自部门的最终用户手中,并且作为项目意义的传达者,让更多同事接受系统各项操作方法和流程的变更,尤其是跨部门的业务,更是需要业务相关方的理解和认可。系统顺利上线不是关键,关键是业务的流转能否通过系统的优化更新,进行更好的管理和推进。

五、问题归纳

在通过sap项目,不断深入剖析和梳理公司现有的业务逻辑时,由于公司业务复杂程度高,非标准化产品种类多,且业务分布广、事业部各业务单元又相对独立,所以在推进sap系统切换上线的整个筹备期、上线期、上线后的日常运维期时,遇到了很多问题,召开了无数次不同内容和主题的专题会议。尤其在蓝图流程规划阶段,在会议高峰期每周项目组会组织召开超过8次各项讨论会,还不包括各模块内部的碰头会、专题会等等。

召开会议的目的是解决问题,而无休止的争论以及发散性无主题讨论,是会议的大忌。在项目进行的过程中,随着系统的更新优化,就业务前端后端的流转进行了管控,也确实反应了公司长期以来存在的一些问题,厄待解决。

以下只是我通过项目过程中发现的问题,就个人看法表达观点,以供参考。

a、 如何把控供需,减少库存,降低成本

sap系统中的mm模块是采购和库存管理,主要由采购部和仓储部关键用户及mm模块咨询顾问组成。采购管理是企业生产活动的起点。库存管理是控制企业物流和资金流占用的重要内容,而且是连接采购管理、生产管理和销售管理的桥梁。良好的采购和库存管理能缩短生产周期,提高生产效率,减少库存,降低成本,提高产品质量,同时增强对市场的应变能力。mm模块的内容是供需的起点,也是在业务过程中非常重要的模块之一。

项目组在上线前收集未清数据时,盘点库存将各库位的物料数据导入期初库存。sap系统统一制订了规则,分别就物料的特性和状态,进行了批次号、序列号、项目号的使用,同时统一将十一位旧物料编码升级为十位新物料编码,在替换条码标签的同时,更新条码扫描系统和扫描方式,提高了物料出入库、各种领料投入生产的效率,节省企业的人力成本,更有利于库存的把控。

sap系统打破了信息壁垒,当需要查看库存半成品、在制品、产成品的数量时候,在时时保证货品数量的帐卡物相符,也不需要在库房跑来跑去,减少了因为库存不准而导致的无法发货,或因为库存不足,销售人员无法得知库房还有货,进而导致无法销售。当然在实际操作中,特别是在后期系统上线运维的过程中,因为人为操作或者系统在某些细节方面不够优化的原因,确实存在大大小小的问题,这些问题在后期的系统运维过程中,项目组也进行了及时响应和处理。项目组还根据业务需要,定制开发了各类查询报表和自建表,同时也可以在sap系统中直接就excel的形式进行导出筛选和排序,更进一步把控采购和库存管理。

b、如何规范操作,精简流程,提高效率

贯穿在整个sap项目过程中很重要的一项工作就是最终用户的培训和宣贯。在蓝图规划阶段结束后,项目组就安排模块顾问进行各模块关键用户的系统操作培训。所有的业务流程按照计划每天进行集中演示和现场系统操作,在关键用户熟识了系统操作后,安排单元测试,并且开始准备书写各模块的系统操作手册。随着操作的逐渐熟练,最终用户的接受程度越来越高,项目组在完善系统操作手册后,对各业务的最终用户进行培训2-3轮,并进行了考试(理论+上机实操考试),并对没有合格的最终用户安排补考。在接下来的三轮集成测试阶段,除去项目组关键用户的参与,至后两轮集成测试阶段,最终用户直接上机模拟操作业务真实场景。

整个系统培训的过程按照时间节点按序进行。项目上线前夕,还组织了部分最终用户进行了专题巩固培训,比如系统设计、售后备件、运维等部门。各模块关键用户和it内部顾问,作为公司的sap系统培训师,一直致力于业务的规范化操作,利用系统的功能性进行实际业务操作的把控,同时给各业务部门领导也开放权限直接在系统后台进行状态查看,用透明化的方式进行了流程的管控。当所有业务流程转到财务段,进行月结和报表查看时,拥有更高的真实有效性,确保了财务数据报表的准确和有效。

业务在实际操作方面随着实际情况的多发性,也随时会发生改变。如有任务操作人员因为系统操作不熟练或者不仔细,或是因为系统偶发性的情况导致业务操作出现问题,以引起客户的投诉或者产品的质量性问题,这是必须要杜绝发生的情况,也是系统上线切换最不可以出现的情况。因此操作员在实际操作业务时,应该把更多的注意力放在账卡物系统一致的情况,尽量避免出现任何人为系统操作的问题。

利用系统精简流程,提高工作效率,把更多的人力、物力放到公司的关键生产力上面。

c、如何通过系统更好的进行人员管理

sap公司以卖账号为公司的收入来源之一,而账号的价格大概在两万元。因此一个上sap系统的大型公司并不可能做到人手一个账号,势必要多人共用账号。项目组在分配账号权限的时候,从两个维度对不同业务部门的最终用户进行了分类,分别是功能权限控制和组织权限控制。功能权限指的是该账号在sap系统内的操作是查看、修改或是创建,组织权限指的是该账号在该业务范围下需要操作的是哪些业务。从这两个维度把实际需要操作sap系统的业务最终用户分了组,对应到的控制权限的60多个账号中去。因为存在多人共用一个账号的前提,所以在业务实际操作过程中,会要求业务员在其他地方填写工号和姓名,在部分t-code下进行人员的下拉菜单选择。而各模块最终用户,同时也是资深业务骨干会及时对最终用户的实际操作进行管理和把控。另外,如需要增加权限或者因为业务方式的更改进行权限配置,可以通过oa流程发起权限申请,后台也可以实时查看各业务发生和进行情况。

sap系统打破实体制造行业乃至多行业的信息化管理壁垒,通过规范业务流程和操作规范,让数据的流通更透明,使人员工作更高效。但信息化技术的实现,只能解决部分明面上的问题,就实际业务而言,有太多的外在因素以及人为干预因素,因此如何更好的降低员工离职率,因人设岗,因岗定责,有太多需要持续思考和优化的方面。上sap系统只是手段,而不是结果。

d、如何在系统顺利运行的基础上,持续成长,创造积极变化

从表面上看,市场中有竞争力的企业都是拥有好的产品及服务的企业。而那些好的产品与服务都是由企业的技术、生产、销售人员精心开发、生产并销售出去的,而这样一个连续的过程,又是建立在企业各个管理环节的有序运作基础之上的,最终都归结到企业员工团队的精雕细刻。任何一个环节的疏漏,都有可能会使企业的运营链条断裂,从而导致企业经营的失败。

而从长远的角度来看,企业可持续化成长的前提是培养自身核心竞争力。随着全球化的进程,技术革新日新月异,在这种经济和社会发展趋势下,企业若想持续成长发展,只有自我革新,除了不断改革自己之外,别无他法。除了公司的主流产品以外,更多的人力物力和财力用在新产品研发,在适应市场发展走向,预测未来十年的市场走向后,勇于尝试,大胆革新,永远都能够拥有一颗敏锐的判断力,创造出适应未来市场需要的新产品。

我们平时推进工作时,一般是采取所谓自下而上、层层叠加的方式。例如,在开发新产品时,会尽可能收集已有的数据和文献,汇总手头的技术要素,从中探求可能性;在推行一项新系统、新流程时,我们会尽可能多的做业务实际调研,研究旧模式的不足之处。在日常工作中,我们习惯于这种自下而上、层层叠加的方式。但是,采取这种工作方式,就很难产生超越常识的东西,孕育不出飞跃性的崭新的构想。

从项目筹备至上线的八个多月的时间里,我见证了项目组是如何齐心协力完善和修改了原有的流程和审批节点,在不断召开各项专题讨论会,邀请各流程相关责任人到项目组现场参与讨论。就尽量满足实际业务需要的同时,更要进行未雨绸缪的判断,修改完善的系统流程,是否能够满足未来五年、十年公司业务的不断发展壮大,是否能够将人员效率发挥到最高,把更多的时间精力从繁琐的日常流程中解放出来,投入到更重要的业务方面。这种不同于平日推进工作的“自下而上,层层叠加”的方法,需要决策人有更高的预测和判断能力,同时考验了一个新项目能持久运行,能否为实际业务需求发挥出最大效益。

自上而下,这种思维方式非常少见,这是现状。这里的自上而下不是指老板,或者一级部门负责人从上而下发出指示,而是从项目伊始,首先有概念,建立concept,由此开展工作,这样一种所谓自上而下的方式。稻盛和夫曾在经营哲学中提到过,这种思维方式在企业中非常少见,但如今也越来越多的管理者明白了这种思维方法所能够带来的深远影响了。

在系统顺利运行的基础上,我们更应该居安思危,在保持可持续性发展的同时,大胆革新,在预测市场未来发展变化的同时,不断改革自己,精益求精。在管理模式上,应该广开言路、集思广益,运用自上而下的思维方式,更全面思考和看待问题。

六、个人感悟

在项目组工作的这200多天的时间里,也确实有很多的个人感悟和体会,归纳了四条以供参考。

首先是,做成一个项目很难,团队协作是关键;

团队精神和团队合作在任何时候、任何方面都是一个项目成败的关键因素之一。在项目初期,因为各自的工作风格的差异,产生摩擦是不可避免的,但后期随着项目进入正轨,适应了工作节奏以后,团队合作也越来越顺利。一个伟大的团队最重要的作用是让其平凡的成员创造出不平凡的业绩,团队精神和团队合作是决定一个项目能否成功的关键性因素。

二是需要具备统筹协调能力,业务能力,刚柔并兼的沟通和说服能力;

在团队中从事任何一项工作或者担任任何一项职责时,都要用到上述相关能力。首先是统筹协调能力,运用“自上而下”的思维方式,用更全面的角度思考和看待问题。角度对了,处事方法就对了;业务能力毋容置疑,没有业务基础,面对问题的出现,何谈优化解决方案;沟通和说服能力是团队合作的基础,团队合作虽然目标是做事,但做事的主体都是人,而刚柔并举的方式会更加事半功倍。

三是改革是需要付出代价的,但更重要的是运用改革产生更积极的价值;

这里的改革指的是改变原有的模式和规则。任何打破原有计划的变化都会产生积极或者消极的影响,如何使得改变产生更积极的价值,是每一次在推进项目时,都必须要提前认真思考的问题。包括产生价值的意义、产生价值的方法,以及如何实现积极的价值。

四是要用创新性思维去工作和学习,通过项目管理实现自我成长。

学历代表过去,能力代表现在,学习力代表未来。无论从事何种工作,学习能力的重要性都排在第一位,把事情做完不是最重要的,重要的是超出预期。我们的人生使命是创造积极的变化,在每一次参与过程中,运用自上而下的思维方式,或是选择适合自己的方法,比如pdca循环法、黄金圈法则、金字塔原理等,不断的通过“发现—解决—总结”的方式,在工作中进行自我成长和自我实现,是我们一直追求的目标。

以上各项内容是我在参与学习sap项目以来的个人经历和收获做一个总结,仅作为个人学习心得,写的不足之处还望多多包涵,以供后期助理等相关工作人员参考。另外,感谢公司给予我的参与sap项目的学习机会,感谢项目经理陆总、九慧项目经理闫总,感谢项目组各位同事和顾问老师。我希望能够将学习心得总结提炼,更好的投入今后的工作和安排中去。

多项目管理心得篇4

项目管理的优势是工作目标集中、组织架构灵活高效,劣势是因为项目临时性的特点,成员缺少归属感和安全感,一个项目组织内包括了各个技术领域的人员,成员的职业发展不容易做得好。近些年逐渐流行起来的矩阵式项目管理,似乎最有希望克服单纯的项目管理或单纯的部门管理的缺点,让项目管理扬长避短,再跨上一个新台阶。在技术风险较高的it项目管理中,更是成了一个时髦的名词。那么矩阵式管理到底是怎么做的呢?请看下面这张示意表:

我们把部门竖着排成三列,横着切出三个项目,也就是三行,这样的组织结构就像有行有列的矩阵,这就是矩阵管理的最基本含义。这样的组织中,每个成员都有两个领导—项目经理(组长)和部门经理(组长)。根据项目经理和部门经理发挥的管理职能的比例不同,一般又可划分为弱矩阵、平衡矩阵和强矩阵管理,按照项目经理在项目中作用由小到大排列如下:

弱矩阵管理的项目经理一般是由职能部门指派,归部门经理领导,对项目的控制作用很有限,主要依靠部门经理控制项目,项目成员和项目经理都由部门经理进行考核,这种模式适合项目规模较小,基本不跨部门或者某一部门在项目中站绝对主导的情况。平衡矩阵的项目经理是独立于职能部门的,一般是由各部门经理的上一级领导指派,项目经理和部门经理都对项目有一定的控制权,项目经理的主要负责项目的进度、质量、成本,部门经理则负责组织技术攻关、技术培训和成员技术能力提升,项目经理和部门经理共同负责对成员的考核,这种模式适合项目规模较大、技术复杂度较高的情况,很适合it项目的特点。强矩阵类型自然就是以项目经理为主了,部门经理辅助项目经理,这种模式适合项目规模较大、但技术相对简单的情况。

矩阵式管理虽然有诸多好处,但是操作复杂是它最大缺点。矩阵式管理模式下每个成员都有两个领导,这是有悖于传统管理的“常理”的,需要充分宣传引导,谨慎协调。平衡矩阵操作难度最高,就像推独轮车,要不断的关注员工对项目的忠诚度和对部门的忠诚度的变化,要不断的调整,以保持平衡。弱矩阵和强矩阵操作难度也不低,一不小心就会滑到纯项目管理或纯部门管理模式,所谓的矩阵会名存实亡,画蛇添足。

矩阵式管理的另一个缺点就是沟通量大,需要有较强的“沟通管理”能力,否则就会掉入会议的漩涡中。

如果能比较好的处理矩阵式管理的平衡和沟通问题,矩阵式项目管理是非常好的管理模式,对it项目管理必定会有很大好处。

多项目管理心得篇5

前段时间,我负责了一个项目的管理与开发。在时间短、任务紧,而团队人员又大部分是没有经验的菜鸟的恶劣情况下,我带领接近40人的团队,终于在客户规定的时间范围内如期交付产品。这其中,经历了需求变更、人员变动(因为其它任务,先后有近10人离开团队)等诸多问题,项目仍然取得了成功,不能不说有几分侥幸,但此外也有一些经验与教训可以与大家分享。

项目开发方面

项目应以需求为核心。一个项目是否能够成功,对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功,如果需求出现偏差,仍然是南辕北辙。由于eas项目的特殊性,项目开发过程中能够与客户建立有效快速的沟通渠道,是项目成功的关键。

需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书,以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点(用例)。eas项目在前期对需求不够重视,导致在需求理解上出现了一些偏差,从而影响了项目的进度。幸而得到了及时的纠正,在项目管理部的协助下,所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时,有了充分的保证。

项目应确立专门的需求分析师。公司没有专门的需求分析师,不能不说是人员配备上的一大弊端。(软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师)从eas项目的开发过程中,我们就充分地认识到这一问题的严重性。需求的不断更改,客户迟迟未签字确认,原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时,总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术,没有经过专门训练的需求分析师,通常会给项目带来隐患。

项目应指定各个模块的需求接口人。只有这样,才能有效地保证项目组与客户的及时沟通,快速响应客户的请求与反馈。eas项目在开发早期及时地确立了需求接口人,在一定程度上规避了需求变更给项目带来的风险。但是,确立的需求接口人未经过系统培训,在需求调研以及与客户沟通的过程中,工作表现只能说是差强人意。

注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业,而项目经理以及需求分析负责人对这一过程还欠缺足够的重视,同时没有好的工具或流程来监控这一过程,使得需求调研记录没有发挥更大的作用。此外,需求跟踪也非常重要,毕竟,任何项目的需求都不是固定不变的,需求随时会发生变更,而开发人员实现的需求也可能会与客户的要求偏差。

注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解,项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期,项目及时撰写了eas项目需求功能列表,并结合交付版本与客户进行了沟通和协商,从而规避了需求偏差的风险。(需求追踪,任何原始需求来有头就有尾。原始需求—>用户需求—>产品需求—>软件需求—>设计—>测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏,更多的是为了做变更影响分析使用)

控制需求变更。重视ccb的作用,同时应建立需求变更的响应机制。eas项目组对于需求变更的响应还不够及时,这一点项目经理与项目管理小组要担负一定的责任。(范围管理中范围控制的内容,变更管理是配置管理的一个重要内容。需求必须要受到控制,否则容易引起计划的频繁调整而发生混乱)

多项目管理心得篇6

记得在读大学时,作为班干部曾经参与班上的元旦晚会的策划,自己曾经以为策划就是这个样子,无非就是一个流程一个思路。记得读书时老师说过只有一个得人心的策划才是考策划,一个好的策划就是帮助别人同时分享自己的快乐。在大学的时候如果一个任务难度很大自己估计就会放弃或者随便抄一篇应付了事,但是自己的角色早已经变了,早就不是象牙塔的学生了,变成了一个生产者而不是曾经的消费者,现在的情况不允许自己逃避,为了自己,为了安江9c必须要走下去。

在项目第一次全体职工代表大会上xx说:你可以不懂,但是你不能因不懂就不努力,你可以查资料可以向别人请教。很多时候不逼自己能永远也不会知道自己有多大潜能。那些日子向我的老师,我的师兄以及我的领导同事请教,终于明白了一个项目安全专项策划的一些流程,再也不是当初两眼一抹黑了,有了大体的框架 就有了方向,接下来开始写具体的策划了。当安全专项策划上交的那一刻起自己看着几万字的策划居然在自己一个字一个字的敲击中完成,看着自己居然把大学时候资料大部分看了一遍,心中真的感到非常的自豪和不可思议,不曾想到曾是那么患得患失和浮躁的自己能够以四公司的一员,以安江9c的一员认真的思考安江9c项目的安全管理,认真去体会刘宏伟总经理在安江项目管理部署动员会说的质量安全第一原则的指示精神,去思考项目安全管理的思路。

记得我的一个同事不止一次当着我的面说“所谓的安全全是骗人”,那时候我真的非常难受,倒不至于是生气。作为一个在接受了三年正规大学教育然后在路桥施工这一高危领域进行工作的大学生都有这样观点,可以想像到文化程度远低于他的那些农民兄弟对安全是怎么一个样的认识。我们安全第一,预防为主喊了几十年,什么东西都是空中楼阁,安全还是没有落到实处。这就是缺少执行力,缺少脚踏实地。事情总是往好的方面发展,随着国民素质的提高和融于世界经济的需要,安全生产越来越受到重视,作为中国建筑行业最具代表性的企业的子公司xxx在些年全面推行安全总监制度,安全拥有一票否决权,但是我觉得还不够,必须推行安全准入制度。任何一个分部工程或者单项工程,在进行正式的施工作业前安全防护设施必须完好,从业人员受到良好的安全教育,临时用电符合要求,特种设备性能良好,在施工通知书上面有安全负责人签字确认后方可进行施工,实现全面的安全准入制度项目的安全方能得到有效的提高,从而有效的避免重特大事故的发生。

提升安全管理人员的专业水平和项目领导的安全素养是构建安全安全生产的一个非常重要的方面。和我的师兄以及其他安全管理人员交流,很多人员连安全管理应做什么都不知道,一做资料就是从网上东拼西凑,根本不认真阅读安全生产的法律法规或者强制性标准,应付了事。公司应推行对安全管理人员的资格考试,主要考察安全技术,安全管理水平以及其安全意思,连自己的`安全都搞不好还怎么检查别人的安全。领导的安全素养同样非常重要,对于项目经理负责制来说,项目经理就是最大的安全员,一个项目经理对安全的重视程度直接决定项目的安全管理水平。

提升其他管理人员的安全思想和知识构成是项目安全不可缺少的一个方面。很多时候人们一谈安全,就是安全环保部或者安全员的事情,实际是安全很多方面的落实主要靠现场的管理人员,安全员最基本的职能就是监督与检查。项目安全管理必须坚持“谁主管,谁负责“,”“生产,必须管安全”的原则,严格坚持“五同时”这样项目安全管理才有一个一个大的提升空间。

多项目管理心得篇7

20xx年8月10日——11日我参加了公司举办的项目管理培训课程,授课老师通过讲解项目的特点:特定的时间、预设的资源、明确的交付物和零时性组织,让我认识到项目管理是一门技术工具科学,能够帮助我们尽快的理清思路,开展工作,运用基本工具,关注项目管理的基本要素和关键环节。

在课堂上老师通过让我们使用沙盘模拟进行实战演练,让我深刻认识到项目管理是整个项目的基础,学习项目管理可以提高工作效率提升员工的工作能力。项目管理中要减少因传递导致的沟通误差,避免影响项目进度。项目管理的目标设计非常重要,我们要从项目目标所要求的时间、成本、质量三方面出发,对项目目标进行分析。运用好项目管理有九大知识领域和五大过程做出一个横向“时间预算”和纵向贯穿“wbs工作分解”的项目示意图,让所有的项目成员都能明白我们在完成项目的过程中每一个人做什么,应该怎样做。通过学习项目管理,我深信项目管理是企业的行为过程,是企业发展的载体。经过本次培训,我认为我今后在工作中要注意以下几方面。

首先,我的体会是我们在做任何项目的时候,一定要有一个完善的计划和工作思路。在日常工作中,往往没有一个具体的计划和方法。一件很容易做的事情,最后反而搞得很复杂,影响了做事的效率。因此,今后无论做任何事情是,一定要给自己设定一个完整的计划,才能高效率、高质量的做好每件事。

其次,高效利用时间,节约成本。在日常工作中作为管理者,事情多,工作琐碎。这样就需要我做到每天工作结束后回顾一天的工作,并对第二天的工作进行安排。在安排工作上要遵循一个主次分明,轻重缓急合理的原则。这样每天当我一到工作岗位上就能很快的进入工作状态。这样就很好的把握和做到——"工作时效"。课堂上,老师给我们讲解了在项目实施的过程中,项目成本是重中之重。一是公司总体要进行成本核算,二是项目经理要对本项目的支出进行控制,三是成本的高低也是衡量一位项目经理重要指标。日常工作的成本主要是人力,合理的安排人员,提高人员的利用率是节约成本的关键。人员安排妥当,我们的成本自然就减少。

再次,要做好一个项目,必须要懂得团队协作与沟通。特别是我们基础管理人员,在现代社会里,单枪匹马一个人单打独斗的时代早已经过去了。一个项目的实施没有一群人的参与是不能做好的。如何更好的进行团队协作呢?团队中成员之间的分工务必要十分的。明确和精细,成员之间经常要有互动和交流,使每个成员要有强烈的责任。在我所作日常工作过程中,与职工之间的沟通是必不可少的,只有向职工充分的去宣传企业的展形势、工作任务目标、企业规章制度才能更好的让员工为企业持续发展积极工作,所以说拥有一定的沟通能力是必须的。其实工作的运转,在内部与各组的沟通也是十分关键必要的。我作为一名管理者,更加深知沟通的重要性,沟通无时不在。不同的职工有着不同的思想问题,从职工的工作、生活、个人行为到家庭矛盾等,并不是每一职工都能按照你的思路走,沟通是解决这些问题的基础,是建立和改善人际关系必不可少的条件。在沟通过程中,我们要善用询问的语气不要让听者感觉是在命令,学会倾听;学会自信与诚恳,只有这样才能使我们更好地完成工作。

最后,不管做任何项目,任何工作,在实施的过程中,都会遇到意想不到的意外事情发生,因此需要对进程度进行修正,即过程的调整。这是任何项目的完成不可缺少的一个重要组成部分。我觉得:我们在计划某一个项目时,都将实施过程中可能遇到的问题考虑的非常周到和全面,以一种十分严谨谨慎的态度去做,这样才能取得更好效果。

总之感谢公司领导给了我这次学习的机会,使我得到提升,看到了自己差距和不足,明确了自己的目标好方向。在接下来的生活、工作和学习中能更好的运用领会培训所得。