案例展示

这里有最新的公司动态,这里有最新的网站设计、移动端设计、网页相关内容与你分享!

项目管理系统案例?

  风险并不是一发生就消失了.首先,历史经常会重演,只要引发风险的因素没有消险,风险依然存在,它很可能在别外某个时候跳出来影响项目进行.其次,对于整个项目来说,发生问题则意味着系统状态发生了变化,这种变化往往带来新的不确定因素,引发新的风险.对于项目而言,风险不仅仅意味着问题的隐患,风险与机会并存,高风险的项目往往有着高的收益相反,没有任何风险的项目(如存在的话),不会有任何利润可图.作为项目经理,要管理好项目中的风险,避免风险造成的损失,提高项目的收益率.

  项目风险、技术风险和商业风险,其中商业风险又可分为市场风险、策略风险、销售风险、管理风险和预算风险。

  1.没有正确理解业务问题。2.用户不能恰当地使用系统。3.拒绝需求变化。4.对工作的分析和评估不足。5.人员流动。6.缺乏合适的开发工具。7.缺乏合适的开发和实施人员。8.缺乏合适的开发平台。9.使用了过时的技术。

  2.住处系统没有与组织战略相结合、对用户没有做足够的理解、帮助手册编写得不好、用户培训工作做得不够。

  6.技术经验不足、缺乏技术管理准则、技术人员的市场调研或对市场理解有误、研究预算不足、组织实力不够。

  7.对组织架构缺乏认识、缺乏中长期的人力资源计划、组织不重视技术人才和技术工作、行业人才紧缺。缺乏远见、没有市场和技术研究、团队庞大陈旧难以转型、缺乏预算。

  2017年1月5日星期四晚19:00-21:00线软考最新考试动态、考题趋势,专业讲解软考与个人的发展关系,给个人职业道路上带来哪些优势。一对一现场答疑,解决与会成员软考相关疑问,指导制定管理转型新规划。

  成本效益分析在可行性研究报告中用于评估系统的开发成本与效益的可行性。效益分为有形效益和无形效益,有形效益可以用货币的时间价值、投资回收期、收入、投资回收率等指标进行度量。无形效益是难以或无法用某一计量单位进行计量的效益。例如:企业的信息化推动企业市场扩大,市场响应速度加快,市场有形效益增加;而无形效益包括对企业形象的提升和对社会的价值增加,从长远上为企业带来不可估量的价值。

  评估项目在成本效益上是否可行。首先要估算成本,确定项目投资额度,成本估算会在后面的成本管理中详细讲解。成本效益分析有贴现的分析评价方法和非贴现的评价分析方法。

  贴现的分析评价方法,是把货币的时间价值考虑进去。主要是因为项目投资在前,项目收益在后,任何一个项目的收益和成本不可以直接相加,必须将货币的时间价值考虑进去,将不同时间点的成本、收益按一定的贴现率换算成同一时间点的成本、收益进行计算。货币的时间价值就是指当前所持有的一定量货币比未来获得的等量货币具有更高的价值,也可被看成是资金的使用成本。 资金不会自动随时间变化而增值,只有在投资过程中才会有收益。例如:甲某持有现金10000万元,持有的现金不做任何使用,也不存入银行,此时现金不会产生任何增值。甲某只有把持有的现金投入生产或是借给别人再投入生产,才能带来价值增值。

  贴现和计息密切相关,我们接触更多的是计息,例如银行存款到期,银行需要按利息率支付给存款客户,计算利息的过程就是计息。计息是将现在的货币存入银行,到未来某个时刻收回,银行支付这段时间的货币增值额;贴现就是计息的反过程,项目投资后,将项目在未来某个节点的收益现在就收回,计算收回款项时就要扣除这段时间的货币增值额。

  利息的计算方式分为单利和复利,单利仅以本金为基数计算利息,即不论年限有多长,每年均按原始本金为基数计算利息,已取得的利息不再计算利息。单利的计算公式为:

  贴现就是将将来某一时点的资金额换算成现在时点的等值金额。折现时所使用的利率称为折现率(贴现率)。

  净现值法是计算项目未来现金流(未来收益)的折现值与项目投资成本差值,然后根据差值的大小来评价投资方案。净现值为正值,投资方案是可以接受的;净现值是负值,投资方案就是不可接受的。净现值越大,投资方案越好。净现值法是一种比较科学也比较简便的投资方案评价方法。

  净现值法假设项目运营后每年都有现金流入,并把原始投资看成是按预定贴现率借入的,当净现值为正数时偿还本息后该项目仍有剩余的收益,当净现值为零时偿还本息后一无所获,当净现值为负数时该项目收益不足以偿还本息。

  采用净现值法评价投资方案,需要预先给点折现率,而给定折现率的高低又直接影响折现值的大小,在投资制约的条件下,净现值的大小一般不能直接评定投资额不同的方案的优劣。因为,投资额度不同时,还需要考虑投资效益费用比。例如:方案甲投资100万元(现值),净现值为50万元,方案乙投资10万元(现值),按同一折现率计算的净现值为20万元。可以认为两个方案都可行。但是,在资金有限的情况下,不能因为方案甲的净现值大于方案乙的净现值,就说方案甲优于方案乙。因为方案甲的投资现值为乙方案的10倍,而其净现值只达2.5倍,如果建设10个乙方案项目,则净现值可达200万元。

  国家数字复合出版系统工程发布管理系统项目投资720万,项目建设周期为3年,预计项目建成后,四年内每年末净现金流入量总和为2000万,假设年利率为10%,年复利一次,计算该项目的净现值。

  该项目的净现值为正值,说明该项目除能达到规定的基准收益率之外,还能得到超额收益,说明该方案是可行的。

  净现值率(NPVR,Net Present Value Rate)是项目净现值与项目投资总额现值的比率,用于表示单位投资现值所能带来的净现值,净现值率小,单位投资的收益就低,净现值率大,单位投资的收益就高。

  内部收益率法(Internal Rate of Return,IRR)是用内部收益率来评价项目投资财务效益的方法。内部收益率是指项目流入资金的现值总额与流出资金的现值总额相等的利率,也就是求净现值(NPV)等于零时的折现率。

  (1)首先计算投资折现值和现金流入折现值,两者之差为净现值。如果净现值为正值,就要采用这个净现值计算中更高的折现率来测算,直到测算的净现值正值近于零。

  (2)再继续提高折现率,直到测算出一个净现值为负值。如果负值过大,就降低折现率后再测算到接近于零的负值。

  内部收益率在考虑了时间价值的情况下,使一项投资在未来产生的现金流量现值,刚好等于投资成本时的收益率。内部收益率越高,说明你投入的成本相对地少,但获得的收益却相对地多。

  非贴现方法不考虑货币的时间价值,把不同时间段的收支看成是等效的。非贴现分析方法主要是计算投资回收期。投资回收期指标所衡量的是收回初始投资的速度的快慢。在只有一个项目可供选择时,该项目的投资回收期要小于决策者规定的最高标准;如果有多个项目可供选择时,在项目的投资回收期小于决策者要求的最高标准的前提下,还要从中选择回收期最短的项目。

  投资回收期的计算分为两种情况,一种情况是不考虑货币的时间价值,称为静态投资回收期;另外一种情况是考虑货币的时间价值,称为动态投资回收期。

  静态投资回收期是不考虑资金的时间价值时收回初始投资所需要的时间,计算出的静态投资回收期应与行业或部门的基准投资回收期进行比较,若小于或等于行业或部门的基准投资回收期,则认为项目是可以考虑接受的,否则不可行。其计算公式为:

  静态投资回收期 = (累计净现金流量出现正值的年数-1)+ 上一年累计净现金流量的绝对值 / 累计净现金流量出现正值年份净现金流量

  国家数字复合出版系统工程发布管理系统项目投资720万,项目建设周期为3年,预计项目建成后,四年内每年的现金流入为200万、400万、500万、900万,请计算该项目的静态投资回收期。

  动态投资回收期是把投资项目各年的净现金流量按基准收益率折成现值之后,再来推算投资回收期。其计算公式为:

  动态投资回收期=(累计净现金流量现值出现正值的年数-1)+ 上一年累计净现金流量现值的绝对值/累计净现金流量出现正值年份净现金流量的现值

  国家数字复合出版系统工程发布管理系统项目投资720万,项目建设周期为3年,预计项目建成后,四年内每年的现金流入为200万、400万、500万、900万,假设年利率为10%,年复利一次,请计算该项目的动态投资回收期。

  许多人对 Worktile 的认识,都是从项目管理开始的。那么今天我们就来聊一聊什么是项目管理, Worktile 是如何帮助企业将项目管理做到极致的。

  项目管理是项目的管理者,在有限的资源约束下,运用系统的观点、方法和理论,对项目涉及的全部的工作进行有效地管理。

  对企业而言:有效的项目管理方法,可以将项目的耗时有效降低 10% 以上,并能够节约企业资源,直接为企业效益作出正向贡献。

  对管理者而言:项目执行中能够有效地掌握项目进程。项目结束后还能沉淀 企业数字资产,为今后的优化升级提供数据支持和经验模板。

  对员工而言:帮助员工把握工作重点,让项目协作权责分明、分工清晰、流 程有条不紊;有利于员工个人能力的发挥,学到更多东西,增强团队凝聚力。

  托尔斯泰说:“幸福的家庭都是相同的,不幸的家庭各有各的不幸”。同样, 失败的项目管理原因千差万别,而成功的项目管理,我们总能够找出一些共性。Worktile 团队在研究了众多案例之后,总结出了如下的基本要素:

  流程可视化:把工作拆分成小块,一张卡片写一件任务,再把卡片放到墙上。每一列都起一个名字,显示每列任务在流程中处于什么位。

  限制 WIP(work in progress):明确限制流程中每个状态上最多同时进行的任务数

  看板式任务管理是一种较为常用的协作手段,以项目单位,让所有人参与进来,了解工作进度,负责人等信息。既有利于项目经理对整体的把控,也有助于 每个参与者明确自己的职责。

  还有项目甘特图(Gantt chart),燃尽图,让项目可视化,还可多人协作 编辑或查看,进度一目了然。

  在任务详情中,我们可以设置负责人、项目开始/截止时间等基本信息;还 可以进行子任务创建、任务分享等操作;简洁方便的对日常事务进行管理。

  实时数据展现,支持项目内统计和任务全局统计,通过多维度统计图表清晰 展示任务情况,企业、项目及成员进度,一目了然。

  统计项目任务完成情况/工时/进度信息,快速掌握该项目完成进度及延误 率,成员的任务量以及完成度。

  系统内置多个统计图表,分别从企业、项目、成员等多维度进行统计数据展示。此外,还可以自定义任务统计图,按企业、项目、成员不同级别,对任务情况进行更细节展现。

  专为工作场景所打造的企业内部沟通IM,提供一对一私聊、多人群聊等多种沟通方式。消息数据在Web端、电脑客户端和手机移动端在线同步并永久保存。

  此外消息还和任务、日历、网盘等13个应用之间打通,大大降低沟通成本,打破企业内部信息不对称。各功能模块消息助手,不错过每一条与自己相关的通知提醒。

  提供企业网盘和个人网盘,存储空间无上限,以文件夹的形式对繁多的文件进行分类和管理,构建企业知识库,与成员进行资料共享,支持自定义成员网盘操作权限。

  由于官网项目并非全员参与,所以在创建项目时我们将其创建为私有项目——只有参与人可以才有权限参与项目。

  点击【设置】-【项目设置】-【成员管理】,私有项目中,可以在【项目设置】下添加项目成员,并为每个成员分配不同的权限。这里的权限系统默认提供“管理”、“编辑”、“只读“三种权限,“管理”包含项目的最高权限,可以管理项目和任务;“编辑”主要对应项目成员的操作权限,可以操作任务;“只读”主要用于设置某些成员只可见项目内容,以及关注或评论任务。企业还可根据所需在后台自定义更多任务权限。

  我们将整个官网设计流程划分为:【原型设计】-【内容填充】-【UI设计】-【WEB研发】-【BUG反馈】,通过新建任务列表完成项目的流程划分,并在每个分栏下面新建对应的任务。

  当“官网首页”的原型设计完成之时,就可以把该任务拖动到【内容填充】的流程中,并由产品运营负责“官网首页”的内容填充。

  项目燃尽图:燃尽图是用于体现剩余工作量的工作图表,由横轴(X)和纵轴(Y)组成,横轴表示时间,纵轴表示工作量。这种图表可以直观地预测何时工作将全部完成,常用于软件开发中的敏捷软件开发方式,也可以用于其他类型的工作流程监控。

  项目任务周报:点击【任务统计】-【任务周报】,成员可以按周查看项目任务的延期、新增、完成情况,常运用于研发周迭代场景。

  项目工时统计:点击【任务统计】-【工时统计】,可以查看项目每日预估和实际工时趋势、项目任务工时明细。项目任务工时明细中记录了此项目中任务的负责人、截止时间、预估工时、实际工时和工时差值。

  我们都听过许多关于“产品故事化”的论点,我支持这一论点,因为这是在研发和产品设计趋于同质化的今天,形成产品竞争力的核心手段。而一个好的产品,应该是有灵魂的,这也是一个产品能够展现出生生不息的生命力的前提。Worktile背后的设计思想有很多,这也是Worktile在“好用”之外,能做到“优秀”的主要原因。

  沟通先行:由于分工不同导致的信息传递不及时、信息不对等等情况是企业协作过程中最常见也是最主要的问题。Worktile的设计理念中,永远是沟通先行,努力提升沟通效率并着力于建立起有效的沟通机制。

  成员聚焦:企业作为一个共同体,所有成员都应聚焦于同一目标,才能实现最终目的的达成。基于这种观点,Worktile落地了OKR目标管理方法。

  项目流程化:清晰的项目流程,是项目管理成功的要素。Worktile目前的项目管理还存在诸多可以优化的细节,这也会成为我们产品改进的主要方向。

  高度自定义:企业的业务、规模、制度等千差万别,支持高度自定义化,才是项目管理系统匹配企业需求的根本。

  Worktile 客户成功顾问将以卓越的专业性和热情服务,解答客户疑问,听取客户反馈,提供专业的产品指导与培训。同时结合企业组织架构、工作要求,协助梳理业务流程,打造全方位的解决方案,通过Worktile 帮助客户持续获得价值与成功。

  Worktile 上线年来,在数据安全、账号安全、运维安全等多方面从未出现过事故,这背后是研发团队对安全的执着追求。

  老高承接了一个信息系统开发项目的项目管理工作,在进行需求分析和设计后,项目人员分头进行开发工作,期间客户提出的一些变更请求也由各部分人员分别解决,各部分人员在进行自测的时候均报告正常,因此老高决定直接在客户现场进行集成,但是发现问题很多,针对系统个部分所表现出来的问题,开发人员又分别进行了修改完善,但是问题并未明显减少,而且工作和产品版本越来越乱。老高的项目管理方式出了什么问题?

  本来本地进行的测试到客户现场测试 这件事本身就存在很大的问题。心存侥幸,想当然是项目管理的大忌。

  系统的任何一个修改都有可能对整个系统造成影响,所以共享与变更管理,课题管理等要做到全项目成员共知才行。

  在具体的信息系统开发项目中,由于项目本身的特点,经常可以分而治之。但古人云“合久必分,分久必合”,对于分而治之的几个parts,最终交付时,都得合而为一。由此,引出了项目管理工作中的一个非常重要的内容,就是统筹管理。为什么市场经济,还需要国家调控的存在,道理是一样的。

  从文字描述的内容来看,老高的项目管理方式,缺乏的就是这个统筹管理,虽然从各个parts来看,负责各parts的单元,运作都非常良好,但在整理控制上,老高缺少得太多。

  第一、对客户提出的变更,文中看不出来走了变更流程,各部分人员解决后,也没对修改的内容、新增的内容做好文档记录,也没对由于修改可能导致的问题进行预估;

  第二、在客户现场集成,发现了问题,还是分别进行修改完善,各做各的,负责各parts的各小组之间,没有沟通;

  第三、很明显的,缺少整体的版本控制,PartA 的v1.2是否能和 PartB的v1.2完美融合?谁知道呢?

  从上面可以看出,老高在该项目的管理中,在整体管理、变更控制、版本控制、有效沟通上都存在问题。且在客户现场进行集成,这本身也有很高的风险,毕竟成则好,不成则会使得客户对己方的研发能力产生严重的质疑,而客户的质疑对项目的顺利验收的影响也是非常巨大的。

  测试的目的是为了发现问题和完善产品,但在此项目中,测试只在每个环节中进行,而没有进行联合测试和集成测试,这样就不能有效保证系统集成后的效果,各个环节的沟通没有进行,各自为政,只能导致功能的不完善和问题的层出不穷。所以老高需要做一个测试流程规划来进行所有测试。

  同时老高在产品的版本管理上存在很大问题,可以说就没有进行版本管理,这样就不能保证每个参与人员所采用的版本是否致,这也导致了测试的失败,所以老高之后要做的工作一个是质量控制环节中的测试流程管理和版本管理,做好了这两项工作,我想后续也就不会再出现这些问题了。

  1)缺乏需求管理,需求变更怎么直接由开发人员各自接了修改呢?应该有一个产品人员(至少项目经理兼任也行)专门管理需求、需求变更、需求确认等工作

  2)缺乏计划管理,需求分析和设计完成后,应该有后续的任务工作量估算,制定计划,对计划进行跟进和监控是否按照计划完成任务

  3)缺乏测试管理,这么大个信息系统,应该有测试规划,有一个完整的测试流程,测试计划,缺陷修改管理和计划,配备一定的专业测试人员,开发人员自测报告不可靠。而且在客户之前都没有内部集成测试一下,风险是很大的。

  4)缺乏版本 控制。越改越乱,改了哪里那个版本可用,到最后都很难分辨了,对每个修改版本都应该有记录,有集成规范。

  5)项目组人员管理,虽然项目人员各自完成任务,即使是自领取任务形式,项目经理也应该把控任务的完成情况,做好任务和人员的协调的工作。

  说明:项目管理案例系列由项目管理者联盟[PMU]制作推出,版权所有。该系列以PMU会员实际项目案例为蓝本,结合项目管理专家点评和PMU会员分析,真实、深入、可鉴。

  导读:交流问题不仅可能出现在项目小组与其他部门、人员之间,还有可能出现在项目小组的内部。有一些项目经理没有很好的同小组成员进行交流,让他们了解大家对自己工作的期望值。无论是对于项目经理来说还是对于小组成员来说,交流不善的情况都会让项目处于困境。

  某软件外包项目,工期1.7月,需要人员19(总体33人月)其中,外公司有10人,内部正式员工6人,新人8人。

  外部员工技术和经验都不错,但他们所属的公司与本公司有竞争关系。所以参加人员不很配合。尤其是这些人所在的公司经理和本公司的高层经理是同学朋友,在项目没开始前,已经确定用他们的人。作为项目经理考虑到该公司无良好业绩,风险很大,不同意他们独自组成一个组的要求,但高级经理却答应了对方的要求。结果到中期,这些人员抱怨自己分担作业太多,(实际是按平均分配的)提出加人的要求,声称不同意就撤退,高层经理又做了让步。外部人员自己管理进度,不服从项目经理的管理结果最后外部人员的作业没有如期完成,造成很大范围的返工,整个项目评价很低。项目经理被责辞职。

  柯仰杰厦门信达网络科技有限公司常务副总经理、董事,西安交通大学管理学院毕业,获管理学和工学学士。先后任兼职于北京安博成科技有限公司、华深慧正、香港Active系统有限公司中国办事处等,先后担任编码人员、项目经理、技术经理等职位;在上市公司厦门信达先后经历了项目经理、软件部经理、总经理助理、副总经理和常务副总,曾兼任中日韩合资企业厦门掌通科技有限公司董事,有着丰富的项目管理和IT企业运作经验,对IT企业人力资源管理、成本管理、质量管理、项目管理等有着独到的理解和丰富的实务经验。

  这是典型的周期短风险性高的项目,从提供的材料看,其中的大部分风险来源于项目管理。我想如果从以下几方面妥善处理,将比较大程度的降低项目失败的可能性。

  项目经理在面对高层主管部分脱离项目管理规律、过多干预项目成员管理时,没有及时有效的沟通,再加上人力资源支持有限,是该项目失败的部分原因。

  这要求项目经理有效的和高层经理沟通,获得高层主管的授权,在尊重公司目标的前提下,应获得用人的相对自主权,要求责权利对等,避免行政干预所带来的风险。

  该项目的项目管理需要规范,公司的项目管理制度和规范需要改进。任何一个项目的失败绝不是偶然的,和公司内部的管理制度,特别是项目管理制度息息相关。

  项目经理可根据公司特点,剪裁并执行公司软件开发过程,复制成功的项目管理经验,通过控制软件过程的各里程碑,及时调整进度,达到降低项目进度的风险。

  大部分软件项目的分析设计都应遵循高聚合、低耦合的原则,采取内部接口和外部接口相结合的设计思路,尽量减少功能间的关联。根据功能的重要性、是否基础模块等因素安排开发人员。对于技术水平不了解或者技术水平不是很高的人员,可以把次要模块和次要任务分解由其执行,避免因技术原因所带来的大面积返工。

  任何技术人员的薪资和能力都不会一样的,所以平均分配任务是一种貌似合理的不合理,作为项目经理可根据成员能力来分配任务,而不是搞任务量的平均主义。

  该项目中,项目经理可由外部人员自我评估开发进度,结合WBS分解情况,制定进度。项目经理可在尊重开发人员自我管理进度的诉求下,通过有效的里程碑考核,化被动为主动。

  1。作为本项目的项目经理,首先做到风险预警和分析,及时把问题暴露出来,让足够的高层知道,同时声明你的解决条件,如果不能够提供条件将产生的后果。

  前面的兄弟提到了项目的风险预警与消息通报机制.但是我不知道那位项目经理是否对各个合作单位的分工,工作界限做了明确的界定.

  从案例来看,问题出在体制上。首先,项目部成立的时候,管理体系没有建立好:项目到底是谁对项目负责,也就是谁是项目的管理并对项目的成败负责;其次,本公司与合作公司是什么样的合作方式;还有,项目部、公司的权限如何设置。从案例介绍中来看,这方面的基础工作没有做好。另外,公司高层领导的作为也直接干扰了项目经理对职务工作的正常履行。还有,从案例介绍中,个别高层领导还有腐败之嫌。

  2.向本公司及合作公司高层提供风险预警报告,明确告知问题的严重性及可能产生的后果,并提出解决方案。

  也许您应当进行干系人分析,但更重要的是,您应当揣摩领导的意图,也许您本来就是个替罪羊,但即使如此,您也应该先摸摸领导的线:官私合营的复杂组织

  其二:如果高层经理更上层的领导比较支持项目经理,自然可以借力打力,高层经理也不敢太多偏护总之,最能与外部小组形成一个团队,否则就把他当作外包供应商,事事都小心看护,出了事,冤有头债

  第一:项目经理既然做了这工作就要负责,抵制住压力,他没有这么做,证明他着方面不合格。一个字“辞”

  进行质量管理,对项目中的各种不可见指标进行量化。除此外,系统的使用手册还是用户在使用过程中的指导。

  8.形成质量改进的习惯,质量改进要成为一个组织内部的一种习惯和规程,真正发挥质量改进的作用。

  3.项目的监理方,监理是执行监督作用的第三方,站在技术的角度对承建方的各项工作进行考核考查。

  5.项目的投资方,项目的投资方出于对其投资安全性的考虑,对项目的质量进行总责,项目质量管理人员必须取得其信任和支持。

  2017年1月5日星期四晚19:00-21:00线软考最新考试动态、考题趋势,专业讲解软考与个人的发展关系,给个人职业道路上带来哪些优势。一对一现场答疑,解决与会成员软考相关疑问,指导制定管理转型新规划。

  也叫横道图、棒图、条形图,是一种能有效显示活动时间计划编制的方法,主要用于项目计划和项目进度安排。在简单、短期的项目中,甘特图广泛应用。甘特图把计划和进度安排职能结合在一起,纵向列出项目活动,横向列出时间跨度。每项活动计划或实际的完成情况用横道线表示。横道线还显示了每项活动的开始时间和结束时间。甘特图的优点是简单、明了、直观,能较清楚地反应工作任务的开始和结束时间,能表达工作任务的活动时并和彼此间的逻辑关系,可用于 WBS 的任何层次,时间单位可以是日、月、年等。甘特图只表示出已有的表态关系,对于复杂、相互制约的各项活动间的关系没有表示出来,出时也没有指出影响项目生命周期的关键所在,这就不利于合理地组织安排和指挥整个系统,更不利于对整个系统进行动态优化管理。

  2017年1月5日星期四晚19:00-21:00线软考最新考试动态、考题趋势,专业讲解软考与个人的发展关系,给个人职业道路上带来哪些优势。一对一现场答疑,解决与会成员软考相关疑问,指导制定管理转型新规划。

  目前国内游艇企业多为民营或合股中小型企业,属于小批量、多采购、劳动密集型产业。其组织结构和运行机制远不能和大型正规企业相比。现行项目管理知识在这些企业中很难操作。

  小陈现就职于一家游艇制造企业,今年年初就曾因为看不惯管理层的做法想离开,但经过老板的一番“说教”,最终还是决定留下来,并被承诺委任为一大项目的项目经理。小陈自己也想通过努力来证明自己的实力,并对此很有信心。

  第二天,小陈就按所学项目知识,要求企业领导层提供项目委任书和项目团队成员的名单。然而领导的一句话着实让人晕倒:“项目委任书由你来写,然后我牵个字就行了;至于所谓的项目团队名单,你也是知道的,我们公司规模小,不可能给你安排专门的团队成员,何况公司还有其他项目要做啊,因而今后所有该项目的任务和协调工作都由你来做,但你调不动下面的工人时可以再来找我”。真是出师不利,着实给小陈浇了一瓢冷水。(值得说明的是:小陈写的那份委任书,至今还放在抽屉里,领导也没有要过。 )

  (1)采购不及时,采购人员不愿提供采购信息,导致无法进行成本控制。分析原因主要表现在:公司每月库存计算一次,结算期间甚至在平时,仓库人员也不清楚货物余量;还有领料人员经常领用本属于该项目的货物用于其他项目;采购人员因为怕麻烦,不愿提供采购商品的价格等信息。

  (2)因为没有专门的项目成员,所有工作都由小陈一人完成。这些工作包括:领导层的沟通协调、项目中的技术问题、工艺图纸和文件、每天员工工时统计、时不时的项目进度报告等等。幸好小陈借用Project能很快完成进度报告,不然不被这些事累病才怪。作为一个项目经理,小陈需要完成这么多工作吗?

  (3)由于多个项目的进行,公司资金严重不足,投入多产出少。小陈所在项目属于大型项目、开发型产品,但没有定单。因而小陈负责的项目首当其冲的被迫停工,现在已停工两个月了。可以想象,小陈今年的项目奖金受到很大的影响。

  点评专家:郭富才深圳汉捷研发管理咨询公司副总经理,资深研发管理顾问,,中国首批IPMP C级认证获得者,美国PDMA协会会员,中国2006百名优秀IPMP项目经理称号获得者。专著《用Project2002管理项目实务》由机械工业出版社出版,在《IT经理世界》、新浪科技网站等发表《让研发人员找准市场需求》、《实施集成产品开发、提升新烟管理》等文章二十余篇,部分文章被《新华文摘》转载。在中兴通讯股份有限公司总部技术中心工作期间,组织建立了公司产品开发管理模式——产品经营团队,并组织在六大事业部推广,取得了良好的效果。六年的研发管理咨询经历,作为咨询项目经理,服务过的客户包括中粮集团、河南中烟集团、山推股份、京城控股、北京四方继保、杭州士兰微电子、广东步步高等二十余家,擅长企业研发管理体系设计,包括研发战略、产品规划、技术规划、新产品研发管理、技术研发管理、研发组织设计、研发绩效管理等体系设计,以及现场实战的指导工作。

  这个案例非常典型,说它典型是因为,在许多中国中小民营企业发展过程中经常遇到这类问题,而且这些问题一直困扰着企业的发展。我先对这个案例中反映的问题进行一一分析,然后再给出总体的评价和解决方案,供小陈参考。

  1、企业领导说:“项目委任书由你来写,然后我牵个字就行了;至于所谓的项目团队名单,你也是知道的,我们公司规模小,不可能给你安排专门的团队成员,何况公司还有其他项目要做啊,因而今后所有该项目的任务和协调工作都由你来做,但你调不动下面的工人时可以再来找我”。

  点评:这位领导在某种程度上是一位有丰富经验的领导,说他/她有丰富的经验,是因为他/她的朴素想法是依靠大量的实践总结出来的,和项目管理的思路是吻合的。这些朴素的想法或做法,如果企业有总结成功经验并共享的机制,使这些朴素的想法或做法在实际工作中得到总结并普遍运用,那确实可以促使一个企业管理方面持续提升,但遗憾的是中国许多企业并没有总结成功经验和失败教训机制。

  在一个企业中,开发项目的任务书一般是由未来的项目经理撰写的。所谓任务书,通常来说是由上级下达给下级的指令。产品开发任务书中一般包括产品概况、里程碑计划、核心成员分工、资金计划、细分市场财务分析、风险分析等方面。理论上讲任务书应该由上级来撰写,但在企业实际操作中这一点是和理论不吻合的。这是因为,在一个企业中颁布项目任务书的领导一般来说是公司的高层领导,高层领导对未来的产品各项数据指标并不清楚,而且不需要也不会有时间在开发之初就需要高层领导对这些指标搞清楚。所以实际操作往往是未来的项目经理会先进行市场调查,在对市场分析的基础上,撰写项目任务书,并将初稿和高层领导进行沟通,双方在沟通的基础上达成一致,然后由高层领导签署正式的任务书。

  关于项目组员,一般来说企业中的项目团队成员不是专职的,除非一些大项目的核心成员是专职的。项目成员一般来说是身兼数个项目,这位领导说的“不可能给你安排专门的团队成员”在某种程度上是有一定道理的。虽然项目组成员身兼数个项目,但不否定矩阵式管理的有效性,不否定要成立项目团队,不否定明确项目经理对项目组员的任务指派。在企业中,由职能部门经理和项目组员自己共同对多个项目的任务分配进行统一,保证项目群时间上不冲突,而项目经理向职能部门提出项目所需要的角色及技能要求、时间要求,职能部门领导要对项目提供人力资源保证并做出承诺。在项目实施过程中,职能部门领导和项目经理共同对项目组员进行管理,项目经理偏重业务管理,如项目任务分配与项目考核,职能部门领导偏重日常管理,如日常考核与技能培训、职业规划等。

  2、采购不及时,采购人员不愿提供采购信息,导致无法进行成本控制。分析原因主要表现在:公司每月库存计算一次,结算期间甚至在平时,仓库人员也不清楚货物余量;还有领料人员经常领用本属于该项目的货物用于其他项目;采购人员因为怕麻烦,不愿提供采购商品的价格等信息。

  在中国的企业中,采购人员与研发人员之间的矛盾简直是不可调和的,研发人员埋怨采购周期长,影响项目周期,而且研发人员得不到采购信息;采购人员埋怨研发人员提出采购需求时间太晚,而且有标准件不用,非标加工的部件多。

  问题的根源在于各自对职责部门领导负责,而不是对项目本身负责,就是说两个没有结成一个利益共同体,这个利益共同体就是指项目团队。如果大家是一个项目团队中共同的成员,共同要对项目成功和收益负责,有共同的项目经理,那么他们之间的协调和沟通就顺畅得多,相互之间的配合也会顺畅得多。

  目前中国的许多企业是按职能进行管理的,也就是说员工对各自的职能领导负责,跨部门的横向沟通及配合由于部门壁垒墙较厚而不顺畅。为此建议企业要逐渐引入项目管理机制,从系统上来改变这种状况,而不是头痛医头脚痛医脚的做法。

  3、因为没有专门的项目成员,所有工作都由小陈一人完成。这些工作包括:领导层的沟通协调、项目中的技术问题、工艺图纸和文件、每天员工工时统计、时不时的项目进度报告等等。幸好小陈借用Project能很快完成进度报告,不然不被这些事累病才怪。作为一个项目经理,小陈需要完成这么多工作吗?

  有分工有协助,这样效率才会高,这是在十九世纪都已经证明过的理论,遗憾的是我国许多中小企业还处在经验管理阶段,没有意识到这个问题。小陈作为企业中的项目经理,一般来说公司所支付的工资会高于一般的操作员,如果整天被一些琐事缠身,如员工工时统计、编写进度报告等,无论对企业还是对个人来说都是一种损失,因为这些事情,一个操作员就可以做了。公司的人员梯队建设上要考虑分不同层次,有专业的技术人员、管理人员、操作员等,进行专业分工,通过项目团队的工作方式进行配合。

  4、由于多个项目的进行,公司资金严重不足,投入多产出少。小陈所在项目属于大型项目、开发型产品,但没有定单。因而小陈负责的项目首当其冲的被迫停工,现在已停工两个月了。可以想象,小陈今年的项目奖金受到很大的影响。

  这个项目从诞生之初就带着先天不足,可能在项目启动阶段没有经过严格的决策评审,这种大型产品开发项目,即使是作为公司的战略类项目,也是要有至少一两家比较明确的客户需求才能通过决策评审。我们知道产品开发是一项投资行为,决策评审就是为了保证我们的投资得到回报。

  在项目的计划阶段,要做好资金计划,所谓资金计划,就是项目未来各周期需要投入的资金,项目把资金需求信息通过计划的形式报给财务部门,财务部门通过相应的融资渠道准备项目资金。如果没有相应的资金计划,用钱的时候才提申请,会出现资金断链,项目被迫终止的现象,形成“滥尾项目”,这是也许多“滥尾楼”形成的重要原因之一。

  小陈在这个项目中遇到的种种困惑和困难,不是小陈引入了项目管理的方法并试图用项目管理的方法造成的,而是没有真正按照项目管理的方法实施项目。

  项目管理的方法不是只适合于大中型企业,是适合于所有类型、所有规模的企业。因为项目管理是提供给人们一种做事的方法。

  我们曾给一个公司引入项目管理,当时这个公司的技术中心也就只有30多个人员,没有引入项目管理之前,按职能管理的方式运作三个项目,项目组员和领导就感觉到手忙脚乱的。通过引入项目管理机制,首先系统化地建立项目管理的机制和工具,并通过培训让员工掌握这套工作方法。现在这个公司技术中心人员没有增加,同时在运作7个项目,技术中心的职员和领导接受我们访谈时,明确表示:如果没有项目管理的方式,同时运作7个项目,不知技术中心会乱成什么样子,现在项目目标明确了,组员的任务也明确了,7个项目都在有条不紊地实施;而且技术中心领导感觉投入的精力也少了,但得到的项目信息比原来还多,在关键点决策上就又能对项目进行指示,顺多了。

  我们要引入项目管理方法,是一种管理模式的变革,这种管理变革需要公司一把手支持,如果仅是由下层工作人员发起的,80%以达不到预期的效果,而且推动困难。日前,小陈正是面临这种局面。

  一个公司引入项目管理模式,应该系统化地进行实施,所谓系统化,就是从以下方面来着手建设相关的管理方式,这包括:流程、组织、激励机制、IT工具。

  所谓流程,就是产品开发项目是分阶段,每个阶段的活动及内容要识别出来,并在关键点上设置相应的业务决策评审点与技术评审点,保证投资的正确性和产品质量。

  所谓组织,就是指采用矩阵管理方式组成项目团队,明确项目团队成员角色与职责,明确分工与配合的接口关系。

  只有从以上方面来着手建设,系统实施项目管理方式,我想小陈的问题才能解决,否则,如果关注局部,头痛医头,脚痛医脚,即使针对一两个问题解决了,又会带来新的问题。

  目前国内的企业,真正的管理正规的企业并不多,大多数企业都会有各种各样的问题,文中的小陈有这种困惑也算正常,而关键是自己在这种环境中如何能克服一些困难,不断提升能力。有问题的地方,有障碍,同时也有机会,如果小陈能在这种情况下带出一个漂亮的项目,就说明他能力有了很大的提高,加薪升职也是顺其自然的事情。

  1、 首先是目标,要向领导问清楚,如果像文中提到的情况,连领导也不能很明确地提出目标,那么只能靠自己判断领导交待给你的任务的风险,并尽量确定自己近期的工作目标并与领导沟通。一方面让自己很清楚自己在做的事情,另一方面也让领导知道自己在做的事情,从而帮助领导在整体项目策划中的方案调整。

  2、 第二是团队要相对确定,这个需要领导的支持,在领导没有认识到这个问题的重要性,以“规模小”“�...

  2014年9月底,国家数字复合出版系统工程项目正式启动,国家新闻出版广电总局委托中钢招标公司公开招标,项目共分为34个包,项目资金来源为财政资金,投资规模4.3亿,项目建设周期40个月。

  招标公告发布后,本人所在公司立刻组织精干人员编写多个技术包的投标书,本人主要负责工程17包发布管理系统招标书的编写。工程于10月20号在北京金潮玉玛国际酒店开标,17包竞标人包括方正、清华同方、东软集团在内的16家公司竞标,竞争不可谓不激烈,经过答辩评标,由本人负责的17包竞标方案最终中标。

  近两年一直忙于《国家数字复合出版系统工程》17包项目建设,整个工程由近20个公司和研究所承担项目各分包建设。工程采用迭代式开发,研发周期40个月,原计划是到2018年3月完成,不过从当前建设进度来看,整个工程研发比原计划滞后近一年。

  工程滞后的原因除了工程系统复杂、近20家公司参与了工程建设,系统集成难度高,各方协调难度大的原因外。还有一个原因是有些项目承担方在项目管理上存在的问题,没有严格按照合同进度要求进行项目管理,导致项目研发滞后,影响到了整个工程的进度。再一个原因是工程采用迭代式开发,每次迭代都经历需求调研、系统设计、编码、测试验证、评审阶段,每个阶段的需求调研、系统设计都需要进行专家评审,每次评审29个技术包,4个集成包都要耗费近2个月的时间,也间接拖延了工程进度。

  当前工程建设已经进入V2.0版第三方测试阶段。回顾项目建设过程,有经验和教训,也有心得和想法。期间经历过因测试用例和软件质量问题,导致项目第一次验证测试险些没有通过的教训,也有第一次迭代需求评审得到专家一致好评的愉悦经历,更有团队建设不力,导致进度延迟,编码质量不高的问题。项目建设过程中诸多的问题和经验,促使自己写下来,还原项目管理过程轨迹,为读者提供可供参考的项目管理经验和教训。

  既然是还原项目管理过程轨迹,教材开端就从招标写起。项目中标后,同事都问写标书的技巧,是如何屡投屡中的,我只能哑然失笑,哪有什么技巧,只不过认真去写罢了,对标书的每一个指标的应答都要有据可查,合情合理,切不可信口开河,随便乱写。

  项目管理从两个角度去写,一个是从工程参与者的角度去看整个工程的项目管理;一个是从项目负责人的角度去看17包项目研发管理。

  工程项目管理以参与者的角度去记录工程多项目管理的组织机构、管理方法和手段,针对各分包项目进度不一采取的管理措施等内容。

  17包项目研发管理以项目负责人的角度去写,更多地是记录项目管理的经验和教训,涉及项目管理过程中的团队建设、范围管理(需求管理)、成本管理、进度管理、质量管理、风险管理。

  为叙述方便,后面内容所提到的项目和系统,如无特殊说明,均指17包发布管理系统。工程均指国家数字复合出版系统工程。

  国家数字复合出版系统工程是我国政府在新时期振兴现代出版业的重点工程,已被明确列入《国家“十一五”时期文化发展规划纲要》和《国家“十二五”时期文化发展规划纲要》。

  工程建设目标是重点研发统一标准的新型数字复合出版技术,形成综合印刷版出版物、数字出版物和各类数字信息资源生产与服务的数字复合出版系统。其中,数字复合出版是指新闻出版单位以结构化内容加工和管理为核心,支持多重产品和服务形态的全流程、数字化、自动化的按需出版方式。

  以智能检校工具(提供SDK工具)为核心,针对出版全过程质量进行智能辅助检校与控制,提高报纸、书籍、期刊、音像电子等出版物的质量。主要实现出版过程流程设置、出版过程模块化、系统管理、统计分析、文件校对等功能。

  主要为作者、编辑、审校人员及管理人员等用户提供统一的编辑平台,实现对文本、图表、多媒体、公式等不同类型内容的复合编辑和结构化编辑和协同工作流程。

  利用最新信息技术与数据资源,结合采编流程,实现期刊约稿、组稿、审稿、编辑加工、引用跟踪等业务的自动化。

  通过数字化手段支持出版机构与作者、编辑之间实时、跨地域协同与合作,满足多人员、多角色、异地、实时协同编校的需求。

  作为报业在复合出版过程中的生产工具,实现稿件、图片、图文混编稿、音视频的编辑、审核、签发、排版的管理。

  研发目标是在保证出版时间的前提下,满足多人、多岗位、多进程地协同编撰同一期、同一选题、同一板块、甚至同一版面的要求,实现多家新闻单位之间的合作。

  建设目标是实现来自新华社、各记者站、网络或社会等各部门、各媒体新闻信息资源待编稿件资源的全部整合和共享。

  关注特定出版领域或相关出版事件的发展动态和趋势,收集微博、微信和网络媒体中与出版相关的动态、舆情热点,运用大数据分析技术,帮助出版社及时了解自身出版产品的市场反应和评价,调整出版计划和决策,为市场营销和发展战略制定提供参考依据。

  为XML结构化文档套用统一的版式模板,实现自动化排版、组刊及组稿,并在自动排版基础上实现版式的精细调整。

  集制作、管理于一体,提供富媒体电子书内容制作、封装加密、电子书管理、解析SDK和阅读器等功能。

  利用网络技术,根据不同教学模式、不同教育对象的特点,在不同的教学环节中为网络教学提供灵活的、可缩放的、适合于多种层面、多种对象及多种网络环境的交互式教与学支撑环境。

  发布管理系统的建设目标是能够对多种形态的产品及内容进行发布管理的系统,可部署在出版机构或云端的。在出版单位面向渠道投送产品和内容的环节,系统可将前端传输过来的产品、内容存入产品内容发布库,将待发布的产品、内容进行内部链接的检测,发布目标确认后,自动发布到相应的目标,对发布产品内容进行留证,并支持对发布的授权时间期限、发布目标、版权记录等信息进行综合管理。

  在领域专业词表和领域本体的基础上,考虑不同专业领域的特点,利用已构建的专业知识体系,以及各种媒体资源及内容之间关联性,根据事先设定的规则,将经过碎片化、格式化、结构化的数字内容资源,进行自动或半自动地重新组合,使之成为新的数字内容产品。

  本包包括出版机构运营服务系统和出版机构运营数据支撑系统两个课题,为出版机构提供整体的、可拆分、可插拔的、全面的内容、资源、产品的运营服务解决方案。

  依据国家标准和行业相关标准,参考国际标准,采集图书的产品信息、市场信息、营销信息和图书馆借还书等信息,通过数据共享服务,实现图书产业链上各环节的信息共享和交换。

  开发一个兼容ISO 26324-2012和ISO 17316-2014标准的数字资源标识管理系统和一个数字资源调度解析服务系统,实现数字资源标识分配、注册、登记、管理及数字资源标识解析调度的功能。

  建立一个统一的数据交换平台,实现出版机构内部各个业务系统之间数据交换、出版机构与外部的加工系统和出版资源发布系统之间的数据交换。

  为出版机构的广告业务提供便捷易用的广告发布平台,针对不同媒体,根据不同出版物特征、不同用户的阅读偏好等特征,投放适合的广告,灵活定义广告展现形式,方便管理广告位信息,精准投放广告。

  将作者提交的内容与已出版期刊、书籍、学位论文等全文内容进行比对分析,并形成分析报告,为专业、教育和学术期刊等出版机构的编辑提供相似性辅助分析服务,实现对学术不端、写作不规范或使用未授权内容等重点问题的把控,保证学术出版质量。

  考主题词表构建的方法和相关标准,为新闻出版单位提供领域专业词表构建所需的辅助工具,支持领域专业词表的协同编纂工作。

  针对数字出版知识服务的需要,研发适合于新闻出版行业使用的领域本体构建与管理系统。通过本系统,新闻出版单位可以构建领域本体库,实现知识管理。

  工程总体集成是在系统工程科学方法的指导下,根据工程总体设计,从建设单位和出版行业的需求出发,将本工程硬件、系统软件、工具软件、网络、数据库及相关应用软件集成为相互关联、统一协调的数字复合出版系统。

  图书应用集成是在系统工程科学方法的指导下,从图书出版机构的实际应用需求和业务流程出发,针对专业出版、教育出版和少儿出版等应用示范单位的特殊情况,整合本工程中涉及图书出版的全部技术成果,满足和图书出版机构已有系统或服务的衔接需求,对相关软硬件系统、工具软件、网络、数据库及其他应用软件进行集成,形成图书数字复合出版典型应用系统。

  期刊应用集成是在系统工程科学方法的指导下,从期刊数字出版的实际应用需求和业务流程出发,充分反映期刊出版的定期更新、专题性、系统性等特征,并针对期刊应用示范单位的特殊情况,满足和期刊出版机构已有系统或服务的衔接需求,整合本工程中涉及期刊出版的全部技术成果,对相关软硬件系统、工具软件、网络、数据库及其他应用软件进行集成,形成期刊数字复合出版系统。

  整合本工程中涉及报业出版的全部技术成果,对相关软硬件系统、工具软件、网络、数据库及其他应用软件进行集成,形成报业数字复合出版系统。

  项目整体管理是指在项目的整个生命周期内,汇集项目管理的知识领域,对所有项目计划,进行整合执行及控制,以保证项目各要素相互协调的全部工作和活动过程。项目整体管理是从全局的、整体的观点出发通过有机的协调项目各个要素(进度、成本、质量和资源等),在相互影响的项目各项具体目标与方案中权衡和选择,尽可能地消除项目各单项管理的局限性,从而实现最大限度地满足项目干系人的需求和希望的目的。

  某市电子政务信息系统工程,总投资额约500万元,主要包括网络平台建设和业务办公应用系统开发,通过公开招标,确定工程的承建单位是A公司,按照《合同法》的要求与A公司签订了工程建设合同,并在合同中规定A公司可以将机房工程这样的非主体、非关键性子工程分包给具备相关资质的专业公司B,B公司将子工程转手给了C公司。

  在随后的应用系统建设过程中,监理工程师发现A公司提交的需求规格说明书质量较差,要求A公司进行整改。此外,机房工程装修不符合要求,要求A公司进行整改。

  项目经理小丁在接到监理工程师的通知后,对于第二个问题拒绝了监理工程师的要求,理由是机房工程由B公司承建,且B公司经过了建设方的认可,要求追究B公司的责任,而不是自己公司的责任。对于第一个问题,小丁把任务分派给程序员老张进行修改,此时,系统设计工作已经在进行中,程序员老张独自修改了已进入基线的程序,小丁默许了他的操作。老张在修改了需求规格说明书以后采用邮件通知了系统设计人员。

  合同生效后,小丁开始进行项目计划的编制,开始启动项目。由于工期紧张,甲方要求提前完工,总经理比较关心该项目,询问项目的一些进展情况,在项目汇报会议上,小丁给总经理递交了进度计划,公司总经理在阅读进度计划以后,对项目经理小丁指出任务之间的关联不是很清晰,要求小丁重新处理一下。

  新的计划出来了,在计划实施过程中,由于甲方的特殊要求,需要项目提前2周完工,小丁更改了项目进度计划,项目最终按时完工。

  请用400字以内的文字,描述小丁在处理监理工程师提出的问题是否正确?如果你作为项目经理,该如何处理?

  在项目执行过程中,由于程序员老张独自修改了已进入基线的程序,小丁默许了他的操作。请用200字以内文字评论,小丁的处理方式是否正确,如果你是项目经理,你将如何处理上述的事情。

  项目计划是项目管理的基础,项目管理中最重要的就是项目计划的工作,项目计划是一个综合概念,凡是为实现项目目标而进行的活动都应该纳入到计划之中。

  项目计划的制订是贯穿这个项目生命周期的持续不断的工作,是利用其他计划编制过程的结果,监理一份连贯性、一致性的文档,以指导项目实施和项目控制。项目计划过程是一个反复的过程。一个详细的项目计划过程包括:

  (1)项目范围计划:阐述进行这个项目的原因或意义,形成项目的基本框架,使项目所有者或项目管理者能够系统、逻辑地分析项目关键问题及项目形成中的相互作用要素,使项目干系人在项目开始实施前或项目相关文档编写以前,能够就项目的基本内容和结构达成一致;项目范围说明应当形成项目成果核对清单,作为项目评估的依据,在项目终止以后或项目最终报告完成以前进行评估,以此作为评价项目成败的依据;范围说明还可以作为项目整个生命周期监控和考核项目实施情况的基础和项目其他相关计划的基础。

  (2)项目进度计划:进度计划是说明项目中各项工作的开展顺序、开始时间、完成时间及相互依赖衔接关系的计划。通过进度计划的编制,使项目实施形成一个有机的整体。进度计划是进度控制和管理的依据,可以分为项目进度控制计划和项目状态报告计划。

  (3)项目质量计划:质量计划针对具体待定的项目,安排质量监控人员及相关资源、规定使用那些制度、规范、程序、标准。项目质量计划应当包括和保证与控制项目质量有关的所有活动。

  (4)项目资源计划:决定在项目中的每一项工作中用什么样的资源(人、材料、设备、信息、资金等),在各个阶段使用多少资源。项目费用计划包括资源计划、费用估算、费用预算。

  (5)项目沟通计划:沟通计划就是制定项目过程中项目干系人之间信息交流的内容、人员范围、沟通方式、沟通时间或频率等沟通要求的约定。

  (6)风险计划:风险计划是为了降低项目风险的损害而分析风险、制定风险应对策略方案的过程,包括识别风险、量化风险、编制风险应对策略方案等过程。

  (7)项目采购计划:项目采购计划过程就是识别哪些项目需求应通过从本企业外部采购产品或设备来得到满足。

  (8)变更控制、配置管理计划:由于项目计划无法保证一开始就预测得非常准确,在项目进行过程中也不能保证准确有力的控制,导致项目计划与项目实际情况不符的情况经常发生,所以必须有效处理项目的变更。变更控制计划主要是规定变更的步骤、程序,配置管理计划就是确定项目的配置项和基线,控制配置项的变更,维护基线的完整性,向项目干系人提供配置项的准确状态和当前配置数据。

  根据《中华人民共和国招投标法》第48条:中标人应当按照合同约定履行义务,完成中标项目。中标人不得向他人转让中标项目,也不得将中标项目肢解后分别向他人转让。

  中标人按照合同约定或者经招标人同意,可以将中标项目的部分非主体、非关键性工作分包给他人完成。接受分包的人应当具备相应的资格条件,并不得再次分包。

  本案例中,A公司将子项工程分包给B,B又将其分包给C,显然违背了招投标法的这一条款。根据条款中的内容,“中标人应当就分包项目向招标人负责,接受分包的人就分包项目承担连带责任。”A公司显然要承担责任,同时B公司也承担连带责任。

  作为项目经理,不仅仅要做好项目的进度、质量、成本的控制管理,而且要注意避免陷入法律陷阱中,因此,对《合同法》、《招投标法》都要有一定的了解。

  软件配置管理是贯穿软件开发过程始终的一项工作。对于一个软件项目来说,软件配置管理规范至少包括以下的内容:

  项目中的基线有两个方面:一是作为里程碑的基线;另一个是模块的阶段性成果基线(对工作产品而言),一般来说都要避免变更基线。对这两种不同的基线,其影响的范围不同,确立和变更方式也不一样。

  项目的基线变更控制委员会由客户代表、产品经理、项目经理和技术经理组成,对发布的里程碑类基线的变更必须由变更控制委员会确认并由QA进行变更记录,所有被变更影响的配置项都需要重新同步后再次发布;而对于仅仅作为工作状态保留的基线,一般只需要建立基线的小组确认更改并在QA进行记录即可。

  作为项目经理,可以考虑首先从项目管理的9大知识点出发简单阐述对本项目的一般性理解。此外,从本案例中,你可以发现项目中的合同与招投标管理、配置与变更管理方面均发生了问题。因此,可从本项目管理较弱的部分进行重点的阐述,如对法律法规的理解(招投标管理),项目进度管理、项目变更的控制。配置管理,以及进度计划的变更将导致质量和成本的变化,此外,还可从进度、质量、成本三要素之间关系进行阐述。因为,基线的变更往往会带来成本、进度方面的变更。

  (l)项目总计划(包括范围计划、工作范围定义、活动定义、资源需求、资源计划、活动排序、费用估算、进度计划以及费用计划)。

  根据《中华人民共和国招投标法》第48条:中标人应当按照合同约定履行义务,完成中标项目。中标人不得向他人转让中标项目,也不得将中标项目肢解后分别向他人转让。

  中标人按照合同约定或者经招标人同意,可以将中标项目的部分非主体、非关键性工作分包给他人完成。接受分包的人应当具备相应的资格条件,并不得再次分包。

  本案例中,A公司将子项工程分包给B,B又将其分包给C,显然违背了招投标法的这一条款。根据条款中的内容:“中标人应当就分包项目向招标人负责,接受分包的人就分包项目承担连带责任。”A公司显然要承担责任,同时B公司也负连带责任。

  本题中,在项目执行过程中,项目发生的变更,程序员小张擅自修改了已进入基线的程序,作为项目经理的小丁不应该默许他的操作,且修改后的东西没有经过评审。

  项目中缺乏变更控制的体系,需要建立变更控制流程,确保项目中所做的 变更保持一致,并将产品的状态、对其所做的变更,以及这些变更对成本和时间表的影响通知给有关的项目干系人,以便于资源的协调。同时,项目团队所有成员要清楚变更程序的步骤和要求。

  (2)从本项目管理较弱的部分进行重点的阐述,如对法律法规的理解(招投标管理)、项目进度管理、项目变更的控制。配置管理及进度计划的变更将导致质量和成本的变化,描述进度、质量、成本三要素之间的关系。

苏ICP12345678