Oracle的实施
小组在项目的实施过程中，采用了一种被称为“快速循环的原型设计”的开发技术。采用这种技术，小组成员把实施过程划分成了一系列被称为“CRP”（Conference Room Pilot）的过程。每个CRP的目的是在前面工作的基础上进一步对软件进行理解，弄清它是如何在企业内发挥作用的。
第一个CRP（即CRP0）阶段是从对实施员工进行培训和建立技术环境开始的。项目小组在这个阶段同时进行这两项工作。一方面，集中精力培训员工，让他们熟悉Oracle的应用程序。在两周之内，项目小组的大部分成员都参加了这种对整个应用程序的“浸泡”式的培训。与此同时，一个名为“老虎之组”（tiger team）的小组正进行着另一件工作：安装应用程序并让它运行起来。
CRP0阶段实施的一个重要结果是思科不再坚持早期的一个实施目标，即避免修改ERP软件。避免修改之所以很重要，是因为软件改动常常都是公司行为，改动之后要升级到将来的版本就非常困难，而且很费时间。项目小组在第一个实施阶段的经验告诉他们，如果不对软件进行很多改动，它就不能有效地支持公司的业务。当一个月过去的时候，要做一些变动已经是很清楚的了；而两个月之后，做一些改变明显成为必要之举。
有了在CRP0阶段的教训，实施小组很快开始了CRP1。和先前的工作一样，这次的重点也是让系统不用修改就能很好地适应思科的业务流程。在CRP1阶段，小组成员制作了详细的底稿来记录完成每一个流程的目的与程序。为了保证所有的协同工作都得到解释，小组还设计了商业流程原型追踪表。与CRP0不同，小组成员将他们在建模过程中遇见的所有问题都记录了下来，并在由程序管理办公室每周召开的为时三小时的会议上提出来，让参加会议的各个部门的负责人来共同解决它们，从而推动整个项目向前发展。这个阶段的建模过程明确了软件的一些问题，确实有大量的商业流程该软件并不支持。
对于系统的不足，实施小组采取的应对措施是设计一种方法对每种不足进行分类和评估：“所有的修改要求被分为红色、黄色和绿色三类。每一类都要经由部门领导人的批准。其中，红色类的修改还必须有执行委员会的批准。”最后，总共需要30名开发人员三个月的时间来修改Oracle系统，以满足公司的实际需要。
发现需要对Oracle做一些修改使得项目计划和预算发生了一些意料之外的变化。除了要找到需要进行修改的地方之外，项目实施小组还发现Oracle的软件包不能充分支持公司的售后服务。因此，小组同时也开始评估和选择服务支持软件包。软件包被选定后，它的实施时间表也与整个项目的实施进度保持一致。思科的打算是让企业同时运行这两个软件包。
当从CRP1进入CRP2，也就是从夏天进入秋天以后，实施小组发现他们进入了实施任务最重、也是最困难的阶段。项目的范围已经扩大到所有重大的修改以及新的售后服务软件包。此外，另一个重要的范围也在发生变化。由于对后期项目的影响远远超过了预期程度，项目小组决定先解决一些重要的技术问题。在把各个系统直接连通起来之前（如点与点之间的连接），项目小组开发了—种新的技术，使得所有的数据通讯都通过一个“数据仓库”（data warehouse）来进行。利用数据仓库，可以让思科的所有应用系统只需要访问一个数据源，就可以获取他们所需要的信息。
范围的变化意味着思科进一步加强了对资源的利用，特别是对公司100人的IT部门的利用。很多范围的变化，由于技术上的原因，也要求IT部门承担起多数项目的附加责任。索尔维克是这样描述范围变化的结果的：
基本上，IT小组的所有其他人员都开始从其他项目上退了出来。他们说：“我们必须花时间以弄明白公司的核心系统正在发生改变这个事实，我们需要把越来越多的精力和资源转移到这个项目上来。”那一年，IT部门没有做任何其他事。我们也决定不再将任何历史的东西转移到这个项目上来。相反，由负责数据仓库的小组在一个整合的数据转换程序中对历史数据和将来的数据进行报告。我们重新清点了我们的客户、产品，对材料账单的结构做了变更，彻底更换了公司的所有基础数据，让数据仓库成为了联结历史和未来的沟通系统。
到CRP2结束时，第一阶段的修改开始发挥作用了。在CRP2，实施小组继续加深他们对Oracle和服务软件的理解，以判断如何才能使它们更好地为思科工作。CRP2的最终目标是开始对系统的软件和硬件进行测试，以判断它们是否能在思科业务量不断增长的情况下，正常地处理各种交易。
CRP3的重点是测试整个系统，并评估公司是否为系统的全面实施做好了准备。最后的测试是完全由用户来进行的，测试的目的是判断系统是否能从头到尾、正常地处理一笔完整的交易。实施小组的测试是这样进行的：他们先提取某天公司所有有价值的商业数据，并在一月的某个星期六重新在系统上运行它。在这个过程中，小组成员会监视每个部门模拟完成工作的情况。这个测试的结果令项目小组非常满意，以致在2月份，每个人都认为应该是接入新系统的时候了。
