×

扫描二维码登录本站

ISO20000广破论(2) ---破子  

标签: 暂无标签
                                       



项目管理是决定ISO20000项目核心的一个因素,如果按重要次序排列,它应置于第一位,它比你懂不懂ISO20000更重要,项目管理在企业管理与工作之中所占据的位置会越来越重要,一个优秀的现代工作者应该具备起码的项目管理意识,一个优秀的管理者应该是一个合格的项目经理,为了交流的便利,这里对项目管理的基本概念做一个介绍:

什么是项目
项目是为完成一个或多个特定的目标而进行一次性的任务。项目有明确的起点与终点,它是一次性的,它的目标是特定的,它的结果是不可逆转的,它是有成本约束的。所以按这种定义,我们日常工作与生活中许多事务可以定义成项目,比如完成一次培训,让学员理解接受此次培训课程的内容,这是目标,但是不是理解这难以量化,所以我们采用考试测验的方法,设计一套考核试卷,目标即可定义为考核及格率为100%,为了做这个培训,需要做许多子任务,比如要做培训教材,要做培训试卷,要寻找培训场地,找培训讲师,组织所有学员培训,最后组织考核与做培训满意度调查,这些都是项目的活动,需要有一个计划把它组织起来,按一定的逻辑次序进行进间安排,比如培训教材没有设计出来之前,不可能做培训试卷,培训讲师没有确定之前,不可能组织培训,要寻找不同活动之间的逻辑关联,按时间把它们安排好,这就是项目计划,项目计划非常重要,以这个例子而言,如果做得比较严谨的话,培训场点的设备测试(投影仪、电脑、扩音投备、网络连接)这些活动都要考虑好,甚至要考虑到某个设备如果作业时环了,怎么办,等等这些,每个子任务要明确由谁负责,整个培训的任务由谁负责,这就形成了一个项目体制。按照这种理念,一次婚礼的举办、一个公司的开业、一次旅行、一场音乐会、一场战争这些都是一个项目,如果我们想有质量有保障的完成这些事情,一定会用的项目管理的某些方法,有人可能说,我不懂什么项目管理,但这些事情一样可以做得好,其实你认真去分析做这些事情的过程,它一定契合项目管理的一些方法,只是我们没有意识项目管理这个名词罢了,这有些象金刚经中所说的“所言一切法者,即非一切法,是故名一切法”的道理。一个任务分解越多、时程越长、涉及人员越多的项目越需要项目管理,这二者成正比。

什么是项目管理
项目管理是在有限的资源约束下,对项目范围内的全部工作进行有效地组织,以保障其达成项目目标的一系列方法与理论。项目管理的活动是非生产性的,它包括对生产性事务的管理、质量的管理、风险的管理、计划的管理、配置的管理、绩效的管理等等,这是按管理属性进行大致分类,项目管理主要由项目经理负责,当项目极其复杂时,可能将项目经理可能会设立一些项目管理角色将某些项目管理活动分担下去,甚至有可能将一个大项目分拆成若干个小项目,进行分头管理,说到底,所以项目管理并没有一个硬性的模式,当前有许多项目管理的书籍与课程在介绍这方面的知识,这些知识只是一个一个的工具而已,如何去采用哪几种工具或组装不同的工具在一起为项目所用,这需要项目经理的智慧,当前的网络发展,各式各样的知识信息随手可取,对以前的人类而言,信息的获取最为困难的,需要花费巨大的时间去记忆记录,而现在的人类最为困难是信息的分析与应用,由于搜索引擎的越来越先进,网络接入方式越来越便利,这对人类的学习模式与大脑运作机制带来根本的影响,博学已经没有太多意义,你再博学也不会超过1GB的硬盘,当机器占领了这个领域,人类将永远退居二线,在各种自相矛盾的管理逻辑之内,找到适于此时此景的解决之道,这需要智慧,一个当前世界顶尖的项目管理方法的理论专家可能管理不好一个小项目,一个完全不知项目管理为物的26岁的拿破仑可以攻克意大利,所以不能脱离人与场景的情况下去唯方法论,一个优秀的管理者必定在管理一个项目时更有得心应手,一个优秀的项目管理者必定在管理时也更有心得,项目管理与管理的本质是大部份是同通的,但在我们大多数人并不是天才的情况下,熟知一些基本的项目管理方法与知识,有益无害,会让我们真正从事项目管理或做其它事务时更加效率。

项目经理的选择
对于ISO20000这种项目而言,项目经理的挑选至关重要,我的观点是,对于一个ISO20000的项目经理而言,项目管理意识与经验比ISO20000的知识更为重要,以下的是我认为几个比较重要的素质要求:

聪明些的大脑
找一个聪明些的脑袋比什么都重要,它会让许多复杂的事情变得简单而容易,虽然现在的工作者基本上是受过正统的教育与检验的,但在你跟周围的人的每一次交流、会议、报告、工作接触、材料阅读中,你还是会发现有一些人比其它人更能展示出清晰的思路和某种敏锐,它可能是先天也可能是后天的,发掘出来这种人出来,让他做更多的事情,承担更多的责任,会省很多事,这也是为什么一些IT公司寻找最聪明的人的原因,这里指的聪明不是指IQ或学历的最终结果,而是对事物能迅速、灵活、正确地理解和解决的能力,即趋于智慧。在项目过程中需要不断的学习新东西,理解、分析、判断当前的情况,做出合理的干预措施,包括以下所说的各种要求,无一不是以一个聪慧的大脑紧密相关的,不够聪明的大脑容易做出糟糕的决策,糟糕的决策容易把项目拖入不可控制的困境,要让有利条件最大化,才能让成功概率最大化中,才能让项目成本最小化。

