|
最近接触到一个项目。项目的原定计划是4个月交付，但是现在已经过了半年，项目的交付件大概才完成三分之一，而且交付的质量也不太理想。从项目成员陆陆续续的反馈中来看，有一些客观原因的存在，比如项目成员的变动，合作方的公司内部的一些配合问题，项目本来的难度，缺乏对口的专家支援等等。但是，我认为这个项目的管理问题应该是最大的问题：整个项目计划看不到，项目的交付件清单没有，项目的资料零零散散，双方合作的交流机制没有，甲方已经对项目比较失望。 事情已经到这个地步，已经发生过的也无法追溯了，我们还是回到业务流程上来看，怎么来做一个咨询项目的管理。 个人认为，要把一个咨询项目做顺，在做项目计划之前，其实有几个工作是需要投入的。不过做任何项目，我觉得这几个步骤都应该有，只是在公司内部做和以咨询顾问的身份介入，投入量会不一样。下面是一个简单的流程图（后面半段没有画）
把这几个活动展开看。其实每个都可以做一个小流程。比如收集资料可以扩展为： 具体来看每个活动。 第一个活动，资料收集计划：
第二个活动，资料收集。这是个体力活+脑力活，按照资料清单和计划去找相应的资料，该找甲方公司要的找甲方公司，该找公司同事支援的找公司同事，以及其他的所有渠道。当然，要把 第三个活动，资料整理。把收集到的资料按照一定的顺序归类存放。 第四个活动，资料收集跟踪管理。 有计划，就能保证一定能有效执行吗？不一定！所以执行的情况到底怎么样，得靠跟踪管理。如果跟踪管理没有做到位，再小的事情，再完美的计划，也可能是一个不好的结果。
行业分析，如果把行业分析做成一个小流程，我觉得应该是下面这个样子的： 也是从计划开始，然后执行，总结，过程中的跟踪管理。这几个活动的具体内容我就不展开了，和上面的资料收集的活动一样，每个活动中明确责任人，参与人员，活动的输入和输出，都是一样的套路。只是把这些活动怎么做深入，能够切实的指导后续的工作，我觉得这是就涉及到绩效牵引以及人员能力的内容了，放在以后的内容讨论。
如果在有的项目中，或则公司的实际业务中，行业分析这个活动没有必要做成一个小流程，或则内容确实比较简单，就用一个活动来说明也行。还是那句话，流程不是死的，是活的，要看制订流程的人怎么去考虑这件事，要看流程的设置到底是到哪种粒度更合适。活动形式的行业分析如下图： 最好能有分析报告的模板，这样大家的输出看起来比较统一，对新手也是一种实际的指导。 项目环境了解，项目组讨论，项目计划就不一一展开说明了，都是同样的道理，只是每个活动的具体内容，侧重点不一样，要根据活动的内容再做具体的规定。 重点来讲“项目跟踪管理”。我认为这是保证项目成功非常非常重要的一环。项目在刚开始的时候，大家都处于蜜月期，项目的节奏也没有那么快，很多问题都没法充分的暴露。但随着项目的推行，很多问题就会暴露出来，比如项目本身存在的技术难点，项目中成员的能力强弱差异，性格差异，都会造成项目的执行偏差。要怎么去解决这些已经出现的问题，去尽可能的规避风险，都是项目跟踪管理要做的事情。从这个项目来看，我认为项目跟踪管理的几个关键点： 1.项目进度的跟踪把握。判断项目目前处于什么阶段，进度延迟的原因，后续处理的方式。 2.项目成员的状态。能力欠缺的该怎么补齐，不好管理的成员，要怎样更换管理方式。 3.阶段风险的识别与备选方案。我觉得很多时候都是等项目真的遇到问题了，才去想怎么解决，这个时候其实已经有点滞后了，更多的时候要去对风险进行一个预估和备选方案的制定。 4.项目状态的上报。喜忧都要报！有时候项目经理害怕问题暴露导致领导的责备，有时候盲目乐观认为自己能hold住，结果往往出乎自己的预料，项目越到后面越失控。所以尽早的将问题暴露出去，请求必要的支援，是非常有必要的。你不说，老大怎么知道该怎么支持你呢？
好吧，回到这个项目的本身来说，如果项目经理能够按照这些流程活动来进行，是不是整个项目的结果会好一点呢？你们认为呢？
最后，我们再回到最开始的这一层流程设计来讲讲流程的设计的一个小细节。 第一层的泳道图开始是这样画的： 把它变一变我觉得可以改成这样：把项目组讨论拎出来，作为一个评审节点，把评审要素整理出来，这就变成了一个重要的项目节点。而且这样设计是不是也更加合理？ 从我的角度来讲，我认为大家一开始不要把流程就想得尽善尽美，一定要按照怎样的规范来做才能叫流程，其实不必要，真正重要的是把业务过程梳理清楚，先把第一步走出去，“从无到有”的这个过程一定要经历，才能够一个版本到一个版本的完善。
|
|
|
