扫码阅读
手机扫码阅读

新手项目经理如何快速搞定内部相关方

755 2023-09-02


感谢阅读,本文共10918字,预计阅读时间大约需要27分钟。

为了方便您的阅读提前列出本文的章节:

1.如何识别项目相关方

2.内部相关方的重要性

3.内部相关方沟通原则和方法

4.跨部门协作



大家好,很多小伙伴没有观看上次的直播,也有不少小伙伴希望能够更深入的理解,那我在这边整理出一篇文章来详细分享一下:

新手项目经理如何快速搞定内部相关方

一、如何识别项目相关方

什么是相关方

既然我们说要搞定内部相关方,那我们首先要来说一说什么是相关方?

    根据PMBOK第六版:相关方(Stakeholder),能影响项目、项目集或项目组合的决策、活动或结果的个人、小组或组织,以及会受或自认为会受它们的决策、活动或结果影响的个人、小组或组织。
    很多新手项目经理可能会忽略两个地方:

那么我们在日常工作当中,常见的项目相关方主要有:

    • 认为项目相关方是一个人,但其实相关方还有可能是一个群体或组织。
    • 相关方不仅仅是能够影响项目进展的相关方,还要考虑受到项目影响的。
    • 项目发起人(老板、BOSS);
    • 高级管理层;
    • 职能经理和职能部门(资源经理);
    • 项目经理;
    • 项目管理团队(PMO、CCB)
    • 项目团队;
    • 客户(合同客户、最终用户);
    • 合作伙伴;
    • 供应商;
    • 政府职能部门或监管机构;

真实案例

这样说起来可能感觉有点虚,没关系,我们来结合一个实际案例来看看如何更好地识别相关方。

    项目背景
    我司与当地电信下属A公司(中标公司)合作开发一个安全出入系统,满足客户(市机关事务局)对于市政府大院的门禁、预约、会务、停车、安全出入等需求,同时移动端需要集成到市政府的智慧大院APP中。

项目结果

    营销中心项目部的项目经理小张,被分配到任务后在市场部商务人员的协助下直接与A公司的对接人小王直接沟通,确定后需求直接安排研发中心开发一部、二部的开发人员开发。结果,项目延期、频繁返工、开发人员怨声载道、合作伙伴各种不满、客户要求承担违约责任。
更好识别相关方

对于如何识别相关方,PMP第六版中提供了很多工具和技术,列明了输入和输出,但是该如何去做,似乎说的并不多,我们借助这两个两个思维模型来帮助我们识别相关。

1.PRINCE2 2017:项目管理结构

三种项目利益

    PRINCE2将项目的利益相关方划分为三个主要类别:商业、用户和供应商,虽然项目中可能会有其他代表各自利益的利益相关方(例如,政府、监管机构或工会)。

每一个类别的利益相关方对项目都有其各自代表的利益及观点,为了使其利益得到满足,他们在项目中也各自具备其具体的角色。

商业 项目产品应该满足一种商业需求,证明项目投资的合理性和投资价值。
    因此应确保这两个先决条件在项目正式开始之前就应存在,且在项目整个生命周期中应始终存在。PRINCE2在项目中定义了项目总监这一角色,以代表商业方面的利益。
用户 PRINCE2对商业利益与那些将使用项目产出的人员的要求进行了区分。
    用户观点应该代表的是符合以下部分或所有内容的人员或者团体:
    • 在项目完成后,他们将使用项目的产出实现收益
    • 他们将运营、维护或支持项目的产出
    • 项目的产出将对他们产生影响。
    PRINCE2 在项目中定义了高级用户(们)这一角色,以代表用户的利益。
供应商 创建项目的产出将需要具有特定技能的资源。供应商观点应该代表那些将提供必需技能和生产项目产品的人员或团体。
    供应商需要了解项目产出(产品)需要满足的所有相关标准,以及项目可能需要使用的能够创造产品的团队,无论是内部的还是外部的。