进取型的性格
管理过项目的人有一种心理经验,从项目开始团队初成的情绪高涨、到开始慢慢的问题越来越多,心中开始产生焦虑,然后会出现比较严重的困难,似乎已无力挣脱泥潭,此时整个项目位于最低点也最关键点,内部的项目成员位于情绪的最低点,各种负面情绪接连而至,怀疑的声音越来越多,最后来自到项目外围的领导层的压力也越来越大,然后项目经理焦头烂额的想办法化解,渐渐豁然开朗,到项目后期时,一切又越来越趋于控制之内,各方的情绪又随之拔高,到最后项目结束的喜悦时,大多数甚至不记得在项目最困难时的那种负面的情绪了,而项目经理在想起以前某个项目时,第一反应更多是做那个项目时那种心理起伏的感觉。性格的特质对于项目经理也特别重要,项目某种层面就是一堆接着一堆的问题的集合,或者说那就是一团乱缠在一起的网线,不是网络的网,而鱼网的网,项目经理要做的就是解开它。一个性格不强健的人容易在困难出现的时候陷入消极应对,在遭受指责与批评时进行无谓的对抗,这都会置项目于不利的地步,进取型的人的目标性较强,这使得过程中的困难、障碍、矛盾不会成为太大的干扰,项目经理就得把项目扛在肩上,连爬带滚的冲向终点,而不是碰到困境时,把沙包丢掉自己先逃或推卸责任由别人顶包,要有迎面问题的进取心。

管理能力
一个广义的管理能力定义基本包括前后所说的所有要素了,这里说的管理能力只是相对狭义的,更多是指方法与技巧层面的,对于管理能力的定义很多:比如在国家的通用标准中是指四个模块:自我发展管理,团队建设管理,资源使用管理,运营绩效管理。针对具体的方法技能则是指:

设计能力:制订组织架构、流程、规则、方法、产出的能力

组织能力:将资源(人、物资、资金、时间)进行分配、组合、以使其按预期既定的模式运作的能力。

计划能力:对一个复杂的任务进行无遗漏的逻辑分解、并在时间上进行前后排序作业设计的能力。

控制能力:围绕已有的计划、目标、约束对作业进程进行检查、调整、改进施加影响的能力。

授权分工能力:根据任务的属性以及成员的属性,对两者进行最优组合的能力

分析决策能力

分析能力是根据信息对客体的正确判断的能力,决策能力是指在合适的时间完成合理的决定的能力。管理的核心在于分析与控制,没有分析就没有决策,没有决策就没有控制,分析能力确定当前的方位,能够指出通过最终目的可能路线,决策能力需要挑选出一个最佳路线,一个管理者没有良好的分析能力就如一个司机没有方向感,这样就没有办法到达目的地,或者没有办法效率的达到目的地,缺乏良好的分析能力将使一切变得艰难,无法对当前的情况做出正确的判断,甚至不知道要进行判断,这样就容易造成在最需要[url=]干预[/url]的时机没有做进行干预或没有进行正确的干预。谈到分析能力人们第一反应就浮现一大堆的数据报表,这是对分析能力的局限,大多数场景是没有数据这样明确量化的参考的,当我们看一张漂亮的脸孔时,这其实就是一种分析,我们在很短的时间就分析认为这张脸是漂亮的,只是分析动作太快了我们就不觉得它是分析,当我们觉得现在公司管理情况很不好时,这其实也是一种分析,只是这个分析过程非常内在化,这两个例子中我们一下子没有办法去理解这个分析的模型而已,所以某种程度上这些其实也是一种运算,当一个运算非常复杂而迅速时,我们会觉得它很“自然”,它是“人性”的,它不是机械式的,而是天然存在的,这时我们理解不了也觉察不到它的运算分析过程,如果我们哪一天可以理解了,那么人工智能的时代将会到来,这种瞬间的分析能力是人类最大的进化结果。
从更抽象的层而来说,分析能力的优劣则是每个人的计算模型与速度造就的,而每个人内在的模型是随着后天进行不断的调整的,从出生甚至在母胎中时一个模型就开始建立,而后随着对外围的感知模型开始复杂,渐渐分裂成多个子模型,然后又各自发展,出现矛盾、又不断进行调和,当一个局部的子模型发展越复杂时,往往意味着这个人某方面的能力会越强,在这个巨大的相互关系的体系中,内在层面我们一直倾向建立一个统一的、不矛盾的模型,当我们的内在模型实现统一时,我们会感到内心和谐,这与认知与痛苦有紧密的关系,我们对世界与自己的看法随着这个进程慢慢的在改变,自我就在这经年累月中形成,所以按照这种推理,自我未来必然可以被复制,自我也是可以被摧毁的。

