项目经理的生存之道.docx
- 文档编号:26563023
- 上传时间:2023-06-20
- 格式:DOCX
- 页数:23
- 大小:34.08KB
项目经理的生存之道.docx
《项目经理的生存之道.docx》由会员分享,可在线阅读,更多相关《项目经理的生存之道.docx(23页珍藏版)》请在冰豆网上搜索。
项目经理的生存之道
项目经理的生存之道
(一)-Howtosurviveasaprojectmanager
到2009年为止,本人作为项目经理已经接近9年,成功完成大大小小的IT项目超过20多个。
在HP也做了几年的项目管理培训(对内和对外)和PMP认证培训的工作,2008年还获得了“StarOfYearofProjectLeadership”(1/3800):
项目管理年度之星。
在对项目管理有诸多体会的同时,却发现自己身边有的项目经理同行们日子过得不是特别好,有菜鸟项目经理,资深的项目经理,成功的项目经理,却因为某些项目没有控制好,从而极大地影响了自己的职业发展。
项目结果不好,最好的情况是换一个项目,以图挽回之前失败的影响;其次的是没法再原来部门呆下去,考虑换部门;而最多的情况呢,自然是没法在组织呆下去,要不体面地走人,要不被扫地出门。
什么是项目结果不好?
我们先来看看项目经理这个角色,项目经理为项目的成败负责,其职责是建立并领导项目团队,全程控制项目流程(项目启动,项目计划,项目执行和项目结束),平衡项目进度,成本和范围的关系,并最终达到项目的目标。
在HP的几年里,身边就有不少的项目经理因为种种的原因离开(印象深的至少有10个),其中不少还没有等到项目结束就被换掉了,也就是说压根就没有看到项目的目标是否完成。
换句话讲,达成项目的目标并不是项目经理的第一目标,项目经理的第一目标应该是如何活下来,至少要熬到看到目标的那一天。
残酷的事实是,项目经理阵亡的比率太高了。
在过去的3个月里,我身边就有2例,并且这两位还是非常有经验的项目经理。
随着现在经济形势的发展,项目经理承担的项目越来越受到管理层的关注并被当成救命稻草,成功是必须的,失败是绝对不行的,稍有风吹草动,项目经理作为替罪羊的概率大大增加。
回想自己过去几年的项目管理经历,过程中不乏危机时刻,如果当时我没有处理好,会发生什么事情呢?
我想结局好不到哪里去,至少那个年度之星就别想了。
^_^
曾经有人问我一个很白的问题:
考了PMP证书,是不是就能够把项目管好?
很遗憾的是,上面提到阵亡的项目经理大多拥有PMP证书。
既然有PMP证书,自然是熟知项目管理的9大知识领域:
项目综合管理,项目范围管理,项目时间管理,项目成本管理,项目质量管理,项目人力资源管理,项目沟通管理,项目风险管理,项目采购管理;
并且我们还可以获得很多诸如项目模板(template),检查清单(checklist),历史项目资料等等对我们项目管理有用的数据和工具;
我们带领的团队基本都是比较熟悉的人员,自己对项目的领域也相当的熟悉。
既然这样,有理论知识,有工具,还有自己熟悉的团队,为什么项目经理还常常面临危机并可能被扫出项目呢?
作为一个项目经理,是不是有它的生存之道呢?
有句话说的好:
一年里你对女人的一千个好,比不上重要的一天(比如她生日)里的一个不好。
作为项目经理,允许犯错,但是在关键的问题和事情上绝对不能犯错。
这个“项目经理的生存之道”系列就是期望列出项目经理的一些雷区,总结在项目管理中的一些关键问题和关键挑战。
当然,对于每一种状况的应对方法都没有标准答案,期望的是带给大家更多的思考。
项目经理的生存之道
(二)-识别和管理关键项目干系人
(1)
[主要症状]这类项目经理认为,只要能够带领兄弟们埋头苦干,届时这样按时完成项目,质量还可以,成本不超就是项目大大的成功了。
何为项目干系人(ProjectStakeholder)是指积极参与项目的个人或者组织,并且会对项目的结果产生影响或者被项目的结果所影响;干系人可以是组织内、或者组织外的人。
项目干系人包括客户、监管机构、经理、分析师、开发者、测试者、文档编写人员、法律人员、销售、支持人员、制造人员等项目相关人员。
作为项目经理,如何整理和汇总项目干系人?
应当编写项目的通信录:
姓名,角色,主要职责,联系信息等等
如何管理项目干系人的沟通?
通过项目沟通管理计划来做到,考虑When(什么时候)、What(什么信息)、Who(什么人)、How(通过什么方式发布或者获得信息)
上面的大家都会,干系人很多,找出关键项目干系人更重要。
怎么样识别出关键项目干系人?
很多人相信自己的脑子,结果却是常常会忘掉或者漏掉一些,这里介绍一种结构化的方法:
建立一个评分等级和加权,从权利、需要、兴趣、知识等方面对主要干系人分析和评分,得分据前列的为关键干系人。
权力:
对项目的影响力
需要:
项目满足个人和位置(position)的需要程度,体现为对项目的关注。
兴趣:
对项目的参与度
知识:
对项目涉及专业知识的了解度
接下来的步骤是列出这些关键干系人的期望,他们会直接告诉你明明白白吗?
一般不会的。
尽力分析出来,特别是哪些互相冲突或矛盾的期望。
比如对于Time&Material的合同,客户期望能够成本尽量降低,而你的经理却希望钱收得越多越好。
项目经理的重要职责就是平衡这些关键关系人的期望,并在整个项目过程中跟踪这些期望。
注意:
期望是会变化的!
特别是组织内或组织外项目相关的人事或组织架构发生变化时,这时如果不及时调整,问题就大了!
除了管理干系人的期望外,还需要管理干系人,对于不同类型的关键干系人需要采取不同的策略。
第一类:
权力->高
兴趣/需要->高
知识->低
在你眼里,他/她可能是客户的项目经理或者领导,也可能是你的领导,他们具备影响项目的绝对权力,参与度很高,问题是他们对于项目涉及的专业知识掌握度很低。
你觉得人家水平低,人家自我感觉非常良好。
水平低就算了,还特喜欢发号施令,乱指挥,你说他不对他绝对跟你急。
“叉腰肌”的谢亚龙不就是这么一位么?
有这样的干系人,看看项目经理们(国足教练们)最后都干成咋样了?
<案例一>
对方是客户的领导(项目经理的领导),为了搞好关系,项目经理顺着这类干系人的思路进行项目,结果导致对方自我感觉膨胀,经常左右项目的走向和决策,项目经理的好意完全没有得到尊重,被斥为“专业知识不过关”,一气之下,顶了句嘴“啥都不懂吓指挥”,客户暴怒,连公司业务也受影响,项目经理也只好黯然离去。
<案例分析>
作为项目经理,控制自己的情绪很关键,生气的时候或者接近发飙的时候,先深吸一口气,给自己3秒钟时间问自己:
我真的要这样做吗?
即使不进行反击,项目就能顺利进行了嘛?
明显项目经理在处理这类干系人的策略不对。
<解决方案>
针对这类干系人,有以下的建议:
1.树立真正的专家形象,选择和包装自己团队的专家,并且能够震住对方,最好有什么名号。
让对方了解到成为专家的困难度,自然可能会考虑知难而退。
可行度:
五星
2.这类型的干系人更倾向于先进、最新技术、主流产品、国际标准等,在技术路线或者技术包装上需要考虑到这样的喜好倾向。
场景:
您的意见非常好,我们采用的是业界先进的方案,具备科学的设计和架构,...,我们可以考虑先用目前的方案,你的建议可以考虑在将来三期的时候规划。
真的是“业界先进”吗?
只要你能说服对方就行了。
可行度:
四星
3.在对方组织中寻找专家,并争取干系人可以授权给这位专家。
通过这样的方式,其需要仍然很好,但是兴趣会大幅降低,从而大大减少对项目的干预度
可行度:
五星,很多人从这方面想过,如果从一开始就考虑到这点,可操作性是很高的。
4.既然对方对项目涉及的专业知识缺乏了解,那么不妨挖一个小坑,并且结果在控制范围内,然后让其掉下去,你再来完美得收尾,送对方一个人情。
对付不见棺材不掉泪的主特适合,但是小心操作,不然搬起石头砸了自己的脚。
可行度:
两星
5.了解对方真正的需要是什么,尽力作为顾问的方式为其提供多种建设性方案来满足其需要,并用实际成果说服对方信任自己。
如果国足有很好的成绩,谢亚龙还会那么瞎折腾么?
可行度:
三星
说到底,我们希望最后达到的效果是:
权力->高(高)
需要->高(让对方意识并且相信减少参与,自己的个人和位置的需要也能得到满足)
兴趣->低(降低其参与度)
知识->低(让他/她意识到这个事实)
<后续思考>
其它类型的关键干系人如何合理呢?
第二类:
权力->高
需要->高(position的需要高)
兴趣->低
知识->高
这一类属于最容易忽略的关键干系人,也有实例证明一旦处理不当,后果是非常严重的。
大家思考一下如何处理?
第三类关键干系人:
权力->低
需要/兴趣->高
知识->低
下一章我会继续探讨这个问题,重点会关注2个案例:
1.第二类干系人管理
2.项目过程中客户期望发生变化时却沿用老方法处理。
项目经理的生存之道(三)-识别和管理关键项目干系人(续)
上一篇文章谈到下面这一类的重要项目关系人
权力->高
需要->高(position的需要高)
兴趣->低(项目的参与度低)
知识->高
为什么这类关键干系人容易忽略?
这类干系人具有很高的位置(比如项目经理的老板的老板或者技术和业务专家),这个项目的成功会为其带来很好的政绩,平时却不会出现在日常项目过程中,但是很可能突然有一天他/她因为种种原因跳出来给你一个大Surprise!
拿案例说事吧。
<案例>
角色A:
项目经理
角色B:
项目经理的直接汇报经理
角色C:
B的直接汇报经理
Areportto->Breportto->C
一项目经理A在客户现场带项目,项目进行了2个月,客户没啥意见,项目经理的老板B由于特别忙,也没有特别关注这个问题。
但是这个项目属于项目经理的老板B的老板C的重点项目,对C在2009年的业务开拓具有相当重要的意义。
换句话来说,对C来说,只许成功,不能失败。
而A呢,只是关注客户,关注自己的老板B,压根就没把C当成重要的项目干系人。
阶段一:
C看了1个多月的项目周报,项目周报总是汇报天下太平,但是有1天从侧面了解项目,基于自己的知识和经验,觉得项目周报有问题,于是要求B进行整改(注意,这个阶段还没有直接跟项目经理A直接联络)。
项目经理A通过自己老板B得到这样的要求后,当然说好,但是项目事情很多,这个要求又经过了自己老板B的转述,也就没有把优先级放得特别高。
阶段二:
C开始看第二个月的项目周报,发觉居然没有啥改进,立即question自己的下属B,B由于对本项目参与不多,好多事情也回答不出来,那么C的判断就是:
A没有执行力;没人在控制这个项目。
阶段三:
第三个月,C十分不满,决定自己跳进去看这个案子,C这个时候进来看这个案子,基于之前的两个月的经历,对项目经理A已经是带着有色眼镜来看问题了。
而我们可爱的项目经理呢,他并不了解过去1个月在B和C之间发生的所有事情,也并没有了解到事情的严重性!
C由于具备很强的知识,自然很轻易地找出来项目的一堆问题和潜在问题,谁是责任人呢?
这个时候自然会归咎于项目经理A,为什么?
因为在C的眼里,很多事情在2个月前就已经交待了,却没有得到跟进和改善!
作为项目经理,我们自问:
我们的项目是否都是很完美的?
不会的,总会找出一堆问题来的,关键是找问题的人怎么看这些问题。
项目经理A怎么看C的突然加入呢?
级别高两级给他巨大的压力,C提出的事情做不做?
A的回答都是“好”。
阶段四:
问题升级和爆发了,项目经理A对C的要求都是回答“好”,但是这是积累了好长时间的issues,哪有那么容易就搞定啊,关键的是,项目经理A没有证据来支持自己为什么无法按时完成。
C很紧张这个项目,现在发现项目经理A总是响应缓慢,由于又是在客户现场带项目,并不习惯经常跟C汇报。
对C来说,判断就是:
虽然自己介入,却由于项目经理A执行力差而无法改善,项目危险!
阶段五:
问题定位到人就很简单了,解决方案只有一个:
换项目经理。
最后结果:
项目经理A被开了“绩效警告信”,为了避免被直接开除,只好1个月后黯然离职走人。
就这样,刚刚3个月,项目经理A就阵亡了,至于客户是否答应这次换人,换人后新项目经理干得怎么样,就不是这个案例的内容了。
<案例分析>?
?
这个案例中的关键干系人是来自自己的组织的,常常更难处理的来自客户的这类人员,比如一个IT开发项目进行到中途,客户的技术架构部门跳出来,说这个项目的架构不符合他们的技术要求;或者客户的高级主管突然跳进来对项目进行粗暴干涉。
?
?
这类状况的常见现象就是你突然发现你认知的”关键干系人“突然不顶事了,他们也顶不住更高干系人的压力。
?
?
项目经理A为什么会阵亡?
在他个人的认知中,客户没有问题,自己老板B没有问题,团队也没人拆台,为啥还会被钉着打?
最后还死得不明不白呢?
有三点:
没有识别出C这个重要干系人;没有避免C直接介入;C介入后也应该顶住。
?
?
头疼啊,权力高的干系人,平时可是不容易见到的,处理好了,自然是为项目经理个人大大加分;处理不好,权力高,自然也具备直接枪毙项目经理的权力,结果如何全看人家心情了。
?
?
说点自个的事情,进HP不久后带一个重要的项目,大Boss(老板的老板)在启动阶段连续跟进了1个月,然后放心地不管了,这段时间给了其非常正面的印象,相信对日后我的升职肯定有着不小的正面影响(在外企,跨级沟通的机会并不多的)。
<解决方案>
?
?
如果有效管理这类干系人?
?
1.及时告知-改进沟通机制
?
?
?
这类干系人基于自己的需要,因此期望项目是受控的,是稳定的,因此所有项目的关键信息,关键决定,项目状态必须要知会(cc)到他们,也就是说他们必须在cclist里面。
保证的机制是在沟通计划中专门加上这一项。
如果这类干系人质疑你的项目状况,你完全可以拿出曾经发送给他/她的所有历史记录,告诉其来龙去脉。
这类关键干系人的唯一缺点就是三高一低,这低的一点就是其项目的参与度很低,根本不会去查看所有的项目信息,但是这些项目信息会暗示他/她:
项目是在受控的持续进行的,自己是"可以"掌控这个项目的。
?
?
注意:
项目报告要有持续性和一致性,不要突然出现surprise。
?
2.利用这类干系人成为项目解决关键问题的重要力量:
?
不要以为高高在上的领导们高不可攀,既然被你定义为重要干系人,就好好地把他们给用起来。
你想象一下,有一个高层的老板一直在mailloop里面,会不会给一些人压力?
有压力就好办事啊,你大可以狐假虎威吧。
再换一个角度,这是不是一个很好的escalation的机会?
当然是了,持续在项目周报里面把重要issue标注成红色,如果不能解决,字体放大2倍,你放心,有人会在上面或明或暗帮你的。
?
?
3.提升其参与度
?
最好提升其参与度的方法就是适时地请其帮忙,利用其专业知识进行一些指点。
这类关键干系人适度参与了之后,会大幅增加项目的认同感。
原理很简单,专业知识(技术、业务或项目管理)强的人是非常乐意自己的知识发挥作用并被得到尊重的。
?
?
4.减少不合理的干涉
?
减少干涉的方法很简单:
重要的技术或者业务决策是通过集体决策得到,并且有明确的记录告知给这类干系人知道。
为什么,这样大幅增加其干涉的成本,因为普通人都有从众心理,并且如果想推翻这样的决议需要说服更多的人。
国内很多项目经理常常是业务、技术、项目管理一把手,特别喜欢做决策,如果项目中存在这类关键干系人,一定要特别注意,否则项目意见的不一致会完全上升到个人能力问题。
宁愿让其相信项目团队的能力问题,而不要让其坚信全是项目经理的问题。
?
简单点讲,直白点讲,用集体来保护自己。
事实也是这样呀,项目又不是出了啥天大的事情,干嘛用项目经理开刀?
?
5.寻找支撑点
?
如果真的发生大Boss突然参与到你的项目里面,并且是如案例中一样的质疑态度,应该怎么办?
首先一定要知道为何而来,知道其根源,利用各种原因探听真正的原因,只有这样才能对症下药;其次,一定要搞清楚其质疑的对象,是项目本身,项目经理还是项目中其他关键角色;如果很不幸,针对的就是项目经理,那么应该寻找到支撑点。
?
所谓支撑点,就是要寻求项目组内外的支持:
?
客户:
如果是内部的老板质疑你,客户的支持就很重要,在案例中的状况,如果你能说服客户给你发一封个人或者项目的“ThankLetter(感谢信)”,即使内容不痛不痒的也行,这绝对会促使质疑你的老板重新考虑:
是不是我只看到了问题的一方面而已?
?
你的老板:
在外企里,跟自己的直接汇报经理沟通是最多的,关键的时候一定要他/她支持你,即使不能根本解决问题,好歹也可以争取捞一个死缓啊。
案例里面的项目经理A压根就没有争取其项目经理B的支持,老板都搞不定,做啥项目经理呢?
?
重置成本:
作为项目经理,你应该在项目各方面参与得很深,比如客户关系管理,团队管理,项目流程,业务/技术/质量的一个方面以上,也就是说你是不可缺少的。
即使大Boss想用莫须有的借口让你成为某个事情的替罪羊,但是他/她得考虑重置成本(更换项目经理)啊,和谐至上嘛。
如果你可有可无,哼哼,上班在混日子吧。
?
说了那么多,有人问,遇上这么困苦的状况,我战略撤退,申请换个项目还不行嘛?
不行的,被高层贴上了“无能”的标签就意味着你在这个组织短时间没啥好混的了。
?
?
识别和管理关键项目干系人(完),请关注项目经理的生存之道的后续章节。
项目经理的生存之道(四)-问题升级机制
什么叫问题升级机制?
英文叫做IssueEscalationMechanism,是指当项目组出现问题,而这个问题超出项目经理级别的处理范围,因此将该问题升级到更高级别处理的机制。
听上去很简单,但是这句话有两个需要琢磨的地方:
升级的是什么问题?
升级到什么级别?
先来看问题的类型,通常,导致问题出现的原因有以下几个方面:
?
?
1.质量问题:
已交付的交付物或者系统功能存在质量问题
?
?
2.需求范围(Scope)问题:
经用户确认的业务需求,后来又发现有遗漏或者又提出新的需求
?
?
3.功能问题:
方案设计的功能与确认的需求有差异
?
?
4.运行问题:
方案设计已经符合确认的需求,但可能在运行性能、可靠性、可用性方面尚存在问题,这些问题常常会在如下方面对项目产生影响:
?
?
5.技术上的问题:
系统设计可能因此而有所改变
?
?
6.进度上的问题:
项目进度计划可能因此延误
?
?
7.合同上的问题:
可能需要对合同条款进行变更处理
?
?
8.合作的问题:
合作的人员的个人能力或者态度存在问题
很明显,不同的问题升级,代表着不同的后果。
在看看升级的级别,一般原则上的上报机制是:
?
?
Level1:
项目组成员——>Level2:
项目经理——>Level3:
项目经理的经理或者负责主管——>Level4:
项目指导委员会(如果有这样的一个组织)——>项目能够到的最高级主管,比如CEOorGM(据项目而定)
我们可以想象,项目组成员或者客户就不同的问题升级到更高级别的时候,会发生什么问题?
用案例来说话吧。
<案例一>
阶段一:
项目进行到关键时候,项目出现了一些质量问题,即客户在测试中发现了一些Bug,于是客户的项目经理B直接向项目经理A的大老板C(项目经理A的老板的老板)发email做正式的抱怨:
“针对xxx功能的bug问题,我们需要发出一个正式的客户抱怨。
以一个CMMiL5的国际大公司,在xxx功能中,经过你们的测试和质量控制,最后正式交道客户手中,居然存在这样的bug,实在难以令人理解。
......”。
试问,哪个项目不会在交付后还有bug?
但是大老板C会关心这些细节么?
他只关心的是:
客户很不爽,这个抱怨已经影响到了公司的声誉,于是他回了一封信郑重道歉,然后把项目经理A的老板叫过来,一顿教训。
项目经理A的老板啥状况都不知道(他不在mailloop里面)很郁闷,于是把项目经理A抓过来,也是一顿教训。
项目经理A很委屈,但也只能安排团队加班熬夜赶快解决问题了。
阶段二:
故事还没完,客户的项目经理B一看,一封email这么有效,项目经理A现在也老实了不少,过了1个月,他故伎重演,又来了一封抱怨信,当然这次是另外的bug了。
1次是偶然状况,但是2个月里连续2次就很让人紧张了,于是检讨的检讨,背书的背书,内部一致认为这个项目组质量控制不力,项目经理A有着不可推卸的责任!
替换项目经理的事宜也提上了内部日程。
阶段三:
项目经理A被彻底击垮了,当客户的项目经理B一提bug,立即条件反射般地回答“改,改,马上改”;客户的项目经理B要增加新的需求时,原想坚持这个需求不在范围之内,对方脸一横:
上次的bug的事情,我们还没有算账呢?
赤果果的威胁啊,我们可怜的项目经理只好屈辱地同意了。
结果:
非常容易就可以猜到结果了,不是吗?
<案例二>
在客户现场办公的项目,项目组有专门的房间(projectroom),两个BA(业务分析师)就业务问题有不同看法,争执不下,即使客户项目经理在场时也不避嫌,甚至还请其评理。
客户项目经理在后来的客户反馈中评论到:
“项目组成员沟通不畅,协助中存在着矛盾和推诿。
现场办公如此,很难相信他们可以同offshore的众多开发人员可以很好的协作。
”
结果:
两位BA没有过多久就因为种种原因非正常的打道回府。
项目组内部正常的业务争论,到了客户的耳朵里却有着明显不同的解读。
<分析>
做为项目经理,你碰到过类似项目经理A的遭遇吗?
有人会讲,客户的项目经理太不给面子了,客户关系没有搞好。
如果平时在一起多吃吃饭,喝喝酒,建立起个人感情,自然可以解决这个问题。
诚然建立个人感情会起到很好的作用,但是毕竟代表着甲方和乙方,代表着不同的利益关系,常常有时候吃饭喝酒建立起的感情会特别脆弱,比如或者对方的项目经理有着很大的内部压力的时候,上面列了那么多的问题类型,难道对方找不出可以做文章的内容么?
换一个角度,如果不是对方的项目经理越级升级,而是对方的团队成员或者自己的团队成员呢?
这类的状况也是不少,一旦控制不好状况,就会造成很难处理的困难局面。
到底是什么原因导致了这个案例的局面呢?
我们应该如何预防这种状况?
如果这个状况真的发生了,我们应该如何应对?
不当的问题升级会危及到项目及项目经理的生存,我们必须思考解决方案。
具体解决方案的建议请等候下一章节。
项目经理的生存之道(五)-问题升级机制(续)
在上篇文章中谈到了问题升级机制相关的两个案例,下面我们来探讨一下解决方案。
<解决方案>
先谈一下预防机制,预防的方法就是建立有效的“问题升级机制”。
第一步,在项目启动阶段的项目启动会议上正式宣布项目的问题升级机制,即上文所述的逐级升级机制:
Level1:
项目组成员——>Level2:
项目经理——>Level3:
项目经理的经理或者负责主管——>Level4:
项目指导委员会(如果有这样的一个组织)——>项目能够到的最高级主管,比如CEOorGM(据项目而定)。
这个升级机制需要注意的内容有四点:
1.双方都知道每一个的Level的人都是谁。
2.这个机制是双方都认可的。
3.既然是项目启动会议,尽量要求机制中提到的老板们到场。
4.升级机制是双向的:
也就是说,你(乙方)是可以向对方的主管(甲方)抱怨对方的项目经理的!
很令人吃惊的观点,我们不一定这样做,但是需要有这样的权力。
如果有可能,在项目的合同和工作说明书中尽量增加一章“问题解决机制”来阐述这一的机制。
为什么要做这一步?
一旦大家了解并认可这样的机制后,特别是大老板收到项目相关的抱怨时,他首先会倾向于认为他的下属了解这个事情,否则就是对方没有走正确的流程。
第二步,使用工具来引导和执行问题升级机制
首先是针对项目组成员级别的问题,使用在线问题跟踪工具(onlinewebbasedIssueTrackingTool)来管理和跟踪日常的项目issue,常用的软件有很多,比如Jira,Mantis,BugZilla,当然这类工具也可以用来做tasks和defect的跟踪。
需求相关的,质量相关的,性能相关等类型的问题都可以放到系统里面。
有
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目经理 生存