The 'How To' guide to CRP...

After having gone through the 'How to guide to Requirement Gathering' and 'How to guide to Solution Design' Part 1 and Part 2, now is the time for your first CRP (Conference Room Pilot), often called (Naturally) 'CRP 1'.

Excited?

First of all, let us make clear what CRP is not. 

CRP is not product demo.

Many consultants often mix the two together. Product demo is what you do at the beginning of the project, showing the capabilities of the product, not knowing the typical requirements of the customer. In product demo, you help the customer take the first steps into the vast world of ERP. The objective of the product demo is to show to the customer the generic flows in a test organization.

But CRP is not product demo. Period

Between product demo and CRP, the implementation consultant would have completed the steps mentioned in requirement gathering and solution design. This means that in CRP, you are telling the customer as to how s/he is going to run his business in ERP. In ERP jargon, Requirement Gathering helps to identify the 'AS IS' processes and CRP demonstrates the 'TO BE' processes. 

In a non-customized implementation, CRP is the only TO BE Process demo that the consultant shows in the project. However, in a customized implementation, there are normally two CRPs, CRP 1, which shows the standard TO BE flows and CRP 2 which shows the customized 'TO BE flows.

In summary, CRP is not a Product Demo. It is a Demo of the 'TO BE' process that the customer will follow in ERP.

There are two key factors to be considered while planning for CRP

1. Tell it like Grandma said
2. Tell it as a story.

First, tell it like grandma advised. A little girl was preparing to give her first public speech. She was scared and asked her grandma for advice. Grandma consoled the little girl and adviced her to 1.Tell them what you are going to tell them, 2. Tell them, 3. Tell them what you told them.

You should heed grandma's advice while doing CRP. In CRP context, you can apply it as,

1. Tell 'em what you are going to tell 'em: Create a good introduction. You should mention the objectives of the CRP, how the CRP integrates with overall project plan, What is the role of each participant in the CRP and in the project, What are the steps that you have performed running up to CRP and how you are going to Schedule CRP.

2. Tell 'em: Do the CRP. Link the CRP to the introduction by cross-referencing the actual steps to the points mentioned in the introduction.

3. Tell 'em what you told 'em: At the end of CRP, summarize the key points that were covered (you have to do it regularly, as I explain below). Create a set of action items, which have to be completed by participants. Finally Schedule the next phase.

 The second thing to consider is, Tell CRP as a story.

What are the three components of the story?

1. Once upon a time, there lived the protagonists....
2. Protagonists underwent some experience...
3. They lived happily ever after

If you look at it, and ERP Implementation is the second part of the story. The protagonists are undergoing ERP Implementation Experience. They hope that this will be successful and they will 'Live with ERP happily ever after'.

This means that you have to weave the thread during an CRP. In fact CRP is your first opportunity, and probably the only opportunity, to link the current AS IS Processes and how the TO BE process is going to be beneficial to them. Throughout the CRP, this theme should play over and over. 'Earlier you were doing it like this', 'after ERP you will do it like  this', and 'these are the benefits' that will accrue to you. Always paint a positive picture to the client. 

Having laid down the above principles, how should you as a consultant approach CRP?

The following points are helpful.

1. Show confidence: Having taken requirements and designed the solution, you are the expert who is sitting with the customer. You are going to tell him, how he will run his business in ERP. For the customer, you are the guide and mentor. This means that you have to give the customer the confidence that they can trust you to design their business. That means that always you have to show that you are in command and in total control of the situation. 

2. Cross - reference: The audience to the CRP is the same team that gave you the requirements. A good CRP given by you is a validation to the customer that they have given correct requirements. While doing the CRP, always refer to the requirements given by the customer. ("John wanted the supplier CIC number to be entered when creating an Inovice. This is where he can enter this information. This can also be picked in the Supplier List report and the same information will also flow to payments"). John is happy.

3. Balance between Objectivity and Involvement: It is always good to be involved in customer's business and their challenges when doing the CRP. That passion shown during CRP can significantly improve the acceptability of ERP in the minds of the customers. However, one must also be objective enough not to over commit solutions which may not be possible.

4. Always demonstrate the flows: The normal tendency during the CRP is to show processes. For example, one set of audience will be shown how to create a Purchase Order, while another group will be shown how to create a receipt. This beats the purpose of CRP which is to show how ERP integrates the business. A PO user should know how a store keeper receives inventory in the system and how the costing user costs the item and the accounts user considers the accounting. This will give the PO user a clear idea of how each part of business is linked together. 

5. Summarize, Summarize, Summarize: One cannot emphasize the importance of Summary. At the end of each session, summarize what was demonstrated, take notes, take questions....

6. Provide quick clarifications: It is a normal habit of the consultant to promise to 'Get Back' when some clarifications are raised. If you have promised to 'Get Back', do 'Get Back' quickly. This will enhance your credibility.

7. Make it Personal: Rather than saying 'You will do this like this', say 'Bob will navigate to the Costing Window and enter the unit cost of the item'. 

8. Focus on Enquiries and Reports: As soon as you complete a transaction, go back to the Enquiry Screen or to the related reports and show the impact of the transactions on the system. This will increase buy in.

9. Go slow: You are the expert. You know all the short cut keys to quickly navigate from one window to another. The tendency is to navigate quickly to various screens and show them the transactions and their impact. Don't do that. Remember that demonstrating the navigation is a very important part of CRP. Always use narration like, 'now that we have completed the PO, let us navigate to PO Summary to review the PO that we created.  To navigate to PO Summary, we click on....'

10. Document: This is self-explanatory. Most of the critical requirements of the customer comes out during the CRP. Be alert and be aware of (sometimes 'Imperceptible') comments that users make. Take special note when the user is hesitant in giving his views. Those requirements, spoken hesitantly, could end up as a 'Show Stopper' later in the project. Document these requirements, try to understand their significance and provide solution.

The best outcome that you can have is for the customer to accept that you have understood and demonstrated the TO BE Process very clearly. This is a big win for you.

And the worst? (Sadly this happens in too many projects). Customer says that ERP will 'Complicate' my business, and you are forced to go through the cycle all over again.