心急能吃热豆腐嘛？

不能，烫嘴。

故事

下午6点下班后，公司南区的销售团队拉在北区的我开线上会，探讨客户刚提出的需求怎么应对。

半个小时聊下来，我算是明白了，客户只给了几个“行业术语”，别的啥信息没给。然后，销售同事就迫不及待的拉我们开会了。好像销售那边有个感觉，这个会不开，这个需求不应对，会立马丧失千万大单。

我能理解销售的感受，好不容易花了一年做了一点大合作伙伴的关系，然后合作伙伴内部人事调动。现在新来的团队，对同行来说，还算是同一个起跑点。所以，想跑快点，争取多搞搞合作。

只是，想搞合作也不是这么个搞法。

销售作为公司接触客户的一线，如果自己对信息没把握好，频繁的调动后端资源，最终的最终，只会带来一个后果：将帅无能累死三军。

所以，在会议上，我也从售前的角度进行了点反馈，我们需要销售再和合作伙伴多碰碰，多了解一点信息，然后针对性的应对。这样，才能在应对时体现我们的案例、技术、经验等等。这样，才不至于基于现在知道的行业名词，直接递通用资料给客户，然后客户觉得不对口，丧失掉后续的合作机会。

比较好的是南区的销售团队还能接受我的反馈，而不是像北区的销售一样，膨胀了，觉得自己无敌了，啥都听不进去。

也挺好，北区都是爷。咱级别低，伺候不起，不伺候还不行嘛。

唉，也只能发发牢骚，如果领导安排下来，肯定还是要听的。

还是聊回到“心急”。

现在的社会变化太快了，快到刚相亲见个妹子，直接把孩子的名字都想好了。

都太浮躁。

我现在，算是明白，为什么很多老年人喜欢钓鱼了。

钓鱼，就和做项目一样，要有耐心。要先分析那个鱼塘有鱼、鱼有多大、吃什么饵、喜欢什么时辰活动，然后找准地方，投饵，静等。

急不得。

例外

当然，万事不绝对，有些事情是可以加速的。

比如，企鹅家掌门人的一句名言“你这个问题，充个钱就能解决。”

类似以前我在头马给一些新会员分享的时候，有一些新会员会问我“怎么样才能成为你这样的‘大咖’？”

通常，我的回复很简单，“和我一样在头马待4-5年，你肯定成长的比我更好。”但这个回答得到的反馈则是“4-5年？太长了，有没有快速的方法？”

有，真的。

为什么说“时间就是金钱”，因为在某种意义上，这两者是可以互换的。比如，你上班花时间挣钱，你老板花钱买你的时间。

所以，想快，很简单，找个私教，肯定可以让你快速的达成你想要的目的。

结语

人生，急不得。

每个人有每个人的节奏，每个项目也有每个项目的节奏。

节奏乱了，就不是曲了。

貌似这一年来很少写一些项目管理方面的内容，刚好最近有一些零星感悟，所幸写一些吧。

要不然，又要遗忘了。

今天的文章主要来自于近几年在售前工作过程的一个思考，仅供参考。

另外，需注意，本文为工作实践，对PMP考证可能起不到正向作用，请慎重。

评估

需求平台或者商机评估对售前人员来说，可谓是必修之课，也是公司项目合作的第一个重点里程碑。如果评估失误，可能会导致合作失败或者项目亏损。

当然，合作失败、项目亏损可能来自于很多因素，但其中售前对项目整体的评估也将为合作的成功起到决定性作用。

通常，对需求的评估或商机的评估需要依照多重因素，除常规的项目制约因素：范围、时间、成本之外，还需要考虑公司的产品、公司的实施能力、客户的相关信息以及相关商务部分的信息。

当然，做为售前，最重要的还是要依据项目的三种制约要素来进行评估。

在评估之前，我们还是要看看要评估的对象：需求，或者说商机。

需求

需求这个事情，在工作的实践过程中大体会分为以下几种情况：

1. 口述需求。
2. 规划需求。
3. 招标需求。
4. 分包需求。

口述需求，通常较为粗略，也是在工作中面对最多的一种情况，但此类的需求评估也较为简单，只需回复能做、不能做或者可基于相关经验定制开发即可。

口头上的需求评估，基本上不涉及相关费用，只需评估业务范围是否可行，便于销售进一步推进项目即可。

在口述需求的之上，得益于销售团队的能力，可能会提前拿到客户的相关规划的需求文件，针对此类的需求可以参考以下具体评估的细节步骤。

招标需求的评估比规划需求还要严谨一些，所以此类的项目评估会需要售前团队、技术实施团队、商务团队以及招投标团队进行综合性评估，更为复杂，所以此文不在赘述。

而另一类的分包需求则与规划需求类似，只是在评估成本上采用的系数不同，因此可同样参考规划类的需求评估步骤。

背景

作为售前，我个人在接到评估任务的第一时间，我会先问我们的销售团队几个问题：

