对项目管理软件多维结构模型的思考
软件项目管理模型实践论文

软件项目管理模型的探索与实践摘要:在分析了软件项目管理体系和cmm3标准的基础上,提出了一个符合cmm3标准的软件项目管理模型。
它是一个适用于中小软件企业的通用型软件项目管理模型,模型从上至下分为4层:公司方针、管理目标层、管理支持层和开发实现层。
管理支持层为中间层,管理目标层的所有意图都是通过它传达到开发实现层的。
过程裁减是管理模型的重要实践方法,不同的项目有不同的需求,只有通过对管理模型进行适当裁减,不同软件项目的软件过程才能清晰定义。
关键词:软件能力成熟度模型;过程裁减;软件工程中图分类号:tp311.5 文献标识码:a 文章编号:1007-9599 (2011) 22-0000-01software project management model study and practice li wenjie(wuhan polytechnic,wuhan 430073,china)abstract:in the analysis of software project management system and cmm3 standards proposed on the basis of a line cmm3 standard software project management model.it is a small software enterprises for general-purpose software project management model,the model is divided into four layers from top to bottom:company policy,management,the targetlayer,management layer and development to supportimplementation layer.management support layer for the middle layer,all layers of management objectives are intended to achieve by it communicated to the development level.process management model reduction is an important practice methods,different projects have different needs,and only through an appropriate reduction of the management model,different software projects in a process to be clearly defined.keywords:software capability maturity model;process of reduction;software engineering一、模型简介这个模型结构上分为四层,从上至下是公司方针,管理目标层,管理支持层和开发实现层。
软件项目管理学习心得(精选5篇)

软件项目管理学习心得(精选5篇)篇一:项目管理学习心得项目管理心得通过在课堂上的学习,我对项目管理有了一个大概的了解和综合的认识。
再在老师的教导下,我对项目管理有了进一步的学习和认识,我真正认识T项目管理在现实生活中的运用。
现将我对项目管理的理解总结如下。
项目管理是项目管理在领域的应用。
它结合了行业特点并且运用了项目管理技术、理念和方法,包含着多个知识领域(如时间管理、成本管理、质量管理、风险管理、人力资源管理、沟通交流管理及采购管理等)。
由于项目管理是项目管理在领域的应用,因此它有着在信息技术行业的许多特征:任务的明确性、管理工具的先进性、信息沟通的及时性、资源提供的必要性、测试的完善和严谨性、度量的准确性及项目管理的贯穿性等。
项目集成管理是指在项目的整个生命周期内,汇集项目管理的知识领域,对所有项目计划,进行整合执行及控制,以保证项目各要素相互协调的全部工作和活动过程。
项目集成管理是从全局的、集成的观点出发通过有机的协调项目各个要素(进度、成本、质量和资源等),在相互影响的项目各项具体目标与方案中权衡和选择,尽可能地消除项目各单项管理的局限性,从而实现最大限度地满足项目干系人的需求和希望的目的。
项目的范围管理影响到信息系统项目的成功。
在实践中,“需求蔓延”是信息系统失败最常见的原因之一,信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能,无论是客户的要求还是项目实现人员对新技术的试验,都可能导致信息系统项目范围的失控,从而使得信息系统项目无论在时间、资源和质量上都受到严重影响。
项目管理的首要任务是制定一个构思良好的项目计划,以确定项目的范围、进度和费用。
在给定的时间完成项目是项目的重要约束性目标,能否按进度交付是衡量项目是否成功的重要标志。
因此,进度控制是项目控制的首要内容,是项目的灵魂。
同时,由于项目管理是一个带有创造性的过程,项目不确定性很大,项目的进度控制是项目管理中的最大难点。
软件工程师软件工程模型

