
随着现代项目范围和复杂性都在逐步增长,一个项目很容易就需要数百名项目成员并跨越不同的时区来进行交付。因此, 控制项目的变量对于项目的成功至关重要, 项目经理如果没有责任心很可能会导致项目失败,会对项目管理者的职业生涯造成严重的后果。
项目经理需要学会不断的降低项目成本来满足项目中利益相关者日益增长的收缩预算的期望,项目经理需要克服政治动乱和地理障碍等不利因素培养新员工,所以,对于了解下面这几个成功的关键点会帮助项目经理实现更高效的项目管理过程。
项目的透明度有助于维护项目中的公共关系并保持与项目中各利益相关者的联系。 保持项目的透明度是项目管理者的基本素质之一, 通过项目透明度来来确保项目严格遵守项目的指标标准并降低成本,随着多项目并行的存在以及项目群的工作方式,这种透明度显得越来越重要。
项目中的一些任务或者活动最初可能会有一些错误或疏忽导致成本的增加,但如果不加注意或者没有被揭示出来,当随着项目进展或者事情变得越来越复杂时,这些成本乘以管理的项目总数时,最终形成大量的收入损失和增加额外的费用。
项目经理必须帮助所有的各个利益相关者了解他们的行为如何影响到项目的状态, 通过增加项目信息的透明度来改善项目管理中的问责制,降低项目风险,并能够有有效地促进合作。
项目评估过程的效率和有效性仍然是项目成功的一个方面,想想这个项目如何从当前的新技术中获益,通过完成这个项目如何能够获取商业上的显性利益和潜在利益, 通过项目中的协作和任务的执行,以及有效的沟通,能够锻炼和打造一支高水准的项目交付团队。 项目的评估应该在准备阶段就要完成,而不是等到项目交付的过程中才去进行评估,这会破坏项目的成功。
当然项目的过程评估也是必不可少的, 通过将项目的整体目标进行作分解,并划分成为不同的阶段,对每个阶段进行评估,看是否达到了当初制定的要求, 一旦评估不能通过,就需要进行判断是进行纠偏还是将项目进行终止,避免损失的继续扩大。对于项目的评估可以通过第三方进行,也可以利用互联网新技术搭建IT系统来完成,没有好的评估,就无法知道是否有好的结果。
如果你想在餐厅得到一份色香味俱佳的高品质食品,那么厨房里的每个人都需要知道食品的安全和完成最终成品的流程。对于项目也是一样的, 项目中的各种要求可能有所不同,项目中的所有成员都需要了解每个人的不同职责并清楚如何不影响项目的成功。
项目的规划团队需要了解如何将估算转化为预算,项目文档人员必须要了解其他各个成员当前的任务是什么以及如何获取成员的报告,项目的培训资源就是项目成员本身,通过相互之间的综合培训,可以使团队成员感到团队整体的责任感,也会诱使团队成员更加开心而有高效准确的开展工作。
项目管理过程中,总是要涉及到各种IT系统,电子邮件系统,项目管理软件平台,流程评估系统,会议通信系统等等,这些IT系统平台可以大大帮助项目经理完成项目管理的效率提升和价值呈现。 项目经理需要确保这些系统必须要有IT支持解决方案来进行保障,一旦出现由于系统中断事件,IT能够在遵守适用安全性和法规的前提下,进行快速响应。
IT支持解决方案不仅在系统出现问题时可用,IT支持人员还可以帮助项目管理者进行系统平台迁移,可以帮助项目成员处理个人的IT问题。比如系统中可能会有很多软件自动更新,但仍然会发生错误,系统中那些信息包含关键的安全信息如何进行处理,这些都可以通过IT支持团队指导项目成员来维护系统,减少系统停机时间,降低风险。
在项目的实施过程中,项目成员的额分心是不可避免的,即使是最好的员工也仍然会犯错误或者花费太多的时间去处理复杂的问题,同时随着活动任务和费用的持续上涨,项目的预算也受到威胁。 项目中的时间和费用的分配是一个很复杂的方式,但是必须要去做。 项目成员必须要将管理任务所花费的时间和成本进行分析比较,来评估这些任务,来看整个项目的管理效率和生产率水平。
换句话说,如果时间和费用分配超支会导致生产价值下降,但如果分配的太少又会导致项目可交付成果质量差或者不准确。项目经理需要帮助成员确定一个合适的比例,帮助他们保持自己的责任感和预期的时间要求,这样可以降低项目的整体成本。
卡西亚IT管理系统是全球领先的IT管理系统方案提供者,支持当下所有的计算机系统,如Windows2003、2000、NT、XP、98、95和Windows 7。同时在补丁方面自然也支持这些系统, 同时能够提供良好的方案。
重庆电信企业信息化事业部 傅诣
目前垂直的部门管理模式对“以客户为中心”、“零不爽”要求弊端日益明显。特别是在当前市场需求瞬息万变,需求要求快速支持的背景下,需求无法高质量的实现,首先表现在需求实施的效率与速度上,无法快速支持需求。其次表现在需求实施质量上,需求上线问题较多,带来很多次生问题,需求质量业务单位与分公司都不满意,影响IT口碑。
以客户需求为中心,启用矩阵式需求管理,建设高、精、尖需求界面团队,在企信部设立后方资源池,深入需求一线,让需求一线指挥炮火,实现需求小前端,大后端,前端综合化、后端专业化,后端全力支持前端。
现状:目前企信部采用传统的垂直化组织架构,各域组织界面分明,容易形成部门壁垒,需求由需求前置团队接收,分派到各个域,较为复杂的联合需求由各域分别评估,各域再进行联合确认,再与需求业务单位进行沟通,期间反馈多次,效率较低,特别是在部分需求细节存在问题时,往往需要多次开会共同确认,在实现方案上各部门也往往各执一词,耽误需求实施时间,也影响需求实施质量。
措施:
1采用需求矩阵式管理:针对重要需求,采用项目制管理,由各部门部门负责人、技术专家、实施人员、厂商组建临时需求实施团队,此团队不隶属于任何一个部门,采用承包方式,将需求承包给虚拟团队,每个需求团队负责人拥有可以“呼唤炮火”的权利与“签署责任书”的义务,做到权责对立,平衡(后面会详细说明)。这样就可以整合事业部各部门的专家优势,打通部门壁垒,快速实现需求。该方式也就在事业部层面就形成了一个垂直于传统部门的需求实施矩阵,与各域的生产维护形成互补。
2“黄金四边形”:黄金四边型目标是建立贴近需求一线的敏捷化组织,在事业部层面对外形成统一的界面,能灵敏捕捉到公司领导及一线的关键需求,找准需求“痛点、关键点”,迅速调动资源,建立专项团队,灵活快速实现需求,打破部门壁垒,突破原始需求流程的烦冗。团队必须包含“项目经理”、“需求分析团队”、“方案设计实施团队”、“后期维护支撑团队”四个关键团队,形成黄金四边型。
各团队职责如下
(1)项目经理:项目经理是团队的****,是需求的第一责任人,拥有“呼唤炮火”调度资源的权利,同时,也是需求目标达成的第一责任人,签署需求实施承诺责任书,在需求完成后接受事业部对实施情况的考评。厂商负责人也纳入项目经理。
(2)需求分析团队:需求分析人员是与业务单位接触的排头兵,是第一接触人,首要任务是找到需求的“痛点”或“题眼”,其次是需求实施的桥梁,对外,负责引导业务单位按照IT“先上菜”进行推进,引导业务单位采用IT推荐的需求实施方案与分布实施的时间计划;对内,负责将需求与方案设计实施团队沟通,形成需求支撑方案,并与前端沟通。再次,在需求实施全生命周期中对需求变更进行管理。分析团队工作必须量化,每个需求必须要有需求分析说明书,每次需求会议必须要有需求沟通(或评审)会议纪要,每次需求变更需要有需求变更记录。
(3)方案设计实施团队:由各域的专家与执行人员组成,负责需求实施方案的落地,并与需求人员一起对实施方案向业务单位沟通,达成一致,最后由此团队的实施人员完成需求上线(执行人员可能与后面的“后期维护支撑团队”人员重复)。方案实施团队必须输出每个需求的方案,方案由事业部形成统一的模板输出,方案质量纳入管控。此环节是当前需求实施中的短板,很多需求在完成需求分析后,直接丢给厂商实施,实施方案中功能部分内容没有评审,界面部分在实施中也没有DEMO,没有也业务单位沟通,导致质量不被业务单位认可。该点如何提升,建议如下:
首先把需求分为5个层次,要求在方案模板中必须都进行说明,底层为功能需求,仅仅针对功能本身;第二层为服务需求,本层包含业务及流程,提升服务能力的需求;第三层为体验需求,考虑到客户感知的需求,含易用性, *** 作性,感知方面;第四层为关系需求;顶层为成功需求,即满足公司组织成功,有效推动业务发展。我们现在往往注重第一层的功能需求,对其他层次需求不够关注。即使在第一层功能需求中,还存在“简单功能做不好,复杂功能做得好”的情况,原因就是以IT惯性思维技术为导向,没有以客户需求为中心,没有抓住需求“痛点”,将IT功能做得复杂。后续,我们要多放精力到第2至第5个需求层次中,更加注重易用性, *** 作性,快速支撑。
(4)后期维护支撑团队:目前我们往往“重建设,轻维护”,需求上线后,就算完了,监控、作业计划没有跟上,上线后也不能主动发现问题,往往前端发现问题后,已经晚了,造成了较严重的后果。对此,后续维护支撑团队,首要任务是建立需求上线初期的监控保障手段,用数据说话,证明新需求上线后的运营情况,提前于业务单位发现问题,及时处理。其次,对新需求上线后的监控,作业计划进行实施,对新需求上线后出现的问题进行集中解决,为一线提供支撑。
前面说了,我们建立了矩阵式需求管理制度,组建了高、精、尖的需求团队,那么如何进行运作?
1小前方,大后方:需求分析团队直面业务单位,但我们后面有一个强大的支撑保障团队(各域专家、实施人员、战略合作伙伴等),各域整合资源形成整体支撑大平台,提供解决方案,提供技术支持,这样才能让小前方需求分析人员有底气,有引导需求,主导实施的资本。
2一线呼唤炮火:当需求人员或需求预沟通发现重点需求时,一线要迅速做出反应,立即呼唤炮火支撑,后端将根据需求难易程度,配备必要的资源,在实施过程中动态补充人员,必要时采用王牌团队或王牌专家,快速应对需求,落实方案,稳步推进。
实现小前方、大后方,一线呼唤炮火的措施:
(1)呼叫的炮火要集中在一点原则:集中在“痛点”或“需求题眼”上,才能实现“闪电战”。这也是中心领导说的先上关键“菜”。虽然我们呼唤到了火力,但是如果针对整个需求的方方面面,无法显示出火力的局部优势(火力被分散了),这就要求我们的需求项目团队,与业务单位沟通,集中火力先上关键“菜”,这个原则的度一定要控制好。
(2)组织人员保障:按不同域对不同人员进行打标,定义他们的责任,为他们指明发展方向,形成人力资源池。按照需求项目管理,需求实施需要管理者、需求分析人员、技术保障人员、上线后维护支撑人员。需要对各部门人员打标,属于哪一种角色,形成专家库,为随时组建队伍做准备。
(3)需求考评机制:事业部拟定出台《需求实施承诺书》,包含权利与义务。权利是可以在一定范围内调配资源,承诺为需求完成的目标,在完成目标时对应的奖励与惩罚。项目经理代表团队签署承诺书,并在需求上线后1个月内接受事业部考评,并进行奖励或处罚,并给团队及成员等级评定。
(4)团队及专家等级晋升机制:各种人才打标后,均成为此类型的专家,需要对组建的团队与专家根据需求实施效果进行考评,采用军队的晋升方式。通过考评筛选出王牌团队与王牌专家,在遇到重要需求,疑难问题时,优先使用王牌团队与王牌专家,使其成为“特种部队”。这样做的目的,是将事业部目前的“屯兵模式”提升为“精兵模式”,让不确定、困难复杂的关键需求,由精兵完成,提升感知。通过此方式,还可以建立企信部的战略预备队,为IT队伍的后续发展提供帮助。
(5)仲裁(指导)委员会:仲裁委员会设立的目的就是打破部门间的壁垒,具备横向传递沟通及协同作战能力。前面说到,项目经理作为需求项目实施的第一负责人,具有一定的动态调配资源的权限,但如果在需求实施工程中,出现与职能部门的壁垒或冲突,或遇到其他管理问题、人力资源问题,由仲裁委员会仲裁决定。建议仲裁委员会由事业部领导及部门领导组成,针对非技术性问题进行协调仲裁。
(6)技术委员会:事业部技术委员会负责需求实施中遇到的方案问题解决及支撑,特别是对在哪个系统实施较优方面进行确认。在需求遇到技术难题时,技术委员会将对技术细节进行指导。
(7)需求管理平台(缺失):事业部目前使用门户及ITSM系统结合对需求流程进行管理,但缺失一个统一的需求管理平台,各部门目前均使用EXCEL对需求进行管理,哪些需求已超期,哪些需求为事业部当前重点需求,哪些需求不合理,没有一个需求管理系统进行管理,所以,建立一套需求管理分析系统,迫在眉睫。
(8)会议管理系统(缺失):以业务部为例,上周业务部有10个会议,其中需求会议6项。业务部目前通过人员进行管理,罗敏每周五发会议周报,列举会议清单,从安徽学习后,业务部要求每个参会的人员出具会议纪要,由罗敏汇总。简单会议出简单的会议纪要,重要会议,出详细的会议纪要。我们希望有一个会议管理系统,将每次会议的纪要进行上传,纳入系统管理,这样,可以有效杜绝需求、专项工作进度上下不一致的情况。
(9)需求变更文档化:加强需求文档管理,这里重点强调一下需求变更管理,由于一些重要需求是公司领导需求,需要业务单位按照领导要求细化,并不断与领导沟通,这样必然会多次变更需求,IT为保障需求尽快上线,必然存在需求在实施中多次变更的情况。这就要求,每次需求变更必须文档化,把整个需求变更的情况记录下来,也要求需求团队与方案设计团队、后续维护支撑团队做好沟通,将每次确认的内容文档固话。这里建立事业部出具需求变更模板。
(10)需求模式固化:先选取少量需求试点此方式,在积累经验后,迅速固化实施流程,并将流程清晰、重复运营的流程及工作模板化,抓住主要的模板建设,再把相关的模板流程串起来,不断优化。形成知识库,事业部通过呼叫炮火的方式,集中支持,集中处理,解决共性问题,这些共性问题的解决要形成知识库,在后续遇到类似问题时,快速支撑。
(11)需求透明化:月初,需求版本部署会议,与业务单位沟通本月需要实现的需求;月中,由事业部整体出面(或各需求项目经理)与需求业务单位就需求进度进行沟通;次月上线后,与需求单位进行需求后评估,对需求后续维护及问题解决进行落实,对需求后评估结果进行沟通。
(12)加强需求过程管控:在建立此机制后,需要进一步加强需求过程管控,授权不等于放任,必要时实时监控。
我们面对新的观点、新的思想,作为职业人士,更多的需要学习、理解并加以灵活运用,这也体现对企业文化的融合和认同。
但是,切不可盲从,盲从就会活在他人的世界里,失去对事物的预判能力;相反,要养成独立思考的习惯,进行深度思考,探索背后的本质,这样的目的不是为了驳斥与反对,而是先人一步,洞见未来。
我们曾总结过,IT系统的主要价值包括精确地呈现数据、固化流程、防呆提效等;反过来,如何提练出IT价值的评估要素,以之为牵引,倒逼业务改善呢?
例如:IT评估要素主要可以包括业务IT覆盖率、方法工具沉淀占比、指标报表导出率、异常移动提示率等维度。其中:
指标报表导出率、异常移动提示率可以理解为数据(报表、指标)的提取和应用,这符合数字化企业建设和经营的思想,利用IT具实现数据可视、简单高效,形成数据文化,数据驱动决策和战略;
但是,数据是来源于业务流,来源于业务底层,确保数据的及时性、客观性是数据应用的基础;同时,如果指标、报表设计不合理,偏离客户导向,会促使管理层为了数据而数据,甚至弄虚作假,背离初衷。
方法工具沉淀占比是比较好的导向,鼓励发明方法工具、全员创新,形成规范体系,并通过IT固化,将好的经验进行传承。
而业务IT覆盖率是比较重要的一个指标,它体现了企业经营活动IT的支撑程度,业界也形成了一些标准的方法论,如流程梳理五步法,然后,在此基础上来进行IT覆盖的判定,决定IT项目的投入。
但这里要特别注意的是,如果基于现状流程审视IT的投入和价值,会是一个根本性的错误。无数经验表明,流程变革(再造)才是产生价值的核心,业务IT覆盖要基于变革后的流程,而非现状。
当然,我们既不能为了流程而流程,也不能为了IT而IT,支持经营目标,打造组织能力才是核心。
以上就是关于项目管理过程中的5个关键点,项目经理都应该了解全部的内容,包括:项目管理过程中的5个关键点,项目经理都应该了解、卡西亚IT管理系统在打补丁时都支持哪些系统、IT需求如何主动支撑,快速支撑,高效支撑等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)