1. 这个需求的来源？是来自于渠道、还是直接客户？
2. 客户/渠道的关系如何？首次合作、多次合作？
3. 当前需求的阶段？是做预算阶段，还是中标后要分包的阶段？
4. 如果分包阶段，则会追问一句：当前的预算大体是多少份额？

只有把这几个问题了解清楚之后，才能知道项目的大概基本信息，也能选择相应的评估技术和方法。

举个例子：一个商机需求来自于最终客户，但该客户还未合作过，当前正出在预算编制的阶段。

基于这个例子的信息，我要评估的话首先成本会选择公司的市场公开报价，并在工期的评估上上调50%，便于后期的项目风险控制。

在这个前提之下在进行具体相关需求的技术评估，以及整体的项目概算设计。

评估

具体的评估还是要落地到项目的范围、时间、成本上，通常依照相关需求进行项目范围的划分，在此基础上大体拆分下我们所需的时间，最后汇总成通用的成本，然后反馈给销售。

范围

通常，规范内文件中写的范围不一定就是项目的全部范围。因此，需要对相应的项目内容进行仔细斟酌。这个时候就需要有一定的技术知识、实施的知识及项目管理的知识，最好还需要对公司的实施能力的一些了解，这样才能划分的更为准确。

举个例子，我上天接到的一个技术需求，客户的要求是X，而这个X的达成在规划文件写的是通过A来达成。这个X呢，我司也可以通过自己的B方法进行实现，但我们的这个方法B与A是不兼容的。所以，我最终给销售团队的反馈就是，需要和客户明确，是只要这个X，还是实现X的A也都需要。如果客户只要X，那OK，我司可以通过B实现。如果客户不仅只想要X，还想要A，那这个项目我司承接不了。

在举一个小例子，在我接到的需求评估中，经常有“通过XX算法实现相应的预测分析进行价值呈现”。很简单的一句话，但XX算法这个词就代表了背后最少1-2月的人工。针对此类项目，不仅只要考虑价值呈现的工作量，还需要包含这XX算法背后隐藏的工作量。

在范围评估这一块，推荐使用项目管理中的WBS工具，把自己当成项目经理对整体需求拆分，这样才能更合理的整理出项目框架以及项目范围。

时间

在整理出项目范围后，则需要对相关的范围进行拆分然后进行时间的评估。拆分主要是要区分软硬件成品以及相应的服务，软硬件成品可直接外釆或者转包，但服务部分就需要仔细衡量相应的时间。

在进行相应的时间评估时，则可以根据拆分的颗粒度进行独立评估。汇总后上浮50%，然后找技术实施团队，大概过一眼，没啥问题，再进行最后的成本汇总。

成本

成本，最核心的是人力成本。毕竟，人力成本不可控因素过多。

例如，有些工作初级工程师即可处理，而有些则必须要求高级工程师才能处理。这两者通常在人力成本的评估上会采用的不同的系数。

因此，在进行成本评估时，需要考虑对WBS拆分出的任务进行相应资源的匹配，然后在进行相应成本的核算及汇总。

其他

资源、风险、质量也是项目的另几重制约要素，只是，在评估时可以太过在意。

只是在进行项目范围确定时，确认一些重大不可行风险即可。如，不在公司业务范围的、公司以前没有做过的行业项目，以及公司明显不具备的相关软件、功能。

这些在进行评估后汇报时，需和销售团队明确。

总结

不知道，看完本文，你是否对售前工作的评估多了一份了解。

今天是第二次去天津出差，挺好，又解锁了一个陌生城市。（虽然也没逛过）。

这次去和第一次去天津一样，见的同一位客户， 推进的是同一个项目。

不一样的是，随着项目的推进，感觉项目的可靠性在逐渐清晰，变得不那么可靠了。

吐槽

初步的分析了下，使未来合作的可能性降低的不是技术问题。

毕竟，在不考虑成本（时间、金钱）的情况下，没有技术解决不了的需求。

核心的原因就在于，客户想在有限的资金和时间下完成不太有限的需求。

感觉，这都是甲方的常规诉求。

“挑战不可能”。

作为一个半技术出身的人，我有点讨厌这种感觉。

一分钱一分货，是商业市场的基本准则。

当然，这一分钱谁出那是另一回事，比如“羊毛出在猪身上，狗来买单。”

但归根到底，这“一分钱”总归是有出处的，不存在“免费的午餐”。

要素

所以，回归到今天的文章主题：制约项目的核心要素是什么？

钱嘛？

不是。

最核心的要素，其实是客户的诉求。

这个诉求包含两部分内容：客户的支出与客户的收益。

其中收益是通过项目解决客户存在的问题，而支出则是为了完成收益要付出的成本。注意，这个成本不仅仅是金钱，还有一些潜在无形的内容。

相对应的，客户诉求与供应商的诉求是反向的。

客户的支出为供应商的收益，客户的收益为供应商的支出。

只有双方这两个等式成立，这个项目才是靠谱的、皆大欢喜的。

所以，客户诉求的合理性将决定项目启动及后续实施的可能性、完整性及价值性。

那如何判定客户的诉求是合理的？

