浅谈企业信息化之项目管理.docx
《浅谈企业信息化之项目管理.docx》由会员分享，可在线阅读，更多相关《浅谈企业信息化之项目管理.docx（17页珍藏版）》请在冰豆网上搜索。
浅谈企业信息化之项目管理
浅谈企业信息化之项目管理
指导教师：
海刚
小组成员：
梁诚杰
2010年12月31日
一、我国企业信息化建设的现状
1.意识上
随着体制转轨，市场化压力的逐渐增大，企业深切体会到了信息的重要性，对信息化可以促进企业发展也基本达成共识.总体上看，认识在不断提高，但在实际操作上的重视程度各个企业却相差很大。
企业竞争环境的变化促使企业向信息化寻求出路，信息技术的成熟及成本下降也使企业提高信息化水平的积极性进一步提高。
许多大中型企业在制定中长期发展规划中都把信息化建设作为今后几年要抓好的重点任务。
与此同时，网络化发展为中小企业利用信息，迅速崛起创造了极为有利的条件，其信息化建设的热情与大中型企业相比并不逊色。
2.需求上
1）成长企业信息化建设起点高，老企业信息化基础相对薄弱。
改革开放后新成长起来的企业由于技术装备智能化水平高、市场观念和现代管理意识强，其信息化建设基础较好，很多企业在创建时就把信息化建设考虑在。
这些企业无论在信息化水平还是在信息化应用效果方面都比传统老企业具有明显优势。
2）企业效益好、外向型企业、具有国际市场开拓能力的大中型企业信息化需求较为强烈，效益不好、竞争领域相对狭窄以及小型企业信息化的需求相对不旺。
企业竞争环境越复杂、竞争压力越大，越要求企业信息化达到较高水平，但企业经济效益的好坏往往决定了企业在信息化建设方面的投入保证程度及其实施效果。
3.应用深度上
1）基础应用的普及面较宽，重大信息工程建设相对滞后。
目前我国各种规模企业绝大部分都用上了微机，利用计算机技术进行信息处理和辅助管理。
许多大中型企业拥有相当多的信息技术设备，也培养和储备了一些自己的信息化人才队伍。
但重大信息工程建设如MIS、MRPⅡ、ERP、CIMS等普及率低、水平也相对落后，有些企业应用效果不好。
2）信息化建设出现“分层”
目前企业的信息化投入和运用的分布很不均衡。
企业的中间技术层，尤其是设计部门和财务部门已经初步实现计算机管理；但企业的决策部门的信息化建设依旧很薄弱，基本停留在“形象工程”上，相关的报表满天飞；另一方面企业的末梢，如供应、生产、销售等环节的计算机基本上是空白，整个企业的信息化建设呈现出中间大，两头小的格局，也即是目前的企业信息化建设还处于“战术层“的居多，而企业的“决策层”和“战略层”是相当薄弱的，也是下一步企业信息化建设中的一个重点。
3）信息化水平和普及程度因行业、地区经济发展水平而存在差异。
总的来看，技术含量高的行业和经济发展水平及市场化程度高的地区，企业管理水平高的企业，信息化水平和普及程度相对较高；技术含量低的行业和经济发展水平及市场化程度低的地区，企业管理落后的企业，信息化水平和普及程度相对较低。
4）企业上网数量逐渐增多，但是应用网络进行交易的少
2000年“企业上网年”，很多企业都建立了自己的，但是绝大多数企业起到的作用仅仅是停留在媒体的简单扩充上，没有充分利用网络资源进行深层的挖掘，尤其是电子商务的运用上还非常落后。
4.技术实现上
1）研究较深，实现较浅单元技术和集成技术的研究上取得一定的成绩，尤其是在体系的建立上的研究已经到达了一定的深度，但是在相关技术转换为产品，相关产品转换为产业的程度较低，很多的科研成果被科研院所束之高阁，没有发挥其应有的成效。
已经转换的技术，因企业的市场化程度较低或规模较小或相关的政策扶持较少，没有形成整体的规模效果。
2）“信息孤岛”日益突出
随着企业计算机技术运用的不断深入，不同软件间，尤其是不同部门间的数据信息不能共享，设计、管理、生产的数据不能进行交流，数据出现严重脱节，即产生“信息孤岛”势必给企业的运用带来：
a、信息需要重复多次的输入；
b、信息存在很大的冗余；
c、大量的垃圾信息；
d、信息交流的一致性无法保证。
“信息孤岛”的问题已经严重的阻碍了企业信息化建设的整体进程，使企业在进行新一轮投入时，瞻前顾后，难于决断，而解决“信息孤岛”问题的关键不仅仅是在软件的技术方面，更重要的是在企业的流程管理和相关的技术标注化等相关技术方面。
3）单元技术需进一步深化。
计算机单元技术如CAD、财务等软件能解决企业部分紧急的问题，但随着企业计算机运用的不断深化，目前的软件无论从深度和广度都很难满足企业的要求，尤其是计算机软硬件技术的不断发展，老的瓶颈问题解决了，但新的瓶颈问题随之而来，计算机的进一步深化运用提到日程上来。
4）管理理念亟待更新。
企业的信息化建设能否取得成功，除了相关的技术因素之外，更大的因素将取决于能不能将先进的管理理念同企业的具体实际良好结合，“企业信息化建设以其说是技术问题还不如说是管理问题”。
管理的不科学、流程的随意性、“人治”与“法制”的混淆，是国企业的通病，如何运用良好的时机，整合企业的管理，不是某一个或几个信息集成商所能解决的，而是取决于我们的企业领导如何更新观念。
5）企业的个性化需求
企业由于所处的行业及历史背景各不相同，企业的运作模式虽有雷同，但企业在信息化建设过程中的需互异的，就需要“量身定制”，以工具化、成组的设计来实现不同的需求，同时考虑信息的集成性和开放性是信息集成商所面临的挑战。
二、我国信息化存在的问题
随着企业IT建设的深入和国际交往的增多，应用开发的项目管理日益受到重视。
国面向企业客户的应用软件开发项目管理的问题和差距何在？
更多的可能是实践问题而非理论问题，以下结合笔者在集团用户、外资企业和国民营企业的项目经验和思考，作些初步的探讨。
1.项目管理意识
不能真正区分项目实施和项目管理的工作任务，是目前存在的普遍问题。
可概括为“没事做”和“没人做”并存的现象，这往往由开发骨干兼任项目经理所致。
一方面，如果设立专职的项目经理，专做项目管理而不做任何分析、设计、编码、测试等具体的技术实施工作，就会感觉“没事做”，或是在打杂。
另一方面，由于主要或全部精力均忙于具体技术工作，各种项目管理任务（如：
项目分析/评估、项目计划的制定/检查/调整、上下左右的沟通、专业资源调配、项目组织调整、项目财务控制、风险分析/对策等）不可避免地疏于顾及，项目管理的事情“没人做”，导致项目控制的问题“积劳成疾”，后悔莫及。
在中、小型项目中，管理任务可能不饱和，有条件的项目经理可以兼任项目技术主管或业务咨询，关键在于要有将项目管理工作区分出来的意识和责任感。
2.项目成本基础
项目管理的精髓是必须在规格（Specification）、成本（Cost、Resource）和进度（Schedule）之间取得平衡。
而目前国的系统集成企业，普遍没有建立专业工程师的成本结构及运用控制体制。
因而无法确立和实现项目成本的指标、考核和控制，导致公司与项目经理之间的责任不清。
直白地说，项目经理可以不计成本地申请资源，“信点兵，多多益善”，而公司处于两难，答应则可能投入太大，拒绝则必须承担项目失败的责任。
不建立专业资源成本结构，就无从实现项目的成本管理，就不会有真正的项目管理。
3.项目管理制度
规化而且切实可行的项目管理制度，必须因企业、因项目而异。
一般而言，应是项目管理原理、企业/行业特点和项目规模/性质、企业开发文化/素质等各种因素综合的产物。
产生的过程应是，由具一定的理论素养、丰富的规化项目实施经验和总结能力的资深项目管理专家，结合企业的具体情况，有针对性地制定，并经培训、试行、调整予以落实贯彻。
国目前的普遍情况，或者是企业无项目管理制度，仅凭个人经验实施项目管理；或者是书生制度，照搬教条，纸上谈兵，束之高阁。
其结果是，不仅实际的项目管理无所依循，而且也使项目监管层难以落实项目的间接监控和支持。
4.专业服务组织
国际上的企业级应用软件的开发组织，基本上分为产品研发和专业服务两类。
国由于市场成熟度低等原因，多以直接面向客户需求的项目型开发为主，应属专业服务型的技术组织结构。
目前国的差距主要在于，一是公司策略上将项目实施部门定位为配合系统产品销售的成本中心，而未能作为一个独立核算的业务单元或业务方向；二是基本采取层次性的业务管理性组织结构，而缺乏业务管理和专业管理（诸如运营经理、资源调配、资源开发、行政助理、项目会计、项目质量监控等）的分工合作的矩阵结构；三是缺乏纵向专业深度的设计和结构。
专业服务组织结构的差距，使专业服务部门市场定位模糊，发展方向迷茫。
平时不利于专业队伍建设，不能持续有效地发展和提高技术队伍的专业素养；售前活动中，不利于程序化地组织售前支持及控制售前风险；项目实施中，不利于合理及时的项目资源的调配，不能将运营（Operation）监管和项目监管有机结合，以确保项目监控状态。
5.项目计划
项目计划是项目经理实施项目管理控制的基础。
目前的差距主要有：
一是项目计划的制定不够严谨，随意性大，可操作性差，因而实施中无法遵循，如项目计划过于粗略，落实Breakdown（“粒度”）不足；没有做到任务、进度、资源三落实。
二是缺乏贯穿项目全程的详细项目计划，甚至采取每周制定下周工作计划的逐周项目计划方式，其实质是“项目失控合法化”。
三是项目进度的检查（与进度计划比对）和控制不足，不能维护项目计划的严肃性。
项目计划的Breakdown或“粒度”，是一个需要小心把握平衡的问题。
越细则控制力度越大，但项目管理的成本越高；反之亦然。
以国目前的状况，个人看法，3个月以下的项目，应细到人天，至少2～3人天；半年以上的项目，至少应到人周。
如果项目经理对于项目专业领域不够熟悉，则项目计划主要应由项目技术主管和Teamleader（团队领导者）具体起草，因为他们最熟悉工作容和具体资源的适应性，项目经理做沟通、调整、平衡、确认，并负最后之责。
6.项目风险意识
项目风险意识就是失败意识。
每当我们启动一个项目的时候，我们往往憧憬项目投产之日的成功，但是否想过精疲力竭后失败的沮丧？
做项目不比卖产品，产品卖出就是成功，项目投产才算成功；产品是静态的，项目是动态的；产品质量有问题可以包换、保修，项目一旦失败，时间不能倒流，客户损失的可能就是市场竞争优势和机遇。
风险意识，就是对这种结局的可能性的警惕。
如此，我们就会小心谨慎地处理许多项目业务需求、技术方案和组织管理的问题。
目前市场竞争的激烈和市场的成熟度不足，可能导致应用开发项目的恶性竞争风险。
客户希望物美价廉而加需求、压价格、压进度；厂商惟恐出局而拍胸脯、打包票。
忽视必要的科学的可行性分析和评估，签订不可能完成的服务合同，项目尚未启动，已经注定了其中的高风险。
事实上，这种风险是双方的，厂商可能是经济和信誉上的损失，客户也可能是经济和业务发展上的损失。
7.业务参与意识
客户购买IT系统的目的是为了更好地发展自己的业务。
应用软件将通用计算机变成了专用的业务系统，因此应用软件中渗透着业务制度、策略，成为应用软件甚至是IT系统的灵魂。
因此，国际上成功的案例是业务部门贯穿始终地参与，作为确保项目成功的底线之一。
遗憾的是，我们经常会看见技术人员“独立”地开发“创新”性的系统，究其原因，往往有：
认为应用开发是IT的事情；认为业务人员的认识囿于手工或现行方式；业务人员工作太忙，无暇参与项目；嫌业务人员要求太多、太口罗嗦，以致频繁变更需求。
尽管这些原因不无道理，但归根结底，应用项目是来自于业务部门的需求，最终供业务部门使用。
业务参与不足，既可能产生业务偏差的隐患，也可能因业务人员不理解、不认可而夭折。
三、IT项目管理
在诸多招聘广告中，经常可以看见一些IT软件企业或集成商对他们的技术部门经理或者项目经理是这样要求的：
有XX行业X年软件开发经验
精通XXX编程语言
掌握XXX数据库
……
这里面隐含着什么意义？
那就是对于大多数IT企业，他们眼中的技术部门经理或项目经理都是技术高手，部门员工碰到什么搞不定的技术难题，这些经理一出手，一切搞定，赢来阵阵喝彩。
这应该是这些经理们的第一职责吗？
显然，有不少人都会说“No”。
他们明白，对于这些经理们来说，管理好项目是更重要的职责。
正因为这样，项目管理资质认证成为继MBA之后的一大热点，许多媒体纷纷刊登有关项目管理资质认证的各种利好信息，大有项目管理资质认证是解决一切项目问题之灵丹妙药。
其实，专业的项目管理是保障项目成功实施的关键因素之一，但并不是唯一因素，就象股份制只是使企业的所有制趋于合理化，但股份制并不能保证企业的经营一定能获得良好的经济效益。
虽然国众多IT企业都开始重视项目管理，也积极的让员工们参加各种项目管理的培训，但是在实际的项目执行中，往往还是会出现许多不尽如人意的情况，或者可以说，在注意项目管理后，许多项目的执行效率并没有得到实质性的提高。
或许，我们需要一双慧眼来仔细看看项目管理领域里存在的诸多关键点。
1.项目管理的理论、方法和工具
首先需要认清的是项目管理的理论、方法和工具的区别以及相互关系。
有不少人接受了一些关于项目管理培训，或者阅读了一些关于项目管理的书籍，他们基本上就知道项目管理需要制定计划，需要进行跟踪和监控，也了解项目管理包含哪些容，比如说质量管理、变化管理、风险管理、合同管理等等。
但是，当他们真正在一个项目中去进行项目管理，却仍然会感到无从下手，无法通过执行项目管理的活动让项目沿着正确的方向前进。
之所以出现这样的情况，是因为他们所掌握的往往还只是项目管理的理论，但却还没有掌握项目管理的方法。
而理论的可操作性往往很弱，因此出现这样的情况也是非常正常的。
用一句话说，掌握理论只是知道了“What”，但还不知道“How”。
而方法会告诉你应该如何去做，它解决了“How”的问题，比如说，项目管理分成几个阶段？
每个阶段又包含哪些活动？
这些活动的执行顺序是什么？
这些活动之间的关系是什么？
这些活动产生哪些计划？
诸如此类等等。
这样就具有很强的可操作性。
但遗憾的是许多培训或者书本，都还是保持在理论的层次。
在日常工作中，经常会听到这样一句话“计划不如变化快”。
甚至有人会拿这句话做为挡箭牌，拒绝进行积极的项目管理。
实际上，没有一个项目可以在执行中完全遵守一开始制定的计划，尤其是在计划制定得非常详细的情况下。
项目的执行过程中肯定会随时发生各种变化的，因此在进行项目管理时，是一定要对项目进行监督和控制的，并设定一些节点根据项目的进展对项目计划进行必要的调整；另外，在制定项目计划时，还应该注意根据项目的规模和时间，从粗到细制定详细程度不同的计划，以保证计划的指导作用和有效性。
象这样的情况，都是要有方法才可以解决的。
出现问题，并不是“进（续致信网上一页容）行项目管理”的理念不对，而是没有找到合适的方法。
在日常工作中，还常听到有人说：
“以后我们要加强项目管理，使用××软件进行项目管理。
”他们不但用软件做出了计划，也产生了甘特图和关键路径图等等，但是实际的工作往往和他们所做出的计划有很大差异，项目管理成效依然甚微。
在这种情况下，他们所犯的错误通常是以为有了工具，就可以解决一切问题，而其实他们并没有项目管理方法。
实际上，工具是基于方法的，需要和方法相结合。
使用工具是为了更好的贯彻方法，如果没有相适应的方法，使用工具甚至会产生负面的效果。
因此，在具体项目实施中，一定要有清楚的项目管理方法，才可能用好工具；同时也必须注意到所选择的工具和采用的项目管理方法是相匹配的，因为并不是所有的项目管理软件都会适用于所有的项目，应该基于项目管理的特定需要选择某个项目管理软件，就象ERP系统实际上体现着某种企业管理的理念，每个企业在选择ERP时都需要密切关注隐藏在它背后的企业管理方法，而不只是它需要的技术支撑平台是什么？
它的实施需要几个人月？
2.项目管理方法和项目实施方法
其次，也必须看到，在一个项目的执行过程中还同时需要两种方法：
项目管理方法和项目实施方法。
项目管理方法是关于如何进行项目管理的方法，是可在大部分项目中应用的方法。
而项目实施方法指的是在项目实施中为完成确定的目标如某个应用软件的开发而采用的技术方法。
项目实施方法所能适用的项目围会更窄些，通常只能适用于某一类具有共同属性的项目。
而在有的企业里，常常把项目管理方法和项目实施方法结合在一起，因为他们做的项目基本是属于同一种类型的。
实际上，只要愿意，做任何一件事情，我们都可以找到相应的方法，项目实施也是一样。
以IT行业的各种项目为例，常见的IT项目按照其属性可以分成系统集成、应用软件开发和应用软件客户化等，当然，也可以把系统集成和应用软件开发再分解成一些具备不同特性的项目。
系统集成和应用软件开发的方法很显然是不一样的，比如说：
系统集成的生命周期可能会分解为了解需求、确定系统组成、签订合同、购买设备、准备环境、安装设备、调试设备、验收等阶段；而应用软件的开发可能会因为采用的方法不同而分解成不同的阶段，比如说采用传统开发方法、原型法和增量法就有所区别，传统的应用软件开发的生命周期可能分解成：
了解需求、分析需求、设计、编码、测试、发布等阶段。
至于项目管理，可以分成三个阶段：
起始阶段，执行阶段和结束阶段。
其中，起始阶段是为整个项目准备资源和制定各种计划，执行阶段是监督和指导项目的实施、完善各种计划并最终完成项目的目标，而结束阶段是对项目进行总结及各种善后工作。
那么，项目管理方法和项目实施方法的关系是什么呢？
简单的说，项目管理方法是为项目实施方法得到有效执行提供保障的。
如果站在生命周期的角度看，项目实施的生命周期则是在项目管理的起始阶段和执行阶段，至于项目实施生命周期中的阶段分布是如何对应项目管理的这两个阶段，则视不同项目实施方法而不同。
项目管理方法和项目实施方法对项目的成功都是有重要意义的，两者是相辅相成的，就如管理人员和业务技术人员对于企业经营的意义一样。
从IT企业的角度看，任何一个IT企业如果要生产高质量的软件产品或者提供高质量的服务，都应该对自身的项目业务流程进行必要的分析和总结，并逐步归纳出自己的项目管理方法及项目实施方法，其中项目实施方法尤其重要，因为大部分企业都有自己的核心业务围，其项目实施方法会比较单一，在这种情况下，项目管理方法可能会弱化，而项目实施方法会得到强化，两者会较紧密的结合在一起。
只有总结出并贯彻实施符合企业自身业务的方法，项目的成功才不会严重依赖于某个人。
在某种程度上，项目管理方法和项目实施方法也是企业文化的一部分。
从客户的角度看，如果希望得到有保障的产品或服务，那就既需要关注提供产品或服务的企业是否有恰当的项目管理方法和项目实施方法，也必须尊重该企业的方法。
3.项目管理和项目的目标
有了合适的方法，还要清楚项目的目标，才能有针对性的进行项目管理。
项目的目标是指项目做完后能够支持客户如何运作业务，或者客户可以获得具备哪些功能的产品等。
在项目的实际执行过程中，客户方和项目执行方往往很容易产生争执，出现“先君子，后小人”的情况：
开始时大家都是一团和气，或项目执行方为了获得项目合同，先是猛拍胸脯保证没问题，只要是客户方的要求就承诺一定实现。
但随着项目的进展，才发现双方的期望有着不小的难以弥补的差距。
这种现象的原因就是项目双方并没有定义清晰的、可实现的项目目标，换句话说，双方并没有真正在项目目标上达成彼此认可的一致。
这样就很可能出现不了双赢的局面，要么是最后产生的结果不是客户需要的，要么是客户不断的修改需求，导致项目的进度和质量受影响。
项目目标既是客户期望的体现，也是项目执行方期望的体现，因此它们应该是清晰的和可实现的。
从另一方面讲，项目目标的实现是要受到一定制约的，那就是它应该在确定时间和财务预算实现。
有一些目标并不是不能实现，而是实现的代价太高，或者不能满足进度的要求。
这也是在项目实施中需要注意的。
同时，清楚的目标也是界定项目是否成功的客观标准，是对项目进行验收和质量管理的重要依据。
设定清楚的项目目标，在某种程度上也会让执行项目的IT人员更清楚要做什么，因为在一些项目中，往往会出现片面追求技术的先进和完美，而忽视项目的结果是为谁服务的。
因此，为了保证项目双方能够在项目执行过程中愉快有效合作，保证项目的成功执行，双方都应该注意尽快在项目实施初期定义清楚的目标。
4.项目管理与体系结构
“体系结构”这个词语来自英文单词“Architecture”，在计算机行业中也有译为“系统结构”，许多行业都用到这个单词。
对于一台计算机而言，它所关注的是如何合理的利用合适的软件、硬件和固件来构造计算机，使之能够以最好的性能价格比完成用户所需要的任务。
之所以特别提出“体系结构”，主要有三方面的原因：
一个是IT应用围的扩大；一个是IT系统的复杂性和产品多样性；一个是软件技术的发展。
随着IT技术的发展，以及人们对IT技术的理解和掌握，IT在各行业的应用都日渐的发展和成熟，越来越多的行业和人员都在利用IT技术提高他们的业务运作效率，也就产生越来越多的应用型项目。
尤其是IT应用发展到现在，一个IT系统所覆盖的围日益扩大（围包括最终用户数量、部门数量、地理分布等），比较常见的大型IT项目是一些新用户希望在一个高起点上构建一个覆盖多个业务部门的完整的新IT系统，或者一些用户希望在原有分散的IT系统基础上进行整合，从而构建成一个完整的IT系统。
对于这样的大型项目，它们所覆盖的业务部门很多，彼此的业务功能差异比较大但又存在相当的联系，也就是说应用软件的功能会比较多，且相互之间存在着一定关联；而与之相适应的是应用软件技术也发生了变化，多层结构、对象技术和组件技术等得到日益广泛的应用，这就意味着必须对应用软件的体系结构进行全面的分析设计如层次如何划分、组件如何划分等，才有可能产生一个较完善的应用软件系统以满足最终用户的复杂需求。
同时从IT系统的基础设施来看，其使用的产品也是多种多样的，从服务器级的系统平台、网络平台到客户端等，有功能的差异，也有性能的差异，甚至还有采用异构技术实现的。
如何让这些产品构成一个和谐完整的系统为客户提供方便、快捷的服务，就需要站在整个IT系统的高度上进行完整的分析设计，定义整个IT系统的组成容，每个组成部分的功能和性能，相互之间如何进行数据交换。
如果没有清楚的体系结构观念，在项目实施中往往会出现这样的情况：
客户今天说需要这样的功能，项目人员就按照客户的要现了；客户明天再提出新的功能，项目人员也实现了。
这看起来很简单，“简单就是美”——客户也会感到很满意，可是随着项目的进展，情况就不那么美了，客户开始发现“这两个部分怎么不能连接”，进而提出要修改想法，甚至要求重新来过。
整个项目实施就可能会出现“边施工，边设计”的情况，在这种情况下，项目的进度和开销就很难有效控制，项目的资源可能被极大的浪费，而质量能否得到保证则存在很大的风险。
在体系结构清楚的基础上，项目管理人员就可以根据一定的优先次序关系组织资源去建设IT系统的各个组成部分，从而保证项目的顺利实施，而不致于出现“停工待料”甚至是“推倒重来”的局面。
因此，在一个合理的项目组织机构中，必须保证项目经理和体系结构设计师的有效配合。
5.ISO9000、CMM与项目管理
从90年代中后期开始，众多的IT企业象其它传统企业一样，开始关注国际标准组织颁布的ISO9000标准系列，并有不少企业通过了ISO9000认证。
2000年后，国大部分从事软件开发的IT企业开始和国际接轨，重视CMM认证，并有许多企业走上CMM认证之路。
这是非常好的一个现象，说明我们的观念和意识在提高，在一定程度上意味着未来更加光明。
但是也出现有的企业为认证而认证，而对于它们的客户来讲，所得到的产品或者服务并没有因为这些企业通过某项认证而得到更好的质量保证。
为什么会这样呢？
其中很重要的一点是大家并没有完全认识清楚ISO9000、CMM和项目管理、项目实施的相互关系，或者是不愿意承认这种关系。
ISO9000针对质量保证和管理，而项目管理要考核的指标包括了时间（或进度）、成本、资源和质量，它不仅有质量管理，还包含了变化管理、风险管理、合同管理等，当然这些专项管理容和质量管理是
升级会员 