项目管理软件

项目管理软件

建设工程项目管理软件开发风险浅析

本文结合公路工程建设项目管理软件的开发,对其过程存在

的风险进行了一般的分类、分析，供大家参考。

0引言

建设工程是一个产生巨量内容的地方，这里的内容包括文

档、数据、图片、音像等。而软件则能让这些内容有效地积

累存储并通过最有效的手段使其充分发挥应有的作用。所以

软件工程和建设工程的结合是工具和内容的结合。在这基础

之上的大数据工作，才是财富最大化的未来。

1建设工程项目管理软件概况

建设工＜项且萱理软件是指将建设工程业务操作的过程通过

软件化手段实现，例如审批、填报、记录等。通过搭建软件

平台或软件系统，初始录入各类项目管理用的内容,在使用

过程中不断的更新信息和数据。

不似一般的小软件开发，建设工程项目管理软件一般需要承

载大量的信息和内容，同时还有复杂的流程处理。这就决定

了该类软件的开发面临的风险不同于一般的软件开发，其风

险特征既具备普通软件开发的特点，又具有自己的特殊性。

2建设工程项目管理软件开发风险及分类

风险是指客观存在的，对目标达成具有负面影响的不确定

性。风险分类方法是根据风险性质、风险的来源、风险产生

的阶段、风险产生的后果、风险发生的对象等进行的，有多

种不同的分类方法。项目管理软件开发按照上述五种分类方

法有如下风险因素。按风险性质分为：经济风险、政治风

险、社会风险、技术风险、资源风险;按产生阶段分为：业务

开发、需求阶段、业务分析、接口、软件开发、交付使用；按

产生后果分为：重大、较大、一般、轻微;按发生对象分为：

业主风险、开发团队风险(业务团队风险、软件团队风险)、

市场团队风险。

3项目管理软件开发各阶段面临的风险分析

3.1软件开发阶段面临的风险穷举

对风险进行分析、评估、管控的前提是对风险进行识别，找

出某一过程所有可能的风险因素才能更好地对症下药。对项

目管理软件开发各阶段的风险进行分析，利用穷举法对其风

险因素进行分析。

3.2业务开发风险

业务开发风险是指出在项目市场开发阶段所面临的不确定

性。

(1)项目的不确定性。项目团队、开发团队缺少配合或经验缺

失，对项目策划、建议、实施措施理解、分析不到位，导致

项目本身在落地之前产生了易主、取消、降低投资等风险。

(2)市场不稳定。一些项目管理软件的开发必须依托市场经济

或工程项目进行，当这方面发生政策变化、重大变更以及建

设单位对项目软件的需求降低时,容易产生项目中途流产风

险。

(3)业主心态。如何抓住业主的痛点，真正解决业主的问题，

或者仅仅是从业主的角度出发思考项目管理软件的做法，是

项目先发经理应该深思的问题。

(4)自身实力不足。项目管理软件结合了建设工程和软件工

程，建设工程不同于其他行业，例如金融、互联网等，其透

明度高，讲究资源效率。工程行业自身的资本运作密集，项

目建设流程模式固定并且存在许多的“漏子、暗道、关系、

利益”等，如果没有足够的市场疏通、业务分析和软件开发

实力，难以做出成功的项目管理软件。经常可见有许多项目

管理系统开发完成以后闲置、弃用，就是因为这些原因。

3.3业主风险

和以上开发阶段来自于业主的风险不同，这里的业主风险更

多的是强调业主在项目软件项目开发决策和执行力上存在的

风险。

(1)因为是建设工程的原因，业主可能存在自身业务能力不足

导致软件开发初期，功能需求不全面、不详尽、模糊的情

况。

(2)部分业主因为存在建设管理程序不合法,例如图纸准备不

到位就招标施工、随意调整施工进度、重大变更多等，对软

件部署时的数据初始化、部分功能使月造成严重影响。

(3)项目管理软件属于新型的工程建设费用，国家对此暂未出

台相关取费标准，因此对于软件开发、使用的资金来源，部

分业主解决能力不强，导致软件开发和使用受阻。

(4)项目管理软件的开发要以合同为主线，早制定、早落实合

同内容。

(5)因为建设管理人员和软件开发人员在知识体系上的不同，

需求方经常会给出软件难以实现或在合同、投资范围内难以

实现的功能要求，从而产生搁置、重启需求调研、功能调整

等风险。

3.4需求阶段风险

如果软件开发是业主、业务团队、软件团队的三级开发结

构，那么需求阶段的风险就是业主和业务团队之间的信息过

渡。了解这个阶段的风险尤为重要。

(1)需求细分不全面。需求细分，其实是对软件开发所需要的

一切原始信息的分类。业主本身积累了足够庞大的知识量和

隐藏的管理行为，需要进行细分挖掘。

(2)需求调研不充分。需求调研不够深入，自身缺乏对建设工

程活动的更多认识，从而产生遗漏、错失相关需求信息。