作为售前来说，我们可以确定的只有一个等式，那就是客户的收益（公司要出的成本）。

至于另一个等式客户的支出（公司的收益）将由销售团队或公司高层决定。

最终的两个等式能不能划等号，这就不是我这个小售前可以决定的了。

结语

简单总结下，制约项目的核心要素是：客户的诉求。

而判定客户诉求是否合理，这是公司高层要考虑的事情。

当然，售前也可以从公司高层的角度去出发。只是，这么做可能会有些偏差。

5.26日在公众号上提的问题，木有回复。

顺带也扩散了下问题。

什么样的项目可以称之为“成功”？

达成目标？

如果目标是“错误”的呢？

如何定义“错误”？“正确”？

还记得当时提这个问题的原因，是在一些微信群里各种“商业互夸”，就没见到不成功的项目。

所以有此一问。

不过，现在看来，这个问题问的可能也是些废话。

思考

作为一名前项目经理，在我个人看来，如何定义成功的项目，只有一点，是否完成既定目标。

目标达成，那肯定是成功的项目。如果目标未达成，那肯定是不成功的项目。

所以，项目的成功不成功主要取决于这个“目标”。

那么问题来了，这个“目标”是达成共识的嘛？

在一个项目当中，参与这众多，如何确定大家对目标的理解是一致的？

在工作当中，经常会遇到一种情况就是，项目承建方认定的“目标”与项目出资方、项目使用方认定的“目标”是不一致的，从而导致项目的验收出现问题。

公说公有理，婆说婆有理。

如何应对？

应对

沟通。

以客户为中心，基于客户价值达成目标的一致性。

客户出资建设项目的目的核心是解决问题。

所以，针对问题去框定目标。

当然，这里面也会存在一个问题，相关利益方太多。

比如，同一个项目，甲乙双方的项目经理、项目经理背后的部门、背后的公司，简单的算下来就有6个角色，更别提，还有商务人员、相关领导、业务部门领导等等。

利益相关者这么多，如何确保目标一致？

一个字“谈”。

核心，就是利益的切分，争取多方达成共赢。

比如，可以分析这些相关者的权重，目标的偏离程度，找重点突破。然后和权重高的一块去影响、说服那些权重比较小的。最终，达成共赢，从而是项目走向成功。

这是涉及到“利益”的项目。

如果，不涉及到利益呢？

不涉及利益的话，为什么还要在意成功和失败，自己经历就好了。

结论

一个感觉有点废的问题，没有问道核心点。

或者说，这次的填坑，没填到核心点。

最近项目在推进POC（概念验证）的过程中，基于沟通的原因，出现了一点小问题。不过还好，沟通产生的问题沟通就可以解决。

因此，也简要总结下在信息化项目过程中，常见的售前沟通目标。

信息化项目中的常见沟通目标

本人从事IT行业10年，其中售前做了5年，所以，我觉得我算是见过大场面的。

在这些场面里，售前沟通的主要类型，在我看来，可以分为四个方面：

• 展示能力
• 描绘愿景
• 控制预期
• 呈现价值

展示能力

展示能力的核心点就是展示公司产品、解决方案、项目案例中客户需要的那部分的能力。

注意，是客户需要。

如果客户不需要，能力展示的再多，对项目的成交毫无帮助。

因此，要做到展示能力，就需要准确了解客户的需求。

但是在商务阶段，很少客户会直白的告诉你，他需要什么，那我们怎么做 ？

• 了解客户背景，包括客户所处的行业，对接的部门、科室，对接的人员。

• 熟悉公司的项目、产品，寻找同行业的项目案例，综合对比分析，将客户可能需要的内容与商务团队分享。

• 让商务团队启动商务策略，侧面确认。

描绘愿景

在能力获得初步认可之后，随之而来的就是要帮助客户规划本次项目的目标，形成愿景获得客户认可。

客户的需求都是散的，如何有效的将需求从点串成线，由线织成面，这就需要售前充分发挥团队作战能力。

可以从相关政策、从行业发展、从企业创新等多个维度去寻找，找到与当前客户最匹配的那个，并将之描绘给客户，同时让客户进行愿景的修正。

这是整个项目的基石。

控制预期

有时候项目的愿景会做的特别大，客户也特别着急的去实现它。但项目建设是需要时间的，愿景越大、成本越高、周期越长。这个时候，我们要做的就是控制预期。

我们可以将这个大的愿景调整为三、五年规划，并在规划中再进行细分，分到季度。尽量的做到让客户感知到可以逐步投入资源，慢慢的实现小的价值，从而逐步的接近目标，实现愿景。

呈现价值

在项目的逐步落地过程中，我们需要近实时的让客户感知到价值。

这个价值，不是项目完成后的价值本身，而是让客户感知到你在“创造”价值。

同时，在小阶段性进行成果汇总，向客户汇报，真正让客户明确阶段性价值成果，感受到项目整体价值在逐渐形成，能感受到愿景的逐步落地。

结语

有没有发现，这几种沟通的目标和演讲的几种类型有点相像？