2023年IT项目管理案例_第1页
2023年IT项目管理案例_第2页
2023年IT项目管理案例_第3页
2023年IT项目管理案例_第4页
2023年IT项目管理案例_第5页
已阅读5页,还剩29页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

项目团队如何拥有高的协调性案例正文:徐家龙最近被公司任命为项目经理,负责一个重要但不紧急的项目实行。公司项目管理部为其配备了7位项目成员。这些项目成员来自不同部门,大家都不太熟悉。徐家龙召集大家启动动会时,说了很多谦虚的话,也请大家一起为做好项目出主意,一起来承担责任。会议开的比较沉闷。项目开始以后,项目成员一有问题就去找项目经理,请徐家龙给出意见。徐家龙为了树立自己的权威,表现自己的能力,总是身体力行。其实有些问题项目成员之间就可以互相帮助,但是他们怕自己的弱点被别人发现,作为以后袭击的借口。所以他们一有问题就找经理,其实徐家龙的做法也不全对,成员发现了也不吭声,由于他们认为我是按你说的做的,有问题你经理负责。团队成员之间一团和气,“找徐经理去”、“我们听你的”成为了该项目团队的口头禅。但随着时间的推移,这个貌似祥和和团结的团队在进度上不久出现了问题。该项目由“重要但不紧急的项目”变成了“重要并且紧急的项目”。项目管理部意识到问题的严重性,派高级项目经理张凤指导该项目的实行。请问:该项目问题出在哪里?徐家龙应当怎么做?分析:1.项目经理的定位我们先澄清一个概念:什么是项目经理。项目经理就是项目中的总经理,总经理的职责是决策,领导。而不是关注所有的事情。本案例中的项目经理犯的错误在我们身边屡见不鲜,其根源最重要在于:1)项目经理定位不准2)团队无明确的沟通计划2.只竖向沟通不横向沟通显然不行作为项目经理,你应当要引导成员互相横向沟通后,无法解决的再竖向沟通或开会协商;这就好比民主集中制,要民主,也要有人说了算,案例中项目经理都是自己拿主意,但他不也许在每方面都是长处,长此以往,团队形成一种风气,压力全转移到项目经理处,项目风险也会越来越大。3.职责、团队、方法论.一个成功的团队是指由不同技能,才华,工作风格和知识的成员组成的士气高涨的团队.项目经理的职责就是将这些人组成团队并激励他们.项目经理的技能应涉及技术技能和管理技能,坚实的技术基础可以在技术方面对团队起指导作用,管理技能有助于沟通和解决问题.管理技能不仅限于技术方面,还涉及解决问题的能力,估算能力,编制计划的能力,人际和沟通能力.所以本案例出现的问题本质是项目经理对自己的职责没有很好的结识,因此在管理团队的方法上也就走了偏路。问题从项目组成员形成了一个习惯(有事找徐...),失去了团队的协做意义,使团队的实际能力得不到体现;到最后使得项目进度出现严重延迟。项目管理案例:项目的开发周期案例正文:一个项目经理在开发一个为期10个月的项目的三个星期后得到客户告知,项目要在不增长成本,不影响范围和质量的情况下,需要在8个月内完毕。请问:项目经理应当怎么做?分析:一、了解客户计划改变的真实因素在做项目的很多时候,客户方会规定项目在不增长成本,不影响范围和质量的情况下,提前完毕,但是一定有他的理由,也许是你的竞争对手采用的措施,也许是我们在做项目的时候有哪些不对的地方,或者是客户碰到新的其他情况不等,但是在客户提出之后,不能明确的答应也不能以强势的态度拒绝,等了解真正的因素后再做打算。

二、向客户沟通假如必须提前完毕任务,要向客户说明其困难,假如公司真的有实力,那就答应他,并适当的拿出协议进行说明,是否在其他方面给予公司补偿。假如公司的把握不是很大,那就站在客户的立场为他考虑,本来十天完毕的任务现在8天完毕,困难时什么,结果会怎么样,是否采用,按照客户的规定完毕部分功能,比如为了迎接上级领导检查,那就把系统的表面工作都做好,要是真正的使用的话,那就把不影响工作进行的部分往后推迟等等,一个项目实行后,所有功能在一定的时间都能使用上的几率不是很大,此外也可以采用在重要功能方面做好,次要方面稍往后放等等方法。

三、从公司自身出发在不影响范围和质量的情况下,提前完毕,我们只有在加班或加人中选择,但是一定要谨慎,由于加人是存在一定的风险的,毕竟项目已经进行了3个月。假如公司实在没有办法的话,那就把部分较独立的功能模块外包出去,当然这是下下策了。四、团队的管理在这个时候,一定要在团队的管理方面做好工作,无论从人员的到位,还是人员的情绪,或者其他方面等等做到恰到好处项目管理中的创新智慧自从中国改革开放、走向世界,她就登上了全球化的互相依存和竞争的舞台。这个舞台催醒了东方巨龙的创新意识。只有从中国制造走向中国发明,才也许有中华的复兴,才会有自立于世界民族之林的能力。

但是创新不能停留在标语上。假如说中国人缺少发明性,你一定不会批准。然而说在中国成功地走到了‘智慧型组织'阶段的公司还凤毛麟角,你大约不会反对。肖知兴在他的《中国人为什麽组织不起来》一书中分析其因素,强调了价值观、信念和文化的力量。的确创新需要有群体智慧和组织文化。本文把这个大问题收缩到项目管理领域,看看情况又是怎么样呢?

项目经理们喜欢这样的赞誉"你驾驭的‘列车'总是准点到达并且不超过能耗指标"。他们通常都是一些做事非常专注,习惯严格按预定框架和程序办事的人。很少从他们嘴里冒出创新这样的词。很不幸,其实这是一种结识上的疏漏。许多公司忽略了组织文化这个因素,不知道如何在项目管理的框架里哺育发明性。项目管理中的发明性并不是与规范化、标准化相矛盾的,它的确存在并有助于时间和金钱的节省。我过去也写过文章,认为项目管理应当是标准化和个性化的融合。

创新的赛场有边界约束许多人有一种误解,认为有发明性的人必须是不受任何拘束的。然而,项目管理结构就像一个发明能力的比赛场地,它的确是有边界的。尽管灌输这样一种充足评价创新价值的理念是重要的,然而领导者仍然需要对创新设立必要的界线。假如没有适当的边界和领导,无序的创新性必然会将项目引向一片混乱。在整个投资组合的范围中保持工作流程的连贯、一致非常重要。这将有助于在全公司内为创新建立一个坚实的‘巨人的肩膀',否则创新只会是胡闹的游戏。这涉及维持稳定的规章制度和行为准则,像制订计划进度和预算等都要有一定的程序,不要随意变更。在项目一开始就应建立好一个总的章程,并且在整个项目过程中维护好这个章程,使其可以得到有效的遵循。这可以避免许许多多问题和麻烦的产生。其实真正的‘创新狂躁'来自高层头脑发热的、糟糕的领导。无疑,公司高管应找到一种办法来哺育发明能力,以提高项目成功的概率。项目自身是一类独特的过程,所以对于具有突破性的发明存在着许多机会,特别是在立项和寻求缩短工期、节省费用、提高质量的努力中。

过度控制克制发明性要使项目能具有发明性,公司高管需有慧眼辨认和启用能评价、鼓励创新精神的项目经理。不要由于有些创新的意见被认为‘说起来容易、做起来难',就对其嗤之以鼻。为了使工作团队有最佳的发挥,一个项目经理需要具有指导、支持、教育和委任的技巧。控制性的领导往往一切自己决定并监视部下的每一个工作细节,这样必然克制发明精神。

有时候简便的技巧比高超的技术还更管用。美国新泽西州的一位创新和领导力征询顾问WayneMorris认为,一个有创新能力的领导人的重要作用是设计和维护好一个支持创新精神的、安全的心理环境。为此,他提出领导者应具有:接受风险的承受力对智者失误(非愚蠢的失误)的经验价值的理解互相交流、沟通的平易鼓励发明激情的能力授予部下一定自主权的民主意识给部下个人事宜留下适当时间的宽容乐观的态度鼓励意外发现的能力对悖于常理的言论的宽容全面哺育创新意识创新的项目管理贯穿项目的全过程,从建立一个创新的框架开始,让大家去思考如何找到一种与众不同的好方法来节省时间和金钱。美国西雅图的一位创新管理顾问DonnaShirley说,以她的经验创新的机会无处不在,不要仅仅满足于技术性的发明,还需要管理的创新以及用人机制的创新。