PRINCE2 在项目中定义了高级供应商(们)这一角色,以代表供应商的利益。

4个管理层次

公司、项目群管理层或客户方 这个层次在项目管理团队之外,但负责正式批准项目,包括确定项目总监,以及定义项目层次的容许偏差,项目管理委员会在此容许偏差范围内工作。如果可能,这些信息应该记录在项目任务书中。

指导 在公司或项目群管理层设定的限制范围内,项目管理委员会负责项目整体的指导和管理。项目管理委员会对项目的成功负有责任。作为项目指导的一部分,项目管理委员会将:
    • 批准所有主要计划和资源
    • 授权任何超过或者预测将要超过阶段容许偏差的偏差
    • 批准每个阶段的结束,授权下一个管理阶段的开始
    • 与其他利益相关方沟通

    管理 在项目管理委员会设定的限制范围内,项目经理负责项目日常管理。项目经理的主要职责,是根据时间、成本、质量、范围、风险与收益绩效目标确保项目生产所要求的产品。
    交付 项目经理负责项目日常管理,而小组成员负责在特定时间和成本范围之内交付达到适当质量要求的项目产品及其组件。根据项目的规模与复杂性,编制产品生产计划、管理专家团队的职权和职责,可以委托给向项目经理汇报的小组经理
    会有很多方面的利益相关方将对项目产生影响或受到项目的影响。这些利益相关方可能来自公司、项目群管理层或客户方组织的内部或外部,并可能:
    • 支持或反对该项目
    • 因项目交付之后而有所得或有所失
    • 将项目看作是对其职位的一种威胁或利好
    • 成为对项目及其进展的支持者或阻碍者
    分析谁是这些利益相关方,并以合适的方式与他们建立密切关系,这一点非常重要。利益相关方有效的参与是项目成功的关键
2.三种角色

用户:

从项目中受益的,比如终端使用者,市场部门,业务部门
客户:
要为项目付出金钱或资源,比如甲方,第三方公司
项目:

要为项目而工作,比如项目团队,供应商,上下游部门,合作伙伴

案例中的项目相关方
    那么根据以上两个思维模型呢,我们可以从上面那个真实案例分析出来的相关方有:
    • 市机关事务管理局(用户)
    • 市政府大院内的各部门各单位(用户)
    • 市政府大院外的各部门各单位(用户)
    • 需要进入市政府大院内的人员(用户)
    • 电信下属公司(客户)
    • 智慧大院APP开发方(第三方公司)
    • 海康威视(设备供应商)
    • 市场部(职能部门)
    • 开发一、二部(资源部门)
    • 营销副总(项目发起人)
    • 研发总监(资源部门负责人)
    • 公司高层(老板、运营总监)
    • 项目经理
    • 项目团队

项目失败的原因
    那么,等到我去给这个项目擦屁股的时候,这个项目已经是严重延期了,需求来回反复的变,开发团队怨声载道,客户也是印象极差,张三本人也是疲于应付,苦苦挣扎的状态。
    我接手之后把项目第一期快速收尾之后,带领项目团队复盘就发现了,这个项目之所以会失败,就是从一开始识别相关方这里就出了问题。
    那么当时我们的项目经理在识别相关方的时候犯了什么错误呢?
    首先,他并没有去识别项目的最终用户,或者说识别了,但没有把这些用户纳入相关方管理规划,导致完全忽略了他们的需求,而误把电信下属公司认为的需求当成了项目的主要需求,
    其次,在需求确认的过程中,也只是和电信下属公司的项目经理来确认需求,都没有经过电信下属公司高级管理层的确认,简单的把相关方认为是单独的一个人。
    最后,回来就直接安排开发人员开发,没有与内部的相关方进行任何的沟通。
    那么结果可想而知,不要说满足用户的需求了,连电信下属公司的领导那关都过不了,导致来回反复修改,当然最后项目失败的原因也有很多其他因素,但是从一开始就因为没有做好相关方管理从而导致需求就不对,这就是一个最大的原因。