软件工程师软件工程模型在软件开发和工程领域,软件工程模型是指一种用于组织和管理软件开发过程的结构化框架。
它帮助开发团队在项目周期内有效地规划、实施和控制软件开发过程。
软件工程模型有很多种类,每种模型都有其特定的优势和适用场景。
本文将介绍几种常见的软件工程模型,并对其特点进行分析和比较。
1. 瀑布模型瀑布模型是最早出现的软件工程模型之一,也是最经典的模型之一。
它将软件开发过程划分为一系列阶段,包括需求分析、系统设计、编码、测试和维护等。
这些阶段一般是线性顺序进行,即每个阶段完成后才能进入下一个阶段。
这种顺序性使得瀑布模型适用于需求相对稳定、开发任务明确的项目。
然而,它的刚性结构也可能导致进度延迟和变更困难。
2. 增量模型增量模型允许软件开发团队通过反复添加新功能和组件的方式来逐步构建软件系统。
初始版本是一个基本的核心系统,随着每个迭代周期的进行,新的功能和特性被添加到系统中。
这种模型的优势在于能够更早地产生可用的软件版本,并及时获得用户反馈,从而提供快速迭代和灵活应对需求变化的能力。
3. 原型模型原型模型是一种快速开发和迭代改进的模型。
在这个模型中,开发团队首先创建一个原型,该原型可以是一个简单的模拟或一个基本的界面设计。
然后,通过用户的反馈和需求变更,不断修改和改进原型,直到满足用户期望。
原型模型适用于对用户需求不够明确、需要快速验证和迭代的项目。
4. 敏捷模型敏捷模型是一种以迭代、协作和响应变化为核心的开发方法。
它强调团队合作、快速适应和交付可用的软件版本。
敏捷开发通常采用短期迭代周期,称为“冲刺”,每个冲刺结束后都会交付一个功能完整的软件版本。
敏捷模型适用于需求频繁变化、团队灵活协作的项目。
5. 螺旋模型螺旋模型是一种将风险管理和迭代开发相结合的模型。
它强调在软件开发过程中不断进行风险评估和验证,从而降低项目失败的风险。
螺旋模型的核心思想是根据实际情况逐步演化软件系统,并及时进行风险分析和管理。
软件开发的四个模型的优缺点

软件开发的四个模型的优缺点⼀、瀑布模型优点1)为项⽬提供了按阶段划分的检查点。
2)当前⼀阶段完成后,您只需要去关注后续阶段。
3)可在迭代模型中应⽤瀑布模型。
瀑布模型有以下缺点:1)在项⽬各个阶段之间极少有反馈。
2)只有在项⽬⽣命周期的后期才能看到结果。
3)通过过多的强制完成⽇期和⾥程碑来跟踪各个项⽬阶段。
⼆、快速原型模型快速原型模型需要迅速建造⼀个可以运⾏的软件原型,以便理解和澄清问题,使开发⼈员与⽤户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。
快速原型模型允许在需求分析阶段对软件的需求进⾏初步⽽⾮完全的分析和定义,快速设计开发出软件系统的原型,该原型向⽤户展⽰待开发软件的全部或部分功能和性能;⽤户对该原型进⾏测试评定,给出具体改进意见以丰富细化软件需求;开发⼈员据此对软件进⾏修改完善,直⾄⽤户满意认可之后,进⾏软件的完整实现及测试、维护。
快速原型是利⽤原型辅助软件开发的⼀种新思想。
经过简单快速分析,快速实现⼀个原型,⽤户与开发者在试⽤原型过程中加强通信与反馈,通过反复评价和改进原型,减少误解,弥补漏洞,适应变化,最终提⾼。
优点1)克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险。
缺点1)所选⽤的开发技术和⼯具不⼀定符合主流的发展;2)快速建⽴起来的系统结构加上连续的修改可能会导致产品质量低下;2.1模型类型探索型原型这种类型的原型是把原型⽤于开发的需求分析阶段,⽬的是要弄清⽤户的需求,确定所期望的特性,并探索各种⽅案的可⾏性。
它主要针对开发⽬标模糊,⽤户与开发都对项⽬都缺乏经验的情况,通过对原型的开发来明确⽤户的需求。
实验型原型这种原型主要⽤于设计阶段,考核实现⽅案是否合适,能否实现。
对于⼀个⼤型系统,若对设计⽅案⼼中没有把握时,可通过这种原型来证实设计⽅案的正确性。
演化型原型这种原型主要⽤于及早向⽤户提交⼀个原型系统,该原型系统或者包含系统的框架,或者包含系统的主要功能,在得到⽤户的认可后,将原型系统不断扩充演变为最终的软件系统。
建筑施工项目多维成本管理模型与方法研究