创新仅仅依靠个别人的天才也是不够的。个别人单枪匹马的创新能力不也许真正把事情做好。整个团队必须具有集体的创新智慧和创新文化。工作流程中设定创新空间。组织应在工作流程中给予创新一定的空间。你可以也应当把创新列入计划之内,但务必将其放在需要的地方。创新这类工作方式的特性就是随心所欲地放纵思维,并为关闭狂想闸门的最后时刻设立好底线。对大多数人而言,在给出限定条件的情况下会工作得更好。项目管理的责任就在于设定合理的边界,给创新留出空间,并让你的团队成员都知道。这将有助于他们最佳地发挥发明性,并且不会无端地浪费资源。要让人们知道遵守工作流程的好处,你必须尊重有创新精神的人,告诉他们在什麽情况下可以做新的尝试并允许犯错误。然而,同样重要的是,也要让他们尊重项目管理的工作流程。一个好的领导者要鼓励创新,但不允许随意破坏工作流程。

软件外包项目中的进度管理案例正文:A公司是一家美资软件公司在华办事机构,其重要的目的是开拓中国市场、服务中国客户,做一些本地化和客户化的工作。它的重要软件产品是由总部在硅谷的软件开发基地完毕,然后由世界各地的分公司或办事机构进行客户化定制、二次开发和系统维护。这些工作除了平常销售和系统核心维护之外,都是外包给本地的软件公司来做。东方公司是A公司在中国的合作伙伴,重要负责软件的本地化和测试工作。Bob先生是A公司中国地区的负责人,Henry则是刚刚加入A公司的负责此外包项目的项目经理。东方公司是由William负责开发和管理工作,William自身是技术人员,并没有项目管理的经验。当Henry接手这项工作后,发现东方公司的项目开发成本非常高,每人天天130美金,但客户的满意度较差,并且每次开发进度都要拖后,交付使用的版本也不尽如人意。并且,东方公司和A公司硅谷开发总部缺少必要的沟通,只能把问题反馈给Henry,由Henry再反馈给总部。但由于Henry自身并不熟悉这个软件的开发工作,也导致了很多不必要的麻烦。为此,Bob希望Henry和William用项目管理的方法对该项目进行管理和改善。随后,Henry和William召开了一系列的会议,提出了新的做法。一方面,他们制定了具体的项目计划和进度计划;另一方面,成立了单独的测试小组,将软件的开发和测试分开;并且,在硅谷和东方公司之间建立了一个新的沟通渠道,一些软件问题可以与总部直接沟通;同时,还采用了里程碑管理。半年后,软件交付使用。但是客户对这个版本还是不满意,认为尚有很多问题。为什么运用了项目管理的方法,这个项目还是没有得到改善?Henry和William又进行了反复探讨,发现重要有三个方面问题:1、软件本地化产生的问题并不多,但A公司提供的底层软件自身存在一些问题;2、软件的界面也存在一些问题,这是由于测试的项目不够具体引起的;3、开发的周期还是太短,没有时间完毕一些项目的调试,所以新版本还是有许多的问题。此时,Henry向Bob提出是否采用公开招标的方式,选择新的、实力更强的合作伙伴。但Bob认为,与东方公司合作时间已经很长了,假如选择新的伙伴又需要较长的适应期,并且成本也许会更高。于是,Henry向东方公司提出一些新的管理建议。一方面,他们采用大量的历史数据进行分析,制定出更具体的进度计划;另一方面,规定东方公司提供具体的开发文档和测试文档(之前William的团队做的工作没有任何文档,给其他工作带来了很多困难);第三,重新审核开发周期,对里程碑进行细化。

又过了半年,新的版本完毕了。这一次,客户对它的评价比前两个版本高得多,基本上达成项目运营的规定。但客户还是对项目进度提出了疑问,认为实时推出换代产品不需要那么长的时间。分析:

软件外包是现在软件工程中较常见的做法。在软件外包工程中,保证质量的进度是很难控制的。对于项目经理来说需要一整套复杂的能力,比如制定计划、拟定优先顺序、干系人的沟通、评价等,每一种能力都与项目的最终结果有直接或者间接的关系。然而,国内的项目经理大多没有接受过正规训练,缺少项目管理方面的专业知识的技巧,往往只是凭借以前的少量经验盲目去做,容易出现各种问题。特别是在管理外包项目时,缺少足够的经验和技巧,往往导致进度不断推迟,而质量无法保证的情况。

前文是一个比较典型的软件外包项目的案例。在这个案例中,我们可以看到现在IT业内许多外包项目的影子。在该案例中,东方公司没有专门的项目经理,是由技术人员William兼做管理。这是国内软件公司经常会出现的问题。最初,出现进度落后的问题时,A公司的Henry与东方公司的William讨论后决定采用项目管理中计划管理等手段,其中涉及里程碑管理。这是控制进度的较常见做法。里程碑管理的引入一般来说,在项目开始时,项目组成员都会对项目制定一个具体的计划。通常情况下,在明确的工作说明书(SOW)和WBS的基础上制定具体的进度计划时,需要采用一些具体的技术。像这种软件外包项目,最成熟的技术是里程碑管理。里程碑一般是项目中完毕阶段性工作的标志。不同类型的项目,里程碑也不同。比如,在开发项目中,可以将需求的最终确认、产品移交等关键任务作为项目的里程碑。本案例中,Henry在接手项目后采用里程碑进行管理是很恰当的但是,要注意的是,每到一个里程碑处,应及时对前段工作进行小结,并对后续工作进行计划调整。对于一些管理效果明显的领域,可以不必投入较多精力。而对于下一步管理过程中也许会出现问题的领域,应给予较多的关注。当然,在软件项目里,进度的变化是较常见的事情。

在本案例中,采用里程碑管理后仍没有达成客户的规定,进度仍然拖后。在这里,就需要考虑另一个因素—质量与进度的关系。质量与进度关系通常,项目管理的前提是保证在预算内、满足质量的前提下,按进度完毕项目。因此,可以看到,保证质量是前提。那么,如何在满足质量的前提下管理进度呢?单纯从项目管理理论知识中并没有一种有效的方式。笔者通过实践,推荐一种较实用的方法。具体环节为:一方面,尽量运用历史数据。在本案例中,Henry应当调查之前的项目情况,将会发现可以类比的情况,事先就可以知道需要管理质量和进度的关系。另一方面,由于此项目是软件外包项目,Henry不能完全掌握项目的资源调度情况,因此缺少对质量的控制。这也是大多数外包工程中最令人难以掌握的地方。在这里,可以采用对进度管理计划添加质量参数的方法,也就是通过参数调整进度和质量的关系。这一做法的前提是要有一定的历史数据。比如,从历史数据中得知,完毕子项目的时间是5天,测试后有15个问题;完毕同样子项目的时间是7天,测试后有10个问题;完毕同样子项目的时间是8天,测试后有5个问题,……以此类推。随着数据的不断增多的,采用两维坐标图,就会得到一些离散的点(不考虑资源的差异),并形成一条曲线,见图1。考虑项目允许的质量范围,对照图中的数据,找出相应的参数。根据得到的参数,拟定一个合适的进度计划。进度与成本的关系在本案例中,Henry发现东方公司进度一直拖后,成本却居高不下。这里就需要了解软件外包项目中进度与成本的关系。很多时候,此类工程大多采用固定总价协议。但由于软件项目的修改比较多,事实上此类协议很像是固定总价加奖励费用,其中奖励费用一般会采用单价协议,即若干元/人天的协议,也就是说,承包商的成本是建立在人力成本估算上的。这样,一些承包商会倾向于迟延进度(或者减少实际投入,导致质量下降)。因此,项目经理需要了解整个协议的情况,最佳参与协议的制定。在此案例中,Henry试图通过引入竞争来提高整个项目的效率,满足项目目的,也是出于同样的因素。特别值得注意的是,有时候,出于竞争的需要,承包商会提供低廉的价格,此时对于进度管理更应当谨慎和完善。

还要指出的一点是,要对学习曲线有深刻地结识。在软件开发工程中,学习曲线(learningcurve)有很大的用途。通常情况,承包商在接到同样类型的软件项目后,第二次会比第一次节省15%-20%的时间。项目经理最佳要了解一下以前类似项目的情况。

