通信产品需求相对稳定
通信产品的项目需求一般遵循业内通用的标准展开，相对比较稳定，或者说大的需求方向一般不会有过多的变动。另外，某企业研发的产品更具前瞻性，柱往引导者用户的购买和使用方式，而不仅仅是被动满足客户变化的需求，这种自发的需求往往更加主动和明确。所以，如果某特定用户有不同于业内通用需求的变化，一般都在原有大版本的基础上，规划到下一个附属的子版本里提供特殊处理以满足需求，而不是即刻重建大版本，也就是说当前流程并不是为拥抱变化而设计的，当开发过程中需求的变化很可能会造成项目的延误，或者拖延到下一个子版本中才发布。
通信产品的嵌入式软件复杂且代码规模巨大
一般的小型软件项目不过几十上百KLOC，而通信产品的软件代码动辄上千KLOC，而且嵌入式软件的特点就是软硬件的结合，软件代码的成功交付不仅取决于软件自身各模块间的配合，还有很多实时性和软硬件兼容配合问题的考虑。如此复杂而巨大的工程，很难自上而下地将整个项目规划为各个短期的，可实现部分独立功能的，进而逐步完善的发布。所以，按阶段开展需求、开发、测试的设计和评审工作，循序渐进地完成项目里程碑，最后毕其功于一役，发布最终包含所有功能的版本给用户的方式被一直采用。
通信产品开发的资源比较充沛
这里的资源包括时间和人力物力。客户并不喜欢延期，但事实是通信产品的发布往往伴随着不同程度的延误。所以，时间上的“充沛”一方面是指通信产品的研发过程本身就比较长，多为12个月甚至24个月。另一方面，如果不是有非常苛刻合同条款，“充沛”实际上是指业内常见的对项目延期发布的默许，而如期交付几乎都是奢望，业界的平均水平大概是15%，也就是2-4个月的延期，但这当然是值得改进的。为了保证项目进度，某企业往往会大肆增加项目人力和物力，而在用人高峰过后却又无处释放资源。另外，这种增加的人力一般是通过招聘引入的新员工，或者是为了应急而突然加入的，对项目的帮助其实还要再打一个折扣。这种自然而原始的应对方式，显然是对成本管理的漠视。但由于通信产品的研发公司的规模一般都不小，不缺钱招聘也不缺救火队员，再不行还可以加班。
缺乏改变的勇气
现有的流程各阶段任务清晰，责任明确，项目参与者也都比较熟悉和适应。
为了减少拖延的情况，项目管理者们虽然也一直在各个版本的发布过程中不断地优化流程和细节，但绝不敢贸然采用全新的开发方式，因为通信产品发布往往意味着巨额的订单，延期总比难以预期要好一些。巨大的惯性带着各个项目和项目成员遵循着传统的流程前行，尽管尽力避免，但老的问题在新的项目中仍然一次次地出现。
3. 5管理问题诊断
组织有效性的问题
参与研发项目的各部门间虽然经常一起参与讨论和评审，但一起紧密合作的机会并不多。一般是系统工程师首先完成软件规划，开发人员再进行设计和编码，测试人员再开展多轮的测试，也就是各角色分别主导和负责若干阶段，进而完成整个项目。各角色对他人负责的阶段不甚关心，也就容易造成沟通的障碍，当各角色对项目理解的不一致，对变化的更新不及时，也就无法使组织的效能最大化。
需求/开发/测试结合不紧密，往往导致在大规模测试中发现阻断性故障和海量缺陷，而由于开发变动频繁，有时甚至因为修改缺陷而生成新的阻断性的缺陷。
阶段性开展活动的问题
项目研发过程中串行的组织方式，严重限制了各部门开展不同种类工作的灵活度和积极性。即使每个阶段之间的间隔并不大，累积到项目整体上来看，整个进程还是拖沓的。而且一旦前面的环节有延期的情况出现，即使其他团队己经准备完毕，后面多个阶段也只能顺延，严重损伤团队士气，甚至会使项目成员逐渐养成被动等靠的工作习惯。
阶段间里程碑的问题
外部强加的阶段性里程碑条件，使各团队成员疲于应付，唯里程碑马首是瞻。这样的氛围下，得到更多关注的只是里程碑的形式，为了通过而通过。尽管某些交付物有量而没有质，某些数据是经过人工修饰过的，今天能通过而明天实际上是通不过的。里程碑的真正意义是用来标记过程管理的拟合度，为以后的过程优化提供改进的参考点，如果每次都顺利通过，也就掩盖了项目开发过程的弱点和缺陷，很容易使流程的改进停滞不前，更可能使同样的问题反复出现在不同的项目上。
文档管理的问题
文档驱动型的研发项目中，各种开发和测试活动均依赖于文档的正式发布。这种依赖关系，虽然从静态的视角看起来清晰且明确，但从动态的视角上看它也造成了很多负面的效应。需求和设计文档，都需要根据各种变化不断完善，这一方面增大了文档维护的工作量，另一方面也可能导致其与未修改文档间的不一致，造成“尽信书不如无书”的尴尬。在过强的依赖作用下，一旦文档发布受阻或者频繁更改，会使后续工作开展缓慢甚至停工。
综上，低效运转的组织，带来的不仅是延误的进度，沟通的不畅和不及时往往会导致误解甚至返工，哑需新型高效的组织模式。僵化的流程会一再因为某个单点问题，而造成整个项目的停滞，绕过这一点而灵活地发掘和开展其他可能活动则是更好的解决方案。不论里程碑怎样的具体而且量化，总是会被人打擦边球，那么这种非黑即白的判定准则是不是应该更模糊一些呢?研发项目中的大量静态交档，建立和维护的开销巨大，且时常延期发布，最好能使文档轻量化便于阅读和实用，且必须消除对文档过强的依赖性。
