大型项目管理论文
随着城市化进程的不断加快,越来越多的建设工程项目日趋复杂,体量逐渐庞大,投资不断加大;而且项目与项目间的制约关系越来越突显。下面是学习啦小编为大家整理的大型项目管理论文，供大家参考。
大型项目管理论文范文一：浅谈系统集成项目的进度管理
【摘要】本文以本人管理的某大型医院检验样品管理系统的开发、实施为实例，探讨了信息系统项目的进度管理，总结了该项目进度管理中运用的基本原则和相关具体措施。结合项目实际情况指出，做好项目管理要有扎实深厚的项目管理理论基础，要能结合项目实际情况灵活运用这些理论知识，要站在项目整体的角度去看待和实施项目的进度管理。
文中，从项目各阶段总体规划原则、工作结构分解策略、计划安排、任务分配与跟踪、实际进度数据分析以及项目管理其他方面对进度管理的影响与作用等方面，根据自身经验教训和项目实际情况进行总结和阐述。
【正文】
2010年，某大型医院为加强检验样品(病人化验的血样、尿样等检测样品)的管理，招标一套检验样品管理系统。我公司中标后指派我为项目经理，负责该项目的开发与实施。
这套系统包含了检验样品射频标签匹配、识别与跟踪，检验项目分组与信息确认，检验数据的传递与存储，检验报告的编制与审批、打印等主要环节，同时还需要与医院现有的HIS(医院信息管理系统)进行接口连接。由于医院规模比较大，布点多，从设计开发到现场施工工程量都是比较大的。另外，虽然射频识别(RFID)技术本身已经比较成熟，但对于我们团队来说还没有足够的相关经验，而且由于各种原因留给我们总共的时间只有6个多月。任务重、时间紧，在保证质量的前提下，项目进度控制无疑是该项目的重中之重。
面对项目的实际情况，我灵活运用所学的项目管理知识，采取相应措施，在合同要求的工期内比较圆满的完成了该项目，目前该项目运行稳定，客户非常满意。我主要采取了以下的具体措施。
第一，总体上合理规划各个环节的时间安排和工时投入，适当加大调研、需求、概要设计以及测试阶段的工时投入，控制开发实现以及安装实施阶段的工时投入。
对于时间紧急的项目，我们的惯性思维往往要求我们急于开展开发、编码等所谓的“实质”工作，而不由自主的缩减调研、需求、概要设计以及测试等所谓“虚”的环节。但这样往往适得其反，也不符合项目管理的客观规律。如果调研不足，可能导致开发过程中出现意想不到的技术问题;如果需求与客户没有足够的沟通并明确，可能导致重大功能模块的调整;如果概要设计做得不充分，可能导致系统架构级的问题;如果测试不充分，更可能导致施工调试过程中的巨大反复。而如果没有充分的前期投入，所有这些问题在其产生的阶段都是隐匿的，在后续阶段才会逐步显露出来，而问题一旦出现，其影响和问题已经严重扩散，后续的补救工作至少需要花费几倍甚至十几倍的时间和成本来弥补，严重时这无疑将导致项目进度的失控。对于像该项目这样时间要求紧迫的项目来说，是容不得出现较大的反复的，严重时可能将导致项目的彻底失败。
与之相对的，开发实现阶段虽然是项目的实质主体，也是我们经验最丰富也最擅长的部分，在解决了关键的技术障碍之后其实是最容易控制的部分。同时，前面各阶段，尤其是测试足够充分的话安装实施自然就会比较顺利。
从效果看，这个策略很好的保证了项目的整体进度，各阶段进展都相对比较顺利。 第二，对于影响项目进度的任何不确性因素，务必第一时间、第一优先级解决处理。 在工作结构分解与安排上，对于此类问题不能按部就班的进行排序安排，务必尽可能向前安排，向高优先级安排。因为对我们不确定不熟悉的各项因素有可能很容易解决，更有可能称为棘手的障碍，我们识别发现的越早，我们的主动性就越强，留给我们的反应和处理时间也就越多，从而便于我们调整和控制项目的进度。而这些问题一旦在项目的中后段才得以发现，对项目的影响很可能是颠覆性的。
在该项目中我们对于医院业务不熟悉，对于RFID技术没有足够经验，不确定在采购成品的基础上是否需要二次开发等。因此，除了如上面所说的提前和加大需求、调研阶段的投入外，在完成对RFID的调研之后立即安排硬件测试工作，排除和确认我们所不熟悉的技术问题和障碍，而不是安排在软件开发完成之后进行统一测试。而事实也证明，我们调研后预选的方案和供应商虽然从书面的性能参数等方面完全符合要求，但实际测试中漏读率还是达不到我们的要求。而由于我们提前测试，发现问题时我们总体需求分析阶段还没结束，也因此我们有足够的时间重新选型采购，从而基本没有对项目进度造成明显影响。
第三，计划安排要有一定的弹性，有一定的调整和控制余量。
除了首先确定好串行进行的关键路径任务外，要充分灵活安排与其他任务关联度不强的工作任务(我称之为“游离任务”)，计划中给予此类任务足够的“游离”空间，使其能在关键任务提前完成，或关键人力资源有空余时可以穿插安排，以充分利用人力资源;而在关键任务一旦延期或关键人力资源紧张时可以适当调整其时间安排，以释放部分人力资源，保证关键路径的进度和人力资源的充分利用。
第四，利用相关工具软件(如PROJECE等)，定期(如一周)关注项目进展相关数据，关注项目进度趋势，提前预判并决定是否及如何干预。
比如，项目延期可能不大并完全在可接受范围内，但连续两周在扩大，就需要加强关注，分析原因提前采取措施，以免失控。当然，俗话说“计划不如变化快”，任何计划在实施过程中都不可能完全依照计划进行，必然会出现不同程度的偏离。但是否是偏离就一定要干预一定要纠正呢，当然不是。因此要分析对计划的偏离是否可控，呈现何种趋势。在可控范围内就没有必要过多干预，以免过度管理降低工作效率和造成时间浪费。因此干预调整的程度需要把握在一个合适的火候，除了经验之外，很重要的就是多利用工具软件提供的相关数据，进行分析和判断，找出趋势和原因。
第五，对工作结构的分解粒度要适中，不能过大也不能过小，过大不易控制，过小容易产生过渡管理降低效率。
对于该项目我基本掌握在工期在一周左右，以最大不大于两周，最小不小于3个工作日为原则进行分解。项目组一共6人，在这个规模上，实际的经验告诉我这个粒度时相对比较合适的，可以保证比较有效的跟踪管理，同时我还可以有一定的时间负担一些技术工作。
第六，工作任务按工作结构分解情况以任务单的形式安排跟踪，任务单下发到具体组员，避免将同一执行人的多个任务打包安排。
我在项目中坚持按上述工作结构分解后的任务进行单任务的分配跟踪，而不是几个相关任务打包安排、跟踪。因为如果将同一执行人的几个任务打包安排，看似节约时间，但实际经验告诉我，这样很容易造成这些任务与其相关联任务(尤其是与别人关联的任务)的不同程度的脱节。因为作为同一执行人在执行几个任务时重点考虑的时保证这一包任务的总体完成情况，会忽视单个任务的时间进度要求。而项目总体控制要求任务之间的关联关系，尽管这种关联关系的脱节不会很严重，但会比较普遍。而且这些任务有超前有延后，从总体上不容易发现问题。但正是由于任务关联脱节的比较普遍，经过一定时间的积累很容易产生影响项目整体进度的大问题，而当问题比较明显时，往往已经很难调整和控制了。
第七，上述任务安排基础上，除安排需要执行的任务外，还要预先安排下一项工作任务。 这和上面的论述是否矛盾呢?不是的。这里的预安排只是告知执行人下一个要执行的任务是什么，而不进行实质安排，这样做的目的主要有两个，首先是执行人可以预先在脑子里构思下一个任务(主要是潜在的，不由自主的)，待实际执行时会提高效率或提前识别发现问题;其次是一旦由于工作冲突或其他原因工作未能及时安排时，执行人完成当前任务就可以执行下一个任务，避免人等任务的情况出现。
第八，项目中采取早会、周例会结合的例行沟通模式，强调及时沟通、快速反应。 我们每天利用早晨10分钟左右时间，项目组互相通报一下前一天的工作情况和问题。目的是及时掌握项目进展动态和问题，以便及时采取措施提高项目组反应的敏捷度。但早会上主要是沟通和识别问题，不对具体问题做展开讨论，如有需要再专题安排。周例会主要分析项目进展的重大问题和进展趋势，讨论和决策相关措施。但要注意引导避免早会、例会形成形式主义，尤其是例会在项目进展顺利时可以缩短时间或隔周召开。
第九，项目管理是一个整体，要做好项目的进度管理必须有其他方面的相辅相成。 比如上面提到了的关于沟通管理、人力资源管理等方面的措施。此外，比如质量管理也是有效保证进度的重要一环，尤其是在产品实现方面的质量管理工作，毕竟不出问题不返工才是最节约时间最有效率的。我们项目益于我公司多年贯彻执行ISO9000标准和CMM5级的软件成熟模型，给予我们强有力的保障。再比如，变更管理也是影响进度的很重要部分，项目执行过程中通常都会有各种各样的变更，如何在受控的前提下快捷又有效的进行变更是提高效率的必要手段。在该项目中，我根据变更的类型、涉众等对项目的变更分成不同的级别，采取不同的控制、管理及审批措施和程序，在保证变更合理受控的前提下有效地提高了变更效率降低了变更带来的负面影响。
在这些措施及项目组成员的团队配合及共同努力下，我们按时保质保量的完成了项目，赢得了客户的赞誉，目前该系统运行稳定，反馈良好。
总之，要做好项目的进度管理首先要有扎实的项目管理知识和经验，在此基础上要充分从基础理论出发结合项目的实际情况进行灵活变通的应用，制定和采取具体的措施来控制项目的进度，不能生搬硬套，毕竟项目管理理论是高度总结和抽象化的东西，不是万能公式。另外，要做好项目的进度管理一定要站在项目整体的角度去考虑问题，项目管理是一个整体的系统工程，各个领域和方面都是相辅相成的，不能独立存在，需要相互协调与配合。
大型项目管理论文范文二：软件项目管理综述
一.引言
随着计算机技术的飞速发展，软件产品的规模越来越庞大，个人单打独斗的开发模式已经越来越不能适应实际的需要。因此各软件企业在软件开发活动中纷纷引入软件项目管理相关技术，使得开发过程得到有效的实行与管理。以现今中国的百度，腾讯，阿里巴巴等软件公司为例，在这些公司中针对大型项目开发时都实行了项目管理制度，并把软件项目管理作为整个项目管理中的一个重要组成部分。从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展(即减小开发风险)。软件开发不同于其他产品的制造，软件的整个过程都是设计过程(没有制造过程);另外，软件开发不需要使用大量的物质资源，而主要是人力资源;并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。基于上述特点，软件项目管理与其他项目管理相比，有很大的特殊性。
二.什么是软件项目管理
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。
软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期(从分析、设计、编码到测试、维护全过程)都能在管理者的控制之下，以预定成本按期，按质的完成软件交付用户使用。而研究软件项目管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则，方法，同时避免前人的失误。
软件项目管理的概念是在20世纪70年代中期由美国提出的，当时美国国防部专门研究了软件开发不能按时提交，预算超支和质量达不到用户要求的原因，结果发现70%的项目是因为管理不善引起的，而非技术原因。于是软件开发者开始逐渐重视起软件开发中的各项管理。到了20世纪90年代中期，软件研发项目管理不善的问题仍然存在。据美国软件工程实施现状的调查，软件研发的情况仍然很难预测，大约只有10%的项目能够在预定的费用和进度下交付。
1995年，据统计，美国共取消了810亿美元的商业软件项目，其中31%的项目未做完就被取消，53%的软件项目进度通常要延长50%的时间，只有9%的软件项目能够及时交付并且费用也控制在预算之内。
软件项目管理和其他的项目管理相比有其自有的特殊性。首先，软件是纯知识型产品，不同于实际工程，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。Windows这样的操作系统有1500万行以上的代码，同时有数千个程序员在进行开发，项目经理都有上百个。这样庞大的系统如果没有很好的管理，其软件质量是难以想象的。
软件项目管理的内容主要包括如下几个方面：人员的组织与管理，软件度量，软件项目计划，风险管理，软件质量保证，软件过程能力评估，软件配置管理等。这几个方面都是贯穿、交织于整个软件开发过程中的，其中人员的组织与管理把注意力集中在项目组人员的构成、优化;软件度量把关注用量化的方法评测软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值，包括过程度量和产品度量两个方面;软件项目计划主要包括工作量、成本、开发时间的估计，并根据估计值制定和调整项目组的工作;风险管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防;质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划，有组织的活动;软件过程能力评估是对软件开发能力的高低进行衡量;软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略。因为大家对人力资源管理和软件过程能力比较有兴趣，下面就详细的对这两方面展开讨论。
三、软件项目管理的组织模式
软件项目可以是一个单独的开发项目，也可以与产品项目组成一个完整的软件产品项目。如果是订单开发，则成立软件项目组即可;如果是产品开发，需成立软件项目组和产品项目(负责市场调研和销售)，组成软件产品项目组。公司实行项目管理时，首先要成立项目管理委员会，项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。 3.1、项目管理委员会项目管理委员会是公司项目管理的最高决策机构，一般由公司总经理、副总经理组成。主要职责如下：(1)依照项目管理相关制度管理项目;(2)监督项目管理相关制度的执行;
(3)对项目立项、项目撤消进行决策;(4)任命项目管理小组组长、项目评审委员会主任、项目组组长. 3.2、项目管理小组项目管理小组对项目管理委员会负责，一般由公司管理人员组成。主要职责如下：(1)草拟项目管理的各项制度;(2)组织项目阶段评审;(3)保存项目过程中的相关文件和数据;(4)为优化项目管理提出建议。 3.3、项目评审小组项目评审小组对项目管理委员会负责，可下设开发评审小组和产品评审小组，一般由公司技术专家和市场专家组成。主要职责如下：(1)对项目可行性报告进行评审;(2)对市场计划和阶段报告进行评审;(3)对开发计划和阶段报告进行评审;(4)项目结束时，对项目总结报告进行评审。 3.4、软件产品项目组软件产品项目组对项目管理委员会负责，可下设软件项目组和产品项目组。软件项目组和产品项目组分别设开发经理和产品经理。成员一般由公司技术人员和市场人员构成。主要职责是：根据项目管理委员会的安排具体负责项目的软件开发和市场调研及销售工作。
四、软件项目管理的内容
从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发，还是团队协作开发，这六个阶段都是不可缺少的。根据公司实际情况，公司在进行软件项目管理时，重点将软件配置管理、项目跟踪和控制管理、软件风险管理及项目策划活动管理四方面内容导入软件开发的整个阶段。在20世纪80年代初，著名软件工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则，同样，在进行软件项目管理时，也应该遵循这七条原则。它们是：
(1)用分阶段的生命周期计划严格管理;
(2)坚持进行阶段评审;
(3)实行严格的产品控制;
(4)采用现代程序设计技术;
(5)结果应能够清楚地审查;
(6)开发小组地人员应该少而精;
(7)承认不断改进软件工程实践的必要性。
五、编写《软件项目计划书》
项目组成立的第一件事是编写《软件项目计划书》，在计划书中描述开发日程安排、资源需求、项目管理等各项情况的大体内容。计划书主要向公司各相关人员发放，使他们大体了解该软件项目的情况。对于计划书的每个内容，都应有相应具体实施手册，这些手册是供项目组相关成员使用的。
六、软件配置管理
软件根据规模来决定是否进行配置管理，软件的规模越大，配置管理就越重要。软件配置管理简称SCM(Software Configuration Management的缩写)，是在团队开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。
6.1、目前软件开发中面临的问题:在有限的时间、资金内，要满足不断增长的软件产品质量要求;开发的环境日益复杂，代码共享日益困难，需跨越的平台增多;程序的规模越来越大;软件的重用性需要提高;软件的维护越来越困难。
6.2、软件配置管理应提供的功能:
在ISO9000.3中，对配置管理系统的功能作了如下描述：唯一地标识每个软件项的版本;标识共同构成一完整产品的特定版本的每一软件项的版本;控制由两个或多个独立工作的人员同时对一给定软件项的更新;控制由两个或多个独立工作的人员同时对一给定软件项的更新;按要求在一个或多个位置对复杂产品的更新进行协调;标识并跟踪所有的措施和更改;这些措施和更改是在从开始直到放行期间，由于更改请求或问题引起的。
6.3、版本管理软件配置管理分为版本管理、问题跟踪和建立管理三个部分，其中版本管理是基础。版本管理应完成以下主要任务：
建立项目;
重构任何修订版的某一项或某一文件;
利用加锁技术防止覆盖;•当增加一个修订版时要求输入变更描述; •提供比较任意两个修订版的使用工具;
采用增量存储方式;
提供对修订版历史和锁定状态的报告功能;
提供归并功能;
允许在任何时候重构任何版本;
权限的设置;
晋升模型的建立;
提供各种报告。
七.人员组织与管理
软件开发人员对软件来说是最大的资源。软件整个过程中对人员的配置、调度安排至关重要，人员的组织管理是否得当，将决定软件项目质量的好坏。 首先在软件开发的一开始，要合理的配置人员，根据项目的工作量、所需要的专业技能，再参考各个人员的能力、性格、经验，组织一个高效、和谐的开发小组。一般来说，一个开发小组人数在5到10人之间最为合适，如果项目规模很大，可以采取层级式结构，配置若干个这样的开发小组。
在选择人员的问题上，要结合实际情况来决定是否选入一个开发组员。并不是一群高水平的程序员在一起就一定可以组成一个成功的小组。作为考察标准，技术水平、与本项目相关的技能和开发经验、以及团队工作能力都是很重要的因素。一个一天能写一万行代码但却不能与同事沟通融洽的程序员，未必适合一个对组员之间通讯要求很高的项目。还应该考虑分工的需要，合理配置各个专项的人员比例。例如一个网站开发项目，小组中有页面美工、后台服务程序、数据库几个部分，应该合理的组织各项工作的人员配比。对于一个中型农技110网站，对数据采集量要求较高，一个人员配比方案可以是2个美工、2个后台服务程序编写、3个数据采集整理人员。
在决定一个开发组的开发人员数量时，除了考虑候选人素质以外，还要综合考虑项目规模、工期、预算、开发环境等因素的影响，下面是一个基于规模、工期和开发环境的人员数量计算公式：
L=Ck*K1/3*td4/3
L:开发规模，以代码行LOC为度量td:开发时间K：人员数
Ck：技术常数表示开发环境的优劣
取值2000：表示开发环境差，没有系统的开发方法，缺乏文档规范化设计; 取值8000：表示开发环境较好;
取值11000：表示开发环境优。
在组建开发组时，还应充分估计到开发过程中的人员风险。由于工作环境、待遇、工作强度、公司的整体工作安排和其他无法预知的因素，一个项目尤其是开发周期较长的项目几乎无可避免的要面临人员的流入流出。如果不在项目初期对可能出现的人员风险进行充分的估计，作必要的准备，一旦风险转化为现实，将有可能给整个项目开发造成巨大的损失。以较低的代价进行及早的预防是降低这种人员风险的基本策略。具体来说可以从以下几个方面对人员风险进行控制： a.保证开发组中全职人员的比例，且项目核心部分的工作应该尽量由全职人员来担任， 以减少兼职人员对项目组人员不稳定性的影响。
b.建立良好的文档管理机制，包扩项目组进度文档、个人进度文档、版本控制文档、整体技术文档、个人技术文档、源代码管理等。一旦出现人员的变动，比如某个组员因病退出，替补的组员能够根据完整的文档尽早接手工作。 c.加强项目组内技术交流，比如定期开技术交流会，或根据组内分工建立项目组内部的开发小组，是开发小组内的成员能够相互熟悉对方的工作和进度，能够在必要的时候替对方工作。
d.对于项目经理，可以从一开始就指派一个副经理在项目中协同项目经理管理项目开发工作，如果项目经理退出开发组，副经理可以很快接手。但是只建议在项目经理这样的高度重要的岗位采用这种冗余复制的策略来预防人员风险，否则将大大增加项目成本。
e.为项目开发提供尽可能好的开发环境，包括工作环境、待遇、工作进度安排等等，同 时一个优秀的项目经理应该能够在项目组内营造一种良好的人际关系和工作氛围。良好的开发环境对于稳定项目组人员以及提高生产效率都有不可忽视的作用。
八.软件过程能力评估
软件过程能力描述了一个开发组织开发软件开发高质量软件产品的能力。现行的国际标准主要有两个：ISO9000.3和CMM。
ISO9000.3是ISO9000质量体系认证中关于计算机软件质量管理和质量保证标准部分。它从管理职责、质量体系、合同评审、设计控制、文件和资料控制、采购、顾客提供产品的控制、产品标识和可追溯性、过程控制、检验和试验、检验/测量和试验设备的控制、检验和试验状态、不合格品的控制、纠正和预防措施、搬运/贮存/包装/防护和交付、质量记录的控制、内部质量审核、培训、服务、统计系统等二十个方面对软件质量进行了要求。
CMM(能力成熟度模型)是美国卡纳基梅隆大学软件工程研究所(CMU/SEI)于1987年提出的评估和指导软件研发项目管理的一系列方法，用5个不断进化的层次来描述软件过程能力。现在CMM是2.0版本。
ISO9000和CMM的共同点是二者都强调了软件产品的质量。所不同的是，ISO9000强调的是衡量的准则，但没有告诉软件开发人员如何达到好的目标，如何避免差错。CMM则提供了一整套完善的软件研发项目管理的方法。它可告诉软件开发组织，如果要在原有的水平上提高一个等级，应该关注哪些问题，而这正是改进软件过程的工作。
CMM描述了五个级别的软件过程成熟度(初始级，可重复级，已定义级，已定量管理级，优化级)，成熟度反映了软件过程能力的大小。
初始级特点是软件机构缺乏对软件过程的有效管理，软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，其软件项目的成功来源于偶尔的个人英雄主义而非群体行为，因此它不是可重复的;可重复级的特点是软件机构的项目计划和跟踪稳定，项目过程可控，项目的成功是可重复的;已定义级的特点在于软件过程已被提升成标准化过程，从而更加具有稳定性、可重复性和可控性;已定量管理级的软件机构中软件过程和软件产品都有定量的目标，并被定量地管理，因而其软件过程能力是可预测的，其生产的软件产品是高质量的;优化级的特点是过程的量化反馈和先进的新思想、新技术促进过程不断改进，技术和过程的改进改进被作为常规的业务活动加以计划和管理。
CMM是科学评价一个软件企业开发能力的标准，但要达到较高的级别也非常困难，根据1995年美国所做的软件产业成熟度的调查，在美国的软件产业中，CMM成熟度等级为初始级的竟占70%，为可重复级的占15%，为定义级的所占比例小于10%，为管理级的所占比例小于5%，为优化级的所占比例小于l%。而国内企业的水平就更加堪优，到目前为止，只有东软一家达到优化级，少数几家能够达到可定义级。尽快改变这种局面，科学化、规范化、高效的进行软件开发活动，从整体提高我国软件行业的水平，是国内软件企业的当务之急，也是专业人员应该为自己制定的目标。如果有一天也能指挥一个数千人的庞大开发队伍，操作Windows这样巨型规模的软件项目，并生产出高质量的产品，才有理由宣称自己的软件项目管理能力达到了一个“自主自足”的水平。
大型项目管理论文相关文章：
2.关于项目管理论文
5.浅谈工程管理论文