综合管理:如何成为一个受欢迎的项目经理程序员的一个重要的职业发展方向就是项目经理,然而,做一个项目经理和做一个程序员是有很大区别的。项目经理需要面对的人和事更多并且更复杂,需要具有更多的知识和技能才可以胜任。

正文项目经理是整个项目的负责人,对项目成败负有直接责任。项目经理需要打交道的各方面的人很多,需要解决的事情也很多,要做一个受欢迎的项目经理更加的不容易。那么,如何才干做一个受欢迎的项目经理呢,我们从Who-What-How这三点出发,来共同探讨这一问题。

Who—受谁的欢迎:

项目经理同时要面对来自内部和外部两方面的对象。外部对象——项目的所有干系人都是项目经理要面对的,内部对象——项目经理的上级领导和项目组成员,也是需要关注的。

What—受欢迎的标准:项目干系人在不同类型的项目中有所不同,比较普遍和重要的涉及:项目发起人、出资人、相关业务部门负责人、最终用户等。对于项目发起人来说,可以保证项目准时完毕、满足功能规定同时又能保证质量的项目经理最受欢迎;对于出资人来说,可以保证项目的费用不超过预算的项目经理最受欢迎;对于业务部门负责人来说,分两种情况,一种是项目的推动对其有利,他们对项目经理的规定与发起人基本一致,另一种情况是项目的推动对其有不利影响(比如改变现有流程、权力回收等),想得到他们的欢迎也许很困难,这个时候项目经理只能尽力减少他们对项目的抵触心理和对项目经理的敌对情绪,以可以接受的代价为其考虑的更加周全,尽量提高受欢迎的限度;对于最终用户来说,可以提供方便易用的软件和全面及时的培训的项目经理最受欢迎。

对于项目经理的上级领导来说,可以保证项目按照进度、成本、质量的规定顺利完毕的项目经理最受欢迎;对于项目组成员来说,可以明确给出项目目的,合理安排分工和分派任务,具有亲合力和容易沟通的项目经理最受欢迎。

How—如何做到:计划制定能力。一个项目涉及到的事情总是千头万绪,假如没有很强的计划能力将很难成为合格的项目经理,要善于制定各方面的计划,并按照计划执行各项工作。随着项目的开展,还要不断的调整和更新相关计划,保证计划的合理性和可执行性。项目控制能力。涉及对项目的范围、进度、成本、质量各方面的监督和控制。善于运用各种分析工具来全面了解项目的进展情况,及时发现项目存在的问题和风险,并采用适当的应对措施,在需要的时候向上级领导报告并寻求支持。时间管理能力。把握项目进展的节奏,合理安排各项任务的重要性和优先级,保证项目组可以定期地交付一些可见的工作产品,以避免项目干系人因长时间看不到项目的进展而给项目组施加不必要的压力。成本控制能力。项目的费用成本也是各方关注的焦点,项目经理要可以运用费用管理工具及时掌握费用花费情况,尽量减少不必要的开销,对于无法避免的用户额外的规定,则要善于争取费用的追加。沟通交流能力。项目经理需要面对方方面面的人,并同他们讨论林林总总的事,因此,顺畅的沟通和交流是必不可少的。项目经理必须要善于根据不同的沟通对象来选择合适的沟通渠道、沟通方式和沟通频率,并在沟通过程中采用适当的技巧获得对方的支持和认可,使得项目可以顺利进行。

团队建设能力。项目不是靠PM一个人来完毕的,需要所有的项目组成员共同努力。作为团队的领导者,项目经理要善于通过各种培训、团队活动、奖励和表彰等手段,加强成员间的互相了解,使得每个成员的力量逐渐整合为一股合力,从而达成1+1>2的效果。

后记

项目经理需要考虑的问题与程序员完全不同,对项目的成败负有完全的责任,必须具有更多的管理技能。项目经理除了要保证项目按照规定顺利完毕之外,还需要面对项目组内外的形形色色的人和事,解决不断发生的各种风险和冲突,因此,项目经理只有具有了更多的知识和技能,才有也许成为一个受欢迎的项目经理。外包仍需要项目管理案例正文:公司外包的网站出了问题,身为公司信息部门主管的何经理最近有点烦。

何经理所在的公司是一家制造行业的民营公司,重要生产管件、轴承等产品,由于地处东南沿海,何经理的老板对于信息化很重视,眼看着一个个行业类网站如雨后春笋般建立起来,何经理的老板也想通过电子商务给公司带来一些新的销售渠道。

虽然何经理所在的公司总体规模不大,但具体到轴承和管件等产品,这家公司在行业内排名还是很靠前的,因此,在何经理建议做一个公司门户网站时,老板觉得,那样还不如直接做一个行业网站,只针对轴承行业。这样一来,不仅可以帮助自己的公司拓展业务,还能帮助同类公司。何经理的老板甚至还在想,行业网站做得好,说不定会给自己的公司带来新的赢利点。但是,何经理所在的信息部仅有三个人,除了维护公司内部的IT系统和硬件之外,他们已经没有精力再做一个行业网站,做网站对于何经理来说,也是一个新的领域,他在技术上并不是很强。做专业的事就要找专业的人,在网站建设上,何经理和老板通过多次沟通,决定把网站建设、运营、管理等所有外包,交其他公司或个人解决。但关于域名、空间等的选用,以及关于网站内容、版面的策划,再到对于市场的分析、目的群体的分析等方面,何经理他们并没有太多的想法,他们觉得,既然花了那么多钱,自己就不用投入太多的人力物力了。此外,何经理所在的公司有60%的产品都销往海外,公司重要针对海外客户。于是,何经理考虑到,一个好的网站就成了一个窗口,向海外客户展示公司产品、宣传公司理念、维护公司形象。并且国外不再通过文本的方式进行贸易,都是运用电子邮件的方式。这样,网站成了与国外客户交流、贸易的最佳方式。所以何经理在策划网站建设的时候,决定在做中文网站的同时推出一个英文版。公司开始策划公司网站,并和国内一家提供网站服务的公司签订了协议,约定该公司为他们建设一个中英文双语版网站,并支付了40多万元的服务费。这家网站服务公司承诺赠送网易、SOHU、TOM等网站的推广一年,并提供.com的域名一个,期限为三年。可是,由于这家网络服务公司未按照约定及时进行网站的注册,就在双方签订协议没几天,本来这家公司承诺给何经理的.com的域名已经被别人抢注。在这种情况下,这家网络公司并没有与何经理商议变更协议的问题,就擅自为他们注册了.net的域名,并在该域名下制作网站。不仅如此,网站制作的进度也大大超过了他们最初的承诺,内容同样存在多处不完善的地方,英文版的超链接更是拖了半年多才完毕。分析:何经理原本想通过一个行业网站推广自己的公司,进而为同行们服务,可是,外包的网站建设一波三折,让何经理有些气馁。他开始怀疑当初是不是该建议老板做这样一个双语的行业网站?即使要做,他又该如何做,是不是完全外包给网络服务公司?本案例所描述的网站外包事项具有良好的出发点、可取的方法和准确的目的,项目实行之所以出现令人不满意的地方,主线因素在于双方存在结识上的差距,表象就是缺少沟通,没有开展有效的项目管理。作为一个直接面向市场销售产品的制造型公司,规模不大,并且60%的产品销到海外,有一个高效的公司网站是十分必要的,出发点很对的,目的可以清楚预见。至于是否建立一个行业网站,要看在轴承生产行业是否有很专业的网站。当然,以排名靠前公司的身份建立一个具有特色的行业网站也不失为好的想法。在信息部只有3名员工的情况下,服务外包是极其对的的一种策略。即便是本公司有很强大的信息化建设力量,外围建设及维护服务往往也是较好的选择。专业化的成果只有通过专业化的服务来获得。换句话说,在网站建设立项初期,目的和方法都很明确,即服务于全球客户,从项目管理的角度分析,也许出现的风险应当较低,也许会出现个别难题,但只要有缜密的实行计划和严格的项目管理,潜在的风险都可规避。其实,单就网站自身建设与维护而言,在公司信息化项目中其难度相对较低,投资也不大。那么,为什么在公司网站建设中还是出现了一系列的问题呢?网站建设之所以一波三折,问题重要就出在项目管理方面。项目虽简朴,但并不意味着建设和运营管理一帆风顺,从而甲方可以撒手不管。正相反,同样也需要按照一个标准的信息化项目来进行管理。虽说行业网站的内容复杂度会高于公司网站,但建设过程大同小异。假如对症下药,在建立行业网站过程中完全可以避免类似情况的出现。具体说来,重要改善如下几点。甲方零工作量的误区网站外包不等同于甲方零工作量。任何项目都需要理清合作各方的工作内容,甲方必须主导项目的进展,以满足各利益相关方的规定。每一个阶段都不也许离开甲乙双方的配合,启动阶段特别如此。至于域名的注册与管理,是一件非常简朴的工作。无需花费太多的人工,不一定外包。

