第一篇:项目管理人员继续教育论文-中级- 论项目管理之进度管理-黄娣丽-314050070
论项目管理之进度管理
[黄娣丽]-[314050070]
2013年4月5日
摘要:若要想赢得客户100%的满意度,对其质量的保证想必是必然的,然而一个项目的进度也不容小觑。保证项目的所有工作在一个指定时间内保质完成,不仅能提高客户的满意度,同时也能在竞争者中提高我们的信誉度,故此抓好一个项目的进度将不容忽视。关键词:满意度
进度
2011年4月,我参与了《江西省移动弹性薪酬系统》开发项目,整个系统包含江西省各地市的子项目系统开发,我在其中负责上饶、吉安、南昌、赣州4个地市的系统项目开发工作。各子系统大致包括:薪酬汇总、基础信息管理、客户主管管理、协同办公等几大模块,其中薪酬汇总主要是实现智能报表的定制,基础信息管理主要是确认数据的来源与提供,协同办公主要是实现对各流程信息的转派,流转情况获悉等,整个系统主要目的是实现各大网点、营业厅间的协同工作,以便于网上办公。
各功能点主要包括:智能报表定制;联动查询;各基本信息录入、审批、驳回等,在确定各功能点的同时,对其做概要设计,例:以下是我们对集团关系到位率录入所做的概要设计:
【功能描述】:增加、修改、删除、批量导入客户经理集团关系到位率信息 【查询条件】:选择年月、选择区县、选择客户经理
【查询结果】:年月、区县、客户经理工号、客户经理姓名、日常走访得分、集团客户满意率得分、合计得分(合计得分不超过10分)【增加】:选择年月、选择区县、选择客户经理、输入日常走访得分、输入集团客户满意率得分
【修改】: 显示年月、显示区县、显示客户经理、显示日常走访得分、显示集团客户满意率得分、显示合计得分
【删除】:直接提交,删除记录信息
【批量导入】:格式区县、客户经理工号、日常走访得分、集团客户满意率得分、合计得分
【数据结构】:dGrpRateDet
一个好的开发团队,最忌讳的是中途有人掉链子。这不仅影响整个项目的进度,同时还关乎整个项目的成败。故此团队的组建也将慎行,项目团队有两个鲜明的特点:①个人成员有着相同的工作目标 ②成员需要彼此协同工作,抓住这两个特点使用合法权利、强制力、奖罚制等去影响整个团队,进而提高整个团队的成效性。相信各团队成员有明确的项目分工、工作流程简明有效、明确考核评价标准,工作结果公开公正,奖罚分明、组织纪律强、善于学习,互相沟通等项目实施工作必将胜利进行。
在整个团队合作中,我主要负责前台功能实现、配合后台数据开发者共同把数据流程控制到位,这其中充分体现了团队合作精神,大家一起取长补短,共同学习、讨论怎样在保证功能实现的同时,方便用户,做到简明扼要。项目配置人员主要情况如下:需求分析1人,负责数据库文档开发3人,前台页面开发4人,测试2人,需求变更沟通1人等。
3、随时了解项目进度
作为整个项目的统筹者,项目进度如何是首要关心的问题。在确定项目开发时我们制定了个详细的开发进度表,在确定每一项任务时,都确定该任务的工作量、开始时间、持续时间、结束时间、备注(如未完成,需要的技术支持等)。并对项目参与者实施“每日一志、每周一结”管理制度,所谓“每日一志”就是为了了解各项目组成员完成日工作而定的,要求其每个人必须对自己每日工作情况做相关日志,做好详细记录,这记录包括:所需技术支持、心得、个人技术突破等。所谓“每周一结”就是每周五下午2:00,我们将开例会,汇报这周工作情
第二篇:浅谈项目进度管理之计划编制
浅谈项目进度管理之计划编制
软件项目计划(SPP:Software Project Plan)是CMM二级中列出的第二个关键过程域。这是因为CMM2软件项目计划需要根据纳入配置管理后的软件需求进行项目估算,并依据文档化的流程,形成项目计划文档。软件项目计划的目的在于建立合理的计划,执行软件工程和管理软件项目。软件项目计划管理在软件开发过程中处于十分重要的地位,它体现了对客户需求的理解,是开展项目活动的基础,是软件项目跟踪与监控(SPTO)的基础。
一、软件项目计划这一关键过程域在实施的过程中应该贯彻如下方针:
1.以分配的软件需求作为计划软件项目的基础。
在项目定义阶段,针对用户提出的原始需求(又称statements of work ,SOW),通过用户方和承接方的相互协商,确定双方一致同意的、项目组承诺实现的需求,这个需求即是“分配给软件的系统需求”或者更简洁地说,“分配需求”,然后根据它来提出项目意见,制定初始的项目计划。由此可见项目计划是以分配给软件需求作为软件项目的基础。
2.由项目经理、项目软件经理和其他软件经理共同协商软件项目的各项约
定,并与系统工程组、硬件工程组和系统测试组协商,这些组介入该活
动的有关事宜,同时记入文档。
所谓约定有对外约定和对内约定。对外约定如与客户、分包商有关部门约定。对内约定包含两方面:一是项目组与组织内部其他组,如测试组、硬件组、系统组的约定。二是项目组内部的约定。对软件而言,对外约定像用户需求的更改是不可避免的,一旦有变动会影响整个项目。因此CMM提出由高级管理者控制对外约定。约定是计划的基础,CMM SPP中将其列为一个目标,即约定必须是有关各方一致同意、认可的。
另外,软件计划要包括所有项目活动和所有参加方面的责任,这些活动和责任都要文档化,以保证有效地将计划传达给项目各个参加方。在项目计划执行前,各个项目参加方要认同所承担的项目责任,这种认同是项目计划有效性的一个基本保证。
3.软件项目的规模、工作量和成本估计、进度和其他约定必须通过相关组的审查,以获得相关组及个人的支持。
CMM中的一个组织或一个机构里,通常有许多小组,比如软件质量保证组,负责计划和实施项目的质量保证活动的团队;软件配置管理组,负责策划、协调和实施软件项目正式配置管理活动的团队等等。在执行每个活动时候,这些组并不是独自行事的,而是相互影响的。在SPP这个关键过程域中受影响的组包括软件工程组、软件估计组、系统工程组、系统测试组、软件质量保证组、软件配置管理组、合同组和文档组。但是在对所有与组织外部的个人和组所作的软件项目约定,则由高级管理人评审。所以CMM中提出“高级管理者参加按照文档化规程对组织外部个人和组所作的软件项目约定的评审”以此作为一项活动。
4.项目软件开发计划需要进行管理和控制
项目计划是CMM实施一开始就涉及且最后才能相对完善的关键过程域,它主要包括软件规模估计、工作模块计划、人力资源计划、进度安排和其他资源计划。在其他关键过程域的实践相对稳定之前,项目计划的实践总是处于需要改动的状态。所以需要对项目软件开发计划进行管理和控制以保证项目顺利实施。
二、软件项目计划的关键问题及解决方案
1.关于软件项目的估计
建立合理的软件计划的基础是对软件项目规模、资源要求和风险等要有一个合理的估算。这个估算过程应是规范的,而不是任意的。例如,如果提出一个项目计划需十个软件工程师工作六个月的计划,那么就要问这些数据是如何得到的。用户提出的时间和费用的要求仅能作为项目计划约束的条件,而不能作为项目计划的基础。
根据CMM SPP 的活动9、10、11,估计对象应该包括软件规模、工作产品的工作量和成本、软件进度、风险、关键计算机资源等。项目计划的基础要求是估计项目中的各种工作所需的工作量和进度,软件成本通常由工作量换算而得到。
估计模型有很多种,常用的如下:
算法模型:包括一个或多个算法,生成的软件估计是一些变量的函数,如COCO-MO
专家判断:利用一个或多个专家的经验作估计。
类比:和已完成的与新项目的规模和功能十分类似的项目做比较,作估计 自顶向下的估计:从项目的全局特性导出项目的整体估计,然后将其分配到各个分量上
自底向上的估计:分别估计软件作业的各个分量,再综合出整体估计
在具体进行估计的时候应该注意以下几个问题:
1)选择科学的估计方法。CMM的核心思想是不断学习、不断改进。在项
目过程中,计划是被不断修订的,所以每做一次修订,就必须作估计。
因此在某个项目中只对项目选定一种(几种)能改进的估计方法,多次
估计的结果进行比较,才能积累经验和数据,估计也才能越来越精确。
2)必须积累本组织自己的数据
随着生命周期阶段的进展,估计会越来越精确。一方面是不确定性随着
阶段的进展而减少,另一方面基于对估计值与实际值的分析比较,可合理选择估计模型的参数。组织在每一个项目结束时,需要将项目数据综合归纳,保留。如果在刚开始没有估计值的情况下,我们只要选定方法,做就是了。需要数据的地方如项目有数据用自己的数据,否则用本组织数据。对于无组织的数据,则一次选定本地区的数据、本国行业数据,国际上的行业数据。CMM 2级SPP的活动场15要求建立一个数据库,记录项目估计数据,包括计划时的数据、再次调整计划后的数据。为使数据可用,必须记录下估计的假定,如采用的估计模型、模型参数、估计时作业的描述等。
另外,CMM2的本关键过程域还提到要按照文档化规程进行估计。由前面,在整个生存期内,随着项目的发展,需要不断进行估计。为确保估计的有效性,结果的可比性,必须描述项目进行估计的具体步骤,即所谓规程。这样一来就能保证估计过程的可重复性,无论什么人去估计,或是在不同时间估计、估计的步骤都是一致的,估计的假设也是一致的。CMM SPP中要求有4个文档化的估计规程,具体的规程形式由项目自己确定,CMM仅提出了对规程的一般要求。这些规程指出:
估计假定要记入文档;
如有历史数据,使用历史数据;
估计要经过评审;
规模估计是多种估计的基础;
在用CMM进行过程改进的实践中,许多项目常常忘记进行规模估计,认为项目计划内容未明显包含规模。然而正是规模大小会影响技术解决方案。对于同一计划,人和月是不能交换的,比如说5个人干3个月的活就不等于4个人干4个月的工作。规模越大。通信与管理的开销越大。规模直接影响进度的安排、人力资源的安排、计算机资源的安排以及风险的分析。所以最初的模型估计也应该在项目定义阶段给出。其中代码行技术和功能点技术两个技术用来对软件规模进行估计。代码行技术是比较简单的定量估计软件规模的方法。这种方法根据以往开发类似产品的经验和历史数据,估计实现一个功能需要的源程序行数。功能点估计依据对软件信息域特性和软件复杂性的评估结果,估计软件规模。
在进行估计的时候我们可以参考如下几点建议:
首先下功夫精简软件需求规格说明书。从根本上来讲,估计的输入是需求规格说明书。要做合理的估计首先要力争使需求规格说明清晰。
尽可能将工作分解得详细。分解得越详细,对开发软件的技术方面理解越透,估计越精确。
采用几种独立的技术,没有一种估计技术是万能的,所以要避免其弱点利用其强处,最好采用技术组合。可以按情况对不同软件成分采用不同的估计技术。
比较与印证。对同一对象采用不同的估计技术,然后比较其结果,研究为何它们得到不同估计,从中能做出较精确的估计。
注意采集数据,将实际数据与估计值进行比较,不断修订估计值和估计模型的参数。
总之,根据CMM,当我们需要制定项目计划,首先确定了项目的需求后,估计出所有的可交付产品,以及这些产品的规模。比如,规模可能包括哪些?如果是生产类项目,可能估计的是交付的东西的数量,比如凳子多少条,牛奶多少箱等,如果软件开发类项目,可能是特性多少个,代码行多少行等,这些根据你所估计的对象来确定。另外,规模估计出来后,需要根据生产率估计项目可能的工作量,比如生产一条凳子要多长时间,一箱牛奶要多长时间,软件开发的话,可能就是一天生产多少行代码。在设计阶段,可能就是一天设计几个特性或者几页设计文档等。根据生产率再估计出总工作量。最后,根据你所拥有的人力,来确定出项目的进度计划。
根据这个再对应到软件开发上来。一个软件开发项目可能的生命周期有可能包括以下几个阶段: 需求分析、软件设计、编码、单元测试、系统测试、交付。不同的项目有不同的生命周期,但项目计划阶段一定要把项目的生命周期确定下来,这也是计划的一部分。那么,在制定计划时,怎么估计这几个阶段的里程碑时间呢?在处于二级的组织,由于之前没有什么量化的能力基线(也就是一般的每个阶段的生产率),那么也只能去参考历史项目的信息。假使以前的项目刚好做了这些度量的话,比如度量过每个阶段花费的时间,投入的人力,统计过交付件的规模(文档页数、代码行数等)。那么,项目刚好可以参考这些历史的数据,大致估计一下这个项目各个阶段可能需要的时间,来确定这个项目的阶段里程碑时间。假使没有类似的项目数据的话,可能估计的可信度就不高了。业界有估计方法,都是用来帮助我们得到比较可信的估计结果的,比如Delphe、Pert sizing。
在项目的生命周期不同阶段,因为所作的工作不同,生产率也就不同,每个阶段甚至都有不同的生产率度量单位,比如需求分析阶段,可能就是需求分析文档页数/人天。在编码阶段,可能就是代码行/人天等。一个组织需要积累和建立
这些能力数据,才能保证后面的项目有可信赖的数据参考,支撑后面的项目进行估计和计划的制定。
2.鉴别和评估软件风险
风险管理是项目管理的重要内容之内,从某种意义上讲,项目管理就是风险管理。风险就是不利事件发生的不确定性。所有。首先必须清楚风险是可能事件,它可能发生,也可能不发生。所以决定了风险的动态性。
风险评估是项目计划时必不可少的一项工作。正如前面提到的项目成本估算和进度估计一样都是项目管理的重要活动。忽略了风险,轻者给项目工作带来被动,重者可能对项目造成严重的灾难性后果。
CMM实际上在本关键过程域的活动13是如此表述这个问题的:
“对与项目的成本、资源、进度和技术方面相联系的软件风险进行鉴别、评估和建立文档”。
风险评估包括风险识别、风险分析和对风险进行优先级排序。
风险识别是风险评估的第一步。就某个特定的软件工程项目来说,从项目具体情况出发,列举出可能出现的风险。真正弄清每一个可能风险的情况是风险识别的主要任务。检查单是风险识别的一个有力的工具。采用检查单中所列举的各种风险,对照即将开发的软件项目,逐一加以甄别,判定检查单中哪些风险在该项目中可能发生。在进行风险识别时采用访谈、调查还是会议方式应根据软件项目的具体情况决定。
风险识别以后需要弄清楚已识别的风险可能何时何地发生,发生了会怎么样。风险分析的任务是分析每个风险可能造成的影响,给出比较风险大小的量值。进行分析可以借助一些已有的模型,但不是所有列出的风险都可以借助模型进行分析的,因此常常采用主观分析。
识别出风险,对其进行分析后就要对其进行排序了。排序步骤包括对已识别和分析的风险估计概率类型,如高概率风险、低概率风险;评估每个风险对项目的影响级,如低级、中级、高级。风险排序应该根据该项目各有关风险的概率和影响级。显然高概率和高影响级的风险应该排在中概率和高影响级风险的前面。最后针对排序列在前几位的风险采取缓解措施和跟踪措施。
3.确定软件生存周期
确定软件的生命周期,这在CMM本关键过程域活动5也有体现“识别和确定具有可管理的预先规定阶段的软件生命周期”。典型的几种生命周期模型包括瀑布模型、快速原型模型、渐进模型、喷泉模型等。
瀑布模型严格规定各阶段的任务,上一阶段任务输 出作为下一阶段工作输入。此模型适合于用户需求明确、开发技术比较成熟、工程管理严格的场合使用,其缺点是:由于任务顺序固定,软件研制周期长,前一阶段 工作中造成的差错越到后期越大,而且纠正前期错误的代价高。
渐进模型是指从一组简单的基本用户需求出发,首先建立一个满足基本要求的原型系统。通过测试和运行原型系统,有用户提出进一步细致的需求,然后修改和完善原型系统,反复进行这个过程直到用户满意为止。该模型适合开发初期用户需求不甚明确,相关技术和理论需要不断研究、反复实验以及开发过程需要经常与用户交互的场合,学习或研究类软件的开发常用此法。
快速原型是指快速建立起来的可以在计算机上运行的程序,它所能完成的功能往往是最终产品能完成的功能的一个子集。这个模型的优点是软件产品的开发
基本上是线性顺序进行的。
喷泉模型主要用于面向对象软件技术开发项目,其特点是各项活动之间没有明显的界限。由于面向对象技术的优点,该模型软件开发过程与开发者对问题认识和理解的深化过程同步。该模型重视软件研发工作的重复与渐进,通过相关对象的反复迭代并在迭代中充实扩展,实现了开发工作的迭代和无间隙,该开发过程分为:分析、设计、实现、确认、维护和演化。
三软件项目计划的实际应用模式如下:
1.项目采用 Microsoft Word 拟定计划文档,以 Microsoft Project 拟定计
划的进度表。
2.项目经理根据项目软件需求进行估算,确定进行项目选择的生命周期、项目规模、所需的人员、时间、进度、资源、风险等内容。将估算的结
果形成估算过程文档,并拟定软件开发计划。
3.软件开发计划内容包含:软件项目计划、迭代计划、进度时间表、配置
管理计划、质量保证计划、需求管理计划、项目评测计划、风险管理计
划、产品验收计划、问题解决计划、测试计划。
4.估算过程文档和软件项目计划文档必须通过相关组的审查,以获得相关
组及个人的支持,包括:系统分析组、设计组、编码组、测试组、质量
保证组、配置管理组、文档管理中心及个人。通过审查,发现并修正项
目估算和项目计划的偏差。只有获得了支持,软件项目组在开发过程中
才能尽量避免或消除风险。
5.在高层管理者复审通过后,项目经理指定人员或参与拟定软件开发计划
其它部分,并由相关组和个人复审。
6.配置管理人员将软件开发计划文档纳入配置管理。
7.实际项目中应用的文档有:
制定项目计划流程定义、项目估算流程定义、项目评估表、资源评估表、软件开发计划模板(包括:软件项目计划、迭代计划、配置管理计划、质量保证计划、需求管理计划、项目评测计划、风险管理计划、产品验收计划、问题解决计划、测试计划)、进度时间表、制订软件开发计划的指南。
综上所述,SPP阶段需要制定的计划不仅仅是进度计划,也包括需求管理计划(对需求如何管理,变更如何控制,谁来评审这些变更,如果变更了要怎么办),进度计划,配置管理计划(项目所有的交付件包括可交付的产品和中间的交付物等如何归档,如何变更,如何控制等),风险管理计划(项目开展中会碰到哪些风险,目前有哪些不确定因素后面可能发生,这些风险如何应对,假使风险发生如何处理,如何预防这些风险等等),资源配置计划(项目开展过程中需要哪些资源,包括办公用品,电脑,机器等等,这些资源何时提供,怎么分配,怎么管理等),等等这些都是项目计划要考虑的,比较复杂的内容,计划阶段会考虑所有的东西,甚至可能要包括利益关系人管理计划(比如识别项目的利益关系人,这些人应该如何管理,如何及时向他们汇报项目的信息等)。
第三篇:IT项目进度管理对策论文
一、IT项目进度的影响因素
IT项目管理是项系统工程,在其生命周期内,通过设立临时性的项目团队进行计划、组织、指导、控制和实施,以实现全过程的优化管理和既定目标的达成。时间、成本和质量是项目的三要素,而时间控制即进度管理是项目的灵魂,贯穿项目始终。本文以笔者公司实施的项目为例着重探讨了影响IT项目进度的四个主要因素:进度计划、需求分析、团队管理、进度控制。
二、IT项目进度管理中的问题
本案例是笔者公司研发平台整合的IT项目,该项目包括研发平台整合及需求定制开发;信息网络建设及硬件平台搭建,是一个一体化综合性的系统集成项目。企业希望通过本次项目的实施,建立产品研发管理平台系统,把产品设计、产品数据管理、变更管理及研发并行设计过程的协作等有机地集成为一个整体。
(一)进度计划不周全。项目涉及多个事业部的研发部门,各自的基础环境均有差异,实施的进度计划也都会有不同的时间点和困难点,初期计划定制时并没有考虑到这些关键影响因素,因而计划的执行和落地有些顾此失彼。
(二)调研分析不到位。项目的实施方把售前和售后严格分开来,致需求调研信息脱节,实施方人员衔接不到位;其次实施方人员对企业的业务模式了解不透彻,双方在范围定义的理解上存在偏差,含糊的需求和频繁的变更容易导致外延无法界定。
(三)团队成员沟通不顺畅。本项目组的成员来自不同部门的业务骨干,容易从自己部门的角度出发希望平台的建设能更加符合其应用习惯,刚开始的磨合期工作推进缓慢。另外实施方顾问人员不稳定工作衔接也出现问题。
(四)进度控制追踪不及时。实施范围临时扩大且时间节点不容变更,使得项目时间更为紧迫。首先每个事业部的领导重视程度不同,推行执行力度不同,其次产品迁移的数据量不同,还有部门本身设计使用的软件的兼容性,数据规范性可用性等等。为项目计划落实带来了一定的难度,各事业部任务完成的时间点无法同步,进度执行追踪的及时性无法保障。
三、完善研发平台整合项目进度管理的对策
(一)采用分层管理细化计划。
“凡事预则立,不预则废”。计划的制定对于整个项目运行来说无疑十分重要。
1.多层计划分段制定。项目计划分成整体、事业部、底层三个层次,分别对应项目组、事业部组和关键用户的管理结构。按里程碑的节点计划进行逐步细化,每层计划的变化频度及单位不同。
2.底层计划实时更新。动态跟踪关键用户的工作任务完成情况,可赵文星厦门厦工机械股份有限公司有效地了解项目的当前状况和整体趋势,及时发现问题点有的放矢地进行纠错。采用该方法制定的项目计划,既可符合事业部自己的进度,又可全面掌控各组的进度。
(二)掌握正确的调研方法。
IT项目主要风险来自于不准确的需求,目标清晰范围精准是前期调研的重点。
1.售前售后脱节处理。要求实施方的售后经理等人直接介入到售前的投标阶段,并一直负责到项目结束,同时企业方的信息部人员全程督导协助,可较好的解决这个问题。
2.多轮调研把控。首轮调研注重现状与未来平台的差异分析;第二轮调研与技术人员沟通评估其工作量和工作难点,选出数据迁移最优方案;第三轮调研重点了解各部门、各岗位之间的联系,及其准确真实的业务流程。本过程对于优化现有平台提供有效准确的依据。
(三)缩短团队的磨合沟通。
团队内的信息沟通、意见交流,保证顺畅至关重要,成员之间建立和改善人际关系是必不可少的条件。
1.建立良好的沟通。项目组周例会进行重点难点的问题沟通,日常问题则是电话或OA直接沟通,若发现进度偏差则采取纠偏措施,及时调整或变更工作计划,确保项目整体进度。
2.增加团队的凝聚力。使团队成员都明了项目目标并共同为此努力,及时通报项目进度让大家清楚自己、他人和整个项目的工作进展,主动参与所关注的问题并及时协调解决,团队意识才能得到进一步强化。
3.知识传递增强成员自信。项目组内部根据进度计划,适时举行专题培训进行相应的知识传递,提升成员的自信心,对系统平台构架配置等有更多了解,为日后平台维护奠定基础。
(四)进度控制采用关键链。
项目是若干个相对独立的任务链条组成,各链条之间的协作配合直接关系到整个项目的进度,利用系统网络化的管理方法,可以优化整个项目的进度控制。
1.监控关键环节实现动态平衡。项目的进度管理绝不是一个静态的过程,实施与计划是互动的,不断优化协调以实现整体的动态项平衡,保证项目的均衡发展。底层计划关键链的任务之一就是数据迁移,迁移工作量与数据的多少及数据的规范性密不可分,是确保项目能否按时完成的关键。根据各事业部的数据现状,采用并行整理,分批迁移的策略。
2.找短板强突破。任何部门和环节的时间延误,都会导致整个项目实施周期的延长。因此,对影响项目进度的”短板”环节,进行着力攻坚,协同共进有效保障项目的实施周期。例如小型机事业部的服务器老旧数据多,数据形态与总部差异较大,如同步替换修改时间长达2-3个月,直接采取了先迁移后修改的方式以保证数据安全,事业部成员积极配合将进度提前了半个月。该短板的突破为项目按进度保质量提供了有效的保障。
四、结束语
本文以项目进度管理论为依据,结合案例实施的经验,对IT项目的进度管理在执行过程中充分地考虑这些影响因素,有效地控制了进度确保该项目的顺利实施。只有适合项目的模式才是最好的模式,再好的管理方式针对不同的项目也会有不同的效果,因此项目实施过程必须多沟通、多分析、多实践、多总结。
第四篇:得分50分的论文-论项目进度管理
论项目进度管理
[摘要]本文以某烟厂大型信息自动化系统建设项目为例,论述了本人在该项目管理中诸多关于进
度管理的问题。该项目由省中烟公司发起,经国家烟草专卖局批准,定位为全国烟草行业的信息自动化系统示范工程,属于省级重点项目,业务范围涉及到企业的人、财、物、产、供、销,合同金额5千万元。删、改、查等常用操作业务。这样我们就可以在需求分析和软件测试上多花点时间。2.识别关键任务定义里程碑
根据项目活动的逻辑关系,本人采用关键路径法定义项目进度管理网络图,比如销售计划模块作为
整个生产计划的驱动,应该安排在生产计划模块的前面开发,物资采购计划模块要以生产计划模块为依据,该项目周期长、投资大、干系人多,再加上甲乙双方之前有多年的合作关系,以至于该项目在合同签订时比较随意,项目范围边界不明确,导致需求难以准确定义。
在本项目的开发过程中,我作为乙方的项目经理对项目进度进行了管理,本文结合项目实际从活
动定义、工作量及技术难度估算、识别项目关键任务、合理地项目进度控制和项目变更管理等方面讨论了该项目进度管理的基本活动与方法。项目历时3年并于2008年10月顺利验收,系统运行稳定并具有良好的行业示范作用,在文章结束之处对项目进度管理中的经验教训进行了总结。
[正文]本人2005年参加了烟草行业某大型卷烟厂的信息自动化系统项目建设。该项目经国家烟
草专卖局批准,由省中烟公司发起,定位为全国烟草行业的信息自动化系统示范工程,属于省级重点项目,受到各级政府领导和业界的普遍关注。项目以建设烟草行业信息自动化系统示范化工程为目标,努力打造特色鲜明、符合企业未来发展的企业信息全面自动化。该系统由于业务覆盖面广,再加上甲乙双方有多年的合作关系,在签订合同时很多的范围边界没有得到明确、需求难以准确定义。
该项目主要工作包括:物资管理、材料管理、原料管理、生产管理、销售管理、产品技术研发管
理、办公自动化管理、人事管理、项目管理、机电维修管理和财务管理系统等子系统的设计、开发、实施以及系统整体优化和完善。系统历时3年并于2008年10月通过全面验收,不少烟草企业进行了参观与模仿,口碑良好,起到了烟草行业示范化效果。
进度管理是项目控制的首要内容,是项目管理的灵魂,项目超过完成期限,其它的做的再怎么完
美,也不算是一个成功的项目,同时由于信息系统项目不确定性,项目的进度控制是项目管理中最大的难点。项目进度管理与项目的质量、成本管理密切相关,其基本过程包括了以下活动:
1)项目活动定义:确定为完成项目必须进行的各项目具体活动和工作内容;2)活动排序:根据业务逻辑,找出活动之间的依赖关系;
3)活动资源估算:确定在实施项目活动时要使用何种资源以及每一种使用的数量; 4)活动历时估算:资源持续时间的估算;
5)制定进度计划:通过对以上几点的研究和分析,进而制项目的进度计划; 6)
进度控制:跟踪项目进度计划表,对于出现的偏差进行分析,并采取相应措施。
本人在参与该项目之前,有多个中小型企业管理信息系统的项目管理经验,因此在本项目中被任
命为项目经理,全面主持该项目的管理工作。做过项目经理的人都知道,项目范围边界不明确、需求定义不准确是导致项进度失控的主要原因之一,有效的项目进度管理是项目在规定工期内完成的重要保障。本人非常清楚项目管理金三角在项目管理中的重要地位,工期上的延误,往往会带来一系列的问题。如项目成本增加,质量难以保证,甚至引起合同争端,造成严重的后果。
以下是结合本人在该项目中的实际工作情况,从项目进度管理几个方面的工作进行简要论述:
1.定义活动并估算其工作量和技术难度
我们在定义活动并估算其工作量和技术难度上采用面向对象技术和类比法原则,先将每个子系统
进行逐步分解,直到分解成基本模块(当然,分解的工作在WBS中基本完成),借鉴项目历史经验,估算出实现基本模块的技术难度和所需要的工作量,因为和以往项目相同或者相似之处我们认为没有太大技术难度,资源和时间估算上不会有太大误差,对于以往项目中没有用到的技术,我们做为重点考虑对象,一方面靠项目内部核心技术人员提前试验,另外一方面向行业内专家进行咨询并向公司申请相关的培训,比如我们在该项目中用到了数据仓库技术(ETL)和商务智能技术(BI),在进行工作量估算之前特别邀请产品供应商过来对产品和技术进行相关介绍和培训,为工作量估算技术难度分析提供重要依据。项目工作估算完成后,召集子系统负责人对项目进度进行讨论,获得大家对估算结果的认可。当然,在资源安排上,对于技术难度相对较大的工作,一般会安排给经验丰富的程序员,这样不至于在某个技术细节上而影响项目的整体进度。
由于本公司之前曾有多个大型管理信息系统开发经验,因此有不少的案例可供参考,如系统框架
部分的组织机构、功能授权、系统登录等,甚至包括数据库设计我们都是复用以前的案例,在此基础上做少量修改,这对工作量的估算也是一个重要的参考。别外,前台的常用操作,如增加、删除、修改、查询等一系列活动各模块大体上也是相同的,我们就编写统一的类,通过传递参数的方式实现对不同的表的增、所以可以安排为生产计划管理模块的紧后任务,财务结算模块又可以做为物资采购的紧后任务,与生产不直接相关的子系统如办公自动化系统,人事管理系统,项目管理子系统可以在人力资源充足并且不影响整个工程进度的情况下的任何时间启动,找出历时最长的路径定义为关键路径,并且在重要的活动上定义里程碑或者检查点,以便项目对项目进度时行监控。3.进度计划编制
本人以定义的项目活动为依据,制定了详细的进度计划表,进度表内容包括任务工作量,开始时
间,持续时间,结束时间、任务版本号等,并且让每个人都知道自己承担的工作任务的时间表,根据自己的任务制定详细的工作计划。对于进度计划中重要的检查点进行高亮显示,以便在进度执行的时候引起重视,进度计划编制完成后,有可能需要更新的文档包括项目日历表、资源安排表、进度基准表、项目管理计划等。4.项目进度控制
本人在该项目中采取定期检查和定点检查的方式控制项目进度,其中定期检查的主要形式是周项
目例会,该项目规定在每周五下午定时召开项结并形成小组任务进度报告向项目组汇报。项目例会的一项重要议程就是了解项目进度,参会人员主要是项目经理和各任务组组长,项目任务组组长向项目组汇报该组周工作完成情况,工作进度结论中不得使用“差不多”、“大概”、“基本上”等模糊字样,项目经理对工作完成情况与计划进行比较,如果出现了偏差,则及时地调整措施,纠正偏差。定点检查主要是在事先设定的检查点,如里程碑结束时,对任务完成情况进行进行检查,判断偏差是否会对项目工期造成影响,如果对工期造成影响,则需要上报给CCB请求变更,并说明引起变更的原因及建议的解决方案。
基于该项目在项目初期项目范围没有明确界定,需求难以定义和项目工期紧的原因,为了确保项
目不出现多次返工的情况,我们选择迭代模式进行开发,设计与编码同时进行,尽量保证项目人力资源没有闲置的情况,除此之外,鼓励员工适当加班也,要手段,我们给予愿意加班和主动承担项目任务的员工多发奖金和公开表扬进行激励。5.成立配置管理小组
严格的配置管理是保障项目进度的重要手段,项目管理部门配置了一名兼职的配置管理员辅助我完成配置管理工作,同时成立了项目配置控制委员会CCB,CCB由项目经理,技术总监,甲方项目负责人,配置管理员等五人组成。考虑到VSS界面友好,操作简单,使用方便,所以选择作为本项目的变更管理工具。开发库主要供开发人员使用,变更比较频繁。我为项目组每个成员建立了访问帐户和权限,开发库主要由我负责管理,配置管理员负责管理和控制项目受控库,在项目内部对变更控制的权限做了明确的分级,项目经理有权决策WBS框架内项目内部人员提出的各种变更;WBS边界上以及边界外的变更,必须提交项目CCB.本项目CCB严格按照变更请求评估、变更决策、变更实施、变更验证、沟通存档的流程执行变更处理。
回顾该项目进度管理的过程,虽然比较顺利,但也有很多问题存在,现将主要经验教训总结如下:1. 有效的沟通能事半功倍。
2. 进度管理的模式不能机械地套用,合适本项目的才是最好的。3. 进度计划不能走过场,一定要严格执行。
4. 进度计划过粗或过细。好进度计划既容易发现问题,又能保证业务的连贯性。5. 建立奖惩制度,激发员工的工作热情。
6.建立标准的进度管理模板,便于快速统计和分析。
总之,项目的进度管理是整个项目管理过程的重要环节,它与项目的质量、成本、人力资源管理
密切相关,项目进度管理没有一种一成不变的模式,不同的项目、不同的团队,需要采取不同的进度管理模式,但最终的目标是一致的,那就是在规定的时间内完成项目的目标,满足项目干系人的期望。
第五篇:信息系统项目管理工程师,进度管理论文
论大型信息系统项目的进度管理
摘要:
2010年3月,我有幸参加了xx市财政局国库集中支付系统项目,担任项目经理职位。该项目是该市政府2010年重点项目,涉及部门多,功能复杂,具有大型信息系统项目的特点。该项目目标是是建立以国库单一账户体系为基础的财政资金拨付体系,提高财政资金的使用效益。本文结合作者的项目实践,以xx市财政局国库集中支付系统项目为例,讨论大型信息系统项目的进度资源管理,主要包括活动定义、活动排序、活动资源估算及项目综合变更控制、沟通管理。通过采用以上进度管理方法,最终使项目按期保质完成,系统至今运行稳定,取得客户的好评。
正文:
2010年3月我以开发方项目经理的身份主持了滨州市国库集中支付系统项目的开发和实施。该项目被列为2010年市政府重点工作,项目由财政局主导,人民银行、商业银行、预算单位参与配合,目标是建立以国库单一账户体系为基础的财政资金拨付体系,提高财政资金的使用效益。项目主要有指标、计划、支付、综合查询、单位账务5个模块构成。该项目以Java为开发语言,中间件使用Weblogic,数据库采用Oracle10g;应用服务器浪潮高性能服务器,数据库服务器采用双机热备加光纤存储。系统网络依托当地的可靠地电子政务网连接的各预算单位,网络集成部分由我方出方案,信息中心负责完成。市财政局对该项目特别重视,对项目的进度和质量提出了很高的要求,成立了以局长任组长的领导小组,负责整个项目的领导工作,指定信息中心为甲方主要联络部门。所以我公司中标后对此项目非常重视,承诺在项目的各方面给予我最大的支持。
由于前期项目招标过程中我也是主要的参与人之一,所以对项目情况也比较了解,公司任命我为项目经理后我根据项目的特点把项目的重点放在了项目的进度资源管理上,这是软件项目管理中一个非常重要的组成部分。我们主要通过项目的活动定义,活动排序、活动资源估算等项目管理活动对项目的进度资源进行管理。同时也意识到项目过程中的变更也是无法避免的,在这方面我们也进行了管理。
1、活动定义
项目的活动定义就是为确定为得到项目的各种可交付成果而必须进行的各种活动。项目的活动定义主要以WBS和WBS字典为主要输入,以项目活动清单和主要里程碑作为主要输出。项目组根据本项目特点,在活动定义时首先联系财政局主要业务科室及有代表性的单位对整个业务的流程进行了规范定义,然后根据财政资金拨付的特点将系统分为指标、计划、支付、综合查询、单位账务五个主要部分,并以此为五个主要的里程碑,最后细化各模块将模块要实现的功能分别进行了定义并得到相关科室的签字认可,如指标模块主要向预算科征集需求,计划部分主要向国库科征集需求,然后再向其他有关业务科室反馈需求,最后将系统分解成具体的,可实施的详细任务,然后分配给相关人员来完成。
2、活动排序
项目的活动排序主要是确定各个活动任务之间的依赖关系,并形成文档,活动排序是编制切实可行的进度计划的重要依据,所以这是一项非常重要的工作。在项目的活动排序前,我们先和财政局的领导商讨了资金拨付流程,经过分析我们认为系统虽然有五个主要模块组成,但这五个模块独立性非常强,如果拿出任何一个模块就是一个独立的财政业务系统。而且模块内部的业务流程非常相似,主要有业务数据的录入、初审、复核组成,然后数据流入到下一个模块。我们根据系统的特点利用活动排序的工具和技术箭线图法,及各活动的依赖关系,制定了项目的计划网络图确定了项目所有活动以及它们之间的逻辑关系。
3、活动资源的估算
活动资源估算是完成计划活动所需资源的种类和数量,它要和成本估算相结合,本项目主要包括人力资源、设备资源、网络资源。该项目主要是建立以国库单一账户体系为基础的财政资金拨付体系,所以系统的财政业务性比较强,所以项目成功的很重要的一部分就是项目组的人员要有一部分精通精通财政业务。我根据项目的WBS及活动定义对项目所用人员进行了自下而上进行了估算,确定了所需的人力资源,分别是项目管理小组(5人),开发小组(20人),平台测试小组(10人),商务及外协(3人),并对每一个工作小组要完成的工作进行了详细描述,据此向公司领导层进行了申请,因为公司的重视,公司对我的要求完全满足,这给了我极大的信心,我不断给自己增加压力,一定要把这项目做好。设备资源主要是四台高性能服务器及光纤存储,这部分我根据项目对硬件的需求情况,组织人员制定了招标书交给了公司的系统集成部来完成,网络资源根据当时合同要求由财政局的信息中心协调当地政府电子政务科来完成,把这两项工作安排好后,我把项目组的主要精力放在系统的开发实施上,这为系统的成功上线运行提供了保障。
从事项目管理工作的我深知,制定了项目的活动定义、活动排序、活动资源估算后,对项目的进度资源管理并不意味着完成,项目的实施过程中不断的有新问题出现,我主要从以下两个方面进行了控制。
1、项目综合变更控制
综合变更控制是项目生命周期内对项目变更进行识别、评价和管理的工作,贯穿项目的整个过程,也是项目经理的一项重要工作。由于该项目功能多、涉及面广、干系人众多,所以变更在所难免为了保障项目能够按进度完成,我主要采取了如下措施 一是成立变更控制委员会,委员会由财政局主要科室负责人、项目组有关成员、有代表性的预算单位财务人员组成。对请求的变更需求书面提交信息中心统一办理,然后由变更委员会对变更进行评估,决定是否要变更。二是加强对变更的管理。对经过评估后确实需要发生的变更,加强对变更跟踪和记录。如果变更对项目有重大影响,申请公司领导和财政局进行沟通。如项目进行到一半时财政局预算科提出增加部门预算模块,并得到了局领导的认同,作为开发方很难拒绝,但如接受将增加工期一个月,在公司领导进行沟通后,决定该模块放到明年解决,保证了系统进度的要求。
2、加强沟通管理。
项目的沟通管理非常重要,直接关系到项目的成败。由于该项目涉及到财政局多个业务科室及银行和160多家预算,在项目的进度资源管理时都离不开各主要干系人的参与。我主要做了以下三个方面的工作一是制定了详细的沟通计划,二是在项目组内部加强沟通,三是采用灵活的沟通技巧。项目实施过程中的每一步都得到甲方的签字确认,避免了需求的不一致和返工,保证了系统按进度顺利实施。
结束语
经过努力项目于2011年3月1日正式上线运行,并顺利通过了验收,回顾该项目的资源管理过程,主要还存在以下问题:
1、对资源冲突估计不足,项目的实施过程中有一开发人员离职,造成他负责的模块延误了一周,在领导的支持下没有对进度造成影响。
2、对项目干系人分析不到位,项目的管理过程中注重了向相关业务科室负责人和局领导的汇报,二忽视了财政局的业务骨干,造成系统需求获取不全面,项目及时发现了这一问题,得以及时改正。
综上所述,活动定义、活动排序和活动资源估算是项目进度资源管理的主要过程,项目的综合变更控制和沟通管理是保证项目资源管理成功的基础。在以后的项目管理中我要以此为经验,加强项目的进度资源管理,更好的完成项目的管理工作。