项目计划方面(PP)
1.通过流总数来定义用例的复杂度很难准确，且发现很多时候用例本身也偏大，但又很难去拆分它为几个子用例。（项目估算）
后期对小版本采用专家法，对大版本采用功能点法估算，并进行功能点估算培训。对于基于用例估算的时候需要考虑到对于复杂用例必须要考虑拆分出扩展用例或子用例。另外基本流，扩展流的粒度和编写原则要进一步细化，现在还存在就是一条流描述了多条业务规则，或者是本来可以一条流描述的写软件需求的时候拆分为多条描述。
2.估算没有通知到测试人员参与（项目估算）
测试的工作量和软件产品本身的规模是相关的，我们知道首先需求的规模和测试用例的规模之间根据历史经验数据可以得出一个换算比例关系。所以根据软件需求规模可以得出测试规模，根据测试规模/测试生产率后可以得到测试的工作量。因此估算需要通知到测试人员，进行测试设计和测试执行工作量估算。
3.估算的新模板很多参数和指标具体含义项目成员不熟悉（项目估算）
包括COPQ,COGQ，以及评审，返工，设计开发等工作量是如何估算出来的参与估算的项目成员并不是特别清楚。很多流程和规则都固化到了Excel模板中，虽然估算的过程简单了，但是成员并没有真正了解估算的流程和原理。
4.周例会没有和项目成员共同分析和确认风险以及风险参数
周例会需要共同分析本周发生的问题，这块BA做的好，设计开发很少提问题。周例会需要共同对已有的风险进行跟踪，并识别新风险。项目需要组织专门的风险管理培训，项目管理很多时候就是对风险的管理
5.不是所有的成员都参加了项目主计划的评审获取项目承诺
个别设计开发人员没有全部参加项目主计划内部评审，项目成员不清楚总体情况。这跟项目团队的异地化开发协调也有一定关系，但是我们仍然强调所有成员都应该参加项目计划的评审，并进行承诺，这样团队成员可以将自我项目任务和团队项目目标很好的匹配。
6.项目成员不清楚项目自定义过程和作用
项目自定义过程是IPM过程域的一个重要内容，需要对其作用了解清楚。过程裁剪的方法，原则，裁剪和项目特征之间的关系等都需要有个大致的了解。不是简单的为了进度而裁剪掉过程，评审，集成测试等重要过程裁剪掉了往往项目质量和进度更加无法保障。
7.项目在一些技术方案和实现方式选择上面没有形成规范做法
CMMI三级DAR过程域强调了项目的分析和决策，如何通过DAR来指导项目识别，分析，选择技术方案需要考虑。
8.WBS分解计划阶段没有包含风险计划分解结果
项目的风险管理过程从项目一启动就已经开始，在项目计划阶段应该包括了风险的识别，风险的分析，风险的应对措施和计划等很多内容。对于最终采取的风险应对措施和计划应该有专门的WBS摘要计划和具体的风险应对任务和活动。
项目跟踪和监控方面(PMC)
1.项目周报很难体现项目总体进度
项目周报的形式需要进行改善，项目的开发模式需要更加的体现增量和迭代开发。这样跟踪的时候可以按照功能点或需求特征点进行跟踪，根据冒烟测试的情况来使项目进度真正可视。在这一块可以引入停车场图更加直观的项目进度展现方式。
2.集成测试比预期进度延后3天左右
再次强调敏捷开发中持续集成和每日构建的概念，这个版本在这里吃亏较多，持续集成的一个重要作用就是保证测试的迭代，提前发现结队任务问题，避免设计严重泄露。
3.问题分析和跟踪机制不完善
因为经常最多的就是听到这个问题解决了没有，在谁哪里，为什么这样解决，这种解决方式有问题等词语，说明整个问题解决和跟踪机制还有待改进。组织有组织级别的资产库和经验库，项目也需要有项目级的问题和经验收集管理库。
4.设计人员对开发输出的Review力度还要加强
在团队本身不稳定或团队成员新老交替的时候，应该多采用以师带徒的模式，这个时候师傅要加强代码的Review工作，通过Review代码来尽早的发展开发质量问题，发现新员工技能存在的欠缺点，后续好开展有针对性的培训。
5.项目经理不能每周准确跟踪到进度情况
还是说到设计这块，由于没有持续集成，每周功能点也没有集成到151上来，项目经理这块很难确切跟踪到准确进度情况，所以这块建立在对设计完全信任上。
6.架构如何跟踪设计是否按照架构思路执行问题
如何保证设计和架构的一致性？这块架构要考虑下，后期如何加强控制。这也是我们IT项目管理中强调概念完整性的一个重要内容，首先需求本身不能出现偏差，其次架构和总体设计和需求匹配，设计的思路要能够严格贯彻执行。
7.任务承诺和执行的问题
PMS任务周四提出可以延后两天，周五提出需要延期的只能延后一天。但任务延期必须有明确的原因。项目经理口头或邮件的非PMS任务请大家一定注意，你承诺了在某个时间点能够搞定的要确保在时间点搞定。
验证和确认相关(VER&VAL)
1.测试人员的测试用例模板存在问题
测试一个重要环节是分支分析和测试数据的准备，这块还要考虑后续改进方法。
2.测试人员对业务的理解程度问题
这块对测试业务培训较少，测试对业务理解深度还要加强，测试有需求要尽早提出来，项目组这边会多安排BA给测试进行培训
3.测试用例本身的质量问题
测试用例本身的质量涉及到两方面的内容，一个是测试用例的编写方法，一个是测试人员对业务的理解程度。测试用例要能够全面覆盖到软件需求的内容，包括非功能性方面的软件需求。测试用例一定要能够很好的体现流程，体现数据准备，体现数据在流程中处理完成后我们分析出的期望结果。测试数据，输入，期望输出必不可少。
4.通过评审的效果和质量问题
对于需求和架构的同行评审效果较好，能够发现大部分问题。但对于设计和编码的同行评审后期进度紧张，进行的不是特别好，评审的时间点也较后，很难提前发现设计和编码问题。同时我们看到在需求和设计阶段，我们评审重点都在功能性需求上面，对于系统的易用性，可扩展性，性能等方面的非功能性需求考虑较少。