假如公司盼望注册的域名已经被抢注,可以买回或者更换成类似的名称来解决,这不应当成为制约网站开发的一个重要因素。拒绝松散管理每一个信息化项目都不容松散管理。信息化项目通常会有需求调研、设计、开发、测试、试运营、上线和维护几个阶段。各阶段均应按照项目管理金三角设立专人实时跟踪、参与、审查和评价其质量、进度,控制资金投入。

在关键阶段,为避免方向性的错误和工期严重耽误,现场及时监督、指导、讨论和纠正不可或缺。何经理所在团队缺少人力和技术力量,可以考虑委托具有经验的第三方代行其职能。

确立对的的方法论该公司制定的外包策略虽然很对的,但乏于具体实现方法,从而导致大量问题出现。网站建设是一个典型的需求驱动项目,花大力气摸清需求是成功实行的主线。技术实现、版面设计是专业网站建设队伍的强项,但网站的主题、基调、展示思绪和内容重点只能由公司自己说了算。

何经理及其团队不熟知网站内容布局和版面设计在情理之中,但这并不说明他们可以不去协调、组织整个项目。网站是公司的信息窗口,良好的需求分析等于成功了一半。假如何经理有信心自行组织,在网站设计开发之前就应在开发单位的配合下做好。假如没有自行组织的也许,可以寻找一些专业的征询顾问来代为实行,提出多种可靠方案,最后由何经理及其老板选定。

把握关键控制点有了对的项目实行策略、方法与计划,余下的工作重点就是把握住关键控制点。这实际也是项目管理重要的一部分。例如,前文提及的需求分析确认和版面设计审查等都直接关系网站建设的成败。此外,英文版的网站对于该公司来讲甚至比中文版意义更加重大,网站开发队伍未必在语言翻译和英文网站布局方面很强,特别是专业性很强的领域。因此,英文材料的提交、版式的拟定和开发效果的审核都应当是何经理关注的关键点。

选择合格的实行队伍实行队伍的诚信和服务质量直接影响甲方的参与工作量和项目的成功率。从擅自修改域名这一事实来看,案例中的网站开发商不值得信赖。工期迟延和内容不完善显示出该开发商在项目管理和服务品质保障方面很不力。由于缺少精力和经验,何经理的部门无法起到很好的主导作用。

良好的开发商在洞察这些情况以后,应当占据积极,积极采用措施,及时引导并与何经理的团队沟通,共同寻求每个问题的解决方法以实现协议规定的目的,而不是悲观被动地迂回或放任自流。假如继续做行业网站,可以考虑选择更好的队伍。

对的评判网站建设成果网站的制作仁者见仁,不能盼望短期内面面俱到。应以满足最初定位和连续攀升的点击率来评价其优劣。在页面基本框架和展示风格拟定的情况下,作为一个制造型公司应以方便客户为宗旨,让网站访问者最简朴快捷地寻找到想要阅读的信息或完毕网上操作。至于次要的内容,可以分步完善和上载。完善配套的管理制度制度是项目良性运作的保障。众所周知,任何信息化项目不也许由信息部门独立完毕。信息上载、版式调整和内容更新等是长期的工作,每个部门必须各司其职、互相配合,才干保证网站的时效性和生命力。内容不齐全,责任重要在于甲方。网站栏目设计与调整技术上不困难,只要有需求就可以实现。假如有了栏目,缺少内容,何经理应当通过制度和老板这两个利器调动大家的积极性,及时准确提交或者上载有关的信息。假如建设行业网站,该公司是领头羊,更应当在产品信息、行业文化方面及时更新内容,起到风向标的作用,而不能一味的认为是网站建设方的问题。

如何走出项目规划陷阱?案例正文:2023年12月,宁波开云公司与宏研公司签署合作协议,实行SCM(在线供应链管理系统)。但是,直到今年6月份,双方也没有拟定出一个认可的方案,项目的进展几乎陷入困境,用宏研公司项目经理李凯的话说:“我现在已经胆怯接到开云公司CIO张励的电话。”这是为什么呢?何以反复修改解决方案?开云公司是宁波市的一家小型零售连锁公司,总部设在宁波,目前已在宁波下属一些县区设有分部。业务扩张后,公司内却出现了一系列的问题:各门店之间、门店与总部之间、与供应商之间的信息管理系统是不相联接的,各店也是分别向供货商采购,这样一来,开云公司事实上就成了单店经营,一个个店其实就是一个个“信息孤岛”,规模优势和集团优势难以发挥。面对这些问题,开云公司急于借信息技术来提高整体管控能力。最初,李凯为开云公司量身打造了一个以门店为中心的B2B电子商务平台,涉及基于Intranet内网的报表记录系统,基于Extranet外网的e-SCM供应链管理系统等。系统功能涉及在线结算、信息分享(销售、库存、补货、结算)以及品类管理及分析。方案实现了开云公司多家门店与供货商之间的电子订单、对账、经营数据分析、查询等协同商务工作。没过多久,张励就发现,上游供货商出于各自业务记录和分析的需要,会对自己所经营的商品采用一定的分类标准和编码规则,即使同一连锁集团内,各门店所经营的商品种类、商品编码、价格等属性也也许各不相同。所以,方案必须解决一定标准下信息转换的问题,否则B2B电子商务平台就是一句空谈。针对张励提出的问题,李凯把方案做了调整,开发出了异构系统之间的“翻译”模块。不久,张励又提出了新的规定:在总部建设数据中心系统,涉及基于数据仓库的CRM顾客关系管理系统。当然,李凯对项目方案也做了再次调整。每一次方案的调整,对李凯都意味着繁重的工作量,要对开云公司的工作流程仔细调研,制订方案,甚至要与其上游厂商进行沟通,保证方案的可行性。满认为通过几次的调整,这回应当让张励满意了。然而事情又出现了新的变化,张励需要一套BI商业智能系统为公司的决策提供支持。到底怎么做客户才满意?这一回,李凯再也坐不住了。第一,项目方案又要调整,这会是一个较长的时间,并且不知道以后还会如何变化;第二,李凯认为,对于开云公司来说,BI商业智能系统的考虑太长远,目前的数据量太少,项目实行后数据量的增长也会是一个长期过程,没必要现在就做所有规划。作为公司CIO,张励有不同的意见:现在的零售连锁竞争相称剧烈,公司要考虑长远的规划。系统上线后,随着供货商和各门店的数据共享,信息量不断扩大,需要一套BI商业智能系统为公司领导的决策提供帮助。这样才会在竞争中保持不败。项目初期就碰到了如此多的问题,张励认为“用户更喜欢一个能提出个性化解决方案、碰到问题都可以解决的供应商,能根据公司的发展提供符合规定的差别化服务。”而李凯却有自己的苦恼,客户不断规定改变方案,经常把做好的方案推倒重来,解决方案的供应商主线没有办法控制成本且无所适从。更何况,有些方面的规划并非客户所急需。双方各执一词,为我们带出了两个问题:在项目规划上,解决方案供应商与客户之间如何才干更好地沟通和协调?项目究竟应当满足现有的应用需求,还是也要满足未来的应用需求?分析:发现信息化规划中的陷阱开云公司的项目规划案例是一个普遍现象,折射出当前许多公司在软件选型过程中所碰到的问题,而“软件项目规划应当如何做”正是该问题的核心。众所周知,不管做什么事情都需要有一个总体目的和规划,在总体规划下进行目的分解,不断细化阶段性目的和规划,才干保证把事情作对,不脱离正常的轨道,从而让投资得到最大的回报。软件作为一种信息化管理的工具和手段,是为管理服务的,因此它的规划必须可以适应公司的发展,满足公司某一时间段的需要。综观这个案例,当事双方存在如下几个问题值得思考。①项目的目的和范围定义不够明确。不难看出,两家公司在目的上是有些不一致的。开云公司认为他们只要是碰到的问题,涉及以后也许碰到的问题以及对未来的一些想法就应当在本次项目中实现。而宏研公司则认为他们的目的只是解决目前已经存在的问题,过于长远的问题不是他们本次项目需要考虑的。这样就由于目的、范围不够明确,导致双方各自站在自己的角度和立场去想问题,从而产生了一些分歧。②没有进行业务框架梳理,缺少征询环节。本次项目一开始就很仓促,开云公司没做好需求整理及规划就找来软件厂商进行选型,可以说,开云公司只是大约知道他们需要什么,但还不能清楚定义出这次项目的具体范围及未来IT架构整合的问题,这是一个重要因素,也是起因。而宏研公司在作为合作伙伴进行调研时,也只是对现存的问题进行了规划,没有帮助开云公司对整体的业务框架进行梳理,同时也没有从软件公司的专业角度提供一些建设性参考意见,而只是单纯从目前业务需要给出方案,没有从更为长远的角度帮助客户去考虑问题。浅谈房地产项目风险管理一、引言20世纪90年代,我国房地产行业过度膨胀引致整个行业一度萧条的余痛在某些地区尚未消失,今天该行业又再度展现了如日中天的投资气氛。在乐观的投资气氛背后有很多投资者由于无法抵挡风险的袭击而投资失败,因此,对房地产项目实行风险管理就显得至关重要。

