以上面的模型说明当前的遇到的情况：
业务线1，2，3在根据自己的业务的情况研究一款工具，这款工具用来支持各自业务条线的展开，每个工具的研发阶段不同，使用的技术也不同，接口协议也有差别，解决问题的方式也有不同之处，这个时候，组织看到了这三个工具有相同之处，想通过一个项目把三个工具整合起来，作为一个统一的平台同时支持三条业务线的工作。
面临的问题是，最终的技术方案不确定，项目的责任人选择有困难。因为涉及到三个遗留系统的改造和迁移，这个项目不是单纯的新系统上线对接，而是老系统改造+新的上线对接，三个系统几乎都要改造保留部分功能，选择任意的原遗留系统责任人做整个项目的负责人？还是选择一个三个业务线之外的人做项目的整体负责人？还是成立项目联合管理小组，由A1，A2，A3+B1共同负责？
选择A1，A2，A3其中一人作为主要负责人的问题
当前技术方案不确定，因此选择其中的任意一人都有可能造成，主管人极力推广自己的系统到其他的业务线，或者最后主管人自己的系统被砍掉，其他的系统上线，因此自己变得有权无实，工作难以开展；责任和权利不匹配，难以行权；
选择B1作为主要负责人的问题
B1是独立于3条业务线的人，任何系统上位对他都没有影响，因此B1不会有偏见，立场比较公正；但是这样貌似会影响A1，A2，A3的积极性，毕竟从他们的角度出发，自己的系统得以推广，自己的收益应该最大，但是项目的主要负责人不是自己，好像是给其他人做了嫁衣裳；责任和利益不匹配，A的积极性无法调动；
选择三个A和B1做联合负责人的问题
成立项目管理小组的问题貌似是大家都有和责权利，貌似动力应该是有了，但是会产生实际的问题。这个做法实际上是把问题隐藏到这个小组内部，问题并不会消失。产生的后果就是在项目的进行中，这个小组内部会有很多问题难以达成一致，甚至会导致客观正确的方案无法实施，多头管理在权责不清的情况下也会让执行产生混乱；
让一个事情做的顺利，关键是责、权、利的相互匹配
使主管人可以
- 主管人责任清晰，立场公正；
2.有行使权利的能力，下属要听其指挥；
3.有做事的意愿，可以获得相应的收益；
就上述案例而言，难点在于上面的三种方法都是有缺陷的，原因是对于项目的不同阶段，出现了责任主体的变化，难以一套班子做到底；
因此这样的项目应该按照责任主体的变化拆解成不同的子项目进行执行，即项目集program；拆解的维度取决于项目的责任主体。
上述的案例就适合于首先按照时间分成规划和实施两个阶段；
规划阶段由B1牵头统一负责，产出统一的技术方案；
实施阶段按照A1～A3业务线拆分成3个子项目，由业务线工具负责人负责改造和实施；
这种方式，对于每一个项目，都可以达到责权利的基本匹配，可以从很大程度上改善执行效果；
这类项目在实施过程中，仍然有利益敏感性问题，这个时候原则始终应该是做正确的事情是第一位，利益分配是第二位，因此为了防止因为利益让方案变形，第三方咨询顾问公司就被引入了。