(3)需求信息不对称。在需求调研、收集的过程中，因为记

录、理解的原因，需求信息发生了错位，偏移了业主的初

衷。

(4)需求文档管理不规范。需求阶段要做好文档记录，对相关

会议进行备案，对业主的需求要进行充分确认，形成规范有

序的文件档案管理制度,防止出现软件开发问题找不到源

头,增加开发成本和难度。

3.5业务分析风险

要将传统的建设工程的知识体系、管理行为、结果过程通过

软件实现，首先要对建设工程所涉及的一切业务进行深入分

析。

(1)业务流程不确定性。建设工程的审批流程、上报流程、验

收评定流程等，涉及的人多、单位多、文件多，在实际操作

中，流程具有可变通性、不定期性、人员代签等问题。

(2)业务内容生成难度大。建设工程的业务内容具有涉及面广

泛、数量庞大、牵连性强、专业性高等特点，而软件开发需

要集中处理大量的业务内容，同时准备好初始化数据，需要

软件工具、专业人员、组织管理等多方密切配合。

(3)软件化后的现实风险。软件化的弊端是固定化，少了灵活

性，对于工程建设人员可能会带来体验性的风险。因此要尽

可能设计得合理，从工程人员的习惯出发，讲求实用性、适

用性。

(4)业务架构与系统架构。针对项目质量、进度、计量支付、

档案等的业务管理存在内在的关联关系，在软件化的时候，

要注重各模块之间的内在关联关系，关注各模块内部数据的

调用和资料文件的归属。

3.6接口风险

业务团队和软件团队的对接是真正实现项目管理软件开发的

最重要环节，提高业务人员的流程策划能力和软件人员的业

务熟悉程度同等重要，让双方在交错出实现软件的顺利开

发。

(1)需求理解不到位。单纯的文档化需求分析及设计交接很难

形象直接地展现需求方对软件开发的各种要求，软件人员也

要花费大量的时间去了解文档的背后，然后梳理成自己的逻

辑。这个过程中，很可能发生需求曲解、重新设计、修改困

难等风险。

(2)设计思维差异化。在原型设计功能不能满足建设工程软件

项目开发的时候，因为软件开发人员的固有思维模式，其对

界面设计、功能点选取、流程设置、角色配置会有个人的惯

性设计方式。

(3)资源配置不合理。软件项目开发是一个将业务工作持续软

件化的过程，有点儿边设计边施工的感觉。这个时候软件方

面要合理地配置各项开发资源，包括人力的投入曲线、进度

计划的制定、业务人员的工作安排、基础数据的准备等。

3.7软件开发风险

软件开发风险已经有很多专业性的风险研究,在这里不做相

应说明，仅列出软件开发可能面临的风险类型:①软件开发

技龙不足。②配套软硬件风险。③软件开发管理风险。④软

件开发安全风险。⑤人才组织风险。⑥文化风险。

3.8软件交付使用风险

(1)市场风险。体现在长周期软件开发项目中，市场环境变化

带来的风险。比如竞争对手更新更快的产品出现，研发产品

市场地位下降;项目建设投资发生变化，费用投入减少;环境

舆论对新产品应用带来的不良影响，尤其是跟风产品。

(2)使用测试风险。主要体现在系统集成以后，因未有充分准

备或潜在软件bug而出现大量的问题。

(3)用户体验风险。软件开发过程客户参与度不高造成的使用

习惯风险，体验不佳;对软件使用说明不够详细全面，造成用

户使用障碍。

(4)二次开发风险。跟工程返修类似，因部分功能大量调整或

新增功能，以及系统整体功能、稳定性、适用性等出现严重

bug,而面临二次开发风险。

4总结

建设工程项目管理软件归根结底是一种产品，应积极应用产

品开发的相关管理方法。但也一定要注意到建设工程的特殊

性，要深入分析软件产品在跨行应用时的“入乡随俗”和

“技术先进”的共融方案。

业务设计和软件开发要紧密结合，但也要有各自分立和结合

的机制。业务需求要清晰，转化为软件设计要确保“不失

真“。加强和重视产品开发过程中容易发生并带来影响较大

的风险，合理规避和减少风险损失，降低开发成本，提高开

发效率和产品质量。

有关应用项目管理软件的开发与设计探究

资源优化的准确性受原始数据收集积累以及资源权重系数的

影响。因此，对工程项目管理的基础数据要多收集、整理，

通过不断分析和总结才能逐步提高资源均衡优化的质量及可

靠性，使之更好地为工程管理服务。网络计划的资源均衡优

化只是相对均衡，不可能绝对优化。在工程项目管理过程中

还必须根据实际情况采用其它辅助措施，才能真正满足资源

供需的矛盾。

在工程项目的进度管理中，限于资源的约束，网络计划的作

业之间除了存在工作逻辑的联系，逻辑上无关系的作业也有

可能因为需要同种资源而存在联系。因此，在安排各项作业