一
、
引言
随着市场经济的迅速发展 , 建筑产业 已发展成为 国民经济支柱产业。但是 , 市场经济的激烈竞争和 国际金融危机的影响 , 建筑工程企业获利越来越难。加强建筑工程项 目的成本管理 、 控制资源耗费、 降低 成本成为企业增加效益的不竭源泉 。它一直是人们研究的热点问题 。
化、 科学 化 、 细化 。鉴 于论 文篇 幅 的限制 , 精 论 文仅讨论第二部分 内容 , 但是 , 以项 目经理为核
法、 途径及其数据结构的合理运用问题。它是工
程项 目成本管理 的着力点。本文在学习综合前人 研究成果的基础上 , 综合分析 了建筑施工企业 特
点, 构建 了一个多视角全过程的多维成本 管理 模
科 学决 策 2 0 0 9年 第 6期
建 筑 施 工项 目多维 成 本 管 理 模 型 与 方 法 研 究
赵 红
( 中国海 洋大学 , 东 青 岛 2 境 竞争 的 日益 激烈 , 改进 和创 新施 工项 目成本 管理技 术与 方 法 成 为建 筑 企 业 实现 成
森称该方法是“ 一种有效的分析项 目数据的方法 , 每个管理团队都能快速而有效获得对他们绩效 的测量 结果 , e 成本/ S c p 进度控制系统方法是最佳 的。卡兰普和诺 顿的综合记分卡系统则是本世纪初期美 国诸
多大公司广泛使用的一种绩效分析和成本管理的有效方法 。它强调的是项 目的全流程控制 、 计量 、 记录 和管理 , 并用记分卡图反映在册 , 以考核评价经营过程中的人、 物 的耗费 、 借 财、 成果及降低经营成本。美 国工程项 目成本管理则更强调工作结构分解与成本结构编码管理。WB 根据需要对工作进行分解 , S 进而
大规模软件项目管理的思维模式

大规模软件项目管理的思维模式大规模软件项目管理的思维模式是指在处理大规模软件项目时,项目管理人员所采取的一种思维方式和方法论。
它是由多个管理原则和技巧组成的,并在软件项目管理的各个阶段中得到应用和发展。
下面以阶段性、风险管理、团队合作和持续改进四个方面进行阐述。
首先,大规模软件项目管理的思维模式是阶段性的。
它将软件项目分为不同的阶段,如需求分析、系统设计、编码、测试等,每个阶段都有明确的目标和交付物。
通过制定详细的计划,并将项目分解为多个可管理的部分,可以更好地控制项目的整体进度和质量。
此外,通过阶段性的管理,可以及时发现和解决问题,保证项目高效顺利地进行。
其次,大规模软件项目管理的思维模式是风险管理的。
在软件项目中存在各种不确定性和风险,如需求变更、技术难题、人员流动等。
项目管理人员需要具备识别、评估和应对风险的能力,以减少不确定性对项目的影响。
他们可以通过制定风险管理计划、建立风险评估机制和培训团队成员的方式来控制和应对风险。
同时,不断学习和总结经验是提高风险管理能力的重要手段。
第三,大规模软件项目管理的思维模式强调团队合作。
软件项目中,涉及到多个岗位和技能的人员,他们需要密切合作、互相协作才能完成项目。
项目管理人员需要激发团队成员的积极性和创造力,通过有效的沟通和协调,解决团队内部的问题,建立团队精神和合作意识。
同时,项目管理人员还需要保持与顾客和利益相关者的良好关系,与他们进行有效的沟通和合作,确保项目能够满足需求并取得成功。
最后,大规模软件项目管理的思维模式是持续改进的。
在一个大规模软件项目中,时刻保持对项目进展的监督和反思是非常重要的。
项目管理人员需要不断审查和评估项目的成果和过程,采取必要的纠正措施,以保证项目的质量和效率。
他们可以通过项目回顾会议、质量评估和绩效考核等方式来收集团队成员和利益相关者的反馈和建议,推动项目持续改进。
综上所述,大规模软件项目管理的思维模式是一种综合性的管理方法,包括阶段性、风险管理、团队合作和持续改进等多个方面。
软件开发项目管理经验总结
软件开发项目管理经验总结对于软件开发团队而言,项目管理是整个工作流程中占据至关重要的一部分。
在一个软件项目中,项目管理包括了活动计划、进度管理、资源分配、风险评估和质量保证等方面。
软件开发项目管理的效率和质量,决定了该项目的成功或失败。
本文将从几个角度,对软件开发项目管理经验进行总结和分析。
一、项目管理的方法论软件项目管理的方法论包括:水平模型、敏捷开发模型和结构化模型等。
不同的模型在不同的场合下使用,这不同的模型方法也有其独特的优点和缺点。
如何选择与应用一种最合适的模型方法,是项目管理者需要首先了解的一个问题。
1、水平模型水平模型又称为瀑布模型,是软件开发过程中较为传统的一种模型。
它通常按照以下步骤进行:需求分析——>系统设计——>编码——>测试——>实施——>维护。
在水平模型下,每个阶段都需要完成后,才能进入下一个阶段。
这种顺序划分明确,便于管理和控制,适用于功能单一、结构稳定的软件。
但水平模型也存在很多缺陷,如前期需求分析不充分,难以适应需求的变化等问题。
2、敏捷开发模型敏捷开发模型是软件开发过程中的一种轻量级的模型。
它主要强调的是以人为核心,打破传统的瀑布式管理方式,更加注重快速响应客户需求和变化。
敏捷开发模型的核心是要求项目管理者与开发团队之间始终保持良好的沟通和协作,以便及时处理产品的不足和问题解决,这是实现敏捷开发模型成功的关键要素之一。
3、结构化模型结构化模型是软件开发过程中的一种重点关注资料的管理模型,其方法是将大型软件分割成能够处理的独立模块,这些模块可以独立编写、测试和管理,然后再整合起来。
这种分割设计有助于提高开发团队的工作效率,减少错误出现的可能性。
但是结构化模型也需要一定的人力物力投入,在开发过程中需要投入更多的时间和精力。
二、项目管理的工具现代软件项目管理包括众多的工具和技术,这里介绍几种常用的工具和技术。
1、JIRAJIRA是Atlassian所开发的一个项目管理工具,它能够协调和跟踪软件开发的过程,并保持开发团队中人员之间的有效沟通。
软件项目管理探析
软件项目管理探析摘要:软件项目管理从一组项目计划活动开始,对软件开发的各个阶段进行管理,增强软件开发的控制能力,提高软件开发质量。
可见软件项目的有效管理对项目有着至关重要的作用。
主要讨论如何在项目生命周期的早期给出一个好的成本估算和项目进度计划,从而知道如何决定项目人员的任务以及如何组织项目人员,最后讨论如何预测和降低风险。
关键词:软件项目;项目人员;成本估算;风险管理1工作量和成本估算1.1预测软件规模为了估算软件项目的工作量和完成期限,首先需要预测软件规模。
度量软件规模的常用方法有代码行技术和功能点技术。
代码行技术(LOC)是依据以往开发类似产品的经验和历史数据,估计实现一个功能所需要的源程序行数。
把实现每个功能所需要的源程序行数累加,就可得到实现整个软件所需要的源程序行数。
但是源程序仅是软件配置的一个部分,用它来代表整个软件的规模似乎不大合理。
为了克服代码行技术的缺点,人们提出了功能点技术。
功能点技术(FP)依据软件信息域特性和软件复杂性,用功能点(FP)为单位度量软件规模。
这种方法的计算公式是:FP=UFP×TCF。
UFP包括各种输入、输出、查询、主文件数、外部接口数等;TCF 包括高处理率、性能标准、联机更新、可重用性等复杂性因子。
功能点数与所用的编程语言无关,因此在判断信息域特性复杂级别和技术因素的影响程度时,存在着相当大的主观因素。
这两种方法各有优缺点,应该根据软件项目的特点选择适用的软件规模度量方法。
1.2工作量估算根据项目的规模可以估算出完成项目所需的工作量。
表示工作量和影响工作量因素之间关系的模型有很多,我们可以从中选择一个或多个方法进行估算。
这类模型的总体结构形式:E=A+B×(ev)C(1)其中,A、B和C是常量,E是以人月为单位的工作量,ev是估算变量(KLOC或FP)。
(1) Walston和Felix开发的模型是首批此类模型中的一个,他们根据IBM的60个项目数据得出以下的方程式:E=5.2×(KLOC)0.91(2)这种规模用代码行数来测量,其中还包括注释(当然注释不能超过代码行总数的50%)。
项目管理中的项目管理成熟度模型有哪些
项目管理中的项目管理成熟度模型有哪些在当今复杂多变的商业环境中,项目管理已成为组织成功实现目标的关键因素之一。
为了评估和提升项目管理能力,项目管理成熟度模型应运而生。
这些模型为组织提供了一种结构化的方法,以确定其在项目管理方面的当前状态,并指明改进的方向。
接下来,让我们一起探讨一些常见的项目管理成熟度模型。
一、CMMI(能力成熟度模型集成)CMMI 是一种广泛应用的模型,它不仅仅适用于项目管理,还涵盖了软件开发、系统工程等多个领域。
CMMI 将成熟度分为五个级别:初始级、已管理级、已定义级、量化管理级和优化级。
在初始级,项目的执行通常是混乱和无序的,缺乏规范的流程和方法。
已管理级则意味着组织已经建立了基本的项目管理流程,并能够跟踪项目的进度、成本和质量。
已定义级时,组织拥有标准化的、文档化的项目管理流程,并在整个组织内得到一致的应用。
量化管理级能够基于数据对项目进行量化的管理和预测。
优化级则代表着组织能够持续优化项目管理流程,以适应不断变化的业务需求。
CMMI 的优点在于其综合性和广泛的适用性。
然而,它的实施可能相对复杂,需要大量的资源和时间投入。
二、OPM3(组织项目管理成熟度模型)OPM3 专注于评估组织的项目管理能力。
它通过三个维度来进行评估:项目管理的知识和实践、组织的能力以及成果。
OPM3 认为,组织的项目管理成熟度不仅仅取决于单个项目的成功,还包括组织在项目管理方面的战略、文化和治理结构等方面。
通过对这三个维度的评估,组织可以确定其在项目管理方面的优势和劣势,并制定相应的改进计划。
OPM3 的特点是强调组织的整体项目管理能力,而不仅仅是单个项目。
但它的评估过程可能较为复杂,需要专业的评估人员和工具。
三、P3M3(项目组合、项目群和项目管理成熟度模型)P3M3 主要关注项目组合、项目群和项目三个层次的管理成熟度。
它将成熟度分为五个级别:初始级、可重复级、已定义级、管理级和优化级。
在初始级,项目的管理是临时和随意的。
有关软件工程系统结构模型的应用研究
有关软件工程系统结构模型的应用研究摘要:传统软件工程的过程存在很多不足,通过软件工程系统的思想能够给我们的工作起到很好的促进效果。
本文对其概念、步骤、模型建设、风险以及成本控制进行了分析,希望对其研究起到一定的指导效果。
关键词:软件工程;系统结构模型;项目管理中图分类号:tp311.52 文献标识码:a 文章编号:1007-9599 (2012)18-0000-021 相关概念简述关于软件工程系统,当前还没有对其概念进行明确的描述。
普遍接受的一种概念是使用工程系统论这一思想对软件工程的科学体系进行考察及研究,并根据工程系统论的方法来研究其内在的规律和性状。
一般来说,软件工程系统都一般结构包括系统环境、状态、结构以及行为间的作用规律。
另外,软件工程系统具有层次性、复合性、协调性、突现性、有序性等特点。
对于软件工程系统的原则,一般主要有目的性原则、实事求是原则、确定化原则以及适用性原则。
2 软件工程系统中工作的步骤软件工程系统属于非常复杂的系统,会涉及到很多认为的因素、各种评价标准及要求、组织间的利益等,而且很多时候难以区分约束和目标。
这种背景下,了解软件工程系统中的步骤对于我们工作的开展有很大的指导作用,一般我们可以将其分为7个步骤:首先,考察问题的场景,这主要是问题可能存在却还没有被明确的某一种环境。
其次,对考察的结果进行总结,然后使用自然语言将其表达出来,或者通过图像对其进行描述,这种表述越丰富,则对于我们了解真实的问题越有利。
第三,建立根定义来服务系统概念的建立,这主要有:软件工程系统的受益者或者受害者,执行者,输入至输出之间变换的过程,所有者,环境约束以及世界观等,通过这些定义我们能够对系统活动要素进行确定。
第四,建立一个概念模型,在这个过程中,我们可以利用自然语言表达,也可以通过比较直观的图形工具对其进行表达。
第五,将现实情景和概念模型进行对比,然后根据之间的差异来修改概念模型,确保其更加符合实际的模型。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
对项目管理软件多维结构模型的思考 前言 我从事建筑工程项目管理多年,在工作的经验基础上,有一些对项目管理的认识和想法,一直想与同行共享和实现„„以下是我的文章。
1.问题的提出,及对项目管理的初步认识 1.1 项目 许多项目管理的课程、书籍、文章、软件,均对项目作了一些定义。到目前为止,还没有一个共认的简炼的定义。
我们可以从以下眼光看一个项目。 如果你从远处看一个项目,项目就像一个点、一个名称、一件事情……(例如,国家大剧院……) 当你向项目走近时,你可看到项目的轮廓,一个建筑工程建设、一个飞机制造、一个新药品的开发…..从项目管理的角度来看(例如,一个建筑工程的建设……),你看到项目的技术配置(例如,市政外线、室外场区外线、结构工程、建筑工程、机电工程、精装工程、装饰品工程…)此回答了我们一般想问的“是什么?做什么?WHAT?”
当你进入或参与或调查或指挥此项目时,你逐步发现此项目所发生的建设过程中事件――项目进度(例如,立项、设计、招标、施工、验收、开业…),此回答了我们一般想问的“怎样做?如何做?HOW?”
再进一步了解发现,项目所需要控制的目标……技术、进度、质量、安全、风险、成本、合同、资料……此回答了我们一般想问的“要求是什么?条件是什么?WHEN、WHERE?”
看一个项目,就如同由远到近、由表至里、“循序渐细”的分解项目。 由此,我们可以给项目一个这样的定义:项目就是一个相对独立的创新事件(远看一个点),此事件出自一个设想(项目输入),需有投入并实现的过程(项目过程),从而产生一定的功能(项目输出:技术配置)、达到某种目的(项目输出:约束条件)。
1.2 项目管理的基础:“循序渐细” 从上面的项目定义,我们就不难理解项目管理的定义。 项目管理就是控制并实现一个相对独立事件的工作,包括确定项目的设想(项目输入)、控制项目的实现过程(项目过程)、并验证项目的目标(项目输出)。
项目管理的基础着重在于明确了“项目总目标”后,“循序渐细”地进行项目工作的分解工作,使项目从大目标分解成小目标――合同包――步骤――工序……使我们各控制部门、各参加建设单位、各专业工种在此项目上同时“并行协同”地进行各自的工作。
那么,如何将所有人的工作组织在一个有秩的计划中?如何分解项目目标? 以往的项目管理及软件均是按WBS(工作分解结构)进行项目的分解,是一维的。很多时候我们自己就将项目分解乱了…不知道是先按项目过程分解,还是按项目技术配置分解,或是相互穿叉。 按上述我们所看项目的眼光,可以用三维对项目进行分解,而时间单位仅是一个测量尺而已。 A. 按项目产出物或产品分解,则为PBS(技术配置分解结构系统)。比如, 汽车可分为车身、发动机、底架结构; 建筑可分为室外、裙楼、主楼、结构、建筑、机电、装修等; B. 另外一维是按工作过程流程分为WBS(过程工作分解结构系统)。比如, 汽车制造可分为概念、设计、采购、加工、组装、测试等; 建筑的流程可分为规划、立项、征地、场地、设计、招标、采购、施工、验收、试运行、交付等)。 C. 第三维是按项目目标分解为MBS(项目目标分解结构系统)。比如, 产品技术配置(在制造行业中已经经常使用此概念,有PLD配置管理系统)、进度、质量、造价、合同…… D、当然,在一个项目中还有一些多级、多层、多组织的概念: 多级别:项目是由各级单位组成的――例如,项目管理层次有投资人、业主、项目经理、项目监理、设计单位、施工单位、供应商、分包商、物业管理使用单位等;对不同级别的使用者来说反映不同的重点,对于业主高层领导,多层计划是看见较高级别的问题,从宏观的角度看是否存在工期的滞后、费用超出的问题,而对于项目管理部的计划工程师来说,看见的是比较微观的问题,即工程计划的哪些WBS和哪些作业存在问题,应该如何去调整计划。
多层次:项目(例如,在P3软件中)在EPS、项目、WBS、作业、步骤上形成“从粗到细”的、按照项目“渐进明细”特征的层层细化的计划,项目被细分为总目标――大目标――小目标――合同包――步骤――工序……成百、上千、上万个工序和步骤。
多组织:所有的项目,均是由多个组织共同“并行工作”完成的。各单位组织按照上述分解系统,分别完成不同项目产出物,或在不同的过程阶段,或控制不同的项目目标,或承担不同的管理级别任务,或处于不同的管理级别岗位,或承包不同的子项目合同任务……
由此,可将项目目标分成多级、多维分解结构系统:项目总目标――大目标――小目标――合同包――步骤――工序……成百、上千、上万个工序和步骤。这些众多的工作均是以时间为测量尺,以逻辑关系或组织关系的前后顺序编排而成。
1.3 现有一些项目管理及软件,在实际工作中的问题 现有的项目管理,一般都使用项目管理软件辅助进行WBS分解工作,(是按一维方式分解的)形成一个个工作包(合同包)。并以进度计划管理模块为基础,然后将资源、成本、组织责任、等信息放置到每个工作包上,再按时间坐标进行排列,从而形成一系列项目管理各种子目标随时间轴的目标计划安排和每个工作包上信息强度列表(例如,资源分布图表)。
在此种工作中,通常,进度计划管理模块的表现形式有甘特图、单代号网络图、单代号时标网络图、双代号网络图、双代号时标网络图等表现方式。
甘特图的最大优点是表格化,许多项目管理软件中预制了大量的项目管理表格,十分方便于统计报告。但是,其最大的不便之处是一维表格,所有的项目工作分解任务均在左侧单列,往往一个项目的分解表很长,而甘特图中的条条很稀,占用很多纸张图面空间,不能一目了然。
双代号网络图和其双代号时标网络图的最大优点是图形化表现形式,图面很紧凑;但其最大的缺点是不能形成表格化,虽是二维的,但不能按项目分解的思路进行排列成表格。而在项目管理实践中经常需使用各式各样大量的表格,故而双代号网络图在项目管理中的应用遇到了阻碍。
单代号网络图和其单代号时标网络图的优缺点同双代号网络图。同样,在项目管理中的应用遇到了阻碍。 题外话,单代号网络图与双代号网络图之间可以进行转换。把单代号网络图中的节点方框拉长,就得到双代号网络图的工序线。有一些项目管理软件已经实现了此种转换。
另外,我建议:我们在双代号网络图中引进第三节点――即除头尾二节点外,我们在双代号的中段引进第三节点,用来表示工作间的搭接关系,则双代号网络图同样可以表示FS、FF、SF、SS等工作间搭接关系。
2.解决方法――软件的思路 为了克服双代号和单代号网络图不能形成表格化的缺点,我本人有以下建议模型。 2.1、我们经常会遇到此种情况,即在进行编制WBS工作分解结构时,到底是以项目阶段过程为主线进行分解,比如建筑工程项目分解成立项、设计、招投标、施工、验收等阶段过程,还是以项目产出物的专业系统为主线进行分解,比如建筑工程项目分解成结构、建筑、机电、装修、外线、市政管线等专业系统?有时候拿不准,二者相互穿叉,自己就分解乱了,出来的分解表自然比较乱。
其实,我们发现,在进行WBS工作分解结构时,用矩阵表方式是最清楚的。我们可以将项目实施的阶段过程和步骤分解项列在表格的顶部行中,将项目产出物的专业系统分解结构项列在表格的左侧列中,这样就形成了一个WBS二维矩阵分解表。表中各单元格内的数据就是项目子项目、或是合同包(或称为工作包)、或是各工序的承载数据,各单元格相当于单代号网络图中的节点,比如各工作包格中可以承载子项目编号、工作编号、工作名称、工期、资源、成本、责任单位人、合同分解编码等。
再者,如果将上述矩阵表中各单元放在我们一般编制进度计划网络图中,按工序的逻辑顺序連线起来,再加上时间坐标,就形成一张同我们一般思维相同的《单代号时标网络图》:横向看是每个专业系统的工作过程各阶段各步骤,纵向看是项目每个阶段中并行工作着的各专业系统。而且,此图也符合我们平常的工作编排―――即从图的横向看,项目各系统专业均有一个实施过程,比如建筑、结构、机电、精装专业均有设计、招投标、施工、验收等过程,从图的纵向看,项目的设计、招投标、施工、验收的每个阶段过程中均有项目各系统专业的人们在并行工作。图中的节点,即为大项目的子项目,或为小项目中的合同包。 在时标网络图中,各单元项被放置在时间坐标中,则其承载数据也就随之被放置在时间坐标中。进而,我们随这得到了有时间坐标的人员计划、图纸计划、材料计划、设备计划、场地计划、资金计划、机械计划施工计划、验收计划、。我们可以按照矩阵表的纵横两方向进行统计,进而,得到了有时间坐标的设计、招投标、施工等《项目各阶段计划》,或者,有时间坐标的《项目各专业系统的分包实施计划》其中包括各专业系统的设计、招投标、施工等工作。
2.2、当然,一般项目不是用此一个二维矩阵表格就能表现清楚的。按P3软件的原理说法,在大型工程项目的管理中,进度计划的编制一般是采用编制不同内容的多级计划(multilevel plan)和 多层计划。也就是说,项目在EPS、项目、WBS、作业、步骤上形成从粗到细的、按照项目渐进明细特征的层层细化的计划,计划的层次远远超过传统意义上的进度计划。而这一计划对不同级别的使用者来说反映不同的重点,对于高层领导,多层计划是看见较高级别的问题,从宏观的角度看是否存在工期的滞后、费用超出的问题,而对于计划工程师来说,看见的是比较微观的问题,即工程计划的哪些WBS和哪些作业存在问题,应该如何去调整计划。 项目经理都知道,项目进度计划一般均有三级管理计划。 第一级为项目总进度计划,一级计划一般称为里程碑计划,一般反映的是重要的总形象进度控制点。 第二级为项目各阶段或各子项目进度计划,二级计划分为指导性计划与控制性计划,其中指导性计划由业主工程部门编制,其编制依据是里程碑计划及项目的投资与单位工程的轻重缓急编制,
第三级为各承包单位的实施进度计划。三级进度计划是由承包商根据二级控制性计划编制,可以说是合同包进度计划,反映承包商对所承包的项目内容的总体安排。
而四级计划则是三级计划的作业实施计划,是对三级计划的进一步分解.通常用滚动计划。 滚动计划是在同一个计划上,在一个固定的时间,输入进度,推算将来。而每一次提交作审批的,都是从这个计划内,抽取部份内容提交。《年滚动计划》就是每年提交整个计划。《季滚动计划》就是每季提交数据日期后180天的推算。《月滚动计划》就是每月提交数据日期前30天的进度和数据日期后90天的推算。《周滚动计划》就是每周提交数据日期前7天的进度和数据日期后35天的推算。
各级上计划中的目标参数,例如,工期、成本、资源等,均按照工序间的关系路线进行汇总到上一级计划中。反映了工程施工由粗到细逐步深化的过程。在多层计划情况下,无论你处于哪一个级别,看见的计划都是完全一致的。无论是设计计划、采购计划还是施工计划,都完美地统一于总计划里面。例如,我们需要的只是设置设计的交图计划点与采购计划订单的接口、采购计划交货时间与施工计划的接口。例如对于一个大型工民建项目,首先可以分为业主、监理、总包单位、设计、分包单位、主要设备供应商等不同的应用单位,分别设为不同的EPS级别;而其中的任一项目,又可以按施工部位和施工阶段分为不同的WBS;对于每一个WBS,又可以分解为不同的作业及作业步骤。对于每一次分解,都可以做出费用分解计划。在作业层次上使用作业完成百分比,在WBS和EPS层次上使用预算完成百分比,这样就可以在各个WBS上灵活地应用赢得值技术对一个或者多个项目进行绩效考核、进行工作变更的管理以及项目发展趋势的准确预测。