小结

那么通过我们对于这个案例的分析,会得到一个什么结论呢?

识别并引导相关方参与越早越好

    PMBOK第六版中提到:“为提高项目成功的可能性,应尽早开始识别相关方并引导相关方参与”。
    而且我们看十五至尊图,识别相关方是在启动过程组中除制定项目章程之外唯二要完成的过程。
    也就是说PMI认为,相关方管理应该越早开始越好,在项目一开始的时候就应该把相关方识别工作给做好,规划的时候就应该把识别到的相关参与给规划好。

识别并引导相关方范围越宽越好

    我们同样可以看到在PMBOK第六版中提到:“相关方”一词的外延正在扩大,从传统意义上的员工、供应商和股东扩展到涵盖各式群体,包括监管机构、游说团体、环保人士、金融组织、媒体,以及那些自认为是相关方的人员(他们认为自己会受项目工作或成果的影响)”。
    PMI认为应该尽可能宽一些,“识别所有相关方,而非在限定范围内”,因为遗漏重要相关方会给项目带来很大的麻烦。

回顾
    通过上面的这个案例,我们可以看到在项目当中做好相关方管理是多么的重要,客户很重要、用户也很重要、合作伙伴也重要。
    那我以后做项目一定要把外部相关方管理到位,那我以后做项目一定要把外部相关方分析到位,权力利益方格、权力影响方格,或作用影响方格、RACI矩阵等等工具,从权力;作用;态度;信念;期望;影响程度;与项目的邻近性;在项目中的利益;与干系人和项目互动相关等等多个方面照顾到位,那我一定就能把项目完成得漂亮。

二、内部相关方的重要性

容易忽略的角色-内部相关方
    如果是是这样想的,那我可能要给你泼一泼冷水了,我们都知道做好相关方管理对于项目的成败至关重要,但是很多项目经理通常都喜欢把目光和重点放在外部,而忽略内部的相关方。
    这也是很多新手项目经理把项目搞砸的另一个重要原因。
    我还是拿上面这个项目当做案例,这位项目经理在做项目的过程当中,不仅没有做好外部相关方管理,内部同样没做好。

我简单介绍一下我所在的组织呢是一个非常典型的职能型采用传统管理方式的软件开发公司,分成三大中心:研发中心、营销中心、运营中心,项目部、市场部归属营销中心,产品部和开发部归属研发中心。

而小张在调研完需求后,回来就直接安排给开发人员开发,结果可想而知,开发人员根本就没把这当回事,不说完成的质量怎么样,甚至根本都不会排进自己的工作安排。

    为什么呢?
    前面说过了,我们组织是一个典型的职能型组织,每个人都有他的直属上级,每个人都有自己要完成的任务,每个人都有部门安排的目标,从上至下进行垂直管理。而项目经理没有与研发中心的领导和开发部门的经理进行任何的沟通,直接通过工单派发任务,结果就是工单无人理会。
    先不说收集的需求合不合理,是不是真实需求,就他自己制定的项目进度管理计划就根本执行不了,用他自己的话来说呢就是“腹背受敌”,当然了,用我的话来说就是“自作自受”。
    当然,在这样一个环境中项目经理想要开展项目工作确实是很不容易的,那么,我们应该怎么做呢?
项目中的“两会”
    其实就是按照五大过程组做问题就不大。当然,我这说的是废话,要是不按这个做,我们不就白学了,
    所以,我认为在一开始最重要的呢,就是开好项目当中的两会。