沟通表达能力
一个管理者的大部份工作时间会在沟通表达上面,与上级与下属交谈,会议、报告、培训,大部份表达是依附于口头,也有相当的比重依附于文档,沟通表达的目的无非是希望在充分说明情况下,得到别人的支持、配合、理解。这意味着这方面能力会影响面很大,当你需要向上级索要资源与决策支持时,你需要它,当你需要向下属下达任务与作业要求时,你需要它,当你需要向一个团体推销一个方案时,你需要它,对于别人来说,绝大多数的能力体现都是通过你每一句话、每一份文档去感知的,这如水桶理论一样,你其它方面的能力再强,沟通表达能力不足,也只能发挥与沟通表达能力相等的绩效,它会一直决定你的最短板,而且它会影响你的人际关系与个人形象,大多数人第一直觉很难相信一个文档做得糟糕无比的人会是一个有能力、思路清晰的管理者,也很难相信在一个非受迫的环境下无法清楚表达自己想法的管理者,可以很好的带一个团队完成任务,这些情况虽然不是一定理智的,但这是合理的现实,除非你是非常高层的领导,不然大都数时候,仍然需要自己做文档、自己想清楚怎么讲话,这些基础的技能一个合格的管理者应该要扎实掌握,这并不是鼓励夸夸其谈,也不是鼓励文档花哨,现在社会带有较强的趋 ,不能指望领导、同事、下属的全能全知,管理者自己要能充分表达自己的思想,文档也应该展现适当的工整与美感。

ISO20000的理解能力
对于一个项目经理来说,ISO20000是一种业务知识,对业务知识的理解与掌握会有利于项目经理的工作,虽然我认为它不是项目经理必备的知识,但这只是在任命项目经理的时候的判断,一旦开始项目后,项目经理必须要掌握一定程度必要的业务知识,这样会更有效率,也会避免一些业务的特性不能很好识别,而造成项目过程中的错误作业,所以我的建议是ITIL foundation级别的知识还是要具备的,当项目规模越小时,越对项目经理的业务知识掌握提出更高的要求,项目规模越大时,项目经理的业务知识掌握要求反而可以降低,这两者成反比。业务知识的掌握与理解在上述的能力具备条件时,是多多益善的,但把它拔高到第一个顺位则是本末倒置了,这是很多公司在挑选项目经理的一个很大的误区,

项目经理的素质要求,以上只是选择性的说明了几个比较重要的几个项次,它并不全面,这是其一,其二素质的评判并不是0和1之分,每一项素质都是或多或少的问题,就上面而言,如果第1、2要项匹配得很好,但其它要项很差,或者第3、4、5项要项很好,其它要项很差怎么办。每个人都或多或少具备这些能力,要考量发布的特点与项目要求是否匹配,甚至要考虑到缺点的分布,是否此人的缺点与项目要求有严重冲突,如果一个人上述的能力都OK,但是他与项目几个关键成员以前因为工作产生了严重的矛盾不和,让他负责项目能很好完成项目吗?。其三除去素质外,每个公司的环境不一样,需要考虑的因素更多,比如时间因素与权力因素,一个具备以上素质要求的人员,他从事重要的生产职能管理,不可能脱身从事ISO20000项目管理事务,或者这名人员在公司处于底层作业,让他担负项目经理,是否有可能真正掌握权力去调配比较职位高几个层次的人员作业,这些都是很现实的因素,需要针对每个公司不同的情况做不同的考量,找到那个最有可能把项目做成功的人员来担任项目经理很重要,高层领导做的人员任命决定是非常有影响力与破坏力的。

咨询公司的选择
目前国内有不少公司有ISO20000咨询业务,寻找一家有实力、专业、负责任的咨询公司很重要,目前通常的做法,首先圈定备选的咨询公司名单,圈定的原则基本是搜寻咨询公司有哪一些,然后查找一些这些公司的资料,一般公司网站上会有介绍,看这些公司的开业历史、业务范围、业务规模、项目经验,一个业务范围广、规模不大的公司基本是不大可能专业的,项目经验少的也不太可能专业、一个成立不久的公司同样不太可能专业,一般而言寻找做过有跟自己公司业务相近的项目的咨询公司是相对好的选择,这些再查找看一些对这些公司的评论信息,基本可以拟定一个备选名单。



有了一个备选名单后,可进行业务联系,经过第一轮的接触,即咨询公司的自我推荐,会剔除一部份不合格的,保留3家左右的咨询公司进行最后选择,后面更多是对咨询方案的评价,与咨询顾问的评论,要牢牢把握一个重点,选咨询公司最终其实对顾问的选择,一个看似有实力的咨询公司可能派出不合格的咨询顾问服务,以目前的ISO20000咨询情况而言,尤其如此,所以在咨询公司讲解咨询方案时,要求由咨询公司的项目担当顾问进行讲解,以加强了解,而不是由咨询公司安排所谓的专家来讲解,咨询公司的售前阶段,多数会派比较有实力的顾问与专家来应对,最后拿下合同后,再派一个其它的顾问来作业,那些售前阶段的专家顾问多是不参与具体项目的,或者只是挂个名,偶尔来转转,要特别注意这个环节的把关,一定要在未签合同时,充分与真正负责项目操作的咨询顾问交流,以做到适当的了解,因为中国真正合格的管理咨询顾问非常非常少,尤其以ISO20000这种相对新生的国际标准,情况更甚之。


