有些朋友会说：现在中国IT技术人员普遍有种浮躁和易动的心态，一个成熟的项目经理和他所熟悉的，相对成熟的项目团队几乎不存在，人员总在变动，你所说的灵活的项目管理不可能实现，更不用谈内部、外部不确定因素这些具体的东西了。由此话题引出了成熟的项目组织的重要性。
一个行业软件开发供应商如果想在行业中有些名气，必须在时间上存在足够长，行业背景要有一定程度上的认可度，成功案例要有一定的数量。在攒够这些资本的过程中，企业逐步完成它对于行业软件领域中业务、技术和人员的原始积累，企业由此走向成熟。
我见过一些国内软件企业，在成长的过程中没有实现这些方面的积累，在企业发展到一定规模之后，这些问题凸现出来，有些在短短数月间骤然间消失，有些分崩瓦解到一定程度后稳定下来，艰难的等待第二次辉煌。
这些软件企业成熟度和内外部不确定因素有什么关系呢？很多人看到这里已经想到，越成熟的企业，项目的内部不确定因素和部分外部不确定因素的风险性越小，因为它已经经历了足够的错误和痛苦，将足够多的不确定因素和不知道因素所造成的风险减小到了很小。
现在谈谈外部不确定因素，外部不确定因素在很大程度上是不受项目经理所控制的，前面所举的外部不确定因素的例子是少数可被控制的因素。将工作重点从项目本身转移到控制外部不确定因素是项目经理成功运用灵活的项目管理的必要手段。
实际上，客户清楚什么是竞争，不像内部不确定因素，外部不确定因素更多的取决于行业的成熟度，在中国，各个行业都在快速的发展过程中，不论是电信，还是银行，或者是互联网，拿电信行业来说，GSM正在逐步退出历史舞台，联通2003年推出CDMA，中国移动也推出相应的3G产品体系，而4G的研究也正在进行中；处于这样的竞争条件下的项目，对WCDMA、cdma2000和TD-SCDMA三种主流的3G技术标准的取舍，时间上的紧急性，技术的复杂性等方面都提出了很高的要求。这个时候，标准项目管理在很多方面会遇到很多困难，越来越多的不确定因素将标准项目管理方法的界限从不同的角度延伸，从某一点上开始，你必须找到新的方法去管理你的项目，可能这些方法还没有被前人使用过。
项目计划
计划通常是痛苦的，耗时的，对于需求频繁变化的项目来说是没有价值的；在标准项目管理过程中计划是重要的，没有计划项目经理和项目组将丧失方向和感觉，而对于灵活的项目管理中计划也是重要的，但如何计划才能将计划变成有价值的呢？
对于中小型商业银行的金融项目来说，项目的每一分，每一秒都是重要的，项目是否能多快好省的完成决定了商业银行当年在当地市场的竞争地位，市场变化飞速，如果项目不能及时完成，一步赶不上，步步赶不上。所以商业银行对于项目的期望和要求都很高。
当项目组遵循标准项目管理流程进行项目计划时，客户会说：“我们需要项目尽快完成，不然我们将不能够完成今年的利润目标，并且工商银行在一个月后推行这几项业务了，我们要在他们之前完成，你们的老总和销售都向我保证过，可以在此前完成。所以不管如何做，你们现在开始写程序吧” 或 “你们已经做过此类型项目，你们应该知道怎么做，计划只会拖延时间，所以快点开始”。
在种种条件迫使下，项目组不得不在极短的时间内产生行之有效的项目计划后进入开发。甚至没有时间做详细的需求。我们不得不面对这样一个矛盾，一方面，需求频繁的变化导致计划纯属浪费时间，而另一个方面，我们必须做计划。
标准项目管理流程的计划包括大大小小十几二十个计划，从工作列表、甘特图到时间安排、人员选择，成本分析等等方面。我本人不想否定这些计划的制定，这些计划确实能够有效的对项目进行规划和控制，将风险降到小，成功率升到大。举例来说：一个商业银行整体解决方案的项目，经过和客户的反复讨论，综合业务系统在保证其原本业务功能的基础上，同时对客户现有系统（如CRM，行长决策，OA，管理系统等）、信贷管理系统和国际业务（包括现有和未来需要的业务功能）提供端口和数据源，将综合业务系统进行必要的改动和优化，对种种情况进行周全的考虑，然后制定一套完整的计划和方案，再进入实施。这样当然好，但在现实中国社会中，有什么样的银行允许你这么做？
项目活动和成绩
标准的项目管理流程是以项目活动为基础的，也是说项目按照要做多少事，先做哪件，后做哪件来决定的；当关键的项目活动确定后，资源得以分配，工作量和时间得以估算，次序也相应排列出来了。标准项目管理通常使用以以前做过的项目所总结出来的通用模版来完成初期的项目计划。
而灵活的项目管理中，计划的制定是通过确定要完成的目标和里程碑，但不具体到详细的任务。新科技或需求不断变化的项目中的项目经理清楚要达到的目标和一定要按时完成的里程碑，他所不清楚地是非常准确的任务，所以在此情况下，制定一个在任务列表的基础上的完整而详尽的项目计划不切实际了。如果要这样做，只会起到反效果。这大概是灵活的项目管理和标准项目管理之间微妙而关键的不同。
在灵活的项目管理中，通常有多种方法推进项目并解决项目中出现的问题，项目经理不能以机械的方法按照标准项目管理的方法来实施项目。而有丰富经验的项目组成员也经常对不了解项目性质的项目管理层有抵触。他们不喜欢对不确定的业务功能和系统功能作出承诺，因为他们知道这些需求会改变或正在改变中。可是，他们会对确定要按时完成的里程碑作出承诺，如果项目经理对他们如何做不太多进行干涉。
项目估算和承诺
在此类项目中，项目估算的关键点是相信项目组成员的承诺，而不是从上至下WBS的估算，只要能够实现系统层面上对于客户业务上的运作畅通，换一句话说：是将客户商业运作上的要求在系统中实现，设身处地的在业务层面上为客户着想。
这要求项目组和客户不得不在整体上进行考虑，然后在细节方面逐步实现需求。在中国软件开发项目中很常见的一个现象是客户和项目组的考虑重点不同，导致误差和困扰。如果项目组和客户在同一个思路上思考，项目的难度会减小很多。这样在计划阶段双方很容易达到共识，而富有技术和业务经验的项目组成员可以更好的发挥他们的优势而达到双赢。
你，作为项目经理可以把重点放在你的优势上，协调、沟通、整合系统，保持它的完整性。
当然，基于此基础上制定计划和进度安排不是个容易的事情，因为系统中的各部分有着千丝万缕的联系，而一个大集成系统中的各系统之间也是相互依靠的。所以所有项目组需要有效的共同工作。
出于这些原因，项目计划的网络图比甘特图在计划中更加有效，更能够展现项目中可实现目标的途径