首先,就是项目启动大会,确保在章程中自己获得任命,并被授权调用组织内的资源以完成项目目标的内容,其次应该邀请包括老板、高层、各职能经理、资源经理等拥有高级权限的相关方召开项目启动大会,在启动会中要确保通过项目章程,其中最重要的也就是通过发布项目章程来确立项目在组织内部的地位,并任命项目经理,赋予项目经理动用组织资源的权力。

    然后,我们还要再开一个会,项目开工大会,也叫项目开踢会,这个会议同样也非常重要,除了启动大会的相关方外呢,还有内部相关方和项目团队也一定要参加,在这个会中呢,介绍项目主要信息,比如项目的组织结构、管理计划、进度里程碑计划、风险控制流程等等,这对于鼓舞团队士气、树立项目经理威信、建立相关方信心、面对面沟通获得相关方对于项目的支持,获取老板和高层领导的支持非常重要,同时关键的是也能够获得各个相关方对于参与并支持项目的重要承诺。
    开好“两会”对于我们以后开展项目工作至关重要,也是决定了项目成功或失败的关键因素。

回顾小结
    通过上面这个示例,我们可以看到项目的相关方对于项目的成败有多么的重要,而我们很多项目经理在日常的工作当中呢,经常会忽略了内部相关方而导致项目失败,或者说因为不懂如何去跟内部相关方沟通而导致无法做好相关方管理,最后也没有把项目做好。
    那么又该如何做好内部相关方的沟通工作呢?

三、内部相关方沟通原则和方法

黄金圈法则

作为一名优秀项目经理或者想要成为项目经理的我们来说,思考一件事情肯定不是和一般大众那样由外而内的方式。

而是要使用非凡模式,就像黄金圈法则一样,一种以目标为中心的思维方式,我们要先思考为什么(WHY)的问题。

    我们首先思考为什么要做好为什么要做好内部相关方的沟通工作?因为相关方沟通是相关方管理的重要组成部分,内部相关方同样是相关方的重要组成部分。
    PMBOK第六版:研究显示,顶尖的项目经理投入有 90% 左右的时间是花在沟通上。
    逻辑简单明确,对不对,那么这就回答了为什么的问题。
    那么我们就来看看怎么做的问题,怎么做,我们就需要方法、原则、措施。
    内部相关方沟通我们该怎么做呢,我总结了以下5点:
目标一致 利益先行

相关方,我们通常也叫利益相关方,但凡涉及到人或者组织,必定是有利益关系在。

那么我们在项目当中也是一样的,如果利益关系摆不平,那么事情肯定就是干不好。

虽然我们说的是内部相关方,大家都是在一个组织当中,按理说目标应该是一致的,那我既然为了公司去完成项目,你们就应该要来帮我一起完成好项目呀,那真实情况是这样吗?

是,我们作为一个组织,大家的整体战略目标是一致的,但是具体到每个业务部门,虽然要为组织的整体战略服务。

但是,根据他们自己在组织中的定位、需要完成的目标等等,每个业务单元也都有自己的战略,而且不同的人也有不同的行事风格和部门规则,也都会有自己的利益诉求。

    而我们项目经理如果只是扛着公司战略的大旗,不去考虑内部相关方的利益,肯定是很难获得支持的。

比方说上面这个案例,如果是我作为项目经理,那么我要重点考虑谁的利益呢,没错,就是资源部门及资源部门的负责人,就是研发中心,我需要开发人员,必定要从研发中心借人,一旦借走了人,势必造成研发中心自己的进度安排出问题,那我会找研发中心负责人商量,我会在项目预算中增加一个新的开发人员预算,我项目用完后借四个人还五个人,你人员多了自然每个人的任务就少了,你以后安排任务的空间就会更大。

而且在项目期间,这四个开发人员的绩效奖金由项目组承担,不占用研发中心的奖金池,这样你们每个人的奖金会变多,而且还能保证开发人员的项目奖金还比部门的绩效奖金多一点点。

至于你研发中心的工作安排,我会先找老板说明情况,帮你协调好,不会让你难做。最后,项目成功的话,一定会单独再给你记一功。

这样操作下来,不管是研发负责人,还是借过来的四个开发人员,都是皆大欢喜。