大多数相对成熟的咨询公司的咨询方案基本形成了固定的模版了,只需在里面把客户的名字与标识改一改即可,这样的方案他们讲过无数次,不懂行的人难以看观破绽,所以要准备更多的问题,包括项目操作、理论、业务的问题来进行测试,这种互动性质的交流比较容易验证出咨询顾问的认知与能力。不建议负责项目操作的咨询顾问人数过多,除非公司业务地理非常分散而且规模很大,不然以一个顾问为佳(如要是二个人,一定要搞清楚共分工),参与项目的咨询顾问多,往往意味着咨询顾问的实力不济需要多人合作,或者咨询顾问的时间不能保证,需要几个顾问拼凑时间,也有可能是有新入职顾问需要试验品来学习,以ISO20000这种标准而言,许多人的理解不一,不要以为咨询公司的顾问是一致的,多数咨询公司的人是找来的成品顾问,这些顾问都是基于过去自己的经验理解,几个认识不同的人一起给你治病,可以想象其中的风险,尤其ISO20000各流程的接口关联甚多,这样体系非常容易出现问题。另一个经验是,要注意那些动则在售前阶段咨询公司的老总来参与的情况,看视对方重视客户,实际上可能与这个公司的实力有关系。

选择咨询公司没有一个定性的方法,多了解,多准备问题,多互动交流,多直接与项目担当顾问提前了解,都是降低选择风险的方法,以ISO20000咨询业务来看,国内目前还难以成长比较有实力的专业咨询公司,这个市场很快会象ISO9000一样进行恶性的竞价,最终咨询公司为了生存会加快项目操作,以证书为第一考虑,客户最后口碑差,价值感越发低,如此形成一个恶性的循环,这是中国咨询业的悲哀也是中国企业的悲哀。

商务合同的约束
咨询公司选定后,商务合同需要进行拟定,基本上ISO20000的服务级别管理是同样适用于此的,象服务日历、服务目录、服务级别、服务报告这些要素同样需要考虑,比较关键的在于服务目录的部份,在明确甲乙双方的分工与责任,要清楚界定咨询公司的到底做什么,不做什么,比如提供多少规模的什么样的培训服务,在项目过程中是否担任项目管理职能,还是只提供纯粹的咨询意见即可,咨询公司是否参与文件编制,或者是否提供哪一些案例参考,在服务过程中提供哪一些报告与产出,顾问在现场的服务时间是多少,远程服务时的响应时间是多少,这些能明确的部份要写入合同,如有可能把参与项目参与的顾问人员也写入合同,并明确写明咨询公司不得中途更换咨询顾问人员。合同验收条件要进行明确,不建议在合同中写入过多不可量化的、不切实际的要求,比如一些类似合同写着要明显提高甲方的服务质量与客户满意度等等,这种要求本身期望于在项目中进行解决是不现实的,如果严格进行测算,需要设计一套明确的测量方法与计算方法,不然根本无从知道现在以及项目结束后的服务质量是多少。在合同签订时乙方大多数时候会为了赢得合同答应这些条件,碰到较真的甲方,最后就容易发生纠纷,不满意是由于心理预期与实际感知的落差造成的,甲方应理智的对待项目与合同,要真正把自己的项目需求梳理好,进行一个优次排列,这样真正明白哪一个是真正重要,哪一些是可以放弃的,觉得花了钱不多做些好象吃了亏,事实上在一直想抱着一堆目标作业时,最后会发现连最重要的目标也保障也出现了困难,这都是在对项目寄于了过高的期望,乙方也应该有技巧的引导、调整甲方的心理预期,毕竟这方面乙方的认知是相对理智与有经验的。



尤其注意的是付款的条件,要针对性的进行设计,把握好其中关键的里程碑,考虑双方的利益问题,合适的付款条件会对甲乙双方形成压力,对甲方而言,当然是款项越后面支付越有利,但如此咨询公司的成本支出就显得不公平并带有很大的风险,对乙方而言越早付的款项越多,就对自己越有利,但如此甲方的利益就缺乏最有力的保障,一般而言合同签订会付一部份,培训完成后付一部份,体系文件完成编制后付一部份,体系正常运行一段时间后付一部份,认证完成后付一部份,最后判定验收条件全部后再付最后的部份,这样子切分成多个部份,咨询公司会期更大的动力去追逐作业进程,同时每一个阶段开始前,咨询公司都提前得到了收益,不会成本预支的问题,而对于甲方而言,因为钱已经付出,必然要得到服务并对服务质量进行评判,双方形成一个良性的博弈,对项目的成功形成正面的动力。

项目目标的定义
项目目标的定义多数情况并没有得到重视,如果一个项目是软件开发型的项目,这时目标会显得相对显而易见,但当是一种管理咨询类项目时,对它的目标定义就存在一定难度,但目标又是如此重要,没有它的指引,任务无法生成、作业没有方向,结果无法判定,对于ISO20000这种项目而言,每个公司在项目初期都宏图大志,证书反而是最不考虑的,但随着项目的进展后,会放弃越来越多的目标,最后唯证书论了,这里做为公司的领导,最需要清醒的是,在周期以半年或一年计的时间里,你花钱做这个项目想干嘛,到底想干嘛,要想清楚,用常识也会知道,在半年或一年的时间内,建设一整套设计优秀的制度这本身是很困难的,何况是要让一整套制度进行运作起来,而且要拿到一个国际认证,这些要实现其实是很难的,真正把按月把时间切分一下,你会发现,一般设计一整套覆盖全公司的流程制度要有2-3个月内完成,考虑到编制、评审、修订,而且参与人员的文档能力与设计能力,这是很难的,最后会为了赶进度而牺牲设计质量,要理智的看到在短短时间我们能做什么,把最难的事情给做了,把离开咨询顾问做不了的事情给做了。注意项目目标包括时间的目标,即赋予这个项目多久的时间来实现目标,不建议采用低于半年的时间目标,也不建议采用超过一年的时间目标。