二、房地产项目风险产生的因素

房地产是一个特殊的行业,它具有以下特点:投资额大、建设周期长、资金周转慢、变现能力差,涉及到的社会、经济和环境因素多,其投资过程是一种预测未知将来需求而进行产品生产的过程。这些特点决定了房地产业是一种典型的高风险投机行业。另一方面,由于房地产的地区差异、项目差异,涉及的内容不单单是技术问题,尚有很多其它方面的问题,因此,国家很难像针对建筑工程那样去制定房地产项目风险管理的统一规范和规程。这一切都决定了房地产行业的高风险性。

三、房地产项目重要风险

在房地产开发的不同阶段存在不同风险

1、投资决策阶段的风险

投资决策阶段的风险重要有开发区域风险,开发物业类型风险,开发时机风险和开发项目的定位风险。

2、土地获取阶段的风险

土地风险重要来自于土地自然属性、社会属性和土地规划部门对土地使用性质和规划设计指示的不拟定性。购买了土地使用权后,尚有大量的征地、拆迁、安顿和补偿工作。

3、项目建设阶段的风险

项目建设阶段的风险重要来自设计理念的落后、建筑物实用性差、甚至由于承包商建筑技术落后、施工方案与方法不同、偷工减料以及项目监管不负责任等导致建筑物存在质量安全隐患。

4、售管理阶段的风险

这个阶段的重要风险有销售时机的风险、租售协议的风险、自然灾害的风险和意外事故的风险。

五、房地产项目风险管理与控制

1、风险分析

风险分析一般要通过三个环节。一是风险辨识阶段找出风险因素,研究风险因素会导致的后果;二是风险估计阶段,根据已有资料和经验对各风险因素也许发生的概率及对项目的影响限度做出估计;三是风险的评价阶段,采用适当的方法对各种风险因素的影响进行评价,即拟定风险的概率分布。项目管理者联盟,项目管理问题。

2、风险防止

在风险发生前,为了消除或减少也许导致损失的各种风险因素,而采用的各种措施称之为风险防止。风险防止贯穿于房地产开发经营的各个阶段。

在投资决策的阶段,房地产开发公司风险防止的重要任务涉及:

(1)建立高水平、多学科的开发人员队伍。

(2)建立健全风险预警系统。

(3)贯彻执行风险管理责任制度。

在土地获取阶段,开发商应当重视以下几个问题:履行开发商的社会责任,积极积极的与各地方政府管理部门和土地所有者搞好关系,

妥善解决征地、拆迁和安顿补偿工作中碰到的棘手问题。增强合批准识,认真签订各种相关协议,尽量避免协议歧义。

项目建设阶段风险防止的重要措施有:高度重视项目建设中的安全问题,在现场控制中,减少风险源,防止风险扩散,

特别是强化现场质量监控,防止出现质量缺陷和建筑工程质量。及时协调、妥善解决建设过程中的设计、施工、监理、材料设备供应之间的矛盾,使项目的建设顺利的进行

在房地产开发租售管理阶段,为了防止风险,应当特别重视租售协议条款的明确、详尽,并聘请律师或法律工作者审核。

3、风险转移

可以采用工程保险或工程担保的方式来转移风险。

4、风险管理

合理界定项目覆盖的范围,在公司发展规划和战略的总体规定下,用科学的方法和态度进行项目决策,拟定项目目的,避免出现决策失误风险;

编制《项目管理规划》,用《项目管理规划》指导项目的建设和管理;

理顺组织结构,明确岗位职责,建立项目的反馈沟通职能,为风险管理提供组织保障。

5、风险克制

风险克制是在风险发生时或风险发生后采用的各种减少损失限度或缩小损失发生范围的措施,目的是使风险发生时损失最小,风险发生后有挽救措施。

房地产是一种投资大、周期长、内部结构复杂、涉及因素众多的复杂开发系统,影响该系统的风险因素众多,影响关系错综复杂。同时,不同风险因素引起后果的严重限度迥异,项目能否取得预期结果具有很大的不拟定性,因此,在项目风险管理中,应进行科学的、系统的风险分析,风险防止,风险转移,风险管理,风险克制,将风险损失减少到最低限度,保证建设项目取得良好的社会和经济效益③项目方案没有一个总体构架。方案多次修改虽然同用户的项目目的、范围不明确有关,但宏研公司没有帮助一起进行总体构架也逃不了干系。假如宏研公司可以多花一些时间同开云公司讨论总体构架,那么后面所碰到的编码转换、商务智能等问题可以提早被挖掘出来,不至于最后被动应付方案的不断调整。要避免类似案例所产生的问题,重点在于如何科学有效地进行公司信息化的规划。解决问题:信息化规划四步走针对公司信息化规划,我们应如何进行,在每个环节中又应注意什么要点呢?一方面,需要按照公司运营模式和业务特点进行总体规划。从公司的运营模式和业务特点入手,明确了解公司的发展方向、业务模式及其核心竞争力,定义出核心业务与辅助业务,则整个信息化的核心目的就可以体现出来。需要强调的是,除了需要考虑到现有状况之外,还需要可以兼顾未来,也就是说在做这样的规划时,需要为未来的10到2023打下一个基本框架。后期可以随业务做一定的调整和扩充,但整体的框架是不可以随意更动的。当然,这样的工作公司自身未必可以独立完毕,可以找软件征询公司协助规划,提供业内的最佳实践案例作参考,以保证规划的合理性。另一方面,将信息化目的进行分解和排序。建立公司的整体信息化框架,这只是一个框架性的目的,是无序的。我们应当把这些目的细化、分解,根据公司的发展阶段按重要性排序,以拟定什么时候需要完毕什么样的信息化目的。再次,进行IT系统规划。当我们把阶段性的信息化目的都定义清楚之后,就可以进行IT系统的规划,对一些业务边界进行细分,以明拟定义出有哪些IT系统,分别负责什么样的业务,IT系统之间有什么样的联系,需要什么样的建制关系等等。最后,分步实行。通过前面的三步,这时,每个软件应当大体负责的业务范围都已明确,同其他系统的整合规定及未来的功能预留也有了定义,软件选型也会更有目的性,更容易操作,容易通过软件实现管理效益和避免软件投资风险。所以概括来说,这个案例所碰到的客户同软件厂商之间的项目沟通和协调问题,以及到底是满足目前业务还是未来业务的问题,都可以通过总体规划、分步实行来从主线上解决。实践出真知之透过案例看实行项目的实行工作,何以谓之成功?由于软件产品的特殊性,决定了这种项目的成功标准是很难被量化的,验收缺少清楚的数字指标。对于客户而言,在一个协议里面获得最大的管理价值,包含最广泛的业务应用,是他们对成功的见解;而在供应商眼里,项目就是项目,早日验收早日回款,是他们追求的目的。双方立场的差异,导致项目在进行中会出现各种情况影响到项目的验收。如何减少分歧,按期完毕项目,就成为了项目组最大的挑战。一般来说,我认为项目的实行需要遵照以下方针:加强沟通,精细计划,全力推行,运用资源,随机应变。怎么解释呢?“加强沟通”,沟通是应当占据项目组成员最多时间的工作。他们不光要跟客户沟通,还要跟后方的销售人员、开发人员、测试人员多交流,以及涉及了项目组内部的信息互换。实行人员应当是信息的中转和汇总的枢纽,获得的信息量越大,项目现状就越透明,对后续工作的把握就越大。PMBOK中提到,一个项目经理有90%的时间都是在沟通上,可见这项工作的重要性。“精细计划”,这个需要考验PM的功力。一个合理的计划,是项目可以成功的先决条件。PM要最大化了解项目的相关信息,涉及资源、风险、客户特点等等,然后制定出一个适合项目特性,甲乙双方都有能力去实行的计划,并界定出项目边界和里程碑。从这一刻起,就要为项目的最终验收开始努力。