如果说用利益打动不了的话,那么这个时候就是需要请出项目发起人了,一般就是老板或者高层,由他出面协调。

这个时候你也不能干干看着,要继续以对方的利益为先,充分考虑他们的利益,动之以利,辅之以理。

“把坏人留给制度,把好人留给自己”,你看,我也是接了这个烫手山芋没有办法,在我最大范围内给你争取利益,动之以情,晓之以理。

横向沟通 及时有效
    我们常说,项目经理大部分时间都在沟通,可见沟通对于项目的重要性。
    而沟通最重要的是及时有效。
    及时,确保相关方都能够第一时间了解项目的各种情况,
    有效,确保传递给相关方的信息都是清晰准确的,且能够获得准确的反馈。
    及时有效的沟通可以借助各方面的经验和意见规避常见的风险。
    若沟通不及时,严重的情况会使开发方向偏离预定的目标,造成各方面无谓的资源投入并影响后续节点。
    而如果在职能型组织中,采用横向沟通能确保我们的沟通及时有效,实际工作当中也是,比如还是上面这个案例,我需要一些职能部门的协助,如果我每次都是要只跟这个中心的负责人沟通,等他再找部门经理沟通,等到安排具体人员来协助我的时候,黄花菜都凉了,而我会直接找到这个具体的办事人员,告诉他详细的工作安排,他只要问一问他的领导行还是不行即可。
    横向沟通。简单高效,沟通成本极低。
向上沟通 借力使力
    PMBOK中提到不少上报,对于项目经理无法处理的,超出权力和影响范围的,我就需要及时上报,在我们实际工作当中也是一样。
    我们需要上报的仅仅就是以上这些权责之外的内容吗?
    除此之外,我们还需要将项目的绩效、进度、团队状态、困难、问题等等情况都需要及时地上报给关键相关方、发起人、高级管理层、职能和资源经理。
    人是拥有控制感需求的动物,控制感的获得,不仅来源于对事件进程的显性干预,也来源于对事件的目所能及。
    我们来回想一下在星巴克的排队购买咖啡时的场景,沿着柜台横向排队,轻而易举的可以看到在工作区内的工作人员的所有工作细节。
    这样,随着工作人员的忙碌的身影,调制出一杯又一杯的咖啡,意味着自己那杯也很快来临,焦虑感也随之降低。
    我们再来回想一下你在肯德基的排队,当你排在最后面的时候,你会焦急的望向柜台,心里不停的嘀咕,怎么这么慢?前面的人在干什么?
    所以,我们在完成项目的过程中,一定要记得在时时汇报,不要总想着把事搞完后,有了结果,再给老板一个surprise。老板不需要惊喜,只需要控制。
    所以,降低焦虑的方法是让对方看到过程,把我们所有的工作透明化,满足对方的控制欲,就要学会向上沟通。要想办法把项目变成和高层共建的项目,而不是项目经理自己单独的项目,这样项目的碰到问题就是高层的问题,借高层的力,办项目的事。
    及时有效地汇报,让管理层了解项目动态,并从更高层面为项目推进提供必要的支持和帮助。
以人为本 把人当人
    我们常说“以人为本”,但是对这四个字的理解可以是千奇百怪,各有不同吧,我要说的是“把人当人”。
    为什么这么说?
    以人为本,然后呢,后面该怎么做呢?
    说不出个所以然来,所以我说,以人为本就是把人当人,把别人当人看,把自己当人看。
    人就有人性,就有七情六欲,就有复杂性,就有善的一面,恶的一面,要从项目经理、项目团队、内部相关方等等这种角色中退出来,不能把这些人仅仅看做获取帮助的工具和供自己驱使的棋子,回归到“人”的立场,审视思考自己的所作所为,是否违背了“人”的意愿,从而使自己保持“人”的思考能力。

