There are several major advantages over other approaches:

• Evaluate, test and learn at minimal risk.
• Test more alternatives, more comprehensively.
• Easier to control conditions.
• Far faster and cheaper than full simulation, “live” pilot, parallel operation or “cold turkey”/“big bang” (total implementation all at once).
• Much more realistic than program/module technically- oriented testing.
• The CRP is slow, but it will usually result in better, faster implementation results in the long run.

Disadvantages exist as well:

• CRP’s are time-consuming.
• They initially slow down the implementation cycle, but can yield improved results.
• Require high degree of discipline, but so does implementing a major system - think of it as good practice.

How It Works

Recommended key elements of a successful CRP are outlined and briefly explained:

A. Planning/organization

• Objectives - It's a good idea to reiterate the system objectives or write them if you haven’t already. Good objectives are clear and quantifiable where possible. They directly support company strategic plan goals and objectives. CRP objectives should be selected from the applications section above and tailored to company objectives.

• Scope - It’s important to state what’s included - and not included - in your CRP. State the applications, organizations affected and the depth of involvement desired. For instance, do you want to completely re-engineer the process to eliminate all non-value added operations, or merely automate or convert an existing approach? Does the project encompass all company business systems, or just purchasing, MRP or accounts payable?

• Organization - Who will be responsible for directing, performing and acting upon the results? What is the role of each player? What degree of autonomy/empowerment is assumed? How will MIS, vendors, consultants be involved?

• Approach - How will the CRP project work? How will players go about their assigned tasks? What tools will be employed to accomplish the process?

• Project plan - Create major milestones, dates, supporting activities, responsibility assignments, precedence relationships, durations, resource requirements (people, equipment, outside support). The plan becomes the principal project management tool and may actually be a subset of a larger plan, such as MRPII implementation. Each application area needs to have its own milestones, responsible people and activity plan. We have found it works better to use at least some people whose regular job responsibilities lie in the affected areas.

B. Requirements definition/documentation

Some people say this shouldn’t be part of a CRP. It appears here for three reasons:

• Make sure it’s not forgotten.
• Put a business rather than a technical emphasis on the CRP.
• Put structure into the CRP effort.