“全力推行”,指的是项目小组成员要明确以验收为中心,计划是准绳的目的,想方设法去按照计划推动项目的开展。这个过程中肯定会出现各种各样的状况,也是项目最复杂,头绪最乱的时候。运用各种手段,来全力保障计划的按期执行甚至提前进行,是项目组所有成员的职责。“运用资源”,资源是什么?只要一切有助于项目推动,有助于最终验收的人、财、物,甚至气候、政治动态等等,都是资源。例如说甲乙双方的高层领导是资源,一台大内存的测试PC是资源,哪怕即将来临的雨季也是资源。项目经理要善于考虑可以运用的资源,敢于申请资源,然后把它用在项目所需要的地方,来解决一切干扰项目进度的问题。“随机应变”,没有到来的时间里总是充满了未知的因素,有不少是风险管理中无法预料的事情。这个时候该怎么解决,解决的后果会产生什么影响,尚有没有更合适的办法都在考验PM。这就需要PM运用其综合能力,涉及经验、技术能力、个人性格等,临时来找到有效的解决意见。以上谈到了项目实行的重要方针,我们再来看几个真实的案例,从中进一步理解。

案例一:

某PM所做的一个局级OA项目,通过前期的工作以后已经进入了试运营阶段,情况良好,正准备验收。这时机关上调来了一个常务副局长,他提出OA中缺少劳资管理的功能,需要补上。PM并没有立即允诺或拒绝,而是找甲方关系较好的人员作了了解,本来此领导本来是主管人事出身,只对这块比较有发言权。PM就找到了这位副局长,提出要为他专门做两张报表,可以从既有数据中进行人事相关信息的分析。领导不久乐,也不再强求需要专门的劳资管理模块。项目进度因而几乎没有受到影响,最终顺利验收。

分析:OA和HRM有关系么?显然差别很大。但是客户是不能随便得罪的,特别是一个刚上任有实权的二把手。这个时候要思考领导提出此需求的因素。新官上任,一般要烧几把火,一个正在进行中的项目当然要留下他的个人烙印。所以说,其实他真正的需求不在于搞劳资管理,毕竟这一块业务以后也不归他主管,其重要目的还是为了树立威信。了解了这一点就好办了,给他两张“量身定做”的报表,既能体现他的个人意志,又表达了对他的尊重,最关键的是开发工作量很小。这个事件中,PM的及时沟通和思考决策,起到了决定性的作用。

案例二:某CRM项目,已经到了试运营阶段,原计划下周二验收。这时PM得知对方主管领导下周三要出国考察,想到对方也许没有心思准备验收的工作,便与对方沟通后把验收时间改到领导回国以后。却不料领导考察了国外的先进管理思想以后,回来决定大幅修改自己的业务管理模式,原有的CRM内容因此有大半失去作用。项目几乎等于要重头再来一次。

分析:重视计划永远是对的的,甚至要想办法让条件成熟的后续工作提前开始。这个案例中的PM就犯了错误。领导要出国,没心思召开验收会是正常的。但是PM应当有很多办法来促成项目的及时验收。例如说找各业务主管对各模块分别书面签字验收,然后只需要领导最后签字确认即可。或者找公司领导报告,争取一笔资金,找个名目通过SALES交给领导(通常情况下项目都有回扣点数),同时谈谈立即验收的事宜。反正是在计划安排的时间内,这种顺水人情领导当然乐意。并且,对于领导去做业务考察这件事,PM居然没有联想到跟自己项目业务的关联,敏感度太低。

案例三:一个PDM项目,需求调研已经完毕,正处在开发阶段。这时客户提出想把PDM和常用的三维设计软件PRO/E进行集成,实现两套软件的数据交互。根据PM的经验和技术人员的反馈来看,这个集成的难度相称大。但PM却一口答应下来,然后向客户提出需要对方配合的工作:请客户方找PRO/E公司,以大客户的身份规定PRO/E提供所需的数据接口。但是进行这种洽谈的话,用户需要提供正版序列号。事实上这家公司所用的PRO/E全是盗版,领导为此踌躇不决。PM更进一步地提出让他们干脆采买几套正版,但是即使是一套正版,价格也在80万以上。权衡再三,最终客户还是积极放弃了这个需求。

分析:出现超过开发能力但又符合项目边界的需求是项目中最让人头疼的问题。这种事情一旦解决不好,很容易让客户对供应商的水平产生怀疑,双方合作产生裂痕,进而影响验收。这个案例中的PM相称懂得随机应变,他答应客户去做这个需求其实是张空头支票。但是通过巧妙的解决方式,最终的结果却是需求被积极放弃,并且客户对PM的好感增长。但是采用这样的办法是有风险的,只有事先作好调查,心里有较大把握,才干付诸实行。

案例四:某公司即将上马一个ERP项目。由于以前该公司曾经有一次实行ERP失败的经历,所以这次的新项目让公司相关部门感到紧张,谁也不想碰这个摊子,一致主张低调启动项目。但是供应商的PM却力主召开一个隆重的启动大会,在得到公司方重要领导的支持后,又找公司高层出面,请到了对方公司的上级主管到会,还在会上宣读了以各个业务部门骨干为成员,某领导为组长的项目实行小组名单。在胆怯项目失败的压力下,小组的各成员和责任领导战战兢兢,尽力配合好实行的每一处工作,还团结一致消除公司内部的杂音,争取早日验收早日完事。这个项目果然进行得异常顺利,在规定期间内达成了各项功能指标,通过验收。

分析:信息系统对于很多公司而言,都不是离开它就干不了事的东西。所以客户中出现散漫或者抵触对待项目的情况比比皆是。这个时候最佳的办法就是把客户跟自己捆在一条船上。在这个案例中PM很强势,他一方面说服了对方领导调配各个重要骨干来参与项目组,然后又让对方的上级主管知晓此事来暗地施加压力。这种情况下的项目干系人,唯一的想法恐怕就是安全过关,能用就行。既然抓住了公司中最能说上话的业务骨干,又减少了他们的心理盼望值。这样的项目,不验收都难。

案例五:某PM主导一个工厂的技术改造项目。天天和项目组成员一起泡在对方的车间里,和对方技术人员面对面交流。通过几个月的埋头苦干,逐步完善了系统,最终达成了可以验收的地步。这时PM去找对方的总工提出召开验收会。总工大吃一惊:“你们事情做完了?做到什么限度了?我怎么不知道?”于是总工又找来重要的几个负责人,开会了解情况。虽然系统已经可以满足对方的需求,但是既然领导专门开会,当属下的自然要憋出几个新想法来。再加上总工的个人意见,这个项目又出现了较大的需求变化,进度被迫延迟了。

分析:做项目切忌“埋头苦干”。当PM很需要会做表面工作。日请示月报告,这样才干让领导重视。不管客户上级主管有没有时间或者爱好了解项目状况,该做的日报、周报、月报、阶段性报告,一定要按期递交到领导的案头,就算对方不看,也混个脸熟。并且做了些什么事情,都是有记录可查的。假如领导不清楚情况,哪怕下面的具体办事人员再认可,对项目也没有太大的作用。信息化项目管理案例先,S集团明显缺少IT战略规划,移动商务项目准备时间达成2年之久,而项目的上马启动会议居然是在项目经理不在场的情况下召开的,由此可见,该项目的整体生命周期是有其随意性的,反映了S集团IT规划的缺失。项目启动会议对于项目是非常重要的,其核心在于对项目经理的授权,明确项目高层次目的和项目可动用资源等。钟剑经理在项目运作当中多次推迟项目上线时间,数据提交的反反复复、项目经理身体力行进行项目加班加点等细节,从侧面反映项目经理对资源的掌控还是不够的,这也是启动会议没有到位的结果之一。