在人之下,把自己当人

    比如前面觉得例子中,项目经理小张就是面临着这种囧境,像前面说的,相关方管理工作一开始就没做好,让自己师出无名,处处碰壁,最后就彻底放弃躺平摆烂,把自己不当人,对甲方,恨不得跪在地上让别人少提需求,对团队,各种讨好小恩小惠收买为自己干点活,自己都不尊重自己,你还指望别人来尊重你吗?

在人之上,要把人当人

    还是上面这个案例,我在接手烂摊子,开始擦屁股的时候,重新澄清项目授权,建立项目型团队,树立权威,这个时候那我就要变本加厉,矫枉过正吗?其实不是的,保持开放的心态、尊重他们的个性和想法、信任他们的工作,珍惜他们的付出,告诉团队成员,我们的目标是一致的,我们可以通过自己的努力来达成这个目标。
    要考虑到每一个相关方他们作为一个人的价值感受,尊重他们的人格和尊严,以及作为一个人的权利,以及他们的利益诉求,只有这样,我们才能真正的共情,也才能真正知道他们想要什么。
    同样作为项目经理自身也是要尊重自己,展现出自己的专业性和良好的职业素养,不卑不亢,才能获得他们真正的认可、协助和支持。
软技能 非正式沟通
    软技能,这里主要指人际关系。
    PMBOK中说到:项目经理使用软技能(例如人际关系技能和人员管理技能)来平衡项目相关方之间相互冲突和竞争的目标,以达成共识。这种情况下的共识指即便不 100% 赞同,相关方还会支持项目决定和行动。
    可见软技能的重要性。
    其实不只是在解决冲突的时候有效,在我们沟通的过程当中,人际关系也是发挥着巨大的作用。因为良好人际关系往往是建立在良好沟通的基础上,而良好的沟通又会反过来促进人际关系的良性循环。
    说到沟通呢,沟通又分成正式和非正式,而在很多时候,正式的沟通其实并不能帮我们达成目的。
    我们可以回想一下我们实际工作当中,每次正式的项目会议当中,真正有用的信息有多少,是不是大部分都是空话套话,翻来覆去的说,导致一听到开会,大家都是反感:又要开会。
    而非正式沟通不一样了,午饭时间一起吃饭顺便聊聊项目进展,加班的时候来个内部讨论,一边吃点零食一边侃侃而谈,阳台抽烟的时候吐槽一下某个高层,是不是能够获得很多真实的、平时不想说不愿说的信息。而这些非正式的沟通,是能够帮助我们建立良好人际关系的基础。
    当然,如何去建立良好的人际关系有很多方法,今天也不展开去说,单把非正式沟通拎出来说,在我看来,确实是能够帮助项目经理建立好人际关系,也能帮助我们处理好和内部相关方的沟通,从而帮助我们更好的搞定内部相关方
    同样的PMBOK也是多次提到非正式沟通、会议、访谈等等,所以为什么说非正式沟通这么重要,形式灵活,直接明了,速度快,省略许多繁琐的程序,容易及时了解到正式沟通难以提供的信息,最重要的他能够真实地反映情况,比如相关方的真实想法、态度和动机。

四、跨部门协作

跨部门协作中的难题
1.每个部门都有自己的战略
    虽然我们在一个组织当中,受我们整体战略所指引,但是我们每个部门在组织内部身份不同,承担的任务不同,聚焦点也不同,自然部门的战略也会不同,而战略不同就会导致出发点完全不一样。
    还是拿我现在所在公司举例子,我们研发中心的战略就是产品战略,包含了产品平台战略和新产品开发战略,那么营销中心的战略中项目的部分其实就跟我们部门一点关系都没有,虽然我们都是公司整体战略的组成部分。
