为了解决这个问题，相关的软件部门成立了一个6sigma项目，抽专人寻找原因。在大家的协同工作下，一周之后，就将同步时间降为1.5分钟。这是个不对原有系统伤筋动骨的最好结果，如果希望进一步减少同步时间，只有调整系统架构。由此引发的风险和成本太大，在经过项目组和6sigma黑带的权衡后，同意此项目到此成功结束。
这是个成功地应用DMAIC来解决问题的软件项目，从中体现了6sigma的几个主题：对客户的真正关注；由数据和事实驱动的管理；跨越组织的无界限合作；对完美的渴望。
在这个案例中，没有CMM的介入，单纯利用6sigma的方法解决了软件的问题。有人会讲：“这只是证明了6sigma确实可以应用于软件行业，但是我们的软件行业已经有了CMM，也能取得成功，又何必花费这么多资源推广6sigma呢？”
我们另外举一个案例，网络管理系统项目组发现，一年以来系统发布的时间总是推迟，而这个项目已经实施CMM一年有余，而且其实施方法中关于高效召开CCB会议还受到了表扬，其他的同行评审、设计先行等都是做得比较好的。那么问题出在哪里呢？在成立了一个绿带项目之后，统计一年以来的计划数据和测试故障数据发现，每当设备系统升级，从而引发的网元管理模块升级，与系统平台本身的升级同时进行的时候，网元管理模块出的故障占到了66.6%；而由于这些故障，测试由平常的两次，增加到平均7.25次，因此系统发布时间平均延误29天。在分析数据和项目现状之后，大家提出了两条措施：一是将系统平台的升级与网元管理模块的升级错开，系统版本发布以平台的升级为主；而为了解决网元管理模块的故障太多的问题，大家继续研究其解决方案。
在与许多开发人员和一线经理的讨论后，大家一致认为是由于自测不够充分造成的。按照CMM流程，这家企业要求软件项目在提交系统测试之前，需要提供功能清单和相应的自测报告。这个项目的自测报告每次都提供，它的一个片断是这样的形式：
