其主要原因是一些新任的项目经理是由程序员提拔起来的，不太熟悉软件工程各阶段工作职责中某些具体工作的分配，无法按任务分清每个人的责任。如应该分清楚需求人员该做什么、设计人员该做什么、编码人员该做什么、测试人员该做什么。责任似乎很容易分清，但大家却经常听到“这是需求的事”、“这是设计的事”这样的争论，严重的造成项目组内部的纠纷扯皮。就是因为这些新的项目经理对一项具体工作，如界面设计、数据规格等应该由需求分析人员来做，还是设计人员来做分不清楚，还有就是做到什么程度算概要设计，什么程度算详细设计，职责上也要搞清楚。建议新上任的项目经理应该多学习软件工程的相关知识。
6、项目任务分工或进度计划表的颗粒度太大
常见的现象有对任务持续时间进行不切实际的估计；或未考虑到任务的相互依赖关系而造成遗漏工作。其主要原因是软件工程的分析与设计经验的不足，无法细化系统需求，并从需求推导出设计，根据设计去分配任务。根据细化的需求也可以分配任务，但是由于需求中的功能点和设计中的模块往往不是一一对应的，如一个需求功能点需要一系列的模块来实现，多个需求功能点也可以共用同一组模块加上不同的设置参数来实现。所以根据设计来确定程序代码阶段的任务分配比较合理。需求是整个项目的基础、需求的清晰颗粒度对后面的工作及工作计划的准确性至关重要。项目计划的准确度是以一开始以需求（包括设计层需求）为基础得出的工作结构分解的完整性、清晰性为基础的。如果没有这个基础，项目计划就不可能做得很准确。在无法准确制定项目计划的情况下，对其风险要足够重视，并制定出具体可行的对策。如果对整体的需求或工作结构分解无法一次完整的清晰，就应当把它先分解为几个大块，分块进行，已经清晰的先制定本块（阶段）计划，下一环节的工作也可以开始（分块）进行。再项目开始阶段往往还没有得到详细的需求成果，因此根据项目计划渐进明晰的特点，在需求调研分析阶段过后，需求成果清晰是，应当及时细化项目计划，在概要设计完成时，要更进一步地细化后面编码测试阶段的详细计划。
7、与上一种情况相反的是计划表的颗粒度太细
就是说软件开发的工作虽然可以被划分为若干阶段，但是这些阶段不应该是整齐划一的。虽然每个环节阶段成果是下一环节阶段成果的基础，但即使在阶段成果通过评审之后下一环节对上一环节也应当随时进行检查验证，上一环节根据下一环节的验证检查情况进行调整。在上一环节没有得出可以供下一环节开展工作的基本成果时，下一阶段的投入可能是浪费时间。“按任务分清每个人的责任”并不是说上一环节的人员在初次完成本环节后交给下一环节就了事了，而应该继续与下一环节的人员共同作战、相互影响、不断进行同步完善，及时地解释和调整上一阶段的成果。如果上一阶段与下一阶段的负责人是同一个人，就没有这方面的问题，但是在实际工作汇报时要考虑到在某个阶段可能进行着前一个阶段或后一个阶段的工作。
8、资源需求没有经过较为周密的估算
软件开发项目的资源因为因为其自身的特点和受到各种因素的影响，很难做到“精确”。尽管如此，还是应该尽可能地做到“周密”。需要重点考虑的软件开发项目的资源主要是人力资源，没有尽可能足够详细精确地估计整个项目的每个阶段所需要的人时（或人日、人月）数；这是因为对软件开发的工作量没有进行精确的估算。为了估算软件开发项目的工作量和完成期限，首先需要根据较为完整的需求来预测软件规模。度量软件规模的常用方法有、代码行估算法和功能点估算法。这两种方法各有优缺点，应该根据软件项目的特点选择适用的软件规模度量方法。根据项目的规模可以估算出完成项目所需的工作量，我们可以使用一种或