Exploring the Who, What, When of Conference Room Pilots

By Eric Newell | April 25, 2019

Conference Room Pilots

First, this article addresses the mid-implementation conference room pilot (“CRP”). Many people talk about a conference room pilot as an activity in the sales cycle where you try before you buy. We tend not to do that because it's unlikely to be tailored enough to be a good experience for potential clients. If we did present something during the sales cycle we'd call that a "Hands-On Lab."

What is a Conference Room Pilot?

CRP is our first opportunity to try the system on for size as a team. Until this point in the project, most of the testing is siloed to the individual modules or processes we review during Joint Process Design. During CRP we string these processes together into end-to-end business scenarios. An example might be a sales process where we start with creating a customer, end with receiving payment from them, and cover all the processes in between. We repeat this for every business scenario we can think of.

When do you host a CRP?

So if it isn't during the sales cycle, when do you host a Conference Room Pilot? At Stoneridge Software, CRPs are executed during the Create phase of the project. The exact timing and number of CRPs depends upon the project – however, usually, we will execute a CRP after 2 or 3 rounds of Joint Process Design sessions. After a few JPD, we have gathered enough requirements and prepared the system well enough to try out some of the processes together as a team. CRP is your last chance to get into the system and make suggestions before you lock in on the design with which you plan to go live.

Who participates in a CRP?

The short answer is “everyone”. Planning a CRP is a collaboration between the project managers, the solution architect, and the QA Lead. The environment is prepared by the technical and functional consultants. The CRP tests are executed by the business process owners or subject matter experts with the functional consultants sitting close by in case they need help. If this is an enterprise implementation, you may want to seek participation from a wider range of team members with expertise in this area.

What do you cover in a CRP?

CRPs cover every business process your company uses. A typical CRP event lasts for about a week and is broken up into sessions that cover each process category that's in scope during the implementation. For example, you'd have a session on Quote to Cash which may include salespeople, warehouse staff, and accountants who will participate in that process. The goal is to make it through the system end-to-end in a way that makes sense. You wouldn't invite your purchasing team to the Quote to Cash CRP - you'd have a separate session for Procure to Pay.

What do you hope to accomplish in a CRP?

The main goal is to find any design flaws or changes in the system before you head into the Deploy phase of the project. Since this is usually your first time to put the process flow together from end-to-end you want to make sure the handoff between sales and warehouse or purchasing and accounting work as expected. You are seeking to validate the end-to-end process before it's too late to make changes to it.

What data is used during a CRP?

During the early CRPs you usually haven't finished every data topic in the data migration process, so you will need to fill in the gaps using a sampling of data in some areas. By sampling, I mean a small, representative set of data using examples from production. The more breadth you can get in your sample, the better. You will likely not get a chance to test the full dataset until the later rounds of CRP or even User Acceptance Testing.

What happens if you find problems in a CRP?

That is to be expected - you can start to identify bugs if you find them during the process but you're mostly on the lookout for design changes. Does the process as designed fit your business needs? You will still have a little bit of time to change your designs before they are set in stone, so you'll want to make those adjustments at this time. If you must radically rethink a process, your timeline may be at risk, so let's hope that doesn't happen.

What happens after a CRP?

The next immediate step is to review the design feedback and schedule any re-configuration or new development work right away. Once that is all complete and you are code complete, you move to the deployment phase of the project.

What is the difference between CRP and UAT (User Acceptance Testing)?

They look very similar - and are very similar. In both cases, you're testing the process end-to-end with the project team and subject matter experts in the system. There are structural differences in each event concerning the size of the testing team and the organization of the tests, however, the main difference is that CRP happens during the design phase where you can still make some fundamental changes to the system whereas UAT is during deployment where your primary aim is to validate the system and raise any bugs you find. In both cases, it's good to try to break the system to expose any potential issues that an end user might encounter in production. As mentioned in the data section, the CRP data is typically a sampling of your data (in part or whole) whereas the UAT is the full dataset.

The Importance of CRP

CRP can often be seen as an optional part of the implementation; however, I encourage clients to build it into the project plan as it accomplishes some important objectives:

  1. It gives the team a chance to practice the end-to-end process before UAT
  2. It helps with usability to have the team review the solution while you still have development time left
  3. It raises the team's confidence if they have the chance to put the system through its paces before UAT starts.

To learn more about the Create and Deploy phases mentioned above read our article on the Stoneridge Software Proven Process. 

If you’re ready to have a conversation about CRP or any other aspect of your ERP project feel free to contact us.

Eric Newell
Our Verified Expert
Eric Newell

Eric Newell is the CEO and Founder of Stoneridge Software. Since founding the company in October 2012, Eric has led the Stoneridge Software organization through rapid growth in team members, clients, services and product offerings and consistently successful ERP and CRM implementations. Eric was named Entrepreneur of the Year by the Fargo Moorhead West Fargo Chamber of Commerce in 2016. Prior to founding the company, Eric spent 13 years at Microsoft and led the North America Premier Field Engineering team for Dynamics.

Read More from Eric Newell

Related Posts


Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.

Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.

Start the Conversation

It’s our mission to help clients win. We’d love to talk to you about the right business solutions to help you achieve your goals.

Subscribe To Our Blog

Sign up to get periodic updates on the latest posts.

Thank you for subscribing!