一个ISO20000项目,最重要的是得到一整套设计合理的流程制度,也即是一个好的管理体系,其次这个管理体系要得到外部的检验,即一个国际标准认证,再次之是培养一批理解ISO20000的ITSM内核的中层管理者,让组织得到一个持续监控、维护、改进管理体系的方法。有了四点(一个体系、一个认证、一个队伍、一个方法)这个项目才会不断的开花结果,未来服务质量的提升才更有保障,这样才不会项目一结束,体系就死亡,这四点都可以进行具体的检验判定,而且这四点甲方难以在没外力的情况下进行作业,能做好这四点就非常非常完美了。大胆放弃一些具体的业务指标,比如成本下降多少、质量提高多少、效率提高多少、满意度提高多少,这些指标的决定的因素与条件是非常复杂的,管理体系只是其中一个要素而已,这些指标的提升需要更长的周期,更全面、更系统化的改善,不能把这些乱压在项目中,不然会非常容易出现问题。

项目体制的设计
有了项目目标,接下就要设计一个项目体制去实现它,体制中最关键的一点就是项目经理的权责定义,不要搞那些流于形式的项目经理制,中国大多数的公司的风格是什么项目都会让职务最高的领导来担任项目经理,但实际上项目操作这些高层领导不可能负责,这些就造成一个严重的问题,真正负责项目管理的人员没有对应的项目经理的权力,真正有项目经理权力的人不负责项目管理,负责项目的人员做事名不正言不顺,反而会经常受到高层领导的项目事务干预,无法按自己的思想去做项目操作,最后谁都负责也谁都不负责,造成一系列的困境,一个清楚的组织架构比什么都重要,一定要切分清楚项目经理的权力边界与职责边界,要明确什么事情项目经理说了算,什么事情需要由高层领导决策,要明确项目经理做什么,项目经理是一个角色,体制的第一层是定义好有哪一些小组,哪一些角色,这些角色分别的权责是什么,第二层是然后是分别是谁担任什么角色,这样才能形成一个真正可以指导作业的项目体制。
    ISO20000项目的体制,建议的职能组可分为:决策领导、项目经理、项目助理组、咨询组、培训组、流程设计组、流程评审组、体系实施组、软件工具组、认证审核组。



决策领导:阶段性的了解项目进度,对重大决策进行决议,提供资源支持,授权项目经理的项目权力。

项目经理:拥有项目内事务的最终发言权,制订与控制项目计划、策略、协调、检查各小组的任务,对项目成员进行考核,工作对决策领导负责。

项目助理:为项目成员服务,提供后勤支持,负责会议管理、文档、模版管理、计划跟催、检查反馈。

咨询组:对项目作业中的问题提供咨询建议与解决方案。

培训组:负责整个项目的所有培训组织、管理、记录。

流程设计组:负责程序文件的设计、编制、修订、解释。

流程评审组:负责程序文件的评审。

体系实施组:负责程序文件的发布、执行落实、执行检查与反馈。

软件工具组:负责体系运行的工具技术支持。

认证审核组:负责外部审核的组织、准备、配合

以上只是根据公司的项目规模可进行职能合并与重组,小组建制越多,职能越明确,但小组间的任务交互就越复杂,项目经理整合任务与信息的能力就要越强,小组建制越少,职能越不清楚,但小组间的信息交互也就越少,作业管理难度也相对较小,具体的取舍要根据具体的情况来定。上面介绍的职能是很粗略的,在真正设计项目体制时,需要具体画出组织架构,并做职能文字说明,项目体制一定要明确对所有项目成员进行公布,以所有成员清楚各自的权力与职责,避免出现不必要的解释纠份,影响项目工作,在可能的情况在公司内部的信息系统上进行公告,以扩大影响。

项目计划的设计
明确项目体制后,项目经理需要编制项目计划,项目计划建议进行分层控制,以便于进行管理,将项目的计划分为三层:

第一层是项目一级计划,它只定义关键的里程碑,这里是指把整个项目按时间进程分解成几个主任务,比如项目启动是一个里程碑,然后第二个主任务是理论培训,理论培完成的点就是里程碑,然后第三个主任务是流程设计、第四个主任务是流程评审,第五六七个主任务是流程实施、内部审核、外部审核,这样最粗线条把项目分解成若干个主任务,定义出每一个任务完成的时点,列成计划,这个就是战略计划,它必须得到决策领导的审批,这个战略计划一旦要变更,需要决策领导进行审批,所以一般而言一级计划是严攻死守的,它一旦打破就意味着项目面临基本目标可能丧失的问题。

