项目管理杂谈样本.doc

资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。项目管理杂谈 文章有不妥之处, 请指教。 (1)项目管理说起来很复杂, 最关键的一点是控制。当然, 要实现有效的控制, 你需要事先明确很多东西。项目, 就是在有限的时间内, 有限的资源下, 完成一个明确的目标的过程。这些, 是作为一个项目经理必须要了解的, 也是每一个团队成员应当要了解的。同时, 沟通也是非常重要的, 没有对项目各个进程的明了, 要做到有效的控制, 就是天方夜谭。 控制的依据, 就是所作的项目计划, 计划应当是按照目标安排的, 并根据情况及时调整, 项目经理的职责就是协调手里的资源, 使项目进度按照计划完成( 说说容易做起来难) , 并在这一过程中, 实现资源的最优化配置, 使得项目能够在有限的时间内, 有限的资源下完成。从事项目管理工作, 其中酸甜苦辣滋味, 一言难尽。愿意在这里跟大家交流一下这些年的体会, 我想以杂谈的方式, 一次一个题目, 也希望大家多鼓励交流, 我也有点动力。 我不想讲太多理论, 毕竟非我所长, 而且项目管理是一门实践性非常强的学科, 这也是为什么认证考试都要求申请者要有几千小时的经验的原因。 能够这样说, 即使有人经过了认证考试, 而没有真正做过项目, 她决不会是一个合格的项目经理。 第一次, 就从项目的定义说起。所谓项目, 就是在有限的时间, 有限的资源内, 完成一个或一些特定目标的过程。( 不是从书上抄的, 可能会略有差异, 差不多吧) 。 先说目标, 明确的目标是一个项目能够成功实施的前提, 但在现实中目标的确定并不容易。在不同类型的项目中, 目标的确定各有不同。在工程项目里, 相对容易些, 有合同作为依据, 什麽时候完成, 完成什麽样算合格在合同里都有明确定义, ( 不要跟我说没有, 那就是另一回事了) , 这些都是硬性的, 基本上不能改, 那末项目的目标就很明确了。 可是在研发的项目中, 就不容易了, 首先, 客户经常并不知道她们到底要什麽( 记得上学时讲软件工程的老师讲过一个笑话就是这样的) , 因此结果就是在开发过程中她们不断在变主意, 这样就意味着项目的目标一直无法确定, 结果可想而知。因此说, 在进行软件研发的项目中, 目标的明确是非常重要的, 重要到经常近一半的时间是在做可行性研究, 确定目标, 而这一过程绝对必要。错误的目标会给项目带来极大伤害, 可能导致项目半途而废, 或是结束遥遥无期, 结果经常是不断降低对目标的要求, 以结束这一痛苦过程。相信大家会有这方面的体会。 再说时间, 一个项目必然要有时间要求, 对于工程项目特别如此, 而且经常是个硬指标, 没有时间限制的无限期项目是不可想象的, 不能称之为项目。 最后说到资源, 资源包括很多方面, 资金, 人力, 材料, 设备, 场地等等都是资源, 而资源也是有限的, 如何利用有限的资源完成项目, 是项目经理存在的一个重要原因。项目经理应当在项目开始前做好预算, 明确需要多少资源, 所谓巧妇难为无米之炊, 如果这一点无法由项目经理控制, 这个项目经理还是别当的好, 日子太难过了。时间与资源之间是有互动关系的, 在目标确定后, 一般情况下, 要想时间更短, 在单位时间内资源需要的更多, 但也不是无限的, 需要具体情况具体分析。 举例来说, 有些特定的项目( 经常是政治任务) , 时间是最重要的, 那就不能再考虑花多少钱, 要多少人, 必须完成, 才能在某天完成, 为。献礼。 另一例子, 几个人攒了个工作室要开发游戏, 人就这麽几个, 机器就这麽几台, 只能以时间为代价了, 要是目标再不明确, 时间就更长了, 这样的例子比比皆是, 不再多说。 关于目标补充一句, 目标是否定义合适有一个简单的衡量标准, 简称SMART, 含义如下, S-specific M-measurable A-accepted R-realistic T-time based (2)一般来说, 项目能够分为四个阶段, 准备立项, 可行性研究, 执行, 总结。 这里有个概念, 称为TOLLGATE, 我一直不知道该怎没翻译这个词, 原意是关口, 收费站等。 每一个阶段结束时都有一个TOLLGATE, 目的是进行分析总结, 是否将项目进行下去, 在这一过程中项目组的职责是提供相关的信息和数据, 以及分析, 预测等, 供决策参考, 而是否进行下去的决定权在于STEERING GROUP, 大概是指项目的资助者及监督者, 这个概念以后还会提到。 准备立项, 没什么好说的, 就是有个意向, 准备要搞个项目, 关于目标, 时间, 预算有个大概的想法。 可行性研究, 在这一阶段要做的事很多, 如确定项目目标, 作出预算, 时间表, 所需资源预测, 风险分析, 应对手段等等。前文曾经提及, 这一阶段非常重要, 毫不夸张的说, 这时候把工作做好, 项目就成功了一半。 在研发的项目中, 一般不会省略这一步, 虽然有时做的很不够。但在工程项目里, 特别是扩容的工程中, 常常会忽略其中某些必要的环节。 我第一次接手一个特大型项目时, 有过这样的教训。当时我们准备给一个省的客户做系统扩容, 涉及合同金额大约有一亿多美元, 习惯上在合同谈判时( 从项目管理角度来说, 能够视为可行性研究的重要部分) 项目经理介入不多, 特别是关于设备采购数量, 合同签了, 第一次与客户研究技术实施方案时, 问题发生了。 问题能够这样描述, 客户原有1套系统在用, 扩容到2套, 为了节省投资, 里面涉及到很多系统设备的利旧, 由于没有经验, 设备定购时考虑数量只是单纯的用扩容后的规模减去现有数量, 但事实上在施工过程中必然存在这样一种状态, 新的系统建成后, 才能把在用系统的用户割接到新系统上, 旧系统的一部分才能拆下来。而按照合同里的设备采购情况, 只能把旧系统停下来, 把设备拆下, 再和定购的新设备一起组成新系统, 由于客户所处的行业, 系统运行决不能停, 记得当时我的冷汗一下子就下来了, 这个问题如果不能解决, 我们就得向用户免费提供一套系统供周转, 那对公司将造成极大损失。 后来我们与客户一起苦干了两星期, 终于拿出了一份可行的技术方案, 代价是工作量是原计划的3倍, 而时间比原计划晚了4周, 我运气不错, 总是解决了, 这很有可能是个解不开的死结的, 不是每一次都能这样幸运的。 在又一次的扩容前, 在我的坚持下, 技术谈判时我们就开始介入, 在合同签署之前, 我与公司的技术人员以就所有可能的发生的问题拟定了解决方案, 虽然新的扩容规模大了几倍, 比前期复杂了很多, 实施时却很顺利。 执行, 简单的说就是按照在前一阶段制定的计划控制监督项目进展, 直至完成。 总结, 项目执行完后, 对项目的回顾和总结。这一阶段很重要, 但容易让人忽略, 很多人都认为干都干完了, 也还不错, 有什麽必要写这些长篇大论。 即使在我们这样的国际化大公司, 一样如此, 我每次写的FINAL REPORT就基本上没人看, 更别说提意见了。事实上, 对项目各方面的回顾, 如预算, 时间表, 人力资源, 风险分析等, 对下次的项目执行有非常重要的意义。记得刚进公司时做工程, 办公室里贴着这样一句话, Remeber ,you have not finished the work until you finish the paper work. (3)谢谢SPRING的鼓励, 就你提出的问题, 这涉及到项目的计划, 我是准备作为一个专题以后要讲到的, 这里我简单说几句。首先澄清一个观点, 从理论上来说, 项目经理和项目所涉及的专业完全没有关系, 即使对相关专业一窍不通, 仍能够进行项目管理。从我的经验来说, 这个说法不错, 但在实际工作中, 具备一定的专业背景是非常有帮助的, 能够节省很多时间, 避免一些不必要的风险。记得我的一个师傅( 我有过四个师傅 , 一个马来西亚华人, 一个挪威人, 一个芬兰人, 一个英国人, 跟她们共事很有意思, 以后再讲) 曾经说过, 你不知道并不可怕, 可怕的是你不知道你不知道! 而对所涉及专业的不了解, 就意味着你不知道你不知道, 就意味着你无从知道 有可能存在的危险。那末怎没才能知道哪? 只有实践, 在第一次的实践中要多问, 弯路是肯定要走的, 时间也会多花, 这个代价是值得的。同时, 对项目经理的要求也不会太高, 能满足你知道你不知道就足够了, 毕竟很多专业问题应当由技术人员去解决, 而不是项目经理, 你所要做的就是当问题出现时, 知道属于哪一类的问题, 该由谁来负责, 就足够了。 否则的话, 以做个游戏为例, 就要求一个人既要做策划, 又要做引擎, 还要做美工, 音乐, 可能有这样的天才, 我是没怎么见过。至于另一个问题, 仍是由目标开始, 先明确要做的产品, 性能, 外观, 成本等等, 再把要做的工作逐步细化, 并对每一项进行时间和资源的量化, 即使对没做过的也要如此, 不准确能够及时调整, 但从一开始就要有个预计的数字, 而这一部分, 理所当然在风险分析中应当占据很大比重。 只能简单说到这里, 能够给我发MAIL, 提供更详细的情况, 希望能给你更多帮助。另外提一句, 我发现这里很多求助的人 的问题太抽象, 拿这个做题目能够写本书了, 很难在这里回答, 因此, 越具体越好。言归正传, 下面说说项目的组织。 说到组织结构, 能够分为两种, 一种称为 LINE ORGANIZATION, 一种称为PROJECT ORGANIZATION, 它们有着本质的区别。 LINE ORGANIZATION一般是按职能划分的, 较稳定, 长期存在, 我们常称其为 RESOURCE POOL, 为项目提供所需人力资源; 而PROJECT ORGANIZATION是按项目划分的, 因项目而生, 随项目结束而解散, 人员来自不同的LINE ORGANIZATION, 为同一个项目而聚会到一起, 而项目经理, 就是这个临时团队的领导者。 在一个项目组织里, 能够分为三个层次, 第一层, 是项目的资助者, 我们称其为 STEERING GROUP, 职责是负责批准项目的立项, 提供项目所需资金, 在每一个 TOLLGATE 时审查项目经理的报告, 决定项目是否继续, 同时也是定期的项目进度报告的接收者。 第二层, 是项目管理层, 包括项目经理, 助理项目经理, 可能的话, 还有对各个部门的协调人, 这个集体由项目经理领导, 负责整个项目的协调, 控制, 进度, 报告, 同时也是对客户( 如果有的话) 的主要接口。 第三层, 是由各部门参与项目的人员构成的项目组成员, 由各职能部门的不同, 负责项目中的不同部分, 做具体工作。她们 应当按项目计划要求完成自己的任务, 并有义务对项目经理定期报告所负责领域的进展情况, 提醒项目经理可能存在的问题。 值得一提的是, 这个结构只是个大概的轮廓, 由于项目的不同, 会有很多变化, 但从逻辑上来说, 都应有这三个层次的存在。 对于很小的项目, 有可能第一, 第二层合二为一, 对于大型项目, 会有更多的层次存在, 比如说, 对于每一个参与项目的职能部门, 她们的任务也是一个项目, 那末其协调人就是一个子项目的项目经理, 依此类推。在这种情况下, 结构一定要在事先 明确, 以避免在进行中的职责, 权利不明, 沟通渠道不畅。 (4)项目管理是一项主要与人打交道的工作, 与人打交道是最难的, 这样领导能力就成为项目经理的必须。 LEADERSHIP, 我将其称为领导艺术, 是一门专门的学问, 我没有时间, 也没有能力在这里专门讲述, 希望每一个项目经理 都有机会能参加这方面的培训, 至少要找本书自己读读, 在这里我只提跟项目管理直接相关的几个方面, 以理解在项目管理中 领导艺术的重要性。 先说说团队合作, 一个项目组织就是一个团队, 而项目经理就是这个临时团队的领导者。是团队就必然要经历团队的几个过程, 初创期, 磨合期, 生产期, 结束期。一个项目成立, 成员来自不同的部门, 彼此或认识或不认识, 对于大多数人来说是不熟悉的, 接着开始干活, 慢慢的彼此熟悉, 其间会有冲突, 争论, 甚至争夺领导权, 自然而然某些人在团队里成为大家信赖的人, 建立起领导权威, 大家逐渐熟悉了对方的工作方式, 建立了相互信任, 工作效率明显提高, 然后, 大家已成为配合默契的伙伴, 一切都在井然有序的高速运转, 效率达到最高, 终于有一天, 项目结束了, 团队解散, 大家回到各自部门。 好的项目经理能够使前两个阶段尽量缩短, 使整个团队迅速进入第三个阶段, 而做到这一点并不容易。一个经验丰富的项目经理在团队成立之初, 经过项目目标的确定, 项目的范围, 各个相关部门的责任等讨论及定案的过程中, 就能够树立自己的威信, 建立起团队成员对自己的信任。 再说一下对自己下属的领导, 在这里举两个例子。 在一个省内扩容项目中, 我有3个助理, 同时还有3个工程项目经理作为工程公司的接口, 工作范围大概是按照地区划分的, 我对我的助理们的工作一般不过问, 除了定期的报告, 她们主动来找我请示外, 一般不介入她们的具体工作。原因有几个, 一是在我到任之前, 她们都已经至少做过一年的助理了; 二是考虑到我将来总要离开, 她们要作为项目经理而独立工作, 我有意不作具体的介入; 三是她们的年龄都比我大, 总要给人留几分面子。终于有一次出了问题, 一个工程师到了现场, 发现有些设备未到, 打了报告给工程项目经理, 工程项目经理报告给了我的负责该地区的助理, 她告诉了我, 这一地区的 后续工作因此推迟。而实际上, 在工程师发现缺货两天后, 她发现这是一个由于自己经验不足产生的错误, 她没有撤回自己的报告, 只是打了个电话给工程项目经理, 工程项目经理转头就把这个事情给忘了, 因此在我的记录里, 这里一直不能进行 后续工作直到我们发现了这个错误, 结果是工期推迟了一个月。作为项目的总负责人, 我当然要为此负责任, 而我的错误不在于没发现这个问题, 而在于对于我的这个助理用错了领导方式。 对于下属的领导方式能够分为四种, 第一种称为教练, 对于新手来说, 你需要告诉她每一件事该怎没做, 有时还要自己做示范; 第二种称为后座驾驶, 意即坐在司机后面告诉她怎麽开( 我最讨厌的方式) ; 第三种, 对不起, 忘了, 大概是只用简单指导; 第四种是只交代任务即可。我自己习惯的是最后一种, 对助理们大概是第三种, 而实际上因人而异, 对其中两个能够, 对这一个 , 不行。现在想想, 我当时才到那里两个月, 还谈不上对她们有多了解, 就敢如此, 只有一个给我惹祸, 运气还是不错的。 还有一次, 是项目组里的货运协调, 那是一个年轻的女孩, 性格活泼, 讨人喜欢, 和我平时关系不错。有一次, 她犯了一个 明显的错误, 她把报告交给我时让我发现了, 当着别人的面我指了出来, 还开了几句玩笑, 当时她脸就红了, 下班时约我去吃饭, 然后很严肃的对我说, 下次能不能私下告诉她, 我当即意识到我犯了个错误。当众表扬, 私下批评, 永远是正确地。 说到这里, 忍不住想说几句项目经理的素质要求, 有一个笑话, 是我的一个师傅讲的, ”有一个项目经理休假出去玩, 把身上的 东西不小心都丢了, 天晚了, 无奈下找个农家求助, 老大爷说住下能够, 但要她帮忙干活, 先是铲粪, 一会就干完了, 然后让她挑土豆, 大的一边, 小的一边, 挑了一夜, 一个也没挑出来”, 讽刺当项目经理的非常善于把责任推给别人( put shit to others),但永远不会做决定。 由于项目经理工作的性质, 她永远不会做什么具体的工作( 理论上) , 因此一个不负责任的项目经理总能找到借口把责任推给负责 具体工作的人, 如果这样的一个人作为团队的领导者, 能够想象项目成员们的感受。一个优秀的项目经理必然具备以下几种特点, 勇于承担责任, 敢于下决定, 责任心强, 工作细致, 坚韧不拔( 在巨大的压力下能保持镇定, 领导团队前进) 。 关于项目经理应该具备的素质, 感觉还有很多东西能够讲, 以后有机会再说。需要说明的是, 素质和知识, 经验无关, 而是和个人 的性格, 品德修养有关, 一个经验丰富的项目经理同样可能是个不负责任的人, 每到关键时刻总是把自己摘得干干净净。( 我的一个师傅就是如此, 正好给我做了反面教材) (5)项目的计划 项目的计划应当在第二阶段进行, 其重要性就不再强调了。在项目的目标确定后, 经过项目的计划能够确定项目的时间表, 所需资源, 成本, 以及主要风险等重要内容。 举例来说, 以做一把椅子为例, 目标是一把木质的椅子, 有扶手, 刷红漆。 工作细化后, 能够发现, 有这样一些工作要做( 是我想当然的, 我可没做过椅子) : 1, 打出椅面, 椅腿, 靠背, 扶手; 2, 刷清漆; 3, 晾干; 4, 装配; 5, 刷红漆; 6, 晾干。 再进一步细化, 把所需时间加进去, 得到下面的表格, 制作 刷漆 晾干椅面 4 1 2 椅腿 1 0.5 0.5 靠背 2 1.5 1 扶手 1.5 1 1 装配需要2小时, 椅腿是4个, 扶手是2个。考虑先后次序, 显然制作之后才能刷漆, 晾干后才能装配, 然后才能上红漆( 2) , 最后再晾干( 2) , 完成。 制成图表后会发现, 在人力充分的情况下, 所有工作在可能的前提下都能够同时进行, 最长的一条线是制作椅面刷漆晾干装配。 总共需要41222213个小时, 这就是全部完成所需的最短时间, 我们称其为关键路径( Critical Path)。关键路径的意义在于, 在关键路径上的任何工作如果被延误, 整个项目的完成将会延误, 不论其它工作做的再好也没有用。因此在关键路径上的工作的风险要引起高度重视, 因为对全局有重大影响。 再考虑如果人力不足时, 比如说只有3个人, 制作不能同时进行, 怎么分配人力? 分析后能够发现, 让1个人负责靠背和扶手是最省时间的, 这时关键 路径改变了, 所需总时间增加为16.5小时。 上面考虑的是比较简单的情况, 假设一个工人既能够干木活, 也能够油漆, 考虑到不同工种, 每个工种的人力情况, 会更复杂, 但原理是一样的。 实际工作中项目会复杂得多, 可是能够依照这个原则来做, 首先确立项目目标, 然后将工作逐步细化, 给每个工作一个预测的时间值, 找到关键路径, 根据现有人力资源情况进行调整, 重新确定关键路径, 得到总的时间表, 所需总的劳动时间( 可据此做预算) , 主要风险, 相应对策。 很多时候, 最困难的是将工作细化, 特别是项目经理对项目涉及的技术不了解的时候, 我的办法是把所有的相关部门经理们召集起来, 让她们说, 她们 都需要做些什麽来完成任务, 你会发现这象是一个网络, 左边的起点是你的项目成立, 右边的终点是项目的目标, 部门经理们告诉你的每个任务是网络 的节点, 它们之间的关系是网络的连线, 而每个任务所需的时间和资源是连线的权值。一旦你将这个网络正确的建立起来, 剩下的只是时间问题。 项目计划的另一主要部分是项目的风险分析。 首先要做的是把所有有可能发生的风险全部列出来, 然后依据它们发生的几率和对项目的影响赋予一定的值, 举个例子, 用5代表最高, 1代表最底, 货物晚到的几率是5, 而对工程影响也是5, 相乘后这一风险的值是25; 人员短缺的几率是3, 影响也是5, 相乘后是15。依此类推, 你会得到一张表, 而表内所有结果是25的, 作为项目经理, 必须要采取行动, 如果此时不予理睬, 到时候你就等着倒霉吧! (6)项目的财务管理 对项目而言, 与其说是财务管理, 不如说是成本管理, 或是成本控制。说复杂也复杂, 说简单其实就是省钱, 但省在什没地方, 怎麽省, 就是学问了。 就我的经验, 有几个原则是一定要遵守的。 首先, 不能为省钱而省, 不能本末倒置。项目, 就是在一定时间, 一定的预算内完成特定的任务。这一点一定要记住, 完成任务是最重要的, 如果因为成本问题影响了最终目标的达成, 就是本末倒置, 一般会导致项目的失败。同时时间也是一个极具约束力的因素, 很多时候项目的时间要求很紧, 压力很重, 解决的办法一般是要求更多的资源, 即意味着成本增加, 这是必须付出的代价。举个例子, 前段时间我们拿到了一个合同, 是在一个我们 新进入的业务范围, 对于我们来说, 把项目按质量要求按时完成是最重要的, 因为要靠这个项目坚定客户对我们在这一领域业务能力的信心, 不能给 竞争对手任何口实把我们从好不容易进入的这一市场赶出去, 因此这个时候, 花多少钱就是次要的了, 只要我们在这个新市场站稳脚跟, 花多少代价 都是值得的。因此说, 该省的钱要省, 该花的一定要花, 一切以目标为重。 其次, 一个事先经过充分准备制作的预算是非常重要的。因为预算实际上是一个衡量标准, 一个藉以实行成本控制的依据。 这里有一个关于预算的概念需要澄清, 我认为预算是要完成一个特定任务所需要的成本。一般会有两种误解, 一是认为项目结束时实际开销比预算越低越好, 显得项目经理管理水平高, 给公司省了更多的钱, 错误! 要做到这一点并不难, 做预算时做得高高得就是了, 实际上能把预算和最后得实际开销做得几乎相差无几, 非常准确的才是一个有经验的项目经理, 而事实上要做到这一点非常不容易, 因为项目中总会有意外情况发生, 是项目经理无法预测, 也就无法做进预算里的; 还有一个就是误以为预算就是合同里相关部分的报价, 错误! 你做这件事花多少钱和客户为此付多少钱绝对是两回事! 任务定了, 真正的所需开销就已经在那里了, 你可能需要一百万来做, 但销售人员把这部分卖两百万, 还是免费送给客户与你无关, 那是她们需要从其它角度需要考虑的, 你要做的就是要来一百万做你的项目而已。 预算怎麽做, 也是一个很复杂的问题, 个人认为, 当前没有一个完美的办法。从前我们是这样做的, 把可能要做的所有工作细化, 比如说现场勘查, 需要一个 人, 做8个小时, 旅行时间来回4小时, 共12小时。这样每一项工作都有一个时间的权值, 而每一个工时, 都有一个费率, 费率的制定是由相应的部门确定的。 举例来说, 部门A, 总共12个人, 一年总开销为一百万( 包括一切, 房租, 家具, 水电, 培训, 薪水。) , 其中有10个工程师, 每个人每年工作 小时, 那末她们的费率就是1000000/10/ =50,而部门B因为技术性更强, 同样人数一年开销2百万, 那末她们的费率就是100。这样做预算的好处是很容易, 我们有个软件, 把基本数据输入, 一下就算好了, 自己在根据实际情况编辑修正一下就差不多了, 坏处是难以控制, 工程部门是按工程师花在项目上的时间来找我要钱的, 这样就产生了一个怪现象。一个预计花100小时的工作, 一个出众的工程师50小时就完成了, 而一个新手可能要150小时, 而对于她们部门来说, 这个新手的贡献是老手的3倍, SHIT! 你要是老板你用谁? 答案是显而易见的, 而我就惨了, 花钱多不说, 进度还慢, 而我无从知道这延误的50小时是因为 出了困难情况还是在现场的是个笨蛋! 我经常在月末收到工程部门的时间报告后和她们打架, 为这个得罪了很多部门经理。 后来老板们也发现这样有问题, 改成了特定的任务一个固定打包的价格, 这样做我无须再控制, 反正就这麽多, 但有另外一个问题存在, 就是如何界定工作的范围。这样做以后经理们经常来找我, 说这个那个不在范围之内, 要求加钱, 一样让我头痛。当前能做的只能是以前一个方法为依据做固定价格, 尽量细化工作范围, 同时手里留一部分预算, 留作真有意外发生时追加用。 最后就是抓住成本的主要方面, 严格控制。对于我做过的大部分项目来说, 主要部分在两个方面, 一个是硬件, 一个是人力成本。 有一个例子, 我接手一个大项目时, 鉴于前一期的经验, 加强了对损坏部件更换的控制, 效果是惊人的。前一期合同额约5000多万美元, 这部分的开销按 LIST PRICE算达400万美元之巨, 而这一期合同额约1亿1千万美元, 控制后的结果是不到50万美元。( 可惜没人给我发奖金, 让我倍感挫折) 另一个例子是关于人力成本控制的。一般情况下, 把一些简单工作外包是个好主意。以设备的清点为例, 以前是自己的工程师做, 后来包给客户指定的清关公司, 一箱货付5元, 总共不到1万元, 而我们自己的工程师来做, 我得花几十倍得代价( 在按工时付费的模式时) , 而工程师们也很不愿意, 觉得让她们干这种活简直是在侮辱她们。 另一个需要注意的是客户的额外需求。客户经常在项目中间提出这样或那样的要求, 我一般根据合同判断, 是否是我们的义务, 如果不是, 需要向老板们 汇报, 要求追加预算, 而且应该让客户承诺如何作出补偿。额外的要求总是伴随着预算之外的硬件和人力资源要求, 且常常会影响计划的顺利进行。 最好的方法是不让它发生, 在计划阶段做好工作, 不给客户机会提出额外需求。 个人的精力毕竟有限, 把主要方面抓住, 其它就无所谓了。在我管的项目里, 这两方面的比重加起来一般在整个预算的95以上, 只要把这两方面控制好, 足够了。因此我从来不论助理们请客户吃饭HAPPY花了多少钱, 闭着眼睛签字, 实在是毛毛雨啦! (7)项目的执行 项目的执行无疑是项目管理中非常重要的一个阶段, 从合同签订或项目计划任务书批准开始, 到整个项目结束都是项目的执行期。 对于工程项目来说, 主要是到PAC( 初验) 为止。项目经理在这一阶段的主要职责就是依照确定的计划监督项目的执行, 并根据具体情况对计划随时做调整, 以适应实际情况的需要, 协调各方面的资源, 保证项目能够按时按质完成。 就本阶段而言, 经验是非常重要的, 而且与项目经理的个人能力有很大关系, 这个能力一般是指在压力下解决问题的能力。对于从未经历过这一阶段的人来说, 项目的执行很难解释, 我个人认为, 有几个要点一定要时刻铭记在心, 也可称为原则吧。 第一条, 永远不会有一个项目没有意外; 就是说不论在做计划时有多认真, 多全面, 总会有一些事情你预见不到, 或是没有充分估计其危害程度, 认真的计划会减少问题的发生, 但不大可能完全避免, 因此总会有问题出现, 需要你去解决, 这也是项目经理在项目执行阶段存在的意义。认识到这一点很有用, 它能帮助你保持平静的心态, 同时经过你的表现稳定团队的情绪, 并能够积极的去解决问题, 毕竟问题总会有的, 某种意义上来说, 你应当感谢它, 若没有 问题的出现, 项目经理的存在就没有了价值, 你也就没了这份差使。 第二条, 充分理解合同中的相关部分, 如果没有合同, 就把项目计划任务书作为目标, 要是项目计划任务书都没有, 且住, 你还有工作没做完, 不能开始执行! 理解项目的目标, 要做的工作, 工作的范围, 你所拥有的权限等等, 这样在遇到问题时, 你能够迅速判断问题的性质, 是能够你自己解决的, 还是必须要报告。 刚开始做项目时, 有过一次给别人”擦屁股”的经历, 有经验的人都知道, 这种事时最讨厌的, 因为当时的记录, 经手人都可能不存在了, 问题处理起来很棘手。 当时的问题是用户抱怨很多材料短缺, 致使部分系统不能满负荷工作, 因此拒绝初验。与公司内当时经办人查询, 原因是材料没有按照要求包装, 导致使用时管理混乱, 且没有任何原始记录可供查询, 我只好带着工程师把所有站点跑了一遍, 把现场情况全部登记了, 给客户补足了所有短缺的材料, 耗时6个月, 材料费几百万。得到的经验是, 材料一定要按照要求包装运输, 工程中的文字记录必不可少, 不能图省事。还有一个收获是, 凡是不能明确是谁的责任时, 就是你的责任, 如果想要客户负责任, 能够, 拿出证据来。 另外一次, 在项目中发现少订了几千米电缆, 经与设计工程师核对, 她承认是个错误, 恰好客户有该型号的电缆, 向领导请示后, 买了几千米解决问题。 花了一万多。 这两个例子要说明的是, 需不需要报告不取决于要花多少钱! 第三条, 抓住关键路径; 当资源发生短缺时, 首先保证关键路径上的节点所需资源, 保证整体项目时间表的进度。 有过这样的情况, 两个地方, A和B, 都需要同样的材料, 管A的项目经理较有经验, 提前预定了一批, 而B没有, 但B在关键路径上, 材料给谁? B! 但显然的, A的项目经理将获得较高的评价。 (8)项目的结束与项目的文档 项目初验后, 一般有一段时间的试运行, 3到6个月不等, 然后是终验, 终验意味着项目的结束, 项目组解散, 成员们回到各自的部门, 等待着下一个项目 的到来。项目经理的最后一项工作是总结报告( 下面会提到) , 之后项目经理同样回到自己的部门里, 一般会去休假, 然后等待下一次的挑战。 项目管理中涉及到的文档很多, 最重要的我认为是项目任务计划书, 定时的进度报告, 和总结报告。 首先谈谈项目任务计划书, 这能够说是重中之重。它的对象是全体项目组成员, steering group的成员, 并一般会抄送给相关部门经理们, 由项目经理 完成。 内容由几方面构成: 1, 项目的背景资料, 客户, 市场方面, 与竞争对手比较, 与其它项目关系等等; 2, 项目的目标; 3, 项目的范围, 实施内容, 具体任务等; 4, 时间表, Toll gate,mile stoned 的定义; 5, 预算; 6, 项目的组织, 各自的责任与权力划分; 7, 项目的管理原则, 如定期报告制度, 相关部门间接口的定义, 质量保证体系等; 8, 风险分析及解决措施; 9, 附件( 如合同或协议中的相关部分, 有关技术文件等) 。 其次是定期进度报告, 时间根据具体项目而定, 每月一次, 每周一次, 最紧张的时候甚至每天一次, 内容相对简单, 主要是5个部分: 上次报告以来的进展; 预计下次报告前的进展; 当前的困难( 也就是风险) ; 解决方案, 当前开销与预算的比较。 最后是总结报告, 主要应当是根据项目的实际进展情况, 与项目任务计划书比较, 对项目的时间计划, 预算, 风险分析等方面的回顾总结, 并据此对 下次的项目计划提出修正意见, 同时也应就项目执行中发现的内部管理问题向公司管理层提出改进建议。 (9)结束语 今天把旧文翻出来又看了一遍, 实在有点汗颜, 感觉比较乱, 逻辑关系不清楚, 有点想到哪是那的意思, 很多想说的话还没有提到, 而且没头没尾的, 有愧于鼓励我的读者们, 最近又很忙, 只好先这样凑合作为结束了, 正在读一个管理方面的学位, 可能读完以后能够站在更高的角度再整理一下, 希望如此吧。 前面的内容里很少专门提到理论问题, 在结束的时候我想说, 其实理论还是很重要的, 书本上的东西不但要学, 还要记住, 这样当你在实践中每一次遭遇困难, 撞的头破血流后反思现实与理想的差距时才能有所感悟, 才能真正有所收获, 从而不断进步。 最后在这里祝大家工作顺利, 如果看了我的文字后能对大家的工作有小小帮助, 将是我最大的欣慰。