2.每个部门都有自己的优先顺序
    从决策模式到资源分配方法,不同部门的人关注的重点自然是不一样的,你重视A我重视B,你考核甲我考核乙,造成的结果就是,哪怕我们是同一个项目中,但不一定就能好好合作。
    就像上面说的,研发部门为了实现我们自己的产品战略,那产品的更新迭代工作肯定是优先级最高的,其它插入的任务当然会排在自己的事情后面,除非是有高层介入。
3.每个部门会有不同的思维模式
    想法不同,思维模式不同,做事的方法和时间轴不同,所以很难真正地站在对方的角度去思考问题,合作效率自然也很低。而且就算在部门内部也会存在不同的想法,位置决定脑袋,不在其位不谋其政。
    这个其实就很好理解吧,比如产品经理和项目经理,产品经理为了设计一款解决一类问题的通用产品,关注的是市场动态,需求调研,数据挖掘和产品设计。而项目经理把一个已经具体化的任务按计划完成,关注项目成本控制(时间成本、人工成本、资金成本等)和保证质量。比如市场和开发,对吧,就像我们
4.每个部门有不同主管
    虽然大家可能都是为项目服务的,但有的人手上不一定就一个项目,可能几个项目的工作都有在做,而且,我的顶头上司安排的活不干,难道先给你干?;反正都是给公司干活,干哪个不是干?所以有的时候,人情世故,事情并不是很好推进。
    所以,我们想要改变跨部门协作的这些问题,可以采取下面这三个步骤。
正确表达 尊重感恩


准确清晰表达需求
    当我们需要对方去完成某项任务,需要详细的去表达清楚内容:谁、什么时候、什么地方、做什么、为什么要做,怎么做,完成标准,而不是简单的一句话,那谁谁你去做个什么。
    比如我们软件开发,我们需要开发人员去编码完成一个功能,那么我们必须有需求文档提供,对于需求的详细描述,流程图、活动图、状态图、交互说明、限制说明、字段字典等等。
    如果你想要一个好的结果,那么一定要有一个好的输入。

理解对方的难处
    协作部门推进不积极,很可能是因为对方需要支持的项目很多,或者从他的角度来看你的不重要。如果遇到这样的事情,千万不要先用领导去压人,不要打官腔,讲道理。你可以先试着站在对方的角度,理解对方的难处。
    比如:X哥,我知道咱们这边也不是只顾着我这一个项目,你们这边人手也不够,但这个项目确实挺急,您看要不先给我把这一点做了,这样XX那边才能往下推进......改天我请你吃饭啊。
    先倾听对方的难处,表达理解,然后才可能让对方你倾听你的需求。

匹配对方的期望
    想要争取对方与你合作,首先就要了解对方的期望,对方职位的KPI是什么,想在这个项目中获得什么,个人偏好和价值观是什么,工作状态是什么样的。你能够提供和对方的期望能够匹配上,你能带给对方什么。
    这些如果都能搞清楚,不说全部匹配上,就算能匹配上一半,那其实问题就解决了一大半。

区分需求优先级
    如果所有事情都重要,就说明所有事情都不重要。如果所有事情都是紧急,就说明没有事情紧急。
    我们了解对方的处境、理解对方的难处,就是为了正确的表达自己的需求优先级,哪些是需要今天做的,哪些是本周,哪些事根本不急,如果空了顺手做。
    只有尊重对方的工作和时间才会得到别人的尊重。这一点是跨部门协作中最重要的一点,也体现了项目经理的责任感和领导力。

心怀感恩
    有句话很现实,在职场,没有人有义务帮助你。所以我们要常怀感恩之心,无论这是不是对方份内的工作,也无论对方的动机是什么,只要对你提供了帮助,你都需要承情,并且在合适的时候力所能及给予回报。

跟踪过程 承担责任

及时沟通,调整进度
    跨部门沟通需要定期同步信息、互相分享合作心得与回馈、一起调整工作步调让彼此同步是很重要的。
    作为项目经理,当自己这边的工作进度或者优先级有调整时,要及时主动站出来与其他部门的相关方进行信息同步。当项目出现异常问题时,也要及时反馈、跟进。
    在某种程度上,心态上可以把这些各部门的朋友们当成自己的团队,当你认定对方是伙伴而非敌人时,合作可以更加紧密。