第二层是二级计划,一般是按月进行编制,或者按主任务编制,按月编制是不管属于哪一个主任务的子任务分解,统一按月份来做计划管理,一个月就一个计划,一个任务只要落在某个月份就进行罗列排序,这样的好处是所有的事务会在一个视图中提现出来,利于统一跟踪检查,按主任务编制是指根据一级计划的主任务分解,对每一个主任务进行再分解并进行单独的计划管理,这样的好处是每个主任务分解很清楚,但当几个主任务并行时,计划管理较为困难。也可以将月计划与主任务计划同时进行,先编制主任务,然后再逐月制订月计划。二级计划是战术计划,它是完成一级计划的基础。一级计划与二级计划都应该由项目经理进行制订与管理。

第三层是三级计划,一般是按周进行编制,即每一个周是一个计划单元,周计划来自对月计划的再分解,最终是依靠每周的计划推动来实现项目目标,周计划就是执行计划或作业计划,它是可以落实到人的,在有必要而管理力度可以达到的情况下,日计划的出现也是可能的,这取决于任务分解的可行性与必要性,一般而言周计划基本上是可以满足管控的目的了。周计划可能由项目经理制订,也可以考虑分组由组长进行制订,即一个周计划或分组多个周计划管理,这个取决于实际的情况与环境。

计划编制时考虑的要素是任务的内容是什么、责任人是谁、参与者是谁、产出是什么,什么时候开始、什么时候结束,拥这些要素,计划才成为计划。在编制计划时要考虑适度的冗余,在作业时一定会有各种因素打破既定的预期,尤其当项目的参与者大多是身兼多职时,更是如此,时间的冗余设计同样可以分层,在一级计划时就预留10%左右的时间进行缓冲,即这10%的时间是不在计划之内的,留着做最恶劣的时候来使用,二级计划也做适度的冗余,二级计划不建议一开始就制订出来,而是按阶段按月进行编制,因为做过久的未来的比较详细的计划不切实际,只需做到适度的提前即可,计划的目的是为了指导作业,有了一级计划,每个月末根据当时的情况制订好下一个月的计划,这样更有效一些许多细节的事务,不到那个阶段时,是意想不到的。三级计划因为是周计划,同时有周末的时间可以缓冲,所以计划可以排定得比较紧凑与精确。对于一些可以估算精确的任务要计划严格些,如一个培训一个评审,这种时间可以做好估算,这种计划就得设计得严格些,但一个文件的编制,则比较难估算,这时计划就得留有一定的富余。



计划是否具备较高的执行性与操作性,取决于任务分解的精度,如果任务分解有遗漏,则很有可能导致计划缺失,所以计划的制订需要非常重视,一级计划比较容易制订,二级计划制度就有一定难度了,如果在二级计划就出现缺失,会带来不小麻烦,三级计划缺失,还很有可能具体的作业人员会发现并提醒,但二级计划这种战术层面多数由项目经理一人控制,就非常依赖其个人能力,任务的分解首要对任务有清楚全面的理解,一般首先考虑这个任务是不是可以拆分成若干个子任务,当不能再拆分时,就考虑这个任务的作业步骤,如果作业步骤不能再拆分时,就考虑这个任务需要依赖什么要素,按照三层逻辑去循环分解分一个任务基本上是可以成功分解,计划分解到最精细时,就会成为一个作业指导,比如一个培训,能不能拆分成几个子培训,不能拆就考虑它的步骤,培训一般要先做培训教材、然后是培训展开,最后是培训考核,这样就可以拆分成三个子任务,然再分析每一个子任务,比如培训教材制作,按同样的逻辑再进行分解,先要做一个培训教材的模版,然后收集培训资料,再进行培训教材的编制,然后再做审核,然后打印,这样可以分解得比较清楚,而且不容易出现纰漏;再分析培训展开这个子任务,已经不能再分解子任务了,也没有什么步骤可言,这时可以考虑它的依赖要素有哪一些,要做培训,需要有场地、设备、讲师、学员等等,这时就又可以分解出,确定场地,设备的调试等一系列的活动出来,如此不断分析下去,就可以做出一个具有很高执行性的培训计划出来。

对于计划的追求不宜过于偏执,基本上是不存在非常精确的计划的,每一个项目结束时,你总会发现是有些情况你无法预计的。有些公司的领导会为了计划而计划,最后形成一堆没有内核的流于形式的计划文档,而忘记了计划的根本作用。一定要把握计划的意义所在,计划是为了实现目标而让大家清楚在什么时候要做什么事情,我非常强调项目经理去制订计划,是因为在制订计划的过程是一个建立项目地图的过程,也是自我进程梳理的过程,它会帮助项目经理非常清楚的把握现在与未来的状况,项目经理应该非常清楚项目的进展状况,非常清楚哪一块的计划是存在风险与问题的。计划要形象的在项目经理的脑内,如果项目经理的制订计划能力不强,应该组织进行计划评审,以便大家的一个正确的作业指导依据,计划制订完成后,要进行正式的渠道公布。