逻辑关系时就要考虑资源的限制和资源的供应过程对网络计

划的影响。对网络计划进行资源优化，不仅可以方便资源调

配，而且能够降低工程成本。本文通过加权平均将多资源转

化为单一资源综合指标，通过项目管理软件对总承包工程施

工专项计划进行“工期固定，资源均衡”的优化，获得了较

好的应用效果。

1、网络计划技术应用现状分析

据有关资料分析，目前我国网络计划技术的理论研究与应用

水平，尚处在中间状态，虽然我们在理论水平与应用方面同

发达国家相比相差无几,但在应用管理上，特别是计划执行

中的监督、控制及跟踪调整方面，较少落在实处，基本停留

在编制上，主要影响为工程设计多变，材料供应跟不上，应

用者素质不高。目前我国在网络计划技术的理论研究方面同

国外发达国家相比相差无几，但在应用管理上比较落后，基

本上停留在计划的编制与网络图绘制上。许多企业运用网络

计划，或因招投标文件所要求，或为投标施工组织增加“技

术含量”。所以如此绘制出的网络图不是错误连篇，就是华

而不实，根本谈不上如何运用这一科学管理方法进行项目管

理。绝大部分施工企业网络计划技术的应用只停留在编制计

划或画出几张网络图上，对计划执行日的监督与控制及计划

调整缺少有效的管理方法。网络计划在真正的应用过程中，

应该对于实际进度滞后的项目通过改变某些后续工作的逻辑

关系或缩短某些后续工作的持续时间，并制定相应保证措施

来调整偏差。在施工网络计划的编制出，只是确定各工作单

元之间的逻辑关系，而没有根据施工方法确定工作单元中各

项工作之间的所有关系。编制深度不够，更谈不上网络计划

的优化与控制。

2、网络计划资源优化方法分析

2.1资源优化

在通常情况下，网络计划的资源优化分为两种。“资源有

限，工期最短”的优化是在资源供应有限制的条件下，寻求

整个计划工期最短的方案。“工期固定，资源均衡”的优化

是通过调整计划安排，在工期保持不变的条件下，使资源需

用量尽可能均衡的过程。这里所讲的资源优化，其前提条件

是在优化过程中，不改变网络计划中各项工作之间的逻辑关

系；在优化过程中，不改变网络计划中各项工作的持续时间；

网络计划中各项工作的资源强度为常数，而且是合理的；除规

定可中断的工作外，一般不允许中断工作，应保持其连续

性。衡量资源不均衡程度的指标有三种：资源需要量不均衡

系数、资源需要量方差和极差。三种指标均是值越小，资源

的均衡性越好。在实际工程中，很难使上述指标都达到最

小，一般选用方差作为衡量指标，即资源需要量与单位时间

平均需要量之差的平方和的平均值。

2.2多资源优化

资源作为工程项目实施的基本要素，它通常包括：人力，包

括各专业、各种级别的劳动力以及不同层次和职能的管理人

员；原材料和设备，它构成工程的实体，例如常见的砂石、水

泥、砖、钢筋、木材、设备等;施工所需设备，如塔吊、混凝

土拌合设备、运输设备和施工工具。此外，资源还可能包括

资金、计算机软件、信息系统、专利技术和方法等。工程中

各种工作所需资源的种类及数量不同决定了每种资源的需求

曲线不尽相同。调整网络计划的非关键作业会对各种资源的

均衡效果产生不同的影响，有可能会导致在改善有些资源平

衡效果的同时又破坏了另一些资源的平衡状态，加大其不平

衡程度。简单的重复使用单一资源均衡优化的方法不能解决

多资源优化的问题，甚至出现矛盾。如果引入权重系数，且

所有种资源的权重和为，即。根据工程实际，按照各种资源

对工程的影响程度进行加权平均，计算出综合资源指标，可

以将多资源平衡问题转化为单一资源平衡优化。这样，对网

络计划进行“工期固定，资源均衡”就是找出满足工期规定

条件的网络计划关键路径和关键作业并计算总工期，计算各

个非关键作业的总时差和自由时差。保持关键作业不动，调

整非关键作业的开始时间，直到综合资源指标分布函数方差

最小。

3、项目管理软件资源平衡实践分析

3.1适应性调整

Primavera早先版本的软件PrimaveraProjectPlanner,简

称P3,对项目资源使用的规划只能由软件自动按照相应任务

的计划时间将资源预算量分摊到每个时间周期中去。单纯使

用软件功能规划资源的方式并不灵活，资源的分布柱状图非

常平齐，这种情况在工程中是不现实的。目前的P6软件允许

用户在软件自动分摊周期数量的基础上手工编制或调整资源

在每个时间周期内的使用数量，以便根据实际情况更合理的

规划项目资源使用。

3.2P6软件资源平衡

用手工计算的方法对网络计划进行资源优化，计算调整工作

量十分巨大，而且准确性也得不到保证，以往在实际工作中

很难起到作用。在工程上应用