另一方面,S集团移动商务项目的项目计划制定不合理。从案例看来,项目上线的日期出现多次调整,分别是8月16日、9月1日、10月9日和10月16日,按照项目结果,显然项目进度是迟延了,但从主线因素分析看来,S集团移动商务项目总体计划是非常主观的,如项目启动会议定下来的“规定在8月16日30个分公司的各个办事处上线”目的,显然是值得推敲的。从项目管理角度看来,没有看到项目管理计划及其分计划(如范围管理计划、进度管理计划、成本管理计划、人力资源管理计划、沟通管理计划、风险管理计划和采购管理计划)。作为项目经理面对不可实现目的,虽然提出了项目进度方面的意见,但在郑总的一番“谴责”下,“钟剑没有再做任何辩解”,这种“委曲求全”以保项目上马的案例国内比比皆是,事实上反映了项目经理钟剑自身对项目计划方面经验的缺失。作为项目经理是为实现项目目的负责的,既然明知不可行的目的,为什么要勉强为之呢?从整个案例看来,项目缺少一个数据管理计划,数据管理计划涉及数据在项目周期内是如何被管理的,也涉及静态数据、动态数据的格式、收集规定、职责分工、进度规定、数据质量等方面。笔者实行的SAPERP同样面临着数据的难题,除了总部的基础数据(大小物料、BOM、供应商主数据、客户主数据,物料数据由于行业特性,初始化达成上亿条记录,可见工作量的巨大),尚有全国600家门店的静态数据和动态数据,特别是动态数据,涉及到数据的一致性,需要同老管理系统核对比较,困难可想而知。笔者在项目的中期,也就是“系统实现”阶段,在SAP后台配置的同时就召开数据整理启动会议,安排各项工作任务,且采用了有效的策略,如静态数据提前收集、核对进入系统,动态数据多层次、多岗位的核查等。在整个过程中,值得一提的是IT要发挥主导作用,由于数据解决是一件很细致、很烦琐、工作量很大的事情。我们采用的措施是IT有效的运用EXCEL等函数功能,进行批量数据的比对,也取得了比较好的效果。在项目运作当中,我们更多的做法是IT的高度参与,难题由IT解,薄弱环节由IT帮扶,混乱操作甚至由IT托管等,这是数据管理方面引申开来的,对于项目的成功值得借鉴。

再次,S集团移动商务项目风险管理做得很不到位。从案例看,项目的进度风险是很大的,项目实行过程也证明了这一点。自身作为高层强制性的规定项目进度规定是项目的风险,这是建立在“假设”基础上的,假设是项目的风险来源之一,需要在项目运作过程中不断去分析和跟踪。9月15日反映的记录报表与平常手工报表发生严重不符,事实上也是没有做好风险辨认、风险分析和风险应对措施等方面工作。其因素分析是“上线前销售渠道分类没有按照标准统一的严格规定执行”,这就是风险啊。

再次,S集团移动商务项目的沟通管理也需要总结。8月11日,数据采集只有一半的办事处回复了,并且数据不是按照标准规定提供的,反映了沟通的不到位。对于项目不同的工作要有因地制宜的沟通方法和沟通技能,从数据采集角度看,完全可以通过正式的、书面的、模板化的规定终端进行数据收集。当项目出现了两次进度迟延后,9月22日,高层让钟剑就数据整理的困难在全国销售会议上报告,间接说明项目经理在沟通管理上及其被动。作为项目经理的钟剑要建立不同级别的项目会议,如项目例会、项目评审会议、项目进展会议、项目风险分析会议、项目决策会议等等,通过及时、有效的专题会议形式完全可以把项目沟通工作做好。此外一个侧面细节值得关注,在拟定最后项目上线日期10月16日时,项目总监欧阳雪对许建国、王新水的一段话可以看出,项目的历史沟通频次还是不够的。

然后,项目变更控制缺失。有个细节,10月8日,项目经理钟剑为了调整项目上线日期,以辞去项目经理作“危险”,可见项目变更管理在S集团移动商务项目还是没有做到位的。对于变更需求,完全可以按照正式的变更管理流程进行。本案例也反映了项目变更管理委员会等变更决策结构还是没有在项目中建立。作为项目经理是“集成者”、“综合者”,需要坚定的信念和项目流程管理经验。从案例看来,项目经理这方面意识是比较薄弱的。

最后,S集团移动商务项目也存在很多亮点,如项目经理钟剑的项目收尾工作还是可圈可点的,在项目成功上线两周内,他总结了近三个月的项目问题,整理了一套更完善的项目实行方案,体现了项目经理的综合能力,也反映了项目管理重视历史信息和经验教训的特点。又如团队建设方面,项目经理的最终项目上线日期变更邮件,其中反映的国庆长假的集体加班,也涉及个大区的项目人员的表现可圈可点,可见项目整体士气不错,项目经理功不可没!浅谈新疆高等级公路建设中的工程变更管理工程变更是公路工程协议管理的重要内容之一,由于施工过程中的工程变更,将对施工进度和工程造价产生很大的影响,因此应尽量减少工程变更,假如必须进行工程变更,则要严格按照国家的规定和协议规定的程序进行。新疆吐一乌一大高等级公路及乌一奎高速公路是按FIDIC条款,采用三级监理管理机构进行协议管理,现就建设中的工程变更管理谈谈自己的结识。

1.

工程变更的定义及提出

凡对协议文献、设计图纸(含已批准的施工图)涉及的各种工程的形式、位置、尺寸、数量、质量及标准进行修改和改变,均称为工程变更。

工程变更产生的重要因素有其主观因素和客观因素。主观因素,如勘察设计工作粗糙,以致在施工中发现许多招标文献没有考虑或估算不准确的工程量,因而不得不改变施工项目或增减工程量;客观因素,如发生不可预见的事故,自然或社会因素引起的停工或工期迟延等,至使工程变更不可避免。

工程变更的提出形式有:业主对原设计进行变更;设计单位提出变更;监理工程师提出的设计变更;承包人提出的工程变更。

构成工程变更的重要事项:

(1)更改工程任何部分的标高、线型、位置和尺寸;(2)增减协议中给定的工作量、质量、工程的性质;(3)改变有关工程的施工时间和顺序;(4)其他有关工程变更需要的附加工作。

2.

工程变更的确认及解决程序

2.1

工程变更的确认

由于工程变更会带来工程造价和工期的变化,无论任何一方提出工程变更,均需由监理工程师确认并签发工程变更指令。工程变更发生时,监理工程师要及时解决并确认工程变更的合理性。

2.2

工程变更的解决程序

认真解决好工程变更具有重要意义,一旦解决不好常会引起纠纷,损害业主和承包人的利益,一方面容易使投资失控,为了适应竞争剧烈的建设市场,承包人通常在投标或谈判时让步,而在工程实行过程中通过工程量的变化、索赔获取补偿,都有也许最终超过本来的投资;另一方面,工程变更容易引起停工、返工现象,对进度不利;第三,频繁的变更还会增长监理工程师的协调工作量;此外对协议管理和质量控制也不利。因此对有效控制和管理非常重要。

这两条公路为了加强对工程变更的管理,制定了工程变更的分类、审批权限和审批程序。

(1)根据工程变更的内容和金额,将工程变更分为:小变更、一般变更、重要变更、重大变更。并根据分类拟定监理组、驻地监理处、总监代表处、业主的审批权限。

(2)变更的审批程序。为了更好地控制工程变更,所有变更应由申请的部门提出变更因素、图纸和增减金额的报告,且均需监理工程师审查,并建立了完整的变更审批程序。详见下面的框图。

监理工程师审查变更时,无论哪一方提出的工程变更,都应与业主与承包人进行适当的协商,特别是一些费用增长较多的工程变更项目,要与业主进行充足协商,征得业主的批准才干批准。

由于某些特殊情况如按程序审批,有也许导致对工程的不利影响,乌一奎高速公路协议管理中规定:特殊情况可由有批准权限的监理部门口头批准,7天内由审批变更的部门书面确认并补齐变更手续。同时还规定业主书面批准的变更,由总监代表处签发变更令。

3.

工程变更的估价与方法

3.1

工程变更的估价

3.1.2

估价的环节

(1)监理工程师应得到业主批准的关于对规范或协议工程量所要进行的变更及费用估算和变更的依据和理由的授权,在FIDIC条款中已明确规定了监理工程师的权利。

(2)监理工程师在与承包人及业主协商后,由监理工程师商定一个合适的单价或价格,如协商不成,监理工程师决定一个其认为合适的单价或价格,并告知承包人及抄报业主。假如上述单价或价格未取得一致意见或决定之前,监理工程师可决定一个暂定单价或价格。