项目绩效的设计
大部份人在有足够的动力或担心受到惩罚时,工作效能会更高。对于ISO20000这种项目,绝大多数的项目成员都不可能是专职的,所以项目的事务是本职工作额外多出的事情,而且这些人员多数还是管理人员,依靠什么能让一批管理人员长时间的额外做一些不是本职工作的事情,并且要按质按时的完成呢?领导这些管理者做事情的还不是他们的上司,大多数管理人员还是很忙碌的,所以这些额外的工作势必会占用他的日常工作时间,经常引发时间安排的冲突。这时去谈职业精神与领导者的人格魅力,可能能在一周甚至一个月内让这些人一直项目要求作业,但一年的话就很困难了,把项目的成功寄望于每个人的自律性与主动性,这是不现实的,所以必须要设计一个有效的绩效模式,去解决这种做事的动力问题,说到底就是奖罚,每一个项目成员承诺一笔项目奖金,会解决一些问题,每一个项目成员如果没有没有做好,就罚去一笔钱,也会解决一些问题,不愿意加班就发放加班费,这样子说,可能每一个老板会哭,每一个工作者会笑,这只是基本的道理与规律问题,实际奖多少罚多少,这取决于老板的价值判断与每一个工作者的价值判断,如果这个项目的所有成员都拥非常高的职业精神,又这个项目的项目经理有着强大的威摄力,是不需要支出这种成本的,项目成员本着统一目标,不要一分钱的加班加点干好项目,甚至说不准可以创收一些额外罚款收益,但这样的公司与这样的员工又真的没有那么多,大多数人还是现实的动物,而且每个人又可以很聪明的用各种方式与理由去解释每一次没有按时安质完成任务,所以绩效策略还是相当必要的,如果要更有保障完成项目目标的话。

绩效的设计的第一考虑是要有足够的动力去约束激励项目成员,包括项目经理在内,第二考虑是要让项目经理掌握绩效考核的权力,以便能有效领导与管理项目团队,第三考虑是要有足够有效的措施去约束每一个人具体的作业行为,项目最终其实就是成百上千件任务组成,项目的成功依赖每一件任务的按时按质完成,所以绩效模型的设计要合理,对项目成员的绩效设计,要从三个方面考虑:质量、任务量、行为,质量代表着分配给他的工作是不是按时按质完成,任务量是他投入了多少时间,行为是团队意识与作业态度,三者占有权重各不相同,而且要对每一个方面再进行更详细的定义分解,以便有更明确的指导意义,绩效要做日常记录并在月例会上进行说明,绩效的作用要发挥于当下,当项目结束时,再说绩效考评,这样的绩效起不到多少作用,绩效的设计要由项目经理负责,由决策领导进行审批,通过后应在项目启动会议上进行正式公布,要把绩效纳入日常管理,绩效的数据是在作业过程中产生的,要融入例会制度之中进行报告,这样才能最大效能的发挥作用。

项目过程的控制
项目目标、项目体制、项目计划等等都是假设性的,它是项目的规划设计,它只是空想的结果,其基础是项目策划者的分析能力与预知能力,这些假设是不是正确的是一个问题,项目会不会按料想的假设那样发展也是一个问题,如何保证结果跟我们计划的一样呢?这就需要对过程进行控制,过程没有控制,结果就没有保障,控制二字的核心涵义,从字面可以如此理解,“控”意味着监控、观察、知晓对象的情况,“制”意味着驾驭、制服、影响对象,综合一处的意义为通过一种或多种方法了解某个或多个对象的情况,然后利用手段使对象符合按自己的预期或要求。项目过程控制主要是针对进度、质量、成本三这个方面,项目过程的控制是法无定式的,要根据具体的项目情况具体设计,以下是针对ISO20000这个项目的过程控制的几个建议:

例会制度
最重要的要让项目有一个自我反馈、调整改进的机制,这个频率要相对较高且有规律性,这样才有机会及时干预控制,并形成惯性,设计一个定期的会议制度是一个比较好的选择,会议非常耗费成本,但它的信息扩散也非常有效率,会议制度可以进行分层,月例会:整个项目进展情况说明、上个月的计划完成情况检查报告、下个月计划的分布说明、项目问题跟进报告,月例会可以邀请决策领导层参加,以月例会为的项目信息发布渠道,同时项目经理提出超出其权限范围的协调事项的渠道;周例会:上周计划完成情况说明,下周计划公布,项目内事务协调;根据具体的情况,有时在项目的某些阶段,也需要设计日例会,尤其是文件编制的阶段,很容易一周的时间过去了,但没有任何进度,这时就需要加强监控手段,或者要求任务者编制自己的子计划,以加强管理。会议制度得到良好的执行,会形成项目的生产节拍,这也是项目的心跳,每个项目组成员心里都会有统一的工作节奏,大家的信息与对项目的感知也比较一致,会减少许多不必要的问题。有时会议制度久后,会形成一种管僚化,大家觉没有什么内容就放弃了对会议制度的坚持,这是很不好的,当制度都可以放弃打破时,没有什么是不能被打破的,这是带给大家的一种信息,对制度的坚持比制度本身更重要,它会带来一种文化,它也会传递一种所有人都要毫无折扣的按制度行事,项目如果执行力的意识遭到破坏,会带来一系列的恶果。项目经理要牢记不能让那种涣散、敷衍的习气在项目组内蔓延。会议制度一个是定期很重要,而会议的内容则更加重要,要定义清楚月度会议要做什么,周会议要做什么,把内容圈定在会议材料中,形成模版,会议时间无须过长,会议的形式可以是由项目经理若项目助理针对计划进行检查,任务负责人回答,也可以是由任务负责人或组长进行本周期完成的工作有哪一些。