分配工作,不分配责任
    很多项目经理会在这点上纠结,对方又不是自己部门的人,自己也是权低人微,但又需要对方配合工作,该怎么办呢?
    工作交待出去不代表和你没关系了。职场上常常出现甩锅的事情,领导问起来就说这件事是谁谁谁在跟进。领导是交给你了的,做不好他不会找别人,只会找你。用这种甩锅借口,领导反而会觉得你是个没担当、没责任心的人。
而对于帮助你的跨部门同事来说,这样无异于在推卸责任,他还愿不愿意帮你都是问题。
    所以过程中一定要跟进,将责任始终放在自己身上。提前和对方约定好进度和时间,出现了拖延等异常情况,及时沟通处理和协调。
    最后任务完成时出了问题,也要及时出来承担责任。否则下次没人会愿意帮助你,因为都知道你是甩锅侠了。
    项目经理要明白,你可以把对方需要做的工作分给他,但是即便对方答应配合工作,不代表我们就可以当做把球扔出去,完全不需要管。要记住,锅还在我们身上,做好了是对方的功劳,做坏了是项目经理的责任。
    作为项目的负责人,项目经理要随时准备好,不管因为任何原因导致项目延期、项目失败,我们都需要站出来承担责任,能抗事儿是我们的最重要的品质之一,所以,肩膀硬一点。
及时肯定 正向反馈

及时公开肯定
    项目经理永远都要记住,你是项目的负责人。其他部门的人是配合你、帮助你来完成项目的。所以,即使过程中我们付出99%的努力,无论对方付出1%的努力,你也必须给予及时的、完全的认可。
    不管是私下还是公开场合,不管你出于真心还是假意,一定要多在公开场合给予合作的同事肯定。夸人虽然不用当面,但是也不能一句不说。毕竟你不可能只做一个项目,也不可能只跟几个人合作,你夸奖别人的同时,那些没跟你合作过的人也会私下对你进行评价。
    项目这么多,公司就这么大,谁知道下个要跟谁合作,是吧?
    要多在对方上司和公司高管面前给予肯定
    这也是项目经理高情商的一个重要表现,多夸领导手下的人,下次你再用人家的时候,就好说话。同时,也顺带称赞了对方的上司领导有方。在公司高管面前也能留下你这个项目经理在与人沟通能力很不错的印象。

正反馈效应
    所谓的正反馈效应就是某人做了符合他人价值观,让他人感到高兴的、兴奋的事情,并受到夸奖、鼓励,进而做事人就会继续努力的把这件事情做好,而且会越做越好。或者说,一件事情的发生、发展受到了另一件事情的刺激,促进了其正向发展。
    跟我们管理理论当中的Y理论很像,现在的年轻人,思想自由,追求平等,颠覆传统,不认可权威,但同时又期待被迅速的读懂、认可和肯定,喜欢速成、快速看到结果。他们表面放荡不羁,什么事情都毫不在乎,其实是没有遇到能够读懂他们内心的伯乐,我们多使用正反馈效应,就能够激发他们心中的责任感,主动性,能够承担责任,自我驱动。
原文链接: https://mp.weixin.qq.com/s?__biz=Mzg3NDc0MDc4Mg==&mid=2247483973&idx=1&sn=07d5f00e5c8c86f6523aba94eb71b3d4

对待离自身尚远的事物时,人们可以把它分析得淋漓尽致;但到了自己身上,就往往成了当局者迷,旁观者清。譬如软件开发,譬如项目,譬如产品,譬如敏捷,譬如精益,譬如管理,譬如思辨,譬如哲科思维,譬如哲学。来到圆桌派,让我们一起旁观者清!

35 篇文章
浏览 9871
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线