(3)监理工程师有拟定单价的权力,但是工程量清单(涉及计日工费率表)中的任何项目的单价或价格也不得作任何变更,除非该类变更单独计算其价值已超过协议价的20%,以及该项下实际施工的工程量超过或少于原协议价已报价的协议工程量的25%。

3.1.2

超过15%的变更

假如监理工程师在签发整个工程的移交证书时,发现由于工程变更和工程量清单上实际工程量的增长或减少(不涉及暂定金额、计日工和价格调整),使协议价的增长或减少合计超过有效协议(指不涉及暂定金额、计日工的协议价格)的15%,在监理工程师与业主和承包人协商后,应在协议价格中加上或减去承包人与监理工程师议定的一笔款额。若不能达成一致意见时,则由监理工程师考虑承包人的工地费用及总管理费开支,拟定此数额(此数额仅以增长或减少有效协议的15%为基础)。例如吐一乌一大高等级公路由于变更多,决算金额已超过协议价的15%,根据协议条款,监理工程师与业主、承包人协商后,调整了原协议价。

如当承包人接到变更指令后14天内不向监理工程师提出适当的变更单价和价格意向,将视为该变更不涉及协议价款的变更,不进行估价。因承包人自身因素(过失等)导致的工程变更,承包人无权追加工程款。

3.2

工程变更的估价方法

(1)协议中已有合用于变更工程的费率及价格,按协议已有的费率及价格计算、变更协议价款。

(2)协议只有类型似于变更工程的费率及价格,可参照此费率及价格拟定变更单价,变更协议价款。

(3)协议中没有合用或类似于变更工程的费率及价格,由承包人、监理工程师与业主适当商定后,由监理工程师和承包人商定一个合适的费率及价格作为结算的依据,如商定不成,监理工程师有权拟定其认为合适的费率及价格。费率及价格拟定的合适与否是导致承包人索赔的关键。

(4)监理工程师如认为必要或适宜时,可以指令任何变更工程按日工方法进行工程估价变更。对这类工作应按协议中涉及的计日工作表中规定的项目及承包人在其投标书中对此所定的单价和价格支付承包人费用。

(5)监理工程师将拟定的单价或价格意向告知承包人或承包人将单价或价格意向向监理工程师提出后,14天之内如监理工程师无不合法理由不确认或承包人无提出异议,均视为所提出的单价或价格意向自行生效。

4.

工程变更的支付

吐一乌一大高等级与乌一奎高速公路为了加强对工程变更的支付管理,规定无变更令的工程变更不予支付。当接到变更令,变更工程实行完毕后,经监理工程师确认后,在当月的中间计量中支付。

但在实际工作中,由于某些工程变更涉及金额大、施工期长等因素,为了加快施工进度,减少承包人的资金垫付,可以先根据监理工程师暂定的单价或价格,根据工程的进度先行予以支付。例如:上述例子中乌一奎高速公路新增的排水工程,实际支付中可暂按协议中的单价或类似的工程单价,以千米为单位,按实际施工进度先支付,再根据工程变更的批复进行修正。这样就保证了承包人有资金投入后续工作,加快施工进度。但这样同时增长了工程变更管理的难度,这就需要建立完善的工程变更台帐,根据批复的部门,按变更令的顺序排列,做好变更支付的记录工作,避免漏计、反复计量。可运用计算机采用适当的软件来进行这项工作,笔者使用Execl软件进行变更记录工作,即清楚,又不会犯错,提高了工作效率。

5.

结束语

吐一乌一大高等级公路及乌一奎高速公路由于在工程变更管理中,方法得当,措施有利,执行严格,有效地控制了工程造价,取得了较好的效果。但有时由于工程变更审批过程中文献传递速度慢、部门间协调不及时等因素,导致时间上的延误,建议在变更文献下发同时送达承包人及监理工程师,并定期召开由各部门参与的工程变更协调会,加快变更的审批速度风险管理与管理信息系统建设关于工程建设项目管理系统建设风险的讨论越来越多了,风险以及风险管理这两个概念,大家也许都有自己的理解,但是这种理解是否可以成为一种共识,不得而知。因此,本文希望就这个问题进行一些有关的探讨,旨在强化理解和增长它们在实际工作中的应用。

什么是风险?

尽管风险管理的理论已有了几十年的历史,但由于风险的普遍存在以及风险管理在各个行业中的专门化,风险管理人员会根据自己特定的活动范围,对风险给出不同的定义。对风险进行定义是必要的,它在一定限度上指出风险的对象和目的。下面给出有关风险的两个定义。风险管理的经典著作《RiskManagementandInsurance》将风险定义为:给定情况下那些也许发生的结果的差异性。

保险理论中有关风险的定义为:风险是对被保险人的权益产生不利影响的意外事故发生的也许性。根据风险理论的研究,风险的一般性定义为人们对未来行为的不拟定性而也许引起后果与预定目的发生的负偏差,这种负偏差是指在特定的客观条件下,在特定的期间内,某一实际结果与预期结果也许发生差异的限度,差异限度越大,风险就越大,反之则风险越小。这种偏离可由两个参数来描述:一个是偏离的也许性,即事件发生的概率;一个是发生偏离的方向和大小。因此,又可以将风险定义为:风险是某种不利事件或损失发生的概率及其后果的函数,可以用下列公式表达:R

=

f(P,C)(其中:R表达风险的大小;P表达不利事件或损失发生的概率;C表达该事件发生的后果,即偏离的方向或大小。)

因此,综上所述,我们可以将管理信息系统建设的风险定义为:在特定的条件及时间之内,管理信息系统建设的实际结果与系统建设预期的目的之间也许发生差异的限度。

风险因素、风险事件和风险损失

1、风险因素风险因素是指能增长或产生损失频率和损失限度的因素,是对象风险产生的内在的、间接的因素。

2、风险事件风险事件是指损失的直接因素或外在因素。风险之所以会导致损失,重要是由于风险事件的发生导致的;假如风险事件没有发生,则不会导致风险损失。

3、风险损失是指某一结果也许发生的与预期结果的负偏离或差异限度,所谓损失,在风险管理中是指对风险主体的非故意的,非计划性的和非预期的某种价值的减少。这个定义中涉及两个重要要素:一是非故意的、非计划性的和非预期的;二是价值的概念,这种价值不一定表现为经济价值。缺少其中的任何一个要素,均不构成风险损失。管理信息系统建设风险的特性.

风险的特性是指风险的本质及其发生规律的表现。对的结识风险的特性对于公司管理信息系统建立风险机制、加强风险管理、减少风险损失具有重要的意义。

一、客观性

风险是一种普遍的客观存在,人们既不能拒绝也不能否认它的存在。风险存在于客观事件发展变化的整个过程中,无时不有无处不在。我们必须认可和正视风险的客观存在,并且采用积极的态度,认真对待风险;

二、可预测性

风险是可以预测的。我们可以根据以往发生的类似事件的记录资料或者别人的经验,通过度析和研究,对某种风险发生的也许及也许导致的危害进行预测和评价,在此基础上进行风险控制和管理。管理信息系统建设的风险完全可以通过借鉴其它的系统建设的情况进行预测和判断,对突出的风险因素进行控制。

三、损失性

风险的发生必然会导致损失。对于管理信息系统建设而言,风险导致损失是肯定的,并且这种损失有时侯很难估计它的大小,有的风险导致的损失对系统来说甚至也许是致命的,使系统建设完全归于失败,最后无法产生任何效益。

四、结果的双重性

虽然管理信息系统建设的风险必然导致损失,但是假如可以对这些风险进行有效的控制,可以变不利为有利,对系统质量带来巨大的回报,甚至风险越大,克服风险后带来的正面价值也越大。这就是所谓的“风险越高,利润越丰”的道理。因此,对于管理信息系统来说,只要可以对系统的重要风险因素进行有效的控制,一定可以收到意想不到的效果。

从国内外发生的大量的事实可以看出,管理信息系统建设的风险管理能力在一定限度上决定了系统建设的成败,其中的风险不仅表现在技术和基础设施这些硬件方面的驾御能力,更加突出表现出来的是关于人、组织和制度方面的因素,对这些因素加强管理,找到问题发生的主线因素和有效的解决方法是成功的关键。新产品开发中的风险评估新产品开发是一个复杂的、动态的、连续的过程,其中涉及到大量的信息收集、分析、筛选及传递,各种模式方案的选择与拟定,各种要素资源的投入与配置,新产品生产及营销战略制定等一系列的工作.这些工作都不同

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论