检查措施
检查主要是侧重于进度或侧重于质量,进度的检查要以“时”来检查,即规律性的检查,与会议制度相配合,比如每周五下午检查本周的计划完成情况,这种措施可以由项目助理或项目经理来负责。质量的检查要以“事”来检查,即把检查措施放在任务计划本身去,质量检查可能会带有较强的专业性,需要考虑检查人的专业能力,比如象体系文件编制是不是合格,对它的检查项目助理与项目经理有可能没有这种专业能力,这时可以安排专门的人员检查,或者让几个负责文件编制的人交叉检查,这个检查的动作设计到计划本身去,这样才能避免遗漏。检查要侧重于产出物,尽量避免依靠口头确认,所以在制作计划时,要考虑到每一个任务的产出物是什么,当产出物检查合格后,要上交到项目助理处管理起来,所以当项目助理看计划只要到了交产出物的时间,就会要求交货,而且他不是向作业者要求交货,他是向检查者要求交货,这样分层进行跟催检查,可以让作业者相对规范的完成任务。对于一些关键性事务的质量检查,可以考虑做专题会议性质的评审,比如一个流程文件编制完成要进行定版时,就需要组织人员进行评审。

模版约束
项目经理在制订计划时,凡是有产出物的部份要考虑是不是要设计文档模版,设计一个合理实用的模版,会减轻作业人员的工作量,同时能约束产出结果,统一大家的作业规范。像体系文件的编制,肯定是模版的,还有一些象计划的模版,计划检查记录的模版、会议材料的模版、体系文件评审的模版、会议记录的模版、培训记录的模版、日常绩效记录的模版,这些大大小小的模版会很多,项目助理要负责模版的管理与发行,文档模版要做好版本管理控制。

变更配置
变更管理是指项目体制、项目目标、项目计划、项目文档已确定的东西需要进行调整时,需要做变更控制,这里强调变更,主要是两点,一是要有授权,即谁有权力批准改变,比如一级项目计划要改,项目经理不能决定,需要决策领导审批,再如一个定版的体系文件要修改,需要项目经理审批等等,二是要有通知,改变了什么需要告诉哪一些人,甚至会引发哪一些相关联的事情发生,比如文档模版要改,会影响其它的哪一些文件,要通知哪一些人员,项目经理要有变更控制的意识,避免引发混乱。

配置管理主要是指项目过程中文档管理,每一份计划、模版、记录、报表、报告需要统一管理起来,最好的方式建立一个文件服务器并利用专门的软件进行管理,这样大家调阅与修改都可以留下记录,最需要关注是体系文件的配置管理,由于一群人编制,随着检查与评审的过程,会不断有新的版本产生,需要进行严格的逻辑与物理管理。另外一系纸质的文件需要好保管归档,分门别类进行管理,最终项目结束时,从头到尾的所以产出是可以查阅的,最终的项目成果也是工整清楚的。

项目结束的管理

一个好的开始跟一个好的结束会让你工作事半功倍,项目的启动与结束要仪式化,非常正式的去操作,这会让上至领导层下至项目成员,去严肃正视项目,长远的对大家的意识产生影响,要利用项目启动会那个时刻去树立项目经理的权威,要利用项目总结会议去为项目成员争取成绩。一般谈项目管理比较少重视项目结束的方法与过程,事实上结束与开始同样重要,要找到一种符合公司情况的最有效的方式来结束项目。

首先要把项目目标做一次全面回顾,当目标达到时,项目才能结束,再回头看项目初期定的目标,是否全部做到了对应,达到了判定完成的条件。其次是把项目成果进行整理,清查一次项目的所有文档,做一个分门别类的统计,看看项目团队取得了一些成绩,这些项目文档是一个公司的历史与财富,在项目过程就要有这种意识做好记录。接着要对项目过程进行总结,项目经理需要静下心来,回顾一下整个项目过程,分析一下哪一些地方出了问题,为什么?以后类似的问题是否可以避免?哪一地方做得比较好,为什么?是否可以供日后的项目复制?整个计划的达成情况要做深入的回顾总结。过程总结完后,需要把项目过程中发现的未解决的问题梳理出来,以便于公司日后有人跟进改善。以上说的这些要形成一个工整的项目报告,这个项目报告很重要,要全面而深入,项目在编制之前,项目经理可以组织一次项目成员进行一次小型会议以收集更多大家的意见,当项目总结报告完成后,组织一次正规的项目总结会议,尽可能邀请整个项目体制的成员参加,项目经理在会议上报告项目目标完成情况、项目过程介绍、项目问题总结、项目成果总结。然后项目体制的各个小组分别进行发言,最后由决策领导对项目是否结束进行最终判定,并宣布项目体制解散。一般而言一个项目结束时一定遗留一些问题或未完事项的,需要确定这些问题或事项的对应负责人员,以保障项目过程中的瑕疵得到处理,同时也利于巩固项目成果。



本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x




上一篇:ISO20000体系实施难点---破子
下一篇:ISO20000广破论(1)---破子
长河

写了 971 篇文章,拥有财富 11177,被 31 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies
bs15000 发表于 2010-12-21 16:38:02
谢谢分享
東東 发表于 2020-11-26 08:29:25
谢谢分享,学习了
Powered by ITIL  © 2001-2025
返回顶部